AR6k vs. Tomato: next round (#1250)

Werner Almesberger werner at openmoko.org
Fri Feb 13 03:06:27 CET 2009


Since I now have a small army of WRT54G(L) APs, I put Tomato 1.22 on
one of them, in an attempt to reproduce Mickey's famous bug #1250:
https://docs.openmoko.org/trac/ticket/1250

The test consisted of setting the AP to open, b/g mixed, the preamble
according to the table below, cycling (unbind/bind) the AR6k, calling
wmiconfig (or not) according to the table, and then trying to
associate.

This is what happens:

Tomato	AR6k	AP adv~	Neo 	AP responds
[1]	[2]	ertizes	requests

Long	default	long	long	success

Long	0	long	long	success

Long	1	long	long	doesn't respond at first,
				then success

Short	default	short	short	success

Short	0	short	short	success

Short	1	short	takes a while to get going ...
			long	association denied
			(repeats)

[1] Setting Advanced/Wireless/Preamble
[2] no wmiconfig or wmiconfig -i eth0 --setlongpreamble 0/1

I went back to my books and found that I had mis-interpreted the
short preamble option in the Probe Response: it doesn't mean that
the station is allowed to choose to use short preambles but that
it is required to do so.

Here's why: http://www.tomsguide.com/us/802,review-120-5.html

I therefore send apologies in the general direction of Tomato for
having considered it a lemon, and to Mickey for having doubted his
network. The AP is doing everything right.

The AR6k driver is certainly a bit stupid to try to associate with
a network requiring support for short preambles while insisting
on using a long preamble. However, if told by the user to insist
on long preambles and with the AP only allowing short preambles,
there isn't really any common ground.

What's puzzling me here is that the default setting was apparently
overridden in Mickey's AR6k, even in the first runs, well before
anyone mentioned --setlongpreamble. I tried setting the ESSID to
"vanille" but that didn't yield any magic effects.

The packets captured in
https://docs.openmoko.org/trac/attachment/ticket/1250/bug1250-wifiproblem.dump
are consistent with the Short/1 scenario, so this explains what is
happening but not why.

Mickey, what is the precise setup sequence for the WLAN interface
that leads to this ? I.e., is there more than just an
iwconfig eth0 essid vanille  ? Also, does an explicit
wmiconfig -i eth0 --setlongpreamble 0
help ?

The capture data from my experiments is under
http://svn.openmoko.org/developers/werner/wlan/tomato/

Another observation is that communication seems more fragile if the
network requires support for short preambles than when it doesn't.

So if experiencing network instability, it may be worth trying to set
wmiconfig -i eth0 --setlongpreamble 1
and see if the AP accepts this. If it does, this may improve network
stability, but at the price of lowering available data bandwidth.

- Werner



More information about the devel mailing list