From owner-freebsd-current@freebsd.org Mon Nov 14 12:58:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B394FC3D78E for ; Mon, 14 Nov 2016 12:58:53 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4m.cmail.yandex.net (forward4m.cmail.yandex.net [IPv6:2a02:6b8:b030::1b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3758314EE; Mon, 14 Nov 2016 12:58:53 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp2m.mail.yandex.net (smtp2m.mail.yandex.net [IPv6:2a02:6b8:0:2519::122]) by forward4m.cmail.yandex.net (Yandex) with ESMTP id 7927220F99; Mon, 14 Nov 2016 15:58:40 +0300 (MSK) Received: from smtp2m.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp2m.mail.yandex.net (Yandex) with ESMTP id 1BDBE2300D86; Mon, 14 Nov 2016 15:58:37 +0300 (MSK) Received: by smtp2m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id nVzWqCTmdP-wbQCMKSN; Mon, 14 Nov 2016 15:58:37 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1479128317; bh=HvvWJGlcL7ovb/G5XrC2llmxZEBnHimmMFuRUrNK8a8=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=nQB9ncGCI7KiEAzZ0U7Su1mHmDkAckJaia86l+xg+s3BIf0yIV8IlEZzGTBWps3Wz eS8gG38gJUXpC0jZZGTjLVsdN0PJn5Mi0Fj5dJWqF5MR7jscHnLFL9Op/woZPbCJg7 SR+jS8gX5+CaYa3OSR6Fb/jJME1b1GdypcBWGQbA= Authentication-Results: smtp2m.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0,1 0 Subject: Re: netpfil with if_output and ip(6)_output To: Franco Fichtner , freebsd-current References: <2456B7E6-2425-4D86-A02B-33CE1EFEB608@lastsummer.de> From: "Andrey V. Elsukov" Message-ID: Date: Mon, 14 Nov 2016 15:55:59 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <2456B7E6-2425-4D86-A02B-33CE1EFEB608@lastsummer.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GPavsVsIfJHIOLa3raUMLf6g1uinuUL6u" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 12:58:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GPavsVsIfJHIOLa3raUMLf6g1uinuUL6u Content-Type: multipart/mixed; boundary="InnDANKaMfrpofl8tDIoSGa9CPuS4IjOL"; protected-headers="v1" From: "Andrey V. Elsukov" To: Franco Fichtner , freebsd-current Message-ID: Subject: Re: netpfil with if_output and ip(6)_output References: <2456B7E6-2425-4D86-A02B-33CE1EFEB608@lastsummer.de> In-Reply-To: <2456B7E6-2425-4D86-A02B-33CE1EFEB608@lastsummer.de> --InnDANKaMfrpofl8tDIoSGa9CPuS4IjOL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14.11.2016 15:24, Franco Fichtner wrote: > I've opened a review to start removal of if_output from the > pf code with a conservative first batch, which would eventually > enable ipfw and pf redirect packets using the same PACKET_TAG_IPFORWARD= > mechanism. It was met with multiple opinions, but no agenda out > of the current situation: >=20 > https://reviews.freebsd.org/D8109 >=20 > Since the discussion went stale, I would like to pose three > questions to a wider audience: >=20 > Is there interest in keeping the netpfil framework consistent > for use with either ipfw or pf? >=20 > Is there interest in keeping the netpfil framework consistent > for use with ipfw and pf running at the same time? >=20 > Is there anyone willing to review and guide work towards > correcting these oddities? Hi, I have some thought related to your proposal. What you think if we will introduce new KPI to work with fwd_tags? With such KPI we can make fwd_tags opaque for PFIL consumers and handle tags identically in all *proto*_output() routines. For first glance I can propose the following: /* ip_var.h */ #define IP_HAS_NEXTHOP(m) ((m)->m_flags & M_IP_NEXTHOP) int ip_set_fwdtag(struct mbuf *m, struct sockaddr_in *dst, u_short ifidx); int ip_get_fwdtag(struct mbuf *m, struct sockaddr_in *dst, u_short *ifidx); void ip_flush_fwdtag(struct mbuf *m); /* ip6_var.h */ #define IP6_HAS_NEXTHOP(m) ((m)->m_flags & M_IP6_NEXTHOP) int ip6_set_fwdtag(struct mbuf *m, struct sockaddr_in6 *dst, u_short ifidx); int ip6_get_fwdtag(struct mbuf *m, struct sockaddr_in6 *dst, u_short *ifidx); void ip6_flush_fwdtag(struct mbuf *m); Since I'm not quite aware how PF handles PACKET_TAG_IPFORWARD tags, you can modify this to fully cover its needs. --=20 WBR, Andrey V. Elsukov --InnDANKaMfrpofl8tDIoSGa9CPuS4IjOL-- --GPavsVsIfJHIOLa3raUMLf6g1uinuUL6u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEvBAEBCAAZBQJYKbRfEhxidTdjaGVyQHlhbmRleC5ydQAKCRABxeoEEMiheoGC B/0TlXfSNt1dVIyga6rJxbLBXIJYT5t1549te0gV74HtXPkJRcAi1HaK7WFiW1c+ xCJu4E9MmqQrIOIy1kH5nQqPTVyA7OijSdLfOi6USZngks7M6iQ5lGJnVJDO0N6F 0S3I0dBSzHTzk05+141D0h0K8uKRPOv//oEp3TTmTicJJ99BS31kMUuYq3kTT3R3 TuKa0INMQdO7RcoPrVEB+9GBNo+WPRr9bjgfjAZGoIo744M+yGFHiB8E1V3U437P NPFg1V1x8qfpZdAKG1VIcLKQrGJcIG6qW/LvfQVdK3vHn+B+Pz2wC2nOy3Pl2/dh NpLtGwLyP/+3sJcBw+BT7hqq =veKh -----END PGP SIGNATURE----- --GPavsVsIfJHIOLa3raUMLf6g1uinuUL6u--