https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #14 from Michael Tuexen <tue...@freebsd.org> --- (In reply to Alexandre martins from comment #13) > I want to remind you that the original client is a smartphone. The first time > that > I saw the problem, I made a tcpdump on the wireless box, not on the > smartphone itself. OK. That explains why the client has not processed TCP segments which were reported as received. They are just dropped between the wireless box and the smartphone. > The server response may have been delayed into the wifi process (poor signal > ?) > and takes time to reach the phone (but has already been captured into the > pcap). > The phone may have done a re-transmit because it thinks that the http request > was lost. I guess this is exactly why the client was retransmitting the complete HTTP request. Please note that the retransmission looks like the third message (an ACK) of the three way handshake. It only contains in addition some data and has the PSH bit set. Therefore it looks like such a handshake message and the server accepts it and establishes the TCP connection (again). >I just managed that to reproduce it through the scapy script on the ubuntu with >a iptables configuration that drops the TCP reset. The packetdrill script allows you to reproduce the double accept behaviour on a FreeBSD head system. I used that to figure out why it happens. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
