I discovered a bug in the ecom100. When replying to an icmp echo packet,
it does not reset the ttl in the reply packet.
This makes things like traceroute (using the icmp option) not work right.
You only decrease ttl when forwarding a packet. When replying to a packet, ttl
should be reset to a high starting value.
boot 4.0.165
os 4.0.1473
$ ping -t 5 192.168.22.1
PING 192.168.22.1 (192.168.22.1) 56(84) bytes of data.
64 bytes from 192.168.22.1: icmp_seq=1 ttl=1 time=69.6 ms
$ ping -t 15 192.168.22.1
PING 192.168.22.1 (192.168.22.1) 56(84) bytes of data.
64 bytes from 192.168.22.1: icmp_seq=1 ttl=11 time=70.1 ms
[ -t sets the ttl in the outgoing packet. Note that the ttl in the
reply is dependent on the ttl in the outgoing packet. Actually, it
just uses the remaining ttl for the reply, which is wrong ]
# traceroute --icmp 192.168.22.1
traceroute to 192.168.22.1 (192.168.22.1), 30 hops max, 60 byte packets
1 (192.168.225.254) 0.856 ms 0.857 ms 0.913 ms
2 (192.168.227.237) 68.157 ms 73.306 ms 77.479 ms
3 * * *
4 * * *
5 (192.168.22.1) 91.714 ms 93.531 ms 97.067 ms
See how is interacts wrongly with traceroute.
Other host engineering ethernet devices such as EBCs handle this properly.
I think that H2-ECOMs also handle this properly.
Perhaps it is just a feature of this version, or it is specific to H2-ECOM100s.
I could do more testing on other devices, but I will wait and see how you respond.
Keith