>> Hi Henrich, >> >> Thanks a lot for confirming the issue on 7.7. >> >> Scapy might support IPv6 using `IPv6(dst=target_ip)`, but >> unfortunately, I don’t have an IPv6 testing environment right now, so >> I couldn’t verify it myself. >> >> Also, when running the Scapy script, I added a rule with >> `iptables -A OUTPUT -p tcp --dport <dst_port> --tcp-flags RST RST -j DROP` >> to prevent the kernel from sending RST packets. This is likely because >> Scapy doesn't request the port via the kernel stack, so the OS tries >> to shutdown the unrequested connection. >> >> By the way, do you have any thoughts on the impact of this issue? >> Would it need a fix, and is there anything we can help with from our >> side? >> >> Best, >> Ruinan > > Hi Ruinan, > > I'm not sure how significant it is, but I'm not actually an OpenBSD > developer. No commit access or significant time with OpenBSD (just been > using it since 7.6.) > > I would CC the bugs@ list to see if we can get more feedback from actual > developers on it. > > Do you happen to know if Linux or FreeBSD behave this way as well? > > When I tested, I just used localhost. I assume the same would work for > IPv6 as well. Of course testing it for real, off localhost, might > provide more data. > > -Henrich
Hi Henrich, Following your advice, I also tested the script on Linux, and attached the trace at the end of this email. It shows that Linux refuses to accept the FIN+ACK packet with an incorrect ack number (smaller than 0). I've also CC this message to bugs@, which I forgot to include in the previous one. In the tcpdump output you previously shared, I noticed that the client side (port 46346) was sending several RST packets. This is likely because my Scapy script send raw packets directly and does not register the connection with the kernel TCP stack. For this reason, adding the iptables command I mentioned earlier might help reproduce the issue - whether testing remotely or on localhost. I agree with you that this issue likely work for IPv6 as well, since it appears to happen at the TCP layer. Tcpdump trace from Linux: 11:00:43.185709 IP 192.168.31.251.47262 > 192.168.31.230.12350: Flags [S], seq 1924942564, win 64224, options [mss 1460,nop,eol], length 0 11:00:43.185738 IP 192.168.31.230.12350 > 192.168.31.251.47262: Flags [S.], seq 913229124, ack 1924942565, win 64240, options [mss 1460], length 0 11:00:43.212364 IP 192.168.31.251.47262 > 192.168.31.230.12350: Flags [.], ack 1, win 502, length 0 11:00:43.238835 IP 192.168.31.251.47262 > 192.168.31.230.12350: Flags [F.], seq 1, ack 4294967292, win 502, length 0 11:00:43.238879 IP 192.168.31.230.12350 > 192.168.31.251.47262: Flags [.], ack 1, win 64240, length 0 11:00:43.557435 IP 192.168.31.251.47262 > 192.168.31.230.12350: Flags [.], ack 2, win 502, options [nop,nop,eol], length 0 -Ruinan
