From owner-freebsd-ipfw@freebsd.org Sun Jul 8 09:45:33 2018 Return-Path: Delivered-To: freebsd-ipfw@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 59326102F554 for ; Sun, 8 Jul 2018 09:45:33 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward106o.mail.yandex.net (forward106o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::609]) (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 C7B498C3E8 for ; Sun, 8 Jul 2018 09:45:32 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback6o.mail.yandex.net (mxback6o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::20]) by forward106o.mail.yandex.net (Yandex) with ESMTP id AF3CA78208A; Sun, 8 Jul 2018 12:45:21 +0300 (MSK) Received: from smtp4o.mail.yandex.net (smtp4o.mail.yandex.net [2a02:6b8:0:1a2d::28]) by mxback6o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 8UK5sgPEna-jLUSNdKb; Sun, 08 Jul 2018 12:45:21 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1531043121; bh=JGDxwGn6u0HTmcioclxj/fWQJeDBgZELL+bV/XpDH0c=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=LeoYDCCCGPj4m6zuzsjgO/VpTMFOQHq+Na4/ZEzu5BzWfii36qOfwQLJbZUSQgvNU lVdJwYPdpZhHa/iV8MyYzC+2ma9ZBfvc2cSM+sIuun27yJbNsqwG2w33eN9hrmccE/ 7Y/9rA/du+UWDzoghQJe32Fj4geLrhkMCvY4mQpM= Received: by smtp4o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id yu0t0dllqu-jLMO7pNZ; Sun, 08 Jul 2018 12:45:21 +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=1531043121; bh=JGDxwGn6u0HTmcioclxj/fWQJeDBgZELL+bV/XpDH0c=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=LeoYDCCCGPj4m6zuzsjgO/VpTMFOQHq+Na4/ZEzu5BzWfii36qOfwQLJbZUSQgvNU lVdJwYPdpZhHa/iV8MyYzC+2ma9ZBfvc2cSM+sIuun27yJbNsqwG2w33eN9hrmccE/ 7Y/9rA/du+UWDzoghQJe32Fj4geLrhkMCvY4mQpM= Authentication-Results: smtp4o.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: ipfw uid/gid debugging, tcpdump relation with ipfw and how to block direct access to port 25 To: supportsobaka@mail.ru, freebsd-ipfw@freebsd.org References: <1530707289.696086711@f198.i.mail.ru> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= xsBNBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAHNIkFuZHJleSBWLiBFbHN1a292IDxhZUBmcmVlYnNkLm9yZz7CwHsEEwECACUCGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheABQJMB/ruAhkBAAoJEAHF6gQQyKF6MLwH/3Ri/TZl9uo0 SepYWXOnxL6EaDVXDA+dLb1eLKC4PRBBjX29ttQ0KaWapiE6y5/AfzOPmRtHLrHYHjd/aiHX GMLHcYRXD+5GvdkK8iMALrZ28X0JXyuuZa8rAxWIWmCbYHNSBy2unqWgTI04Erodk90IALgM 9JeHN9sFqTM6zalrMnTzlcmel4kcjT3lyYw3vOKgoYLtsLhKZSbJoVVVlvRlGBpHFJI5AoYJ SyfXoN0rcX6k9X7Isp2K50YjqxV4v78xluh1puhwZyC0p8IShPrmrp9Oy9JkMX90o6UAXdGU KfdExJuGJfUZOFBTtNIMNIAKfMTjhpRhxONIr0emxxDOwE0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAcLAXwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: Date: Sun, 8 Jul 2018 12:45:08 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1530707289.696086711@f198.i.mail.ru> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QrmUWCyEz9kqhaL93FWmWLaaBG8luEmxq" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 09:45:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QrmUWCyEz9kqhaL93FWmWLaaBG8luEmxq Content-Type: multipart/mixed; boundary="AOSJknC0LPnGpHJvA9WIxhQqGqGSbD4qy"; protected-headers="v1" From: "Andrey V. Elsukov" To: supportsobaka@mail.ru, freebsd-ipfw@freebsd.org Message-ID: Subject: Re: ipfw uid/gid debugging, tcpdump relation with ipfw and how to block direct access to port 25 References: <1530707289.696086711@f198.i.mail.ru> In-Reply-To: <1530707289.696086711@f198.i.mail.ru> --AOSJknC0LPnGpHJvA9WIxhQqGqGSbD4qy Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04.07.2018 15:28, supportsobaka--- via freebsd-ipfw wrote: > Could you please explain whether tcpdum should see a packet dropped > on ipfw?=20 tcpdump is not related to ipfw. ipfw(4) has ability to send packets, that are matched by rules with "log" opcode to special ipfw0 pseudo interface. This interface can be created at run-time. Then, you can add "log" keyword to the deny rule and see such packets in `tcpdump -ni ipfw0` output. Simple example: # ifconfig ipfw0 create # ipfw add 1 deny log icmp from me to any # ping 127.1 # tcpdump -ni ipfw0 12:21:19.222133 IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 64151, seq 0, length 64 12:21:20.230762 IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 64151, seq 1, length 64 > Does it look before or after ipfw? tcpdump -vvv port 25 > shows nothing when port is blocked on ipfw (security log shows droped tcpdump works at layer2 level. The kernel sends packets to BPF when it goes through ethernet handling routines. ipfw(4) usually works at layer3 level, i.e. when Ethernet layer already did, or not yet did its work. Anyway, you can not see dropped packets if you did not prepared to this like I described. > packets). Also, is there a way to to see uid/gid on the packet in > ipfw log? Alternatively, can tcpdump show uid/gid of the packet > (before ipfw)? I don't see uid/gid when use tcpdump -vvv port 25. Is > there a way to understand if packet does't have uid/gid or it just > not shown? I can't figure out a good rule to protect access to port tcpdump has not such ability or knowledge. > 25 for other than sendmail (yep, native sendmail). The obvious=20 > ${ipfw} add allow tcp from me to any 25 out gid smmsp setup > keep-state :emailfromme doesn't work (email is not sent out,but > dropped on the ipfw by the last deny rule). Seems like the packet how do you test this? > sent by sendmail doesn't belong to snmmsp group. I have tried gid > operator gid mail gid smmsp gid wheel - won't help. How to debug? --=20 WBR, Andrey V. Elsukov --AOSJknC0LPnGpHJvA9WIxhQqGqGSbD4qy-- --QrmUWCyEz9kqhaL93FWmWLaaBG8luEmxq 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/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAltB3SkACgkQAcXqBBDI oXq+GQf/X3lQIA0/gxprTTA/861IIP2Kl4h57Rsd3Cg9AjzjvkWvTLP5csMNVHgG 95Ko5z3hAGYqEM2/2/eoz2cfYtZxAQ07RSl6EpAaKACj8B7xKlwAnGLcQW0Hg8nP qW9itzSKE8B7TuPRQGn0au+A4RJXBFaygxycRYhokVMobGSG8FePUKaEGvxtnlLj 1UTePtouSIG7g3Lf7QZ3JSRuGzIpNmnFTI9RzQS6V67cDLlgJU6KBh/cObbrzUrU QXMzQCQsuIUy27UYI6nwDAmehKKenFOFj8zrh/MYNNQQXt0HcNAxfmDr20EQp/cq ReTEWrdb3Z/CRiIgEGJSJtIbttyzhA== =q8WH -----END PGP SIGNATURE----- --QrmUWCyEz9kqhaL93FWmWLaaBG8luEmxq-- From owner-freebsd-ipfw@freebsd.org Sun Jul 8 14:43:23 2018 Return-Path: Delivered-To: freebsd-ipfw@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 750DD102B4B8 for ; Sun, 8 Jul 2018 14:43:23 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8DD9D7752F for ; Sun, 8 Jul 2018 14:43:22 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w68EhHgq061785; Sun, 8 Jul 2018 07:43:18 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w68EhGD0061784; Sun, 8 Jul 2018 07:43:16 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201807081443.w68EhGD0061784@pdx.rh.CN85.dnsmgr.net> Subject: Re: ipfw uid/gid debugging, tcpdump relation with ipfw and how to block direct access to port 25 In-Reply-To: To: "Andrey V. Elsukov" Date: Sun, 8 Jul 2018 07:43:16 -0700 (PDT) CC: supportsobaka@mail.ru, freebsd-ipfw@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 14:43:23 -0000 > On 04.07.2018 15:28, supportsobaka--- via freebsd-ipfw wrote: > > Could you please explain whether tcpdum should see a packet dropped > > on ipfw? In general NO, ipfw well not see a packet that is "deny" or "drop" by ipfw, as the bpf code is called after ipfw. > > tcpdump is not related to ipfw. > ipfw(4) has ability to send packets, > that are matched by rules with "log" opcode to special ipfw0 pseudo > interface. This interface can be created at run-time. Then, you can add > "log" keyword to the deny rule and see such packets in `tcpdump -ni > ipfw0` output. One of the reasons to have the ipfw0 pseudo device is so that these dropped packets can be seen by tcpdump. > Simple example: > > # ifconfig ipfw0 create > # ipfw add 1 deny log icmp from me to any > # ping 127.1 > # tcpdump -ni ipfw0 > 12:21:19.222133 IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 64151, > seq 0, length 64 > 12:21:20.230762 IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 64151, > seq 1, length 64 > > > Does it look before or after ipfw? tcpdump -vvv port 25 > > shows nothing when port is blocked on ipfw (security log shows droped After ipfw > tcpdump works at layer2 level. The kernel sends packets to BPF when it > goes through ethernet handling routines. > ipfw(4) usually works at layer3 level, i.e. when Ethernet layer already > did, or not yet did its work. Anyway, you can not see dropped packets if > you did not prepared to this like I described. IIRC tcpdump hooks at the same points as ipfw, just ipfw hooks first. ipfw(3) works at both layer2 and 3 depending on the rule as you can do mac level filtering, and there is even a layer2 option keyword so you can control if your rule is applied at when the packet traverses certain points in the kernel. NOTE that ipfw can see the same packet up to 4 times so you have to be careful if you turn on certain options and start to do layer2 filtering. There is a description of this in the man page ipfw(4) in the PACKET FLOW section. > > packets). Also, is there a way to to see uid/gid on the packet in > > ipfw log? Alternatively, can tcpdump show uid/gid of the packet > > (before ipfw)? I don't see uid/gid when use tcpdump -vvv port 25. Is > > there a way to understand if packet does't have uid/gid or it just > > not shown? I can't figure out a good rule to protect access to port > > tcpdump has not such ability or knowledge. And it appears as if ipfw does not log this info when it does have it avaliable and a rule that matches with the log option is present. This should probably be added as a feature to assist in debugging. > > 25 for other than sendmail (yep, native sendmail). The obvious > > ${ipfw} add allow tcp from me to any 25 out gid smmsp setup > > keep-state :emailfromme doesn't work (email is not sent out,but > > dropped on the ipfw by the last deny rule). Seems like the packet > > how do you test this? > > > sent by sendmail doesn't belong to snmmsp group. I have tried gid > > operator gid mail gid smmsp gid wheel - won't help. How to debug? > > -- > WBR, Andrey V. Elsukov -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-ipfw@freebsd.org Sun Jul 8 21:00:46 2018 Return-Path: Delivered-To: freebsd-ipfw@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 128261030EF6 for ; Sun, 8 Jul 2018 21:00:46 +0000 (UTC) (envelope-from bugzilla-noreply@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 A10658AFC4 for ; Sun, 8 Jul 2018 21:00:45 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 623C11030EED; Sun, 8 Jul 2018 21:00:45 +0000 (UTC) Delivered-To: ipfw@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 500421030EEC for ; Sun, 8 Jul 2018 21:00:45 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E37558AFBB for ; Sun, 8 Jul 2018 21:00:44 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 2F3EA19B07 for ; Sun, 8 Jul 2018 21:00:44 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w68L0iPR049398 for ; Sun, 8 Jul 2018 21:00:44 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w68L0i8x049391 for ipfw@FreeBSD.org; Sun, 8 Jul 2018 21:00:44 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201807082100.w68L0i8x049391@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: ipfw@FreeBSD.org Subject: Problem reports for ipfw@FreeBSD.org that need special attention Date: Sun, 8 Jul 2018 21:00:44 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 21:00:46 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 215875 | [ipfw] ipfw lookup tables do not support mbuf_tag 1 problems total for which you should take action. From owner-freebsd-ipfw@freebsd.org Thu Jul 12 17:42:27 2018 Return-Path: Delivered-To: freebsd-ipfw@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 3B8A9102BAB6 for ; Thu, 12 Jul 2018 17:42:27 +0000 (UTC) (envelope-from bugzilla-noreply@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 C9D4B753F2 for ; Thu, 12 Jul 2018 17:42:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8DCFD102BAAE; Thu, 12 Jul 2018 17:42:26 +0000 (UTC) Delivered-To: ipfw@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 79EF9102BAAD for ; Thu, 12 Jul 2018 17:42:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12C8C753EB for ; Thu, 12 Jul 2018 17:42:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 6F3382A680 for ; Thu, 12 Jul 2018 17:42:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w6CHgPf1097145 for ; Thu, 12 Jul 2018 17:42:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w6CHgPFG097144 for ipfw@FreeBSD.org; Thu, 12 Jul 2018 17:42:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ipfw@FreeBSD.org Subject: [Bug 148091] [ipfw] ipfw ipv6 handling broken. Date: Thu, 12 Jul 2018 17:42:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.1-PRERELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cem@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Unable to Reproduce X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 17:42:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D148091 Conrad Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed CC| |cem@freebsd.org Resolution|--- |Unable to Reproduce --=20 You are receiving this mail because: You are the assignee for the bug.=