Pascal Quantin skrev 2013-05-12 17:50:
2013/5/12 Anders Broman <a.bro...@bredband.net
<mailto:a.bro...@bredband.net>>
Pascal Quantin skrev 2013-05-12 11:08:
2013/5/12 Anders Broman <a.bro...@bredband.net
<mailto:a.bro...@bredband.net>>
Pascal Quantin skrev 2013-05-10 15:20:
2013/5/5 Anders Broman <a.bro...@bredband.net
<mailto:a.bro...@bredband.net>>
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?
I was hoping Guy would comment :-)
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
Well as long as the tap, "taps" after reassembly is done I suppose
it does not matter but if y is on top of x why tap y
and not only X as that would include Y any way?
The purpose of your development is to export higher layer PDUs without
the transport stream / lower layer and I guess depending on the user,
you will have different needs and understanding of what this "higher
layer" is. So a user might be interested by the export of X while
another user might want only Y. But that's really a minor issue.
Sure just saying that you would probably export x OR y.
The export of malformed packets seems a must-have for me otherwise you
would loose too much information.
Regards,
Pascal.
Assuming malformed packets are due to dissector bugs, fixing those would
fix the problem :-))
Seriously - I suppose one have to chose the tapping point as wisely as
possible but it might differ between
protocols.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
