[prev in list] [next in list] [prev in thread] [next in thread] 

List:       net-snmp-bugs
Subject:    [ net-snmp-Bugs-1571945 ] notifications over non UDP/IPv4 transports
From:       "SourceForge.net" <noreply () sourceforge ! net>
Date:       2006-10-17 12:39:41
Message-ID: E1GZoEP-0000RJ-Bi () sc8-sf-web2 ! sourceforge ! net
[Download RAW message or body]

Bugs item #1571945, was opened at 2006-10-06 09:09
Message generated for change (Comment added) made by tanders
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1571945&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Juergen Schoenwaelder (nosuchname)
Assigned to: Nobody/Anonymous (nobody)
Summary: notifications over non UDP/IPv4 transports

Initial Comment:
We did run into a problem with net-snmp-5.4.pre1 when
we tried to use
the TCP transport for notifications. The snmptrapd
performs the new
access control check on incoming notifications. The
access control
check at some point in time calls
netsnmp_udp_getSecName() and this
fails because the format of the content of the
parameter opaque has
changed.

The TCP transport stores the old format while the UDP
transport now
uses a netsnmp_udp_addr_pair, which however is local to
the UDP
transport. So it seems unclear what the proper fix for
this is and we
need guidance (or even a patch) to solve this issue.

One option could be that every transport provides its own
netsnmp_xxx_getSecName() function and this would then
localize the
format of the opaque data passed around. Another option
could be to
share netsnmp_xxx_getSecName() functions between
similar transport,
e.g. have a netsnmp_ipv4_getSecName() function and a
netsnmp_ipv6_getSecName() function. But in this case,
the format of
the opaque data must be exported and agreed upon. There
might be other
options - but since you know this code much better than
we do, I
thought I first ask who you think is the right way to
handle this.

I meanwhile learned that net-snmp-5.4.pre3 is out but
from a quick
look at the diff, it seems nothing related to the
problem described
above has changed.

It seems that the netsnmp_udp_addr_pair has been
introduced in an
attempt to make sure that UDP/IPv4 response packets
somehow use
the "correct" IP address. It seems that this patch
ignores also
IPv6 and obviously kind of breaks the TCP-IPv4
transport since
the TCP/IPv4 transport uses the
netsnmp_udp_getSecName() function
(which either is a conceptual bug by itself or at least
a misnomer of
the function). See the thread "Make snmpd answer from
the correct IP
address".


----------------------------------------------------------------------

>Comment By: Thomas Anders (tanders)
Date: 2006-10-17 14:39

Message:
Logged In: YES 
user_id=848638

Temporary fix applied to CVS MAIN. Will appear in 5.4.pre4.
Leaving open, since we'll need to agree on a proper fix and
also fix the 5.[23].x branches.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1571945&group_id=12694

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Net-snmp-bugs mailing list
Net-snmp-bugs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-bugs
[prev in list] [next in list] [prev in thread] [next in thread]