Ethereal-users: Re: [Ethereal-users] ethereal FDDI void freme from tcpdump capture
> I'm using the tcpdump bundled with the operating system, details below.
It's broken in the way I suspect it was. Digital UNIX's raw packet
capture mechanism puts 3 bytes of padding in front of FDDI frames in
order to neatly align the FDDI payload on a 4-byte boundary.
The standard libpcap from tcpdump.org (and, dating as far back as the
0.4 libpcap release from LBL, previous versions of the standard libpcap)
strip that off before handing it to applications, so tcpdump and
Ethereal don't see the padding, and thus don't write it to the capture
file.
Digital UNIX's tcpdump, however, is either so old it doesn't have
libpcap, or has a libpcap that doesn't do that stripping, either because
somebody mistakenly thought it was A Feature, Not A Bug, that it wasn't
doing the stripping, or didn't realize that it was a problem, or because
it's really old code from before somebody realized it was A Bug.
So its capture files have 3 bytes of padding in front of each FDDI
frame.
This means that its FDDI capture files not only can't be read by
Ethereal, they can't even be read by standard tcpdump! They also can't
be read by other tools that handle libpcap-format files. (Ethernet
captures don't have this problem.)
This may explain the problem I saw ages ago, as, ages ago, we used FDDI
a lot here at NetApp, and the capture I couldn't get standard tcpdump to
read may have been an FDDI capture.
I'd suggest capturing with Tethereal, or with standard tcpdump from
tcpdump.org (built with standard libpcap from tcpdump.org), instead.
> Here are some sample stack traces and details of the tcpdump executable.
>
> # dbx ethereal.v19.vanilla core.ethereal.v19.van.s1021.0
> dbx version 3.11.10
> Type 'help' for help.
> Core file created by program "ethereal.v19.van"
>
> signal Segmentation fault at [rdconvertbufftostr:6
> +0x3a8,0x12016a128] Source not available
> (dbx) where
> > 0 rdconvertbufftostr() ["packet-radius.c":6, 0x12016a128]
> 1 rd_value_to_str() ["packet-radius.c":6, 0x12016a3d8]
> 2 dissect_attribute_value_pairs() ["packet-radius.c":6, 0x12016ae34]
> 3 dissect_radius() ["packet-radius.c":6, 0x12016b2e8]
Hmm. I'll look at the RADIUS dissector to see if it's being
insufficiently paranoid about the data being handed to it.
