Thu May 19, 2022 10:44 am
So indeed for you it occurs as well on a WiFi link? But the WiFi is a local indoor access point for mobile devices?
In my case it occurs on a point-to-point link, which indeed as mentioned above is used in 4-address mode, but I wasn't aware that this is a factor.
Note that any radio protocol unavoidably has to deal with transmission errors, and so there is a L2 protocol in WiFi that sends data from A to B, and then B sends an ACK back to A to indicate it has received the data. When A does not receive the ACK within some time limit, it will re-send the same data (which it has kept in a local buffer).
When designing such a protocol, it is important to add some unique ID (e.g. a serial number) to each packet, and put that in the ACK as well, so the sender knows what the ACK is confirming, but also the receiver can see that the same data has been received twice. If this is not properly implemented, the scenario could be that B has received the data from A just fine (and forwarded it on to the remote network) but A did not receive the ACK packet that B sent. So A will re-transmit the data, and now B could just take that as new data, forward it on to the network, and send the ACK again. That can repeat until either A receives the ACK or exceeds its maximum number of re-transmissions.
I would expect that this has been covered in the 802.11 specs, and "should not happen", but it certainly looks like there is an issue like this, as this duplicated ping reply is quite often seen. I have no idea if it is an oversight in the spec or an implementation error in the device.
Note that during normal use, this often is not an issue as e.g. in TCP there are sequence numbers in the packets as well, and any duplicate packet is discarded inside the TCP layer and not forwarded to the application. UDP traffic normally is made resistant to duplicate packets because this whole issue can occur end-to-end anyway, so UDP request/responses are normally stateless and/or also have some built-in sequence number.
So this issue manifests itself "only" when doing operations like PING. However it can never be ruled out that there is some badly coded UDP application that acts funny.