Re: Request for a new DLT

["Fulko Hew" <fulko.hew () gmail com>]

On 7/17/07, Guy Harris <guy () alum mit edu> wrote:
> Fulko Hew wrote:
>
> > a given capture will only ever have a single protocol within it,
> > but since the header is common for all protocols, I thought it was
> > better to
> > ask for a single DLT instead rather than one DLT per protocol.
>
> Not necessarily - DLTs are cheap, and Wireshark already has, for

I figured they were cheap, but you also want to avoid creating 'same as except'
variations on each theme. Maybe there's no way around that.  :-(

> example, a WTAP_ENCAP_FRELAY_WITH_PHDR encapsulation type.  It currently
> assumes a pseudo-header with less information than your pseudo-header
> will provide, but that pseudo-header can be generalized in a way to
> indicate which pieces of information it has.  Its WTAP_ENCAP_LAPB
> already assumes a pseudo-header with direction information; again, that
> could be extended.
>
> That'd be a bit more work, but I can help with that.

When I decided to go this route, I looked at it as a 'unique capture
file format'
except I wanted to keep using the libpcap format.  But since I
(really) wanted to
propogate the signalling/status info, it then needed to be in the
capture stream.
But its really not part of the protocols being captured, so its a phdr
kind of thing.

My concern (of course) is that:
a) its pretty late in my development cycle,
b) I'm under pressure to wrap up my development,
c) I'm already using an 'older' version of pcap and wireshark and have a
  significant porting excercise ahead of me, before I submit patches
d) I have yet to figure out how to integrate my pcap wireshark changes
   into the mainstream as painlessly as possible for future supporters.
e) I'm leary about how long it would take to change/extend existing PHDRs
  so as not to break any existing code (not under my direct initial control)
  Plus the fact that this would need to be done before all my other
steps above.

> (Sigh.  I wish pcap-NG and the supporting code were done; it already
> has, in the packet metadata header, along with the time stamp and
> lengths, a direction indicator and 16 bits of "link-layer-dependent
> errors" which could be used for the error/status bits and possibly
> signal line status - it also has 7 reserved bits that might be usable
> for that.)

Yes, I started off with reading about pcap-NG, and thought it would be
'a good thing',
but unfortunately its not 'here and now'.  I guess thats because pcap
started off
as LAN capture and didn't consider WAN capture.

(BTW.  I currently use 14 bits of framing status, 5 bits of link-signal
status, and a direction bit.)

So in the end... I think I'd rather continue persuing this single DLT approach
where I can embed status/signalling stuff into a single dissector

IE.  Have a pcap with DLT_ACN_WAN and dissectors for:
  ACN_WAN (that handles signal/status info and then dispatches to:)
    Frame Relay (the existing one)
    LAPB/X.25  (the existing one)
    IPARS (one of my new ones)
    UTS (one of my new ones)
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.