Truncation of trap by snmptrapd with DisplayString ending in null

[Jason Baekey]

Hell Everyone,
I'm not sure whether this is a problem with snmptrapd or with the agent/mib declaration of the vendor. I am receiving a trap with the defined in the following MIB excerpt:

[Removed for clarity]

sessionAuthenticationTrap NOTIFICATION-TYPE
OBJECTS {
sessionAccessType,
sessionUserName,
sessionUserIpAddress,
sessionAuthFailure
}
STATUS current
DESCRIPTION
"Authentication Failure Trap is sent each time a user
authentication is refused."

[Removed for clarity]

sessionUserName OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..31))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The user name of the user logged-in."

[Removed for clarity]

The sessionUserName is transmitted to the trap station as a HEX STRING with a null character as the final character. Nothing after this string is logged or sent to a trap handler as the log excerpt shows below:

2007-09-16 14:37:32,UDP: [10.0.0.1]:161,10.0.0.1,0,sysUpTimeInstance = Timeticks: (647224900) 74 days, 21:50:49.00 snmpTrapOID.0 = OID: sessionAuthenticationTrap sessionAccessType = INTEGER: ssh(5) sessionUserName = STRING: TestByMe

I have attempted to simulate this using snmptrap to formulate my own trap and send it. Using both a regular string and a HEX string without a trailing null, it works fine. When the null is added, I get the same results as you see above. I cannot find any evidence that this should be the way it operates (references to valid characters in DisplayString in RFC 845 only state that null is no operation), but I am definitely not sure. Any help would be appreciated. Thanks.




_________________________________________________________________
Capture your memories in an online journal!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

[Dave Shield]

Post by Jason Baekey
I'm not sure whether this is a problem with snmptrapd or with the
agent/mib declaration of the vendor.
sessionUserName OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..31))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The user name of the user logged-in."
[Removed for clarity]
The sessionUserName is transmitted to the trap station as a HEX STRING with
a null character as the final character.

SNMP uses a length-value approach to representing strings.
It does not use the C-style trailing-NULL approach.

If you are receiving a sessionUserName varbind with the value
"dave\0" (including the trailing null), then this implies that the
user name of the user logged in is "dave\0" (including the trailing null)

Somehow, I doubt this is the case!

I would suggest that this is probably a bug in the agent implementation.
The sessionUserName varbind value should not include the trailing null
character.

Now it could be argued that snmptrapd should be able to handle
embedded null characters, and display them sensibly. But in
practise, NUL is not a character that you would ever expect to
find in a DisplayString value.

Dave

[Mike Ayers]

Behalf Of Dave Shield
Sent: Monday, September 17, 2007 1:02 AM
Now it could be argued that snmptrapd should be able to handle
embedded null characters, and display them sensibly. But in
practise, NUL is not a character that you would ever expect to
find in a DisplayString value.

True, but this should not prevent snmptrapd from correctly displaying varbinds which occur after the DisplayString with a NUL in it. I believe this was the OP's complaint.


Mike

[Dave Shield]

Post by Mike Ayers

Post by Dave Shield
Now it could be argued that snmptrapd should be able to handle
embedded null characters, and display them sensibly. But in
practise, NUL is not a character that you would ever expect to
find in a DisplayString value.

True, but this should not prevent snmptrapd from correctly displaying
varbinds which occur after the DisplayString with a NUL in it. I believe this
was the OP's complaint.

Logged in the Bug tracker (ID 1796886)

Dave