PATCH: HostAP v0.3.9 -- Sig Strength & Low bitrate Problems (host_roaming = 2)

[Tony Espy]

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 
wpa_supplicant ).

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.

Thanks,
Tony Espy
Pepper Computer











-------------- next part --------------
A non-text attachment was scrubbed...
Name: hostap-driver-0.3.9.patch
Type: text/x-patch
Size: 2301 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20050721/25c53122/attachment.bin