Linux - Wireless NetworkingThis forum is for the discussion of wireless networking in Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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 -
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...
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.
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.
Last edited by firefighter44x; 11-09-2009 at 09:20 PM.
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)
Would it be likely the `magic` command referenced here -
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.
Last edited by firefighter44x; 11-14-2009 at 04:12 PM.
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.
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.
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
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 4965.xxd.txt
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.