PATCH: HostAP v0.3.9 -- Sig Strength & Low bitrate Problems (host_roaming = 2)
Thu Jul 21 15:28:13 PDT 2005
We've had two nagging problems with the HostAP driver running as a
station in host_roaming mode '2' ( ie. the default mode used by
Note -- we're running v1.8.3 of the STA firmware.
The first problem which I posted awhile back, was that signal strength
reporting stopped working. Values returned from /proc/net/wireless
stopped changing in mode '2'. I'd reproduced this problem with multiple
0.2.x and 0.3.x versions of the driver ( w/out our application framework
nor wpa_supplicant running ) on both our platform ( an ARM / Linux 2.4
system ) and an x86 laptop running FC3.
The second problem is something we've been working on for the past few
weeks. If a scan is done while associated with an Access Point,
subsequent data traffic causes the bitrate to drop to 2Mbps, then 1Mbps,
and never go back to 11Mbps.
I finally unravelled what I think is the cause of these two problems.
Since our STA FW version is greater the 1.3.1, whenever a scan is
requested, the driver uses the HOSTSCAN method as opposed to the
SCANREQUEST. The function that retrieves the results of the HOSTSCAN
places these results in 'local->last_hostscan_results'.
In host_roaming mode '2', in order to associate with an AP, the ioctl
SIOCSIWAP needs to be invoked, which causes the function
hostap_join_ap() in hostap_ioctl.c to be called. This function walks
thru 'local->last_scan_results' in order to find the channel number to
pass to the firmware with the JOINREQUEST. Since the HOSTSCAN results
were placed in 'local->last_hostscan_results', the preferred_ap is not
found, and subsequently the channel '0' is passed to the firmware on the
JOINREQUEST. This seems to confuse the firmware even though the correct
channel is passed to the fw earlier with the CNFOWN_CHANNEL command.
It seems that Jouni decided to get rid of the two separate scan_results
fields in his latest development branch. Now, both HOSTSCAN and
SCANREQUEST results are placed in 'local->last_scan_results'. This
causes hostap_join_ap() to find the right channel and this makes the
Prism STA firmware much happier.
I've found that both of my problems are solved by this change! ;)-
I also found that the workaround made in handle_info_queue_scanresults()
that calls prism2_host_roaming() when in host_roaming mode '2' &&
associated, doesn't seem to be necessary. Also, this workaround doesn't
seem to do the right thing in v0.3.9 because prism2_host_roaming() will
look at the wrong scan results.
So, I've attached a patch for v0.3.9 which with a slight modification (
eg. you don't apply the hostap_info.c part of the patch ) can be applied
to earlier v0.3.x versions.
Note - this patch doesn't fix the similar problem in
prism2_host_roaming() where the wrong scan_results are looked at when in
host_roaming mode '1'.
The simplest solution would be to move to v0.4.1, although it too would
need the workaround in handle_info_queue_scanresults() backed out.
Please let me know if you have any comments and/or questions.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2301 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20050721/25c53122/attachment.bin
More information about the Hostap