m |
m |
||
| Line 5: | Line 5: | ||
It means the reply packet is a duplicate. ICMP responses contain a sequence number. Sometimes you'll actually get more than one reply with the same sequence number. This is usually caused by faulty networks. Wireless networks often rely on re-sending packets if they don't get proper verification, and if the first one actually worked, the re-send will be a duplicate. In normal usage duplicates are discarded. In ping replies they are noted because they tell you something about how the network is functioning. For example, if you are getting 100% duplicates some fault detection mechanism is likely broken. | It means the reply packet is a duplicate. ICMP responses contain a sequence number. Sometimes you'll actually get more than one reply with the same sequence number. This is usually caused by faulty networks. Wireless networks often rely on re-sending packets if they don't get proper verification, and if the first one actually worked, the re-send will be a duplicate. In normal usage duplicates are discarded. In ping replies they are noted because they tell you something about how the network is functioning. For example, if you are getting 100% duplicates some fault detection mechanism is likely broken. | ||
| + | EXAMPLE 1: | ||
64 bytes from 10.0.0.254: icmp_seq=5 ttl=64 time=1.90 ms | 64 bytes from 10.0.0.254: icmp_seq=5 ttl=64 time=1.90 ms | ||
64 bytes from 10.0.0.254: icmp_seq=5 ttl=64 time=2.84 ms (DUP!) | 64 bytes from 10.0.0.254: icmp_seq=5 ttl=64 time=2.84 ms (DUP!) | ||
| + | |||
| + | EXAMPLE 2: | ||
| + | 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=23.1 ms | ||
| + | 64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=26.1 ms | ||
| + | 64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=26.2 ms (DUP!) | ||
| + | 64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=21.5 ms | ||
| + | 64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=21.5 ms (DUP!) | ||
| + | 64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=21.5 ms (DUP!) | ||
''man ping: Duplicates are expected when pinging a broadcast or multicast address, since they are not really duplicates but replies from different hosts to the same request.'' | ''man ping: Duplicates are expected when pinging a broadcast or multicast address, since they are not really duplicates but replies from different hosts to the same request.'' | ||
It should be stated that public internet hosts usually are configured to discard echo requests to broadcast and multicast addresses to prevent smurf attacks - this is why you hardly ever see it happen. | It should be stated that public internet hosts usually are configured to discard echo requests to broadcast and multicast addresses to prevent smurf attacks - this is why you hardly ever see it happen. | ||
Latest revision as of 21:09, 12 July 2024
Why am I seeing DUP! when using ping on a linux machine with WiFi adapter?
It means the reply packet is a duplicate. ICMP responses contain a sequence number. Sometimes you'll actually get more than one reply with the same sequence number. This is usually caused by faulty networks. Wireless networks often rely on re-sending packets if they don't get proper verification, and if the first one actually worked, the re-send will be a duplicate. In normal usage duplicates are discarded. In ping replies they are noted because they tell you something about how the network is functioning. For example, if you are getting 100% duplicates some fault detection mechanism is likely broken.
EXAMPLE 1:
64 bytes from 10.0.0.254: icmp_seq=5 ttl=64 time=1.90 ms 64 bytes from 10.0.0.254: icmp_seq=5 ttl=64 time=2.84 ms (DUP!)
EXAMPLE 2:
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=23.1 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=26.1 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=26.2 ms (DUP!) 64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=21.5 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=21.5 ms (DUP!) 64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=21.5 ms (DUP!)
man ping: Duplicates are expected when pinging a broadcast or multicast address, since they are not really duplicates but replies from different hosts to the same request.
It should be stated that public internet hosts usually are configured to discard echo requests to broadcast and multicast addresses to prevent smurf attacks - this is why you hardly ever see it happen.