[Prism54-devel] Re: Strange problem with wds in prism54

[Jean-Baptiste Note]

Hello Sergio,

Thanks very much for your input.

The problem seems easy to solve in part, but i won't be able to take
enough time for a proper and clean fix until sunday ; i'm describing it
here for comment before writing it anyways.

> I don't mind helping ... That way we can get all the bugs worked out faster.

And thank you for this.


> Here it the log that you asked for:
>
> wds_find_device
> wds_find_device: WDS from mac ff-ff-ff-ff-ff-ff not in current config,
> returning NULL
> [ff][ff][ff][ff][ff][ff][00][02][6f][21][1a][22][08][00][45][00][00][60][62]
> [9d][00][00][80][11][40][a5][c0][a8][0a][fb][c0][a8][0a][ff][00][89][00][89]
> [00][4c][1c][93][9f][2b][29][10][00][01][00][00][00][00][00][01][20][46][48]
> [45][50][46][43][45][4c][45][48][46][43][45][50][46][46][46][41][43][41][43]
> [41][43][41][43][41][43][41][43][41][42][4f][00][00][20][00][01][c0][0c][00]
> [20][00][01][00][04][93][e0][00][06][e0][00][c0][a8][0a][fb]
> wds_net_send_packet

Now I understand this :
  2     08:00:45:00:00:4e       no                21.88
  2     08:00:45:00:00:ca       no                45.98
  2     08:00:45:00:00:f2       no               298.79
  2     08:06:00:01:08:00       no               155.37

in WDS mode, the code expects the buffer to always contain a 6-byte mac +
802.3 frame. This is not always the case, usual 802.3 frames are
sometimes sent. What you see in the arp cache are macs that start out
like ethernet IP packets, the remnants of the ping packets you sent :)

> wds_find_device
> wds_find_device: WDS from mac 01-80-c2-00-00-00 not in current config,
> returning NULL
> [01][80][c2][00][00][00][00][04][e2][80][7d][42][00][2e][42][42][03][00][00]
> [00][00][00][00][0a][00][04][e2][80][7d][42][00][00][00][00][00][0a][00][04]
> [e2][80][7d][42][80][02][00][00][3c][00][02][00][04][00][a5][a5][a5][a5][a5]
> [a5][a5][a5]
> wds_net_send_packet
>
> The second packet (01:80:c2:00:00:00) has the mac address of the neighbor
> wds device on the second octect (00:04:e2:80:7d:42). So it is indeed coming
> from the other access point.

Now we need to make sense out of this packet if we want WDS to actually
work...

To my untrained eye, this looks like 
1/ a prism54-specific header, 6 bytes

2/ series of 4 MAC addresses (the 4 mac addresses of the WDS frame ?) on
6 bytes,

3/ followed by a (very short) 802.3 frame, 2 mac addresses + a payload
starting at [80][02][00][00]... ? 

Would perchance [00 00 00 00 00 0a] be the mac address you added to the
prism54 device ?
Would [00 2e 42 42 03 00] be a mac address you recognize ?

Maybe Jouni, Luis or Denis can make more sense of this mess; for me to
go on, would it be possible for you to put some device (may be your
prism54 card, but ideally some other) in monitor mode and sniff with
ethereal the frames that are sent on the air by the neighbor WDS device
? -- i'd really like to sort out from the above packet which
transformation the raw 802.11 WDS frame undergoes before being delivered
to us.

I don't think i have a working WDS device (maybe madwifi does it ?), so
it'll be difficult for me to carry out such tests; but i'll try if you
can't.

> We still need to figure out why a ping from my laptop to the prism54 device
> does not work when I add a wds device? Could it be that this packet is not
> making it to the primary interface?

This seems partly understood. Now we need to understand what the other
frames mean, in particular the header with its 4 macs, and then how to
differentiate WDS frames from non-WDS ones, but this should not be so
difficult.

JB

-- 
Jean-Baptiste Note
+33 (0)6 83 03 42 38
jean-baptiste.note at wanadoo.fr