Wireshark-dev: [Wireshark-dev] Adding a dissector for IuB FP

From: Martin Mathieson <martin.mathieson@xxxxxxxxxxxx>
Date: Thu, 22 Jun 2006 16:17:25 +0100

I'm toying with the idea of adding a dissector for FP (TS25.427, TS25.435) as used in the user-plane of IuB. It can be carried over AAL2, UDP or AAL0.

Dissecting these frames is tricky, because the format of the frame can depend upon information not stored in the frame itself (e.g. size&number of transport blocks). FP frames in DCT2000 .out files include this information in their headers, so I can write a dissector that can interpret this info once its available (rather than try to work it out). If other supported file formats do something similar it would be good for testing and for keeping the dissector as general as possible.

I'm struggling with a couple of design issues though, and would appreciate any suggestions:

(1)  Calling the dissector:
- I don't think there are any well-known UDP ports or AAL VPI/VCI settings for FP. I could add a UDP port preference for UDP. I don't think there is a way to register for an ATM address though. I could do 'decode-as' for UDP, but it doesn't look like this is (yet) implemented for ATM. Would it be possible/reasonable to register dissectors with ATM addresses and make 'decode-as' work?

(2) Storing and retrieving the info:
- If I know in the wiretap module that the frame is FP, I could attach pseudo-header information there. The ATM dissector will always look at the atm part of the wtap_pseudo_header union. Possibly I could extend this with optional FP information, but there is also the UDP case to consider. The FP dissector would need to know whether it was running over ATM or not to know where to look to find the information it needs (i.e. the end of the atm header or some new part of the union if running over UDP). Is there a way for a dissector to check which protocol its being carried upon? This already sounds ugly...
- p_add_proto_data() is obviously not possible :)

Some parts of the dissector will also be quite bit-oriented. Even if it works this could easily be too ugly to submit.