The RFC compliant authentication failure trap does not include the source
address of the offending host. Cisco has enhanced this and includes the
offending host's address in the authentication failure trap. Other vendors
may also do this. Why would it be difficult for an agent to grab the IP datagram header of the UDP-encased snmp get or set request that came in with the wrong community string? That header contains the source IP address in bytes 13 through 16.
Dell??? Why not pass this information? It seems it is available with the powerconnect switch managment interface...
Yea, I get that now, it is the OS that discards the packet containing the source address info. Does anyone know of anyway to determine this source address short of trying to capture the packet prior to the OS dumping it?
That sounds similar to a situation we've experienced where an HP ProCurve switch (3400/6400) will send out what looks like an authentication trap, but it is a specialized one. In our case, we could see something very enterprise specific (check the OID of the trap itself in whatever tool is showing you the trap that arrived). We could see the source ip in snmptrapd.exe (part of net-snmp -- see http://www.net-snmp.org). In our case, we had configured a trap destination in the HP switch so it would send traps to a pc running snmptrapd -Le (or something close to that, from memory). However, we had used the CLI of the HP switch to turn OFF authentication trap sending, but that of course does not affect other than standard authentication traps. We are asking HP to help us turn off this specialized trap.
Interestingly, the trap was being generated because a different PC, running HP OpenView Network Node Manager (NNM) was trying to discover devices but used an incorrect community string when talking to the HP switch. Discovery apps are one reason I'd normally turn off any authentication traps on any device, at least by default.
SusanDOT
5 Posts
0
February 16th, 2006 17:00
The RFC compliant authentication failure trap does not include the source
address of the offending host. Cisco has enhanced this and includes the
offending host's address in the authentication failure trap. Other vendors
may also do this. Why would it be difficult for an agent to grab the IP datagram header of the UDP-encased snmp get or set request that came in with the wrong community string? That header contains the source IP address in bytes 13 through 16.
Dell??? Why not pass this information? It seems it is available with the powerconnect switch managment interface...
Susan
tester25
626 Posts
0
February 21st, 2006 16:00
SusanDOT
5 Posts
0
February 21st, 2006 17:00
TIA
Susan
tester25
626 Posts
0
February 21st, 2006 18:00
acarwile
6 Posts
0
May 22nd, 2006 04:00
Interestingly, the trap was being generated because a different PC, running HP OpenView Network Node Manager (NNM) was trying to discover devices but used an incorrect community string when talking to the HP switch. Discovery apps are one reason I'd normally turn off any authentication traps on any device, at least by default.
Hope this is of use.
Alan