Wireshark · Wireshark-dev: Re: [Wireshark-dev] [PATCH] ERF file input

[Stephen Donnelly <stephen@xxxxxxxxxx>]

On Fri, 2007-06-08 at 10:25 -0700, Guy Harris wrote:
> Checked in.

Thanks.

> > I know environment variables are ugly, suggestions are welcome.
> 
> Perhaps have a WTAP_ENCAP_HDLC_FRAMING encapsulation, which only says 
> "these frames are from some network that uses HDLC-style framing", and 
> have a menu item to, at least for some encapsulations, let the user 
> change the file encapsulation - e.g., if it's WTAP_ENCAP_HDLC_FRAMING, 
> offer a choice of various types of serial-line encapsulations (PPP, 
> Frame Relay, LAPB, LAPD, SDLC, Cisco HDLC, etc.).
> 
> With WTAP_ENCAP_HDLC_FRAMING, the raw data from the packets would be 
> displayed, with no further interpretation.
> 
> I think I've seen some Sniffer captures that don't have what appears to 
> be the right encapsulation type, so it might be worth offering that 
> choice for the other serial encapsulations.
> 
> I'd be inclined to have a Wiretap API to request, for a file, what 
> encapsulation types are available; if it returns only one type, don't 
> offer the menu item.
> 
> I'd also have a "set encapsulation type" API, which causes Wiretap to 
> use that type.  If you change the type, Wireshark would close the file, 
> re-open it, set the encapsulation type, and re-read it.  TShark could 
> have a command-line option to set it.

Sounds like the correct way to go about it. I expect there are cases in
other formats where this would be useful as well. Were you thinking of
this menu as part of the open file dialog, or in the main window UI?

Unfortunately I'm not sure I have the time or understand the core of
Wireshark well enough to tackle adding APIs and GUI elements at present.

> > 4) When reading HDLC captures as MTP2, use WTAP_ENCAP_MTP2_WITH_PHDR
> > rather than WTAP_ENCAP_MTP2. This allows us to put the 'Multi-Channel
> > ERF' record 'channel number' field into the MTP2 pseudo header
> > 'link_number' field. This is then displayed in Frame information, and
> > can be filtered on. (Would be nice if it could be made a display
> > column?)
> 
> Geez, *everybody* wants a display column. :-)  I think we're getting to 
> the point where, in addition to the default columns (which aren't 
> associated with particular protocols), we should let a protocol register 
> a column type, so you can add new columns in a dissector without having 
> to change the Wireshark core.

That also sounds like a good idea. On a per-protocol basis there may be
many that have potential columns.

> > Because the ERF record does not specify whether Annex A is used or not,
> > we pass MTP2_ANNEX_A_USED_UNKNOWN and allow the existing user preference
> > to decide.
> 
> I moved the MTP2_ANNEX_A_ definitions to wiretap/wtap.h from 
> epan/packet_info.h, make the packet_info annex_a_used field a guint8, 
> and changed MTP2_ANNEX_A_USED_UNKNOWN from -1 to 2 to match.  This means 
> that if you can save an ERF HDLC MTP2 file as a libpcap MTP2 file, the 
> pseudo-header will have MTP2_ANNEX_A_USED_UNKNOWN in it; this also 
> offers that as an option for libpcap captures.  Perhaps a way to arrange 
> that the user's choice be savable would be useful.

Sounds good, I was thinking about that but didn't want to impose it on
people without asking. I'll take a look at generating MTP2_WITH_PHDR for
ERF in libpcap as well.

As an additional comment, most DAG cards have multiple physical ports,
so having a way of representing the 'link number' or equivalent within
Wireshark would be useful. I'm not sure whether adding a 'link number'
field to the pseudo-headers for all the protocols (ethernet, p2p etc) is
the best way to do this. It might be better if it was more part of the
Wireshark core?

Unfortunately the interface meta information is currently only available
when reading from ERF files, not when capturing via pcap, since libpcap
does not store this meta information (in the common DLTs) either.

Stephen.
-- 
-----------------------------------------------------------------------
    Stephen Donnelly BCMS PhD           email: sfd@xxxxxxxxxx
    Endace Technology Ltd               phone: +64 7 839 0540
    Hamilton, New Zealand               cell:  +64 21 1104378
-----------------------------------------------------------------------