On Nov 6, 2012, at 9:47 AM, Alex Bennée <kernel-hacker@xxxxxxxxxx> wrote:
> Ahh it makes more sense now. I've attached the re-worked patch which
> adds an explicit atmoe dissector which seems to work.
Looks good.
I'd use tvb_reported_length() rather than tvb_length() when calculating the number of cells.
(I'd also suggest using another mechanism for providing the "this is an ATM cell" information, as there's also a pseudo-header for Ethernet, but, unfortunately, there *isn't* another mechanism to do that. The fact that there isn't another mechanism is, if not a bug, a serious deficiency; I'll look at fixing that, but, for now, we might as well go with the way you're doing it; if we add a new mechanism, we can revise your dissector to use it.)
> I guess the real question is do I add options to the ATM decoder to
> select AAL based on VPI/VCI?
That sounds like a good idea.
(At some point we might want to generalize the current notion of "conversations" to abstract away its orientation towards address-and-port-number endpoints, so that address-and-port-number transport-layer conversations are just one subtype, have it subsume the notion of "circuits", and use them in a number of places, including ATM virtual circuits, and add support for dissectors adding arbitrary properties to conversations; that could be used to assign not only AAL types to ATM virtual circuits, but to assign higher-level encapsulation/protocol values, complete with a UI to let the user specify them.)
