From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11D36C433B4 for ; Tue, 27 Apr 2021 02:35:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DD890613BC for ; Tue, 27 Apr 2021 02:35:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234394AbhD0CgC (ORCPT ); Mon, 26 Apr 2021 22:36:02 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:60037 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230516AbhD0CgA (ORCPT ); Mon, 26 Apr 2021 22:36:00 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id EAAC85C01A4; Mon, 26 Apr 2021 22:35:17 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute4.internal (MEProxy); Mon, 26 Apr 2021 22:35:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hmh.eng.br; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=vBVTQ1sbBsQfPYqIXqCK4Jv/CFy4Gq4 uQLWVxvxQRJU=; b=VIuBHyCvI32XasUXpVQ+THVqFZg6Z12Z5UAbWKR/SVWGtWI YmW3qVMEuIiwK3g7+ApWYMsrbyPWw2/G7Cnb4d9zfevz92aef025s2LIVXHkjcc+ sbJPrgYryt4lVOzbD6fc2SC5Rm49Sfe1RpKuB6BUc5hNFlGdVRi8Eg4RSN/lOFwT AtXGEUZnuNMxMF7eUopmQngveZ5XHQm/PxJZ3z30dW5slm5Qu1cqa+X3oQx5bU3d kVCvzCN4HLhXyO36ewzuijVab7XG2ny2RqGCfr7Z8YFalH3aqwutv2BUsLSNsSGv QaFF3iomaZL9irfgIAkZWSqQS1BA6Dzfre8kZrA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=vBVTQ1 sbBsQfPYqIXqCK4Jv/CFy4Gq4uQLWVxvxQRJU=; b=ZW0TAQ915dsNWarhUYBMg4 OBL3oERjAy5Zu+MOdhPWWkRWCwpBuD7Rqligp1piFzc7xbGfa+95Tif3/2nIG23V DjYG7jHJSWaWbc473CRDDiIJ+j1rRlOL1KSpV2A1FdheLhVlt+OkufX9/8XzhJPv YzDhCvgeRx5ZrGogkbL7RBJt5E9oyRmMWZwsBMJjLokp5brFNlnXSY4bTv0Cloj8 OFuU70nT3ja14f4Wj+Eocpae0EN31IUpEpQdHs6Jn8gV5BCC6p64a5HZh7s1GO6q Xtr2RBXlrT1ZceZNlzpJ61dPRVT4MTXrm9hnEEytDy9oFSLVXRmUTIDZkTBxJurA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdduledgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfjvghn rhhiqhhuvgcuuggvucfoohhrrggvshcujfholhhstghhuhhhfdcuoehhmhhhsehhmhhhrd gvnhhgrdgsrheqnecuggftrfgrthhtvghrnhepuddvgfeikefgieehkeevveduhfevteeu heevtdduueduffekuddtffelkefftddtnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhephhhmhheshhhmhhdrvghnghdrsghr X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 75CCE51C005F; Mon, 26 Apr 2021 22:35:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-403-gbc3c488b23-fm-20210419.005-gbc3c488b Mime-Version: 1.0 Message-Id: <52f1b7a1-ff3b-41d3-a84b-badcda8a6ad6@www.fastmail.com> In-Reply-To: <8e0aa5a6-0457-ccd0-8984-9c9aaeab2228@gmail.com> References: <8e0aa5a6-0457-ccd0-8984-9c9aaeab2228@gmail.com> Date: Mon, 26 Apr 2021 23:34:55 -0300 From: "Henrique de Moraes Holschuh" To: "Eric Dumazet" , linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: Unexpected timestamps in tcpdump with veth + tc qdisc netem delay Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 26, 2021, at 14:07, Eric Dumazet wrote: > On 4/26/21 4:35 PM, Henrique de Moraes Holschuh wrote: [...] > > [root netns]: tcpdump -i vec0 -s0 -n -p net 192.168.233.0/30 > > listening on vec0, link-type EN10MB (Ethernet), capture size 262144 bytes > > 17:09:09.740681 IP 192.168.233.1 > 192.168.233.2: ICMP echo request, id 9327, seq 1, length 64 > > Here you see the packet _after_ the 250ms delay > > 17:09:09.990891 IP 192.168.233.2 > 192.168.233.1: ICMP echo reply, id 9327, seq 1, length 64 > Same here. [...] > > Adding more namespaces and VETH pairs + routing "in a row" so that the packet "exits" one veth tunnel and enters another one (after trivial routing) doesn't fix the tcpdump timestamps in the capture at the other end of the veth-veth->routing->veth-veth->routing->... chain. > > > > It looks like some sort of bug to me, but maybe I am missing something, in which case I would greatly appreciate an explanation of where I went wrong... > > That is only because you expect to see something, but you forgot that tcpdump captures TX packet _after_ netem. That was it! Thank you very much for the quick reply, and direct, precise explanation. I had completely forgotten about the qdisc running before interface timestamping, and I overlooked the fact that I did not try three netns in-a-chain with the qdiscs *in the middle netns*: I tried them in the two opposite edge netns, only. Again, thank you! -- Henrique Holschuh