LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking > Linux - Wireless Networking
User Name
Password
Linux - Wireless Networking This forum is for the discussion of wireless networking in Linux.

Notices


Reply
  Search this Thread
Old 08-01-2009, 08:33 AM   #1
Tic
LQ Newbie
 
Registered: Aug 2009
Posts: 5

Rep: Reputation: Disabled
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
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 08-03-2009, 08:45 PM   #2
Tic
LQ Newbie
 
Registered: Aug 2009
Posts: 5

Original Poster
Rep: Reputation: Disabled
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?
 
Old 08-04-2009, 07:19 AM   #3
scheidel21
Senior Member
 
Registered: Feb 2003
Location: CT
Distribution: Debian PPC/i386/AMD64 6/7, Vista, XP , WIN7, Server 03/08
Posts: 1,289

Rep: Reputation: 97
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.
 
Old 11-09-2009, 09:04 PM   #4
firefighter44x
LQ Newbie
 
Registered: Nov 2009
Posts: 10

Rep: Reputation: 0
Angry

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.

Last edited by firefighter44x; 11-09-2009 at 09:20 PM.
 
Old 11-10-2009, 12:58 AM   #5
Tic
LQ Newbie
 
Registered: Aug 2009
Posts: 5

Original Poster
Rep: Reputation: Disabled
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 -

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?
 
Old 11-13-2009, 05:53 AM   #6
firefighter44x
LQ Newbie
 
Registered: Nov 2009
Posts: 10

Rep: Reputation: 0
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.
 
Old 01-12-2010, 05:15 PM   #7
firefighter44x
LQ Newbie
 
Registered: Nov 2009
Posts: 10

Rep: Reputation: 0
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.
 
Old 01-13-2010, 08:03 AM   #8
Tic
LQ Newbie
 
Registered: Aug 2009
Posts: 5

Original Poster
Rep: Reputation: Disabled
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.
 
Old 01-18-2010, 07:14 PM   #9
ittrium
LQ Newbie
 
Registered: Jan 2010
Posts: 5

Rep: Reputation: 2
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.

Last edited by ittrium; 01-18-2010 at 07:17 PM.
 
Old 01-21-2010, 05:48 AM   #10
firefighter44x
LQ Newbie
 
Registered: Nov 2009
Posts: 10

Rep: Reputation: 0
sounds good, see attached. (created with xxd) use xxd -r to create actual content.dump.txt dump1.txt
 
Old 01-22-2010, 12:00 PM   #11
ittrium
LQ Newbie
 
Registered: Jan 2010
Posts: 5

Rep: Reputation: 2
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?

Last edited by ittrium; 01-22-2010 at 01:31 PM.
 
Old 01-28-2010, 01:50 AM   #12
firefighter44x
LQ Newbie
 
Registered: Nov 2009
Posts: 10

Rep: Reputation: 0
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.
 
Old 01-30-2010, 04:41 AM   #13
ittrium
LQ Newbie
 
Registered: Jan 2010
Posts: 5

Rep: Reputation: 2
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.

Last edited by ittrium; 01-30-2010 at 07:13 AM.
 
Old 01-30-2010, 07:55 AM   #14
ittrium
LQ Newbie
 
Registered: Jan 2010
Posts: 5

Rep: Reputation: 2
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
 
2 members found this post helpful.
Old 02-02-2010, 05:39 PM   #15
firefighter44x
LQ Newbie
 
Registered: Nov 2009
Posts: 10

Rep: Reputation: 0
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 4965.xxd.txt

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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Intel Pro Wireless 3945ABG Debian Help jaredhocutt Linux - Newbie 7 01-24-2010 10:22 PM
Intel PRO Wireless 3945ABG: Help! LDJ Linux - Newbie 13 09-21-2007 05:21 AM
Fedora 7 + intel PRO/Wireless 3945ABG :( adam_blackice Linux - Wireless Networking 9 08-13-2007 11:48 AM
Fedora 7 and Intel Pro 3945abg moosport Linux - Networking 0 08-09-2007 02:01 AM
Problem - Intel Intel(R) PRO/Wireless 3945ABG suresheva31 Fedora 2 09-18-2006 07:45 PM


All times are GMT -5. The time now is 06:16 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration