I am wondering how, in detail, a program like wireshark detects duplicates from retransmission in a TCP stream. I've looked at the RFCs regarding TCP but haven't quite been able to figure out how it works. I'd very much appreciate a clear explanation.
An example situation that confused me was the following:
*C: 1227 + len = 1687
C: 1847+ len = 2299
S: ACK 2299
*C: 2299+len = 2751
*C: 2751+len = 3203
S: ACK 2751
Where the * indicates packets with duplicate payloads. How does wireshark and or TCP function to detect and discard the duplicates?
Related
The below screenshot shows the relevant packets I am analysing, which are independent from the rest of the network traffic.
I know that this is malformed network traffic, however I am confused as to why the correct values should be [RST,ACK] Seq = 1 Ack = 1 ... in oppose to the values seen in the screen shot for packet 8.
Any help would be appreciated, as most of the online documentation and explanations I have read, have not given a concrete explanation.
According to RFC 793, page 37:
In the SYN-State (The sender sent a segment with SYN flag, packet 7), The received RST segment (packet 8) is acceptable if the ACK field acknowledges the SYN.
So, packet 8 is malformed and not acceptable for sender of SYN segment, because ACK field is here 0 (relative) instead of 1.
i want to know the difference between sr() and sniff()
i will clear myself:
when i send packets with sr() and then print the answer, it's giving me just one packet:
Received 1 packets, got 1 answers, remaining 0 packets
[(<IP frag=0 ttl=64 proto=tcp dst=216.58.210.4 |<TCP sport=37945 dport=http seq=1 ack=1477254816 flags=A |<Raw load='GET /index.html HTTP/1.0 \n\n' |>>>, <IP version=4L ihl=5L tos=0x0 len=40 id=1338 flags= frag=0L ttl=128 proto=tcp chksum=0xe12d src=216.58.210.4 dst=192.168.233.128 options=[] |<TCP sport=http dport=37945 seq=1477254816 ack=28 dataofs=5L reserved=0L flags=A window=64240 chksum=0x5528 urgptr=0 |<Padding load='\x00\x00\x00\x00\x00\x00' |>>>)]
but when i do the same with sniff i got alot more packets, and one of them its the packet with the answer i asked:
<Ether dst=00:0c:29:bb:8e:79 src=00:50:56:e9:b8:b1 type=0x800 |<IP version=4L ihl=5L tos=0x0 len=537 id=1339 flags= frag=0L ttl=128 proto=tcp chksum=0xdf3b src=216.58.210.4 dst=192.168.233.128 options=[] |<TCP sport=http dport=37945 seq=1477254816 ack=28 dataofs=5L reserved=0L flags=PA window=64240 chksum=0x98df urgptr=0 options=[] |<Raw load='HTTP/1.0 302 Found\r\nCache-Control: private\r\nContent-Type: text/html; charset=UTF-8\r\nLocation: http://www.google.co.il/index.html?gfe_rd=cr&ei=_geSV8u1C6Xb8AeaxJCoDQ\r\nContent-Length: 271\r\nDate: Fri, 22 Jul 2016 11:48:14 GMT\r\n\r\n<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">\n<TITLE>302 Moved</TITLE></HEAD><BODY>\n<H1>302 Moved</H1>\nThe document has moved\nhere.\r\n</BODY></HTML>\r\n' |>>>>
if you will see - the second packet have the html code i asked for (that was with sniffing it.) but wht first not have this.
You can use the lsc() in scapy bash to check out all the required commands and their usage.
sr : Send and receive packets at layer 3
sr1 : Send packets at layer 3 and return only the first answer
srp : Send and receive packets at layer 2
srp1 : Send and receive packets at layer 2 and return only the first answer
srloop : Send a packet at layer 3 in loop and print the answer each time
srploop : Send a packet at layer 2 in loop and print the answer each time
sniff : Sniff packets
send : Send packets at layer 3
sendp : Send packets at layer 2
You can use the sniff(iface ="your interface", filter = "dst aa:bb:cc:dd:ee") to get the packets that you want.
The sniff function has lots of parameters to shortlist the packets.
sr() is Send and receive packets. The function sends specific packets and then looks for the response to only those packets
sniff() acts as a sniffer and reads all of the traffic on the ethernet line, even if it is not directed towards your IP address or your specific socket that you used to send the original packet. This allows you to see other traffic on the network
I'm trying to understand how the transmission and ACK work in TCP. In this Figuure, when A retransmitt the seq 100 after he recive three duplikated ACK , B will answer with 121 ACK or 158 ACK ?
B would only be issuing the 100 ACK because it didn't receive the SEQ 121 packet. There's no evidence that it received the next packets either, but even if it did it isn't required to save them. So the answer depends on things that aren't specified in your question.
I am using tcpdump/wireshark to capture tcp packets while tcp client sending data to tcp server. The client simply sends 4096 bytes to server in one "send()" call. And I get different tcp packets on two sides, two packets on the sender side seem to be "compacted" on the receiver side, this conflicts with how i understand the tcp protocol and I stuck on this issue for a few days and really need some help.
Please notice the packet length in following packets:
client (sender) sends 2 packets 0Xbcac (4) and 0xbcae (5), sends 2896 + 1200 = 4096 bytes in all.
(0xbcac) 4 14:31:33.838305 192.168.91.194 192.168.91.193 TCP 2962 59750 > 9877 [ACK] Seq=1 Ack=1 Win=14720 **Len=2896** TSval=260728 TSecr=3464603 0
(0xbcae) 5 14:31:33.838427 192.168.91.194 192.168.91.193 TCP 1266 59750 > 9877 [PSH, ACK] Seq=2897 Ack=1 Win=14720 **Len=1200** TSval=260728 TSecr=3464603 0
However on the server (receiver) side, only one packet is presented, with ip.id=0xbcac and length = 4096 (receiver.packet.0xbcac = sender.packet.0xbcac + 0xbcae):
(0xbcac) 4 14:31:33.286296 192.168.91.194 192.168.91.193 TCP 4162 59750 > 9877 [PSH, ACK] Seq=1 Ack=1 Win=14720 **Len=4096** TSval=260728 TSecr=3464603 0
I'm aware that tcp is a stream protocol and data sent can be divided into packets according to MSS (or MTU), but i guess the division happens before packets are sent to NIC, thus before captured. I'm also aware that the PSH flag in packet 0xbcae lead to writing data from buffer to NIC, but that cannot explain the "compacted" packet. Also I tried in client to send 999999 bytes in one "send" call and the data are divided into small packets and sent, but still mismatch the packets captured on server side. At last I disable tcp nagle, get the same result, and ruled out that reason.
So my question is the mismatching i encountered normal? If it is, what caused this? If not, i'm using ubuntu 12.04 and ubuntu 13.10 in LAN, and what is the possible reason to this "compacted" packet?
Thanks in advance for any help!
two packets on the sender side seem to be "compacted" on the receiver
side
It looks like a case of generic receive offload or large receive offload. Long story short, the receiving network card does some smart stuff and coalesces segments before they hit the kernel, which improves performance.
To check if this is the case you can try to disable it using:
$ ethtool -K eth0 gro off
$ ethtool -K eth0 lro off
Something complementary happens on the sending side: tcp segmentation offload or generic segmentation offload.
After disabling these don't forget to reenable them: they seriously improve performance.
I am seeing in the network traces, that my client is sending the following ACK frame to the DC:
Frame: Number = 87641, Captured Frame Length = 54, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[AA-AA-AA-AA-AA-AA],SourceAddress:[AA-AA-AA-AA-AA-AA]
+ Ipv4: Src = XXX.XXX.XXX.XXX(CLIENT), Dest = YYY.YYY.YYY.YYY, Next Protocol = TCP, Packet ID = 26829, Total IP Length = 40
- Tcp: [Bad CheckSum]Flags=...A...., SrcPort=14229, DstPort=LDAP(389), PayloadLen=0, Seq=4175359382, Ack=1985975784, Win=1357
- SrcPort: 14229
- DstPort: LDAP(389)
- SequenceNumber: 4175359382 (0xF8DEED96)
- AcknowledgementNumber: 1985975784 (0x765F95E8)
+ DataOffset: 80 (0x50)
+ Flags: ...A....
- Window: 1357
- Checksum: 0xDEAD, Bad
- UrgentPointer: 0 (0x0)
Is the Checksum 0xDEAD an indication of something?
TCP packet checksums have no special meaning, even if their hex representations spell an English word. If the packets with a bad check-sum are a common occurrence, you should investigate the source of the packets... often running TCP offload on your NIC will break the checksums passed to the sniffer (if TCP Offload is on the NIC doing the sniffing)... however, as a general rule, bad TCP checksums could also indicate a faulty driver, faulty software, or possibly malicious activity...
As a side note, faulty ethernet frame checksums may indicate a bad NIC, bad cable, or possible malicious activity as well.