The problem of bridging a wireless adaptor..

M. Grabert xam
Tue Aug 3 01:46:11 PDT 2004

On Tue, Aug 03, 2004 at 10:14:38AM +0300, Jouni Malinen wrote:
> On Mon, Aug 02, 2004 at 12:39:18PM -0700, Christopher Dobbs wrote:
> > Standard bridging does not work.  I know I have tried just about 
> > everything that I can to make it work.
> Former statement does not automatically follow from the latter one..
> Standard bridging (assuming it means something like bridging at layer 2)
> does indeed work, if it is used in modes that the IEEE 802.11 standard
> allows to send packets with different source addresses (i.e., AP
> ("Managed") mode or WDS links).

Might this not be (theoretically) possible to do in adhoc mode or
as a client?

I suppose s.o. could tweak hostap (client) driver to fake/behave like
multiple wireless lan cards.
Then, if you are able to pretent that you have/are a multitude of
wlan cards/clients, you would be able to implement some kind of bridging.

You would not be able to integrate it in the current linux bridging
implementation, thus duplicate efforts. Furthermore, you'll break
a lot of other networking stuff in the kernel: eg. you could not use
ebtables, you would have to patch iptables, the routing stuff etc ...

> > I am therefor working on a software package that will alow a sort of 
> > bridging over the wireless adaptor by tunnleing the bridge through the 
> > wireless.

'Tunneling' ?
Does that mean that you would have to have (at least) two hosts, all using
hostap drivers that offer this 'bridge tunneling' capability?

Or do I get something wrong here?

At least don't get *me* wrong, the idea is neat.
But I really don't see the point, since the same (=bridging) can be 
done in a much saner way and it is already working:

just use hostapd and the standard linux bridging functionality.

> > Also if  Jouni Malinen is interested this could become a standard part 
> > of hostapd. (If it is proven to work correctly)
> I do not think hostapd should have anything to do with normal fast-path
> data packet processing, so I do not see how this would be part of
> hostapd.

I'm not a hostap developer, and even I fully agree with that statement. 


More information about the Hostap mailing list