It really isn't a problem but I would like to hear from the community about this "strange" phenomenon or at least it seems to me.
I have written an RTSP application that streams video and audio (as RTP payload 96 and 97 respectively)
RTSP client make connection and setup and play correctly (the video could be seen over the client end). What I am bother about is that RTP (video and audio) is send out through TCP (through port 554). Yah I know its correct behaviour but I quite confuse that it uses the same port as RTSP (port 554). I have always have the idea that RTSP would have a static port number and after RTSP connection is established, client would then negotiate the RTP/RTCP connection with server (which will results in creation of additional port (4 in my case). However, it seem that all RTP/RTSP/RTCP traffic is tunneled through the same port (or I have misinterpreted the result)
Below is the rtsp transaction captured by wireshark
C->S (video payload)
SETUP rtsp://192.168.22.33:554/MOVIE/stream=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: happytimesoft rtsp client
S->C (video payload ok)
RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=7C0EAE5B;mode="PLAY"
Server: GStreamer RTSP server
Session: -8lIe87._f3qX4.h
Date: Wed, 24 Mar 2021 15:23:22 GMT
C->S (audio payload)
SETUP rtsp://192.168.22.33:554/MOVIE/stream=1 RTSP/1.0
CSeq: 4
Session: -8lIe87._f3qX4.h
Transport: RTP/AVP/TCP;unicast;interleaved=2-3
User-Agent: happytimesoft rtsp client
S->C (audio payload)
RTSP/1.0 200 OK
CSeq: 4
Transport: RTP/AVP/TCP;unicast;interleaved=2-3;ssrc=2E0ECCA6;mode="PLAY"
Server: GStreamer RTSP server
Session: -8lIe87._f3qX4.h
Date: Wed, 24 Mar 2021 15:23:22 GMT
C->S
PLAY rtsp://192.168.22.33:554/MOVIE/ RTSP/1.0
CSeq: 5
Session: -8lIe87._f3qX4.h
Range: npt=0.000-
User-Agent: happytimesoft rtsp client
After which it plays with both of the payload into one port
Is my interpretation correct? Is there any problem of sending all communication via one port (albeit latency)? Or is there any chances that the packets might be rerouted?
Thanks
https://www.rfc-editor.org/rfc/rfc2326.txt
RTSP/RTP has several sending modes. Your client explicitly requests for RTSP interleaving - where RTP data gets send interleaved in the RTSP channel. That a nice fallback for firewall restricted environments. If you don't request this RTP channels should be send over their individual UDP ports.
Reason it uses TCP (your main concern) is that it uses TCP is that the default is in this trying order: tcp+udp-mcast+udp: https://gstreamer.freedesktop.org/documentation/rtsp/rtspsrc.html#rtspsrc:protocols
You can force UDP by setting the rtspsrc parameter protocols to GST_RTSP_LOWER_TRANS_UDP. Or in gst-launch-1.0 -> protocols=1
Related
What are the differences between SMTP and TCP handshaking? Why is SMTP handshaking important?
A TCP handshake happens at the transport layer of the TCP/IP protocol stack, involving signaling using TCP flags, TCP sequence numbers, TCP port numbers and IP addresses.
SMTP handshaking occurs at the application layer of the TCP/IP protocol, above the transport layer. SMTP handshaking is rarely called a handshake and is composed of the server sending a 220 message representing its banner, the client sending an EHLO or a HELO message along with its name, to which the server will respond with a 220 message indicating success. Subsequent to this the actual email exchange begins.
You can read more about this in RFC 5321.
Port number equals to 80 is obviously not a sufficient condition. Is it a necessary condition that Wireshark has found a request message or response message in application layer payload?
I'm not sure this is a full answer, but here is what I know regarding Wireshark's identification of HTTP packets (all items below are dissected as HTTP):
TCP port 80
TCP or UDP ports 8080, 8008, 591
TCP traffic (on all ports) that has line end (CRLF) and the line begins or ends with the string "HTTP/1.1"
SSDP (Simple Service Discovery Protocol) in TCP or UDP port 1900
DAAP (Apple's Digital Audio Access Protocol) in TCP port 3689
IPP (Internet Printing Protocol) in TCP port 631
I have an IMAP server (Dovecot), on which I am trying to create 1,200 mailboxes (for performance testing). The server successfully creates the mailboxes.
After this operation I then want to list all created folders. The server sends some data, however, after some time (nearly 1 second) the CLIENT sends RST, ACK to the server in response to the server responding with IMAP protocol's command about the list of created folders.
Here is my Wireshark dump snippet:
IMAP: Src Port: imap (143), Dst Port: 56794 (56794), Seq: 29186, Ack: 20533, Len: 24
IMAP: Src Port: 56794 (56794), Dst Port: imap (143), Seq: 20533, Ack: 29210, Len: 15
IMAP: Src Port: imap (143), Dst Port: 56794 (56794), Seq: 29210, Ack: 20548, Len: 16384
TCP: 56794 > imap [ACK] Seq=20548 Ack=45594 Win=49408 Len=0 TSV=3940902 TSER=3940902
IMAP: Src Port: imap (143), Dst Port: 56794 (56794), Seq: 45594, Ack: 20548, Len: 16384
TCP: 56794 > imap [RST, ACK] Seq=20548 Ack=61978 Win=49408 Len=0 TSV=3940902 TSER=3940902
Edit: Well, I think I figured out why RST flag is sent by client. The reason is server exceed MTU value for my loopback interface. I have checked similar behavior for sample Mina server - and all is OK there, i.e. huge packets are spited by TCP/IP protocol. So Dovecot can't manage packets wisely. But I have my own IMAP server (based on MINA) and the problem still persist there!
So why TCP/IP protocol manages sent packets (split them according to MTU value) wisely only for some apps but not for all?
Your assumption about the causation of a TCP Reset being sent is incorrect. If you've exceeded the MTU, that's not managed by TCP. It's managed at the IP layer and an ICMP "fragmentation required" message will be sent to the client. Such a message should then cause the client to fragment the packets at the IP layer. This is not happening in your case based on the information that you've shared.
Regarding the loopback interface, this traffic doesn't go anywhere near the loopback interface, is it not two separate devices?
Sadly, your trace file still doesn't offer any insight into why this packet -
IMAP: Src Port: imap (143), Dst Port: 56794 (56794), Seq: 45594, Ack: 20548, Len: 16384
causes a TCP reset. There's nothing really further that I can deduce from this information.
TCP has an option called Maximum Segment size, which is similar but also different :) The TCP/IP stack is independent of applications and does not apply different settings to each application, it's system-wide.
Edit: Looking at you packet capture, there's nothing indicative of a MTU issue. There's no ICMP traffic anywhere so I suspect that it's not an issue. If there's a MTU issue, it should have happened in the previous response because both LIST responses from the IMAP server are of identical size and there's no issue with the window sizes.
The only thing that I can see is in relation to the first element of the final response (before the RST) where part of the reply looks to be malformed (see the attachment). There's something going wrong in the IMAP application and the data it's replying with is malformed. - see the difference with the bottom two responses that are consistent with all other LIST responses in the pcap.
Please help me decode the following. I have a problem in the network, unable to figure out where it is. Follow is the decode summary we got from the capture by running the OPNET software.
I think Connection 2 is successful, where the client ends with FIN, and connection 1 ends prematurely issuing RST, what could be the reasons..?
Connection 1
Frame Source Destination Decode Summary
480 Server Client D=3590 S=443 FIN ACK=3832271994 SEQ=1338775336 LEN=0 WIN=11088
481 Client Server D=443 S=3590 ACK=1338775337 SEQ=3832271994 LEN=0 WIN=64512
502 Client Server D=443 S=3590 RST ACK=1338775337 SEQ=3832271994 LEN=0 WIN=0
Connection 2
855 Server Client D=3600 S=443 FIN ACK=3778329063 SEQ=3650187663 LEN=0 WIN=26328
856 Client Server D=443 S=3600 ACK=3650187664 SEQ=3778329063 LEN=0 WIN=63297
857 Client Server D=443 S=3600 FIN ACK=3650187664 SEQ=3778329063 LEN=0 WIN=63297
859 Server Client D=3600 S=443 ACK=3778329064 SEQ=3650187664 LEN=0 WIN=26328
In summary the connection endings are,
1 - Server: FIN, Client: RST
2 - Server: FIN, Client: FIN
From the Wikipedia page on TCP:
Some host TCP stacks may implement a half-duplex close sequence, as Linux or HP-UX do. If such a host actively closes a connection but still has not read all the incoming data the stack already received from the link, this host sends a RST instead of a FIN (Section 4.2.2.13 in RFC 1122).
Could it be something like this you are seeing?
I am trying to connect to an http server via IPv6 link-local address from Windows xp sp3 with firefox 6.
Although connecting by IPv4 address of serve worked well, IPv6 failed with connection failed error.
By Wireshark, the sequence is observed as:
direction protocol port transmission
1. client -> server: tcp 1061-> 80 [syn]
2. server -> client: tcp 80->1061 [syn, ack]
3. client -> server: tcp 1061->80 [ack]
4. client -> server: http [get /]
5. server -> client: http [200 OK]
In the 5th transmission, requested html file is included.
But the browser shows connection failed.
It seems tcp layer received the messages and cannot deliver it to http layer or browser.
I disabled firewall, and the result is the same.
Can someone give a clue or hint to pursue.
Thank you.
I suspect that it's not the whole response in packet 5.
Usually problems like this are caused by broken Path MTU Discovery. If there is a tunnel in the path then the MTU is probably smaller than 1500 bytes, i.e. 1480 bytes. All the packes that are smaller than 1480 bytes get through. When the server sends a 1500 byte packet it will be too big for the tunnel. The tunnel router sends back a Packet-too-big ICMP error, and the server sends the data in 1480-byte chunks. If the ICMP error is never generated or a firewall blocks the ICMP packet then the server never learns that it should send smaller packets, it keeps sending large packets, and they never arrive...
Most of the time such problems are caused by misconfiured firewalls. Sometimes it's broken hardware or software.