https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2671
--- Comment #5 from Stephen Donnelly <stephen@xxxxxxxxxx> 2008-07-02 14:13:03 PDT ---
(In reply to comment #4)
> OK, from looking at the "ERF Types" document EDM11-01, version 6 (BTW, is there
> a public - as in "you don't need to fill in a form to get access to it" -
> specification for ERF available?), it appears that:
The url http://www.endace.com/support/EndaceRecordFormat.pdf is supposed to be
public, but it is a struggle. I will see if I can get it uploaded to the
Wireshark wiki.
> ERF_TYPE_MC_ATM and ERF_TYPE_ATM contain a single ATM cell, and thus should
> presumably always be dissected by dissect_atm_cell() in packet-atm.c, so either
> we hand it to the ATM dissector with ATM_RAW_CELL set in atm.flags, or register
> dissect_atm_cell() by name as an ATM cell dissector and use that;
Yes, probably true. I'm not too familiar with the ATM dissector.
On early ATM DAG models it was possible to capture in 'cell mode' to get all
cells, or 'first cell' mode which captured only the first cell from each AAL5
frame. In this case the records are equivalent to an AAL5 capture with slen=48,
so the high level dissectors could be called directly.
The 'first cell' mode has been removed on newer ATM models which support AAL
reassembly directly and produce the appropriate ERF records.
> ERF_TYPE_MC_AAL5 and ERF_TYPE_AAL5 contain a reassembled ATM AAL5 PDU, and
> should presumably always be dissected by dissect_reassembled_pdu(), again with
> the appropriate ATM pseudo-header - and selecting a traffic type should perhaps
> be done with heuristics or an ATM-layer preference setting (and ultimately with
> a way of specifying per-VC traffic type);
Yes, probably makes sense if the capability is there. I'm guessing the
Wireshark ATM code has improved since ERF support was first added.
> ERF_TYPE_MC_AAL2 and ERF_TYPE_AAL2 contain a reassembled ATM AAL2 PDU, so
> presumably its payload should never be handed to a dissector for an
> encapsulation used, as far as I know, only over AAL5, such as LLC
> encapsulation;
Fair point. Is there any AAL2 support in Wireshark? Should it simply terminate
dissecting with a hex decode?
> so I'm not sure whether there should be an ERF preference for ATM (as opposed
> to appropriate preferences, heuristics, etc. in the ATM dissector).
If there are appropriate heuristics available we can probably leverage the ERF
TYPE and make a reasonable decision.
Unfortunately I'm not likely to get a lot of time to work on this; is anyone
interested in helping out?
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.