Question on HostAP, IAPP link layer update and bridge station cache (fwd)

[Jean Tourrilhes]

Jon-Olov Vatn wrote :
> 
> As far as I could see I got no reaction on this email.

	Probably missed it.

> > > Now to my question. If one would like to fix this problem, I can see
> > > two different approaches, and I wonder what way to go:
> > > * "Interaction between hostAP and briding code"
> > > * "Inserting link layer update frame in wlan0 input queue"
> > =
> 
> > I think it would be useful to implement more interaction between =
> 
> > Host AP and bridging code.
> 
> Before I saw your answer I started to work on a solution according to
> my second alternative, i.e., upon a successful (re)association the
> hostapd would build the IAPP link layer update packet and then to
> ask the hostap driver (by ioctl) to treat this packet as if it
> came in on the wlan interface (put it in an sk_buff and call netif_rx).

	Yuck ! This is very ugly. The ioctl is a management API, I
prefer to keep data out of it. And this is clearly a "layer
violation".
	If you really want to do that, the clean way to do it :
		o Get yourself familiar with tun/tap operation
		o Add tun0 to the bridge
		o send your packet on /dev/tun0

	But, we are still left with a layer violation. In my mind, no
local process should "impersonate" Rx network traffic. You should
always do thing explicitely, because that's the best way to have a
clear semantic and avoid nasty side effects.
	I don't understand enough of what you are doing, and didn't
follow the discussion, but it seems to me that if you open a standard
raw socket on the bridge device (br0), you should get the same
result. If you want more control, use the SO_BINDTODEVICE option so
you can send the packet on the interface you want (wlanXXX). You can
use netlink to discover interfaces.
	It may look a bit more complex now, but the cleaner semantic
and the additional control will pay in the long run.

	Regards,

	Jean