I have some cases where I ping a device from the mikrotik terminal and I get 3-4 times the ping reply.
What could that mean? It looks weird but I don’t know where to start looking.
What do you mean ?
You have loss of ping replies ?
No every second I get for example 4 replies and the statistics are also like that…
3 pings, 12 replies, lost -400% (something like that)
1 192.168.40.170 56 128 7ms28us
1 192.168.40.170 56 128 7ms342us
1 192.168.40.170 56 128 7ms353us
1 192.168.40.170 56 128 7ms361us
2 192.168.40.170 56 128 14ms467us
2 192.168.40.170 56 128 14ms798us
2 192.168.40.170 56 128 14ms835us
2 192.168.40.170 56 128 14ms844us
3 192.168.40.170 56 128 19ms432us
3 192.168.40.170 56 128 19ms470us
3 192.168.40.170 56 128 19ms526us
3 192.168.40.170 56 128 19ms583us
4 192.168.40.170 56 128 5ms895us
4 192.168.40.170 56 128 6ms24us
4 192.168.40.170 56 128 6ms90us
4 192.168.40.170 56 128 6ms289us
sent=5 received=20 packet-loss=-300% min-rtt=4ms508us avg-rtt=10ms431us
max-rtt=19ms583us
To be honest its the first time i see this.
Do you get the same result if you ping any other external host for example ?
I see that when pinging over WiFi links (admittedly using equipment from the competitor).
I think the protocol used at low level on WiFi is sometimes duplicating the data when the link is good in one direction and not so good in the other.
The 4-MAC problem on Wi-Fi…
What does that mean ?
Config? What are you pinging from where through what?
If some device have WDS active (for other competitors is called: Universal Repeater, Repeater, Extender, etc.),
enable the 4 MAC address mode for simulating "bridging" between interfaces...
ah, sorry for my english.......
@rextended thanks for your answer…
Also seen this problem over ubiquiti links, and when using MAC PING
I have plugged a grandstream gwn7664 to test because I was having nightmares with the WapAC.
At first I thought that it would be an MTU issue.
Is there a solution?
I have a feeling that it doesn't work as expected
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.