Wireless event: cmd=0x8c00 len=20

[Brian J. Murrell]

On Wed, 2004-06-23 at 20:24 -0700, Jouni Malinen wrote:
> 
> That is IWEVTXDROP, i.e., a packet was dropped because maximum number of
> retries failed (did not receive an acknowledgement from the AP).

Hrm.

> Please
> verify kernel log (e.g., 'dmesg') for ay possible errors when the
> connection dies.

All that was in my kernel log when I came back to a dead connection
again was:

wifi0: encryption configured, but RX frame not encrypted (SA=00:04:e2:b2:c9:52)
TKIP: replay detected: STA=00:04:e2:b2:c9:52 previous TSC 000000000a64 received TSC 000000000a64
wifi0: decryption failed (SA=00:04:e2:b2:c9:52) res=-4
wifi0: encryption configured, but RX frame not encrypted (SA=00:04:e2:b2:c9:52)
wifi0: encryption configured, but RX frame not encrypted (SA=00:04:e2:b2:c9:52)

> This may be an interoperability issue with the station firmware and the
> currently used roaming mode. I think I can trigger similar problem by
> manually triggering a scan (e.g., with 'iwlist wlan0 scan') and not
> asking the to join the AP. The station firmware claims that the
> connection is still up, but it drops all TX packets.. 
...
> The connection can
> be fixed by triggering join request ('iwconfig wlan0 ap <BSSID>').

That brings things back online here.  When this happens of course,
wpa_supplicant goes through it's motions.

> If
> nothing else, I could add a workaround for this so that wpa_supplicant
> could trigger a join request if it detects that each TX packets gets
> IWEVTXDROP status..

Seems a bit hackish, no?  If I could understand what the real problem is
(with my very limited -- er, make that next to no knowledge of wifi) and
it's something that needs to be addressed with a hardware vendor, I can
try that route.

> I'm in process of changing wpa_supplicant to use a different roaming
> mode to avoid this issue.

Hrm.  So is this actually a wpa_supplicant issue then and not with
hardware/firmware?

> This works for many cases, but I still have
> couple of open issues with the implementation, so I haven't committed it
> yet to the CVS.

OK.

> If you think you are seeing something different than the issue I
> described above, please send me debug log from wpa_supplicant
> (wpa_supplicant -dd ..).

I'm not really sure to be honest.  I can get a -dd log if you still want
one.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20040624/cface4da/attachment.pgp