☰

¿Existe alguna razón legítima para que haya paquetes de ping duplicados en un solo salto?

tag-icon • tag-icon networking wireless-networking router ping
¿Existe alguna razón legítima para que haya paquetes de ping duplicados en un solo salto?

I'm doing a single hop to a WiFi AP. There's only one AP serving this SSID, and I'm pinging it directly, and getting hilarity like:

64 bytes from 192.168.1.0: icmp_seq=87 ttl=32 time=112.501 ms
64 bytes from 192.168.1.0: icmp_seq=87 ttl=32 time=129.409 ms (DUP!)
64 bytes from 192.168.1.0: icmp_seq=87 ttl=32 time=243.003 ms (DUP!)

(our connection to it also dies all the time.)

Is there some logical explanation? (The normal, "got duplicated by the network" stuff doesn't seem to hold well over a single link. Personally, I think it's time we retire this Netgear, and I'm thinking of using this as proof.)

(at the moment, too, this is happening consistently. I'm getting pretty close to 100% of my pings having duplicates over several minutes of continuous pinging.)

Respuesta1

As @FrankThomas noted in a comment:

192.168.1.0 is not a valid unicast IP address so you are either running pinging with a -b for broadcast, or you should have gotten the message Do you want to ping broadcast? Then -b instead of ping results. What OS are you using (the output looks like linux)? Either way, unless you are pinging a unicast address, you run the likelihood of recieving multiple responses for each datagram you send

I was in fact pinging the broadcast address, when I intended to be pinging the router. (Routers are usually, and in my case, the .1 address, not .0 address.) The multiple results are likely the multiple hosts.

La última nota es que no recibí el mensaje "¿Quieres hacer ping a la transmisión?" advirtiendo que Frank nota; Creo que es una pingadvertencia de GNU, mientras que estoy en OS X, así que supongo que BSD pingno genera eso.

información relacionada