This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Decode as RTCP only some of the packets to a specific port

0

I'd like to capture RTCP packets sent and received to and from specific ports. I have setup this simple filter :

udp.port == 10003 or udp.port == 10007 or udp.port == 10001 or udp.port == 10005

that allows me to capture almost exactly what I want. The problem is that at the same ports there's also STUN traffic. So, if I select "decode as" RTCP, the STUN traffic gets decoded as RTCP as well. That yields invalid RTCP packets of course. Is there a way to filter out the STUN traffic?

asked 17 Jun '14, 01:13

gpo's gravatar image

gpo
6123
accept rate: 0%

edited 17 Jun '14, 04:13


One Answer:

0

Go into Wireshark preferences, and under the RTP and RTCP protocols, check "Try to decode outside conversation".

This should then show your specific RTP and RTCP traffic and leave out the STUN prtotocol.

answered 17 Jun '14, 03:24

Rooster_50's gravatar image

Rooster_50
23891218
accept rate: 15%

I should have mentioned that I've already tried that but it didn't work :(

(17 Jun '14, 03:38) gpo

Do you have a sample trace you can share via dropbox or cloudshark.org?

(17 Jun '14, 03:42) Rooster_50

Does this feature generally work? Should I file a bug report maybe?

(17 Jun '14, 05:01) gpo

Does this same issue happen if you do not capture using the "ANY" device, so that you get a true Ethernet header, instead of the Linux Cooked packet header?

Also, if you look at the values of the RTP header after you decode as RTCP, they are all over the place.

(17 Jun '14, 08:14) Rooster_50

Does this same issue happen if you do not capture using the "ANY" device, so that you get a true Ethernet header, instead of the Linux Cooked packet header?

I'll try that tomorrow.

Also, if you look at the values of the RTP header after you decode as RTCP, they are all over the place.

What do you mean by saying that they're all over the place?

(17 Jun '14, 12:54) gpo

Does this same issue happen if you do not capture using the "ANY" device, so that you get a true Ethernet header, instead of the Linux Cooked packet header?

I just tried that and the problem persists.

(18 Jun '14, 01:17) gpo

Those are actually SRTCP packets. Here it says that SRT(C)P handling was recently added to both dissectors.

UPDATE: It seems there was a patch developed back in 2007 and it appears that it is included in the latest wireshark (I checked the source code) but I don't see how to activate. Is it really included and if so how do I use it?

(18 Jun '14, 02:46) gpo
1

In order for it to work the media session protocols have to setup a crypto session (which they do not) and decryption has to be implemented (like through the use of libsrtp, which is not there). All the RT(C)P dissectors can do now is keep their hands off of encrypted data and tell you about that.

(18 Jun '14, 05:16) Jaap ♦

I kind of need this functionality, so I'm considering implementing it; but I have no clue as to where to start from.

Would you happen to know if there's anything similar currently implemented to get inspired from? Do you think this is possible in Lua? Or do I have to modify packet-rtcp.c and friends to get it to work?

(18 Jun '14, 06:33) gpo
1

First you need to know how to get your hands on the crypto parameters. Then these have to be added to the cipher information structure passed to the RT(C)P dissectors for use there with libSRTP for instance. packet-sdp.c has a skeleton implementation for this. All this can only be done in the existing dissectors, and I assume quite a bit of work to do it right.

(19 Jun '14, 04:41) Jaap ♦

OK, I'll try to get my hands dirty. Thank you very much for all the information you gave me Jaap. Thank you, too, Rooster_50. You guys rock :-)

(19 Jun '14, 07:49) gpo
showing 5 of 12 show 7 more comments