From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 15 11:06:12 2012 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C42A450C for ; Mon, 15 Oct 2012 11:06:12 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [8.8.178.135]) by mx1.freebsd.org (Postfix) with ESMTP id 925BF8FC16 for ; Mon, 15 Oct 2012 11:06:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q9FB6CC6011510 for ; Mon, 15 Oct 2012 11:06:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9FB6C83011509 for freebsd-ipfw@FreeBSD.org; Mon, 15 Oct 2012 11:06:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Oct 2012 11:06:12 GMT Message-Id: <201210151106.q9FB6C83011509@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 11:06:12 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 18 05:49:37 2012 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76084EB4 for ; Thu, 18 Oct 2012 05:49:37 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2A94B8FC08 for ; Thu, 18 Oct 2012 05:49:36 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so11564714vcb.13 for ; Wed, 17 Oct 2012 22:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=e5pkQzclQGeakp58ZS066CU/YI49BoegSAdSJfce7L4=; b=M+XljtrMTTZtSFJJDLua0IGtJ4ND1DIsgfG1AN58FEvaJC7YkexRidAuOuoYlnVGoy gBvXjcpUWbjCFQaOx6FN0zoL6YKojM3ACmwWGCKKBQTWEvqk/PI+fn9e0pz2Q5uxIFBN sCtAkRyfQod1Wt1J85+YKlTj74iVjpr8hULN9sy871xNwsY+Pi10AXEQ3Cu4A5IY95W0 FyacrVSdYoohsPaMw6uDuCybYTha4DmQJBAcrvVHsHaVZBbZjvBQRdHzHGutdGxdbFpu IEOd5EF/fHvNoyfkSMAwSDUkNuNshEjD+SzTpfMyek+XfUYkHvEsV3C/QB3ElsE6v6kG f9gQ== MIME-Version: 1.0 Received: by 10.220.150.82 with SMTP id x18mr3605566vcv.73.1350539376466; Wed, 17 Oct 2012 22:49:36 -0700 (PDT) Received: by 10.58.56.135 with HTTP; Wed, 17 Oct 2012 22:49:36 -0700 (PDT) Date: Thu, 18 Oct 2012 08:49:36 +0300 Message-ID: Subject: ipfw: Opcode 10 size 49 wrong From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 05:49:37 -0000 Hi, I am using FreeBSD 8.3 - RELEASE with ipfw + dummynet + inkernel_nat compiled kernel. This message appears on my console about 20 times per hour : ipfw: opcode 10 size 49 wrong" ipfw: opcode 10 size 49 wrong" ipfw: opcode 10 size 49 wrong" ipfw: opcode 10 size 49 wrong" ipfw: opcode 10 size 49 wrong" ... System works as expectedly but, it hangs after about 2-3 hours. Both IPv4 and IPv6 addresses configured, System has 3 interfaces ( 1 LAN, 1 WAN, 1 DMZ ) All of cards are Intel I350T ( igbX ). kern.ipc.nmbclusters is set to 262144. What does it mean "ipfw: opcode 10 size 49 wrong" ? How can we debug / solve this problem? Best regards, Ozkan. From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 18 06:23:23 2012 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB6135E8 for ; Thu, 18 Oct 2012 06:23:23 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7C8CB8FC08 for ; Thu, 18 Oct 2012 06:23:23 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id v11so10533133vbm.13 for ; Wed, 17 Oct 2012 23:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=BEl+ad9u4BmXJ+PSo2CRa1Yi/iRk2T19MHwd6TW93UY=; b=t45OuFfAiSY7OS2FeIagjZhkpRbNW/WCx+Lu0oYxw5zM68RB2cuJirlzVmgNKJu4Fk R8+qWXJM8kh1KWZWLsLv9p15mPPkWZHlwSfBfoUsT/MPCbfcBs7F1cbt9ZieJpvgq3za ftAwfzOKaU1BaKloe39pnBbPRWGFYPGu+5C+YqRx9c6lYW6Hm+041xrHKpN9DIrdIPIZ 7+JP8fZ1M0Q69UCfd72mVw7lLJkpjg3P/RRqWvRGF7+/DAlbAwZfWc9brDoBRcHziGZZ pHs6zVLrNrhiXjJ3W0FNObZyDb8ZN+0wpGuNohYPnGjY6HZSq92M0V3x7lse805kdq+C wCOg== MIME-Version: 1.0 Received: by 10.220.150.14 with SMTP id w14mr3728104vcv.13.1350541402706; Wed, 17 Oct 2012 23:23:22 -0700 (PDT) Received: by 10.58.56.135 with HTTP; Wed, 17 Oct 2012 23:23:22 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Oct 2012 09:23:22 +0300 Message-ID: Subject: Re: ipfw: Opcode 10 size 49 wrong From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 06:23:24 -0000 Some information below : # netstat -m 133399/12146/145545 mbufs in use (current/cache/total) 132837/5409/138246/524288 mbuf clusters in use (current/cache/total/max) 132837/4891 mbuf+clusters out of packet secondary zone in use (current/cach= e) 291/634/925/262144 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/131072 9k jumbo clusters in use (current/cache/total/max) 0/0/0/65536 16k jumbo clusters in use (current/cache/total/max) 300241K/16390K/316632K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 41 requests for I/O initiated by sendfile 0 calls to protocol drain routines # sysctl dev.igb.0 dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.3.1 dev.igb.0.%driver: igb dev.igb.0.%location: slot=3D0 function=3D0 dev.igb.0.%pnpinfo: vendor=3D0x8086 device=3D0x1521 subvendor=3D0x8086 subdevice=3D0x0001 class=3D0x020000 dev.igb.0.%parent: pci6 dev.igb.0.nvm: -1 dev.igb.0.enable_aim: 1 dev.igb.0.fc: 3 dev.igb.0.rx_processing_limit: -1 dev.igb.0.dmac: 0 dev.igb.0.eee_disabled: 1 dev.igb.0.link_irq: 2 dev.igb.0.dropped: 0 dev.igb.0.tx_dma_fail: 0 dev.igb.0.rx_overruns: 0 dev.igb.0.watchdog_timeouts: 0 dev.igb.0.device_control: 1209795137 dev.igb.0.rx_control: 67141658 dev.igb.0.interrupt_mask: 4 dev.igb.0.extended_int_mask: 2147484151 dev.igb.0.tx_buf_alloc: 0 dev.igb.0.rx_buf_alloc: 0 dev.igb.0.fc_high_water: 33168 dev.igb.0.fc_low_water: 33152 dev.igb.0.queue0.interrupt_rate: 5208 dev.igb.0.queue0.txd_head: 1557 dev.igb.0.queue0.txd_tail: 1557 dev.igb.0.queue0.no_desc_avail: 0 dev.igb.0.queue0.tx_packets: 424156 dev.igb.0.queue0.rxd_head: 681 dev.igb.0.queue0.rxd_tail: 680 dev.igb.0.queue0.rx_packets: 397993 dev.igb.0.queue0.rx_bytes: 90331828 dev.igb.0.queue0.lro_queued: 0 dev.igb.0.queue0.lro_flushed: 0 dev.igb.0.queue1.interrupt_rate: 100000 dev.igb.0.queue1.txd_head: 250 dev.igb.0.queue1.txd_tail: 250 dev.igb.0.queue1.no_desc_avail: 0 dev.igb.0.queue1.tx_packets: 424717 dev.igb.0.queue1.rxd_head: 917 dev.igb.0.queue1.rxd_tail: 916 dev.igb.0.queue1.rx_packets: 435093 dev.igb.0.queue1.rx_bytes: 215966796 dev.igb.0.queue1.lro_queued: 0 dev.igb.0.queue1.lro_flushed: 0 dev.igb.0.queue2.interrupt_rate: 30303 dev.igb.0.queue2.txd_head: 2127 dev.igb.0.queue2.txd_tail: 2127 dev.igb.0.queue2.no_desc_avail: 0 dev.igb.0.queue2.tx_packets: 818615 dev.igb.0.queue2.rxd_head: 3994 dev.igb.0.queue2.rxd_tail: 3993 dev.igb.0.queue2.rx_packets: 434074 dev.igb.0.queue2.rx_bytes: 166773634 dev.igb.0.queue2.lro_queued: 0 dev.igb.0.queue2.lro_flushed: 0 dev.igb.0.queue3.interrupt_rate: 2673 dev.igb.0.queue3.txd_head: 3055 dev.igb.0.queue3.txd_tail: 3055 dev.igb.0.queue3.no_desc_avail: 0 dev.igb.0.queue3.tx_packets: 481533 dev.igb.0.queue3.rxd_head: 2037 dev.igb.0.queue3.rxd_tail: 2035 dev.igb.0.queue3.rx_packets: 681973 dev.igb.0.queue3.rx_bytes: 105467978 dev.igb.0.queue3.lro_queued: 0 dev.igb.0.queue3.lro_flushed: 0 dev.igb.0.queue4.interrupt_rate: 13888 dev.igb.0.queue4.txd_head: 1496 dev.igb.0.queue4.txd_tail: 1496 dev.igb.0.queue4.no_desc_avail: 0 dev.igb.0.queue4.tx_packets: 344471 dev.igb.0.queue4.rxd_head: 3804 dev.igb.0.queue4.rxd_tail: 3803 dev.igb.0.queue4.rx_packets: 392924 dev.igb.0.queue4.rx_bytes: 132467841 dev.igb.0.queue4.lro_queued: 0 dev.igb.0.queue4.lro_flushed: 0 dev.igb.0.queue5.interrupt_rate: 100000 dev.igb.0.queue5.txd_head: 3221 dev.igb.0.queue5.txd_tail: 3221 dev.igb.0.queue5.no_desc_avail: 0 dev.igb.0.queue5.tx_packets: 496837 dev.igb.0.queue5.rxd_head: 418 dev.igb.0.queue5.rxd_tail: 417 dev.igb.0.queue5.rx_packets: 483746 dev.igb.0.queue5.rx_bytes: 114443400 dev.igb.0.queue5.lro_queued: 0 dev.igb.0.queue5.lro_flushed: 0 dev.igb.0.queue6.interrupt_rate: 2673 dev.igb.0.queue6.txd_head: 1625 dev.igb.0.queue6.txd_tail: 1625 dev.igb.0.queue6.no_desc_avail: 0 dev.igb.0.queue6.tx_packets: 308415 dev.igb.0.queue6.rxd_head: 2065 dev.igb.0.queue6.rxd_tail: 2064 dev.igb.0.queue6.rx_packets: 321553 dev.igb.0.queue6.rx_bytes: 78662967 dev.igb.0.queue6.lro_queued: 0 dev.igb.0.queue6.lro_flushed: 0 dev.igb.0.queue7.interrupt_rate: 21276 dev.igb.0.queue7.txd_head: 1472 dev.igb.0.queue7.txd_tail: 1472 dev.igb.0.queue7.no_desc_avail: 0 dev.igb.0.queue7.tx_packets: 514688 dev.igb.0.queue7.rxd_head: 1961 dev.igb.0.queue7.rxd_tail: 1960 dev.igb.0.queue7.rx_packets: 321449 dev.igb.0.queue7.rx_bytes: 104156914 dev.igb.0.queue7.lro_queued: 0 dev.igb.0.queue7.lro_flushed: 0 dev.igb.0.mac_stats.excess_coll: 0 dev.igb.0.mac_stats.single_coll: 0 dev.igb.0.mac_stats.multiple_coll: 0 dev.igb.0.mac_stats.late_coll: 0 dev.igb.0.mac_stats.collision_count: 0 dev.igb.0.mac_stats.symbol_errors: 0 dev.igb.0.mac_stats.sequence_errors: 0 dev.igb.0.mac_stats.defer_count: 0 dev.igb.0.mac_stats.missed_packets: 0 dev.igb.0.mac_stats.recv_no_buff: 0 dev.igb.0.mac_stats.recv_undersize: 0 dev.igb.0.mac_stats.recv_fragmented: 0 dev.igb.0.mac_stats.recv_oversize: 0 dev.igb.0.mac_stats.recv_jabber: 0 dev.igb.0.mac_stats.recv_errs: 0 dev.igb.0.mac_stats.crc_errs: 0 dev.igb.0.mac_stats.alignment_errs: 0 dev.igb.0.mac_stats.coll_ext_errs: 0 dev.igb.0.mac_stats.xon_recvd: 0 dev.igb.0.mac_stats.xon_txd: 0 dev.igb.0.mac_stats.xoff_recvd: 0 dev.igb.0.mac_stats.xoff_txd: 0 dev.igb.0.mac_stats.total_pkts_recvd: 3466618 dev.igb.0.mac_stats.good_pkts_recvd: 3466613 dev.igb.0.mac_stats.bcast_pkts_recvd: 80019 dev.igb.0.mac_stats.mcast_pkts_recvd: 86214 dev.igb.0.mac_stats.rx_frames_64: 1768575 dev.igb.0.mac_stats.rx_frames_65_127: 923733 dev.igb.0.mac_stats.rx_frames_128_255: 90372 dev.igb.0.mac_stats.rx_frames_256_511: 80393 dev.igb.0.mac_stats.rx_frames_512_1023: 123063 dev.igb.0.mac_stats.rx_frames_1024_1522: 480477 dev.igb.0.mac_stats.good_octets_recvd: 1022903617 dev.igb.0.mac_stats.good_octets_txd: 5378183340 dev.igb.0.mac_stats.total_pkts_txd: 4740612 dev.igb.0.mac_stats.good_pkts_txd: 4740612 dev.igb.0.mac_stats.bcast_pkts_txd: 1698 dev.igb.0.mac_stats.mcast_pkts_txd: 3516 dev.igb.0.mac_stats.tx_frames_64: 419889 dev.igb.0.mac_stats.tx_frames_65_127: 365584 dev.igb.0.mac_stats.tx_frames_128_255: 149310 dev.igb.0.mac_stats.tx_frames_256_511: 199405 dev.igb.0.mac_stats.tx_frames_512_1023: 190421 dev.igb.0.mac_stats.tx_frames_1024_1522: 3416003 dev.igb.0.mac_stats.tso_txd: 588491 dev.igb.0.mac_stats.tso_ctx_fail: 0 dev.igb.0.interrupts.asserts: 6979137 dev.igb.0.interrupts.rx_pkt_timer: 3466552 dev.igb.0.interrupts.rx_abs_timer: 0 dev.igb.0.interrupts.tx_pkt_timer: 0 dev.igb.0.interrupts.tx_abs_timer: 0 dev.igb.0.interrupts.tx_queue_empty: 4740550 dev.igb.0.interrupts.tx_queue_min_thresh: 9485162 dev.igb.0.interrupts.rx_desc_min_thresh: 0 dev.igb.0.interrupts.rx_overrun: 0 dev.igb.0.host.breaker_tx_pkt: 0 dev.igb.0.host.host_tx_pkt_discard: 0 dev.igb.0.host.rx_pkt: 61 dev.igb.0.host.breaker_rx_pkts: 0 dev.igb.0.host.breaker_rx_pkt_drop: 0 dev.igb.0.host.tx_good_pkt: 62 dev.igb.0.host.breaker_tx_pkt_drop: 0 dev.igb.0.host.rx_good_bytes: 1022903617 dev.igb.0.host.tx_good_bytes: 5378183340 dev.igb.0.host.length_errors: 5 dev.igb.0.host.serdes_violation_pkt: 0 dev.igb.0.host.header_redir_missed: 0 I show that interrupt rates of queues are different. On Thu, Oct 18, 2012 at 8:49 AM, =D6zkan KIRIK wrot= e: > Hi, > > I am using FreeBSD 8.3 - RELEASE with ipfw + dummynet + inkernel_nat > compiled kernel. > > This message appears on my console about 20 times per hour : > > ipfw: opcode 10 size 49 wrong" > ipfw: opcode 10 size 49 wrong" > ipfw: opcode 10 size 49 wrong" > ipfw: opcode 10 size 49 wrong" > ipfw: opcode 10 size 49 wrong" > ... > > > System works as expectedly but, it hangs after about 2-3 hours. > > Both IPv4 and IPv6 addresses configured, > System has 3 interfaces ( 1 LAN, 1 WAN, 1 DMZ ) > All of cards are Intel I350T ( igbX ). > kern.ipc.nmbclusters is set to 262144. > > What does it mean "ipfw: opcode 10 size 49 wrong" ? > How can we debug / solve this problem? > > Best regards, > Ozkan. From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 19 11:25:39 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 633F0D03; Fri, 19 Oct 2012 11:25:39 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [8.8.178.136]) by mx2.freebsd.org (Postfix) with ESMTP id 19E8D3B53B7; Fri, 19 Oct 2012 11:25:36 +0000 (UTC) Message-ID: <508138A4.5030901@FreeBSD.org> Date: Fri, 19 Oct 2012 15:25:24 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121010 Thunderbird/15.0.1 MIME-Version: 1.0 To: net@freebsd.org Subject: [RFC] Enabling IPFIREWALL_FORWARD in run-time X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCA59115641B47F6217D4A48C" Cc: ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 11:25:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCA59115641B47F6217D4A48C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All, Many years ago i have already proposed this feature, but at that time several people were against, because as they said, it could affect performance. Now, when we have high speed network adapters, SMP kernel and network stack, several locks acquired in the path of each packet, and i have an ability to test this in the lab. So, i prepared the patch, that removes IPFIREWALL_FORWARD option from the kernel and makes this functionality always build-in, but it is turned off by default and can be enabled via the sysctl(8) variable net.pfil.forward=3D1. http://people.freebsd.org/~ae/pfil_forward.diff Also we have done some tests with the ixia traffic generator connected via 10G network adapter. Tests have show that there is no visible difference, and there is no visible performance degradation. Any objections? --=20 WBR, Andrey V. Elsukov --------------enigCA59115641B47F6217D4A48C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQgTisAAoJEAHF6gQQyKF6+UwH/2xemnR6Si2AtLcRJrB0HpXa Kr8r2BCyTulAdBsYBznduCj4cvhpiVrXNhqIf9y1mrY4LMz0Ci98OClOTaom82t/ /1msCig4nt61ZV5X21aQ19xzWUqu/Njx1gGz63v2dBKAyhngdJ3EjGa5sU1L2RU2 wJnJ4/iSmq1IT9Y6x0iFXG+1LZTs/Kg+/9j5G8qnTJDRP0sIRwopG4Imd5MdHOLM KrnpCm2HMxvxq6xls4phaBy20p/Yy5LDl7iDgJLyK7Ro8TA05me6zVBzz9hnuJjJ zN65HAMlhZsfeXb5VxRfKh11QcS8jdYhHATUSYuHIlGibdAa4Pj+hZlWzVKTS1E= =9ra7 -----END PGP SIGNATURE----- --------------enigCA59115641B47F6217D4A48C-- From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 19 11:47:11 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC093305; Fri, 19 Oct 2012 11:47:10 +0000 (UTC) (envelope-from zam4ever@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 655C58FC08; Fri, 19 Oct 2012 11:47:10 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id p27so67209qat.13 for ; Fri, 19 Oct 2012 04:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KCt2rbM2J0//nzGbRbVss9xuEKCsfdhls/n/5ye2RJE=; b=ysfoB5JETcdWj7wpywQ8gZJG837a3N1HcUGudlE1YaInSeL3tXjMtDS5pH2m0M1zVA OBAxH8ouBtesyLr2Tu2eDAJbktBrZSLJzAH7QJr/R/oRQy8UG5/e481saxOTKiPvqpWU i4eTXO7MOeakEo705nqHo4eoAFp5Lv2J6v/5cmE19aNHB8rStwVetSC1KtrCkw2gQoWR Xq+5KY2+C6JEfLpkkSFdEgNtzDwQlsM+mOlEY8Utwb8pCAcCv6USKoTbEpNW+hUxMKYF D+UdnAAyctuXHNRZiE7gFKmglLRhbAYkImso16z2hIg1EyeHk14aVxEaRdPs1NqQilaD 24LA== MIME-Version: 1.0 Received: by 10.224.168.136 with SMTP id u8mr602590qay.17.1350647223650; Fri, 19 Oct 2012 04:47:03 -0700 (PDT) Received: by 10.49.117.134 with HTTP; Fri, 19 Oct 2012 04:47:03 -0700 (PDT) Received: by 10.49.117.134 with HTTP; Fri, 19 Oct 2012 04:47:03 -0700 (PDT) In-Reply-To: <508138A4.5030901@FreeBSD.org> References: <508138A4.5030901@FreeBSD.org> Date: Fri, 19 Oct 2012 19:47:03 +0800 Message-ID: Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time From: Zamri Besar To: "Andrey V. Elsukov" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: ipfw@freebsd.org, net@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 11:47:11 -0000 On Oct 19, 2012 7:25 PM, "Andrey V. Elsukov" wrote: > > Hi All, > > Many years ago i have already proposed this feature, but at that time > several people were against, because as they said, it could affect > performance. Now, when we have high speed network adapters, SMP kernel > and network stack, several locks acquired in the path of each packet, > and i have an ability to test this in the lab. > > So, i prepared the patch, that removes IPFIREWALL_FORWARD option from > the kernel and makes this functionality always build-in, but it is > turned off by default and can be enabled via the sysctl(8) variable > net.pfil.forward=1. > > http://people.freebsd.org/~ae/pfil_forward.diff > > Also we have done some tests with the ixia traffic generator connected > via 10G network adapter. Tests have show that there is no visible > difference, and there is no visible performance degradation. > > Any objections? > > -- > WBR, Andrey V. Elsukov > This is what I want many years ago too... ;) I vote for "yes" From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 19 12:02:53 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97DACA87 for ; Fri, 19 Oct 2012 12:02:53 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id E96138FC0A for ; Fri, 19 Oct 2012 12:02:52 +0000 (UTC) Received: (qmail 35284 invoked from network); 19 Oct 2012 13:41:36 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Oct 2012 13:41:36 -0000 Message-ID: <50814166.1000602@networx.ch> Date: Fri, 19 Oct 2012 14:02:46 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time References: <508138A4.5030901@FreeBSD.org> In-Reply-To: <508138A4.5030901@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org, net@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 12:02:53 -0000 On 19.10.2012 13:25, Andrey V. Elsukov wrote: > Hi All, > > Many years ago i have already proposed this feature, but at that time > several people were against, because as they said, it could affect > performance. Now, when we have high speed network adapters, SMP kernel > and network stack, several locks acquired in the path of each packet, > and i have an ability to test this in the lab. > > So, i prepared the patch, that removes IPFIREWALL_FORWARD option from > the kernel and makes this functionality always build-in, but it is > turned off by default and can be enabled via the sysctl(8) variable > net.pfil.forward=1. > > http://people.freebsd.org/~ae/pfil_forward.diff > > Also we have done some tests with the ixia traffic generator connected > via 10G network adapter. Tests have show that there is no visible > difference, and there is no visible performance degradation. > > Any objections? No objection as such. However I don't entirely agree with the naming of pfil_forward. The functionality is specific to IPFW and TCP, it's doing transparent interjected termination of tcp connections on the local host while keeping the original IP addresses and port numbers visible in netstat output. So it's a feature of IPFW/IP and should be fitted in there for sysctl name and .h files instead of pfil. -- Andre From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 19 12:18:56 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 64A37E39; Fri, 19 Oct 2012 12:18:56 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [8.8.178.136]) by mx2.freebsd.org (Postfix) with ESMTP id 232A43B4F7F; Fri, 19 Oct 2012 12:18:54 +0000 (UTC) Message-ID: <50814523.2070002@FreeBSD.org> Date: Fri, 19 Oct 2012 16:18:43 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121010 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time References: <508138A4.5030901@FreeBSD.org> <50814166.1000602@networx.ch> In-Reply-To: <50814166.1000602@networx.ch> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC2F9C7A14662BA4A777BD6AB" Cc: ipfw@freebsd.org, net@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 12:18:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC2F9C7A14662BA4A777BD6AB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 19.10.2012 16:02, Andre Oppermann wrote:>> http://people.freebsd.org/~ae/pfil_forward.diff >> >> Also we have done some tests with the ixia traffic generator connected= >> via 10G network adapter. Tests have show that there is no visible >> difference, and there is no visible performance degradation. >> >> Any objections? > > No objection as such. However I don't entirely agree with the > naming of pfil_forward. The functionality is specific to IPFW > and TCP, it's doing transparent interjected termination of tcp > connections on the local host while keeping the original IP > addresses and port numbers visible in netstat output. > > So it's a feature of IPFW/IP and should be fitted in there for > sysctl name and .h files instead of pfil. Actually it can be used not only by ipfw. We already have net.inet.ip.forwarding and net.inet6.ip6.forwarding variables, and placing it into net.inet.ip.fw is undesirable, because we can have kernel without ipfw. So, i decided to choose pfil, because it could not work without pfil. --=20 WBR, Andrey V. Elsukov --------------enigC2F9C7A14662BA4A777BD6AB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQgUUqAAoJEAHF6gQQyKF6pyMIAILQkM9tSI6KL5bdG7qotu/Q ulM49kdqP6eHNGt2FMCy634r6uM7HNPK0oY3cZq9acxbUFXf/es8PViz/ELCFmcL V1BUAoDj2J6PBx4n1oGNf+efV9J/s/7YHLj93RH1hgFWVOIOoPdzlyhm/bIs5Dz2 HQ7Nw92GfMCIFREEcZZ55H5ai9xUJoP4BOYDrJ/za9I/XpxTTzqoGUrEJFJUKJP9 ASArYTggA5UrESKTMg/WV2/pIlmwkfEtgAjzAkjweeUi4N3T6QRjY8w8lbz7aZn0 GOq60Ia6cmmrwDZkmTmJ9NJGNKQ7yRlheprcLh9pmoWPEKpgZedcYeDcTLkrprk= =fWAC -----END PGP SIGNATURE----- --------------enigC2F9C7A14662BA4A777BD6AB-- From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 19 13:56:54 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDBD5FC0; Fri, 19 Oct 2012 13:56:54 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 09EE58FC08; Fri, 19 Oct 2012 13:56:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q9JDujNr096880; Sat, 20 Oct 2012 00:56:45 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 20 Oct 2012 00:56:45 +1100 (EST) From: Ian Smith To: "Andrey V. Elsukov" Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time In-Reply-To: <508138A4.5030901@FreeBSD.org> Message-ID: <20121020002249.X88114@sola.nimnet.asn.au> References: <508138A4.5030901@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ipfw@freebsd.org, net@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:56:54 -0000 On Fri, 19 Oct 2012 15:25:24 +0400, Andrey V. Elsukov wrote: > Hi All, > > Many years ago i have already proposed this feature, but at that time > several people were against, because as they said, it could affect > performance. Now, when we have high speed network adapters, SMP kernel > and network stack, several locks acquired in the path of each packet, > and i have an ability to test this in the lab. > > So, i prepared the patch, that removes IPFIREWALL_FORWARD option from > the kernel and makes this functionality always build-in, but it is > turned off by default and can be enabled via the sysctl(8) variable > net.pfil.forward=1. > > http://people.freebsd.org/~ae/pfil_forward.diff > > Also we have done some tests with the ixia traffic generator connected > via 10G network adapter. Tests have show that there is no visible > difference, and there is no visible performance degradation. > > Any objections? Looks great. I'll no longer have to tell people on questions@ that using ipfw fwd is the only reason left not to just load the module. Taking the code on trust, only to comment on the documentation: ipfw.8: ======= To enable .Cm fwd -a custom kernel needs to be compiled with the option -.Cd "options IPFIREWALL_FORWARD" . +the +.Xr sysctl 8 +variable +.Va net.pfil.forward +should be set to 1. NOTES: ======= -# IPFIREWALL_FORWARD enables changing of the packet destination either -# to do some sort of policy routing or transparent proxying. Used by -# ``ipfw forward''. All redirections apply to locally generated -# packets too. Because of this great care is required when -# crafting the ruleset. ipfw(8) could perhaps incorporate that description (and warning) from NOTES in the entry under SYSCTLS where net.pfil.forward (or whatever :) would be expected to be described, apart from sysctl -d ? cheers, Ian > WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 19 14:05:50 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39DB93EA for ; Fri, 19 Oct 2012 14:05:50 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9941F8FC08 for ; Fri, 19 Oct 2012 14:05:48 +0000 (UTC) Received: (qmail 35725 invoked from network); 19 Oct 2012 15:44:32 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Oct 2012 15:44:32 -0000 Message-ID: <50815E36.6010703@networx.ch> Date: Fri, 19 Oct 2012 16:05:42 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time References: <508138A4.5030901@FreeBSD.org> <50814166.1000602@networx.ch> <50814523.2070002@FreeBSD.org> In-Reply-To: <50814523.2070002@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org, net@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:05:50 -0000 On 19.10.2012 14:18, Andrey V. Elsukov wrote: > On 19.10.2012 16:02, Andre Oppermann wrote:>> > http://people.freebsd.org/~ae/pfil_forward.diff >>> >>> Also we have done some tests with the ixia traffic generator connected >>> via 10G network adapter. Tests have show that there is no visible >>> difference, and there is no visible performance degradation. >>> >>> Any objections? >> >> No objection as such. However I don't entirely agree with the >> naming of pfil_forward. The functionality is specific to IPFW >> and TCP, it's doing transparent interjected termination of tcp >> connections on the local host while keeping the original IP >> addresses and port numbers visible in netstat output. >> >> So it's a feature of IPFW/IP and should be fitted in there for >> sysctl name and .h files instead of pfil. > > Actually it can be used not only by ipfw. We already have > net.inet.ip.forwarding and net.inet6.ip6.forwarding variables, and > placing it into net.inet.ip.fw is undesirable, because we can have > kernel without ipfw. So, i decided to choose pfil, because it could not > work without pfil. Again, it's not a property of pfil. It's a property of IP and it should live there from a configuration point of view. Other firewalls than ipfw don't make use of it. You could rename it to transparent connection proxy or some such. -- Andre From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 19 15:17:44 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id C7959854; Fri, 19 Oct 2012 15:17:44 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [8.8.178.135]) by mx2.freebsd.org (Postfix) with ESMTP id E46CB3B6660; Fri, 19 Oct 2012 15:17:41 +0000 (UTC) Message-ID: <50816ECE.4020002@FreeBSD.org> Date: Fri, 19 Oct 2012 19:16:30 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120627 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time References: <508138A4.5030901@FreeBSD.org> <50814166.1000602@networx.ch> <50814523.2070002@FreeBSD.org> <50815E36.6010703@networx.ch> In-Reply-To: <50815E36.6010703@networx.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Andrey V. Elsukov" , ipfw@freebsd.org, net@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:17:44 -0000 On 19.10.2012 18:05, Andre Oppermann wrote: > On 19.10.2012 14:18, Andrey V. Elsukov wrote: >> On 19.10.2012 16:02, Andre Oppermann wrote:>> >> http://people.freebsd.org/~ae/pfil_forward.diff >>>> >>>> Also we have done some tests with the ixia traffic generator connected >>>> via 10G network adapter. Tests have show that there is no visible >>>> difference, and there is no visible performance degradation. >>>> >>>> Any objections? >>> >>> No objection as such. However I don't entirely agree with the >>> naming of pfil_forward. The functionality is specific to IPFW >>> and TCP, it's doing transparent interjected termination of tcp >>> connections on the local host while keeping the original IP >>> addresses and port numbers visible in netstat output. >>> >>> So it's a feature of IPFW/IP and should be fitted in there for >>> sysctl name and .h files instead of pfil. >> >> Actually it can be used not only by ipfw. We already have >> net.inet.ip.forwarding and net.inet6.ip6.forwarding variables, and >> placing it into net.inet.ip.fw is undesirable, because we can have >> kernel without ipfw. So, i decided to choose pfil, because it could not >> work without pfil. > > Again, it's not a property of pfil. It's a property of IP and it Not exactly. It is currently supported in both IPv4 and IPv6. > should live there from a configuration point of view. Other firewalls > than ipfw don't make use of it. > > You could rename it to transparent connection proxy or some such. fwd is widely used as policy-based routing, so it is not just upper-layer TCP feature. > -- WBR, Alexander From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 19 18:38:57 2012 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3BD383F0 for ; Fri, 19 Oct 2012 18:38:57 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id E05168FC0A for ; Fri, 19 Oct 2012 18:38:56 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TPHTI-0004ty-C2 for freebsd-ipfw@freebsd.org; Fri, 19 Oct 2012 20:39:00 +0200 Received: from broadband-77-37-234-86.nationalcablenetworks.ru ([77.37.234.86]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Oct 2012 20:39:00 +0200 Received: from vadim_nuclight by broadband-77-37-234-86.nationalcablenetworks.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Oct 2012 20:39:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Vadim Goncharov Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time Date: Fri, 19 Oct 2012 18:38:40 +0000 (UTC) Organization: Nuclear Lightning @ Moscow, Home Lines: 55 Message-ID: References: <508138A4.5030901@FreeBSD.org> <50814166.1000602@networx.ch> <50814523.2070002@FreeBSD.org> <50815E36.6010703__40288.6851611131$1350655584$gmane$org@networx.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: broadband-77-37-234-86.nationalcablenetworks.ru X-Comment-To: Andre Oppermann User-Agent: slrn/0.9.9p1 (FreeBSD) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:38:57 -0000 Hi Andre Oppermann! On Fri, 19 Oct 2012 16:05:42 +0200; Andre Oppermann wrote about 'Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time': > On 19.10.2012 14:18, Andrey V. Elsukov wrote: >> On 19.10.2012 16:02, Andre Oppermann wrote:>> >> http://people.freebsd.org/~ae/pfil_forward.diff >>>> >>>> Also we have done some tests with the ixia traffic generator connected >>>> via 10G network adapter. Tests have show that there is no visible >>>> difference, and there is no visible performance degradation. >>>> >>>> Any objections? >>> >>> No objection as such. However I don't entirely agree with the >>> naming of pfil_forward. The functionality is specific to IPFW >>> and TCP, it's doing transparent interjected termination of tcp >>> connections on the local host while keeping the original IP >>> addresses and port numbers visible in netstat output. >>> >>> So it's a feature of IPFW/IP and should be fitted in there for >>> sysctl name and .h files instead of pfil. >> >> Actually it can be used not only by ipfw. We already have >> net.inet.ip.forwarding and net.inet6.ip6.forwarding variables, and >> placing it into net.inet.ip.fw is undesirable, because we can have >> kernel without ipfw. So, i decided to choose pfil, because it could not >> work without pfil. > > Again, it's not a property of pfil. It's a property of IP and it > should live there from a configuration point of view. Wrong. It is already supported by IPv6 and could be used for any protocol which supports concept of routing. > Other firewalls than ipfw don't make use of it. Wrong, if one will look long-term, as it should be. This should (er, must) be non-ipfw but generic pfil solution. And if later other firewalls - as they should - will be converted to this mechanism, such sysctl naming would become misleading. And there are chances they *will* be converted, given the ongoing pf's SMP work, which is effectively better pf port to FreeBSD. Better port should be better utilizing native FreeBSD mechanisms, instead of foreign hack, this pfil_forward is one of that native mechanisms. > You could rename it to transparent connection proxy or some such. No, you are wrong here again. While 'ipfw fwd' could be used for transparent proxy, too, there are two completely different applications of this - one for local socket and another for policy routing. The latter, more proper be called 'route-to', is used far more often than the former. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 19 20:06:30 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 160597AE; Fri, 19 Oct 2012 20:06:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id D70C88FC08; Fri, 19 Oct 2012 20:06:29 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-146.hsd1.ca.comcast.net [50.143.149.146]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q9JK6L8K068127 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 13:06:23 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5081B2BD.3090103@freebsd.org> Date: Fri, 19 Oct 2012 13:06:21 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time References: <508138A4.5030901@FreeBSD.org> In-Reply-To: <508138A4.5030901@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org, net@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 20:06:30 -0000 On 10/19/12 4:25 AM, Andrey V. Elsukov wrote: > Hi All, > > Many years ago i have already proposed this feature, but at that time > several people were against, because as they said, it could affect > performance. Now, when we have high speed network adapters, SMP kernel > and network stack, several locks acquired in the path of each packet, > and i have an ability to test this in the lab. > > So, i prepared the patch, that removes IPFIREWALL_FORWARD option from > the kernel and makes this functionality always build-in, but it is > turned off by default and can be enabled via the sysctl(8) variable > net.pfil.forward=1. > > http://people.freebsd.org/~ae/pfil_forward.diff > > Also we have done some tests with the ixia traffic generator connected > via 10G network adapter. Tests have show that there is no visible > difference, and there is no visible performance degradation. > > Any objections? > NO objection from me.. It was always my intention to "some day" either make it standard, OR at least default it to 'on'. looks ot me as if a couple of your 'goto's might just be changed to {}