Ethereal-dev: Re: [Ethereal-dev] patch for wiretap lib: read EyeSDN USB S0

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Rolf Fiedler" <Rolf.Fiedler@xxxxxxxxxxxxxx>
Date: Fri, 13 Feb 2004 15:22:44 +0100
From: Guy Harris <guy@xxxxxxxxxxxx>
Subject: Re: [Ethereal-dev] patch for wiretap lib: read EyeSDN USB S0
format
>On Feb 11, 2004, at 6:29 AM, Rolf Fiedler wrote:
>
>> I added a wiretap for the EyeSDN USB S0, a ISDN probe/call recording
>> device attached to the PC using USB.
>
>Checked in, with some changes to get rid of unused variables, fix up
>some of the error returns, and return an error string for
>WTAP_ERR_BAD_RECORD (the APIs for wiretap have changed since 0.10.0a,
>so that for WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
>WTAP_ERR_BAD_RECORD, an error string is returned; that string is
>displayed in the alert box for those errors, making it easier for the
>user to see the error and report it).
>
>There's one unused-variable warning left:
>
>eyesdn.c:86: warning: `eyesdn_rec_magic' defined but not used

Yes, the magic for a record is only 0xff (single byte) and I must have put that
in literally without referencing the array.

>Are there flag characters at the *beginning* of frames, or just at the
>*end* of frames?
Only at the beginning. The frame header contains a length, so it is always possible to find
the end of a frame. The last frame ends with EOF

>Also, is the data in the record *header* escaped?
>"parse_eyesdn_rec_hdr()" uses 'esc_read()" to read the header.
Yes, the frame structrure is escaped completely. The only 0xff bytes in the file
demark frame starts (one could count the 0xff and see how many frames are in
the trace)

>And, in "parse_eyesdn_rec_hdr()", the record header is read into an
>array of "char", and the bytes from it are extracted into numbers;
>that's done by casting the bytes to "unsigned long", but I think that a
>byte with the 8th bit set will be sign-extended on most if not all
>platforms (are there any compilers for modern UNIX systems where "char"
>is unsigned?), and then the resulting sign-extended integer will be
>cast to "unsigned long", so a byte of 0xff will, I think, be turned
>into 0xffffffff on platforms with 32-bit longs and 0xffffffffffffffff
>on platforms with 64-bit longs.

> Is that what's intended?

No, that should be an array of unsigned char. I did not notice this during testing,
it is a leftover from the toshiba wiretap module that I started from.
Maybe I was lucky/unlucky to not have byte with most significant bit  set during my tests.
Thanks for finding this.
Should I fix it or is it already done in CVS?

Rolf

______________________________________________________________________________
... and the winner is... WEB.DE FreeMail! - Deutschlands beste E-Mail
ist zum 39. Mal Testsieger (PC Praxis 03/04) http://f.web.de/?mc=021191