[Ns-developers] bridging and wifi

[Gustavo Carneiro]

2008/8/25 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

> hi,
>
> I started trying to implement wifi bridging so, I have, naturally, a
> couple of questions. Here is the basic scenario I am trying to test:
>
>  Lan      Wifi
>
>  0  1  2 ********* 3
>  |  |  |
>  -------
>
> Node 2 is bridging lan to wifi. Node 1 is generating traffic towards
> Node 3 so, I expect that traffic to be transparently bridged from lan to
> wifi.



> For simplicity, let's say that wifi network is adhoc.


This is an assumption with serious implications.  I don't think this would
ever work, conceptually, with wifi in adhoc mode because adhoc mode frames
only use two addresses.  It has to be in infrastructure mode, because then
frames have 3 addresses.


> Let's go
> through the scenario.
>
> 1) node 1 sends ARP request macsrc=mac1, macdst=broadcast on lan
> 2) node 2 receives ARP request, bridge learns that mac1 is located on
> lan0, forwards broadcast to all interfaces, except incoming one.
> 3) node 2 sends wifi broadcast macsrc=mac1, macdst=broadcast
> 4) node 3 receives wifi broadcast, sees ARP request macsrc=mac1, sends
> reply ARP reply (unicast), macsrc=mac4, macdst=mac1.
> 8) wifi device on node 3 sends unicast frame, waits for wifi ACK
>
> The problem, here is that no one is ever going to generate the wifi ACK
> for this unicast frame: node 2 will probably receive the ARP reply
> correctly, forward it back to node 1 through the bridge, but it will
> never be able to send a wifi ACK to node 3 because it has no idea that
> it should do this. wifi ACKs are generated only for unicast frames
> targetted at _oneself_ and node 2 does not know that it is the target of
> the unicast frame because its own address is not equal to the
> destination of the unicast frame.
>
> At this point, I got a bit stomped and went back to some serious wifi
> spec reading and thinking but I still don't really know how that is
> expected to work. Gustavo, do you have any idea ?


I think I have an idea.

As I mentioned before, wifi has to be in infrastructure mode, adhoc won't
work (incidentally trying to do bridging in Linux with cards in adhoc mode
is a mistake I often used to make in the past).

The 802.11 frame has a total of four addresses, which have the following
meaning in infrastructure mode (this table comes from somewhere deep in the
802.11 standard):


  /*
   *  To DS    From DS   Address 1    Address 2    Address 3    Address 4
   *----------------------------------------------------------------------
   *    0        0       Destination  Source        BSSID         N/A
   *    0        1       Destination  BSSID         Source        N/A
   *    1        0       BSSID        Source        Destination   N/A
   *    1        1       Receiver     Transmitter   Destination   Source
   */

The ARP response, as transmitted by node 3, is of the type ToDS=1, FromDS=0,
therefore Address 1 is the BSSID (AP netdevice MAC), Address 2 is mac3,
Address 3 is mac1, and Address 4 is not used.  The Access Point (node2) will
receive a frame whose BSSID is itself and so will send a Wifi ACK back to
the source (Address 2 == mac3).

At this point, the promiscuous receive callback in node2 will send back to
the BridgeNetDevice the original source and destination, i.e. Address 2 and
3.  Likewise, when the AP (node2) sends a frame being bridged from node 1 to
node 3, via the new SendFrom API, it should consider the ToDS=0, FromDS=1
line in the table above, and so in this example Address1=mac3,
Address2=mac2, Address3=mac1.

I hope this helps.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert