Ponieważ dzieje się to konsekwentnie, myślę, że najbardziej prawdopodobną przyczyną jest błąd w oprogramowaniu układowym routera, który powoduje, że albo nie upuszcza pakietu śledzenia (i wysyła raport „Przekroczono TTL”), kiedy powinien, albo wysyła go przed nim powinien. Oto przykład pierwszego problemu ze strony podręcznika traceroute BSD :
A sample use and output might be:
[yak 71]% traceroute nis.nsf.net.
traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 56 byte packet
1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms
[...]
Note that lines 2 & 3 are the same. This is due to a buggy kernel on the
2nd hop system - lbl-csam.arpa - that forwards packets with a zero ttl (a
bug in the distributed version of 4.3 BSD).
W tym przykładzie jest to drugi router, który ma błąd, a trzeci router jest wymieniony zarówno jako # 2, jak i # 3.
Z drugiej strony zastanów się, co by się stało, gdyby drugi router miał błąd, który powodował, że upuszczał pakiety, gdy TTL osiągnął 1 zamiast 0:
- Pakiet śledzenia wysłany z TTL = 1 jest zmniejszany do 0 na pierwszym routerze, który upuszcza go i zgłasza przekroczenie TTL, więc pojawia się jako przeskok 1. Wszystko dobrze tutaj.
- Pakiet wysłany z TTL = 2 jest zmniejszany do 1 na pierwszym routerze; następnie drugi router zmniejsza go do zera, upuszcza i zgłasza, a więc pokazuje się jako przeskok # 2. Znowu wszystko tutaj dobrze.
- Pakiet wysłany z TTL = 3 jest zmniejszany do 2 na pierwszym routerze; następnie drugi router zmniejsza go do 1, i błędnie upuszcza i zgłasza, a więc pokazuje się jako przeskok # 3.
Znów jest to drugi router, który ma błąd, ale w tym przypadku jest to drugi router, który jest wymieniony dwukrotnie (w przykładzie na stronie podręcznika jest to trzeci, który jest wymieniony dwukrotnie).