["Visser, Martin (SNO)" <Martin.Visser@xxxxxxxxxx>]

Hi,

I'm being a bit lazy but I noticed that Wellfleet Compression Protocol
purports to be support in 0.8.17. I have attached a PCAP capture in which
frames 3, 4 and 7 ought to be WCP. Ethereal only says it is PPP compressed
but doesn't decode any further? Is there something wrong here?

I captured these using the Nortel PcapTap program (also known as walts)
which captures directly from the serial interface on the router. As long as
I specified the .enc file I saved as PPP format it would flag such packets
as WCP (though not decode them). Below is the text of the 3rd frame from
PcapTap.

Data File: C:/PROGRA~1/PcapTap/dttwcp.enc
Print Date: Tue Apr 17 09:51:23 AUS Eastern Daylight Time 2001

Frame Delta T        Length  Dir  Dest Address        Source Address     
52    14:42:52.579   39      Tx                                          

Frame 52  Date and Time: 22-Mar-2001 14:42:52.579

Point to Point Protocol (PPP)                         byte      0
  addr                       0xff                          8 bits
  contrl                     0x3                           8 bits
  protocol                   WCP                          16 bits
WCP Header                                            byte      4
  op_code                    DATA_COMPRESSED_IND           4 bits
  seq_no                     2764                         12 bits
DATA                                                  byte      6

    0:  82208500  0040d741  20850120  9f065085    . ...@.A .. ..P.
   10:  02210000  d9285190  014f20e6  086d8c22    .!...(Q..O ..m."
   20:  29



    0:  ff0300fd  0acc8220  85000040  d7412085    ....... ...@.A .
   10:  01209f06  50850221  0000d928  5190014f    . ..P..!...(Q..O
   20:  20e6086d  8c2229                           ..m.")




Martin Visser
Technology Consultant - Compaq Global Services

Compaq Computer Australia
410 Concord Road
Rhodes, Sydney NSW 2138
Australia

Phone: +61-2-9022-5630
Mobile: +61-411-254-513
Fax:+61-2-9022-7001
Email:martin.visser@xxxxxxxxxx


> -----Original Message-----
> From: Guy Harris [mailto:guy@xxxxxxxxxx]
> Sent: Tuesday, 17 April 2001 9:56 AM
> To: Ronnie Sahlberg
> Cc: ethereal-dev@xxxxxxxxxxxx
> Subject: Re: [Ethereal-dev] IP defragment
> 
> 
> > please consider for cvs
> 
> The code that does
> 
> 	ipfk->srcip = *((guint32 *)pinfo->src.data);
> 	ipfk->dstip = *((guint32 *)pinfo->dst.data);
> 
> may crash on platforms with strict memory alignment requirements (and,
> in fact, *did* crash on my SPARC/Solaris/GCC platform at work on at
> least one capture file); do
> 
> 	memcpy(&ipfk->srcip, pinfo->src.data, sizeof ipfk->srcip);
> 	memcpy(&ipfk->dstip, pinfo->dst.data, sizeof ipfk->dstip);
> 
> instead.
> 
> Note also that "g_malloc()" is defined to abort the application if you
> run out of memory:
> 
> 	
http://developer.gnome.org/doc/API/glib/glib-memory-allocation.html

"Note: If any call to allocate memory fails, the application is
terminated. This also means that there is no need to check if the call
succeeded."

so it shouldn't check for "g_malloc()" returning NULL - it never returns
NULL.

You also need to save and restore some of the members of "pi" before
calling a subdissector, so that old-style (non-tvbuffified) dissectors
work correctly.

In addition, given that the reassembly code checks the IP checksum, you
have to compute it *regardless* of whether the "tree" argument is null
or not.

I've attached a patch to the "packet-ip.c" you sent out, which includes
those fixes.

Another thing you'll need to do is to arrange that if not all the data
in a fragment is present - i.e., if "tvb_reported_length(tvb)" is
creater than "tvb_length(tvb)" - you don't add it to the fragment hash
table.  This can happen if the capture was done with a snapshot length
less than the MTU of the network; Ethereal/Tethereal, snoop, and
Microsoft Network Monitor default to a large or "infinite" snapshot
length, so, at least with those programs, it'll happen only if the user
explicitly specifies a smaller snapshot length, but the default snapshot
length in tcpdump is 68 bytes, so it'll happen with tcpdump *unless* the
user specifies a larger snapshot length.

> * multiple-tails, overlap-conflict and too-long-fragmnet will also set
> "ip.fragments.error" which is easier to use in a
> display-filter.

Perhaps what we need here is either

	1) a generic "error" flag that can be set on a frame, with an
	   expression such as "error" checking it

or

	2) a way of marking a protocol tree item as an error indication,
	   which could not only be filtered for with a special
	   expression such as "error" but could perhaps also be made a
	   different color (defaulting, perhaps, to the standard color,
	   but allowing the user to specify a different color).

Attachment: wcp.pcap
Description: Binary data