Bugzilla – Bug 1873
IBSS Cell can be established but can't work, lose more than 50% ping packets and scp can't work either
Last modified: 2009-01-20 20:17:10
You need to log in before you can comment on or make changes to this bug.
Testing Environment Platform : Intel SDV M3X15 and IBM-60(Fedora release 9) Wireless Card : Intel(R) WiFi Link 3945 OS : Redhat Fedora release 10 (Cambridge) 32bit uCode : iwlwifi-3945-2.ucode 15.28.2.8 Source : commit 2f71382adc117aba10b04e92a464f4404c08aa70 Peer : Intel SDV M3M31 Issue IBSS Cell can be established but can't work, lose more than 50% ping packets and scp can't work either Steps to Reproduce: 1. reload driver 2. iwconfig wlan0 mode ad-hoc 3. ifconfig wlan0 up 4. iwconfig wlan0 channel <CHAN> essid <ESSID> 5. ifconfig wlan0 <IP_ADDR> 6. iwconfig wlan0 ----> verify established IBSS Cell wlan0 IEEE 802.11abg ESSID:"my-adhoc" Mode:Ad-Hoc Frequency:2.452 GHz Cell: 7A:C5:34:84:61:DA Tx-Power=12 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 7. ping <IP_ADDR_SRV> ----> more than lose 50% ping packets ping 192.168.50.154 PING 192.168.50.154 (192.168.50.154) 56(84) bytes of data. From 192.168.50.160 icmp_seq=2 Destination Host Unreachable From 192.168.50.160 icmp_seq=3 Destination Host Unreachable From 192.168.50.160 icmp_seq=4 Destination Host Unreachable From 192.168.50.160 icmp_seq=7 Destination Host Unreachable From 192.168.50.160 icmp_seq=8 Destination Host Unreachable From 192.168.50.160 icmp_seq=9 Destination Host Unreachable From 192.168.50.160 icmp_seq=10 Destination Host Unreachable From 192.168.50.160 icmp_seq=11 Destination Host Unreachable 64 bytes from 192.168.50.154: icmp_seq=17 ttl=64 time=3.74 ms 64 bytes from 192.168.50.154: icmp_seq=20 ttl=64 time=3.71 ms 64 bytes from 192.168.50.154: icmp_seq=24 ttl=64 time=175 ms 64 bytes from 192.168.50.154: icmp_seq=26 ttl=64 time=17.5 ms 64 bytes from 192.168.50.154: icmp_seq=27 ttl=64 time=4.03 ms 64 bytes from 192.168.50.154: icmp_seq=29 ttl=64 time=4.05 ms 64 bytes from 192.168.50.154: icmp_seq=30 ttl=64 time=4.24 ms 64 bytes from 192.168.50.154: icmp_seq=36 ttl=64 time=3.71 ms 64 bytes from 192.168.50.154: icmp_seq=38 ttl=64 time=95.0 ms 64 bytes from 192.168.50.154: icmp_seq=43 ttl=64 time=3.85 ms 64 bytes from 192.168.50.154: icmp_seq=48 ttl=64 time=126 ms ^C --- 192.168.50.154 ping statistics --- 49 packets transmitted, 11 received, +8 errors, 77% packet loss, time 48777ms rtt min/avg/max/mdev = 3.710/40.166/175.001/59.109 ms, pipe 3 8. scp FILE to PEER_MACHINE ----> can't work 9. peer machine repeated step1 ~ step8 sometimes dmesg log shows "MAC is in deep sleep!" wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: no IPv6 routers present wlan0: deauthenticating by local choice (reason=3) iwl3945 0000:03:00.0: MAC is in deep sleep! iwl3945 0000:03:00.0: MAC is in deep sleep! iwl3945 0000:03:00.0: MAC is in deep sleep! iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1 .2.26kds We rolled back to commit 9378420a3f8da4acf0a12960dc6a7f531ceb0492, IBSS mode work well.
Same in commit e98df74b724417607e039a4e0b28ad230e5e9b96. ping packets lost and scp 5MB file failed in all 5 IBSS cases
Created an attachment (id=1775) [details] iwl3945_init_drv() fix
Hi Jeff, Ximin, Could you guys give the attached patch a try ? It seems to work for me at least. Thanks in advance.
This issue still exists in both applying the patch, or using the latest code.
(In reply to comment #4) > This issue still exists in both applying the patch, or using the latest code. I tried again today, the attached patch applied on top of 25147c5006ac3f1bdaffe2f891789aa03f1d8a1f, and I can ping the other IBSS end, and scp 20 Mbytes there without a glitch. Without my patch, I see the exact same issues you're describing on this bug. Also, applying this patch on top of 2f71382adc117aba10b04e92a464f4404c08aa70 also works for me. Are you sure you applied the patch correctly ?
Yes. I tried both (apply patch, or with the latest tree). I just make wireless modules and copy these modules to /lib/modules/<kernel>/... You can check it in ipw-np1 if you have time.
I tried on 3 version: 1. commit e98df74b724417607e039a4e0b28ad230e5e9b96, it's 2.6.28-rc9 2. official 2.6.28 kernel 3. latest iwlwifi-2.6 (commit 4bc02d2f9b2d6962f123a78a93665c4875562899) latest iwlwifi-2.6 works great. 0% packet lost for ping. official 2.6.28 lost packets, though not very heavily. It's easy to reproduce when there are severl machines in the ad-hoc network. 2.6.28-rc9 is worst, ping packs lost > 50%, and scp generally stalled. Anyway, latest iwlwifi-2.6 tree works, so you can mark it as "fixed"
(In reply to comment #7) > I tried on 3 version: > > 1. commit e98df74b724417607e039a4e0b28ad230e5e9b96, it's 2.6.28-rc9 > 2. official 2.6.28 kernel > 3. latest iwlwifi-2.6 (commit 4bc02d2f9b2d6962f123a78a93665c4875562899) > > latest iwlwifi-2.6 works great. 0% packet lost for ping. Awesome, thanks. > official 2.6.28 lost packets, though not very heavily. Yes, official 2.6.28 doesnt contain the latest 3945 changes. > Anyway, latest iwlwifi-2.6 tree works, so you can mark it as "fixed" Thanks for testing. Will mark as fixed.
Also fixed in 2.6.29-rc1