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.
