Enable Channel 12 and 13 on Intel Pro 3945ABG?
 

First post here, so please be gentle....

I need to enable channel 12 and 13 on this wireless adapter to avoid frequency congestion. I`ve got the EEPROM to dump using ethtool -e and I `think` I can see the value that needs changing (4d - the character `M`). I`m referencing a patch explained here -

http://dzello.com/ipw2200.html

I`m fairly sure I should be able to change the value to what`s required (52 - the character `R`) using the magic command. However I think this will toast the adapter unless I can repair the checksum.

The previous link references code that will repair the checksum for an Intel 2200. Would it be reasonable to assume this won`t repair the checksum on an Intel 3945?

Is there a way to glean which is the checksum looking at the hex dump? Is it possible to manually change this to suit using the magic command?

I`m using Knoppix v6.0.1 with total experience in Linux of about 2hrs...

Hex dump for info -

0x0000 00 15 b7 20 26 e6 20 0b b9 f2 51 00 ff ff ff ff
0x0010 ff ff ff ff 6b 02 01 00 79 11 9a 10 86 80 df 80
0x0020 00 00 00 20 54 7e 00 00 14 00 da 00 04 00 00 27
0x0030 c9 6c 50 31 3e 07 0b 04 8b 29 00 00 00 f0 09 02
0x0040 08 10 00 00 04 0f ff 7f 01 4d ff ff ff ff ff ff
0x0050 14 00 1d 00 14 00 1d 00 af aa 1e 00 00 00 1d 00
0x0060 e4 00 3f 40 1f 12 ff ff ff ff ff ff ff ff ff ff
0x0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0c 05

I`ve found more details here -

http://www.thinkwiki.org/wiki/Intel_...xpress_Adapter

To quote - "If you are not in the US, more Wifi channels are available (EU: 13 instead of 11). If you cannot see your Wifi, but you know it is there, check if it is on Channel 12 or 13.

To fix, create /etc/modprobe.d/iwl3945-fix and add the following line: "options cfg80211 ieee80211_regdom=EU". Reload to the driver for the change to become active: "modprobe -r iwl3945", then "modprobe iwl3945".


I don`t understand how to `create /etc/modprobe.d/iwl3945-fix` as described. Where is this entered?

In general it is telling you to create a text file called iwl3945-fix and save it to /etc/modprobe.d/ with the contents listed above, If /etc/modprobe.d does not exist I guess you create it and any ways after reloading the driver what you want should be done. NOTE: You may be violating some FCC rules I don't know.

One way to get channels 12 and 13 on a MoW1 card (US card) is to download the ipw3945-1.2.2 driver and patch it following these instructions here.

Then edit ipw3945.c and after the statement on line 4684 which is:
case DAEMON_REQUEST_EEPROM:

add these four lines

priv->eeprom[0xdc] = 0x2b;
priv->eeprom[0xdd] = 0x0f;
priv->eeprom[0xde] = 0x2b;
priv->eeprom[0xdf] = 0x0f;


Recompile and install the module and you've unlocked all 13 channels with any Intel 3945 card. All we've done here is overwrite the in memory copy of the eeprom with values that enable channels 12 and 13 before it is passed to the regulatory daemon for enforcement.

It would be nice to be able to write these to the eeprom but following the steps suggested above appears to work, but after reloading the module the old eeprom values remain.

Thanks firefighter. Unfortunately my involvement in Linux is just to get the Intel 3945 modified to work within a Windows environment (I know...boo, hiss):tisk:

Would it be likely the `magic` command referenced here -

http://dzello.com/ipw2200.html

could be used to change to the values you`ve just described?

Or is there still the issue of the checksum update?

Yes, that's the command I tried. I didn't receive any errors and the value appeared to have changed but when I removed and reinserted the module the old value remained. I assumed that the magic number for this card is 3945 as it was 2200 for the other card. I'll keep trying. What would be helpful is to determine the exact model number of the eeprom chip. This requires removing the sticker on the card which I haven't had a change to do yet.

Ok, so the eeprom on the Intel Wifi 3945 and 4965 (iwl3945/iwlagn) chips is an SPI 1024 byte eeprom. See the datasheet for an ATMEL 25080 eeprom chip. Any SPI mode 0/3 eeprom of equivalent size should work.

The hard part is unsoldering it, correcting the relevant values and reattaching it. It may also be possible to program in place.

I noticed this in the AT25080 documentation -

WRITE PROTECT: The write protect pin (WP) will allow normal read/write operations when
held high. When the WP pin is brought low and WPEN bit is “1”, all write operations to the status
register are inhibited. WP going low while CS is still low will interrupt a write to the status
register. If the internal write cycle has already been initiated, WP going low will have no effect
on any write operation to the status register. The WP pin function is blocked when the WPEN
bit in the status register is “0”. This will allow the user to install the AT25080/160/320/640 in a
system with the WP pin tied to ground and still be able to write to the status register. All WP
pin functions are enabled when the WPEN bit is set to “1”.

I have 3945 and can solder and unsolder eeprom without any problems many times. Mine card is for IBM laptop (for US). Also I have already got the dump.
If you want I can post my dump and test your modified dumps on my card.

Also the eeprom can be programmed in place (write protection pin is connected to VCC on the card - so there is no WP). But it is easier to unsolder it.

sounds good, see attached. (created with xxd) use xxd -r to create actual content.Attachment 2533 Attachment 2534

hmm... it looks like the eeprom was read as reversed words... here is my original dump, that was read byte by byte from eeprom using spi programmer.
In other words your dump is in Little Endian encoding, my one is in Big Endian. I'll try to convert your dump and test it. What dump shuold I test? dump1 or dump? Why did you change byte at 0x291?

This was my first go at tinkering with the eeprom. I was just following the steps provided in Tic's original post. I doubt this one will work. As I mention above the way I got it to work was to change these bytes.
priv->eeprom[0xdc] = 0x2b;
priv->eeprom[0xdd] = 0x0f;
priv->eeprom[0xde] = 0x2b;
priv->eeprom[0xdf] = 0x0f;

I did this using the old driver which loads in the eeprom and then passes it to a regulatory daemon, so by making the above changes after they are loaded but before it is passed to the regulatory daemon I was able to make the driver display 13 channels. And connect with them. If you view the hex dump I figured out that there is a row of + symbols, in fact 11 of them. So we know bytes 0xdc/0xdd control channel 12 and bytes 0xde/0xdf control channel 13. The other changes that I have experimented with are changing 0xC0 - 0xC3 (ie MoW1) to MoW2 or RoW1. Although I haven't proven this is used by the firmware or driver.

The last challenge is to determine the checksum method used and which bytes are used. So far my theory is that 0x20 and 0x21 are the checksum values which is computed by adding up a series of bytes in the eeprom. If you can post your dump we can compare and try that. But in the short term just try changing the four values above in your original eeprom and see if it is accepted.

sorry, I haven't tested your dumps yet.
I've posted link to my dump in the reply above - you can download it and compare.
Also I know than there is no checksum in eeprom (or it is not used).
Furthermore it is enough to change four bytes to enable 12, 13 and 14 channels:
priv->eeprom[0xdc] = 0x2b;
priv->eeprom[0xdd] = 0x0f;
priv->eeprom[0xde] = 0x2b;
priv->eeprom[0xdf] = 0x0f;
priv->eeprom[0xe0] = 0x2b;
priv->eeprom[0xe1] = 0x0f;
We can change it in eeprom and the card will work with these channels even after reboot.

I patched my eeprom and it works with 12, 13 and 14 channels.
I uploaded my patched dump here
Changed bytes:
eeprom[0xdc] = 0x2b; //was 00, 12ch
eeprom[0xdd] = 0x0f; //was 00, 12ch
eeprom[0xde] = 0x2b; //was 00, 13ch
eeprom[0xdf] = 0x0f; //was 00, 13ch
eeprom[0xe0] = 0x2b; //was 00, 14ch
eeprom[0xe1] = 0x0f; //was 00, 14ch
Also I changed device id (my card was for IBM laptops only), but it doesn't matter.

To sum up, eeprom structure in 3945 and newer cards differs from structure of 2200 eeprom. Also I did some reverse engineering on intel's cards and now I have method to change eeprom in driver (without soldering, like on 2200). But I can't public it here :)

brilliant work. i'll try it on the 3945.

on the 4965 the layout is a little different, will need further testing. The corresponding bytes to enable 12 - 14 channels are here. non patched file is here Attachment 2631

eeprom[0x174] = 0x2b; //was 00, 12ch
eeprom[0x175] = 0x0f; //was 00, 12ch
eeprom[0x176] = 0x2b; //was 00, 13ch
eeprom[0x177] = 0x0f; //was 00, 13ch
eeprom[0x178] = 0x2b; //was 00, 14ch
eeprom[0x179] = 0x0f; //was 00, 14ch