ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] Serial infrared (SIR) [PATCH]

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

From: Shaun Jackman <sjackman@xxxxxxxxx>
Date: Thu, 17 Jun 2004 11:00:04 -0700
On Thu June 17, 2004 03h11, Guy Harris wrote:
> On Thu, Jun 17, 2004 at 12:03:59AM -0700, Shaun Jackman wrote:
> > What follows is a patch to add serial infrared (SIR) decoding to
> > Ethereal. It is used, for example, by two instances of Palm OS
> > Emulator (Pose) to communicate using IrDA.
>
> Should that be put in its own plugin dissector, or should it be added
> to the "plugins/irda" directory?  (It looks as if IrDA runs atop it,
> rather than it running atop lower-level IrDA protocols.)

There's no reason why it shouldn't move in with the IrDA plugin. Yes, IrDA 
does run on top of SIR.

> > Now a couple of notes. I believe the checksum is the same as that in
> > PPP. This common code could be factored out.
>
> If so, it should probably go into a "crc16.c" file, with a "crc16.h"
> header, and called both by the PPP dissector and the SIR dissector;
> "crc16.c" would be added to the DISSECTOR_SUPPORT_SRC macro in
> "epan/Makefile.common".

Can someone that knows these directories (and platformness) better put 
this patch together?

> > I've tested this as a plugin.
>
> It would have to be added to the "plugin API" stuff to work on Windows
> (at least until we make the plugins link against a libethereal.lib - or
> whatever it is you do on Windows).

I'll incorporate it into IrDA and do whatever it does for Windows.

> > Finally, it has one known bug. The protocol uses an escape sequence
> > to escape control characters. These escape sequences should be dealt
> > with before the buffer is passed to the next dissector (IrLAP). I
> > wasn't sure of the best way to handle this.
>
> The right way to handle that is probably to construct a buffer
> containing an un-escaped packet, and then construct a new tvbuff out of
> that buffer - see, for example, "packet-icq.c", in
> "dissect_icqv5Client()" as an example of how to do that.

I'll do that, thanks.

> > +// prototypes
>
> Not all compilers used to compile Ethereal accept C++-style comments.
> To quote the "Portability" section of "doc/README.developer":
>
> 	Don't use C++-style comments (comments beginning with "//" and running
> 	to the end of the line); Ethereal's dissectors are written in C, and
> 	thus run through C rather than C++ compilers, and not all C compilers
> 	support C++-style comments (GCC does, but IBM's C compiler for AIX,
> for example, doesn't do so by default).

Call them C++ style comments is misleading, since the slash-slash 
commenting style is part of C99. For the sake of portability though, I'll 
convert them.

> > +#include <stdint.h>
>
> 	% more /usr/include/stdint.h
> 	/usr/include/stdint.h: No such file or directory
> 	% uname -sr
> 	FreeBSD 3.4-RELEASE
>
> 	%more /usr/include/stdint.h
> 	/usr/include/stdint.h: No such file or directory
> 	%uname -sr
> 	FreeBSD 4.6-RELEASE
>
> <stdint.h> isn't in C89 (or, at least, not in my copy of the 1989 ANSI
> C spec), and we don't require C99.  Use GLib's types, such as "gint8",
> "guint8", "gint16", "guint16", etc. instead.

Just for my curiosity, is uint8_t (and their like) defined anywhere on 
your system? If not, how were cross platform protocol libraries written 
on these systems without defined width types? (assuming glib isn't being 
used)

Thanks for your help!
Shaun