RTP dissector in Lua not chained with SDP setup info present and post-dissector not saved in pdml

Question

Hi, I'm pretty much a Wireshark noob, but..

I'm trying to analyze some RTP streams, some of which are set up by SIP (with some additional features).

I'm writing packet dissectors in Lua, but there are a couple of problems. As far as I can tell, if I use a chained dissector and add it to the udp dissector table where udp.port == [port of interest] then the dissector works fine EXCEPT where the builtin Wireshark RTP dissector has added a 'Stream setup by SDP' subtree. I'm not sure how Wireshark determines which packets are RTP other than as part of a SIP conversation, but I haven't had any luck attaching a dissector to these packets.

The most reliable way is to disable RTP protocol and dissect the RTP headers myself, but then I lose the stream setup by info that Wireshark provides. I can probably do this myself with Lua but it seems like a lot of extra work, given my level of expertise.. I would prefer to take advantage of all of Wiresharks built in RTP dissectors and just add my stuff.

Which leads me to my second problem. A post dissector actually works fine, is easy to write and accomplishes EVERYTHING I need, EXCEPT for the fact that the post dissector tree IS NOT WRITTEN to an exported .PDML file. This is a blocking issue for me as I'm doing further analysis with this file.

I'd be very grateful for any pointers on what is causing the SDP setup info dissector to disable my dissector and how to make it work. Failing that, is exporting of post dissector info to .pdml problematic, or is this just an omission that could be fixed in the source? (I'm not keen to build Wireshark myself as I'm using windoze, but maybe if this is an easy fix, somebody could submit a patch?).

UPDATE I thought the first problem might be with Wireshark decoding dynamic payload type 99 as RFC 2198. I disabled the dissector RFC 2198 in RTP preferences. see: http://ask.wireshark.org/questions/13891/how-to-decode-dynamic-pt-in-rtp-eg-rfc-2429-in-rtp-carring-h263-video ..However my dissector still won't run on those packets. The only difference seems to be the SDP stream setup info but if I disable this in preferences, the problem persists.

My dissector is installed using DissectorTable.get("udp.port"):add(9050, proto)

I also use Dissector.get("rtp"):call(buf(0):tvb(),pkt,root) at the start of the dissector function, but adding or removing this has no effect other than what's expected.

Cheers, Jono Poff.

Answer 1

1

So it turns out PDML writing should work with a Lua post-dissector, but wasn't in your case due to bug 6020. Ironically that bug was fixed by me, and the code change was just delivered into 1.9.1 this afternoon. So it should work with the latest automated build of 1.9.1, SVN-47877 or higher. (see http://www.wireshark.org/download/automated/)

I don't know if/when it will be back-ported to stable release patches.

answered 25 Feb '13, 22:15

Hadriel
2.7k●2●9●39
accept rate: 18%

Hi Hadriel,

yes I can confirm that Version 1.9.1-SVN-47899 writes post-dissector info and fixes a lot of these issues. RTP setup info is still missing from PDML output, even tho it appears in the GUI. Maybe there's an explanation for this.. Anyway, it's irrelevant to me now as I've written my own RTP and SDP dissectors to analyse setup and add RTP dissectors to new streams.

Thanks again for all your help. Btw, I've written an XSLT to transform PDML as swim lanes into HTML. I'll ask my boss if I can contribute it if anyone's interested.

Cheers, Jono

(26 Feb '13, 14:55) J0N0

Your answer has been converted to a comment as that's how this site works. Please read the FAQ for more information.

If an answer has solved your issue, please accept the answer for the benefit of other users by clicking the checkmark icon next to the answer. Please read the FAQ for more information.

(26 Feb '13, 15:01) grahamb ♦

The setup info appears for me: ' <proto name="rtp" showname="Real-Time Transport Protocol" size="252" pos="42"> <field name="rtp.setup" showname="Stream setup by SDP (frame 11)" size="0" pos="42" show=""> <field name="rtp.setup-frame" showname="Setup frame: 11" size="0" pos="42" show="11"/> <field name="rtp.setup-method" showname="Setup Method: SDP" size="0" pos="42" show="SDP"/> </field> '

Did you re-enabled Preferences -> Protocols -> SDP -> Establish Media Conversation?

(26 Feb '13, 15:15) Hadriel

It works!

Wireshark wrote the built-in SDP/RTP setup info to PDML just fine, but I wanted to use this info downstream in a post-dissector (eg, see below) and write it to PDML. Up til now, that has worked in the GUI but not with PDML.

Now it works for both, which is awesome. Thx.

:-)

udp_src_f = Field.new("udp.srcport")
rtp_setup_f = Field.new("rtp.setup-frame")
trivial_proto = Proto("trivial","Trivial Postdissector")
f_port = ProtoField.uint16("trivial.port","Port")
f_setup = ProtoField.uint8("tait.rtp_setup_frame","SetupFrame")
f_comment = ProtoField.string("trivial.comment","Comment")
trivial_proto.fields = {f_comment}
function trivial_proto.dissector(buffer,pinfo,tree)
    local subtree = tree:add(trivial_proto,"Trivial")
    if udp_src_f() then
       subtree:add(f_comment, "udp.srcport found")
       subtree:add(f_port, udp_src_f().value)
   else
       subtree:add(f_comment, "udp.srcport not found")
   end
if rtp_setup_f() then
   subtree:add(f_comment, "rtp.setup-frame")
   subtree:add(f_setup, rtp_setup_f().value)

else subtree:add(f_comment, "rtp.setup-frame not found") end end

register_postdissector(trivial_proto)

(26 Feb '13, 16:43) J0N0

Sorry about my comment that it didn't work in 1.9.1, SVN-47877. Not sure what happened there...

(26 Feb '13, 16:45) J0N0

Answer 2

0

SDP makes an interpretation of the media lines and uses a helper function in the RTP dissector to define a conversation, with RTP as dissector. This is how the setup information comes in RTP, and assigns RTP as dissector for this stream. Either showing or not showing the setup information doesn't prevent the SDP from creating these conversations. So, these two come in pair: setup information and RTP dissector gets the payload. I think all you can do is inhibit SDP from setting up the conversation. That allows your dissector access to the payload, but you loose the setup info.

answered 28 Jan '13, 03:01

Jaap ♦
11.7k●16●101
accept rate: 14%

Thanks Jaap, I thought that might be the case.

If I disable the RTP dissector entirely and get setup info directly from the SDP message header, eg:

o=16386 1355173130331 1355173130331 IN IP4 172.26.26.8 m=audio 9050 RTP/AVP 100

how practical would it be to follow the conversations myself (with a listener maybe?) then add setup info to my own RTP packet dissector. I guess it would require some ongoing analysis of the SIP conversation..

What would be really great would be a hook to override the RTP dissector being called by SDP with a user supplied one.

(28 Jan '13, 13:17) J0N0

That would mean you have to parse SDP as well. From that you would create a conversation defining UDP packet flow to that endpoint to go to your dissector. I'm not well versed enough in Lua to know if that's possible.

(28 Jan '13, 23:00) Jaap ♦

I think what Jaap means is to go into Preferences -> Protocol -> SDP, and de-select the "Establish Media Conversation" checkbox. That should make the SDP dissector not invoke RTP dissection for the UDP ip:port flows that is indicated by SDP, so that RTP's dissector won't get called before/instead-of your own dissector for those UDP ip:port flows.

Of course that also means there won't be any setup info and dynamic RTP dissection.

Another alternative is to submit an enhancement request for the tree info generated by a post-dissector to be exported in PDML, so that you can instead use a post-dissector - since that's arguably the right thing to use to begin with.

(25 Feb '13, 11:30) Hadriel

Thanks Hadriel,

I've written the SDP setup stuff in Lua and am now loading RTP dissectors as needed according to that info.

It does feel like reinventing the wheel tho, and really all I need is for the post-dissector to be written to pdml, so that wld definitely be a good enhancement from my perspective. Therefore I'll put in a request!

Cheers, Jono

(25 Feb '13, 14:06) J0N0