Date: Thu, 01 May 2008 08:36:07 -0700 From: Sam Leffler <sam@freebsd.org> To: Fabian Keil <fk@fabiankeil.de> Cc: freebsd-current@freebsd.org Subject: Re: Connection problems with wme enabled Message-ID: <4819E367.3060306@freebsd.org> In-Reply-To: <20080501163943.4e8d102e@fabiankeil.de> References: <6b8e8f4f0804291900v521cde5cw1ad4eaba70244e9c@mail.gmail.com> <4817E52F.5070806@freebsd.org> <20080430121014.209beb00@fabiankeil.de> <48189577.4080109@freebsd.org> <48189871.2060005@freebsd.org> <20080501163943.4e8d102e@fabiankeil.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Fabian Keil wrote:
> Sam Leffler <sam@freebsd.org> wrote:
>
>
>> It would still be worth understanding why WME operation breaks iwi;
>> please provide logs showing what is happening.
>>
>
> Where would I get meaningful logs?
>
man wlandebug. If the 802.11-related activity doesn't show you what you
want then try driver-level debugging. This should be controlled through
sysctl dev.iwi.X.debug but some drivers still use debug.iwi or similar.
> dmesg doesn't show any relevant messages,
> even when booted in verbose mode.
>
> The ifconfig output looks normal (to me) as well:
>
> fk@TP51 ~ $sudo ifconfig -v wlan0
> wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> ether 00:0e:...
> inet 192.168.0.49 netmask 0xffffff00 broadcast 192.168.0.255
> media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g
> status: associated
> ssid ... channel 7 (2442 Mhz 11g) bssid 00:14:...
> regdomain DEBUG country DE anywhere -ecm authmode OPEN -wps -tsn
> privacy ON deftxkey 1
> wepkey 1:104-bit powersavemode OFF powersavesleep 100 txpower 30
> txpowmax 50.0 -dotd rtsthreshold 2346 fragthreshold 2346 bmiss 24
> 11b ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6
> 11g ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6
> 11na ucast NONE mgmt 0 MCS mcast 0 MCS maxretry 6
> 11ng ucast NONE mgmt 0 MCS mcast 0 MCS maxretry 6
> scanvalid 60 -bgscan bgscanintvl 300 bgscanidle 250
> roam:11b rssi 7dBm rate 1 Mb/s
> roam:11g rssi 7dBm rate 5 Mb/s -pureg protmode CTS -ht
> -htcompat -ampdu ampdulimit 8k ampdudensity - -amsdu -shortgi
> htprotmode RTSCTS -puren wme -burst -ff -dturbo -dwds roaming AUTO
> bintval 100
> AC_BE cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm ack
> cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm
> AC_BK cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm ack
> cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm
> AC_VI cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm ack
> cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm
> AC_VO cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm ack
> cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm
> groups: wlan
>
> While it shows association, open connections stall and
> I can't create new ones until reviving the device with
> ifconfig wlan0 down up.
>
> Under load (100K download rate) and with wme enabled
> the problem occurs after less than 5 seconds, if there's
> less load, it'll work a bit longer.
>
> wlanstats while the device is unresponsive:
>
> fk@TP51 ~ $wlanstats
> 1 rx from wrong bssid
> 4756 rx discard 'cuz dup
> 33 rx discard 'cuz mcast echo
> 6 rx discard mgt frames
> 471 rx beacon frames
> 6 rx element unknown
> 390 rx frame chan mismatch
> 8 rx disassociation
> 8 beacon miss events handled
> 23 rx discard 'cuz port unauthorized
> 25 active scans started
> 123844 wep crypto done in s/w
> 934 rx management frames
> 24 tx failed 'cuz vap not in RUN state
> 165 total data frames received
> 160 unicast data frames received
> 5 multicast data frames received
> 355 total data frames transmit
> 355 unicast data frames sent
> 54M current transmit rate
> 42 current rssi
> 42 current signal (dBm)
>
>
"8 beacon miss events handled"--so the firmware said you lost signal.
> While the number of "chan mismatch" seems high,
> I get the impression that it only increases while
> the device is getting down and up. It doesn't seem
> to increase while the device is working or hanging.
>
> wlanstats a bit later with wme disabled and wlan0 working:
>
> fk@TP51 ~ $wlanstats
> 1 rx from wrong bssid
> 4891 rx discard 'cuz dup
> 33 rx discard 'cuz mcast echo
> 6 rx discard mgt frames
> 519 rx beacon frames
> 6 rx element unknown
> 453 rx frame chan mismatch
> 8 rx disassociation
> 8 beacon miss events handled
> 23 rx discard 'cuz port unauthorized
> 27 active scans started
> 130514 wep crypto done in s/w
> 1048 rx management frames
> 25 tx failed 'cuz vap not in RUN state
> 3318 total data frames received
> 3318 unicast data frames received
> 2829 total data frames transmit
> 2829 unicast data frames sent
> 36M current transmit rate
> 42 current rssi
> 42 current signal (dBm)
>
wlanstats 1 gives you a rolling display every second; that's usually
more helpful in understanding what's happening. Unfortunately there are
more stats than can fit on a rolling display so sometimes the one(s) you
want aren't shown. There is a column fmt mechanism a la ps to control
output but it's not well developed (someone please take and improve).
Also some stats are maintained by drivers and not yet counted in the
net80211 layer (again, folks are welcome to help).
> It's interesting that with wme enabled the hangs
> usually occur with the transmit rate at 54, while
> it's usually a lot lower with wme disabled and the
> device working.
>
iwi does tx rate control in the firmware so unlikely to be related. The
more likely issue is the beacon miss handling. The driver should
recover and reconnect but it sounds like something didn't work. As a
workaround you can try upping the bmiss count to see if this is a
problem w/ the radio going deaf for a period of time--something I've
seen on older Intel parts.
> Manually setting the transmit rate to a lower value
> doesn't prevent the hangs though.
>
> While the problem occurs, stuff like
> "ifconfig wlan0 scan" hangs as well.
>
That is a separate issue.
> There are several access points in my neighbourhood,
> mine doesn't always have the strongest signal:
>
> fk@TP51 ~ $ifconfig wlan0 scan
> SSID BSSID CHAN RATE S:N INT CAPS
> ... 00:18:... 11 54M 21:0 100 EPS
> my ap 00:14:... 7 54M 21:0 100 EPS WME
> ... 00:15:... 6 54M 14:0 100 EPB WPA
> ... 00:04:... 6 54M 19:0 100 EP WPA WME
>
> I can't reproduce the problem with ath0.
>
> I'll be glad to provide further information, just tell me what you need.
>
> Fabian
>
See above. I ran tests yesterday w/ wme enabled in my environment but
the signal was stronger so not an equivalent test. What you need to do
is get a log that captures the event of losing connectivity. This must
include net80211 logging and probably needs to include some level of
driver debugging as the problem is in the driver. Try:
wlandebug state+scan+auth+assoc
sysctl debug.iwi=5
Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4819E367.3060306>