From owner-freebsd-dtrace@freebsd.org Sat Jun 23 11:57:27 2018 Return-Path: Delivered-To: freebsd-dtrace@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF9B7101DD2C for ; Sat, 23 Jun 2018 11:57:26 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 702E07FDB5 for ; Sat, 23 Jun 2018 11:57:26 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 30F21101DD2A; Sat, 23 Jun 2018 11:57:26 +0000 (UTC) Delivered-To: dtrace@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E8BF101DD29 for ; Sat, 23 Jun 2018 11:57:26 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9125B7FDA6 for ; Sat, 23 Jun 2018 11:57:25 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2003:cd:6f20:4400:3d4a:dbbe:9e48:43bb] (p200300CD6F2044003D4ADBBE9E4843BB.dip0.t-ipconnect.de [IPv6:2003:cd:6f20:4400:3d4a:dbbe:9e48:43bb]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 9B93F721E2825; Sat, 23 Jun 2018 13:57:23 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: receive probes From: Michael Tuexen In-Reply-To: <88747828-2ECD-42A1-BB41-6108F37146DE@neville-neil.com> Date: Sat, 23 Jun 2018 13:57:22 +0200 Cc: dtrace@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4388B5A4-95EF-49E7-817E-E36B3E8E7CD4@freebsd.org> References: <88747828-2ECD-42A1-BB41-6108F37146DE@neville-neil.com> To: George Neville-Neil X-Mailer: Apple Mail (2.3445.8.2) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 11:57:27 -0000 > On 23. Jun 2018, at 13:28, George Neville-Neil = 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 = 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