Trying to get 108mbps w/DLink DI-624 router and IBM a/b/g

[Nolonemo]

I want to point out to everyone that when I first installed this card, windows handled the connection and reported 108mbps - this was *not* the case however - when I timed an FTP transfer over the unloaded network, I observed 54mbps speeds (or, in real terms, 22mbps+)

If you are being told by windows connection manager that you are connected at 108mbps, take that with a huge grain of salt....

The windows network icon will show you at 108MPBS, but your real connect speed should be shown by the card's connection applet icon (if it's in your system tray). Also, my experience with SuperG is that the transfer rate is only bumped above 54mbps when you are doing large file transfers that load the network for more than a few seconds.

[nonyNony]

Tubo mode may be crippled in the eeprom of the 11 a/b/g II card.

See the following link - http://www.thinkwiki.org/wiki/Super_A/G

If this is the case, the documented registry tweaks will not be able to enable it.

If you suspect that your card is crippled you can confirm this by going to a command prompt and entering the following string -

wmic /namespace:\\root\wmi path atheros5000_diageverything get /format:value

The values of interest are AthAdhocWirelessModes, AthInfraWirelessModes, AthHwCapWirelessModes, AthHwExtraCap, and AthTurboMode.

A crippled card in general, will have Ath*WirelessModes set to 13 (0x0d) ==>11A, 11b, 11g and no turbo.

HAL_MODE_11A = 0x001,
HAL_MODE_TURBO = 0x002,
HAL_MODE_11B = 0x004,
HAL_MODE_PUREG = 0x008,
HAL_MODE_11G = 0x010,
HAL_MODE_108G = 0x020,
HAL_MODE_XR = 0x040,

-neil

[andrey]

This is sad, running T42p 2373-P1U

>wmic /namespace:\\root\wmi path geverything get /format:value

Active=TRUE
AthAdhocWirelessModes=12
AthAnalog2GhzRev=0
AthAnalog5GhzRev=54
AthBssid={0,15,61,39,254,139}
AthChannelFlags=0
AthCurrentChannel=335546772
AthDeviceID=4116
AthDiagHungCount=0
AthDiagNdisResets=0
AthDiagSelfResets=0
AthEncryptionAlg=1
AthGoodReceiveBytes=41773843
AthGoodTransmitBytes=4907093
AthHwCapWirelessModes=13
AthHwExtraCap=126
AthInfraWirelessModes=13
AthMacRev=89
AthNetworkType=0
AthNicSKU=2
AthPhyRev=67
AthPowersaveState=0
AthRcvDataRate=54
AthRcvDecryptErrors=0
AthRcvDuplicates=361
AthRcvFifoOverruns=0
AthRcvHwFcsErrors=10327
AthRcvMulticastFrames=0
AthRcvMultipleDuplicates=0
AthRcvRssi=38
AthRcvSwFcsErrors=162131
AthRegulatoryDomain=6704705
AthSsid={68,76,105,110,107,45,56,50,52,0,0,0,0,0,0,0,0,0,0,0,0,0,,0,0}
AthStationState=3
AthSubVendor_DeviceID=1406
AthSubVendorID=4116
AthTurboMode=0
AthVendorID=5772
AthXmitAckRssi=33
AthXmitDataRate=54
AthXmitExcessiveRetries=6
AthXmitFifoUnderruns=0
AthXmitFiltered=0
AthXmitHwAcksMissing=3001
AthXmitRequests=26863
AthXmitRequestsDenied=95
AthXmitRetries={973,340,129,0,0,0,0,0,0,0,0,0,0,0,0}
AthXmitRtsErrors=3
InstanceName=11a/b/g Wireless LAN Mini PCI Adapter II
NdisGenMediaConnectStatus=0
NdisGenRcvOk=38648
NdisGenXmitOk=49329
siteSurvey=0

[nonyNony]

To enable turbo modes on a crippled 11 a/b/g II card, two eeprom values need to be modified -

1) Offset 0xBF [Regulatory] needs to be changed from 0x66 t0 0x60.

2a) Offset 0xC2 [Capabilities] needs to be changed from 0xDA0F to 0x1A07.

2b) Offset 0xCC (or any unused eeprom address) needs to be changed from 0x00 to 0xC8 to compensate for the change made in step 2a - or the checksum will fail.

To determine the current Regulatory value from a command prompt enter -

wmic /namespace:\\root\wmi path atheros5000_regulatory get /format:value

The decoding of the Capabilites word is as follows -

* bit 0: 802.11a supported if set
* bit 1: 802.11b supported if set
* bit 2: 802.11g supported if set
* bit 3: turbo rates at 2GHz disabled if set
* bit 4: turbo rates 2GHz power limit
* bit 5:
* bit 6:
* bit 7:
* bit 8:
* bit 9:
* bit 10:
* bit 11: device type
* bit 12:
* bit 13:
* bit 14: RF kill supported if set
* bit 15: turbo rates at 5GHz disabled if set

I used wbemtest to change Regulatory (step 1), and PCItree http://www.pcitree.de to manually peek and poke the PCI config, memory, and eeprom space (steps 2a and 2b). However, I wouldn't recommend these tools unless you really know what you are doing.

-neil

[andrey]

nonyNony, could you post step by step instructions as to what to do? I personally would greatly appreciate that!

-- Andrey

[jsteele]

nonyNony, could you post step by step instructions as to what to do? I personally would greatly appreciate that!

-- Andrey

The ideal solution would be some sort of script if possible?

[nonyNony]

I agree that there ought to be a script or executable to make the changes.

The source code for changing the regulatory domain and capability bits is available - if you're running linux - http://www.ksp.sk/~rasto/mod2.c.
Perhaps the author of the solution, Rasto Sramek, could assist - http://lists.gnumonks.org/pipermail/ath ... 00134.html.

Unfortunately, the tools that I used can do more damage than good if you've never used them before. You also need to have a certain amount of expertise in PCI devices, and a listing of the Atheros registers to pull this off.

The intent of this post is to report back that the eeprom fix will also work under XP, and not just under Linux.



-neil

[Captain Igloo]

I can only reiterate that you should only do this if you know what you are doing.
I know my way around PCI, but using pcitree I managed to overwrite word 0 of the eeprom (still no idea how that happened) on the mini-pci card in my R50p. Now, word 0 holds the device identifier of the card, so the machine came up with the infamous 1802 error on next bootup. I had to:

1. remove the mini-pci card
2. apply the no1802 patch via a linux bootdisk and reinstall it
3. find out/guess what happened and feel pretty stupid
4. find that i can't access the eeprom if the driver is not started
5. install Linux
6. install the atheros drivers and find out that my kernel is too old (you need git, so: apt-get install curl, apt-get install libcurl3, get git, compile and install it, get the atheros drivers)
7. install a new kernel
8. patch the atheros drivers to accept the changed device id
9. change the device id back using a patched version of mod2.c
10. undo the no1802 patch (not necessary, but i like my equipment in its original state).

cost me 8 hours in work and probably a few months of my life in stress...

In hindview i could have skipped 6-8 and used a patched version of the madwifi drivers instead, see here for a description of a user who changed the driver id successfully. The atheros driver method would also work when your eeprom checksum is broken though.

On the positive side everything works again, but on the downside i still don't have 108 Mbps. Madwifi shows SuperA as available when i change the regulatory domain from 0x61 to 0x60, but i still don't get SuperG.

[nonyNony]

I can only reiterate that you should only do this if you know what you are doing.
I know my way around PCI, but using pcitree

I managed to overwrite word 0 of the eeprom
.
.
.
.
4. find that i can't access the eeprom if the driver is not started

The trick is to use PCItree to configure the EEPROM, config space registers, and memory mapped registers while the driver is *unloaded*.

In fact, the driver will only get in your way, and should not be loaded during your PCItree session. You should disable the device or unload the driver (same effect) and then use PCItree to "start" the device -

1) Apply Power to the device- take the device out of any power save mode.
2) Take the device out of reset.
3) Confirm that the device has started - you will notice that the registers and buffer area now have non-zero values.
4) Write to the EEPROM.
Note: If the relevant EEPROM write protect bits are set, you need to clear them first. [It's been incorrectly reported that a write-protected EEPROM is a show stopper.]
5) Check your work.

If you botched things up, and your driver will not bring up the device, you can always go back and fix things up (as long as you can get your pc to boot, of course).

When you are manually flipping bits, you really need to get the driver out of your way since its also flipping bits in the same memory space, and this could mess up your work.

It's also useful to have the Atheros Linkmon utility handy. Linkmon will show you which channels are being scanned. If you are configured correctly, you will notice that the turbo A/G channels are being scanned, and when you associate in turbo mode, you will see exactly what channel, frequency, link speed, and mode ("T" for turbo) you are operating in. There is no need to speculate.


nN

[_erazor_]

this basically sounds as if it can NOT be done in windows, rite?

[nonyNony]

this basically sounds as if it can NOT be done in windows, rite?

for the record, this was done in windows.

Changing a few bits to enable a feature, once you know which bits need to be changed, is a trivial thing to do, in theory, and does not rely upon any particular operating system.

However, you usually need specialized tools to access protected memory stores. PCItree is one such tool which allows you to read/write the PCI config space and memory space. PCIScope is another such tool such and comes with excellent documentation on the PCI specs and their real-world implementation.

Both of these tools run on Windows.

nN

[code2]

I have request..

Where I find drivers for IBM Thinkpad 802.11abg Wireless WIFI MiniPCI 91P7301 (Philips)
chipset: Atheros AR5212 (aka /5001X+/) ??

This driver http://www-307.ibm.com/pc/support/site. ... MIGR-52527 didn work

thx for help!