Home page logo
/

wireshark logo Wireshark mailing list archives

Re: Conversation handling for UDP
From: Hadriel Kaplan <hadriel.kaplan () oracle com>
Date: Wed, 5 Mar 2014 20:40:29 -0500


So to answer my own questions:

Yes, in v1.11 the UDP code changed to always create exact-match conversations, in r53641, in order to support a new 
'udp.stream' display filter.

Unfortunately that breaks any early-media scenarios for SIP calls.  Luckily the SIP/SDP/RTP stuff needs to be re-done 
anyway, because there are too many problems with the current model of waiting until the SDP answer to install the media 
flow info.  The RTP conversations have to be installed by the SDP offer, which will avoid the problem of UDP creating a 
new exact-match conversation.

So nothing to see here... move along...

-hadriel


On Mar 4, 2014, at 10:06 PM, Hadriel Kaplan <hadriel.kaplan () oracle com> wrote:

Howdy,
I've been looking into bug 9835, which involves SIP+SDP setting up RTP conversations/flows.  I've found 3 bugs so far 
in the relevant code areas, but the last one I'm stuck on looks like it's by design.  It looks like the UDP dissector 
creates a addr:port-specific conversation for new packets, even if no protocol/heuristic ends up claiming its 
payload; and if that happens before a wildcarded conversation is added sometime later that would have matched the 
conversation, then it won't match it ever.  Is that correct?

In other words, imagine you've got this:

Packet #1: UDP source addr:port A -> dest addr:port B, non-dissected payload.

Packet #2: SIP/SDP that sets up wildcarded RTP conversations for dest addr:port A, and another one for dest addr:port 
B; these should match packet #1 (in a second pass) and #3 and #4 in the first pass.

Packet #3: UDP source addr:port A -> dest addr:port B, matches "conversation" created by Packet #1, not the RTP one.

Packet #4: UDP source addr:port B -> dest addr:port A, matches "conversation" created by Packet #1, not the RTP one.

Am I understanding the code correctly? Is that the way it *should* work?

If so, I'll have to change the SIP/SDP logic.  Currently it only creates the RTP conversations on receiving the SDP 
answer, instead of on the offer.  But RTP can (and in fact often does) start flowing in the upstream direction based 
on the SDP offer, before an SDP answer is received.

-hadriel

___________________________________________________________________________
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-request () 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-request () wireshark org?subject=unsubscribe


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]