Stephen Donnelly wrote:
The code for reading ERF files has not been significantly updated since
2004. This patch brings it up to date with a number of changes.
Checked in.
3) Allow the user to specify HDLC encapsulation as 'chdlc',
'ppp_serial', 'frelay' or 'mtp2'. This is needed because the ERF HDLC
capture formats do not include information on what protocol is used at
the next level. This is currently done via an environment variable
'ERF_HDLC_ENCAP' and is analagous to the existing 'ERF_ATM_ENCAP'
variable.
If the user does not specify an HDLC encapsulation it tries to guess,
and falls back to MTP2 for backwards compatibility with Florent's
existing behaviour.
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.
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.
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.
