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

Fri Apr 22 10:32:39 UTC 2005

Hello Jean-Baptiste,

> -----Original Message-----
> From: Jean-Baptiste Note [mailto:jean-baptiste.note at wanadoo.fr]
> Sent: Thursday, April 21, 2005 10:33 AM
> To: Sergio Ammirata
> Cc: prism54-devel at prism54.org; 'Denis Vlasenko'
> Subject: Re: [Prism54-devel] Re: Strange problem with wds in prism54
> 
> 
> Hello Sergio,
> 
> I'm starting to wonder... Is there really WDS going on ? For as far as i
> can see, well, the problem on the tx path stems from the 6-byte header
> we put at the beginning :
> 
> > [00][02][6f][22][9a][d7][01][80][c2][00][00][00][00][02][6f][21]
> 
> The txing device was sent by the driver a packet starting as :
> 
> [00][02][6f][22][9a][d7][01][80][c2][00][00][00][00][02][6f][21]
> 
> Which was interpreted "normally", ie, two MAC adresses, then immediately
> a 802.11 packet. This leads to 00 02 being it's size, so it's been
> truncated (in fact, it was intended to be the beginning of the second
> mac address).
> 
> 
> > [00][02][6f][21][1a][28][ff][ff][ff][ff][ff][ff][00][02][6f][22]
> 
> Same here.
> 
> > wds_find_device
> > wds_find_device: WDS from mac 00-02-6f-21-1a-28 not in current config,
> > returning NULL
> > [00][02][6f][21][1a][28][ff][ff][ff][ff][ff][ff][00][04][e2][80][7d][42]
> > wds_net_send_packet
> 
> Very same here : but then the MAC address starts with 00 04, so we have
> a somewhat bigger packet.
> 
> > Let me know what to do next,
> 
> 1/ Get rid of the wds-specific code in file islpci_eth.c, function :
> 
> int
> islpci_eth_transmit(struct sk_buff *skb, struct net_device *ndev)
> 
> This is vague... but every time you see a decision on wds_init (which is
> seems to be a global variable, or am i dreaming ? :) ), force the code
> to make as though wds_init was zero. Maybe the proper way to do this is
> to replace wds_init in the function by local_wds_init and set
> local_wds_init to zero. (so you'll be able to switch back to original
> behaviour with local_wds_init = wds_init).
> 

I don't think wds_init is being used at all ... At least I could not find
it. What I did was delete all the code between the #ifdef prism54 directives
for the islpci_eth_transmit function.

I also made sure debugging printk functions where enabled in this function
so I could look at the packets going out on each device. This way we can
make sure that they are not being modified on the way over to the neighbor
ap.

The results where mixed. I can see the packets on each device trying to go
out to the neighbors (ping and stp) but they never get there. They look well
formed though.

Connectivity with stations is now working. I can ping from my laptop and
even connect through ssh to the device when wds is turned on. This
connectivity is very slow, I don't know if it is related to all the logging
that is going on or if it is due to something else.

So, it seems that getting rid of all the prism54 code in this function made
it so that the broadcast packets don't get to the other devices over the wds
links.

> 2/ Make absolutely sure WDS is functionning. There is the risk that
> enabling WDS at the device level does nothing ; the tx/rx interface does
> not seem to change, for instance. But maybe one or your example already
> makes sure of this (for instance, if prism54 1/ and hostpad device are
> both access points).

To prove that it is working I did a simple test. Prism54 #1 was not linked
to the hostap device so on the log I could not see the stp packets from it.
I did a simple iwpriv eth1 00:04:e2:80:7d:42 and now I get these packets on
the Prism54 #1 device:

wdsadd 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]

So, I think that pretty much proves that wds is indeed working at the driver
level.

Furthermore, I think it is almost working. I initiate a ping from the hostap
device to the Prism54 #1 and here is the log from the prism54 #1:

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][04][e2][80][7d][42][08][06][00][01][08][00][06]
[04][00][01][00][04][e2][80][7d][42][c0][a8][0a][01][00][00][00][00][00][00]
[c0][a8][0a][03]
wds_net_send_packet
[ff][ff][ff][ff][ff][ff][00][04][e2][80][7d][42][08][06][00][01][08][00][06]
[04][00][01][00][04][e2][80][7d][42][c0][a8][0a][01][00][00][00][00][00][00]
[c0][a8][0a][03]
[00][04][e2][80][7d][42][00][02][6f][21][1a][28][08][06][00][01][08][00][06]
[04][00][02][00][02][6f][21][1a][28][c0][a8][0a][03][00][04][e2][80][7d][42]
[c0][a8][0a][01]

You can see the broadcast ping request and you can see the ping reply trying
to go out ... 

If I ping an arbitrary address from the hostap device I see don't see the
ping reply on the log. This means that the Prism54 #1 device is indeed
getting all the data on the ping request correctly. So the RX path seems to
be working correctly.

How does the driver know which interface to send the packet out through?
Does the kernel bridge code handle that? 

It seems that now that I removed the prism54 ifdefs from the transmit
function packets are not making to the neighbor wds devices. Before, they
would at least make it there malformed.

I also played with another parameter on the hostap device:

wds_type: WDS type bitfield
	0 = options disabled (default)
	1 = use broadcast RA (WDS frame destination) for broadcast and
		multicast frames
	2 = use AP client mode in 'Managed mode'
	4 = use standard compliant WDS (4 addr) frame also in Host

I usually set it to 4 to talk to commercial wds devices and all the tests so
far have been with this setting. When I set it to 2 it does seem to make a
difference, I can still see the stp and ping broadcasts on the prism54 #1.
However, when I set it to 1, I don't see any more packets in the Prism54 #1
log.

> 
> Moreover, i don't know how the device could do proper WDS without the
> additionnal information of which link to send the frames to... strange.
> 
> 3/ Test with other firmwares. Maybe WDS implementation is
> firmware-dependent

I did the test with 1.0.4.3 and 1.0.3.0 and it does not make any difference.

> 
> Luis, where did you get the information about WDS programming of the
> device ? -- maybe we should look there.
> 
> JB
> 
> --
> Jean-Baptiste Note
> +33 (0)6 83 03 42 38
> jean-baptiste.note at wanadoo.fr

Sergio