From nobody Sat Jul 31 23:51:58 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 09C5C12D5463 for ; Sat, 31 Jul 2021 23:53:24 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gch0z2Lvzz3jnc for ; Sat, 31 Jul 2021 23:53:23 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.org [185.220.148.12]) by uucp.dinoex.org (8.16.1/8.16.0.50) with ESMTPS id 16VNqupR009131 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 1 Aug 2021 01:52:56 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: X-Authentication-Warning: uucp.dinoex.sub.de: Host uucp.dinoex.org [185.220.148.12] claimed to be uucp.dinoex.sub.de Received: (from uucp@localhost) by uucp.dinoex.sub.de (8.16.1/8.16.0.50/Submit) with UUCP id 16VNquae009130 for freebsd-hackers@freebsd.org; Sun, 1 Aug 2021 01:52:56 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.intra.daemon.contact (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.16.1/8.16.1) with ESMTP id 16VNqfZ7047363 for ; Sun, 1 Aug 2021 01:52:41 +0200 (CEST) (envelope-from peter@gate.intra.daemon.contact) Received: from gate.intra.daemon.contact (gate-e [192.168.98.2]) by gate.intra.daemon.contact (8.16.1/8.16.1) with ESMTPS id 16VNpwn7047253 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 1 Aug 2021 01:51:58 +0200 (CEST) (envelope-from peter@gate.intra.daemon.contact) Received: (from peter@localhost) by gate.intra.daemon.contact (8.16.1/8.16.1/Submit) id 16VNpw1T047252 for freebsd-hackers@freebsd.org; Sun, 1 Aug 2021 01:51:58 +0200 (CEST) (envelope-from peter) Date: Sun, 1 Aug 2021 01:51:58 +0200 From: Peter To: freebsd-hackers@freebsd.org Subject: TAP device deletes VLAN tag? (netgraph related) Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 185.220.148.12; Sender-helo: uucp.dinoex.sub.de;) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [185.220.148.12]); Sun, 01 Aug 2021 01:52:58 +0200 (CEST) X-Rspamd-Queue-Id: 4Gch0z2Lvzz3jnc X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pmc@citylink.dinoex.sub.org has no SPF policy when checking 2a0b:f840::12) smtp.mailfrom=pmc@citylink.dinoex.sub.org X-Spamd-Result: default: False [-0.92 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.81)[-0.811]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-0.01)[-0.012]; DMARC_NA(0.00)[sub.org]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:205376, ipnet:2a0b:f840::/32, country:DE]; RCVD_TLS_LAST(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-ThisMailContainsUnwantedMimeParts: N Sending here since "stable" still doesn't work... Hi all, I found a problem when connecting tap devices. In the most straightforward way I would do # ngctl connect tap1: fxp0: lower lower Then doing tcpdump on both netifs, the originating (in my case tap0) has the VLAN tag, and the receiving doesn't show it anymore. The same happens when attaching a tap device to a ng_bridge or ng_hub: the tap device (and the bhyve behind it) will not see the VLAN tags arriving from elsewhere on the bridge. The tap device itself seems to support vlan tags. So the problem appears to be most likely related to the netgraph hook of the tap device (the lower, in my case). This is Rel. 12.2 running. Is this a known problem? Is there a patch or workaround known? rgds, PMc