Management frames in 0.0.4 and later

[Petr Novak]

Dear Jouni and others,

> Did you happen to iwconfig txpower in the AP or STAs? It was removed in 
> 0.0.4. If you did not configure TX power explicitly with iwconfig, this 
> should not have changed anything, though. 

We do change the txpower fixed in both the APs and STAs, and we do modify the 
sources to include the manifest constant to enable raw power setting.

> If I remember correctly, all your STAs were quite long way away from the 
> AP. Have you tested the AP with another STA that would be close to the 
> AP? 

We have about 10 APs, some of them with up to 3 master mode cards, all with 
different ESSID. The clients are at varying distances, the maximum is about 
10 km or so. The problem we are discussing has occured on the main AP (the 
one feeding the whole net to the outside world - that means our single point 
of failure - according to old Murphy there is no other way it would break, is 
there?) and with firware set transmit rate it occurs on 2 out of 3 of the 
master mode cards, but no all STAs. With patched hostap to modify the txrate 
of all management frames to the lowest one everything except 1 master mode 
card work fine. What is most curious is the fact that it had worked with post-
0.0.4 for over 2 weeks and suddenly 1 morning it turned bad. Fortunately, 
reverting back to 0.0.3 makes it work in a stable way again, although we have 
occasional crashes during high loads, but at least the stations authenticate 
and associate. The problem occurs even with STAs which are several hundred 
meters away from the AP, but decreasing the transmit rate of management 
frames fixes these (as well as some really distant ones). For curiosity, 
changing to a different frequency/channel does NOT seem to have an impact on 
the problem, so it does not seem likely that it would be a simple 
interference from another WLAN.

>> [the bad sniff]

> Unfortunately, this sniffer log did not include the most interesting 
> information for me, i.e., the time used between the authentication frame 
> from STA and the reply from AP. It would be useful to see these frames 
> (i.e., auth transaction #1 and #2 and all ACKs related to them) in one 
> sniffer log. Some STA implementations seem to not ACK authentication 
> frame from the AP if it takes too long time to receive that after STA's 
> own authentication frame was sent. 

The timing reference can be taken from the MAC clock (I know it is a pain to 
calculate - what sniffer would you feel the best to work with?).

> The frame exchanges in this sniffer log looked somewhat odd.. The AP 
> seemed to be able to receive all management frames from the STA (since 
> it ACKed them), but it did not seem to receive ACK/CTS frames from the 
> STA (since it retried sending the original data/RTS frame). This is 
> quite low-level issue and the driver does not really have much control 
> about retries/ACKs. 

Please remember that these STAs in the sniff/syslog are all hostap running 
post-0.0.4 CVS version (August 2003) and STA 1.7.4 - the same as the AP. All 
are same make and model of card - the Z-COM XI626.

> I don't remember changes anything that should cause something like this 
> between 0.0.3 and 0.0.4, but then again, quite a bit of code changed 
> between those versions. You could at least verify that the BBP and MAC 
> configuration is same by comparing "utils/hostap_diag -a wlan#" output 
> from the same card running 0.0.3 and 0.0.4 version of the driver. 

I will definitely try this and I will post you the results.

> One, maybe somewhat related, change I did in CVS last weekend was to 
> mark STAs authenticated immediately after sending out authentication 
> frame whereas the previously an ACK was required from STA before 
> changing authentication status. This could make it easier for the STA to 
> associate in some cases because association does not fail anymore if AP 
> was able to see the authentication frame but missed the ACK frames. 
> However, association is still requiring a successful ACK, so the problem 
> might just move one step forward.. 

OK, I will try to test the current CVS to see what has changed in the 
behaviour (if anything).

And, I will look for what has changed between 0.0.3 and 0.0.4.


Thanks for all your support so far.

Best regards,
--
Petr Novak
pen at dobnet.cz
+420 776 204 526
+420 603 870 101