snmp.time respective to retransmits

asked 2023-04-24 14:48:44 +0000

nfldson
1 ●1 ●2

updated 2023-04-24 14:53:44 +0000

My operational case is when capturing SNMP packets and if the server detects no/slow response (TO) it will retransmits the same request ID, application will ignore TO response and keep trying (max3) until a response within TO is received

Wireshark when displaying snmp.time associates all the delayed responses to the last transmitted SNMP get request associated to the request ID

packet 1 , id1 request get @ time 0 , snmp.time = - 30 seconds
packet 2 , id1 request get @ time +10 seconds , snmp.time = - 20 seconds
packet 3 , id1 request get @ time +20 seconds , snmp.time = ( no snmp.time as it is a get request )
packet 4 , id1 response @ time + 25 seconds , snmp.time = 5 seconds
packet 5 , id1 response @ time + 30 seconds , snmp.time = 10 seconds
packet 6 , id1 response @ time + 35 seconds , snmp.time = 15 seconds

I want (expect) packets 4-6 to have snmp.time (25,30,35)

Wireshark provide snmp.time to repeats get requests relative the last get request Wireshark provide snmp.time for responses (multiple) to last snmp get request

Is there a way to configure to display differently?

answered 2023-04-24 16:55:36 +0000

Chuckc
3023 ●6 ●610 ●20

rfc3416: Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)

However, in order to calculate the round trip time for transmission and processing of a request-response transaction, the application needs to use a different request-id value on a retransmitted request. The latter strategy is recommended for use in the majority of situations.

With a non-unique request ID in all requests and responses, how do you know the responses are not arriving out of order?

The value of the request-id field in a Response-PDU takes the value of the request-id field in the request PDU to which it is a response. By use of the request-id value, an application can distinguish the (potentially multiple) outstanding requests, and thereby correlate incoming responses with outstanding requests. In cases where an unreliable datagram service is used, the request-id also provides a simple means of identifying messages duplicated by the network. Use of the same request-id on a retransmission of a request allows the response to either the original transmission or the retransmission to satisfy the request.

edit flag offensive delete link

Comments

There would be no guarantee , application is tracking responses. Also if packet(s) were lost , would result in some RT not being able to be calculated. In this case response is delayed to server and can not track specific RT in csv export.

nfldson ( 2023-04-25 22:36:31 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

snmp.time respective to retransmits

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

snmp.time respective to retransmits edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

snmp.time respective to retransmits