Tl dr: You can send your requests from an arbitrary port if you like, but it's not very useful. This is also true for the server, which emits traps and informs on a known, standard, predictable port not only so that you can configure your trap receiver and firewalls in a reliable way, but so that inform responses can be sent back to a known, standard, predictable port that you're listening on. This also allows us to set up simple firewall rules (though you can often get away without firewall rules for the return path, due to hole punching*). Otherwise you wouldn't see the responses. Typically the client will run its own listening "server" on port 162, send requests from there, and then it can receive responses there too. So, in order to get a response on a predictable port, you'll send the request datagram from a bound socket. There's no information in a SNMP packet that provides any alternative "return address" information. If you are expecting a response (which a client does if it's sending an SNMP Get or Set request), the only place the other end knows to send it is back where the request came from, i.e. However, even when run over UDP, SNMP does involve some two-way communication. SNMP is usually transmitted over UDP, so there is actually no "connection", and speaking technically the source port doesn't matter.
0 Comments
Leave a Reply. |