Dave, Thanks for the response. You got the issue correctly. That is what is happening here with atl east with one SNMP tool: > ( 1.2.3.4 : A ) -> ( 6.7.8.9 : B ) > > may result in a response > > ( 6.7.8.9 : C ) -> ( 1.2.3.4 : A )
My question is whether it is acceptable or outside of SNMP specifications. If we don't make an associated pair but just bind on ( 1.2.3.4 : A ), it might work. In fact, the tool is working fine with application snmptrap which synchronously wait on each packet it sends out. > I haven't checked the specs closely, but I believe the general expectation > of UDP-based service in general (not just SNMP), is that given a request > sent from source (1.2.3.4 port A) to (6.7.8.9 port B), then the response > will be sent from (6.7.8.9 port B) to (1.2.3.4 port A). I am not sure that it is true. I think UDP should not care what the sending port is. > ( 6.7.8.9 : B ) -> ( 1.2.3.4 : A ) "Yes" > ( 6.7.8.9 : X ) -> ( 1.2.3.4 : A ) "No" > > could be interpreted correctly, while > > ( 6.7.8.9 : C ) -> ( 1.2.3.4 : A ) "Yes" > ( 6.7.8.9 : D ) -> ( 1.2.3.4 : A ) "No" The example here is not correct as the kernel chooses an unique ephemeral port for sending. It should be > ( 1.2.3.4 : A1 ) -> ( 6.7.8.9 : B ) "Have I won the lottery?" > ( 1.2.3.4 : A2 ) -> ( 6.7.8.9 : X ) "Am I going to die?" > > then responses of > > ( 6.7.8.9 : B ) -> ( 1.2.3.4 : A1 ) "Yes" > ( 6.7.8.9 : X ) -> ( 1.2.3.4 : A2 ) "No" > II think if we create a socket with known ephemeral port and then can bind on it to receive responses. The responses are distinguished from dest address, msgid and reqids. > A single UDP-based transaction really must use a consistent > source/destination addressing quad (i.e. IP addresses and > UDP ports), in order to identify the transaction that it refers to. Definitely true for TCP. I am not sure whether that is true for UDP transactions. Thanks, Fatima On Thu, Feb 25, 2010 at 12:26 AM, Dave Shield <[email protected]> wrote: > On 24 February 2010 23:25, Fatima Peter <[email protected]> wrote: >> I think I spoke too soon without testing with other snmptools. The >> snmpd (from net-snmp) as well as our proprietary "trapd" gets the >> response for INFORM from the other hand only if the remote end uses >> the source-port of 162 like snmptrapd does. >> >> We tried with other snmptools ("Unbrowse Snmp" for example) which only >> guarantees that the udp dest port is the same as the udp orig port in >> the INFORM request. The products use ports like 1048 as udp source >> port and even snmpd does not get the response to INFORM messages >> coming from the other end. >> >> Would like to know whether this is the expected behavior and whether >> you have any suggestions for the issue. > > > I'm not sure I fully understand what you are saying here. > > I haven't checked the specs closely, but I believe the general expectation > of UDP-based service in general (not just SNMP), is that given a request > sent from source (1.2.3.4 port A) to (6.7.8.9 port B), then the response > will be sent from (6.7.8.9 port B) to (1.2.3.4 port A). > This allows the original application to match up responses with the > corresponding initial request. > > > I *think* what you're saying is that a request: > > ( 1.2.3.4 : A ) -> ( 6.7.8.9 : B ) > > may result in a response > > ( 6.7.8.9 : C ) -> ( 1.2.3.4 : A ) > > ? > I couldn't quote chapter and verse, but my immediate reaction is > that this is not valid. If nothing else, how can such an approach > handle two recipient applications on the same destination host? > > Given > > ( 1.2.3.4 : A ) -> ( 6.7.8.9 : B ) "Have I won the lottery?" > ( 1.2.3.4 : A ) -> ( 6.7.8.9 : X ) "Am I going to die?" > > then responses of > > ( 6.7.8.9 : B ) -> ( 1.2.3.4 : A ) "Yes" > ( 6.7.8.9 : X ) -> ( 1.2.3.4 : A ) "No" > > could be interpreted correctly, while > > ( 6.7.8.9 : C ) -> ( 1.2.3.4 : A ) "Yes" > ( 6.7.8.9 : D ) -> ( 1.2.3.4 : A ) "No" > > would leave me in a state of considerable uncertainty! > > A single UDP-based transaction really must use a consistent > source/destination addressing quad (i.e. IP addresses and > UDP ports), in order to identify the transaction that it refers to. > > But I don't know if that's what you mean here. > > Dave > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
