Re: IF_BRIDGE problem on RELENG_6

From: Peter Carah <pete_at_altadena.net>
Date: Fri, 22 Sep 2006 16:26:33 -0400
Andrew Atrens wrote:
> 
> I'm surprsied this worked for you in hostap <--> client
> 
> I've heard that it can work in adhoc <--> adhoc if both nics are in promiscuous
> mode.
> 
> The issue as I remember it is that the 80211 header has three addresses in it.
> 
> On the client side -
> 
> one address is used for bss
> one address is used for sender (client) mac, and
> one address is used for the ap mac
> 
> The problem with bridged packets is that the sender mac in the wless packet gets
> set to the 'src' mac of the packet being bridged.  When the ap side gets this packet it
> doesn't recognise the mac, indeed it thinks that the packet has come from an
> unauthenticated/unassociated station.
> 
> Packets being sent by the ap are okay, because the 3 address header looks like
> 
> one address is used for the ap bss
> one address is used for the src mac
> one address is used for the dest mac
> 
> The whole WDS thing, whenever it's supported utilises a 4 address header and so
> should support what you are doing.
> 
> Most commercial wless bridges do some kind of mac nat or when used with a single
> computer use a mac cloning scheme.
> 
> In my case I introduced another IP type and add a simple 2 address header
> 
> Andrew.
> 

Both Sam and the man page claimed that it worked with the ath ports in hostap
mode, and indeed it did till a couple of days ago.  Now it doesn't, I need to
revert some change but don't know just what the change was.  The IP layer in
wlan is supposed to pick the right src mac when shoving the packet into the
stack.  I've never seen any mac nat used with any AP I've ever seen.  (packets
on the wire side show up with exactly the pair of macs I'd expect, and the real
(other side of ap) dest mac shows in the packets on both sides of the radio
link.  Indeed I haven't snooped the radio itself.  Sam probably knows much more
about this than I do, however...)

-- Pete
Received on Fri Sep 22 2006 - 18:27:14 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:00 UTC