ipw3945 Wifi connection is very slow

[Markus Golser]

My Dell Inspiron 9400 Notebook has a Intel Corporation PRO/Wireless 3945ABG Network Card.

Connecting to my Wireless LAN is no problem.

But my connection is very very slow!

iwstat (downloading from lan)
 KB/s in KB/s out KB/s in KB/s out
    0.00 0.00 113.11 3.57
    0.00 0.00 111.70 4.30
    0.00 0.00 113.11 3.57

modinfo ipw3945
filename:
/lib/modules/2.6.20-13-generic/kernel/ubuntu/wireless/ipw3945/ipw3945.ko
license: GPL
version: 1.2.0mp

0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network
Connection (rev 02)
        Subsystem: Intel Corporation Unknown device 1021
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at ecfff000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [c8] Power Management version 2
        Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-
        Capabilities: [e0] Express Legacy Endpoint IRQ 0

eth1 IEEE 802.11g ESSID:"OpenWrt"
          Mode:Managed Frequency:2.427 GHz Access Point: 00:16:xx:19:xx:A2
          Bit Rate=11 Mb/s Tx-Power:15 dBm
          Retry limit:15 RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=71/100 Signal level=-64 dBm Noise level=-65 dBm
          Rx invalid nwid:0 Rx invalid crypt:14 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:18412 Missed beacon:0

eth1 Protokoll:Ethernet Hardware Adresse 00:19:D2:B0:08:83
          inet Adresse:192.168.1.34 Bcast:192.168.1.255 Maske:255.255.255.0
          inet6 Adresse: fe80::219:d2ff:feb0:883/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:133322 errors:15 dropped:18483 overruns:0 frame:0
          TX packets:102092 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:177937052 (169.6 MiB) TX bytes:10423688 (9.9 MiB)
          Interrupt:17 Basisadresse:0x2000 Speicher:ecfff000-ecffffff

[Markus Golser (golserma)]

There is already similar bug on the upstream bugtracker http://bughost.org/bugzilla/show_bug.cgi?id=1205

[Markus Golser (golserma)]

sudo iwpriv eth1 set_mode 4
temporarily fixes the problem for me

[chantra (chantra)]

I can confirm this bug too.
iwpriv eth1 set_mode 4
make my interface stick around 54Mb/s

[chantra (chantra)]

forgot to say:

laptop: acer aspire 9411 AWSMi
distro: ubuntu feisty
kernel 2.6.20-16-generic

 modinfo ipw3945
filename: /lib/modules/2.6.20-16-generic/kernel/ubuntu/wireless/ipw3945/ipw3945.ko
license: GPL
author: Copyright(c) 2003-2006 Intel Corporation
version: 1.2.0mp
description: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux
srcversion: 9B03103B15A8FE1824967C2
alias: pci:v00008086d00004227sv*sd*bc*sc*i*
alias: pci:v00008086d00004222sv*sd*bc*sc*i*
depends: ieee80211
vermagic: 2.6.20-16-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: associate:auto associate when scanning (default 0 off) (int)
parm: auto_create:auto create adhoc network (default 1 on) (int)
parm: led:enable led control (default 1 on)
 (int)
parm: channel:channel to limit associate to (default 0 [ANY]) (int)
parm: rtap_iface:create the rtap interface (1 - create, default 0) (int)
parm: mode:network mode (0=BSS,1=IBSS,2=Monitor) (int)

[mb (maxbloemer)]

Hello, i can confirm this too.

laptop:
- new DELL Inspiron 6400
- Intel PRO/Wireless 3945
- Intel Pentium Dual-Core CPU
- distro: ubuntu Feisty
- kernel 2.6.20-16-generic

windows: wlan working.

i don't think that the wlan-router (Vigor2500) because with other notebooks (intel wlan too, feisty too) i can connect without any problems.

ethernet is fully working.

reinstalling feisty did'n work. also live CD - same issue.

connecting with network-manager really a problem. also without WEP. Always i can see the aviable wireless networks (also mine) in the network-manager-applet (with great signal) but only in 1 of 12 cases i can connect. and then the connection is very very slow.

I tried manual configuration, without natwork-manager and with static IPs. Since then connecting is now Problem. But the connection is very very slow, too.

iwconfig eth1:
eth1 IEEE 802.11b ESSID:"Vigor2500"
          Mode:Managed Frequency:2.437 GHz Access Point: 00:90:4B:1A:6E:CC
          Bit Rate:11 Mb/s Tx-Power:15 dBm
          Retry limit:15 RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=66/100 Signal level=-68 dBm Noise level=-68 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:3051 Missed beacon:0

ipw3945:
filename: /lib/modules/2.6.20-16-generic/kernel/ubuntu/wireless/ipw3945/ipw3945.ko
license: GPL
author: Copyright(c) 2003-2006 Intel Corporation
version: 1.2.0mp
description: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux
srcversion: 9B03103B15A8FE1824967C2
alias: pci:v00008086d00004227sv*sd*bc*sc*i*
alias: pci:v00008086d00004222sv*sd*bc*sc*i*
depends: ieee80211
vermagic: 2.6.20-16-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: associate:auto associate when scanning (default 0 off) (int)
parm: auto_create:auto create adhoc network (default 1 on) (int)
parm: led:enable led control (default 1 on)
 (int)
parm: channel:channel to limit associate to (default 0 [ANY]) (int)
parm: rtap_iface:create the rtap interface (1 - create, default 0) (int)
parm: mode:network mode (0=BSS,1=IBSS,2=Monitor) (int)

"sudo iwpriv eth1 set_mode 4" does not work or change anysthing.

hoping for some help.

regards,
max

[Ketil Malde (ketil-ii)]

Me three.

Dell C620 with ipw3945, lots of packets dropped, note the "Invalid misc" and "RX dropped" in the information below. (Checks to see nobody is listening:) As things seem to be much better connecting to my neighbor's unprotected LAN (SpeedTouch ADSL with wireless, I think), I tried disabling WEP, but it doesn't help against my router (Billionton el-cheapo model).

There appears to be an abundance of people reporting similar problems, but the only "fix" I've seen so far is to replace the router and/or the wifi card.

  http://www.linuxquestions.org/questions/showthread.php?t=525300
  http://ubuntuforums.org/archive/index.php/t-506271.html
  http://osdir.com/ml/drivers.ipw3945.devel/2006-11/msg00025.html

Here's the relevant output. It seems pretty clear that "invalid misc" wifi packets in turn become RX dropped packets on the eth1 interface (closely correlated numbers). The enourmous packet drop rate means that web pages load extremely slowly, and often fail entirey. Other computers work against this router, and mine work against others (at least better than this), so my guess is some sort of incompatibility.

eth1 IEEE 802.11b ESSID:"TV4"
          Mode:Managed Frequency:2.467 GHz Access Point: 00:04:ED:01:34:18
          Bit Rate:11 Mb/s Tx-Power:15 dBm
          Retry limit:15 RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=84/100 Signal level=-50 dBm Noise level=-51 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:128018 Missed beacon:0

eth1 Link encap:Ethernet HWaddr 00:19:D2:6C:82:10
          inet addr:172.30.1.249 Bcast:172.30.255.255 Mask:255.255.0.0
          inet6 addr: fe80::219:d2ff:fe6c:8210/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:11526 errors:3523 dropped:131870 overruns:0 frame:0
          TX packets:11301 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:264255001 (252.0 MiB) TX bytes:32472518 (30.9 MiB)
          Interrupt:17 Base address:0x4000 Memory:ecfff000-ecffffff

[Mark Jeynes (mjeynes)]

I also experience this condition. I am fortunate enough to run 2 machines, bot running Ubuntu Feisty 7.04. One of them uses the Ath' driver, the other runs this ipw3945 one. The Ath' driver gets great performance ... showing

Link Quality=26/70 Signal level=-69 dBm Noise level=-95 dBm

The ipw3945 driver shows Signal and Noise both at -61dBm. It's slow. Unbearably slow.

The two machines sit side by side on the same desk. So please don't try convincing me there's an issue with my network. Please fix your bugs guys...

The same ipw3945 machine whrn running WindowsXP has no issues. So it's not my hardware either.

[mb (maxbloemer)]

I have this ipw3945 problem only with a Vigor 2500 WLAN Router. Other WLAN-routers are working. vista too. update of the routers firmware, restart, reconfigure didn't help.

[kcstrom (stutterheim)]

I have this same issue on a D620. This seems like a fairly serious issue to have been open for so long. Does anyone know if there is any development time going into fixing this issue?

The command sudo iwpriv eth1 set_mode 4 seems to temporarily help. Seems like that would be a decent foothold to beginning fixing this problem.

kcstrom

[mb (maxbloemer)]

i have a 802.11b wifi. but iwfriv eth1 set_mode 2 (2 for 11b) doesn't change anything. speed is still badly unusable. what am i doing wrong?

[Mark Jeynes (mjeynes)]

sudo iwpriv eth1 set_mode 4 did nothing to help me

[Chris Kälin (ck1)]

Confirmed on a Dell XPS M1710:

 iperf -c target -i5 -t30
------------------------------------------------------------
Client connecting to target TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.8 port 56104 connected with 192.168.1.6 port 5001
[ 3] 0.0- 5.0 sec 784 KBytes 1.28 Mbits/sec
[ 3] 5.0-10.0 sec 1.14 MBytes 1.91 Mbits/sec
[ 3] 10.0-15.0 sec 1.30 MBytes 2.19 Mbits/sec
[ 3] 15.0-20.0 sec 1.34 MBytes 2.25 Mbits/sec
[ 3] 0.0-24.7 sec 5.47 MBytes 1.86 Mbits/sec

and now with the workaround (sudo iwpriv eth1 set_mode 4):
iperf -c target -i5 -t30
------------------------------------------------------------
Client connecting to target TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.8 port 46670 connected with 192.168.1.7 port 5001
[ 3] 0.0- 5.0 sec 8.10 MBytes 13.6 Mbits/sec
[ 3] 5.0-10.0 sec 6.69 MBytes 11.2 Mbits/sec
[ 3] 10.0-15.0 sec 2.16 MBytes 3.62 Mbits/sec
[ 3] 15.0-20.0 sec 2.38 MBytes 4.00 Mbits/sec
[ 3] 20.0-25.0 sec 2.72 MBytes 4.56 Mbits/sec
[ 3] 25.0-30.0 sec 2.42 MBytes 4.06 Mbits/sec
[ 3] 0.0-30.1 sec 24.5 MBytes 6.81 Mbits/sec

Seems better. But what exactly does set_mode 4 do? Open the gates? ;-)

And does anybody know, how to confirm, if the firmware (which is located at /lib/firmware/2.6.20-16-386/iwlwifi-3945.ucode and ipw3945.ucode) is used by the kernel at all? There seems to be not hotplug mechanism for firmware active, but I might be wrong...

So far thanks for the workaround!

[mb (maxbloemer)]

> Seems better. But what exactly does set_mode 4 do? Open the gates? ;-)

  set_mode
 Can be used to configure which IEEE 802.11 mode the driver will
 support.

 Usage:
 % iwpriv eth1 set_mode {mode}
 Where {mode} is a number in the range 1-7:
 1 802.11a (ABG only)
 2 802.11b
 3 802.11ab (ABG only)
 4 802.11g
 5 802.11ag (ABG only)
 6 802.11bg
 7 802.11abg (ABG only)

look at: http://ipw3945.sourceforge.net/README.ipw3945

so set_mode 4 configures your 3945 wifi card to 802.11g Mode.

I have those speed-problems with a 802.11b-Only router. so i tried "set_mode 2". with no change in speed.

[chantra (chantra)]

Under gutsy, my card seems to be fine, network manager now reports 54M
here is my iwpriv output:
eth1 Available private ioctls :
          set_power (8BE0) : set 1 int & get 0
          get_power (8BE1) : set 0 & get 80 char
          set_mode (8BE2) : set 1 int & get 0
          get_mode (8BE3) : set 0 & get 80 char
          set_preamble (8BE4) : set 1 int & get 0
          get_preamble (8BE5) : set 0 & get 16 char
          reset (8BE7) : set 0 int & get 0
          monitor (8BE6) : set 2 int & get 0

----

http://www.debuntu.org

Debuntu deb's repository

Debuntu Debian and Ubuntu Tips and Tricks

[chantra (chantra)]

by the way, I forgot to mention:
 sudo iwpriv eth1 get_mode
eth1 get_mode:802.11abg (7)
this is default under gutsy.... or at least I can't remember of any
custom script setting setting my wireless interface.

>

----

http://www.debuntu.org

Debuntu deb's repository

Debuntu Debian and Ubuntu Tips and Tricks

[Ketil Malde (ketil-ii)]

Me too.

That is, I've now installed the Gutsy Beta for AMD64, and it seems to work. I'll let you know if/when it breaks, but so far, things look good. Also ran some updates etc, i.e. fairly heavy use.

 % ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:19:D2:6C:82:10
          inet addr:172.30.1.249 Bcast:172.30.255.255 Mask:255.255.0.0
          inet6 addr: fe80::219:d2ff:fe6c:8210/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:72479 errors:0 dropped:262 overruns:0 frame:0
          TX packets:42742 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:82671795 (78.8 MB) TX bytes:3444437 (3.2 MB)
          Interrupt:17 Base address:0x6000 Memory:ecfff000-ecffffff

(Compare the number of dropped packets to my previous report.)

[Ketil Malde (ketil-ii)]

I spoke too quickly - or there has been a regression in recent updates. It is back to the old behaviour with "invalid misc"s, and transfers that stall after some time.

[[e-mail] (schmud)]

iwpriv eth1 set_mode 4 does not fix this problem on my notebook: FuSi E8210

any new ideas?

[Markus Golser (golserma)]

Same problem on gutsy

[ski (skibrianski)]

I'm having this problem too.

ipw3945 is slow and unreliable to point of not being usable.

even ping is slow, and seems to be caught in some uninterruptable state as ^C doesn't kill it for a second or two. The odd thing is once a tcp connection is established, things seem more or less okay - for example, I can watch movies over sshfs just fine.

If I shell into a machine on my lan *over the wireless*, and ping normally, but while simultaneously pinging from my laptop, the difference in speed is stark. ganiodayo is my laptop, deskaheh is my desktop machine (both running gutsy amd64). note that, although the lateny reported from each packet isn't significantly different, the total elapsed time on the laptop is 4 times slower. I've tried with similar results on 2 other networks - same results.

ski@ganiodayo:/var/cache/apt/archives$ date ; ping -c 10 google.com ; date
Tue Nov 13 18:30:23 EST 2007
PING google.com (64.233.187.99) 56(84) bytes of data.
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=240 time=64.7 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=2 ttl=240 time=93.2 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=3 ttl=240 time=148 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=4 ttl=240 time=59.7 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=5 ttl=240 time=60.2 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=6 ttl=240 time=59.4 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=7 ttl=240 time=80.7 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=9 ttl=240 time=117 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=10 ttl=240 time=89.6 ms

--- google.com ping statistics ---
10 packets transmitted, 9 received, 10% packet loss, time 41975ms
rtt min/avg/max/mdev = 59.493/85.931/148.386/28.802 ms
Tue Nov 13 18:31:15 EST 2007

ski@deskaheh:~$ date ; ping -c 10 google.com ; date
Tue Nov 13 18:30:24 EST 2007
PING google.com (72.14.207.99) 56(84) bytes of data.
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=1 ttl=242 time=221 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=2 ttl=242 time=299 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=3 ttl=242 time=46.9 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=4 ttl=242 time=56.0 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=5 ttl=242 time=52.4 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=6 ttl=242 time=384 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=7 ttl=242 time=86.9 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=8 ttl=242 time=47.5 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=9 ttl=242 time=47.7 ms
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=10 ttl=242 time=52.4 ms

--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9003ms
rtt min/avg/max/mdev = 46.998/129.559/384.575/118.986 ms
Tue Nov 13 18:30:33 EST 2007

[ski (skibrianski)]

There seem to be two different bugs here. The one which is assigned upstream is related to changing physical location and network speed not returning to normal when one moves back to a higher speed location. This one also seems to be fixed by the iwpriv eth1 set_mode command.

The other one is related to latency and signal to noise ratios, and is not related to moving the laptop nor fixed by the iwpriv work around.

[ski (skibrianski)]

More information on the latency bug - it seems clear after more use that the issue is one of latency on each initial connection.

Each connection is fine once it is established but there is some 2-20 second delay in initiated the connection (or even getting a ping back).

For example, on a system connected physically to the ethernet:
ski@deskaheh:~$ time sudo ping -f -c 10 google.com
PING google.com (64.233.187.99) 56(84) bytes of data.

--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 119ms
rtt min/avg/max/mdev = 57.694/67.463/95.618/11.344 ms, pipe 6, ipg/ewma 13.309/67.140 ms

real 0m0.200s
user 0m0.000s
sys 0m0.004s

But on a system connected via ipw3945 (and affected by the bug):

ski@ganiodayo:~$ time sudo ping -f -c 10 google.com
PING google.com (72.14.207.99) 56(84) bytes of data.

--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 30423ms
rtt min/avg/max/mdev = 52.250/68.772/92.240/11.990 ms, pipe 6, ipg/ewma 3380.390/72.389 ms

real 0m55.716s
user 0m0.004s
sys 0m0.008s

What's more, ping cannot be interrupted via control-C on the affected system.

However, thruput is fine (circa 2.2MBps).

[ski (skibrianski)]

Ignore my comments - they are a different bug related to network manager.

[Brian Murray (brian-murray)]

I am assigning this bug to the 'ubuntu-kernel-team' per their bug policy. For future reference you can learn more about their bug policy at https://wiki.ubuntu.com/KernelTeamBugPolicies .

[[e-mail] (schmud)]

Here an addition. I'm not sure, if no one has tested this before, but it does not seem to be mentioned here.
The connection is not slow if I am not using WPA. Connecting via WEP to a Linksys 802.11bg Router / AP works fine. Connecting to a 802.11a unencrypted network is very fast, too.

Does anyone else notice this behaviour?

[Ketil Malde (ketil-ii)]

<email address hidden>: I think what you are describing is different from what I have - I only have problems when connecting to my 11b AP; 11g works fine. This seems to be unrelated to encryption, although I haven't tried WPA.

-k

[Richard Curley (rcurley)]

I agree with the problem being related to WPA. On a dual boot Windows XP Pro & Ubuntu Gutsy Dell Latitude D830 machine, using the Intel 3945, connecting to a Watchguard Firebox e10-w, I have no problems connecting with WPA on Windows, but get many dropped "ping" packets when in Ubuntu. For example, pinging my default gateway gives me:

root@linux-vr:/etc# ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1) 56(84) bytes of data.
64 bytes from 192.168.20.1: icmp_seq=1 ttl=64 time=1.63 ms
64 bytes from 192.168.20.1: icmp_seq=2 ttl=64 time=1.62 ms
64 bytes from 192.168.20.1: icmp_seq=3 ttl=64 time=1.60 ms
64 bytes from 192.168.20.1: icmp_seq=4 ttl=64 time=1.50 ms
64 bytes from 192.168.20.1: icmp_seq=5 ttl=64 time=1.75 ms
64 bytes from 192.168.20.1: icmp_seq=6 ttl=64 time=1.66 ms
64 bytes from 192.168.20.1: icmp_seq=7 ttl=64 time=1.36 ms
64 bytes from 192.168.20.1: icmp_seq=8 ttl=64 time=1.63 ms
64 bytes from 192.168.20.1: icmp_seq=9 ttl=64 time=2.14 ms
64 bytes from 192.168.20.1: icmp_seq=12 ttl=64 time=2.63 ms
--- 192.168.20.1 ping statistics ---
13 packets transmitted, 10 received, 23% packet loss, time 12001ms
rtt min/avg/max/mdev = 1.361/1.755/2.634/0.352 ms

If I turn WPA off, I get no dropped packets. I'm running kernel 2.6.22-14-generic, WPA_SUPPLICANT 0.60+0.58-0Ubuntu, and have set the mode using iwpriv set_mode to 4 and 2, (changing the Watchguard to match) as well as changing the power using "iwpriv set_power 1". I've configured the network with network manager and manually, with slightly better results setting manually, but still a 20%+ rate of dropped packets. My /etc/network/interfaces file is shown here:

root@linux-vr:/etc/network# more interfaces
auto lo
iface lo inet loopback

auto eth1
iface eth1 inet static
address 192.168.20.99
gateway 192.168.20.1
dns-nameservers 192.168.20.1
netmask 255.255.255.0
wpa-driver wext
wpa-ssid homer
wpa-ap-scan 1
wpa-proto WPA
wpa-pairwise TKIP
wpa-group TKIP
wpa-key-mgmt WPA-PSK
wpa-psk 8e46a434f28a43547d2f32836a6d9b2ec46c37b18470db3d8fc64bdc89692c74

I've tried WPA(1), WPA(2), both with TKIP and AES. All result in dropped packets of more than 20%. Again, this whole setup works fine when the system is booted into Windows, or if I'm not using any authentication or encryption. So, it appears to me that there is clearly a bug somewhere.

[Eric Clack (eric-bright-interactive)]

I also have a Dell Inspiron 6400 with Intel PRO/Wireless 3945ABG card and experience the issues above.

I wonder whether it's related to interference from other devices?

I have a BT cordless phone next to the wifi router and when the phone is off its base station wifi speeds are terrible (ping reports about 20% packet loss) but when the phone is on its base station speeds are much improved (ping reports about 1-2% packet loss). I've just noticed this today and am very relieved to have usable wifi again!

My Mac laptop doesn't seem to suffer from the same problems (and it's right next to my Dell laptop).

-Eric.

[Eric Clack (eric-bright-interactive)]

OK, spoke to soon. It's very slow again now and phones don't seem to make any difference.

[Marius Gedminas (mgedmin)]

I have this bug too.

Lenovo T61, gutsy, ipw3945 here, connected to a 802.11bg access point (Linksys WRT54GL running openwrt), no encryption. Normal throughput is over 1 megabyte per second (measured with the netspeed applet), signal/noise ratio is over +50 dB (according to wavemon). When I transfer a large file over the network, after several minutes the transfer speed drops to 100 kilobytes per second, s/n-r drops to +0/+1 dB. Asking network-manager to reconnect to the same WLAN fixes things temporarily (but some connections get dropped). The iwpriv workaround I discovered here fixes things too.

[Misha Koshelev (misha680)]

Btw I have this bug too. Mine is with gutsy amd64 on a Dell Latitude D630, connected to a 802.11bg access point with WPA. It is the same as the bug of the original poster though, the one about the connection being veeeery slow (works fine on XP on the same computer and on other computers) and having lots of dropped packets. It's very annoying - I can't really use wireless and the iwpriv command does not do anything.

As I believe someone posted above, there seem to be people with two different bugs on this one "bug report", both with the same # (mine is the same as the original posters I believe but the linked upstream bug is actually the other bug about losing speed after a while).

Thanks
Misha

[Paul Rensing (prensing)]

I am having somewhat similar problems with my wireless. I have an Lenovo X61 with a 3945 card. At home, I have two different wireless routers, both running 128-bit WEP encryption. I associate with one of them, but I almost never manager to get a DHCP address. When I do get a connection, it is extremely slow because of a large number of dropped or mangled packets. I can't seem to connect to the other router (not sure what that problem is). My wife's computers (two, running windows) generally have no problems.

[radsaq (radsaq)]

This is still a problem for me with Hardy's kernel.

[[e-mail] (schmud)]

for me, it seems to be only a problem in combination with my speedtouch Wifi ADSL Router. Using an other AP with the same WPA config is working without a problem.

[Misha Koshelev (misha680)]

<email address hidden> are you referring to hardy or gutsy? For me in gutsy it's a problem with WPA on my home Asus WL-500g Premium router running OpenWRT, and I don't really want to switch to WEP so basically it makes wireless unusable for this computer (works fine with my old Inspiron 600m though, different wifi card).

[[e-mail] (schmud)]

I'm still running Gusty. As I reported in December, it seems to be a problem with the combination of this Wifi Card with certain AP/Routers. I'm not sure anymore if this is an WPA issue at all. Unfortunately I cannot test my speedtouch with deactivated WPA.

[Ketil Malde (ketil-ii)]

Well - perhaps we are talking about two different problems, but I am not using WPA at all, so there is clearly a problem here that is independent of WPA. This occurs in 11b mode (or perhaps against 11b-only access points?), and the symptoms are lots of dropped packets (e.g. reported by 'ping', poor transfer rates, broken/locked up connections) labelled as "RX dropped" by ifconfig, and "Invalid misc" by iwconfig. Signal and Noise reported by iwconfig are always within 1dB of each other, but Link quality is reported as okay (e.g. 67/100), so I'm not sure if that is a problem or not.

Anyway I "solved it" by replacing my 11b AP with a new 11n one - which so far seems to work great. Another solution might be ndis-wrapper and the Windows 3945-driver -- it seems to work in that other OS against the same AP. Anyone care to try?

-k

[Alessio Igor Bogani (abogani)]

Hi Everyone,

An updated version of the iwlwifi drivers (version 1.2.25) was recently added to the linux-backports-modules-2.6.24 package:

https://bugs.edge.launchpad.net/ubuntu/+bug/200950/comments/30 .

It would be good if you could retest once lbm with the update is published and available. Thanks.

[Leann Ogasawara (leannogasawara)]

Hi All,

As Alessio pointed out, please test with the latest linux-backports-modules package in Hardy and let us know your results. You can see which version of the driver you are using by running "modinfo iwl3945" in a terminal.

I'm also removing the linux-source-2.6.24 task since beginning with the Hardy development cycle the kernel source package naming convention changed from 'linux-source-2.6.xx' to just 'linux'. This bug should be against linux-backports-modules/linux-ubuntu-modules anyways. Thanks.

[radsaq (radsaq)]

I'm using iwl3945 from the backports package and I'm currently stuck at 110kb/s despite high link quality. I don't see any sort of errors or dropped packets using iwconfig/ifconfig. Is there any useful debugging info I can give?

[Eric Clack (eric-bright-interactive)]

For me the problem is now solved :-)

I replaced my old, slow D-Link router with a new Net Gear one.
And I switched to the intel, open source drive, iwlwifi.

All is now working fine!

[Misha Koshelev (misha680)]

Eric, thanks a lot for your comment. I installed iwlwifi on my Gutsy installation, kept the same router and I am
able to connect fine wirelessly now !!! (yay man cables suck).

Only prob is I can't seem to connect to a hidden ssid with network manager, this seems a known problem in
Hardy but apparently not in Gutsy which is a little odd since I am running Gutsy...

Misha

[Jonne (jonathan-vanherpe)]

I've had this issue since edgy, and I just used the 'sudo iwpriv eth1 set_mode 7' thing every time I moved away from my AP. Unfortunately this doesn't work any more in Hardy. I still get limited at around 100KB/s sometimes, but when i run the command i get 'Invalid command : set_mode'.

I'm using the iwl3945 drivers now, so I'm not sure if this bug is limited to ipw3945. My laptop is a HP pavilion dv5285ea.

I'll try upgrading the firmware on my openwrt router to see if that fixes anything.

[Jonne (jonathan-vanherpe)]

Upgrading the firmware of my router didn't do anything (running whiterussian 0.9 now, I'm confused by the whole Kamikaze thing).

[Misha Koshelev (misha680)]

Well for me the bug was the "slow from the beginning iwpriv doesn't do anything" bug, so I think yours is a different bug. Mine was completely fixed by iwl3945 (btw I have always run Kamikaze on my router and this has not changed).

Misha

[Markus Golser (golserma)]

@Jonne is the router broadcom based?

[Jonne (jonathan-vanherpe)]

It's a WRT54G v2.2.
From the openwrt wiki:
The WRT54G v2.2 is based on the Broadcom 4712 board. It has a 200 MHz CPU, 4 MB flash and 16 MB DDR-SDRAM. The wireless NIC is integrated to the board. The switch is a BCM5325. Resetting to factory defaults via reset button or mtd erase nvram is safe on this unit.

So I guess that's a yes. I'm willing to try the Kamikaze firmware, but the download page doesn't exactly make it clear which one I should get or if it's even supported by my unit.

[Launchpad Janitor (janitor)]

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!

[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.

[Marius Gedminas (mgedmin)]

AFAIU beginning with Hardy the ipw3945 driver was replaced with the iwl3945 driver. I've occasionally experienced this problem in Gutsy, but never in Hardy.

[Leann Ogasawara (leannogasawara)]

Markus, since you are the original bug reporter, can you comment if this is still an issue for you with the latest Alpha5 release for Intrepid - http://www.ubuntu.com/testing/intrepid/alpha5 . You should be able to test with a LiveCD. Thanks.

[LumpyCustard (orangelumpycustard)]

I'm also using the iwl3945 driver. WPA was causing the problem, but WEP works at full speed.

Strange thing was that my M$ Win XP VM seemed to run at full speed when using NAT under WPA.

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Marc Jauvin (marc-r4l)]

I'm running Ubuntu Intrepid Ibex and this bug just resurfaced after the last kernel upgrade.

- The older kernel where this was working fine was: linux-image-2.6.27-9-generic
- Now running linux-image-2.6.27-11-generic and the problem reappeared.
- I have a Thinkpad T61 and am using driver iwl3945.

If I reboot in the previous kernel (which I kept), it works fine.

Thanks.

[Markus Golser (golserma)]

The mainline kernel 2.6.27-02062719-generic seems to fix this problem for me

[Markus Golser (golserma)]

Looks like the bug is fixed in the updated kernel package from smb_tp (2.6.27-14-generic)

[Stefan Bader (smb)]

Status for Intrepid is commited. Jauty is fixed (alpha6)

[Stefan Bader (smb)]

Reminder to check Hardy LBM for whether it makes sense to/is possible to backport the fix.

[Leann Ogasawara (leannogasawara)]

I've approved the Intrepid nomination. Launchpad unfortunately approves the nomination for all of the tasks/packages listed in this report, so I'll be cleaning up some of the tasks. Thanks.

[Stefan Bader (smb)]

I build a lbm package for Hardy including that fix I suspect to have solved the issue on Intrepid. The package is at http://people.ubuntu.com/~smb/bug103210/
if you could try to see whether this fixes Hardy as well, that would be awesome. Thanks.

[argonath (gleunda)]

I have the problem with the iwl3945 only when connect to Wireless network and WPA encryption, but WEP and open networks works great.

System :Ubuntu intrepid and linux 2.6.27-7.14

Thxs.

[Marc Jauvin (marc-r4l)]

Updating to kernel 2.6.27-14-generic fixes this for me on my Thinkpad T61.

Thanks!!!

[Stefan Bader (smb)]

This fix actually was already released but referenced bug #330902

[Stefan Bader (smb)]

Fix released through bug #330902

[[e-mail] (deheld999)]

Hey everybody, my laptop with wifi is very slow.
on windows have 14 mbs Internet speed.
on ubuntu have 3 mbs.

Help!

USB Wifi : Ralink RT73 USB WIRELESS LAN CARD