From owner-freebsd-pf@freebsd.org Thu Sep 1 23:59:38 2016 Return-Path: Delivered-To: freebsd-pf@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 AAF3EBCC56A for ; Thu, 1 Sep 2016 23:59:38 +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 mx1.freebsd.org (Postfix) with ESMTPS id 9A70C22A7 for ; Thu, 1 Sep 2016 23:59:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u81NxbKE042079 for ; Thu, 1 Sep 2016 23:59:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 185633] [pf] scrubbing bug in transparent mode bug with bigger than MTU UDP packet Date: Thu, 01 Sep 2016 23:59:37 +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: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: olivier@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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-pf@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 23:59:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D185633 --- Comment #12 from Olivier Cochard --- I've added some lines like: if_printf(ifp,"[DEBUG] bridge_fragment() exiting, m_len: %d\n",m->m_len); in the sys/net/if_bridge.c code. Now, here is the behavior with pf-in-bridge-mode, BUT without scrub, when I generate a "ping -c 1 -s 1500" (: bridge0: [DEBUG] bridge_pfil() enter, dir: 1(IN:1/OUT:2), m_len: 1514 bridge0: [DEBUG] bridge_pfil() exit, dir: 1(IN:1/OUT:2), m_len: 1514 bridge0: [DEBUG] bridge_pfil() enter, dir: 2(IN:1/OUT:2), m_len: 1514 bridge0: [DEBUG] bridge_pfil() exit, dir: 2(IN:1/OUT:2), m_len: 1514 bridge0: [DEBUG] bridge_pfil() enter, dir: 1(IN:1/OUT:2), m_len: 62 bridge0: [DEBUG] bridge_pfil() exit, dir: 1(IN:1/OUT:2), m_len: 62 bridge0: [DEBUG] bridge_pfil() enter, dir: 2(IN:1/OUT:2), m_len: 62 bridge0: [DEBUG] bridge_pfil() exit, dir: 2(IN:1/OUT:2), m_len: 62 bridge0: [DEBUG] bridge_pfil() enter, dir: 1(IN:1/OUT:2), m_len: 1514 bridge0: [DEBUG] bridge_pfil() exit, dir: 1(IN:1/OUT:2), m_len: 1514 bridge0: [DEBUG] bridge_pfil() enter, dir: 2(IN:1/OUT:2), m_len: 1514 bridge0: [DEBUG] bridge_pfil() exit, dir: 2(IN:1/OUT:2), m_len: 1514 bridge0: [DEBUG] bridge_pfil() enter, dir: 1(IN:1/OUT:2), m_len: 62 bridge0: [DEBUG] bridge_pfil() exit, dir: 1(IN:1/OUT:2), m_len: 62 bridge0: [DEBUG] bridge_pfil() enter, dir: 2(IN:1/OUT:2), m_len: 62 bridge0: [DEBUG] bridge_pfil() exit, dir: 2(IN:1/OUT:2), m_len: 62 =3D> For each packet received, there are transmitted as-it. Now, here is the behavior with pf-in-bridge-mode WITH scrub: bridge0: [DEBUG] bridge_pfil() enter, dir: 1(IN:1/OUT:2), m_len: 1514 pf_normalize_ip: DEBUG branch frag: 0xfffff80003e73300(m_pkthrd.len:1500) pf_normalize_ip: reass frag 45306 @ 0-1480 pf_fillup_fragment: reass frag 45306 @ 0-1480 bridge0: [DEBUG] bridge_pfil() enter, dir: 1(IN:1/OUT:2), m_len: 62 pf_normalize_ip: DEBUG branch frag: 0xfffff80003e73200(m_pkthrd.len:48) pf_normalize_ip: reass frag 45306 @ 1480-1508 pf_fillup_fragment: reass frag 45306 @ 1480-1508 pf_isfull_fragment: 1508 < 1508? pf_reassemble: complete: 0xfffff80003e73300(m_pkthrd.len:1528, p_len: 1528) bridge0: [DEBUG] bridge_pfil() exit, dir: 1(IN:1/OUT:2), m_len: 1542 bridge0: [DEBUG] bridge_pfil() enter, dir: 2(IN:1/OUT:2), m_len: 1542 vtnet1: [DEBUG] bridge_fragment() entering, m_len: 1528 vtnet1: [DEBUG] bridge_fragment() exiting, m_len: 1500 panic: bridge_enqueue: no mbuf packet header! =3D> There are 2 new functions called: pf_normalize and bridge_fragment. Here is my interpretation in the scrub-and-bridge-mode: 1. bridge_pfil (IN) the first fragmented packet (mbuf_len of MTU max ethern= et frame =3D 1514) 2. pf_normalize (scrub) detect a fragment, and wait for the next fragment 3. bridge_pfil (IN) the second fragment packet (mbuf_len of 62 Bytes Ethern= et frame) 4. pf_normalize reassemble this 2 mbuf in one big mbuf of 1528 (=3D20 bytes= for IP header + 1508 bytes of ICMP header+data) 5. bridge_pfil (IN) re-add 14 bytes of Ethernet Header to this mbuf (m_len= =3D1542 bytes) 6. bridge_pfil (OUT) takes this mbuf (m_len=3D1542), remove the Ethernet he= ader (m_len - 14 =3D 1528) and call bridge_fragment() because it's bigger than M= TU. 7. bridge_fragment should have a bug, because it reduce the m_len to 1500 a= nd try to fordward it to NIC (it should be at 1514 minimum, not 1500!). 8. The ASSERT I've set is triggered: We can't send an mbuf without ethernet header to the NIC. --=20 You are receiving this mail because: You are the assignee for the bug.=