GoSNMPServer icon indicating copy to clipboard operation
GoSNMPServer copied to clipboard

TCP support

Open poornachandratejasvi opened this issue 1 year ago • 7 comments

Does GosnmpServer support TCP? in sample code, i see only UDP

poornachandratejasvi avatar Jan 08 '25 18:01 poornachandratejasvi

Yes, we currently only support UDP because the SNMP protocol is primarily based on UDP[1]. After a brief investigation, I found that RFC3430[2] mentions information related to TCP-based SNMP, but it is an experimental proposal that has not been widely adopted.

May I ask about your use case? Why do you need TCP-based SNMP?

[1] https://stackoverflow.com/questions/3565975/why-is-snmp-usually-run-over-udp-and-not-tcp-ip [2] http://www.faqs.org/rfcs/rfc3430.html

slayercat avatar Jan 09 '25 01:01 slayercat

Use case:

  1. In environments where guaranteed delivery of SNMP messages is critical.
  2. Large-scale networks with high latency or packet loss where UDP may not perform well.

poornachandratejasvi avatar Jan 09 '25 11:01 poornachandratejasvi

My personal recommendation is to revisit your use case and evaluate it in light of this information[1].

Unfortunately, the library does not currently support TCP functionality. If this is a critical requirement for you and you're interested, we warmly welcome your contributions to implement this feature!

[1]https://stackoverflow.com/questions/3565975/why-is-snmp-usually-run-over-udp-and-not-tcp-ip

slayercat avatar Jan 10 '25 01:01 slayercat

thanks for the response; i was able to find few latest rfcs for snmp tcp support

https://www.rfc-editor.org/info/rfc6353 https://www.ietf.org/rfc/rfc5953.txt?number=5953

poornachandratejasvi avatar Jan 10 '25 06:01 poornachandratejasvi

https://github.com/slayercat/GoSNMPServer/pull/38

Naveenrajp26 avatar Jan 17 '25 11:01 Naveenrajp26

I appreciate the contribution from @Naveenrajp26, and I would like to ask @poornachandratejasvi to confirm whether this TCP implementation meets your requirements.

Furthermore, upon initial review, this implementation does not account for the length field in the protocol. It needs to be supplemented based on RFC3430[1].

Additionally, if you could provide a unit test, I would be very grateful.

[1] http://www.faqs.org/rfcs/rfc3430.html

   It is possible that the underlying TCP implementation delivers byte
   sequences that do not align with SNMP message boundaries.  A
   receiving SNMP engine MUST therefore use the length field in the
   BER-encoded SNMP message to separate multiple requests sent over a
   single TCP connection (framing).  An SNMP engine which looses framing
   (for example due to ASN.1 parse errors) SHOULD close the TCP
   connection.  The connection initiator will then be responsible for
   establishing a new TCP connection.

slayercat avatar Jan 20 '25 05:01 slayercat

hi @slayercat , myself and @Naveenrajp26 are from same team.

poornachandratejasvi avatar Jan 20 '25 12:01 poornachandratejasvi