[SNMP4J] udp packet overrides for TTL (time to live)

[Frank Fock]

Hi Syed,

SNMP4J does not set the TTL by default and never for retries.
So it seems to be some OS or JRE issue.

Best regards,
Frank

Am 04.02.2013 20:52, schrieb Ali, Syed F:
> Hi,
> Does SNMP4j override the (OS's) default time to live value on outgoing packets?
> I have observed a wireshark capture where an identical GET request (with identical request ID) is retried 61 times in 20 ms. UDP does not guarantee delivery / retransmit of messages in the protocol, so any retransmission, in theory, has to be done in the application layer. In the wireshark capture, I noticed that in each of these 61 retires, the TTL / Time To Live on the packet in Internet Protocol layer is decremented by 1. So it starts off with a value of 61 and keeps going until you get to 0, after which the retrasmission of the packet stops.
> Note that these 60 retransmissions are not a result of the timeout / retry value. We use retries = 2 and timeout = 3000 milliseconds / 3 seconds. So after three seconds, we observe another batch of 61 identical requests in 20 ms, and so on.....
> If snmp4j never overrides default TTL values on outgoing packets, then it must be some OS-level or Java platform-dependent issue that is causing the packet-level retransmission with a decrement of the TTL. I would think that enabling snmp4j debug will help identify if the retransmit is possibly coming from snmp4j layer.
>
> Thanks,
> Syed
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j

-- 
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax:   +49 7024 8688231