From: Jouni Malinen (jkmaline_at_cc.hut.fi)
Date: 2002-09-17 14:37:07 UTC
On Tue, Sep 17, 2002 at 11:53:44AM +0200, Martin Whitlock wrote:
> I tested the new release (2002-09-12) and found a problem regarding packet
> lengths when I have 128 bit WEP enabled. When I ping no packets larger than
> 1464 bytes (i.e. 'ping kth.se -s 1464') will pass through the AP. In
The dmesg output you sent is not produced by 2002-09-12. Instead, it is from a somewhat older CVS snapshot.
I was unable to repeat the problem with packet lengths near the MTU. I tested both routing (AP acting as NAT box) and bridging. Both worked without problems and ping to kth.se worked fine with packets 1491 .. 1501 (i.e., -s 1463 .. 1473) when using WEP.
> addition, I get this message and then the system reboots:
> wlan0: AP queue full - dropping new message
That's not good.. I haven't seen it that message in my tests and it should not really happen unless the scheduled task is sleeping due to some other use (hostap driver should never sleep in that task).
Do you mean that the system crashed/rebooted immediately after getting that message? The dmesg log did show 'AP queue full' messages, but there was no reboot..
> wlan0: authentication: 00:05:4e:81:02:94 len=6, auth_alg=0,
> status_code=0, fc=0x00b0
> wlan0: AP trying to authenticate?
Do you have other_ap_policy set to something else than 0? This message would indicate that the station 00:05:4e:81:02:94 was first noticed from a beacon frame and then it tried to authenticate. This could happen, e.g., with other_ap_policy=3 and station acting first in IBSS and then trying to associate with the AP.
> wlan0: WEP decryption failed (SA=00:05:4e:81:01:fd)
Is this related to the ping packet not getting through? What was the hwaddr of the device sending those packets? What card is in the station? What about the driver? Does the same test work with another AP?
-- Jouni Malinen PGP id EFC895FA