[Bug 192950] [iwn] Centrino Advanced-N 6205 slow on 11n, better on 11g
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192950 --- Comment #23 from dieterich@gmail.com --- (In reply to Hiren Panchasara from comment #22) (In reply to dieterich.joh from comment #21) (In reply to Adrian Chadd from comment #17) Also, please test out with the latest -HEAD and see if it behaves better for you. Just installed r271215 and can confirm that the situation is much improved. Without setting -ht, I can get some 3.5 MB/s upload over scp to off-site. I can run more detailed tests if you wish, but I am more than happy with the status as is. Are you connecting at 11g? Can you paste ifconfig o/p? It'd be nice to see what rate does it go up to? (with wlandebug +rate) No, this should be 11n (on the 2.4 GHz band and w/ only 20 MHz channel width, though) as I explicitly configured the access point to not support anything but 11n. ifconfig: wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether XX inet 192.168.1.3 netmask 0xff00 broadcast 192.168.1.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet MCS mode 11ng status: associated ssid XX channel 10 (2457 MHz 11g ht/20) bssid XXX country US authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 15 bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 64 protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi wme roaming MANUAL wlandebug + rate: Sep 7 13:51:54 kernel: wlan0: [] AMRR: current rate 15, txcnt=36, retrycnt=11 Sep 7 13:51:54 kernel: wlan0: [] AMRR: current rate 15, txcnt=37, retrycnt=2 Sep 7 13:51:55 kernel: wlan0: [] AMRR: current rate 15, txcnt=37, retrycnt=6 Sep 7 13:51:55 kernel: wlan0: [] AMRR: current rate 15, txcnt=34, retrycnt=1 Sep 7 13:51:56 kernel: wlan0: [] AMRR: current rate 15, txcnt=38, retrycnt=8 Sep 7 13:51:56 kernel: wlan0: [] AMRR: current rate 15, txcnt=33, retrycnt=2 Sep 7 13:51:57 kernel: wlan0: [] AMRR: current rate 15, txcnt=39, retrycnt=5 Sep 7 13:51:57 kernel: wlan0: [] AMRR: current rate 15, txcnt=33, retrycnt=10 Sep 7 13:51:58 kernel: wlan0: [] AMRR: current rate 15, txcnt=38, retrycnt=20 Sep 7 13:51:58 kernel: wlan0: [] AMRR decreasing rate 14 (txcnt=38 retrycnt=20) Sep 7 13:51:58 kernel: wlan0: [] AMRR: current rate 14, txcnt=38, retrycnt=5 Sep 7 13:51:59 kernel: wlan0: [] AMRR: current rate 14, txcnt=35, retrycnt=4 Sep 7 13:51:59 kernel: wlan0: [] AMRR: current rate 14, txcnt=34, retrycnt=6 Sep 7 13:52:00 kernel: wlan0: [] AMRR: current rate 14, txcnt=32, retrycnt=1 Sep 7 13:52:00 kernel: wlan0: [] AMRR increasing rate 15 (txcnt=32 retrycnt=1) Sep 7 13:52:00 kernel: wlan0: [] AMRR: current rate 15, txcnt=31, retrycnt=12 Sep 7 13:52:00 kernel: wlan0: [] AMRR decreasing rate 14 (txcnt=31 retrycnt=12) Sep 7 13:52:01 kernel: wlan0: [] AMRR: current rate 14, txcnt=36, retrycnt=3 Sep 7 13:52:01 kernel: wlan0: [] AMRR: current rate 14, txcnt=34, retrycnt=6 Sep 7 13:52:02 kernel: wlan0: [] AMRR: current rate 14, txcnt=34, retrycnt=5 Sep 7 13:52:02 kernel: wlan0: [] AMRR: current rate 14, txcnt=34, retrycnt=6 Sep 7 13:52:03 kernel: wlan0: [] AMRR: current rate 14, txcnt=34, retrycnt=5 Sep 7 13:52:03 kernel: wlan0: [] AMRR: current rate 14, txcnt=35, retrycnt=8 Sep 7 13:52:04 kernel: wlan0: [] AMRR: current rate 14, txcnt=30, retrycnt=6 Sep 7 13:52:04 kernel: wlan0: [] AMRR: current rate 14, txcnt=33, retrycnt=0 Sep 7 13:52:04 kernel: wlan0: [] AMRR increasing rate 15 (txcnt=33 retrycnt=0) Sep 7 13:52:05 kernel: wlan0: [] AMRR: current rate 15, txcnt=26, retrycnt=5 Sep 7 13:52:05 kernel: wlan0: [] AMRR: current rate 15, txcnt=33, retrycnt=12 Sep 7 13:52:05 kernel: wlan0: [] AMRR decreasing rate 14 (txcnt=33 retrycnt=12) Sep 7 13:52:06 kernel: wlan0: [] AMRR: current rate 14, txcnt=30, retrycnt=8 Sep 7 13:52:06 kernel: wlan0: [] AMRR: current rate 14, txcnt=33, retrycnt=5 Sep 7 13:52:07 kernel: wlan0: [] AMRR: current rate 14, txcnt=27, retrycnt=2 Sep 7 13:52:07 kernel: wlan0: [] AMRR: current rate 14, txcnt=32, retrycnt=9 Sep 7 13:52:08 kernel: wlan0: [] AMRR: current rate 14, txcnt=32, retrycnt=3 Sep 7 13:52:09 kernel: wlan0: [] AMRR: current rate 14, txcnt=27, retrycnt=1 Sep 7 13:52:09 kernel: wlan0: [] AMRR increasing rate 15 (txcnt=27 retrycnt=1) Sep 7 13:52:09 kernel: wlan0: [] AMRR: current rate 15, txcnt=33, retrycnt=9 Sep 7 13:52:10 kernel: wlan0: [] AMRR: current rate 15, txcnt=32, retrycnt=8 Sep 7 13:52:10 kernel: wlan0: [] AMRR: current rate 15, txcnt=32, retrycnt=7 Sep 7 13:52:11 kernel: wlan0: [] AMRR: current rate 15, txcnt=32, retrycnt=8 Sep 7 13:52:11 kernel: wlan0: [] AMRR: current rate 15, txcnt=33, retrycnt=11 Sep 7 13:52:12 kernel: wlan0: [] AMRR: current rate 15, txcnt=31, retrycnt=11 Sep 7 13:52:12 kernel: wlan0: [] AMRR decreasing rate 14 (txcnt=31 retrycnt=11) Sep 7 13:52:12
[Bug 192950] [iwn] Centrino Advanced-N 6205 slow on 11n, better on 11g
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192950 Lars Engels l...@freebsd.org changed: What|Removed |Added CC||l...@freebsd.org --- Comment #24 from Lars Engels l...@freebsd.org --- To jump in: I'm not having problems on yesterday's HEAD using an 6205: ubuntu-14.04.1-server-amd64.iso 6.4 MB/s - 195 MB of 572 MB, 59 secs left wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 60:67:20:xx:xx:xx inet 192.168.0.11 netmask 0xff00 broadcast 192.168.0.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet MCS mode 11ng status: associated ssid hafenkneipe24GHz channel 1 (2412 MHz 11g ht/20) bssid c4:27:95:xx:xx:xx regdomain ETSI country DE authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit txpower 50 bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 64 protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi wme roaming MANUAL -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Issues with urtwn
I've been having some issues with connection stability in urtwn for several months. The usual symptom is that after some period of time the connection will apparently stall. If I'm running ping continuously, for instance, it will at some point stop receiving replies. Then, sometime later, immediately if I use the reassociate command in wpa_cli, the connection will fix itself and all the packets I didn't get earlier get delivered at once: hundreds of ping replies, for instance, some with time stamps minutes in the past. No data is actually lost, though. I think the issue is that the driver does not actually support powersave mode (maybe it should?) but reports to the AP that it does: ifconfig wlan0 list sta (this is on the AP) ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 80:1f:02:cc:47:a91 11 11M 8.50 5526 55712 EPS AE RSN I don't know enough about wireless to fix this, but the AP waiting for a powersave poll and never getting one seems consistent with the problem. Is there a simple way just to disable advertising this? -Nathan ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
On 7 September 2014 08:09, Nathan Whitehorn nwhiteh...@freebsd.org wrote: I've been having some issues with connection stability in urtwn for several months. The usual symptom is that after some period of time the connection will apparently stall. If I'm running ping continuously, for instance, it will at some point stop receiving replies. Then, sometime later, immediately if I use the reassociate command in wpa_cli, the connection will fix itself and all the packets I didn't get earlier get delivered at once: hundreds of ping replies, for instance, some with time stamps minutes in the past. No data is actually lost, though. I think the issue is that the driver does not actually support powersave mode (maybe it should?) but reports to the AP that it does: ifconfig wlan0 list sta (this is on the AP) ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 80:1f:02:cc:47:a91 11 11M 8.50 5526 55712 EPS AE RSN I don't know enough about wireless to fix this, but the AP waiting for a powersave poll and never getting one seems consistent with the problem. Is there a simple way just to disable advertising this? When it next stalls, check ifconfig wlan0 and ifconfig urtwn0 - see if OACTIVE is set. I know iwn and ath had problems in the past where OACTIVE handling was plain broken (wasn't behind locks) and in an SMP, preemptive world things got gunked up. -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
On 09/07/14 08:28, Adrian Chadd wrote: On 7 September 2014 08:09, Nathan Whitehorn nwhiteh...@freebsd.org wrote: I've been having some issues with connection stability in urtwn for several months. The usual symptom is that after some period of time the connection will apparently stall. If I'm running ping continuously, for instance, it will at some point stop receiving replies. Then, sometime later, immediately if I use the reassociate command in wpa_cli, the connection will fix itself and all the packets I didn't get earlier get delivered at once: hundreds of ping replies, for instance, some with time stamps minutes in the past. No data is actually lost, though. I think the issue is that the driver does not actually support powersave mode (maybe it should?) but reports to the AP that it does: ifconfig wlan0 list sta (this is on the AP) ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 80:1f:02:cc:47:a91 11 11M 8.50 5526 55712 EPS AE RSN I don't know enough about wireless to fix this, but the AP waiting for a powersave poll and never getting one seems consistent with the problem. Is there a simple way just to disable advertising this? When it next stalls, check ifconfig wlan0 and ifconfig urtwn0 - see if OACTIVE is set. I know iwn and ath had problems in the past where OACTIVE handling was plain broken (wasn't behind locks) and in an SMP, preemptive world things got gunked up. OACTIVE is not set when it stalls. It also appears that only the RX path is stalled: transmitted packets make it, at least some of the time, to their destination when this happens. -Nathan ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
Ok. Try disabling bgscan. ifconfig wlan0 -bgscan -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Intel Centrino Wireless-N 2230 status
I think no. I'm running with this settings: iwn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 60:6c:66:7b:af:75 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 60:6c:66:7b:af:75 inet 10.0.0.102 netmask 0xff00 broadcast 10.0.0.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet OFDM/48Mbps mode 11g status: associated ssid hellooo channel 3 (2422 MHz 11g) bssid c0:4a:00:ea:5a:ea regdomain ETSI country HU authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme roaming MANUAL And these lines are in rc.conf in working case: wlans_iwn0=wlan0 ifconfig_wlan0=WPA NOSYNCDHCP country HU -powersave -ht and these in not working case: wlans_iwn0=wlan0 ifconfig_wlan0=WPA NOSYNCDHCP country HU -powersave On 9/5/14, Adrian Chadd adr...@freebsd.org wrote: Also, do you run this with -bgscan ? -a On 5 September 2014 12:26, Adrian Chadd adr...@freebsd.org wrote: Hi! This is just an iwn panic. Did your actual -HEAD kernel panic? Try doing this with sysctl dev.iwn.0.debug=0xff; let's see what happens just before the firmware loses its mind. Thanks! -a On 5 September 2014 12:22, Oliver Pinter oliver.p...@gmail.com wrote: I got the attached iwn panic, even if running in -ht mode. In between I have a working connection. I set up now a serial console and try to enable the ht mode with debugging. On 9/3/14, Oliver Pinter oliver.p...@gmail.com wrote: Or not, I forgot the -ht option in rc.conf. G STA + G AP = ok G STA + N AP = ok N STA + N AP = fail On 9/3/14, Oliver Pinter oliver.p...@gmail.com wrote: Hi! Small status update: The mode N works too, I mistyped the other AP's passwork. So both mode G and mode N working after the backports. BTW, can you MFC the same changes to 10.1? On 9/2/14, Adrian Chadd adr...@freebsd.org wrote: Hi, Compile it with IWN_DEBUG, then sysctl dev.iwn.0.debug=0x1 -a On 2 September 2014 12:41, Oliver Pinter oliver.p...@gmail.com wrote: I not tried freebsd-head yet, but I'm able today. In mode N seems like the NIC sends only one frame, and no more. With tcpdump and/or wlandebug I see only rx packets and no tx. If you add some pointer what changes must I create to easier debug, or what concrete information required, feel free to ping me or send the details. On 9/2/14, Adrian Chadd adr...@freebsd.org wrote: Cool! Have you tried freebsd-head? Does it work there? How's it failing in association state? What's it saying? -a On 2 September 2014 12:30, Oliver Pinter oliver.p...@gmail.com wrote: Hi All! After I backported all of the net80211 and iwn changes from 11-CURRENT to 10-STABLE the wireless NIC in subject working on mode G. If I try to use with mode N (ht20, ht40) it failed in association state. All of the backports are in this github repo: https://github.com/opntr/opBSD/commits/op/stable/10-iwn-backport Oliver ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
Also does not help. I also tried various other things like forcing 11b or 11g mode, all of which made no difference. -Nathan On 09/07/14 11:51, Adrian Chadd wrote: Ok. Try disabling bgscan. ifconfig wlan0 -bgscan -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Issues with urtwn
Hi, On 7 September 2014 19:16, Thiago Farina tfrans...@gmail.com wrote: On Sun, Sep 7, 2014 at 12:09 PM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: I've been having some issues with connection stability in urtwn for several months. The usual symptom is that after some period of time the connection will apparently stall. If I'm running ping continuously, for instance, it will at some point stop receiving replies. Then, sometime later, immediately if I use the reassociate command in wpa_cli, the connection will fix itself and all the packets I didn't get earlier get delivered at once: hundreds of ping replies, for instance, some with time stamps minutes in the past. No data is actually lost, though. I think the issue is that the driver does not actually support powersave mode (maybe it should?) but reports to the AP that it does: ifconfig wlan0 list sta (this is on the AP) ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 80:1f:02:cc:47:a91 11 11M 8.50 5526 55712 EPS AE RSN I don't know enough about wireless to fix this, but the AP waiting for a powersave poll and never getting one seems consistent with the problem. I think what you are relating here is what I observed recently too. Sorry, I'm new to FreeBSD. Just installed it recently, and I noticed that after I left it idle (I went to do something for some hours) for some time it lost the connection. Only rebooting makes it connect again to my network. Which NIC are you seeing this on? I don't have this problem with Intel/Atheros chips on freebsd-head. -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
