From owner-freebsd-net@FreeBSD.ORG Sun Apr 6 04:27:46 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B5D2C10 for ; Sun, 6 Apr 2014 04:27:45 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id B00021AE for ; Sun, 6 Apr 2014 04:27:45 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id WAA11607 for ; Sat, 5 Apr 2014 22:27:41 -0600 (MDT) Message-Id: <201404060427.WAA11607@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 05 Apr 2014 22:27:17 -0600 To: net@freebsd.org From: Brett Glass Subject: More on odd IPFW behavior Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 04:27:46 -0000 A bit more investigation of IPFW's behavior on VLAN interfaces has revealed some even stranger stuff. Consider the tallies on the following firewall rules: # ipfw show | head 00001 65071 36685513 count ip from any to any layer2 via re0 00002 65303 36856334 count ip from any to any layer2 via re0_1 00003 6 3381 count ip from any to any layer2 via re0_2 00004 49338 35208527 count ip from any to any layer2 via re0_3 00005 0 0 count ip from any to any layer2 in recv re0 00006 65071 36685513 count ip from any to any layer2 out xmit re0 00007 0 0 count ip from any to any layer2 in recv re0_1 00008 65303 36856334 count ip from any to any layer2 out xmit re0_1 It looks as if, when one adds "in" and "out" to the rules, one never sees any Layer 2 packets coming "in" on either a vlan(4) interface or its parent. There might be a problem with general brokenness in IPFW's "in" and "out" qualifiers when dealing with Layer 2 packets, or something else might be wrong.... Not sure, but this behavior is definitely weird. And note that, again, re0_1 (a child interface) shows more packets than re0 (the parent). Weird. Do not have experience with pf, so do not know if it would do better, but IPFW certainly has something broken. Help in figuring out what to propose as a patch would be MUCH appreciated. --Brett Glass