From: John D. Rowell (jdrowell_at_exerciseyourbrain.com)
Date: 2002-04-07 18:18:02 UTC
Thanks Jouni, the patch worked beautifully. I haven't tested today's
release yet but will do later.
Unfortunately there's still something weird going on when bridging is used. I have a setup like:
ether (1) <---> ether+wlan0+wlan0wds0 (2) <---> wlan0+wlan0wds0 (3)
The "+" signs mean bridged segments on each host (1, 2, and 3). When pinging with even sizes (I'm using 2000), everything works fine from 1 to 2, 2 to 3, and 1 to 3. When pinging with odd sizes (i.e. 2001), there's still no packet loss between 1 and 2 or 2 and 3, but there's an _exact_ 50% packet loss between 1 and 3. This allows TCP to work fine (err, retransmiting the lost packets I'd guess) but UDP is broken, so host 3 (and the stations connected to it, or other meshed APs after that) cannot get any hosts resolved (the DNS server runs on host 1). There are still several apparently bridging related packets being dropped in the WDS connection (see dump below, they're related to MAC 01:80:c2:00:00:00 which I _think_ is for STP broadcasting), but they don't seem to be directly related to the packet loss. They happen about once a second and that doesn't increase when pinging from 3 to 1 (even ping -f, which gives me TX timeouts ;) - will try with the version released today).
Apr 7 11:09:15 localhost kernel: wlan0: dropped received packet from
00:04:5a:c
c:c8:17 with no ToDS flag (type=0x02, subtype=0x00)
Apr 7 11:09:15 localhost kernel: wlan0: RX status=0x2000 (port=0,
type=1, fcser
r=0) silence=8 signal=51 rate=10 rxflow=0; jiffies=648063
Apr 7 11:09:15 localhost kernel: FC=0x0208 (type=2:0) dur=0x0000
seq=0x9fe0
data_len=54 [FromDS]
Apr 7 11:09:15 localhost kernel: A1=01:80:c2:00:00:00
A2=00:04:5a:cc:c8:17 A
3=00:04:5a:cc:c8:17 A4=0a:0b:0c:0d:0e:0f
Apr 7 11:09:15 localhost kernel: dst=01:80:c2:00:00:00
src=00:04:5a:cc:c8:17
len=54
Apr 7 11:09:17 localhost kernel: wlan0: dropped received packet from
00:04:5a:c
c:c8:17 with no ToDS flag (type=0x02, subtype=0x00)
Apr 7 11:09:17 localhost kernel: wlan0: RX status=0x2000 (port=0,
type=1, fcser
r=0) silence=8 signal=57 rate=10 rxflow=0; jiffies=648257
Apr 7 11:09:17 localhost kernel: FC=0x0208 (type=2:0) dur=0x0000
seq=0xa170
data_len=54 [FromDS]
Apr 7 11:09:17 localhost kernel: A1=01:80:c2:00:00:00
A2=00:04:5a:cc:c8:17 A
3=00:04:5a:cc:c8:17 A4=22:23:24:25:26:27
Apr 7 11:09:17 localhost kernel: dst=01:80:c2:00:00:00
src=00:04:5a:cc:c8:17
len=54
00:04:5a:cc:c8:17 is the other end of the WDS connection. "Identical" messages (opposing MAC) appear on the other end's log.
I'm impressed by how fast the development of HostAP is going, and its quality. Thanks for a great project!
Cheers,
jd
On Saturday, April 6, 2002, at 12:17 PM, Jouni Malinen wrote:
> On Sat, Apr 06, 2002 at 08:06:34AM -0800, John D. Rowell wrote:
>
>> Now comes the funky part. I can ping most IPs in either wireless or
>> wired networks (some take a bit to show up, probably related to the
>> bridging), using any ICMP packet size (I tried several up to 30Kb).
>> OTOH, any UDP or TCP seems to get truncated. DNS does not work, and
>> trying to fetch a page using HTTP only retrieves the first 4Kb.
>> Needless
>> to say, things like ssh do not work due to this...
>
> Aaah.. My ping testing<TM> is apparently not enough anymore
> ;-). Actually, to be exact, my ping testing with even sized packets
> was not enough. Using odd sized packets duplicates the problem..
>
> Fake-WDS header generation had bug in it.. I added the fourth address
> after the payload, but did not consider what would happen if the
> payload length was odd. Prism2 chipset does not support writes to odd
> offset, so this resulted in last byte of the payload being
> overwritten. Patch to fix this is attached and I'll have to apparently
> release new version of the driver, but that can wait till tomorrow.
>
>> I'm getting lots of debug messages in the log files.
>
> I was seing some dropped frames when using bridging code, but I
> haven't yet looked into them more closely since everything seemed to
> be working. Anyway, I didn't see any dropped frames with the latest
> driver and odd sized packets and TCP worked fine. However, I did not
> test bridging code this time. I'll take a closer look at it later.
>
>> The MAC addresses after the "dropped received packet from" are always
>> from one of the other two APs I'm WDSing with. A4 varies a lot (not
>> only
>> sequential octets). I've seen A4=68:65:3c:2f:54:54 and
>> A4=70:3a:2f:2f:77:77, for instance.
>
> Addr4 in those header dumps is from the Prism2 rx/tx frame header and
> it will contain some random information in more or less every case. If
> someone would happen to send standard-compiliant WDS frame, it might
> even be correct address.
>
>> On a separate issue, doesn't the fact that WDS works on a single
>> channel
>> create inter-AP interference?
>
> Yes and I would consider using two cards (on different channels) in
> each AP when WDS is used in an AP that has client stations. Making a
> wireless link between two wired networks on the other hand, would not
> suffer from this.
>
> --
> Jouni Malinen PGP id EFC895FA
>