Glenn Mansfield Keeni
glenn at ...1085...
Fri Oct 11 04:08:02 EDT 2002
I did think twice or thrice before deciding to do the
patch that way. We do not want to keep ourselves in sync
with the net-snmp command line options. That way every time
there is a change - the snort-conf's will have to change.
The move is towards a simpler interface that works for the
snort-conf snmptrap activation line. The present version
came out after several iterations and I really like it the
way it is. [ Most of the other trials would not work for
this reason ot that. Default port is not right/Colon
separated port number is not accepted in ucd-snmp etc.]
Regarding the IPv6 addresses and transport domains
the discussion has been on for some time on the net-snmp
list and we did prepare a patch to have IP-addresses in
braces. That probably got lost. Will dig that up again
and send it to the list.
Andrew Hood wrote:
> Glenn Mansfield Keeni wrote:
>> The net-snmp support for the snortSnmp plugin ran into
>> some rough weather - the port specification convention has
>> changed, the community specification convention has changed
>> and the default port selection logic seems to be buggy in the
>> present net-snmp release (5.0.5).
>> A patch for the spo_SnmpTrap plugin has been readied - this
>> will work with minimal changes to your snort.conf. There is only
>> one change - if you are using v2c then the community MUST be
>> specified using the '-c <community>' option BEFORE the
>> snmptraplistener address. [Community after the snmptraplistener
>> address will not be accepted]
>> The comments in the snort.conf and the explanation in the
>> doc/README.SNMP have been updated to that effect. The patch is
>> available on
> Having looked at the patch, I don't think this is the way to go. Rather
> than duplicate the function of snmp_parse_args it would be much cleaner
> to bite the bullet and force people to fix their snort.conf. They
> already have to fix the community string for SNMP version 1 or 2c.
> "udp:hostname.some.org:snmptrap" should be a legal destination string
> for net-snmp. Do you really want to duplicate the code to allow for all
> possible parses?
> The issue of not being able to deal with colon separated IPv6 addresses
> should be referred to the net-snmp list. They will need to deal with
> this. I will submit this question to them
> It is quite possible net-snmp will find some new use for the p option.
> Maybe it will need to be reused to cope with IPv6.
More information about the Snort-devel