[Pascal Quantin <pascal.quantin@xxxxxxxxx>]

2013/5/12 Anders Broman <a.broman@xxxxxxxxxxxx>

Pascal Quantin skrev 2013-05-10 15:20:

2013/5/5 Anders Broman <a.broman@xxxxxxxxxxxx>

Hi,
I have added a basic implementation making it possible to export higher level PDU:s to file using a USER_DLT.
The basic implementation makes it possible to export SIP traffic to a new file adding some meta data before the actual SIP message. The idea is that it should be possible to export the reassembled PDU:s(and mix several protocols) removing the under laying transport protocol but retaining some interesting data such as IP addresses and ports.

The implementation is bare bones to get the demo to work. It would be nice to get some feedback on useful tags
to add, helper functions to load tags and if some one is willing to work on the GUI part that'd be nice too.

Would it be feasible/useful to apply for a link-layer type from tcpdump?

Any comments welcome.
Regards
Anders

Hi Anders,

it looks interesting. I started playing a bit with it and fixed a few bugs in r49232. Moreover I added the tags content to a subtree. Feel free to revert it if you do not like the output.

I would find it great to have a link layer type allocated. This way the feature could work out of the box without any configuration.

Yes

 Then how should we proceed? Can Guy allocate us a DLT or must we send a request to someone?

Any idea on how to handle the export of several protocols ? Should we allow the user to select them in the GUI or should we export all the protocols registering the tap and let the user select afterwards which ones to keep with filters?

My idea is to export all the protocols registering to the tap, if you tap with a filter only the filtered
protocols should be tapped I think.

Fine with me.

By the way, I noticed that if a dissector and sub dissector both support the export functionality, the sub dissector message is dumped twice (once per protocol). Not sure whether this should be considered as a feature or a bug.

Do you mean protocol x+y in the first packet and y in the second? I would expect that.

Yes that's what I meant. I think we should tap the packet at the beginning of the dissection and not at the end as it is currently done in the SIP dissector. I see two advantages:

- packet x+y will be tapped before packet y and not the opposite (I find it awkward to have packet y displayed before packet x+y)

- a malformed packet will still be tapped

Regards,

Pascal.