Hi,
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.
Thanks,
Martin