From remko at FreeBSD.org Sun Aug 2 09:52:26 2009 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Sun Aug 2 09:52:37 2009 Subject: kern/137346: ipfw nat redirect_proto is broken Message-ID: <200908020952.n729qP8G048499@freefall.freebsd.org> Synopsis: ipfw nat redirect_proto is broken Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: remko Responsible-Changed-When: Sun Aug 2 09:52:25 UTC 2009 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=137346 From bugmaster at FreeBSD.org Mon Aug 3 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 3 11:08:55 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200908031106.n73B6xNC088646@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 62 problems total. From mira at chlastak.cz Tue Aug 4 22:49:30 2009 From: mira at chlastak.cz (Miroslav Chlastak) Date: Tue Aug 4 22:49:37 2009 Subject: Matching all protocols in /etc/protocols (1 rule) Message-ID: <4A78B6DD.7060908@chlastak.cz> Hi all, it's possible to create one rule to pass (or disable) all traffic (all protocols - from /etc/protocols)? I know, that I can use "all" keyword. But this keyword "all" mean only "tcp, udp, icmp" protocols. But there is more then tcp, udp and icmp protocol (gre,esp,ospf,...). If I can allow all of this protocols, so at the moment I have to create 134 rules (1 rule for 1 protocol from /etc/protocols). Thanks for any idea. -- Mira From fjwcash at gmail.com Tue Aug 4 23:18:51 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Tue Aug 4 23:18:58 2009 Subject: Matching all protocols in /etc/protocols (1 rule) In-Reply-To: <4A78B6DD.7060908@chlastak.cz> References: <4A78B6DD.7060908@chlastak.cz> Message-ID: 2009/8/4 Miroslav Chlastak > Hi all, > > it's possible to create one rule to pass (or disable) all traffic (all > protocols - from /etc/protocols)? > I know, that I can use "all" keyword. But this keyword "all" mean only > "tcp, udp, icmp" protocols. > But there is more then tcp, udp and icmp protocol (gre,esp,ospf,...). If I > can allow all of this protocols, so at the moment I have to create 134 rules > (1 rule for 1 protocol from /etc/protocols). > If this is for IPFW, just use "ip" or "any". That will match any IP packets, regardless of what protocol data is inside the packet. -- Freddie Cash fjwcash@gmail.com From smithi at nimnet.asn.au Wed Aug 5 05:23:24 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Wed Aug 5 05:23:32 2009 Subject: Matching all protocols in /etc/protocols (1 rule) In-Reply-To: References: <4A78B6DD.7060908@chlastak.cz> Message-ID: <20090805150508.B19821@sola.nimnet.asn.au> On Tue, 4 Aug 2009, Freddie Cash wrote: > 2009/8/4 Miroslav Chlastak > > > Hi all, > > > > it's possible to create one rule to pass (or disable) all traffic (all > > protocols - from /etc/protocols)? > > I know, that I can use "all" keyword. But this keyword "all" mean only > > "tcp, udp, icmp" protocols. > > But there is more then tcp, udp and icmp protocol (gre,esp,ospf,...). If I > > can allow all of this protocols, so at the moment I have to create 134 rules > > (1 rule for 1 protocol from /etc/protocols). > > > > If this is for IPFW, just use "ip" or "any". That will match any IP > packets, regardless of what protocol data is inside the packet. To be fussy, 'any' applies to addresses; 'ip' or 'all' is what's needed here: protocol: [not] protocol-name | protocol-number An IPv4 protocol specified by number or name (for a complete list see /etc/protocols). The ip or all keywords mean any protocol will match. cheers, Ian From bugmaster at FreeBSD.org Mon Aug 10 11:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 10 11:08:31 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200908101106.n7AB6wIw025196@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 62 problems total. From bugmaster at FreeBSD.org Mon Aug 17 11:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 17 11:08:30 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200908171106.n7HB6vsI075836@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 62 problems total. From mike at magicislandtechnologies.com Mon Aug 17 15:01:16 2009 From: mike at magicislandtechnologies.com (Michael Spratt) Date: Mon Aug 17 15:01:22 2009 Subject: out xmit (demux) pipe bw accounting Message-ID: <4A8969FF.2070601@magicislandtechnologies.com> Could not find answer to following question. Given : # pipe 1 config bw 1Mbit/sec # ipfw 1000 add pipe 1 ip from any to any out xmit em0 Will the bandwidth limit include layer 2 Ethernet headers or will only the IP datagram itself be included in the accounting mechanism? Total output on the em0 at layer 2 is limited to 1Mbit/s or IP going out em0 layer 3 will be limited to 1Mbit/s -- -------------------------------------------------- Mike Spratt - Iraq (GMT+3) Office: (214)242-1782 DSN: (318)847-2983 Cell: +964-770-398-4366 mike@magicislandtechnologies.com --------------------------------------------------- From cswiger at mac.com Mon Aug 17 17:25:35 2009 From: cswiger at mac.com (Chuck Swiger) Date: Mon Aug 17 17:25:40 2009 Subject: out xmit (demux) pipe bw accounting In-Reply-To: <4A8969FF.2070601@magicislandtechnologies.com> References: <4A8969FF.2070601@magicislandtechnologies.com> Message-ID: Hi-- On Aug 17, 2009, at 7:32 AM, Michael Spratt wrote: > Could not find answer to following question. > > Given : > # pipe 1 config bw 1Mbit/sec > # ipfw 1000 add pipe 1 ip from any to any out xmit em0 > > Will the bandwidth limit include layer 2 Ethernet headers or will > only the IP datagram itself be included in the accounting mechanism? IPFW normally processes traffic at layer-3, but you can toggle net.link.ether.ipfw sysctl to on, in which case the above rule would also be run against layer-2 packets including the 802.3 ethernet header. See the diagram in "PACKET FLOW" of "man ipfw".... Regards, -- -Chuck From mike at magicislandtechnologies.com Wed Aug 19 09:11:27 2009 From: mike at magicislandtechnologies.com (Michael Spratt) Date: Wed Aug 19 09:11:33 2009 Subject: out xmit (demux) pipe bw accounting In-Reply-To: References: <4A8969FF.2070601@magicislandtechnologies.com> Message-ID: <4A8BC140.8050203@magicislandtechnologies.com> Chuck Swiger wrote: > Hi-- > > On Aug 17, 2009, at 7:32 AM, Michael Spratt wrote: >> Could not find answer to following question. >> >> Given : >> # pipe 1 config bw 1Mbit/sec >> # ipfw 1000 add pipe 1 ip from any to any out xmit em0 >> >> Will the bandwidth limit include layer 2 Ethernet headers or will only >> the IP datagram itself be included in the accounting mechanism? > > IPFW normally processes traffic at layer-3, but you can toggle > net.link.ether.ipfw sysctl to on, in which case the above rule would > also be run against layer-2 packets including the 802.3 ethernet > header. See the diagram in "PACKET FLOW" of "man ipfw".... > > Regards, Dear Chuck thanks for your response. I am not sure though that my question is answered. Yes switching net.link.ether.ipfw->1 does cause processing against layer 2 as indicated in the man ipfw diagram and the command # sysctl -d net.link.ether.ipfw Yields the description net.link.ether.ipfw: Pass ether pkts through firewall Setting this sysctl variable to 0 does disengage the processing of Ethernet frames and corresponding IP payloads according to the rule set specified and visa-versa. I do not see anything indicating this sysctl variable affects the way dummynet does bit counting as it enforces bw limits on a pipe or queue. Will the ruleset I provided above impliment the 1Mbit/s limit at layer 2 including the Ethernet frames in the 1Mbit/s budget or (VS.) Only layer 3 IP datagrams (and their coresponding layer 4 payloads) are incrementing the counters responsible for counting against the 1Mbit/s limit Simplification of question: Given: # pipe 1 config bw 1Mbit/sec # ipfw 1000 add pipe 1 ip from any to any out xmit em0 Dichotomy: layer 2 is limit to 1Mbit/s out em0 (Vs.) layer 3 is limit to 1Mbit/s out em0 Only one of these can be correct and I do not see documentation anywhere indicating to me which one is indeed correct. I am not educated enough to look in the source code to determine this for myself. I did not state before the dummynet is on a freebsd transparent bridge. Here are my sysctl variables net.link.ether.ipfw: 0 net.link.bridge.ipfw: 1 net.link.bridge.ipfw_arp: 0 # sysctl -a | grep dummynet net.inet.ip.dummynet.debug: 0 net.inet.ip.dummynet.pipe_byte_limit: 7000000 net.inet.ip.dummynet.pipe_slot_limit: 100 net.inet.ip.dummynet.io_pkt_drop: 33250421 net.inet.ip.dummynet.io_pkt_fast: 0 net.inet.ip.dummynet.io_pkt: 3512830485 net.inet.ip.dummynet.io_fast: 0 net.inet.ip.dummynet.tick_lost: 0 net.inet.ip.dummynet.tick_diff: 1662798 net.inet.ip.dummynet.tick_adjustment: 1679911 net.inet.ip.dummynet.tick_delta_sum: 721 net.inet.ip.dummynet.tick_delta: 2 net.inet.ip.dummynet.red_max_pkt_size: 1500 net.inet.ip.dummynet.red_avg_pkt_size: 512 net.inet.ip.dummynet.red_lookup_depth: 256 net.inet.ip.dummynet.max_chain_len: 16 net.inet.ip.dummynet.expire: 1 net.inet.ip.dummynet.search_steps: 0 net.inet.ip.dummynet.searches: 0 net.inet.ip.dummynet.extract_heap: 0 net.inet.ip.dummynet.ready_heap: 16 net.inet.ip.dummynet.curr_time: 1804818806 net.inet.ip.dummynet.hash_size: 64 # sysctl -a | grep fw net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.static_count: 26 net.inet.ip.fw.dyn_max: 4096 net.inet.ip.fw.dyn_count: 0 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.default_rule: 65535 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 0 net.inet.ip.fw.debug: 1 net.inet.ip.fw.one_pass: 1 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.enable: 1 rule set 00900 15945359 1264958184 allow ip from 10.18.0.6 to any out xmit bce0 00901 44378882 8041056830 pipe 1 ip from 10.18.0.0/24 to any out xmit bce0 00910 225165 18913860 pipe 1 ip from 10.18.2.1 to any out xmit bce0 00915 0 0 pipe 2 ip from 10.18.2.2 to any out xmit bce0 00920 0 0 pipe 3 ip from 10.18.2.3 to any out xmit bce0 01000 265959 40261978 pipe 1 ip from 10.21.192.8/29 to any out xmit bce0 01001 19627389 3444748305 pipe 1 ip from 10.20.0.0/20 to any out xmit bce0 01002 180922838 31277916333 pipe 1 ip from 10.21.32.0/20 to any out xmit bce0 01003 376697028 75171259985 pipe 1 ip from 10.20.64.0/20 to any out xmit bce0 01004 68629348 12603497407 pipe 1 ip from 10.20.192.0/20 to any out xmit bce0 01005 185005607 37413644435 pipe 1 ip from 10.20.176.0/20 to any out xmit bce0 01006 59179395 10051795154 pipe 1 ip from 10.20.144.0/20 to any out xmit bce0 01007 235863676 41845371053 pipe 1 ip from 10.20.128.0/20 to any out xmit bce0 01008 51518999 10847386956 pipe 1 ip from 10.20.96.0/20 to any out xmit bce0 01009 79734709 13723937026 pipe 1 ip from 10.20.112.0/20 to any out xmit bce0 01010 30062283 4078276506 pipe 1 ip from 10.20.80.0/20 to any out xmit bce0 01011 36318511 6974450810 pipe 1 ip from 10.20.208.0/20 to any out xmit bce0 01012 19642496 3098922560 pipe 1 ip from 10.20.160.0/20 to any out xmit bce0 01013 18209570 2964820411 pipe 1 ip from 10.20.224.0/20 to any out xmit bce0 01014 13707931 3915527156 pipe 1 ip from 10.22.160.0/20 to any out xmit bce0 01015 9893051 1175739042 pipe 1 ip from 10.21.112.0/20 to any out xmit bce0 01016 39876049 7905051976 pipe 1 ip from 10.22.144.0/20 to any out xmit bce0 01017 0 0 pipe 1 ip from 10.22.147.0/24 to any out xmit bce0 01018 128251743 24972920481 pipe 1 ip from 10.21.0.0/20 to any out xmit bce0 01019 102099411 27172050432 pipe 1 ip from 10.21.16.0/20 to any out xmit bce0 65535 53581341116 24295389614128 allow ip from any to any and pipe spec # ipfw pipe list 00001: 11.500 Mbit/s 0 ms 75 KB 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 10.21.44.163/47934 65.55.131.121/80 1735939204 358391598184 1 191 10152696 You can see that the bw has been configured to 11.5Mbit/s which should be the base 10 expression for bit/s meaning exactly 11,500,000 bit/s And here lies the question again does this limit include layer 2 Ethernet frame headers in the bit/s counting mechanism -Mike -- -------------------------------------------------- Mike Spratt - Iraq (GMT+3) Office: (214)242-1782 DSN: (318)847-2983 Cell: +964-770-398-4366 mike@magicislandtechnologies.com --------------------------------------------------- From smithi at nimnet.asn.au Wed Aug 19 15:20:25 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Wed Aug 19 15:20:33 2009 Subject: out xmit (demux) pipe bw accounting In-Reply-To: <4A8BC140.8050203@magicislandtechnologies.com> References: <4A8969FF.2070601@magicislandtechnologies.com> <4A8BC140.8050203@magicislandtechnologies.com> Message-ID: <20090819224032.B90928@sola.nimnet.asn.au> On Wed, 19 Aug 2009, Michael Spratt wrote: > Chuck Swiger wrote: > > Hi-- > > > > On Aug 17, 2009, at 7:32 AM, Michael Spratt wrote: > > > Could not find answer to following question. > > > > > > Given : > > > # pipe 1 config bw 1Mbit/sec > > > # ipfw 1000 add pipe 1 ip from any to any out xmit em0 > > > > > > Will the bandwidth limit include layer 2 Ethernet headers or will only > > > the IP datagram itself be included in the accounting mechanism? > > > > IPFW normally processes traffic at layer-3, but you can toggle > > net.link.ether.ipfw sysctl to on, in which case the above rule would also > > be run against layer-2 packets including the 802.3 ethernet header. See > > the diagram in "PACKET FLOW" of "man ipfw".... > > > > Regards, > > Dear Chuck thanks for your response. I am not sure though that my question is > answered. Yes switching net.link.ether.ipfw->1 does cause processing against > layer 2 as indicated in the man ipfw diagram and the command > # sysctl -d net.link.ether.ipfw Yields the description net.link.ether.ipfw: > Pass ether pkts through firewall > > Setting this sysctl variable to 0 does disengage the processing of Ethernet > frames and corresponding IP payloads according to the rule set specified and > visa-versa. > > I do not see anything indicating this sysctl variable affects the way > dummynet does bit counting as it enforces bw limits on a pipe or queue. That's right, dummynet pipes and queues work at the IP packet level. > Will the ruleset I provided above impliment the 1Mbit/s limit at layer 2 > including the Ethernet frames in the 1Mbit/s budget or (VS.) Only layer 3 IP > datagrams (and their coresponding layer 4 payloads) are incrementing the > counters responsible for counting against the 1Mbit/s limit I think only IP packets are queued in dummynet pipes, and it's IP packet throughput rates being managed. Check out Luigi's site at http://info.iet.unipi.it/~luigi/dummynet/ There's a couple of really good .pdfs listed at the bottom describing the porting of ipfw/dummynet to Linux, with lots of detail background. It'd seem unusual if the 1Mbit/s limit you've presumably been allocated from 'higher up' would include ethernet headers as well as IP traffic. And even if it did, it's not so hard to calculate what factor to use to keep the rate below 1Mbit/s at ethernet layer, if they count that way. > Simplification of question: > Given: > # pipe 1 config bw 1Mbit/sec > # ipfw 1000 add pipe 1 ip from any to any out xmit em0 > Dichotomy: > layer 2 is limit to 1Mbit/s out em0 (Vs.) layer 3 is limit to 1Mbit/s out > em0 > > Only one of these can be correct and I do not see documentation anywhere > indicating to me which one is indeed correct. I am not educated enough to > look in the source code to determine this for myself. man ipfw read a few times forwards and backwards pretty well covers it, though the code's not bad bedtime reading :) > I did not state before the dummynet is on a freebsd transparent bridge. > Here are my sysctl variables > > net.link.ether.ipfw: 0 > net.link.bridge.ipfw: 1 > net.link.bridge.ipfw_arp: 0 > # sysctl -a | grep dummynet > net.inet.ip.dummynet.debug: 0 > net.inet.ip.dummynet.pipe_byte_limit: 7000000 > net.inet.ip.dummynet.pipe_slot_limit: 100 > net.inet.ip.dummynet.io_pkt_drop: 33250421 > net.inet.ip.dummynet.io_pkt_fast: 0 > net.inet.ip.dummynet.io_pkt: 3512830485 > net.inet.ip.dummynet.io_fast: 0 > net.inet.ip.dummynet.tick_lost: 0 > net.inet.ip.dummynet.tick_diff: 1662798 > net.inet.ip.dummynet.tick_adjustment: 1679911 > net.inet.ip.dummynet.tick_delta_sum: 721 > net.inet.ip.dummynet.tick_delta: 2 > net.inet.ip.dummynet.red_max_pkt_size: 1500 > net.inet.ip.dummynet.red_avg_pkt_size: 512 > net.inet.ip.dummynet.red_lookup_depth: 256 > net.inet.ip.dummynet.max_chain_len: 16 > net.inet.ip.dummynet.expire: 1 > net.inet.ip.dummynet.search_steps: 0 > net.inet.ip.dummynet.searches: 0 > net.inet.ip.dummynet.extract_heap: 0 > net.inet.ip.dummynet.ready_heap: 16 > net.inet.ip.dummynet.curr_time: 1804818806 > net.inet.ip.dummynet.hash_size: 64 > # sysctl -a | grep fw > net.inet.ip.fw.dyn_keepalive: 1 > net.inet.ip.fw.dyn_short_lifetime: 5 > net.inet.ip.fw.dyn_udp_lifetime: 10 > net.inet.ip.fw.dyn_rst_lifetime: 1 > net.inet.ip.fw.dyn_fin_lifetime: 1 > net.inet.ip.fw.dyn_syn_lifetime: 20 > net.inet.ip.fw.dyn_ack_lifetime: 300 > net.inet.ip.fw.static_count: 26 > net.inet.ip.fw.dyn_max: 4096 > net.inet.ip.fw.dyn_count: 0 > net.inet.ip.fw.curr_dyn_buckets: 256 > net.inet.ip.fw.dyn_buckets: 256 > net.inet.ip.fw.default_rule: 65535 > net.inet.ip.fw.verbose_limit: 0 > net.inet.ip.fw.verbose: 0 > net.inet.ip.fw.debug: 1 > net.inet.ip.fw.one_pass: 1 > net.inet.ip.fw.autoinc_step: 100 > net.inet.ip.fw.enable: 1 > > rule set > > 00900 15945359 1264958184 allow ip from 10.18.0.6 to any out xmit bce0 > 00901 44378882 8041056830 pipe 1 ip from 10.18.0.0/24 to any out xmit bce0 > 00910 225165 18913860 pipe 1 ip from 10.18.2.1 to any out xmit bce0 > 00915 0 0 pipe 2 ip from 10.18.2.2 to any out xmit bce0 > 00920 0 0 pipe 3 ip from 10.18.2.3 to any out xmit bce0 > 01000 265959 40261978 pipe 1 ip from 10.21.192.8/29 to any out xmit bce0 > 01001 19627389 3444748305 pipe 1 ip from 10.20.0.0/20 to any out xmit bce0 > 01002 180922838 31277916333 pipe 1 ip from 10.21.32.0/20 to any out xmit bce0 > 01003 376697028 75171259985 pipe 1 ip from 10.20.64.0/20 to any out xmit bce0 > 01004 68629348 12603497407 pipe 1 ip from 10.20.192.0/20 to any out xmit bce0 > 01005 185005607 37413644435 pipe 1 ip from 10.20.176.0/20 to any out xmit bce0 > 01006 59179395 10051795154 pipe 1 ip from 10.20.144.0/20 to any out xmit bce0 > 01007 235863676 41845371053 pipe 1 ip from 10.20.128.0/20 to any out xmit bce0 > 01008 51518999 10847386956 pipe 1 ip from 10.20.96.0/20 to any out xmit bce0 > 01009 79734709 13723937026 pipe 1 ip from 10.20.112.0/20 to any out xmit bce0 > 01010 30062283 4078276506 pipe 1 ip from 10.20.80.0/20 to any out xmit bce0 > 01011 36318511 6974450810 pipe 1 ip from 10.20.208.0/20 to any out xmit bce0 > 01012 19642496 3098922560 pipe 1 ip from 10.20.160.0/20 to any out xmit bce0 > 01013 18209570 2964820411 pipe 1 ip from 10.20.224.0/20 to any out xmit bce0 > 01014 13707931 3915527156 pipe 1 ip from 10.22.160.0/20 to any out xmit bce0 > 01015 9893051 1175739042 pipe 1 ip from 10.21.112.0/20 to any out xmit bce0 > 01016 39876049 7905051976 pipe 1 ip from 10.22.144.0/20 to any out xmit bce0 > 01017 0 0 pipe 1 ip from 10.22.147.0/24 to any out xmit bce0 > 01018 128251743 24972920481 pipe 1 ip from 10.21.0.0/20 to any out xmit bce0 > 01019 102099411 27172050432 pipe 1 ip from 10.21.16.0/20 to any out xmit bce0 > 65535 53581341116 24295389614128 allow ip from any to any > > and pipe spec > > # ipfw pipe list > 00001: 11.500 Mbit/s 0 ms 75 KB 1 queues (1 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte > Drp > 0 tcp 10.21.44.163/47934 65.55.131.121/80 1735939204 358391598184 > 1 191 10152696 > > > You can see that the bw has been configured to 11.5Mbit/s which should be the > base 10 expression for bit/s meaning exactly 11,500,000 bit/s Yes, but I don't see how you get 11.5Mbit/s from your specification above of 1Mbit/s? Or is this a different example? > And here lies the question again does this limit include layer 2 Ethernet > frame headers in the bit/s counting mechanism I'd say not, but check with your provider that 1Mbit/s of IP is allowed; that would be my expectation of such a spec, hereabouts anyway. cheers, Ian From lars.eggert at nokia.com Sat Aug 22 00:10:05 2009 From: lars.eggert at nokia.com (Lars Eggert) Date: Sat Aug 22 00:10:17 2009 Subject: bin/117214: ipfw(8) fwd with IPv6 treats input as IPv4 Message-ID: <200908220010.n7M0A419071352@freefall.freebsd.org> The following reply was made to PR bin/117214; it has been noted by GNATS. From: Lars Eggert To: bug-followup@FreeBSD.org, fabian@wenks.ch Cc: Subject: Re: bin/117214: ipfw(8) fwd with IPv6 treats input as IPv4 Date: Sat, 22 Aug 2009 02:27:44 +0300 I still see this on 7.2-STABLE: [root@fit: ~] uname -a FreeBSD fit.nokia.com 7.2-STABLE FreeBSD 7.2-STABLE #18: Fri Jun 26 15:43:17 EEST 2009 root@fit.nokia.com:/usr/obj/usr/src/sys/FIT i386 [root@fit: ~] ipfw add 64010 fwd 2001:2060:40:1::1 ip6 from 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:0708:0040:fff2::1/64 out 64010 fwd 0.0.7.209,2060 ip6 from 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:708:40:fff2::/64 out [root@fit: ~] ipfw show 64010 64010 0 0 fwd 0.0.7.209,2060 ip6 from 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:708:40:fff2::/64 out From lars.eggert at nokia.com Sat Aug 22 00:10:07 2009 From: lars.eggert at nokia.com (Lars Eggert) Date: Sat Aug 22 00:10:17 2009 Subject: bin/104921: [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (another variation on PR 91245) Message-ID: <200908220010.n7M0A78T071385@freefall.freebsd.org> The following reply was made to PR bin/104921; it has been noted by GNATS. From: Lars Eggert To: bug-followup@FreeBSD.org, seh-10lzx4@mail.quadrizen.com Cc: Subject: Re: bin/104921: [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (another variation on PR 91245) Date: Sat, 22 Aug 2009 02:27:27 +0300 I still see this on 7.2-STABLE: [root@fit: ~] uname -a FreeBSD fit.nokia.com 7.2-STABLE FreeBSD 7.2-STABLE #18: Fri Jun 26 15:43:17 EEST 2009 root@fit.nokia.com:/usr/obj/usr/src/sys/FIT i386 [root@fit: ~] ipfw add 64010 fwd 2001:2060:40:1::1 ip6 from 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:0708:0040:fff2::1/64 out 64010 fwd 0.0.7.209,2060 ip6 from 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:708:40:fff2::/64 out [root@fit: ~] ipfw show 64010 64010 0 0 fwd 0.0.7.209,2060 ip6 from 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:708:40:fff2::/64 out From wjw at digiware.nl Sat Aug 22 11:42:22 2009 From: wjw at digiware.nl (Willem Jan Withagen) Date: Sat Aug 22 11:42:28 2009 Subject: bin/117214: ipfw(8) fwd with IPv6 treats input as IPv4 In-Reply-To: <200908220010.n7M0A419071352@freefall.freebsd.org> References: <200908220010.n7M0A419071352@freefall.freebsd.org> Message-ID: <4A8FD99F.1050406@digiware.nl> Lars Eggert wrote: > The following reply was made to PR bin/117214; it has been noted by GNATS. > > From: Lars Eggert > To: bug-followup@FreeBSD.org, fabian@wenks.ch > Cc: > Subject: Re: bin/117214: ipfw(8) fwd with IPv6 treats input as IPv4 > Date: Sat, 22 Aug 2009 02:27:44 +0300 > > I still see this on 7.2-STABLE: > > [root@fit: ~] uname -a > FreeBSD fit.nokia.com 7.2-STABLE FreeBSD 7.2-STABLE #18: Fri Jun 26 > 15:43:17 EEST 2009 root@fit.nokia.com:/usr/obj/usr/src/sys/FIT i386 > > [root@fit: ~] ipfw add 64010 fwd 2001:2060:40:1::1 ip6 from > 2001:2060:40:1::123,2001:2060:40:1::124 to not > 2001:0708:0040:fff2::1/64 out > 64010 fwd 0.0.7.209,2060 ip6 from > 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:708:40:fff2::/64 out > > [root@fit: ~] ipfw show 64010 > 64010 0 0 fwd 0.0.7.209,2060 ip6 from > 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:708:40:fff2::/64 out The trouble is with the :'s and the fact that parsing doen't really take care of multiple :'s. What I considering is changing it in such a way that one is allowed to specify ipv6 adresses as [a:bc::d] just like it works in firefox (and other places) Question then is do we use [a:bc::d]/48:53 or [a:bc::d/48]:53? --WjW From lars.eggert at nokia.com Sun Aug 23 14:06:03 2009 From: lars.eggert at nokia.com (Lars Eggert) Date: Sun Aug 23 14:06:12 2009 Subject: bin/117214: ipfw(8) fwd with IPv6 treats input as IPv4 In-Reply-To: <4A8FD99F.1050406@digiware.nl> References: <200908220010.n7M0A419071352@freefall.freebsd.org> <4A8FD99F.1050406@digiware.nl> Message-ID: <67526C6C-7C00-4D0F-A987-B9AA42868E59@nokia.com> Well, one pretty simple (and not always correct) fix would be to assume that if an address has more than 1 colon, it's IPv6. The correct fix is to generate a small flex parser. Lars On 2009-8-22, at 14:42, Willem Jan Withagen wrote: > Lars Eggert wrote: >> The following reply was made to PR bin/117214; it has been noted by >> GNATS. >> >> From: Lars Eggert >> To: bug-followup@FreeBSD.org, fabian@wenks.ch >> Cc: >> Subject: Re: bin/117214: ipfw(8) fwd with IPv6 treats input as IPv4 >> Date: Sat, 22 Aug 2009 02:27:44 +0300 >> >> I still see this on 7.2-STABLE: >> >> [root@fit: ~] uname -a >> FreeBSD fit.nokia.com 7.2-STABLE FreeBSD 7.2-STABLE #18: Fri Jun 26 >> 15:43:17 EEST 2009 root@fit.nokia.com:/usr/obj/usr/src/sys/FIT >> i386 >> >> [root@fit: ~] ipfw add 64010 fwd 2001:2060:40:1::1 ip6 from >> 2001:2060:40:1::123,2001:2060:40:1::124 to not >> 2001:0708:0040:fff2::1/64 out >> 64010 fwd 0.0.7.209,2060 ip6 from >> 2001:2060:40:1::123,2001:2060:40:1::124 to not >> 2001:708:40:fff2::/64 out >> >> [root@fit: ~] ipfw show 64010 >> 64010 0 0 fwd 0.0.7.209,2060 ip6 from >> 2001:2060:40:1::123,2001:2060:40:1::124 to not >> 2001:708:40:fff2::/64 out > > The trouble is with the :'s and the fact that parsing doen't really > take > care of multiple :'s. > What I considering is changing it in such a way that one is allowed to > specify ipv6 adresses as [a:bc::d] just like it works in firefox (and > other places) > > Question then is do we use [a:bc::d]/48:53 or [a:bc::d/48]:53? > > --WjW From wjw at digiware.nl Sun Aug 23 20:25:52 2009 From: wjw at digiware.nl (Willem Jan Withagen) Date: Sun Aug 23 20:25:58 2009 Subject: bin/117214: ipfw(8) fwd with IPv6 treats input as IPv4 In-Reply-To: <67526C6C-7C00-4D0F-A987-B9AA42868E59@nokia.com> References: <200908220010.n7M0A419071352@freefall.freebsd.org> <4A8FD99F.1050406@digiware.nl> <67526C6C-7C00-4D0F-A987-B9AA42868E59@nokia.com> Message-ID: <4A91A5CD.1010901@digiware.nl> Lars Eggert wrote: > Well, one pretty simple (and not always correct) fix would be to assume > that if an address has more than 1 colon, it's IPv6. > > The correct fix is to generate a small flex parser. Which will require to spec an real grammar for the tokens. In itself of course a "good thing(tm)" --WjW From bugmaster at FreeBSD.org Mon Aug 24 11:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 24 11:08:34 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200908241106.n7OB6vPm048623@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 62 problems total. From bugmaster at FreeBSD.org Mon Aug 31 11:07:09 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 31 11:08:34 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200908311107.n7VB783k070603@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 62 problems total.