It seems we bought a Lenovo laptop that has a BIOS lock where it will only
support certain wifi NICs based on the pci-id. It came with an Intel
NIC, so at least that ID must work...
One way around this might be to over-write the pci-id of an Atheros NIC
in it's non-volatile storage to make it look like an Intel, at least until
the kernel boots.
Then maybe add some sort of ugly code to force the Atheros driver
to manage this Intel pci-id (and probably disable the same pci-id in
the Intel driver).
Has anyone tried doing anything like this? Any suggestions for a cleaner
way to go about this?
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 03/12/2012 03:32 PM, Christian Lamparter wrote:
> On Monday, March 12, 2012 10:52:49 PM Ben Greear wrote:
>> It seems we bought a Lenovo laptop that has a BIOS lock where it will only
>> support certain wifi NICs based on the pci-id. It came with an Intel
>> NIC, so at least that ID must work...
>>
>> One way around this might be to over-write the pci-id of an Atheros NIC
>> in it's non-volatile storage to make it look like an Intel, at least until
>> the kernel boots.
>>
>> Then maybe add some sort of ugly code to force the Atheros driver
>> to manage this Intel pci-id (and probably disable the same pci-id in
>> the Intel driver).
>>
>> Has anyone tried doing anything like this? Any suggestions for a cleaner
>> way to go about this?
> Been down this road before. First an old X41 Tablet and more recently a HP
> dv6 laptop.
>
> I think if you manage to reprogram the cards pciids then you are more than
> halfway there. Because theoretically, you can get away with adding the fake
> intel id to ath9k through sysfs:
>
> echo "8086 dead"> /sys/bus/pci/drivers/ath9k/new_id
> [for more information, take a look at the new_id sysfs interface]
> (Of course, you'll have to get rid of the intel driver first)
>
> That said, in both cases I risked flashing a modded bios. So whitelists are
> no longer a problem.
>
> PS: AFAIK [Maybe some QCA dev can verify this]: all AR9300+ have OTP ROMs
> for the pciids. So you might want to get an older AR9280 for your laptop.
We're hoping to use the WPEA-127N.
Thanks for all the info!
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Mon, Mar 12, 2012 at 3:36 PM, Ben Greear <[email protected]> wrote:
> On 03/12/2012 03:32 PM, Christian Lamparter wrote:
>>
>> On Monday, March 12, 2012 10:52:49 PM Ben Greear wrote:
>>>
>>> It seems we bought a Lenovo laptop that has a BIOS lock where it will
>>> only
>>> support certain wifi NICs based on the pci-id. It came with an Intel
>>> NIC, so at least that ID must work...
>>>
>>> One way around this might be to over-write the pci-id of an Atheros NIC
>>> in it's non-volatile storage to make it look like an Intel, at least
>>> until
>>> the kernel boots.
>>>
>>> Then maybe add some sort of ugly code to force the Atheros driver
>>> to manage this Intel pci-id (and probably disable the same pci-id in
>>> the Intel driver).
>>>
>>> Has anyone tried doing anything like this? Any suggestions for a cleaner
>>> way to go about this?
>>
>> Been down this road before. First an old X41 Tablet and more recently a HP
>> dv6 laptop.
>>
>> I think if you manage to reprogram the cards pciids then you are more than
>> halfway there. Because theoretically, you can get away with adding the
>> fake
>> intel id to ath9k through sysfs:
>>
>> echo "8086 dead"> /sys/bus/pci/drivers/ath9k/new_id
>> [for more information, take a look at the new_id sysfs interface]
>> (Of course, you'll have to get rid of the intel driver first)
>>
>> That said, in both cases I risked flashing a modded bios. So whitelists
>> are
>> no longer a problem.
>>
>> PS: AFAIK [Maybe some QCA dev can verify this]: all AR9300+ have OTP ROMs
>> for the pciids. So you might want to get an older AR9280 for your laptop.
>
>
>
> We're hoping to use the WPEA-127N.
I might as well chime in to explain the long story. If we figure out a
way to ensure we can always get the antenna gain uniformly across
different systems and expose this to the OS I suspect we can convince
some OEMs this would be a better solution than simply restricting
devices. I looked a the newer generation of dmidecode (its not called
DMI, its something else now) thingy but saw no one yet had added
802.11 specifically, perhaps it may be good to consider it in the
future for this. that's as far as I got from trying to kill this
concern.
Luis
Hi,
Le 12/03/2012 22:52, Ben Greear a ?crit :
> It seems we bought a Lenovo laptop that has a BIOS lock where it will only
> support certain wifi NICs based on the pci-id. It came with an Intel
> NIC, so at least that ID must work...
>
> One way around this might be to over-write the pci-id of an Atheros NIC
> in it's non-volatile storage to make it look like an Intel, at least until
> the kernel boots.
>
> Then maybe add some sort of ugly code to force the Atheros driver
> to manage this Intel pci-id (and probably disable the same pci-id in
> the Intel driver).
>
> Has anyone tried doing anything like this? Any suggestions for a cleaner
> way to go about this?
The only viable hack that I have came to with my laptop (Lenovo X61) is
to have a patched BIOS. Fortunately the web is full of such modified
BIOSes enabling various features (SATA2 vs SATA1, Wireless NICs
whitelisting ...)
--
Florian
On Mon, Mar 12, 2012 at 05:53:03PM -0700, Luis R. Rodriguez wrote:
> I might as well chime in to explain the long story. If we figure out a
> way to ensure we can always get the antenna gain uniformly across
> different systems and expose this to the OS I suspect we can convince
> some OEMs this would be a better solution than simply restricting
> devices. I looked a the newer generation of dmidecode (its not called
> DMI, its something else now) thingy but saw no one yet had added
> 802.11 specifically, perhaps it may be good to consider it in the
> future for this. that's as far as I got from trying to kill this
> concern.
Exposing it as either an smbios table or in ACPI somewhere would be the
two most typical methods for doing this. It's easy to spec an ACPI table
for it if you think there'd be any vendor interest.
--
Matthew Garrett | [email protected]
On Tue, Mar 20, 2012 at 10:01:05PM -0700, Adrian Chadd wrote:
> On 12 March 2012 18:11, Luis R. Rodriguez <[email protected]> wrote:
>
> >> Exposing it as either an smbios table or in ACPI somewhere would be the
> >> two most typical methods for doing this. It's easy to spec an ACPI table
> >> for it if you think there'd be any vendor interest.
> >
> > Better than what we have today, no alternative proposal.
>
> Is there any current "vendor space" in ACPI that we can write to and
> leverage as a kind of example test case?
Not really. In theory the ACPI namespace is only usable if you've pushed
something through the ACPI process - in practice, grabbing a table name
first and asking questions later tends to work fine.
--
Matthew Garrett | [email protected]
Hi Ben,
On Tue, Mar 13, 2012 at 11:58, Ben Greear <[email protected]> wrote:
> Seems like laptop vendors are just being lame. ?Why can normal PCs
> get away with no restrictions but somehow laptop makers have to do this??
>From what I've read, the issue isn't the card or regulatory itself,
it's the antennae.
In a desktop situation, you have a card with an detachable antenna,
and the card / antenna unit can be confirmed to comply with whatever
regulations are in effect.
In a laptop, the antennae are usually part of the laptop body, and
only the card itself is replaceable, so the manufacturer is locking
out cards that it has not tested with the built-in antennae.
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
On Mon, Mar 12, 2012 at 5:57 PM, Matthew Garrett <[email protected]> wrote:
> On Mon, Mar 12, 2012 at 05:53:03PM -0700, Luis R. Rodriguez wrote:
>
>> I might as well chime in to explain the long story. If we figure out a
>> way to ensure we can always get the antenna gain uniformly across
>> different systems and expose this to the OS I suspect we can convince
>> some OEMs this would be a better solution than simply restricting
>> devices. I looked a the newer generation of dmidecode (its not called
>> DMI, its something else now) thingy but saw no one yet had added
>> 802.11 specifically, perhaps it may be good to consider it in the
>> future for this. that's as far as I got from trying to kill this
>> concern.
>
> Exposing it as either an smbios table or in ACPI somewhere would be the
> two most typical methods for doing this. It's easy to spec an ACPI table
> for it if you think there'd be any vendor interest.
Better than what we have today, no alternative proposal.
Luis
On 12 March 2012 18:11, Luis R. Rodriguez <[email protected]> wrote:
>> Exposing it as either an smbios table or in ACPI somewhere would be the
>> two most typical methods for doing this. It's easy to spec an ACPI table
>> for it if you think there'd be any vendor interest.
>
> Better than what we have today, no alternative proposal.
Is there any current "vendor space" in ACPI that we can write to and
leverage as a kind of example test case?
Adrian
On 03/12/2012 05:53 PM, Luis R. Rodriguez wrote:
> On Mon, Mar 12, 2012 at 3:36 PM, Ben Greear<[email protected]> wrote:
>> On 03/12/2012 03:32 PM, Christian Lamparter wrote:
>>>
>>> On Monday, March 12, 2012 10:52:49 PM Ben Greear wrote:
>>>>
>>>> It seems we bought a Lenovo laptop that has a BIOS lock where it will
>>>> only
>>>> support certain wifi NICs based on the pci-id. It came with an Intel
>>>> NIC, so at least that ID must work...
>>>>
>>>> One way around this might be to over-write the pci-id of an Atheros NIC
>>>> in it's non-volatile storage to make it look like an Intel, at least
>>>> until
>>>> the kernel boots.
>>>>
>>>> Then maybe add some sort of ugly code to force the Atheros driver
>>>> to manage this Intel pci-id (and probably disable the same pci-id in
>>>> the Intel driver).
>>>>
>>>> Has anyone tried doing anything like this? Any suggestions for a cleaner
>>>> way to go about this?
>>>
>>> Been down this road before. First an old X41 Tablet and more recently a HP
>>> dv6 laptop.
>>>
>>> I think if you manage to reprogram the cards pciids then you are more than
>>> halfway there. Because theoretically, you can get away with adding the
>>> fake
>>> intel id to ath9k through sysfs:
>>>
>>> echo "8086 dead"> /sys/bus/pci/drivers/ath9k/new_id
>>> [for more information, take a look at the new_id sysfs interface]
>>> (Of course, you'll have to get rid of the intel driver first)
>>>
>>> That said, in both cases I risked flashing a modded bios. So whitelists
>>> are
>>> no longer a problem.
>>>
>>> PS: AFAIK [Maybe some QCA dev can verify this]: all AR9300+ have OTP ROMs
>>> for the pciids. So you might want to get an older AR9280 for your laptop.
>>
>>
>>
>> We're hoping to use the WPEA-127N.
>
> I might as well chime in to explain the long story. If we figure out a
> way to ensure we can always get the antenna gain uniformly across
> different systems and expose this to the OS I suspect we can convince
> some OEMs this would be a better solution than simply restricting
> devices. I looked a the newer generation of dmidecode (its not called
> DMI, its something else now) thingy but saw no one yet had added
> 802.11 specifically, perhaps it may be good to consider it in the
> future for this. that's as far as I got from trying to kill this
> concern.
Seems like laptop vendors are just being lame. Why can normal PCs
get away with no restrictions but somehow laptop makers have to do this??
Seems ethtool cannot dump eeprom from the atheros NICs I have
(including the WPEA-127N). Any idea if it's possible to add
the ability to dump (and eventually write) to the WPA-127N
(and possibly others)?
Thanks,
Ben
>
> Luis
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Monday, March 12, 2012 10:52:49 PM Ben Greear wrote:
> It seems we bought a Lenovo laptop that has a BIOS lock where it will only
> support certain wifi NICs based on the pci-id. It came with an Intel
> NIC, so at least that ID must work...
>
> One way around this might be to over-write the pci-id of an Atheros NIC
> in it's non-volatile storage to make it look like an Intel, at least until
> the kernel boots.
>
> Then maybe add some sort of ugly code to force the Atheros driver
> to manage this Intel pci-id (and probably disable the same pci-id in
> the Intel driver).
>
> Has anyone tried doing anything like this? Any suggestions for a cleaner
> way to go about this?
Been down this road before. First an old X41 Tablet and more recently a HP
dv6 laptop.
I think if you manage to reprogram the cards pciids then you are more than
halfway there. Because theoretically, you can get away with adding the fake
intel id to ath9k through sysfs:
echo "8086 dead" > /sys/bus/pci/drivers/ath9k/new_id
[for more information, take a look at the new_id sysfs interface]
(Of course, you'll have to get rid of the intel driver first)
That said, in both cases I risked flashing a modded bios. So whitelists are
no longer a problem.
PS: AFAIK [Maybe some QCA dev can verify this]: all AR9300+ have OTP ROMs
for the pciids. So you might want to get an older AR9280 for your laptop.
Hi Ben,
On Tue, Mar 13, 2012 at 08:52, Ben Greear <[email protected]> wrote:
> It seems we bought a Lenovo laptop that has a BIOS lock where it will only
> support certain wifi NICs based on the pci-id. ?It came with an Intel
> NIC, so at least that ID must work...
This is standard with Lenovo (and I believe this originated back when
IBM was building the machines) as it's their method of ensuring some
form of compliance - i.e. they guarantee that it complies with
More details here:
http://www.thinkwiki.org/wiki/Problem_with_unauthorized_MiniPCI_network_card
> One way around this might be to over-write the pci-id of an Atheros NIC
> in it's non-volatile storage to make it look like an Intel, at least until
> the kernel boots.
That is one of the solutions discussed on that page, it also discusses
a few others with varying amounts of success.
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/