I am working on analyzing H264 video data being streamed over a network. Right now, I am able to successfully extract and analyze the raw H264 for UDP. This process is going to be ALOT harder for the TCP/RTSP because of fragmentation and multiplexing.
Is the video compression / encoding any different on the TCP/RTSP multiplexed stream compared to the UDP stream?
It's only slightly harder as you typically have to demultiplex the audio and video, as well as the RTCP reports on the TCP connection. Fragmentation is not an issue.
Is the video compression / encoding any different on the TCP/RTSP multiplexed stream compared to the UDP stream?
No differences at all. The multiplexing of RTP/RTCP packets is defined in RFC2326.
As far as tools go, you can use openRTSP from http://www.live555.com which handles the transport for you (RTP over RTSP via the -t command line argument) and writes the frames to file.
With reference to Ainitak's comment, it's not that complex: there's a 4 byte header, '$' followed by the channel id, followed by the 2 byte length of the following RTP/RTCP packet. It's not too tricky to parse this.
Related
While experimenting with a UDP server that runs on esp32, I found that the size of the received packet is limited to 1500 bytes: 20 (IP header) + 8 (UDP header) + 1472 (data), (although in theory UDP as if can support packets data up to 64K). This means that in order to transfer a larger amount of data, the client must split it into several chunks and send them one after the other, and on the server side, this data will need to be restored. I think that the overhead of such a solution will be quite high. I also know that Toit provides TCP/IP connection. Naturally, the packet size is also limited in the case of TCP/IP. This is 64K (65535 bytes). Does Toit have any additional restrictions on the TCP/IP connection, or 64K value is fact also for Toit?
As described in this question/answer, it's a matter of avoiding packet fragmentation. Sending packages above this size will force the system to split them up into multiple fragments of size MTU, with each of them being individually unreliable. As memory is already very limited on embedded systems, sending large (> MTU) packages where all fragments has to arrive before it can be processed, can be very unfortunate for the overall application behavior as it can time out or go out-of-memory.
Instead the application should look at a streaming pipeline (perhaps even TCP to handle the unreliable aspects as well).
As TCP/IP is a streaming protocol, any sized "packages" can be sent, as they are automatically split into fragments of size MTU. Note that the data is received in "random"-sized packages, though the order of the bytes is fully preserved.
Hello fellow network adventurers,
I'm implementing a network attack, which ARP spoofs a gateway and a victim, filters the HTTP data and reassemble the web pages in my browser. Also known as webspy.
However, I'm having some issues with libpcap. When I receive the packets with TCP segments contaning the HTTP data, some of them are bigger than MTU! Like 1922, 2878 and even 4909 bytes.
At first, I thought that these were reassembled HTTP packets, given by the kernel. But, according with this post, libpcap doesn't reassemble packets, so it won't bring me a entire, well-formet packet with all the HTTP response from a given request.
For testing, I printed all these packet which are bigger than MTU. All of them contained normal data (CSS, JS, HTML, images, ...).
So what the hell is going on? What are these big guys? I'm struggling with this for a few days.
BONUS QUESTION: Do I'll really need to reassemble by myself all these HTTP data?
However, I'm having some issues with libpcap. When I receive the packets with TCP segments contaning the HTTP data, some of them are bigger than MTU! Like 1922, 2878 and even 4909 bytes.
Your network adapter may be acting as a TCP offload engine, reassembling multiple incoming TCP segments and handing one reassembled segment to the host. At least on Linux, the networking stack might be performing Large Receive Offload, and if that's done before handing packets to "taps" (the PF_PACKET sockets used by libpcap on Linux), you'd get the reassembled segments.
For your program, this shouldn't be an issue, given that...
Do I'll really need to reassemble by myself all these HTTP data?
...you will need to reassemble all the components of an HTTP request or reply yourself.
I'm receiving a RTP/UDP from a hardware encoder, I have tried ffmpeg, so it takes this input and outputs the stream as FLV (it's being sent to NGINX, nginx-rtmp-module). However I'm not able to play the stream smoothly once it's received by nginx, some frames are broken or lost, etc.
I think that my CPU is too slow for this format change (FLV) and/or ffmpeg is missing a lot of RTP packets. Any ideas?
How do TCP knows which is the last packet of a large file (that was segmented by tcp) in the scenario that the connection is kept-established. (like ftp or sending mp3 on yahoo messenger)
I mean how does it know which packet carries data of one.mp3 and which packet carries data of another.mp3 ??
Anyone ?
Thank you
There are at least 2 possible approaches.
Declare upfront how much data you're going to send. Something like a packet that declares Sending a message that's 4008 bytes long
The second approach is to use a terminating sequence (nastier to process)
So the receiver:
Tries to read the declared amount or
Scans for the terminating sequence
TCP is a stream protocol and fragmentation should be transparent to a TCP application. It operates on streams of data, never packets. A stream is assembled to its intended order using the sequence numbers. The sequence of bytes send by application is encapsulated in tcp segments. The stream is recreated on the receiver side before data is delivered to the application.
The IP protocol can do fragmentation.
Each TCP segment goes to the IP layer and may be fragmented there. Segment is reassembled by collecting all of the packets and offset field from the header is used to put it in the right place.
im now developing a project using winpcap..as i have known packets being sniffed are usually fragmented packets.
how to reassemble this TCP segements?..any ideas, suggestion or tutorials available?..
this i assume to be the only way i can view the HTTP header...
thanks!..
tcp is a byte stream protocol.
the sequence of bytes sent by your http application is encapsulated in tcp data segments and the byte stream is recreated before the data is delivered to the application on the other side.
since you are accessing the tcp datasegments using winpcap, you need to go to the data portion of the segment. the header of tcp has a fixed length of 20 bytes + an optional part which you need to determine using the winpcap api.
the length of data part in the tcp segment is determined by subtracting the tcp header length (obtained from a field in the tcp segment) and the ip header length (from a field in the ip datagram that encapsulates the tcp segment) from the total length (obtained from another field in the ip datagram).
so now you have the total segment length and the length of the data part within the segment. so you know offset where the http request data starts.
the offset is
total length-length of data part
or
length of ip-header + length of tcp header
i have not used winpcap. so you will have to find out how to get these fields using the api.
also ip datagrams may be further fragmented but i am expecting that you are provided only reassembled datagrams using this api. you are good to go!
There is no such thing as a TCP fragment. The IP protocol has fragments. TCP is a stream protocol. You can assemble the stream to its intended order by following the sequence numbers of both sides. Every TCP Packet goes to the IP level and can be fragmented there. You can assemble each packet by collecting all of the fragments and following the fragment offset from the header.
All of the information you need is in the headers. The wikipedia articles are quite useful in explaining what each field is
http://en.wikipedia.org/wiki/TCP_header#Packet_structure
http://en.wikipedia.org/wiki/IPv4#Header
PcapPlusPlus offers this capability out-of-the-box for all major OS's (including Windows). Please check out the TcpReassembly example to see a working code and the API documentation to understand how to use the TCP reassembly feature
Depending on the whose traffic you're attempting to passively reassemble, you may run into some TCP obfuscation techniques designed to confuse people trying to do exactly what you're trying to do. Check out this paper on different operating system reassembly behaviors.
libtins provides classes to perform TCP stream reassembly in a very high level way, so you don't have to worry about TCP internals to do so.