Fabian Keil wrote:
quoted text
> 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.

quoted text
> 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.

quoted text
> 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).

quoted text
> 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.

quoted text
> 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.

quoted text
> 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

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"