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