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 > [email protected] > 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 _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j
