IEEE 802.11s Mesh: How are IP addresses are correlated to MAC addresses?

[thomascrisan]

I don't understand how IP addresses are correlated to MAC addresses when the mesh channel has a different MAC address to the br-lan device of the router.

To give an example, suppose I have a small MBSS of 10 stations, 192.1.1.1 to 192.1.1.10. I am logged in at 192.1.1.1 and ping 192.1.1.7. My current understanding is that the 802.11s HWMP uses ARP services to look up the MAC address and the ARP service will return the layer 3 MAC address used by the WiFi channel, which is typically the br-lan of the 192.1.1.7 device. The layer 2 MAC address of the mesh channel is not necessarily the same MAC address, so an ARP query is not returning the correct mesh MAC address needed by the 802.11s HWMP.

Because of my concern about this, I have assigned the same unique for both the br-lan and the 802.11s mesh channel for each router in the MBSS.

This is mostly guesswork on my part as I haven't been able to determine how the IEEE 802.11s is implemented in the OpenWrt software. Can anyone explain or show me where the IP - MAC address correlation is implemented in the OpenWrt software or perhaps the Linux kernel? I haven't been able to locate it.

[diogohvo]

Forget ARP.
If you want more low-level information about how each node creates an ISO L2 route tree, check the HWMP documentation.

There are two ways that a mesh discovers and tracks neighbors: On Demand, and Tree Building

On demand relies on p2p communications, using control messages to discover routes to other nodes.

Tree Building functions similarly to STP, where a root node tries to establish routes to all nodes.

There is a lot of information available in the documentation that should quell your concerns. If you do not have an institutional login, there is a document here concerning HWMP specs.

[thomascrisan]

Thank you for the reply. I looked over the second reference; I've unfortunately let my IEEE membership lapse so I couldn't review the first one. I probably need to explain my confusion a bit better as I don't think it's with the HWMP module.

When sending a ping command from one mesh station to another, how is the target MAC address looked up from the IP address to feed to the sending station's HWMP?

[diogohvo]

This is wireless comunication, not wired...
This is the data frame of a 802.11s packet:

The four address fields contain MAC addresses. Address 1 is the receiver address which defines the mesh point that has to receive the wireless address transmission. Address 2 is the transmitter address which defines the mesh point that sent this wireless data frame. Address 3 is the destination address which defines the final destination of this data frame. Address 4 is the source address which defines the source of this data frame.

The 16-bit long Mesh e2e Sequence Number is used to control broadcast flooding and to enable ordered delivery of mesh data frames.

Also important to note, mesh nodes discover each other automatically. They also react to changes in topology.

[thomascrisan]

Thank you for your reply; it's forced me to refine my question. I have a copy of the IEEE 802.11 specification and have looked at the various mesh data frames. My question concerns the bridge between layer 3 (IP world) and layer 2 (MAC world), which the IEEE specification defines as the role of the Station Management Entity (SME).

The (SME) in the IEEE 802.11 standard appears to have its functionality distributed across various components of the Linux wireless networking stack. The component I'm interested in would deal with layer management.

Referring to your example, Address1 is the MAC address of the receiving mesh point, so a ping command requires an IP to MAC address lookup. An IEEE 802.11s mesh station implemented in OpenWrt can have two different MAC addresses. One MAC address is defined in the /etc/config/network file for layer 3 and the other is defined in the /etc/config/wireless file for layer 2. Does the OpenWrt implementation of SME layer management have the ability to handle this or should the addresses be defined as one in the same?

[diogohvo]

A mesh network is different from a typical wireless network. Regular client devices cannot connect to the mesh network. Mesh nodes with two radios can participate in both the mesh network and provide AP functionality.

As such, two MAC addresses are in order.

@thomascrisan

One MAC address is defined in the /etc/config/network file for layer 3 and the other is defined in the /etc/config/wireless file for layer 2.

This I dont think is right. Can you provide context?

[bluewavenet]

@thomascrisan

My current understanding is that the 802.11s HWMP uses ARP services to look up the MAC address

Well your understanding is totally incorrect.

In your numerous other threads it was discussed at great length that the 802.11s mesh is totally, 100%, layer 2 and why interface mac addresses must be unique. It was also discussed that in OpenWrt, during the DSA migration, some devices did not set unique mac addresses for wireless interfaces and how this matters mostly in a mesh network and how it can be mitigated.

An 802.11s mesh (including its built in HWMP mac-routing protocol) knows nothing about, nor cares about, nor needs to know about layer 3 or higher data that may be carried on the mesh backhaul.

Once the mesh network/backhaul is established on the mesh interfaces of the meshnodes, nothing else is required for the nodes to be mesh peers. No IP (v4 or v6), no ARP, no NDP nor any other layer 3 protocol/management layer is required for the mesh backhaul to function. The functioning layer 2 backhaul is ready to carry any layer 3 protocol packets you care to use.

The mesh interfaces of the mesh nodes MUST all have unique mac addresses, as is expected in any network, otherwise duplicates will cause all sorts of issues with the mac-routing algorithms.

When you want to introduce a layer 3 network, for example ipv4, then we all know that in OpenWrt, the usual way to do this is to create a bridge interface and "bind" ipv4 to it, setting, or getting an ipv4 address and subnet mask. We also set (or have set for us by the system defaults), a unique mac address for the bridge.

In the simplest form of an ipv4 network, ARP is used to obtain the mac address that corresponds to the allocated ipv4 address you might want to communicate with. The layer 3 ipv4 stack will, once it has the target mac address, know the real, unique, identity of the device it wants to send its ipv4 packet to, via layer 2.

What if the device that has the target ipv4 address is on some other part of the layer 2 network? Easy, the packet is sent to all the interfaces that are part of the bridge.

How do we connect our mesh backhaul to our devices that want to communicate? That is done by creating a "mesh gate", done simply by adding the mesh interface to the bridge.

To get this far in our example, of course an ARP packet (a layer 2 packet) will have been broadcast into the layer 2 network and will only know the target is the other side of the backhaul if both devices are on mesh gates.

The mesh will know, from its mac address, where to send the packet.
You can view the mac-routing table using the mpp dump command available in iw

From this you will see "destination address" and "proxy node". Proxy node is the mac address of the mesh interface of the mesh gate that the target device is connected to.

[zekica]

All 802 standards are not Layer 3 standards. The only reference to Layer 3 is Ethertype, and you will not find any other reference to layer3 in these standards.

I suggest you first familiarize yourself with layer 2 bridges/switches, and especially the STP protocol before trying to understand 802.11s mesh. 11s mesh is a fair bit more complicated than STP, but concepts used in layer 2 bridges/switches will help you understand 11s much better.

For starters forget about IPv4, IPv6, IPX/SPX, NetBios, AppleTalk, PPPoE, PTP, HSR or any other layer 3 protocol, and focus on Layer 2.

11s mesh is completely transparent to Layer 3 protocols in the same way switches are.

[thomascrisan]

@diogohvo Thanks for your answers, they've helped me refine my conceptual model of how an IEEE 802.11 mesh works within OpenWrt. Regarding the two locations of the MAC address configuration file settings. The best I can do now is to suggest that you go to LuCI and set up a mesh channel. Under Advanced Options you will see an entry for MAC Address. This can be left blank, filled in with a valid MAC address, or set to 'random'. The settings are stored in the '/etc/config/network' file.

I appreciate all the answers, but they are not relevant to the question I asked, which was how does the IP address to MAC address lookup take place in the OpenWrt implementation, e.g. executing an IP ping command from one MBSS station to another.

I acknowledge that IEEE 802.11 is primarily concerned with layers 1 (the physical layer) and 2 (the data link layer) of the OSI model, but it does recognise that there is a need to coordinate between these layers and higher. so it loosely defines the SME (station management entity), which is a layer independent entity that resides in a separate management plane or "off to the side".

While topics such as paths and spanning tree protocols are interesting to learn about, I don't see how this addresses the mechanism for IP to MAC mesh lookup (a layer 3 to layer 2 transistion) and caching this layer 3 to layer 2 information for communication between stations within an MBSS.

I could speculate on how this might be achieved, but I was hoping to find someone who knew what was implemented in OpenWrt and could point me to the source code.

[_bernd]

For ipv4 it is arp and for ipv6 it's nhd.
80211s does not care. You can run any layer 3 shizzle which is supported by Linux and iproute2 if you compile it, if it should not already be included in the standard build....
But this was already answered in this thread....

[_bernd]

Addon, just in case you are not aware of it: ip [-4|-6] neighbor show

[thomascrisan]

Thanks, I'm aware of the command.

Okay, an arp request gets boradcast out on the MBSS and a station reply is returned. Why doesn't the information show up in the arp cache?

[_bernd]

Please show your terminal session...

[bluewavenet]

@thomascrisan

I appreciate all the answers, but they are not relevant to the question I asked,

Then I guess you failed to read my reply which, at great length, answered your specific question.

[thomascrisan]

Here's an example of a terminal session showing the arp cache after pinging some of the other mesh stations in the MBSS. None of the mesh channels are shown along with their associated unique MAC addresses.

# arp
IP address       HW type     Flags       HW address            Mask     Device
169.254.255.1    0x1         0x2         68:1c:a2:00:85:64     *        br-lan
192.168.1.28     0x1         0x2         f8:d0:27:34:74:42     *        br-lan
192.168.1.120    0x1         0x2         00:03:7f:ba:db:ad     *        br-lan
192.168.1.172    0x1         0x2         f8:59:71:3b:e1:f6     *        br-lan
192.168.1.239    0x1         0x2         e8:68:e7:8f:e6:e7     *        br-lan
1.1.1.1          0x1         0x2         68:1c:a2:00:85:64     *        br-lan
192.168.1.10     0x1         0x2         02:3c:78:a6:ba:10     *        br-lan
192.168.1.101    0x1         0x2         34:f6:4b:f4:57:04     *        br-lan
192.168.1.2      0x1         0x2         68:1c:a2:00:85:64     *        br-lan
192.168.1.153    0x1         0x2         00:57:c1:a7:8d:b1     *        br-lan
xx.xx.xx.xx      0x1         0x2         00:01:5c:76:46:46     *        wan
192.168.1.12     0x1         0x2         02:f9:aa:df:dd:12     *        br-lan
192.168.1.234    0x1         0x2         e8:68:e7:90:35:f4     *        br-lan
192.168.1.100    0x1         0x2         34:f6:4b:f4:57:04     *        br-lan
192.168.1.30     0x1         0x2         f8:d0:27:31:02:ae     *        br-lan
192.168.1.167    0x1         0x2         6c:33:a9:5a:5f:e8     *        br-lan
192.168.1.215    0x1         0x2         a4:ee:57:e5:f7:a6     *        br-lan
192.168.1.159    0x1         0x2         6e:87:a1:6e:24:23     *        br-lan
192.168.1.117    0x1         0x2         10:4e:89:53:52:5f     *        br-lan

[thomascrisan]

I was trying to be polite. My question was, if ARP is used to determine the correct MAC address when pinging to another station on the MBSS, why isn't the MAC address of the mesh channel in the cache? I don't see you answering that; the vast majority of what you wrote was a straw man argument against what you assumed I wrote.

I apologise if I expressed myself poorly and caused you to write a long reply you did not need.

[bluewavenet]

@thomascrisan

the vast majority of what you wrote was a straw man argument against what you assumed I wrote.

@bluewavenet

Once the mesh network/backhaul is established on the mesh interfaces of the meshnodes, nothing else is required for the nodes to be mesh peers. No IP (v4 or v6), no ARP, no NDP nor any other layer 3 protocol/management layer is required for the mesh backhaul to function. The functioning layer 2 backhaul is ready to carry any layer 3 protocol packets you care to use.

The mesh interfaces of the mesh nodes MUST all have unique mac addresses, as is expected in any network

@bluewavenet

The mesh will know, from its mac address, where to send the packet.
You can view the mac-routing table using the mpp dump command available in iw

From this you will see "destination address" and "proxy node". Proxy node is the mac address of the mesh interface of the mesh gate that the target device is connected to.

As a relatively simple technical description seems to be over your head, here is as simple list of actions for you to experiment with:

1. Check the mac addresses of your interfaces using ip addr
2. Do all interfaces have unique mac addresses?
3. If not, set unique addresses in the wireless config and restart
4. Check the output of ip neigh
5. Check the output of iw dev [mesh_interface_name] mpath dump
6. Check the output of iw dev [mesh_interface_name] mpp dump
7. Try pinging a remote node by its ipv4 address
8. Repeat 4, 5 and 6 above

Your original question was:

IEEE 802.11s Mesh: How are IP addresses are correlated to MAC addresses?

This had evolved to:

@thomascrisan

if ARP is used to determine the correct MAC address when pinging to another station on the MBSS, why isn't the MAC address of the mesh channel in the cache?

This is a more targeted question, but the answer is the same.
The mac address of the mesh interface is not involved in any way at layer 3.

Note: It appears that you choose not to take notice of any replies that you do not like or cannot get an LLM to repeat.

[thomascrisan]

I am going to have to appologize again and eat some crow. Given the number of responses that weren't hitting the mark for me, I must not have phrased my very question well and the answers were that were on the mark, I somehow did not grasp.

I had already run the various commands suggested some the responses, the result of those commands was staring me in the face as to the answer but I only became more frustrated. It wasn't until yesterday when I read this in reference to the HWMP: "In both cases, 802.11s provides a proxy mechanism to provide addressing support for non-mesh 802 devices, allowing end-points to be cognizant of external addresses" from here and it clicked for me. The ARP table provides the MAC address of a non-mesh device and the HWMP has essentially another table which relates this MAC address to the necessary MAC address of the associated mesh station.

IEEE 802.11s Power Save Modes Support Implementation for Linux

I went back and saw that @bluewavenet had given this answer in reply #7 in his second to last sentence: "You can view the mac-routing table using the mpp dump command available in iw", so I apologise and will mark it as solved.

Unfortunately I have one more comment to make. Bluewavenet: You were right to be frustrated with me, but I don't like being slandered by you, here or anywhere else. Your concluding remark is partially correct, I question just about everything (especially information from LLMs) and confirm things for myself before accepting information as true and repeating it to others as accurate.