Ethereal-users: Re: [Ethereal-users] SNMP octet-strings with non-text data not displayed properl
On Dec 16, 2003, at 12:30 AM, Mads Nielsen B (ST/DXD) wrote:
We often trace SNMP packets and have seen that "OCTET STRINGS" that
contains non-readable data (array of bytes) not are displayed proberly
(not only in 0.10.0).
Unfortunately, whatever version of the SNMP library you're using (UCD
SNMP or Net-SNMP) apparently doesn't check for printable characters
when displaying octet strings, and either the MIB doesn't give a hint
as to whether to display it as text or binary (perhaps there's no MIB
item for it at all) or the library isn't handling that hint. Ethereal,
when linked with an SNMP library, doesn't do the work of displaying
values - it leaves it up to the SNMP library.
I don't remember whether it should be fixed in net-snmp or in the
dissector (probably the later).
The latter relies on Net-SNMP to do the work, so the only fix in the
dissector would be to stop using Net-SNMP or either
1) somehow get enough information from Net-SNMP to figure out how to
do the display work ourselves (e.g., find out if there *is* a MIB entry
and:
if there is, assume Net-SNMP will do the right thing;
if there isn't, display the octet string as text if it's all
printable and as hex if not)
or
2) somehow force Net-SNMP to do the right thing.
Also I noticed that OID indices sometimes are displayed in a strange
way (near EOL):
Object identifier 1: 1.3.6.1.2.1.10.94.1.1.14.1.14.500001
(ADSL-LINE-MIB::adslAtucChanConfInterleaveMaxTxRate.'.') <= what does
"'.'" mean?
Object identifier 3: 1.3.6.1.2.1.10.94.1.1.2.1.2.500001
(ADSL-LINE-MIB::adslAtucInvVendorID.500001) <= OK
Again, that's done by Net-SNMP, not by Ethereal, so you'd have to see
why Net-SNMP is doing that.
Also a few ideas to the wish-list (it is soon Christmas;-):
- It could be nice with a default Ethereal file extension when saving
traces (at least on Windows). I have seen people use "*.cap, *.eth,
*.log, *.unameit". We decided to stick to "*.cap" and told "BillG" to
associated this extension with Ethereal.
Unfortunately there are *several* packet analyzers that use ".cap" -
Microsoft Network Monitor and the Windows version of the Sniffer
software, which use it for *different* file types. (That's one
advantage of the scheme used on some UNIX+X11 desktops, where they
don't just use the file extension, they use a mechanism derived from
that of the UNIX "file" command and look at the beginning of the file
to infer the file type - that way
1) you often don't *need* to give the file an extension in order to
for the file manager to recognize it - on my KDE desktops at home, I
don't bother giving PDFs a ".pdf" suffix, but it recognizes them just
fine;
2) it can handle files of different types even if those types share a
suffix.
Perhaps the ideal would be a scheme in which files had an Internet
media type as an attribute, and that were used; however, that'd require
that it be reasonably easy to register media types, and wouldn't work
on file systems that don't support attaching attributes to files -
you'd have to use some scheme to put the attribute in some file on the
side, but if you move or copy the file from outside the desktop, that'd
get lost.)
I'd prefer not to make the problem worse by using ".cap" for
libpcap-format capture files. WildPacket's ProConvert calls them
".dmp" files:
http://www.wildpackets.com/products/proconvert/files
(note all the file formats that have ".cap!), but I could easily
imagine that ".dmp" is used for some other file format.
At home, I tend to use ".pcap" as I'm usually *not* using the KDE file
manager to browse those files, which makes it convenient to use a
suffix. It also has the advantage of not being 3 characters, meaning
that a lot of Windows software developers would probably avoid it, so
we'd be less likely to collide with some other use of it. (It'd also
peeve people who think Windows file suffixes should *always* have 3
characters, but that's only a minor reason for me to like it. :-))
