[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 Michael Tuexen changed: What|Removed |Added Resolution|--- |FIXED

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #95 from Richard Russo --- (In reply to Richard Russo from comment #91) I've tested the linked patch, manually applied to 10.3, setting syncookie only mode (to trigger the condition), and the icmp limit tuned

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 Kubilay Kocak changed: What|Removed |Added Flags|mfc-stable10? |mfc-stable10+

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #94 from Michael Tuexen --- (In reply to Kubilay Kocak from comment #85) Merged to stable/10 in r322315. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #93 from commit-h...@freebsd.org --- A commit references this bug: Author: tuexen Date: Wed Aug 9 13:26:12 UTC 2017 New revision: 322315 URL: https://svnweb.freebsd.org/changeset/base/322315 Log: MFC r317208: Syncoockies

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #92 from Jonathan T. Looney --- (In reply to Richard Russo from comment #91) > For us, this may have limited effect, because our icmplim is much higher than > the default (16k) > [...] Yes, I agree it is a

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #91 from Richard Russo --- For us, this may have limited effect, because our icmplim is much higher than the default (16k), because we do want to send closed port RSTs in high volumewhen our service ports are

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #90 from Jonathan T. Looney --- (In reply to Jonathan T. Looney from comment #89) Forgot to include a link to the patch: https://reviews.freebsd.org/D11929 -- You are receiving this mail because: You are on

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 Jonathan T. Looney changed: What|Removed |Added CC|

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #88 from Richard Russo --- Also, I had intended to include a link to a similar change in the Linux kernel, https://github.com/torvalds/linux/commit/96e0bf4b5193d0d97d139f99e2dd128763d55521 (Although the

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 Richard Russo changed: What|Removed |Added CC||free...@ruka.org

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #86 from Kubilay Kocak --- Previous comment was supposed to read " comment 7 " -- You are receiving this mail because: You are on the CC list for the bug. ___

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 Kubilay Kocak changed: What|Removed |Added CC|

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 Kubilay Kocak changed: What|Removed |Added Flags||mfc-stable11+

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #83 from commit-h...@freebsd.org --- A commit references this bug: Author: tuexen Date: Thu Jun 1 08:32:35 UTC 2017 New revision: 319400 URL: https://svnweb.freebsd.org/changeset/base/319400 Log: MFC r317208: Syncoockies

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #82 from Alexandre martins --- I confirm that the workaround works for my test case. I let you develop a more complex solution to avoid data loss and/or TCP re-open on heavy load. Thank you

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #81 from commit-h...@freebsd.org --- A commit references this bug: Author: tuexen Date: Thu Apr 20 19:19:34 UTC 2017 New revision: 317208 URL: https://svnweb.freebsd.org/changeset/base/317208 Log: Syncoockies can be used in

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 Kubilay Kocak changed: What|Removed |Added URL|

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #80 from Michael Tuexen --- I put a patch under review: https://reviews.freebsd.org/D10272 If syncookies are used in case of an overflow of the syncache, its usage is restricted to the case where there was

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #79 from Sepherosa Ziehau --- (In reply to Mike Karels from comment #78) Hmm, WAIT1, WAIT2 and CLOSING will transit to TIME_WAIT, so killing them (moving to CLOSED) in the code we talked assassinates

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #78 from Mike Karels --- (In reply to Sepherosa Ziehau from comment #77) I don't think it is similar, although I haven't thought it through in great detail. For starters, there is no TIME_WAIT to

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #77 from Sepherosa Ziehau --- (In reply to Mike Karels from comment #74) Is this {FIN-WAIT-1,FIN-WAIT-2,CLOSING} to CLOSED transition by the quoted code kinda similar to TWA (RFC1337)? And would it suffer

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #76 from s...@zxy.spb.ru --- (In reply to Mike Karels from comment #74) Im don't talk "TCP wait FIN", only "TCP wait ACK=SERVER_FIN.SEQ". Server TCP have sending and not confirmed data, what reason to discard this server

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #75 from Michael Tuexen --- (In reply to Mike Karels from comment #74) I agree completely with Mike. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #74 from Mike Karels --- In responding to an earlier comment directed to me, and to the comments since: This connection is dead. Only an RST and CLOSED state apply. Data cannot be delivered to the

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #73 from Sepherosa Ziehau --- (In reply to Michael Tuexen from comment #72) IMO, transition from {FIN-WAIT-1,FIN-WAIT-2,CLOSING} to TIME_WAIT instead of CLOSED upon receiving data from a closed socket can

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #72 from Michael Tuexen --- (In reply to slw from comment #71) I'm not arguing the semantic of the TCP level ACKs. I'm saying that if a TCP stack knows that some user data can not be delivered to its

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #71 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #70) RFC: "An acknowledgment by TCP does not guarantee that the data has been delivered to the end user, but only that the receiving TCP has taken the

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #70 from Michael Tuexen --- (In reply to slw from comment #69) > "Lost" in this context is "not delivered to remote IP stack". > Not application, IP stack. The semantic of an ACK is "delivered to the remote

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #69 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #68) > Hmm. My understanding is that TCP provides a reliable bi-directional > byte-stream. > This means that no user data is lost in any of the two

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #68 from Michael Tuexen --- (In reply to slw from comment #67) > Loss of sended application data caused by close() before incoming user > data arrived? Realy? TCP don't have such claim. Hmm. My understanding

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #67 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #66) > No, the loss of data is caused by the application calling close() *before* > incoming user data arrived. Loss of sended application data caused by

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #66 from Michael Tuexen --- (In reply to slw from comment #65) > This is wrong behaviour. This is cause lost of server data. No, the loss of data is caused by the application calling close() *before*

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #65 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #64) > No. The server sends a RST and move the connection to CLOSED. The connection > is > terminated immediately from the server perspective. This is

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #64 from Michael Tuexen --- (In reply to slw from comment #63) > Accepted RST can cause silent, immediatly closing connection by client. > No acknowledged will be sent to server (in case of serevr responce

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #63 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #62) Accepted RST can cause silent, immediatly closing connection by client. No acknowledged will be sent to server (in case of serevr responce will be

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #62 from Michael Tuexen --- (In reply to slw from comment #61) I don't see why just sending a RST is not allowed. The RFC describes a graceful termination of a TCP connection. We are in a situation where it

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #61 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #60) > Well, the server knows that he has to drop incoming data, since the > application > has closed the socket and there is new data to deliver. I guess

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #60 from Michael Tuexen --- (In reply to slw from comment #59) > No, different data: server response. And no reasson to not deliver/resend > it to client. Well, the server knows that he has to drop incoming

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #59 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #58) > Linux generates a RST, not a RST-ACK. May bad, yes > You are right, user data is lost (the second part of the request). There is > no way around

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #58 from Michael Tuexen --- (In reply to slw from comment #56) > 1. Linux generated RST w/ ACK. socket don't moved to CLOSED state? Linux generates a RST, not a RST-ACK. I guess it is moved to the CLOSED

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #57 from Michael Tuexen --- (In reply to Alexandre martins from comment #55) Great. That is what I'm also testing. It seems that the trace with the long delay shows the same as my testing. However, the trace

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #56 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #54) 1. Linux generated RST w/ ACK. socket don't moved to CLOSED state? 2. This is also wrong behavior: server try to reset connection, client ignore this

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #55 from Alexandre martins --- (In reply to Michael Tuexen from comment #52) In all of my tests, the server call close() because of the error. I didn't check the shutdown(.., SHUT_WR) case.

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #54 from Michael Tuexen --- (In reply to slw from comment #51) Right. I updated the script. The behaviour hasn't changed. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #53 from Michael Tuexen --- Created attachment 181000 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=181000=edit Updated packetdrill script to show how Linux handled data on closed socket This

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #52 from Michael Tuexen --- I ran the script on Ubuntu 16.10 (kernel 4.8). Not sure if the behaviour depends on the version... @Alexandre: Can you figure out whether the server calls shutdown() or close()?

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #51 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #50) === +0.00 write(4, ..., 395) = 395 +0.00 > P. 1:396(395) ack 46 win 58 +0.00 close(4) = 0 +0.00 > F. 396:396(0) ack 46 win 58 +0.00 < P. 46:54(8) ack

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #50 from Michael Tuexen --- (In reply to Michael Tuexen from comment #49) I have added a packetdrill script to show how Linux handles the reception of data when the user called closed before the data is

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #49 from Michael Tuexen --- Created attachment 180999 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180999=edit packetdrill script to show how Linux handles data on closed socket -- You are

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #48 from s...@zxy.spb.ru --- (In reply to Mike Karels from comment #41) > Yes, if new data are received after the close, there is no way to deliver > data anywhere. If we ack it, the peer may just keep sending data, the

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #46 from Alexandre martins --- Created attachment 180996 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180996=edit Linux server, short delay between header and data Capture using

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #47 from Alexandre martins --- Created attachment 180997 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180997=edit Linux server, long delay between header and data Capture using

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #45 from s...@zxy.spb.ru --- (In reply to Alexandre martins from comment #43) Can you do additional tests in this setup? 1. Lost DATA from server, FIN and first RST 2. Lost DATA from server, FIN and TWO first RST -- You are

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #44 from Michael Tuexen --- (In reply to Alexandre martins from comment #43) Please share a .pcap file. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #43 from Alexandre martins --- I tested on Linux. Its TCP stack just continue to reset the connection by increment its sequence. -> SYN (seq 1) <- SYN/ACK (seq 80 ACK 1) -> ACK (seq 1 ACK 81)

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #42 from Sepherosa Ziehau --- (In reply to Mike Karels from comment #41) Would transition from {FIN-WAIT-1,FIN-WAIT-2,CLOSING} to TIME-WAIT for this code segment be more "appropriate" than transition to

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 Mike Karels changed: What|Removed |Added CC|

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #40 from Sepherosa Ziehau --- (In reply to Michael Tuexen from comment #33) I think the code that transit the FIN-WAIT-1 to CLOSED is this: /* * If new data are received on a connection

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #39 from Michael Tuexen --- (In reply to slw from comment #38) The text you are referring to deals with the case that the application has called shutdown(..., SHUT_WR), not close(). So the text doesn't apply

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #38 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #37) RST+ACK, in sequence of data. And don't do transition from FIN-WAIT-1 until got ACK to FIN. "All segments preceding and including FIN will be

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #37 from Michael Tuexen --- (In reply to slw from comment #36) Please note that RFC 793 defines the CLOSE operation as "I have no more data to send." So this does NOT map to the close() system call in the

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #36 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #35) > This doesn't happen because NEW data arrives and the application has called close(). So this new data cannot be delivered to the application. The TCP

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #35 from Michael Tuexen --- (In reply to slw from comment #34) > I am don't understund this. CLOSING must be only after got FIN. > FIN don't received, data in buffer don't ack, what reasson to CLOSING >

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #34 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #33) Right, FIN_WAIT_1. > Then the state is FIN-WAIT-1. Then it receives the second part of the > request. Since the socket is closed, it responds with a

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #33 from Michael Tuexen --- (In reply to slw from comment #32) The server does socket() listen() accept() read() write() close() which means it reads the first part of the request, sends the response (en

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #32 from s...@zxy.spb.ru --- server CLOSE_WAIT, not client. after application close socket server must wait for acknowledgment sended data and resend it if need. So client retransmit must be routed to existing inpcb in

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #31 from Michael Tuexen --- (In reply to slw from comment #30) The client retransmits the whole data and only acks the SYN. So he hasn't processed the FIN sent by the server. All that has been dropped. So I

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #30 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #29) I am ask again about CLOSE_WAIT state and retransmit lost replay. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #29 from Michael Tuexen --- (In reply to Julian Elischer from comment #28) No, I think even FreeBSD would behave the same as a client if the client does socket() connect() send(part1) send(part2) and the

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 Julian Elischer changed: What|Removed |Added CC|

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #27 from Michael Tuexen --- (In reply to slw from comment #24) Consider a client doing a connect() call followed by a send() call. The connect call triggers the three way handshake. Assume that the third

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #26 from s...@zxy.spb.ru --- (In reply to Alexandre martins from comment #25) Ah, I see. Like server to early discard inpcb for this connection/do incorrect state transmission (need some like CLOSE_WAIT for 2msl, I mean). For

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #25 from Alexandre martins --- (In reply to slw from comment #24) In fact, the first ACK is replayed. -> SYN (seq 1) <- SYN/ACK (seq 80 ACK 1) -> ACK (seq 1 ACK 81) -> [DATA] (seq 1 ACK 81)

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 s...@zxy.spb.ru changed: What|Removed |Added CC||s...@zxy.spb.ru --- Comment #24

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #23 from Sepherosa Ziehau --- (In reply to Michael Tuexen from comment #22) Thank you for the explanation for the ACK w/ data. As for syncookie usage. If we use syncookie it probably means two things: -

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #22 from Michael Tuexen --- (In reply to Sepherosa Ziehau from comment #21) > Hmm, do any OS's TCP stacks really send data along w/ the last ACK in the > 3-way handshake at all? Assume the the initial ACK

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #20 from Michael Tuexen --- One could add some additional logic to only accept syn-cookies if either syn-caches are not used or if they are used, there has been recently some entries dropped due to memory

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #19 from Michael Tuexen --- (In reply to Alexandre martins from comment #16) If you don't want to use syn-cookies, you can disable them by setting the sysctl variable net.inet.tcp.syncookies to 0. -- You

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #18 from Michael Tuexen --- (In reply to Sepherosa Ziehau from comment #17) Having data on the third message is fine by the TCP specification. I don't think we should drop them in general. -- You are

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #17 from Sepherosa Ziehau --- (In reply to Alexandre martins from comment #16) Well, ACK w/ data in the 3-way handshake is already _not_ a normal case; I am not sure about fast-open though. But for

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #16 from Alexandre martins --- I think it's not a good idea because, to avoid DDoS attack, firewalls limits the count of SYN packet by seconds. If the connection can be re-openned with a simple

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 Sepherosa Ziehau changed: What|Removed |Added CC|

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #14 from Michael Tuexen --- (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

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #13 from Alexandre martins --- 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

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #12 from Michael Tuexen --- I did some testing and can explain some of the aspects of the traces, especially the ones on the FreeBSD side. The client establishes the TCP connection and send the first

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 Michael Tuexen changed: What|Removed |Added Status|New |In Progress

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #11 from Michael Tuexen --- Created attachment 180829 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180829=edit packetdrill script to reproduce the duplicate accept problem This is a test script

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 Michael Tuexen changed: What|Removed |Added Summary|One TCP connection accepted |One TCP