Date: Sat, 23 Jun 2018 13:57:22 +0200 From: Michael Tuexen <tuexen@freebsd.org> To: George Neville-Neil <gnn@neville-neil.com> Cc: dtrace@freebsd.org Subject: Re: receive probes Message-ID: <4388B5A4-95EF-49E7-817E-E36B3E8E7CD4@freebsd.org> In-Reply-To: <88747828-2ECD-42A1-BB41-6108F37146DE@neville-neil.com> References: <A3C0DAD3-9313-407F-B3CF-207A0B3309B2@freebsd.org> <AE000234-DE9A-47B2-87B4-65EE813D7C16@neville-neil.com> <A84321A1-96B7-48D3-94FD-4ABD364CECEA@freebsd.org> <88747828-2ECD-42A1-BB41-6108F37146DE@neville-neil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 23. Jun 2018, at 13:28, George Neville-Neil <gnn@neville-neil.com> = wrote: >=20 >=20 >=20 > On 23 Jun 2018, at 19:17, Michael Tuexen wrote: >=20 >>> On 23. Jun 2018, at 11:21, George Neville-Neil = <gnn@neville-neil.com> wrote: >>>=20 >>>=20 >>>=20 >>> On 19 Jun 2018, at 5:17, Michael Tuexen wrote: >>>=20 >>>> Dear all, >>>>=20 >>>> when should receive probes for the TCP and UDP network provider = fire? >>>>=20 >>>> I would expect it to fire whenever a non-malformed packet is = received. >>>> Is that the intention? >>>>=20 >>>=20 >>> Of the appropriate type of course, but yes. >> OK. Let me propose a patch for UDP and TCP and put them on = Phabricator... >>=20 >=20 > I'm wondering what you're seeing that you think needs patching. I found two things via testing to understand how things work: 1. The UDP receive provider only fires if udp_append() is called. So it does not fire, if a UDP packet is received and there is no endpoint handlign the data (in which you send out an ICMP packet indicating that the destination is unreachable because the port is unreachable). If the semantic is that the provider should fire if a packet is received it should fire. If the semantic is that the provider fires if data can be delivered to the user, it should not. But the TCP provider also fires for packets without user data, I = think the UDP provider should fire whenever a UDP packet is received. There are a couple of error cases: * We can't get the IP and UDP header in an mbuf. -> Don't fire. * Destination port is 0. -> Don't fire. * Length violation -> Don't fire. * Checksum error -> Don't fire. * In case of multicast and no enp-point point found -> Fire (needs a = fix) * In case of unicast and no end-point found -> Fire (needs a fix) * In case min TTL violated -> Fire (needs a fix) or not Fire? * In checksum coverage insufficient -> Don't fire While being there, separate out UDP and UDPLite, since they are = different protocols. So provide a UDPLite provider. 2. This is what I get when setting up and tearing down a TCP connection over lookback and using the tcpio.d script: 0 127.0.0.1:17024 -> 127.0.0.1:1234 38 (SYN) 3 127.0.0.1:17024 <- 127.0.0.1:1234 38 (SYN|ACK) 3 127.0.0.1:17024 -> 127.0.0.1:1234 30 (ACK) 5 127.0.0.1:17024 -> 127.0.0.1:1234 34 (PUSH|ACK) 0 127.0.0.1:1234 <- 127.0.0.1:17024 34 (PUSH|ACK) 1 127.0.0.1:1234 -> 127.0.0.1:17024 30 (ACK) 4 127.0.0.1:17024 <- 127.0.0.1:1234 30 (ACK) 5 127.0.0.1:17024 -> 127.0.0.1:1234 30 (FIN|ACK) 1 127.0.0.1:1234 <- 127.0.0.1:17024 30 (FIN|ACK) 1 127.0.0.1:1234 -> 127.0.0.1:17024 30 (ACK) 1 127.0.0.1:17024 <- 127.0.0.1:1234 30 (ACK) 2 127.0.0.1:1234 -> 127.0.0.1:17024 30 (FIN|ACK) 1 127.0.0.1:17024 <- 127.0.0.1:1234 30 (FIN|ACK) 1 127.0.0.1:1234 <- 127.0.0.1:17024 30 (ACK) The issues I see: * The initial SYN is not reported to be received. * The SYN|ACK is not show as being sent. * The ACK (third message of the handshake) is not reported to be = received. I guess this is related to the fact that within the TCP syn-cache = code no providers are triggered. * Also the last ACK is not reported to be sent. I would expected all of the above segments to be reported as sent and = received. Do you agree with the above expectations on the behaviour? Best regards Michael >=20 > Best,. > George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4388B5A4-95EF-49E7-817E-E36B3E8E7CD4>