iwl3945 sometimes does not detect ESSIDs, whereas ipw3945 works perfectly

[Martin Pitt]

0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

With the ipw3945 module in the .22 kernel I had great reception, signal strength, and a stable connection. My Wifi here is pretty weak, since it needs to go through 3 walls and the sender is across the street (my shoe string internet), but it worked just fine with ipw3945 (Quality=38/100 Signal level=-86 dBm Noise level=-86 dBm). On my previous laptop with a bcm43xx it also worked.

Now, with iwl3945 it does not even detect the essid reliably. When I poll "iwlist scanning" I occasionally see it for a second, then it disappears again. I never see it in n-m.

Maybe the replacement for the non-free HAL is too conservative about signal strenght?

Any chance we could ship ipw3945 as an alternative until iwl3945 gets better?

[Andrea Colangelo (warp10)]

Signal strenght is above 85/100 with ipw3945, drops to 55 to 60/100 with iwl3945. Not enough to get connection troubles, but enough to confirm this bug.

[Martin Pitt (pitti)]

Right, I noticed that, too, with other WLANs that are around me (I cannot connect to them, but the overall signal strength is much lower when using iwl3945).

[Martin Pitt (pitti)]

This is actually an upstream bug. Ideally signal strength/reception quality of iwl3945 would match ipw3945's.

[Christian (christian-pluym)]

The iwl3945 driver version in hardy is 1.1.17 from September 2007, meanwhile there is 1.2.23, I manually installed this newest version from

http://intellinuxwireless.org/

and it works fine.

Please update iwlwifi and mac80211.

[Joakim Andersson (jocke)]

I did a little investigation about this with gutsy's drivers. It seems to me that the signal level (reported by iwconfig) is the same with both drivers, but the noise level is significantly different (iwl reports about twice the amount that ipw reports). Standing right next to my AP, ipw gives me up to 99% link quality, while iwl only got up to about 89%.

After upgrading to hardy's current kernel (using instructions from http://ubuntuforums.org/showthread.php?t=646755), iwl3945 now reports the same quality as ipw (at least similar, hardy's kernel doesn't contain ipw3945, so I can't compare them). The signal and noise levels are still about the same as with gutsy's version, so I guess only the quality calculation changed. Anyway, this should be marked as fixed in hardy.

[Martin Pitt (pitti)]

Jocke,

no, it should not be marked as fixed. The problem occurs in hardy current. Regardless of which levels iwconfig report, I don't get any signal with iwl whereas ipw works perfectly (my AP is about 60 m away through two walls, so it's quite weak).

Also, at least network-manager does report much weaker signal strenghts with iwl, so I think that's correct, too.

I'll try the new version from upstream now.

[Martin Pitt (pitti)]

Unfortunately the latest iwl3945 from upstream does not build against the current hardy kernel, it also needs the newer mac80211. The latter can apparently only be built in conjunction with a full kernel patching/rebuilding.

Thus it's not easy to try out the new module. I guess I'll wait until the kernel folks update it in the tree.

[Joakim Andersson (jocke)]

Martin,

So there is apparently a difference between running hardy's current kernel in gutsy and running hardy current. As I said, iwl3945 worked flawlessly for me with hardy's kernel in gutsy...

[Joakim Andersson (jocke)]

I managed to get the latest upstream version (1.2.23) running in gutsy (with gutsy's latest stock kernel) by compiling my own linux-ubuntu-modules package, but the problem was still there. Now I'm confused.

[Martin Pitt (pitti)]

With 2.6.24-4 I don't have that problem any more, works well now. Thank you!

[Ricardo Teixeira (ricardo-ctrler)]

This still happens to me with kernel 2.6.24-11 in hardy.

[Martin Pitt (pitti)]

For me, signal strenght is consistently ok now. It just takes several "sudo iwlist scanning" calls until the ESSID is actually detected and used.

[czk (czk19790827)]

I cannot use iwl3945 to connect an ap far away. even it can hardly be discovered.
when i boot with a feisty cd, using ipw3945, it works fine. signal strength shows about 40/100.
the problem not fixed yet.

[Ricardo Teixeira (ricardo-ctrler)]

I can confirm that the problem has not been fixed. Using 2.6.24.16 I still have this problem. And scanning doesn't work reliable either, I have to do several scans before the network appears.

[Ricardo Teixeira (ricardo-ctrler)]

Hi. I'm having the same problem as you, have you found a solution?

Thanks.

On Sun, Mar 23, 2008 at 4:54 AM, czk <email address hidden> wrote:

> I cannot use iwl3945 to connect an ap far away. even it can hardly be
> discovered.
> when i boot with a feisty cd, using ipw3945, it works fine. signal
> strength shows about 40/100.
> the problem not fixed yet.
>
> --
> iwl3945 has very poor signal reception, whereas ipw3945 works perfectly
> https://bugs.launchpad.net/bugs/177624
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Intel Linux Wireless project upstream project presentation in
> launchpad.: Fix Released
> Status in Source Package "linux" in Ubuntu: Fix Released
>
> Bug description:
> 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network
> Connection (rev 02)
>
> With the ipw3945 module in the .22 kernel I had great reception, signal
> strength, and a stable connection. My Wifi here is pretty weak, since it
> needs to go through 3 walls and the sender is across the street (my shoe
> string internet), but it worked just fine with ipw3945 (Quality=38/100
> Signal level=-86 dBm Noise level=-86 dBm). On my previous laptop with a
> bcm43xx it also worked.
>
> Now, with iwl3945 it does not even detect the essid reliably. When I poll
> "iwlist scanning" I occasionally see it for a second, then it disappears
> again. I never see it in n-m.
>
> Maybe the replacement for the non-free HAL is too conservative about
> signal strenght?
>
> Any chance we could ship ipw3945 as an alternative until iwl3945 gets
> better?
>

[Martin Pitt (pitti)]

I confirm that I still have some difficulties detecting my home's wifi. Most of the times it works now, often it needs some "sudo iwlist scanning" poking, but in about 1 out of 5 cases it refuses to detect the wifi at all; then I need to reboot or hibernate/resume.

[Karel Demeyer (kmdemeye)]

I have the same problem on a freshly installed hardy install (kernel 2.6.24-16). A lot of times wireless networks just don't show up in NM's list while I'm in range. This didn't happen in gutsy with the ipw driver.

[Marek (pawinski)]

I have to run "ifdown wlan0" and then "ifup wlan0" every time i boot up, and sometimes my connections dies and i have to run the commands again.

[Pepa Lechner (josef.lechner)]

The same problem. Several times I thought, something fix this problem (wicd, fixed channel on the router, disable_hw_scan=1) but nothing worked good for a long time... During authentization I MUST go near the router, catch a signal and after connection is set I can go back. Signal quality is 50/100.

[[e-mail] (thsoret)]

With my laptop HP DV 6000, Signal quality Wifi + ipw3945 (ubuntu 7.10) is perfect but with iwl3945 (ubuntu 8.04) no signal essid, no wifi.

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Dirk Theis (revilooooo)]

This bug is also discussed as Bug 247181 ``WiFi Problems'', and mentioned in Bug 217653 (iwl3945) ``Wireless connection to WPA Enterprise network fails using Intel iwl3945 driver''.

I have the same problem by the way: with all previous versions of Ubuntu + ipw3945 I had the same connection quality as with Windoze; the moment I updated to Hardy + iwl, it became _a_lot_ worse.

[Dimitrios Symeonidis (azimout)]

dirk, which version of iwl do you have? you can see that by typing "modinfo iwl3945". you should have 1.2.26ks

also, can you tell us the exact model of your hardware chip? you can find that through "lspci -nn". you should have 8086:4222

[Lutfi (lutfiarab)]

Last Intrepid still not success. Only 1 access point detected. Other 2 access point still no detected. But XP can see all access point.

lutfi@djin:~$ uname -a
Linux djin 2.6.27-3-generic #1 SMP Wed Sep 10 16:02:00 UTC 2008 i686 GNU/Linux

root@djin:~# lspci -nn|grep 3945
02:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG Network Connection [8086:4222] (rev 02)

lutfi@djin:~$ dmesg |grep iwl3945
[ 25.904247] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26ks
[ 25.904256] iwl3945: Copyright(c) 2003-2008 Intel Corporation
[ 25.904414] iwl3945 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 25.904435] iwl3945 0000:02:00.0: setting latency timer to 64
[ 25.904467] iwl3945: Detected Intel Wireless WiFi Link 3945ABG

lutfi@djin:~$ modinfo iwl3945
filename: /lib/modules/2.6.27-3-generic/kernel/drivers/net/wireless/iwlwifi/iwl3945.ko
license: GPL
author: Copyright(c) 2003-2008 Intel Corporation
version: 1.2.26ks
description: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux
srcversion: 5C079549ABD48E07B20F3C7
alias: pci:v00008086d00004227sv*sd*bc*sc*i*
alias: pci:v00008086d00004222sv*sd*bc*sc*i*
alias: pci:v00008086d00004227sv*sd00001014bc*sc*i*
alias: pci:v00008086d00004222sv*sd00001044bc*sc*i*
alias: pci:v00008086d00004222sv*sd00001034bc*sc*i*
alias: pci:v00008086d00004222sv*sd00001005bc*sc*i*
depends: mac80211,led-class,cfg80211,rfkill
vermagic: 2.6.27-3-generic SMP mod_unload modversions 586
parm: antenna:select antenna (1=Main, 2=Aux, default 0 [both]) (int)
parm: disable:manually disable the radio (default 0 [radio on]) (int)
parm: hwcrypto:using hardware crypto engine (default 0 [software])
 (int)
parm: debug:debug output mask (int)
parm: disable_hw_scan:disable hardware scanning (default 0) (int)
parm: queues_num:number of hw queues. (int)
parm: qos_enable:enable all QoS functionality (int)

root@djin:~# iwconfig eth1
eth1 IEEE 802.11abg ESSID:"private_line!!!!"
          Mode:Managed Frequency:2.417 GHz Access Point: Not-Associated
          Tx-Power=15 dBm
          Retry min limit:7 RTS thr:off Fragment thr=2352 B
          Encryption key:off
          Power Management:off
          Link Quality:0 Signal level:0 Noise level:0
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

root@djin:~# iwlist eth1 scanning
eth1 Scan completed :
          Cell 01 - Address: 00:1E:E5:96:D2:F0
                    ESSID:"private_line!!!!"
                    Mode:Master
                    Channel:2
                    Frequency:2.417 GHz (Channel 2)
                    Quality=52/100 Signal level:-77 dBm Noise level=-127 dBm
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 22 Mb/s
                              6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
                              36 Mb/s; 48 Mb/s; 54 Mb/s
              ...

[Dirk Theis (revilooooo)]

Hello Dimitrios,

Your answer was probably already answered by the previous poster, anyway, here's the data.
(I've installed all available updates.)

$$ modinfo iwl3945
filename: /lib/modules/2.6.24-21-generic/ubuntu/wireless/iwlwifi/iwlwifi/compatible/iwl3945.ko
license: GPL
author: Copyright(c) 2003-2007 Intel Corporation
version: 1.2.0
description: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux
srcversion: 8E95C617988943846696F97
alias: pci:v00008086d00004227sv*sd*bc*sc*i*
alias: pci:v00008086d00004222sv*sd*bc*sc*i*
depends: iwlwifi_mac80211
vermagic: 2.6.24-21-generic SMP mod_unload 586
parm: antenna:select antenna (1=Main, 2=Aux, default 0 [both]) (int)
parm: disable:manually disable the radio (default 0 [radio on]) (int)
parm: hwcrypto:using hardware crypto engine (default 0 [software])
 (int)
parm: debug:debug output mask (int)
parm: disable_hw_scan:disable hardware scanning (default 0) (int)
parm: queues_num:number of hw queues. (int)
parm: qos_enable:enable all QoS functionality (int)

$$ lspci -nn | grep etwork
03:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG Network Connection [8086:4227] (rev 02)

[Dimitrios Symeonidis (azimout)]

Dirk, it seems you have a slightly different version of the 3945: I have the 8086:4222 (just like Lutfi above), while you have 8086:4227. I don't know exactly what this means.

One thing is for sure: some people have this problem, and some don't. I can assure you that I see multiple access points on mine, with iwl3945 version 1.2.26ks (I'm running a custom kernel 2.6.26.5).

I suggest using UNetBootin to create LiveUSBs of Ubuntu 7.10, 8.04 and 8.10 and verify the problem...

[Dirk Theis (revilooooo)]

I surmise that it's not the * in 8086:422* that makes the difference: there's too many people who have the problem.

By the way: here's another one reporting the same weak signals with iwl as compared to ipw:
http://ubuntuforums.org/archive/index.php/t-770465.html
and google finds more reports.

[Dimitrios Symeonidis (azimout)]

Here's what I found in the kernel source's iwl3945-base.c file:

/* Convert linear signal-to-noise ratio into dB */
static u8 ratio2dB[100] = {
/* 0 1 2 3 4 5 6 7 8 9 */
  0, 0, 6, 10, 12, 14, 16, 17, 18, 19, /* 00 - 09 */
 20, 21, 22, 22, 23, 23, 24, 25, 26, 26, /* 10 - 19 */
 26, 26, 26, 27, 27, 28, 28, 28, 29, 29, /* 20 - 29 */
 29, 30, 30, 30, 31, 31, 31, 31, 32, 32, /* 30 - 39 */
 32, 32, 32, 33, 33, 33, 33, 33, 34, 34, /* 40 - 49 */
 34, 34, 34, 34, 35, 35, 35, 35, 35, 35, /* 50 - 59 */
 36, 36, 36, 36, 36, 36, 36, 37, 37, 37, /* 60 - 69 */
 37, 37, 37, 37, 37, 38, 38, 38, 38, 38, /* 70 - 79 */
 38, 38, 38, 38, 38, 39, 39, 39, 39, 39, /* 80 - 89 */
 39, 39, 39, 39, 39, 40, 40, 40, 40, 40 /* 90 - 99 */
};

/* Calculates a relative dB value from a ratio of linear
 * (i.e. not dB) signal levels.
 * Conversion assumes that levels are voltages (20*log), not powers (10*log). */
int iwl3945_calc_db_from_ratio(int sig_ratio)
{
 /* 1000:1 or higher just report as 60 dB */
 if (sig_ratio >= 1000)
  return 60;

 /* 100:1 or higher, divide by 10 and use table,
  * add 20 dB to make up for divide by 10 */
 if (sig_ratio >= 100)
  return (20 + (int)ratio2dB[sig_ratio/10]);

 /* We shouldn't see this */
 if (sig_ratio < 1)
  return 0;

 /* Use table for ratios 1:1 - 99:1 */
 return (int)ratio2dB[sig_ratio];
}

#define PERFECT_RSSI (-20) /* dBm */
#define WORST_RSSI (-95) /* dBm */
#define RSSI_RANGE (PERFECT_RSSI - WORST_RSSI)

/* Calculate an indication of rx signal quality (a percentage, not dBm!).
 * See http://www.ces.clemson.edu/linux/signal_quality.shtml for info
 * about formulas used below. */
int iwl3945_calc_sig_qual(int rssi_dbm, int noise_dbm)
{
 int sig_qual;
 int degradation = PERFECT_RSSI - rssi_dbm;

 /* If we get a noise measurement, use signal-to-noise ratio (SNR)
  * as indicator; formula is (signal dbm - noise dbm).
  * SNR at or above 40 is a great signal (100%).
  * Below that, scale to fit SNR of 0 - 40 dB within 0 - 100% indicator.
  * Weakest usable signal is usually 10 - 15 dB SNR. */
 if (noise_dbm) {
  if (rssi_dbm - noise_dbm >= 40)
   return 100;
  else if (rssi_dbm < noise_dbm)
   return 0;
  sig_qual = ((rssi_dbm - noise_dbm) * 5) / 2;

 /* Else use just the signal level.
  * This formula is a least squares fit of data points collected and
  * compared with a reference system that had a percentage (%) display
  * for signal quality. */
 } else
  sig_qual = (100 * (RSSI_RANGE * RSSI_RANGE) - degradation *
       (15 * RSSI_RANGE + 62 * degradation)) /
      (RSSI_RANGE * RSSI_RANGE);

 if (sig_qual > 100)
  sig_qual = 100;
 else if (sig_qual < 1)
  sig_qual = 0;

 return sig_qual;
}

[Dirk Theis (revilooooo)]

Here are 3 questions about your posts, Dimitrios:

* Could you explain why you think these functions are of interest?

* Do these functions compute the signal quality values which can be displayed, e.g., with nm-tools?

* Do the computed values affect the actual ability to receive or transmit, or are they just being displayed and used for deciding whether to attempt to connect to a network?

The significance of the last question is, of course, that the connection itself is bad, not (just) the signal quality numbers. If you compute the numbers using a different formula, you'd possibly get something different, while the actual connection quality doesn't change, of course. Again: the connection itself is unreliable, it's not a matter of numbers.

Here's an idea: Even with 2.6.22+ipw the connection quality is slightly worse when on battery power (though still far better than 2.6.44+iwl). Could this be a power management issue?

-Dirk

P.S.: Currently, the way I use WiFi is to boot using the 2.6.22 kernel in the grub menu (I get 100 error messages, but it seems to work ok). This version still has ipw support, I modprobe ipw, and the connectivity is good.

With 2.6.24+iwl, my tiny iPod has more reliable WiFi connection than my linux pc.

[Dimitrios Symeonidis (azimout)]

Dirk, the issue here is signal strength and iwl sometimes not detecting ESSIDs, not connection quality.

Maybe someone should try compiling the ipw for 2.6.24 and report the results. Maybe also we should try to compile iwl for 2.6.22 and test.

[Lutfi (lutfiarab)]

On Thu, Oct 2, 2008 at 4:37 PM, Dimitrios Symeonidis <email address hidden> wrote:
> Dirk, the issue here is signal strength and iwl sometimes not detecting
> ESSIDs, not connection quality.
>
> Maybe someone should try compiling the ipw for 2.6.24 and report the
> results. Maybe also we should try to compile iwl for 2.6.22 and test.
>
> --
> iwl3945 sometimes does not detect ESSIDs, whereas ipw3945 works perfectly
> https://bugs.launchpad.net/bugs/177624
> You received this bug notification because you are a direct subscriber
> of the bug.
>

The last kernel on 8.10 (devel) still not good

[Dirk Theis (revilooooo)]

Hello Dimitrios,
Well, I said ``connection quality'' to distinguish this from the signal strength *numbers*.
I don't think it's the numbers. It's what the WiFi driver can make out of the physical signal that's ``in the air''. What are the symptoms:

* It is more difficult to connect to networks,
* When there is a connection it's more vulnerable
   to fluctuations of the physical signal (e.g., connection
   breaks off)
* when there is a connection, the speed is lower, more
   packages get lost.

If it is the numbers, then someone should just change the functions above in the kernel, make them return higher values, and see what happens....!

Cheers,
D