WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#26 2018-Apr-09 10:20:49

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 4901

Re: 802.11 reference design as 'generic' radio

It is impossible for PC A to send an IP packet to PC B over the air (even with static ARP entries) because the 802.11-ness of the system needs to learn the MAC addresses involved.

This is not accurate. The IBSS code implements bi-directional layer-2 bridging. PCs connected to IBSS nodes can exchange packets in both directions once the IBSS nodes have associated. You don't need to hard-code ARP entries (shouldn't, in fact) or change any configuration on the PCs for this to work.

The diagrams in the user guide show how wired/wireless addresses are handled during (de)encapsulation.

The code in CPU high seems very hard coded for these 802.11 features, i.e., header formats, FCS, etc. Is there an easy way to remove this behaviour so bytes received on the ethernet interface are sent verbatim out the radio? Alternatively, is there an "easy" way to create a bridge_mac_high application from scratch/template?

This is possible but not easy; changing frame formats and per-node address handling would require rewriting large chunks of code in CPU High and Low. Further, this modification would severely limit MAC protocol options (i.e. if wireless packets don't have the wireless Tx/Rx addresses, how can a MAC protocol ACK/re-transmit?).

Offline

 

#27 2018-Apr-20 04:42:17

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

Ah, my apologies for being unclear. I omitted mentioning that I'm trying to send unidirectional traffic only, from PC A to PC B, over a pair of W3s running the modified wlan_mac_high_ibss (as described earlier in this thread). The encapsulation/de-encapsulation process requires ARP to work (as you stated) so intermediate nodes can "spoof" MAC address correctly, and a bi-directional channel is therefore necessary.

In general, I'm experimenting with varying concepts such as relaying, combining, mesh topologies, etc., and as such, require a simpler MAC which can be easily modified. The OFDM Reference Design provides this, but then has an older, less sophisticated (and no longer updated) PHY.

I've now managed to get the 802.11 design to work for my unidirectional scenario but this has been messy (as you mentioned). Additionally, I'm unsure if my modifications may result in other issues/instabilities, etc.

As a general comment, a bridge-type application comprising of _high_bridge_ and _low_nomac_ should be "easy" to create from scratch (as opposed to trimming an existing application like _high_ibss_) and would open up the same hardware for much wider experimentation possibilities.

--vick

Last edited by vick (2018-Apr-20 04:43:52)

Offline

 

#28 2018-Apr-20 10:37:16

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 4901

Re: 802.11 reference design as 'generic' radio

If your topology only supports unidirectional wireless communication you can bypass the ARP handshake with hard-coded ARP entries on the PCs. These hard-coded entries must match the ARP entries that would occur normally if wireless communication were bidirectional.

For IBSS nodes, wired-wireless bridging works by substituting the local PC's MAC address with the IBSS node's wireless address (illustrated here). The (admittedly terrible) ASCII art below illustrates the resulting ARP tables for a 2-node IBSS network:

Code:

     PC 1               PC 2
IP:  10.0.0.1           10.0.0.2
MAC: AA-AA-AA-AA-AA-AA  BB-BB-BB-BB-BB-BB

     W3 Node 1          W3 Node 2
MAC: XX-XX-XX-XX-XX-XX  YY-YY-YY-YY-YY-YY


Topology:

     |-- W3 Node 1 --|              |-- W3 Node 2 --|
PC 1-|--IBSS.ETHA    |) <wireless> (|    IBSS.ETHA--|-PC 2
     |---------------|              |---------------|

ARP Tables:

PC 1:
10.0.0.2 YY-YY-YY-YY-YY-YY

PC 2:
10.0.0.1 XX-XX-XX-XX-XX-XX

Offline

 

#29 2018-Apr-20 16:15:42

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

Thanks for the nice "graphical" description for a workaround :-)

I can't help but wonder if defining static ARP entries on PC1 and PC2 would help. If we consider traffic going only from PC1 to PC2, then based on the ARP tables shown at the end of your drawing:

a. PC1 would generate ethernet frames, to be sent to Ether_Dst YY:YY:YY:YY:YY:YY. Would W3Node1 pick these up since its own Ether MAC is XX:XX:XX:XX:XX:XX? Is it operating in promiscuous mode perhaps?

b. More critically, if the ethernet frame did make it over the air to W3Node2, why would W3Node2 forward it out to PC2? How does W3Node2 know to change Ether_Dst from YY:YY:YY:YY:YY:YY to BB:BB:BB:BB:BB:BB?

I would've thought that for this to work we'd also have to update the ARP table (equivalent) on the W3 boards. The encapsulation procedure implies there must be some sort of ARP-like learning mechanism in place for this MAC translation to be possible, which is bidirectional in nature.

Unfortunately I'll only be able to test this workaround next week, but thought I'd post my doubts now nonetheless, and perhaps get some confirmation from the list.

--vick

Offline

 

#30 2018-Apr-23 11:26:56

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1158

Re: 802.11 reference design as 'generic' radio

vick wrote:

a. PC1 would generate ethernet frames, to be sent to Ether_Dst YY:YY:YY:YY:YY:YY. Would W3Node1 pick these up since its own Ether MAC is XX:XX:XX:XX:XX:XX? Is it operating in promiscuous mode perhaps?

In order to be transmitted over Ethernet, the only requirement the IBSS places on received wireless frames is that address_3 matches the BSSID of the IBSS network. So yes, it's promiscuous in that any node belonging to your ad hoc network will produce a wired frame on any reception of a wireless packet intended for someone on that IBSS network.

vick wrote:

b. More critically, if the ethernet frame did make it over the air to W3Node2, why would W3Node2 forward it out to PC2? How does W3Node2 know to change Ether_Dst from YY:YY:YY:YY:YY:YY to BB:BB:BB:BB:BB:BB?

I would've thought that for this to work we'd also have to update the ARP table (equivalent) on the W3 boards. The encapsulation procedure implies there must be some sort of ARP-like learning mechanism in place for this MAC translation to be possible, which is bidirectional in nature.

The de-encapsulation only stores one address: the address of the host PC connected to the node. It saved this address during encapsuation before overwriting it with the wireless MAC address of the kit. When de-encapsulating and sending an ethernet frame, it only replaces the destination MAC address with the saved stored MAC address if the received wireless frame had a receiver address matching the node. Otherwise, it the Ethernet frame's destination MAC address is an unmodified copy of the wireless frame's receive address.

So, in summary:

- PC 1 believes it has a MAC address of AA-AA-AA-AA-AA-AA and believes that PC 2 has a MAC address of YY-YY-YY-YY-YY-YY.
- PC 2 believes it has a MAC address of BB-BB-BB-BB-BB-BB and believes that PC 1 has a MAC address of XX-XX-XX-XX-XX-XX.
- A hypothetical PC 3 that is wireless traffic on the IBSS believes that PCs 1 and 2 have MAC addresses of XX-XX-XX-XX-XX-XX and YY-YY-YY-YY-YY-YY respectively. This is true regardless of whether this PC is using a third WARP kit to promiscuously sniff the traffic on the IBSS network or whether the PC is directly a member of the ad hoc network with it's own WiFi.

Offline

 

#31 2018-May-01 01:31:19

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

Thanks Chris, I guess this clarification answers my Question a. - W3Node1 would pick up wired packets from PC1 with destination MAC YY:YY:YY:YY:YY:YY and forward them over the air, even though its own wired MAC is XX:XX:XX:XX:XX:XX.

But i think there's probably still some confusion here (very likely on my part) on what happens at the other end. In my scenario, I only have uni-directional traffic from PC1 to PC2 via the two W3 boards (my PC2 is simply listening on a UDP socket/port). Nothing travels in the opposite direction; neither over wire, nor over air. Based on this:

chunter wrote:

The de-encapsulation only stores one address: the address of the host PC connected to the node. It saved this address during encapsuation before overwriting it with the wireless MAC address of the kit. When de-encapsulating and sending an ethernet frame...

how does the above happen? How does W3Node2 know that PC2 with MAC BB:BB:BB:BB:BB:BB is on its wired interface since PC2 never transmits anything?

Based on my limited understanding, it would appear that for encapsulation/de-encapsulation to function, there must be bi-directional communication at some point, to facilitate an ARP-like learning process on the W3 boards. That would seem to be the only way the statement "The de-encapsulation only stores one address: the address of the host PC connected to the node." above could hold. W3Node2 needs to know that all wireless IBSS packets received needs to be remapped to destination ether MAC BB:BB:BB:BB:BB:BB and sent out the wired interface - and this must surely only be possible if it received traffic in the opposite direction from PC2 at some point.

If the above is true, then my silent listening-only PC2 will never receive UDP, or any packets, from W3Node2 (unless they have a destination MAC of FF:FF:FF:FF:FF:FF I guess), right?

--vick

Offline

 

#32 2018-May-01 09:13:15

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 4901

Re: 802.11 reference design as 'generic' radio

how does the above happen? How does W3Node2 know that PC2 with MAC BB:BB:BB:BB:BB:BB is on its wired interface since PC2 never transmits anything?

This is a good point - the IBSS de/encapsulation code requires the attached PC generate at least one Ethernet packet after the Ethernet link comes up. The IBSS code uses the source address from this Ethernet packet to update the wired address it stores (wlan_mac_eth_util.c : wlan_eth_encap()).

It's been our experience that every PC generates traffic when the link comes up, typically the OS doing service discovery/advertisement, gratuitous ARP announcements, DHCP resolution, etc. Any of these packets will have the PC's addresses as the source address and will update the IBSS node's stored address. In our IBSS demos we use static IP address but do *not* hard-code ARP entries. This leads to the PCs running the normal ARP process which ensures every node generates some early traffic. Once addresses are resolved traffic can flow in arbitrary directions among the PCs.

Offline

 

#33 2018-May-03 04:41:52

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

Thanks for the confirmation Patrick and everyone, and for the detailed explanation in this thread. I now have a better understanding of how the encapsulation/de-encapsulation mechanism works, especially in relation to attached hosts on the wired interface.

murpho wrote:

It's been our experience that every PC generates traffic when the link comes up, typically the OS doing service discovery/advertisement, gratuitous ARP announcements, DHCP resolution, etc

As a side-note, I can mention that I typically use FreeBSD on my PCs. A base installation configured with static IP addresses and ARP entries behaves very taciturnly, "speaking only when spoken to" or when necessary. This behaviour simplifies networking experimentation significantly, but may impede mechanisms hoping to leverage on an opportunistic learning algorithm.

--vick

Offline

 

#34 2018-May-03 09:34:20

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 4901

Re: 802.11 reference design as 'generic' radio

A less "chatty" OS is a good idea for experiments. It looks like FreeBSD still sends a gratuitous ARP when the Eth/IP interface comes up. In theory this should suffice to update the de/encapsulation address mapping in the IBSS code.

One way to know for sure would be to add a print to the Ethernet handling code any time the "eth_sta_mac_addr" variable is updated. In wlan_mac_eth_util.c : wlan_eth_encap():

Code:

...
// Save this ethernet src address
memcpy(eth_sta_mac_addr, eth_src, 6);
memcpy(eth_src, get_mac_hw_addr_wlan(), 6);

// New print - displays MAC address of attached Eth device:
xil_printf("Updated eth_sta_mac_addr to %02x:%02x:%02x:%02x:%02x:%02x\n", eth_sta_mac_addr[0], eth_sta_mac_addr[1], eth_sta_mac_addr[2], eth_sta_mac_addr[3], eth_sta_mac_addr[4], eth_sta_mac_addr[5]);

...

Edit: you wouldn't want to leave this print enabled in a real experiment - it would print (i.e. add significant overhead) on every Ethernet Rx event.

Offline

 

Board footer