Ethereal-dev: Re: [Ethereal-dev] Broken Wellfleet LAPB captures ...

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

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: Guy Harris <guy@xxxxxxxxxx>
Date: Thu, 19 Dec 2002 13:31:21 -0800
On Thu, Dec 19, 2002 at 01:48:35PM -0800, Richard Sharpe wrote:
> OK, so the problem seems to be that the capture claims to be a NG Sniffer 
> capture, but wiretap cannot figure out what type it is, so it labels them 
> as WTAP_DLT_LAPB frames, it seems.
> 
> The solution would be to declare a Wellfleet DLT type and detect it there, 

Yes - have "infer_pkt_encap()" try to infer the packet type.

Unfortunately, RFC 1547 section 4.3.5 says

   The Wellfleet router supports synchronous links using simple HDLC
   framing.  The HDLC framing procedure uses the HDLC address and places
   the Unnumbered Information (UI) command in all frames.  A simple
   header following the UI command provides a two octet type field using
   the same values as Ethernet.

which doesn't indicate what it puts in the HDLC address field; if it
always uses the same value, and that value is never used by any other
serial HDLC-like protocol (note that PPP *can* use values other than
0xff), we could use that, but if that's not the case, the first byte
doesn't help, and neither does the second byte as the UI value of 0x03
is also used for PPP in HDLC-like encapsulation.

However, given that the two octet type field, as it's an Ethernet type
value, always has values > 1500 (or whatever the right "minimum Ethernet
type value" is), any packet with 0x03 as the second byte and a two-byte
value <= 1500 can probably be treated as PPP.  Unfortunately, there are
PPP protocols with values > 1500, so that doesn't completely solve the
problem.

> and then have a WellFleet dissector that chews the first two bytes, builds 
> a TVB containing the rest and calls the Etherenet dissector, because the 
> rest seems to be pseudo-Frame-type Ethernet frames.

RFC 1547 suggests that it merely has an Ethernet type; are you saying
that a full Ethernet header, complete with destination and source MAC
addresses, follows the first two bytes?

If not, and it's just an Ethernet type, it should do the same sort of
thing that the Cisco HDLC dissector does.