Is anyone aware of a hard maximum on trap length? One person has
mentioned a 675 character limit that is dictated by the maximum size
of a UDP datagram? Can anyone confirm or deny?
I'm working with a vendor trying to get a more Netview-friendly trap
format defined for an application. The problem is that in response to
malformed trap varbind security exploits, Netview's security efix is
replacing all non-alphanumeric characters other than the dot (.) with
an underscore (_). This makes information text like "threshold 90 <=
100" read "threshold 90 __ 100" . It has also impacted some data
packing for this vendor who uses a | as a field delimiter in one of
their trap varbinds that is packed with specific TEC info. On the
NetView server, we have a script that splits that varbind on the | and
sends a nice tidy postemsg to TEC using variou fields packed into that
varbind.
Unfortunately, with the efix, the script breaks since the field
delimiters are all replaced with underscores. I'm also attempting to
minimize security exposure by limiting the number of
"additionalLegalCharacters" we need to add to the NetView server, and
clearly the | is among the more dangerous. I'm considering proposing
an unlikely alphanumeric sequence like Aa0aA as a field delimiter,
but using a longer alphanumeric string may run us into maximum trap
length limitations..and hence the question.
I'm not faulting Tivoli on this by any means--the underlying root
cause is that SNMP is not secure, and that any device can send a
(possibly malformed, shell-escape-laden) trap to a management console
and that its varbinds might make their way into a shell program.
TIA for any information you have on the maximum length of an SNMP trap
received by netview. If the limit is higher than 675 characters,
then we have a good chance of picking an unlikely alphanumeric field
delimiter for this vendor without hitting a trap length limitation.
Best Regards,
--
|