Possible bug in STA f/w 1.5.6
Martin Whitlock
martin.whitlock
Fri Nov 15 07:38:10 PST 2002
Correction... It appears that it was a little too early to blaim the new
Intersil f/w. I have just proven myself wrong by getting the same kind of
trouble even with older versions of STA f/w. But the problem definately
disappears when other_ap_policy is set to 0.
Is the solution to the problem to kick the macaddress of an AP that tries to
associate? Or would this have any bad side effects?
/Martin
-----Original Message-----
From: hostap-admin at shmoo.com [mailto:hostap-admin at shmoo.com]On Behalf Of
Martin Whitlock
Sent: den 15 november 2002 12:29
To: Hostap at Shmoo. Com
Subject: Possible bug in STA f/w 1.5.6
I beleive I've found a bug in STA f/w 1.5.6 while trying to solve the
HostAP(Client)-to-HostAP(AP) problem. I don't think that this possible f/w
bug is the only reason for my troubles, but it could definately be one
reason.
I have a HostAP (#1, f/w 1.3.6) in Master mode (with other_ap_policy=2)
I start another device with HostAP (#2, f/w 1.5.6), default settting
Master mode.
#1 sees #2 and get thats it is a AP
I change mode on #2 into Managed mode
#1 _still_ thinks that #2 is an AP
#2 tries to associate, but #1 prints debug message (AP trying to
associate?)
iwconfig on #2 shows a good signal quality, but macaddress
44:44:44:44:44:44
When I kick #2's macaddress it associates just fine.
With f/w 1.3.6 in #2 this problem does not occur, but I havn't tested any
versions in between of 1.3.6 and 1.5.6. Also if I switch other_ap_policy to
0 in #1, the problem disappears.
QUESTION: Would it be a bad idea to let HostAP driver do a kick_mac on
that address each time it thinks an AP is trying to associate?
/Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20021115/f2b882b4/attachment.htm
More information about the Hostap
mailing list