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] Short packets / Bad data

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

From: Nathan Neulinger <nneul@xxxxxxx>
Date: Sat, 04 Dec 1999 20:28:47 -0600
Gilbert Ramirez wrote:
> 
> On Fri, Dec 03, 1999 at 04:20:52PM -0600, Guy Harris wrote:
> >
> >
> > > I've been using Ethereal today specifically to debug strange NFS problem
> > > at work. I thought there might be some VFS bug in the Linux kernel, but
> > it
> > > didn't even dawn on my to consider malformed packets!
> >
> > Cf. my earlier comment, in another mail thread, on how one reason for
> > using Ethereal is to check for packets that *aren't* following the rules
> > of their protocol, and hence the requirement that Ethereal not assume
> > all packets are valid....
> 
> Absolutely. In a similar vein, I think it's time to decide on a procedure
> for guarding against having a protocol dissector read beyond the captured
> data, either because of a short packet or because of bad data in the
> packet telling the dissector to keep on reading. I'd like to document
> this procedure and put it in our fledgling doc/ directory, so that all
> of the protocol dissectors solve this nasty problem in the same way.
> 
> Here's a couple things off the top of my head. Some of these
> may be too harsh.. should we try to decode partial packets, retrieving
> as many fields as possible? This would mean lots of BYTES_ARE_IN_FRAME()
> checks, or a setjmp()/longjmp() solution that Guy once mentioned to me.

In a few of the dissectors I have written, I have defined a macro like:

#define TRUNC(x) { if(!BYTES_ARE_IN_FRAME(offset,(x)) { \
	dissect_data(pd,offset,fd,tree); \
	return; }

That could be extended a bit to put some text on the proto tree saying
it was truncated or whatever.

I then just prefix any of my dissections with calls to TRUNC(). It's not
the most efficient method in the world, but it makes coding really easy.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@xxxxxxx
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216