I use raw socket to create TCP packets, with focus on the sequence number and TCP flags(SYN, ACK)
I used one machine S to send a tcp ACK packet (flag ACK is set to 1) and another machine R to receive it these two machines are in different subnets, all in my school
meanwhile, I used tcpdump to capture the packets.
Strange things happens! On machine S, the captured packet is as expected, it is an ACK packet however, on the receiving machine R, the packet becomes a SYN packet, and the sequence number is changed, the seq no is 1 smaller the expected and the ack_seq become 0!
what are potential problems?
my guess is that the router/firewall modified the ACK packet to a SYN packet because it never sees a SYN SYN/ACK exchange ahead of the ACK?
is it possible or not?
the two captured packets are:
https://docs.google.com/file/d/0B09y_TWqTtwlVnpuUlNwUmM1YUE/edit?usp=sharing
https://docs.google.com/file/d/0B09y_TWqTtwlTXhjUms4ZnlkMVE/edit?usp=sharing
The biggest problem you will encounter will be that the receiving TCP stack in each case will receive the packet and possibly reply to it. What you are attempting is really not possible.
Related
When I was doing my network lab, I catched these tcp packets. I use gns3 to simulate the network, use the iperf3 to generate tcp packets.
iperf3 -c 10.0.3.33 -t 30
I do not know why there are so many ack packets, as well as high ack payload.
Piggybacking of acknowledments:The ACK for the last received packet need not be sent as a new packet, but gets a free ride on the next outgoing data frame(using the ACK field in the frame header). The technique is temporarily delaying outgoing ACKs so that they can be hooked on the next outgoing data frame is known as piggybacking. But ACK can't be delayed for a long time if receiver(of the packet to be acknowledged) does not have any data to send.
I'm troubleshooting a MTU/MSS issue that is causing fragmentation over a PPPoE service. Below is a packet dump of a TCP 3-Way Handshake from a different service (that is working as expected) that relates to my question.
I understand the way PMTUD works as this: by setting the Don't Fragment (DF) bit to 1 in the IP header, a router along the path to the destination that requires fragmentation of the packet sends an ICMP back to the host to adjust the MSS size accordingly. However, my understanding is that this will only happen when fragmentation occurs (packets greater than the path MTU). This suggests that PMTUD works during the data exchange phase, NOT when TCP 3-Way Handshake is negotiated (since these are small packets, 78 bytes in this case).
In the above packet capture the SYN packet sends a MSS=1460 (which is too large, due to the 8 byte overhead of PPPoE) and the SYN/ACK response from the server sends back the correct MSS=1452. What mechanism does TCP use to determine the MSS during this exchange?
Maybe, the server hasn't computed the MSS during this three-way handshake. For instance, if the system administrator has observed a lot of fragmentation, he can have set the MSS of the whole system to 1452 (with the command ip tcp adjust-mss 1452), so when you are doing the three-way handshake, the server only advertises its default MSS. Is it applicable to your case?
What you're probably seeing here is the result of what's known as MSS clamping where the network on which the server is attached to modifies the MSS in the outgoing SYN/ACK packets to signal to the sender to use a lower MSS. This is commonly done on networks that perform some form of tunnelling such as PPPoE on ADSL.
I'm filtering packets with libpcap with a filter like "tcp src localhost". It filters all the packets whose source is localhost (my host).
When localhost doesn't receive a TCP confirmation of an already sendt packet, localhost will forward the packet.
Not all the packets filtered by libpcap will arrive to its destination, and I need to identify when a packet is a "forwarded packet". Is there any way with libpcap to identify a forwarded packet?
By my understanding, you're looking for TCP retransmissions. These can be found by display fitters in wireshark after capturing. These two should help you:
Retransmitted packets can be found through the display filter tcp.analysis.retransmission (more such filters).
When the receiver gets an out-of-order packet (usually indicates lost packet), it sends a ACK for the missing seq number. This is a duplicate ACK and these can be found by using tcp.analysis.duplicate_ack (details).
if there is a tcp connection between A and B,
A send some packets and then a TCP RST(or TCP FIN/ACK) to close the connection,
let me say?
PKT1, PKT2, PKT3, TCP_RST
or
PKT1, PKT2, PKT3, TCP_FIN/ACK
but the packet arrival is out of order
PKT1, TCP_RST(or TCP_FIN/ACK), PKT2, PKT3
then how will B react?
according to the sequence number of TCP_RST and TCP_FIN/ACK,
B knows there are some packets missing(PKT2 and PKT3),
will B wait for PKT2 and PKT3 before it close the connection,
or B immediately close the connection when it receives TCP_RST(or TCP_FIN/ACK)?
thanks
The TCP protocol will reorder the packets before sending them further up the stack. This means it will wait for out of order packets according to the sequence number, ask for retransmission if needed, etc. and wait for the last ack before closing the connection.
You can find the TCP state diagram here:
http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html#ST
TCP guarantees sequence. That includes the sequence of the EOS. It must be delivered after all the data.
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.