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

[Sergio Ammirata]

Hello Jean-Baptiste,

> -----Original Message-----
> From: Jean-Baptiste Note [mailto:jean-baptiste.note at wanadoo.fr]
> Sent: Thursday, April 07, 2005 7:53 PM
> To: Sergio Ammirata
> Cc: 'Luis R. Rodriguez'; 'Denis Vlasenko'; 'Jouni Malinen'; prism54-
> devel at prism54.org
> Subject: Re: Strange problem with wds in prism54
> 
> 
> Hello Sergio,
> 
> It seems that i can rely on you to check on more things, so i'll take
> advantage of this if you don't mind :)

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

> 
> > wds_net_send_packet
> > wds_find_device
> > wds_find_device: WDS from mac 01-80-c2-00-00-00 not in current config,
> > returning NULL
> 
> Well, either this mac address is meaningfull for the device, or, well,
> it looks like the beginning of a frame in softmac mode... Maybe a trap
> response ? -- or rather an rx annex, that may be present in WDS mode,
> but is not checked for.
> 
> The only way to know would be to display the *whole* buffer.
> 
> can you add, after
> 
> *** islpci_eth.c:
> islpci_eth_transmit[441]       wds_dev = wds_find_device( skb->data, wdsp
> );
> 
> the following,
> 
> /* no sure about the memcmp check, remove if nothing appears */
> if ( (wds_dev == NULL) && (memcmp(skb->data,ndev->broadcast,6) != 0) )
> 	{
>                 /* dumps the frames which have no wds entry and are
>                 non-broadcast. I think they are frames with an rx_annex */
> 
> 		DEBUG(SHOW_BUFFER_CONTENTS, "\nrx %p ", skb->data);
> 		display_buffer((char *) skb->data, skb->len);
> 	}
> 
> so that we can see if the WDS frames with this strange mac really are
> WDS frames ?
> 

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

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 first packet (ff:ff:ff:ff:ff:ff) has the mac address of my laptop (the
client wireless device) on the second octect (00:02:6f:21:1a:22)

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.

> > wds_net_send_packet
> > wds_find_device
> > wds_find_device: WDS from mac ff-ff-ff-ff-ff-ff not in current config,
> > returning NULL
> > wds_net_send_packet
> 
> OK, those ones are more easily explained : I don't think they can come
> from the WDS links, and they seem to be the ones explicitly directed to
> the main device.
> 
> This is not a problem, as those packets are "by default" sent to the
> primary interface. Yet we should certainly distinguish the
> ff:ff:ff:ff:ff case which is "standard" from the other case which does
> not seem to be... (i'll do the patch when i get time).

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?

> 
> In order to go farther, i'd really appreciate a complete dump of the
> packets starting with the strange MAC...
> 
> Thanks for all the work
> 
> JB
> 

Hope this helps,

Sergio