On Tue, Oct 10, 2006 at 08:15:29PM +0100, Dave Shield wrote: > R1) TCP notifications
> This seems to be the biggy - at least it's the only entry > categorised red. > Do we agree that it needs to be fixed before release, or should it be > re-graded yellow. If it stays red, who understands the problem/code? Well, I think I do. It is just unclear how you want the problem to be solved. Right now, it seems that NET-SNMP tries to match the transport address when it converts a community string to a security name. Let me try to explain... The com2sec directive can be used to specify that a community is mapped to a security name if the request comes from a given source. The implementation of the check is of transport specific, at least for IPv4 transport, IPv6 transports, Unix domain transports. In fact, the udp and tcp transports share the same function to implement the check as do the udp/ipvp6 and tcp/ipv6 transports. What broke recently was the format of the opaque data structures that are used, due to an attempt to ensure that responses are returned from the IP address to which a request was send. So here are the options as I see them: a) Simply revert the patch that broke the TCP transport and declare success. b) Move the relevant functions for IPv4 transport and IPv6 transports out of the internals and define proper data structures so that the functions can be shared between IPv4 transports and IPv6 transports. c) The opposite of b) would be to require that each transport provides its own check function in order to localize the problem. The proper way to do this would be to add a additional function pointer to the netsnmp_transport structure and to call the ..._getSecName() function indirectly using this function pointer. (The only problem I see is that vacm_check_view would need a handle for the netsnmp_transport structure, but I assume this is somehow possible.) d) Rewrite the whole thing to better comply with RFC 2576 which actually uses a reference to the target MIB to select the valid transport addresses (but this would be a majore rewrite and potentially change the configuration syntax, so this is surely out of scope for getting a release out of the door). As you might guess, we are prototyping alternate secure transports and from that perspective, option c) would be the most convenient one since in our case the security name is not at all related to a community string and so having the flexibility to provide our own ..._getSecName() function for these transports would be much appreciated. /js -- Juergen Schoenwaelder International University Bremen <http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
