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

[Jon-Olov Vatn]

Thanks for the response!

23 April 2003 Jean Tourrilhes wrote:
> 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".

I can agree that this was not a nice way to do it; it was just the
simplest way for me to make it work, since I am not experienced 
at kernel hacking. (A small comment: the only information that actually
needed to be transferred via the ioctl was the MAC address of the
STA; the rest of the packet is static and could as well be created
in the kernel code. Even so, this is probably 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

Thanks for the hint about tun/tap. I'm not familiar with it yet.
What I really would like to do is
* to have the packet distributed to all interfaces of the bridge
  except the interface on which the STA resides
  (e.g., on eth0 and on some WDS-link, but not back on wlan0)
* the bridge within the remove any stale entries of the STA that
  it might have in its learning cache, e.g., it may believe that
  the MAC address of the STA still resides on the "eth0" side
  of the AP)
Maybe tun/tap can solve this or parts of it, but I am not able
to judge that. 

> 
> 	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 can agree that this is not nice, but I am not sure if you dislike
that the AP sends a packet on behalf of the STA or if you dislike that
the I suggested to implement this feature by putting in as input on
"wlan0" rather than as output on "eth0" as done earlier, or both.
Anyhow, the reason for the AP to send the link-layer update packet on behalf
of the STA comes from the draft IAPP protocol (802.11f-D3). A cleaner
way would probably be to require the STAs to send this packet themselves,
but this is not the way it was suggested in the draft.

> 	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.

Since I am not experienced enough I cannot say if this would work.
If I would connect it to br0 my fear is that it would go out on
every interface assocaiated with the bridge, including the interface
on which the STA resides (e.g. wlan0). (It can be discussed if this
is a big problem or not.)
Using SO_BINDTODEVICE might very well work (once again, I'm a newbie
and can't judge) if I then can specify that a copy of the packet should
go to all interfaces but the interface where the STA resides (wlan0).

Regarding information about the problem that I am trying to solve,
the posting 
http://lists.shmoo.com/pipermail/hostap/2003-March/001946.html
may give some more hints.

> 	It may look a bit more complex now, but the cleaner semantic
> and the additional control will pay in the long run.

Of course it is better to do it "right" from start. I'm just afraid
that I am not well suited to do it. I will look more deeply at your
hints, but if anyone else would like to step in and do it she/he is
most welcome!

Once againg, thanks alot for you feedback!!

BW /J-O