Hacking PCI-ids to allow Atheros NIC into Lenovo laptop.
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Hi,
Quoted 8 lines · Ben Greear
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.
Quoted 6 lines
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
Hi Ben,
Quoted 3 lines · Ben Greear
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
Quoted 3 lines
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,
Signature · 5 lines
Julian Calaby Email: [email protected] Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/
Quoted 8 lines · Ben Greear
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.
Quoted 6 lines
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.
Quoted 26 lines · Christian Lamparter
Quoted 8 lines · Ben Greear
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.
Quoted 6 lines
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 thenew_idsysfs interface] (Of course, you'll have to get rid of the intel driver first)
Quoted 5 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 37 lines · Ben Greear
Quoted 36 lines · Christian Lamparter
Quoted 11 lines · Ben Greear
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.Quoted 6 lines
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_idsysfs 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.
Quoted 6 lines
Quoted 2 lines
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
Quoted 9 lines · Luis R. Rodriguez
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.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 12 lines · Matthew Garrett
Quoted 9 lines · Luis R. Rodriguez
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.
Quoted 3 lines
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
Quoted 5 lines · Luis R. Rodriguez
Quoted 3 lines
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
Quoted 10 lines · Adrian Chadd
Quoted 5 lines · Luis R. Rodriguez
Quoted 3 lines
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.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 45 lines · Luis R. Rodriguez
Quoted 37 lines · Ben Greear
Quoted 36 lines · Christian Lamparter
Quoted 11 lines · Ben Greear
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.Quoted 6 lines
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 thenew_idsysfs 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.Quoted 6 lines
Quoted 2 lines
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.
Quoted 9 lines
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
Quoted 2 lines
Luis
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Hi Ben,
Quoted 4 lines · Ben Greear
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,
Signature · 5 lines
Julian Calaby Email: [email protected] Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/