Re: RFC: "-@" command line argument to set clientaddr per request/session

Bill Fenner <[email protected]>
Newsgroups gmane.network.net-snmp.devel
Message-ID <CAF4SogZ50BeXtVPXDByL8Doacss-XRGmeh+U=M4LfcHPvsNhkw@mail.gmail.com>
On Sun, May 6, 2018 at 4:33 PM, Robert Story <[email protected]> wrote:

> BF> The tests:
> BF> https://github.com/fenner/net-snmp/commit/
> 41be11b4e3ab93cda376bf044de2f77534b56518
> BF> (T180 and T181 fail. T181 is testing the new functionality in
> BF> 5.8, so, no biggie.  T180 tests functionality that worked in
> BF> 5.7.3.  T182 and T183 pass; this maybe makes the other failures
> BF> less bad since if a user wants this behavior they can configure
> BF> the session using trapsess instead of trap*sink).
> BF> (I think the "myip" perl script belongs in support, not in
> BF> fulltests/default/; I'll move it before i commit to the master
> BF> branch.)
>
> I'm going to skip these for rc1. What do we need to make the tests
> pass?
>

T182 and T183 should pass now.  T180 and T181 failures have the same root
cause: netsnmp_udpipv4base_tspec_transport() doesn't zero out the default
"161" port that netsnmp_sockaddr_in2() fills in.  Compare the code
in netsnmp_udpipv4base_transport() that's checking the clientaddr for
having a port, and zeroes it out if not (the "have_port" check).  There is
no similar code in netsnmp_udpipv4base_tspec_transport().

One plausible answer is to factor out the code in
netsnmp_udpipv4base_transport() (although I am dubious of
NETSNMP_DS_LIB_CLIENT_ADDR_USES_PORT code, and don't think that should be
copied to the tspec_transport() case).

  Bill

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.