Practical case: The most common wireless bridging problems in industrial networks!

The cases shared in this issue are issues related to industrial wireless networks.

1. Background introduction
The customer is a system integration company (Company A), which specializes in automated integration products such as AGV robots and PLCs. Recently, we undertook an automated workshop project for a top company in the logistics industry. The wireless network deployment of this project was completed by Party A's IT, which purchased a certain W AC+AP solution. Company A used a certain M wireless client+PLC solution to bridge the SSID provided by Party A's IT to access the core network to enable communication between the PLC and the host computer. It was found that the host computer could not communicate with the wireless client and PLC at all.

The simplified on-site topology is as follows:

The planning configuration is as follows:

Fool-style network, the host computer IP address is: 192.168.100.200/24
The IP of the wireless bridge is 192.168.1.103/24, and the IPs of the wired PLC attached to it are 192.168.100.105 and 106 respectively.
2. Basic analysis
The IT staff discovered an interesting phenomenon: the MAC address corresponding to the connected wireless client was correct, but the IP kept changing:

Other wireless phones, laptops, etc. are all normal.

Therefore, the customer suspects that the communication abnormality is related to the IP address corresponding to the MAC jumping around. So why is this happening? Let’s start our analysis!


3. Troubleshooting analysis
Step 1: Explain the reason why the MAC of the wireless client (module) is fixed but the IP jumps

First, let me explain that this phenomenon is normal and related to the "wireless communication address format". It is divided into three addresses and four addresses. It is a method of wireless bridging (relay). Examples are as follows:

In the above topology, if WDS uses three-address communication, then the ARP table entries in PC-A are as follows:


PC-A can ping 101 and 102, but their corresponding ARP entries are all the same MAC address, that is, Router B's 54:89:98:D0:62:16. In other words, under three-address bridging, PC-A cannot learn the real MAC of PC-B.

If WDS uses four-address communication, then the ARP table entries in PC-A are as follows:

Similarly, PC-A can also ping 101 and 102, but it can be seen that in PC-A's ARP entry, the four-address communication can learn the real MAC corresponding IP addresses of Router B and PC-B.

Step Two: Analyze Connectivity Failures



From the actual topology of the site, the host computer cannot ping the wireless client and the connected device. It prompts "Unable to access the target host". The essential reason is that the target ARP cannot be learned. Combined with packet capture, you can see:

So there are only 2 possibilities:

The ARP broadcast is not forwarded to the wireless by a certain W AP;
The ARP broadcast was forwarded by a W AP but no unicast response was received from the wireless client.
What to do next? It's easy to say, just use the comparison method to see whose problem it is.

Step 3: Find a small router for comparison testing

(1) Test topology



PC—small router))((wireless client—downloading device

(2) Test results

The PC can ping the wireless client and connected devices;
ARP learning is a MAC address (wireless client) corresponding to multiple IP addresses (wireless clients and connected devices)
The comparison is obvious. It is unlikely that an infinite client will not respond to ARP after receiving an ARP query. Therefore, it can only be forwarded to a W AP that has ARP wireless forwarding restrictions.

Step 4: Find a small router for comparison testing




According to experience, this limitation is caused by "broadcast & multicast packets to unicast" enabled in the default traffic template of a certain W AC. Under three-address wireless bridging, ARP broadcast cannot be normally converted into unicast and delivered to the wireless client:

It is very common in wireless bridging scenarios such as AGV and PLC. Huawei and H3C have this function, so please pay attention to this point when doing projects or maintenance in the future.

4. Solution
Turning off the "Multicast & Broadcast to Unicast" function for ARP solves the problem. The host computer can communicate with the PLC as expected: