On Tue, 2018-10-09 at 14:37 +0000, André Paulsberg-Csibi (IBM Consultant) wrote: > > First off like you mentioned it is weird the SERVICE side sends the > FIN first , it almost always the CLIENT side that initiates this for > normal TCP session like used in HTTPS and HTTP . While I am not at all arguing with your experience, I find this odd. If you think about a typical HTTP GET transaction for example, the CLIENT asks the SERVICE for something which causes the SERVICE to open a file (say), read it's contents and write them to the socket and then to close the file and the socket once it has done the last write. That would initiate the FIN from the SERVICE would it not? > What is more also strange is there is no visible ACK for any of the > last 2 PSH,ACK packets with data back from the SERVICE ( packets at > 19:59:05.676219 & 19:59:05.676553 ) Yes, that's true. > Combined with the first FIN ( 19:59:05.676712 ) which is only 0.159 > ms after last data was sent and and would not allow for a "normal" > ACK to arrive . > The FIN is also re-transmitted ( 19:59:05.742295 )which as another > 65.583 ms after first FIN . > After this you have multiple re-transmits for the "first" of the > "failed" PSH,ACK ( packet at 19:59:05.676219 ) which is because none > of the 2 packets received any ACK according to the tcpdump Agreed. Really seems like a bad client. Or a client that lost it's network connection right before being able to finish that connection. > It is also weird that it retries so many times that the retry last 8 > minutes and 5 seconds , however it explains why the packets gets > logged since the last longer then the 30 seconds default window > before session table is cleared after a "normal" session FIN/ACK > closure , But the session above where the CLIENT didn't properly close the session is not a "normal" session FIN/ACK. Is that 30 second window the same for that case also? > That would rather be a "last resort" if I could not find out why this > sessions to not closed "normally" But this could just be a bad client or a client that lost it's network connectivity, etc. All things that conntrack ought to try to do the right thing with, yes? > ( Or why the SERVICE retries a session it self sent FIN for more then > 8 minutes ago ) Well, it's just being persistent about trying to get the CLIENT to close it's end wouldn't you say? > I noticed also the CLIENT have "low" MTU as it reports mss=1220 bytes > , while the SERVICE have a more "normal" MTU with mss=1440 bytes The > SYN-SN/ACK-ACK have approx 12ms and 48 ms latency , but other times > the ACKs seems to be closer to 1ms and 10ms . > May not be relevant , but noticed and would suggest that if possible > one should try to recreate the issue on 2 hosts you control ... I can't even recreate it on demand on hosts I can't control and have no idea what kind of host SERVICE is in this case. > Could be that there is some strange packetloss that triggers the > issue that you might solve that and remove both that packetloss > itself improving performance and most logs you see . I guess I could do a capture of both the LAN and WAN side of the iptables router and see if what's going out to the WAN at least reflects what's coming into the LAN. Cheers, b.
Attachment:
signature.asc
Description: This is a digitally signed message part
