I have a lot of pcap files
in each pcap file there are some tcp packets
I want to the following steps:
1 filter the pcap file to get expected tcp packets(if with tshark, the filter is like tcp.srcport==80 and tcp.dstport==20000). The tcp data in each tcp packet are of tens of bytes,
1) the first 2 bytes are sequence number
2) the second 2 bytes indicate a length: **n**
3) the following **n** bytes are random (if **n** is 2, then there are 2 random bytes)
4) immediately after the **n** bytes is an IP address
2 from each tcp packet, I want to get the source IP and the IP address string as mentioned in 4)
Above all, I just want to get an IP pair from each tcp packet, the source IP is easy to be obtained from tshark, but the IP address in the tcp data needs some effort
are there any good source code snippets or good ways that can be used for my target?
thanks!
Related
By which fields of TCP packet, we can tell if it is a continuation of a previous TCP packet?
To be part of the same TCP stream, TCP segments must belong to the same session .i.e have the same source IP, source port, destination IP and destination port.
Once two segments are from the same stream, they can be ordered by the sequence number field in the TCP header. The sequence number of the next segment should be equal to the sequence number of the previous segment plus the number of bytes in the previous segment.
So if we have a segment with seq# 1000 and a payload of 200 bytes, the next one should have the number 1200.
TCP: Sequence number, Acknowledgement number.
In Wireshark, you can Right Click on a packet and choose Follow to follow TCP or HTTP stream. It should help seeing how there values change from packet to packet.
I've noticed in wireshark that I'm able to send 4096 bytes of data to a HTTP webserver (from uploading a file) however the server only seems to be acknowledging data 1460 bytes at a time. Why is this the case?
The size of TCP segments is restricted to the MSS (Maximum Segment Size), which is basically the MTU (Maximum Transmission Unit) less the bytes comprising the IP and TCP overhead. On a typical Ethernet link, the MTU is 1500 bytes and basic IP and TCP headers comprise 20 bytes each, so the MSS is 1460 (1500 - 20 - 20).
If you're seeing packets indicated with a length field of 4096 bytes, then it almost certainly means that you're capturing on the transmitting host and Wireshark is being handed the large packet before it's segmented into 1460 byte chunks. If you were to capture at the receiving side, you would see the individual 1460 byte segments arriving and not a single, large 4096 byte packet.
For further reading, I would encourage you to read Jasper Bongertz's blog titled, "The drawbacks of local packet captures".
TCP by default uses path MTU discovery:
When system send packet to the network it set don't fragment flag (DF) in IP header
When IP router or you local machine see DF packet that should be fragmented to match MTU of the next hop link it sends feedback (RTCP fragmentation need) that contains new MTU
When system receives fragmentation needed ICMP it adjusts MSS and send data again.
This procedure is performed to reduce overall load on the network and increase probability of each packet delivery.
This is why you see 1460 packets.
Regarding to you question: the server only seems to be acknowledging data 1460 bytes at a time. Why is this the case?
TCP keep track window that defines "how many bytes of data you can send without acknowledge". Its purpose is to provide flow control mechanisms (sender can't send too much data that can't be processed) and congestion control mechanisms (sender can't send too much data to overload network). Window is defined by receiver side and may be increased during connection when TCP will estimate real channel bandwidth. So you may see one ACK that acknowledges several packets.
I am pretty new to network traffic. I am trying to get the size of data transferred every second in the internet traffic. I downloaded one pcap file, and I'm using tcpdump to analyze it. By running
tcpdump -tttt -v -r sample.pcap
I get some records like below:
21:00:00.539514 IP (tos 0x0, ttl 118, id 0, offset 0, flags [none], proto ICMP (1), length 32)
111.195.18.190 > host-203-203-22-140.net: ICMP echo reply, id 11884, seq 4803, length 12
According to the tutorial (http://packetpushers.net/masterclass-tcpdump-interpreting-output/), the first length (32) is the entire IP packet length, and the second length (12) is the TCP packet length.
I want to know how much data transferred between two hosts. Which one should I use, IP length, TCP length or something else?
An application data (maybe a video, a message, a picture, etc) is sent with a few headers of lower layers (TCP header (layer 4), IPv4 header (layer 3), Ethernet header (layer 2), etc.).
A TCP packet is an application data + TCP header, an IPv4 packet is a TCP packet + an IPv4 header, and so.
IP packet length is TCP packet length + IP header length. This is why the first length and the second length are different.
Headers may be changed by network devices between the two hosts and so it's no way to think about how much data transferred between the two.
If you want to know the length of each packet in the pcap file, run tcpdump -e -r sample.pcap and see the first length of each line.
My application connects to the server using TCP and system is working fine. Using Wireshark I noticed that some TCP packets of 60 bytes are sent with no data. Is this normal?
as part of TCP transmissions and handshake are there some packets sent with no data?
Thanks
Kumar
There are the ACK packets that carry no data and only acknowledge received data. When using Wireshark it should display these "flags" on the empty packets.
To be more accurate you should show a screenshot of the wireshark capture, so we know what the size you mean is.
Meanwhile I dissected an ACK packet of IPv4 TCP traffic here and these are my results:
Protocol Size Description
Ethernet protocol 14 byte 2 MAC adresses (6 byte), Protocoll type (2 byte)
Internet protocol 20 byte The default header size
TC protocol 32 byte The default header size (20 byte) + options (12 byte)
_____________________________________________________________________________________
Total 66 byte
without EP 52 byte (Probably the size the OP is talking about)
without EP, Opts 40 byte (The size talked about in the comments)
The options in my case were 2 NOPs (each 1 byte) and two timestamps (each 5 byte??). The order of the protocols is the same as in Wireshark.
Wireshark splits the information down to each field, so you can see what takes up how much space.
I have a question on how TCP_ACK works when the original packet are fragmented.
For example, original packet size is 1,500*N bytes and MTU is 1,500. Then, the packet will be frgmented into (approximately) N packets.
In this case, how does the receiver sends TCP_ACK to the sender?
I checked with wireshark, it seems that the receiver sends TCP_ACK for every two fragmented packet. Is it right?
Could you give me some refereces for this or explanation?
Thanks.
IP layer on the receiver stack reassembles all the IP fragments into a single TCP segment before handing the packet over to TCP. Under normal conditions, TCP should send only one ACK for the entire TCP segment. The ACK # would be the next expected SEQ # as usual.