[Prism54-devel] Re: Spurious disassociations in prismGT STA <-> prism2.5 AP setup

[vda at port.imtp.ilyichevsk.odessa.ua]

On Sunday 08 February 2004 22:18, vda at port.imtp.ilyichevsk.odessa.ua wrote:
> I will capture unfiltered dump tonight. Right now,
> it will be considerably diluted by traffic
> to/from other STAs.

Quick summary:
prism54 card/firmware/driver spuriously disassociate
at low to medium signal levels even under light traffic.
Under heavy traffic this happens even at the very good
signal levels.

Why is it doing this??!

Logs won't fit mailing list restrictions, so I uploaded
larger files to at http://195.66.192.168/linux/prism.tar.bz2
Captions below.

230.txt
============
Captured with tcpdump -nleieth1 -s0 -w 230.raw
while ping -i3 -s 1400 was running on the STA.

AP, STA and monitor all are within 1 meter and
equipped with small finger-sized antennas.
No other STAs active.

Typical signal level reading on AP:
    /proc/net/hostap/wlan0/00:04:e2:64:15:e5:
    last_rx: silence=164 signal=229
with only minor fluctuations.

Signal level reading on STA is fluctuating wildly,
making readings useless

eth1      IEEE 802.11b/g  ESSID:"ear"  Nickname:"ear"
          Mode:Managed  Channel:11  Access Point: 00:05:5D:FA:58:45
          Bit Rate:11Mb/s   Tx-Power=31 dBm   Sensitivity=20/200
          Retry min limit:8   RTS thr:2347 B   Fragment thr:2346 B
          Link Quality:143/0  Signal level:-20 dBm  Noise level:-154 dBm
                       ^^^                 ^^^                  ^^^^
          Rx invalid nwid:0  Rx invalid crypt:10  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

NB: STA spontaneously changed it's channel to 3 and back to 11
approx. ~5 secs before logging was stopped

230_6.txt
============
Same setup as in 230.txt but AP is on channel 6

STA spontaneously changes it's channel to 2 and back
near the end of capture

180.txt
============
Setup like in 230_6.txt but AP antenna is removed and
STA partially screened with metal shield.

NB: monitoring station's antenna is NOT removed, so it
have to have good signal from STA and from AP
(it's picking AP's signal via mainboard, since it sits
in the AP box! ;)

AP signal reading (signal=NNN) fluctuates 178..185

STA frequently disassociates from AP

190.txt
============
Setup like in 180.txt
Metal screen is reconfigured so that
AP signal reading (signal=NNN) fluctuates around 190

STA sometimes disassociates from AP

flood.txt
============
All previous dumps were taken under very light load
(a ping of 1400 bytes every 3 secs). A ping -f can
trigger 'bad' behaviour easier. Bidirectional UDP
netcat flood at signal level ~190 does not
just cause disassoc events.
It quickly hanged STA card with following syslog messages:

01:56:46 eth1: timeout waiting for mgmt response 1000, trigging device
01:56:47 eth1: timeout waiting for mgmt response
01:56:48 eth1: timeout waiting for mgmt response 1000, trigging device
01:56:49 eth1: timeout waiting for mgmt response
01:56:50 NETDEV WATCHDOG: eth1: transmit timed out
01:56:50 eth1: timeout waiting for mgmt response 1000, trigging device
01:56:51 eth1: timeout waiting for mgmt response
01:56:52 NETDEV WATCHDOG: eth1: transmit timed out
01:56:53 eth1: timeout waiting for mgmt response 1000, trigging device
01:56:54 eth1: timeout waiting for mgmt response
01:56:54 NETDEV WATCHDOG: eth1: transmit timed out
01:56:55 eth1: mgmt tx queue is still full
01:56:56 eth1: mgmt tx queue is still full
01:56:56 NETDEV WATCHDOG: eth1: transmit timed out
01:56:57 eth1: mgmt tx queue is still full
01:56:58 eth1: mgmt tx queue is still full
01:56:58 NETDEV WATCHDOG: eth1: transmit timed out
01:56:59 eth1: mgmt tx queue is still full
...

rmmod/modprobe cycle 'fixed' it.

I tried netcat flood at max signal level (signal>=230).
It does not hang STA but deassoc events are happening.
See flood.log for an example.
--
vda