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