From bugmaster at FreeBSD.org Mon Mar 2 03:07:35 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 2 03:11:26 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200903021106.n22B6s46057336@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/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 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 55 problems total. From sebastian.mellmann at net.t-labs.tu-berlin.de Wed Mar 4 11:48:31 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Wed Mar 4 11:48:37 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so Message-ID: <49AED3B1.1060209@net.t-labs.tu-berlin.de> Hi everyone! I hope this is the right place to ask. I've got a IPFW ruleset that looks like this: cmd=ipfw bottleneck_bandwidth=100Mbit/s in_if="em0" $cmd pipe 500 config bw $bottleneck_bandwidth $cmd add pipe 500 all from any to any via $in_if When I do a simple ping from one machine to another (actually the FreeBSD machine is between those machines), I can see a delay of ~2ms. Without any rules/pipes I've got under 1ms delay. The question is: Why do I have such a "high" delay though I didn't configure any "delay" in my pipe? Where does this additional millisecond come from (processing delay for the packet in the pipe?)? If I configure another rule (or like 10 more rules) that matches the packet, I can see the delay increasing. For example a delay of ~20ms, when I configure 10 pipes. Am I doing something wrong? Thanks in advance for any help and please tell me if you need additional informations (e.g. kernel configuration). Regards, Sebastian M. From sebastian.mellmann at net.t-labs.tu-berlin.de Wed Mar 4 13:05:56 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Wed Mar 4 13:06:03 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <20090304210017.GA29615@onelab2.iet.unipi.it> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <20090304210017.GA29615@onelab2.iet.unipi.it> Message-ID: <49AEED31.8060801@net.t-labs.tu-berlin.de> > On Wed, Mar 04, 2009 at 08:17:05PM +0100, Sebastian Mellmann wrote: > >> Hi everyone! >> >> I hope this is the right place to ask. >> >> I've got a IPFW ruleset that looks like this: >> >> cmd=ipfw >> bottleneck_bandwidth=100Mbit/s >> in_if="em0" >> >> $cmd pipe 500 config bw $bottleneck_bandwidth >> $cmd add pipe 500 all from any to any via $in_if >> > > the delay that a packet experiences corresponds to len/bandwidth, > often rounded up to the next clock tick (1ms is the default). > You get one delay inbound, one delay outbound, so that's 2ms. > > Is there any chance to change this clock tick to a lower value? I think it's the 'HZ=' option in the kernel config isn't it? > cheers > luigi > Regards, Sebastian From rizzo at iet.unipi.it Wed Mar 4 13:09:11 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Wed Mar 4 13:09:19 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <49AEED31.8060801@net.t-labs.tu-berlin.de> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <20090304210017.GA29615@onelab2.iet.unipi.it> <49AEED31.8060801@net.t-labs.tu-berlin.de> Message-ID: <20090304211409.GA29824@onelab2.iet.unipi.it> On Wed, Mar 04, 2009 at 10:05:53PM +0100, Sebastian Mellmann wrote: > > > On Wed, Mar 04, 2009 at 08:17:05PM +0100, Sebastian Mellmann wrote: > > > >> Hi everyone! > >> > >> I hope this is the right place to ask. > >> > >> I've got a IPFW ruleset that looks like this: > >> > >> cmd=ipfw > >> bottleneck_bandwidth=100Mbit/s > >> in_if="em0" > >> > >> $cmd pipe 500 config bw $bottleneck_bandwidth > >> $cmd add pipe 500 all from any to any via $in_if > >> > > > > the delay that a packet experiences corresponds to len/bandwidth, > > often rounded up to the next clock tick (1ms is the default). > > You get one delay inbound, one delay outbound, so that's 2ms. > > > > > Is there any chance to change this clock tick to a lower value? > I think it's the 'HZ=' option in the kernel config isn't it? yes. i believe there is a tunable (so you don't need to rebuild the kernel) but i do not remember exactly which one. cheers luigi From rizzo at iet.unipi.it Wed Mar 4 13:11:30 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Wed Mar 4 13:11:36 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <49AED3B1.1060209@net.t-labs.tu-berlin.de> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> Message-ID: <20090304210017.GA29615@onelab2.iet.unipi.it> On Wed, Mar 04, 2009 at 08:17:05PM +0100, Sebastian Mellmann wrote: > Hi everyone! > > I hope this is the right place to ask. > > I've got a IPFW ruleset that looks like this: > > cmd=ipfw > bottleneck_bandwidth=100Mbit/s > in_if="em0" > > $cmd pipe 500 config bw $bottleneck_bandwidth > $cmd add pipe 500 all from any to any via $in_if the delay that a packet experiences corresponds to len/bandwidth, often rounded up to the next clock tick (1ms is the default). You get one delay inbound, one delay outbound, so that's 2ms. cheers luigi From fjwcash at gmail.com Wed Mar 4 13:48:54 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Wed Mar 4 13:49:00 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <20090304211409.GA29824@onelab2.iet.unipi.it> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <49AEED31.8060801@net.t-labs.tu-berlin.de> <20090304211409.GA29824@onelab2.iet.unipi.it> Message-ID: <200903041318.23083.fjwcash@gmail.com> On March 4, 2009 1:14 pm Luigi Rizzo wrote: > On Wed, Mar 04, 2009 at 10:05:53PM +0100, Sebastian Mellmann wrote: > > > On Wed, Mar 04, 2009 at 08:17:05PM +0100, Sebastian Mellmann wrote: > > > the delay that a packet experiences corresponds to len/bandwidth, > > > often rounded up to the next clock tick (1ms is the default). > > > You get one delay inbound, one delay outbound, so that's 2ms. > > > > Is there any chance to change this clock tick to a lower value? > > I think it's the 'HZ=' option in the kernel config isn't it? > > yes. i believe there is a tunable (so you don't need to rebuild > the kernel) but i do not remember exactly which one. kern.hz in /boot/loader.conf -- Freddie fjwcash@gmail.com From smithi at nimnet.asn.au Wed Mar 4 18:40:40 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Wed Mar 4 18:40:47 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <49AED3B1.1060209@net.t-labs.tu-berlin.de> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> Message-ID: <20090305124242.P71460@sola.nimnet.asn.au> On Wed, 4 Mar 2009, Sebastian Mellmann wrote: > I've got a IPFW ruleset that looks like this: > > cmd=ipfw > bottleneck_bandwidth=100Mbit/s > in_if="em0" > > $cmd pipe 500 config bw $bottleneck_bandwidth > $cmd add pipe 500 all from any to any via $in_if > > When I do a simple ping from one machine to another (actually the > FreeBSD machine is between those machines), I can see a delay of ~2ms. > Without any rules/pipes I've got under 1ms delay. Presumably each of the other machines are on a separate interface? Configured as a bridge or a router? > The question is: > Why do I have such a "high" delay though I didn't configure any "delay" > in my pipe? > Where does this additional millisecond come from (processing delay for > the packet in the pipe?)? Covered; kern.hz=1000 should give you more like .2ms with this setup. > If I configure another rule (or like 10 more rules) that matches the > packet, I can see the delay increasing. > For example a delay of ~20ms, when I configure 10 pipes. > Am I doing something wrong? Configuring more pipes shouldn't make any difference unless packets are made to traverse each of the pipes in turn. That would imply having set net.inet.ip.fw.one_pass=0 (or having run 'ipfw disable one_pass') so that each packet is reinjected into the firewall at the following rule, after traversing each pipe; is that what you're doing? Also, without using a separate pipe for either traffic direction, you're using 'half-duplex' mode, as well described in ipfw(8) TRAFFIC SHAPING. > Thanks in advance for any help and please tell me if you need additional > informations (e.g. kernel configuration). Output of 'sysctl net.inet.ip.fw.one_pass' and 'ipfw show' with your example of using multiple pipes? cheers, Ian From sebastian.mellmann at net.t-labs.tu-berlin.de Wed Mar 4 23:17:51 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Wed Mar 4 23:17:59 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <200903041318.23083.fjwcash@gmail.com> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <49AEED31.8060801@net.t-labs.tu-berlin.de> <20090304211409.GA29824@onelab2.iet.unipi.it> <200903041318.23083.fjwcash@gmail.com> Message-ID: <36634.62.206.221.107.1236237469.squirrel@anubis.getmyip.com> >> > Is there any chance to change this clock tick to a lower value? >> > I think it's the 'HZ=' option in the kernel config isn't it? >> >> yes. i believe there is a tunable (so you don't need to rebuild >> the kernel) but i do not remember exactly which one. > > kern.hz in /boot/loader.conf I only got an empty loader.conf file on my system. How is the syntax of the 'kern.hz' option? Regards, Sebastian From sebastian.mellmann at net.t-labs.tu-berlin.de Wed Mar 4 23:21:50 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Wed Mar 4 23:21:56 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <20090305124242.P71460@sola.nimnet.asn.au> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <20090305124242.P71460@sola.nimnet.asn.au> Message-ID: <36832.62.206.221.107.1236237708.squirrel@anubis.getmyip.com> > > When I do a simple ping from one machine to another (actually the > > FreeBSD machine is between those machines), I can see a delay of ~2ms. > > Without any rules/pipes I've got under 1ms delay. > > Presumably each of the other machines are on a separate interface? > Configured as a bridge or a router? Yes separate interfaces. The machine is configured as a router (as far as I know, I didn't set it up.) > > The question is: > > Why do I have such a "high" delay though I didn't configure any "delay" > > in my pipe? > > Where does this additional millisecond come from (processing delay for > > the packet in the pipe?)? > > Covered; kern.hz=1000 should give you more like .2ms with this setup. See my previous mail to the list (syntax of kern.hz). > > If I configure another rule (or like 10 more rules) that matches the > > packet, I can see the delay increasing. > > For example a delay of ~20ms, when I configure 10 pipes. > > Am I doing something wrong? > > Configuring more pipes shouldn't make any difference unless packets are > made to traverse each of the pipes in turn. That would imply having set > net.inet.ip.fw.one_pass=0 (or having run 'ipfw disable one_pass') so > that each packet is reinjected into the firewall at the following rule, > after traversing each pipe; is that what you're doing? Yes, I've set net.inet.ip.fw.one_pass=0 so packets are reinjected into the firewall after passing a pipe. > Also, without using a separate pipe for either traffic direction, you're > using 'half-duplex' mode, as well described in ipfw(8) TRAFFIC SHAPING. > > > Thanks in advance for any help and please tell me if you need > additional > > informations (e.g. kernel configuration). > > Output of 'sysctl net.inet.ip.fw.one_pass' and 'ipfw show' with your > example of using multiple pipes? [root@ ~/ipfw]# sysctl net.inet.ip.fw.one_pass net.inet.ip.fw.one_pass: 0 [root@ ~/ipfw]# ipfw show 00010 0 0 allow ip from any to any via lo0 10000 122 11832 allow ip from any to any via em2 10100 0 0 pipe 100 ip from 192.168.5.0/26 to 192.168.7.0/24 in via em0 10200 0 0 pipe 200 ip from 192.168.7.0/24 to 192.168.5.0/26 out via em0 10300 342 28728 pipe 500 ip from any to any via em0 10400 359 36512 pipe 510 ip from any to any via em1 10500 0 0 pipe 300 udp from 80.80.80.1 to 60.60.60.1 src-port 4000 dst-port 4000 via em1 10600 0 0 pipe 305 udp from 60.60.60.1 to 80.80.80.1 src-port 4000 dst-port 4000 via em0 10700 0 0 pipe 310 udp from 80.80.80.1 to 60.60.60.1 src-port 4001 dst-port 4001 via em1 10800 0 0 pipe 315 udp from 60.60.60.1 to 80.80.80.1 src-port 4001 dst-port 4001 via em0 65535 14144748 9784372451 allow ip from any to any > cheers, Ian Regards, Sebastian From oleg at FreeBSD.org Thu Mar 5 02:48:07 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Thu Mar 5 02:48:14 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <49AED3B1.1060209@net.t-labs.tu-berlin.de> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> Message-ID: <20090305103232.GA19726@lath.rinet.ru> On Wed, Mar 04, 2009 at 08:17:05PM +0100, Sebastian Mellmann wrote: > Hi everyone! > > I hope this is the right place to ask. > > I've got a IPFW ruleset that looks like this: > > cmd=ipfw > bottleneck_bandwidth=100Mbit/s > in_if="em0" > > $cmd pipe 500 config bw $bottleneck_bandwidth > $cmd add pipe 500 all from any to any via $in_if > > When I do a simple ping from one machine to another (actually the > FreeBSD machine is between those machines), I can see a delay of ~2ms. > Without any rules/pipes I've got under 1ms delay. > > The question is: > Why do I have such a "high" delay though I didn't configure any "delay" > in my pipe? > Where does this additional millisecond come from (processing delay for > the packet in the pipe?)? > If I configure another rule (or like 10 more rules) that matches the > packet, I can see the delay increasing. > For example a delay of ~20ms, when I configure 10 pipes. > Am I doing something wrong? > > Thanks in advance for any help and please tell me if you need additional > informations (e.g. kernel configuration). > > > Regards, > Sebastian M. > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" If you have 7.1R or 6.4R setting net.inet.ip.dummynet.io_fast=1 will probably reduce latency. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From fjwcash at gmail.com Thu Mar 5 09:14:51 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Thu Mar 5 09:14:58 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <36634.62.206.221.107.1236237469.squirrel@anubis.getmyip.com> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <200903041318.23083.fjwcash@gmail.com> <36634.62.206.221.107.1236237469.squirrel@anubis.getmyip.com> Message-ID: <200903050914.48406.fjwcash@gmail.com> On March 4, 2009 11:17 pm Sebastian Mellmann wrote: > >> > Is there any chance to change this clock tick to a lower value? > >> > I think it's the 'HZ=' option in the kernel config isn't it? > >> > >> yes. i believe there is a tunable (so you don't need to rebuild > >> the kernel) but i do not remember exactly which one. > > > > kern.hz in /boot/loader.conf > > I only got an empty loader.conf file on my system. > > How is the syntax of the 'kern.hz' option? grep kern /boot/defaults/loader.conf: #kern.hz="100" # Set the kernel interval timer rate Thus, just add kern.hz=1000 into /boot/loader.conf to have it set at boot time. -- Freddie fjwcash@gmail.com From smithi at nimnet.asn.au Thu Mar 5 10:48:36 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Mar 5 10:48:43 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <36832.62.206.221.107.1236237708.squirrel@anubis.getmyip.com> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <20090305124242.P71460@sola.nimnet.asn.au> <36832.62.206.221.107.1236237708.squirrel@anubis.getmyip.com> Message-ID: <20090306033309.J71460@sola.nimnet.asn.au> On Thu, 5 Mar 2009, Sebastian Mellmann wrote: > > > If I configure another rule (or like 10 more rules) that matches the > > > packet, I can see the delay increasing. > > > For example a delay of ~20ms, when I configure 10 pipes. > > > Am I doing something wrong? > > > > Configuring more pipes shouldn't make any difference unless packets are > > made to traverse each of the pipes in turn. That would imply having set > > net.inet.ip.fw.one_pass=0 (or having run 'ipfw disable one_pass') so > > that each packet is reinjected into the firewall at the following rule, > > after traversing each pipe; is that what you're doing? > > Yes, I've set net.inet.ip.fw.one_pass=0 so packets are reinjected into the > firewall after passing a pipe. Good; your results would have been pretty weird otherwise .. > > Also, without using a separate pipe for either traffic direction, you're > > using 'half-duplex' mode, as well described in ipfw(8) TRAFFIC SHAPING. Paired pipes will speed things up. Maybe not noticeably for pings (call and response work half-duplex) but for esp TCP it could be considerable. > > Output of 'sysctl net.inet.ip.fw.one_pass' and 'ipfw show' with your > > example of using multiple pipes? > > [root@ ~/ipfw]# sysctl net.inet.ip.fw.one_pass > net.inet.ip.fw.one_pass: 0 > > [root@ ~/ipfw]# ipfw show > 00010 0 0 allow ip from any to any via lo0 > 10000 122 11832 allow ip from any to any via em2 > 10100 0 0 pipe 100 ip from 192.168.5.0/26 to 192.168.7.0/24 in via em0 > 10200 0 0 pipe 200 ip from 192.168.7.0/24 to 192.168.5.0/26 out via em0 > 10300 342 28728 pipe 500 ip from any to any via em0 > 10400 359 36512 pipe 510 ip from any to any via em1 > 10500 0 0 pipe 300 udp from 80.80.80.1 to 60.60.60.1 src-port 4000 dst-port 4000 via em1 > 10600 0 0 pipe 305 udp from 60.60.60.1 to 80.80.80.1 src-port 4000 dst-port 4000 via em0 > 10700 0 0 pipe 310 udp from 80.80.80.1 to 60.60.60.1 src-port 4001 dst-port 4001 via em1 > 10800 0 0 pipe 315 udp from 60.60.60.1 to 80.80.80.1 src-port 4001 dst-port 4001 via em0 > 65535 14144748 9784372451 allow ip from any to any A note of caution: using 'via' unqualified can be tricky; 'via em0' on the inbound pass is the same as 'in recv em0', but 'via em0' on the outbound pass includes packets that came IN on em0 but are going out on any interface, as well as those that came in on any interface that are going OUT on em0. I prefer specifying 'in recv' and 'out xmit' where there might be any ambiguity; this usually works naturally with pipes, where you'd normally have one pipe per flow direction anyway. Hopefully increasing kern.hz solves your main issue, and worth trying the new! net.inet.ip.dummynet.io_fast too. Let us know your results? cheers, Ian From sebastian.mellmann at net.t-labs.tu-berlin.de Thu Mar 5 10:58:33 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Thu Mar 5 10:58:40 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <20090306033309.J71460@sola.nimnet.asn.au> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <20090305124242.P71460@sola.nimnet.asn.au> <36832.62.206.221.107.1236237708.squirrel@anubis.getmyip.com> <20090306033309.J71460@sola.nimnet.asn.au> Message-ID: <49B020D8.8070502@net.t-labs.tu-berlin.de> > > > Also, without using a separate pipe for either traffic direction, you're > > > using 'half-duplex' mode, as well described in ipfw(8) TRAFFIC SHAPING. > > Paired pipes will speed things up. Maybe not noticeably for pings (call > and response work half-duplex) but for esp TCP it could be considerable. > > How does this "pairing" of pipes work? Couldn't find any documentation about it. > > > Output of 'sysctl net.inet.ip.fw.one_pass' and 'ipfw show' with your > > > example of using multiple pipes? > > > > [root@ ~/ipfw]# sysctl net.inet.ip.fw.one_pass > > net.inet.ip.fw.one_pass: 0 > > > > [root@ ~/ipfw]# ipfw show > > 00010 0 0 allow ip from any to any via lo0 > > 10000 122 11832 allow ip from any to any via em2 > > 10100 0 0 pipe 100 ip from 192.168.5.0/26 to 192.168.7.0/24 in via em0 > > 10200 0 0 pipe 200 ip from 192.168.7.0/24 to 192.168.5.0/26 out via em0 > > 10300 342 28728 pipe 500 ip from any to any via em0 > > 10400 359 36512 pipe 510 ip from any to any via em1 > > 10500 0 0 pipe 300 udp from 80.80.80.1 to 60.60.60.1 src-port 4000 dst-port 4000 via em1 > > 10600 0 0 pipe 305 udp from 60.60.60.1 to 80.80.80.1 src-port 4000 dst-port 4000 via em0 > > 10700 0 0 pipe 310 udp from 80.80.80.1 to 60.60.60.1 src-port 4001 dst-port 4001 via em1 > > 10800 0 0 pipe 315 udp from 60.60.60.1 to 80.80.80.1 src-port 4001 dst-port 4001 via em0 > > 65535 14144748 9784372451 allow ip from any to any > > A note of caution: using 'via' unqualified can be tricky; 'via em0' on > the inbound pass is the same as 'in recv em0', but 'via em0' on the > outbound pass includes packets that came IN on em0 but are going out on > any interface, as well as those that came in on any interface that are > going OUT on em0. I prefer specifying 'in recv' and 'out xmit' where > there might be any ambiguity; this usually works naturally with pipes, > where you'd normally have one pipe per flow direction anyway. > > Actually I'm using 'in recv' and 'out xmit', but it wasn't applied in this example, but thanks for the hint again (you already mentioned that on the freebsd-question mailing list I think ;-)). > Hopefully increasing kern.hz solves your main issue, and worth trying > the new! net.inet.ip.dummynet.io_fast too. Let us know your results? > > For now we will stick to the delay "issue" and see how it affects our results. > cheers, Ian > Regards, Sebastian From smithi at nimnet.asn.au Thu Mar 5 11:22:30 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Mar 5 11:22:37 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <49B020D8.8070502@net.t-labs.tu-berlin.de> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <20090305124242.P71460@sola.nimnet.asn.au> <36832.62.206.221.107.1236237708.squirrel@anubis.getmyip.com> <20090306033309.J71460@sola.nimnet.asn.au> <49B020D8.8070502@net.t-labs.tu-berlin.de> Message-ID: <20090306060318.O71460@sola.nimnet.asn.au> On Thu, 5 Mar 2009, Sebastian Mellmann wrote: > > Paired pipes will speed things up. Maybe not noticeably for pings (call > > and response work half-duplex) but for esp TCP it could be considerable. > > How does this "pairing" of pipes work? > Couldn't find any documentation about it? Perhaps 'paired' isn't the best term for it, but see the ipfw(8) 'TRAFFIC SHAPING' section for the rationale and relevant examples. > Actually I'm using 'in recv' and 'out xmit', but it wasn't applied in > this example, but thanks for the hint again (you already mentioned that > on the freebsd-question mailing list I think ;-)). Sorry :) > For now we will stick to the delay "issue" and see how it affects our > results. Much more scientific than changing everything at once .. cheers, Ian From smithi at nimnet.asn.au Thu Mar 5 21:23:35 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Mar 5 21:23:42 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <20090304210017.GA29615@onelab2.iet.unipi.it> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <20090304210017.GA29615@onelab2.iet.unipi.it> Message-ID: <20090306153751.D71460@sola.nimnet.asn.au> On Wed, 4 Mar 2009, Luigi Rizzo wrote: > On Wed, Mar 04, 2009 at 08:17:05PM +0100, Sebastian Mellmann wrote: > > Hi everyone! > > > > I hope this is the right place to ask. > > > > I've got a IPFW ruleset that looks like this: > > > > cmd=ipfw > > bottleneck_bandwidth=100Mbit/s > > in_if="em0" > > > > $cmd pipe 500 config bw $bottleneck_bandwidth > > $cmd add pipe 500 all from any to any via $in_if > > the delay that a packet experiences corresponds to len/bandwidth, > often rounded up to the next clock tick (1ms is the default). > You get one delay inbound, one delay outbound, so that's 2ms. After finally getting almost enough sleep, I've just realised, duh, that Sebastian likely already had the default kern.hz=1000, ie 1ms, so would need something faster to achieve less delay. Which led me to take my own medicine and reread the dummynet sections in ipfw(8) at 7.1-RELEASE: delay ms-delay Propagation delay, measured in milliseconds. The value is rounded to the next multiple of the clock tick (typically 10ms, but it is a good practice to run kernels with ``options HZ=1000'' to reduce the granularity to 1ms or less). Default value is 0, meaning no delay. Firstly, this is well out of date; the default has been HZ=1000 since 6.1-R or earlier, a ten-fold increase on the old 100Hz. I'm not sure however that 10000 would be a suitable suggestion, even with today's processor speeds? Secondly, apropos Sebastian's experience, should this say "The value (even if 0) is rounded to the next multiple of the clock tick .." ? ^^^^^^^^^^^ cheers, Ian From rizzo at iet.unipi.it Thu Mar 5 22:55:09 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Mar 5 22:55:16 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <20090306153751.D71460@sola.nimnet.asn.au> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <20090304210017.GA29615@onelab2.iet.unipi.it> <20090306153751.D71460@sola.nimnet.asn.au> Message-ID: <20090306070011.GA94585@onelab2.iet.unipi.it> On Fri, Mar 06, 2009 at 04:23:29PM +1100, Ian Smith wrote: ... > Which led me to take my own medicine and reread the dummynet sections in > ipfw(8) at 7.1-RELEASE: > > delay ms-delay > Propagation delay, measured in milliseconds. The value is > rounded to the next multiple of the clock tick (typically 10ms, > but it is a good practice to run kernels with ``options HZ=1000'' > to reduce the granularity to 1ms or less). Default value is 0, > meaning no delay. > > Firstly, this is well out of date; the default has been HZ=1000 since > 6.1-R or earlier, a ten-fold increase on the old 100Hz. I'm not sure > however that 10000 would be a suitable suggestion, even with today's > processor speeds? You can bump it up HZ but there are things that do not scale as well as CPU clock frequencies. E.g. the access to slow peripherals on the PCI or ISA buses is still as slow as it was 15 years ago, and if your timer-driven routine needs to access one of those peripherals it might consume a significant number of microseconds. At HZ=1000 this is probably negligible; at HZ=10k you might start noticing. > Secondly, apropos Sebastian's experience, should this say "The value > (even if 0) is rounded to the next multiple of the clock tick .." ? > ^^^^^^^^^^^ 0 is rounded to 0 so that's not an issue. The delay Sebastian is seeing comes from the babdnwidth limitation, which is causing a non-zero "transmission time" which is rounded up. cheers luigi From sebastian.mellmann at net.t-labs.tu-berlin.de Thu Mar 5 23:06:52 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Thu Mar 5 23:06:59 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <20090306070011.GA94585@onelab2.iet.unipi.it> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <20090304210017.GA29615@onelab2.iet.unipi.it> <20090306153751.D71460@sola.nimnet.asn.au> <20090306070011.GA94585@onelab2.iet.unipi.it> Message-ID: <64393.62.206.221.107.1236323210.squirrel@anubis.getmyip.com> >> Secondly, apropos Sebastian's experience, should this say "The value >> (even if 0) is rounded to the next multiple of the clock tick .." ? >> ^^^^^^^^^^^ > > 0 is rounded to 0 so that's not an issue. > The delay Sebastian is seeing comes from the babdnwidth limitation, > which is causing a non-zero "transmission time" which is rounded up. Let me get this right: When I configure a pipe with bandwidth limitations, I'll always get some additional delay when a packet passes this pipe? > cheers > luigi Regards, Sebastian From rizzo at iet.unipi.it Thu Mar 5 23:17:27 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Mar 5 23:17:33 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <64393.62.206.221.107.1236323210.squirrel@anubis.getmyip.com> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <20090304210017.GA29615@onelab2.iet.unipi.it> <20090306153751.D71460@sola.nimnet.asn.au> <20090306070011.GA94585@onelab2.iet.unipi.it> <64393.62.206.221.107.1236323210.squirrel@anubis.getmyip.com> Message-ID: <20090306072229.GB94585@onelab2.iet.unipi.it> On Fri, Mar 06, 2009 at 08:06:50AM +0100, Sebastian Mellmann wrote: > > >> Secondly, apropos Sebastian's experience, should this say "The value > >> (even if 0) is rounded to the next multiple of the clock tick .." ? > >> ^^^^^^^^^^^ > > > > 0 is rounded to 0 so that's not an issue. > > The delay Sebastian is seeing comes from the babdnwidth limitation, > > which is causing a non-zero "transmission time" which is rounded up. > > Let me get this right: > > When I configure a pipe with bandwidth limitations, I'll always get some > additional delay when a packet passes this pipe? "additional" compared to the case of no bandwidth limitations. But the delay is exactly the effect of bandwidth limitations and the presence of the queue (and possibly +/- 1 tick of rounding), so you have to understand what is modeled if you want to account for it precisely. From sebastian.mellmann at net.t-labs.tu-berlin.de Fri Mar 6 02:45:47 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Fri Mar 6 02:45:53 2009 Subject: ipfw: Can't see other flows in pipe Message-ID: <5431.62.206.221.107.1236336345.squirrel@anubis.getmyip.com> Hi everyone! I've got the following ipfw rules: cmd="ipfw" webclient_upload_bandwidth="1024kbit/s" webclient_download_bandwidth="6144Kbit/s" bottleneck_bandwidth="100Mbit/s" client_rtt_delay=10 queue=50 client1_subnet="192.168.5.0/26" server1_subnet="192.168.7.0/24" $cmd pipe 100 config mask all bw $webclient_upload_bandwidth queue queue_size delay $client_rtt_delay $cmd pipe 200 config mask all bw $webclient_download_bandwidth queue queue_size delay $client_rtt_delay $cmd add pipe 100 all from $client1_subnet to $server1_subnet in recv $in_if $cmd add pipe 200 all from $server1_subnet to $client1_subnet out xmit $in_if $cmd pipe 500 config bw $bottleneck_bandwidth $cmd add pipe 500 all from any to any via $in_if $cmd pipe 510 config bw $bottleneck_bandwidth $cmd add pipe 510 all from any to any via $out_if For testing purposes I've got 4 concurrent downloads via scp from the server1_subnet to the client1_subnet. ipfw pipe show gives me the following: 00510: 100.000 Mbit/s 0 ms 50 sl. 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 192.168.5.4/47753 192.168.7.1/22 610244 609078476 2 104 1 00100: 1.024 Mbit/s 0 ms 50 sl. 4 queues (64 buckets) droptail mask: 0xff 0xffffffff/0xffff -> 0xffffffff/0xffff BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 18 tcp 192.168.5.4/47753 192.168.7.1/22 15067 820472 0 0 0 29 tcp 192.168.5.1/59724 192.168.7.1/22 64519 3512539 0 0 0 34 tcp 192.168.5.2/58805 192.168.7.1/22 64035 3481423 0 0 0 54 tcp 192.168.5.3/40995 192.168.7.1/22 66705 3633640 0 0 0 00305: unlimited 0 ms 50 sl. 0 queues (1 buckets) droptail 00310: unlimited 0 ms 50 sl. 0 queues (1 buckets) droptail 00200: 6.144 Mbit/s 0 ms 50 sl. 4 queues (64 buckets) droptail mask: 0xff 0xffffffff/0xffff -> 0xffffffff/0xffff BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 2 tcp 192.168.7.1/22 192.168.5.2/58805 121901 182399179 29 43124 234 47 tcp 192.168.7.1/22 192.168.5.3/40995 126392 189093880 43 64124 241 51 tcp 192.168.7.1/22 192.168.5.1/59724 122550 183349839 34 50624 251 60 tcp 192.168.7.1/22 192.168.5.4/47753 28565 42735852 0 0 55 00315: unlimited 0 ms 50 sl. 0 queues (1 buckets) droptail 00500: 100.000 Mbit/s 0 ms 50 sl. 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 192.168.5.4/47753 192.168.7.1/22 609337 607754332 2 1552 0 00300: unlimited 0 ms 50 sl. 0 queues (1 buckets) droptail Why do I only see ONE connection inside the 500/510 pipe? I thought I could see any connection going through that pipe. Regards, Sebastian P.S.: Sorry for sending it on 'freebsd-questions' too, I've messed up my address book :-( From smithi at nimnet.asn.au Fri Mar 6 05:27:36 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Mar 6 05:27:44 2009 Subject: ipfw: Can't see other flows in pipe In-Reply-To: <5431.62.206.221.107.1236336345.squirrel@anubis.getmyip.com> References: <5431.62.206.221.107.1236336345.squirrel@anubis.getmyip.com> Message-ID: <20090306234700.F71460@sola.nimnet.asn.au> On Fri, 6 Mar 2009, Sebastian Mellmann wrote: [.. after merciless snippage ..] > $cmd pipe 500 config bw $bottleneck_bandwidth > $cmd add pipe 500 all from any to any via $in_if > > $cmd pipe 510 config bw $bottleneck_bandwidth > $cmd add pipe 510 all from any to any via $out_if > ipfw pipe show gives me the following: > > 00510: 100.000 Mbit/s 0 ms 50 sl. 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 192.168.5.4/47753 192.168.7.1/22 610244 609078476 2 > 104 1 > 00500: 100.000 Mbit/s 0 ms 50 sl. 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 192.168.5.4/47753 192.168.7.1/22 609337 607754332 2 > 1552 0 > Why do I only see ONE connection inside the 500/510 pipe? > I thought I could see any connection going through that pipe. With no masking specified, all flows use the same bucket (0) so totals shown are of all packets through that pipe. src/dest addr/ports shown are those of the first packet using that bucket, not the most recent. You may also find http://info.iet.unipi.it/~luigi/ip_dummynet/ helpful. cheers, Ian From smithi at nimnet.asn.au Fri Mar 6 06:15:14 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Mar 6 06:15:20 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <20090306070011.GA94585@onelab2.iet.unipi.it> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <20090304210017.GA29615@onelab2.iet.unipi.it> <20090306153751.D71460@sola.nimnet.asn.au> <20090306070011.GA94585@onelab2.iet.unipi.it> Message-ID: <20090307003515.W71460@sola.nimnet.asn.au> On Fri, 6 Mar 2009, Luigi Rizzo wrote: > On Fri, Mar 06, 2009 at 04:23:29PM +1100, Ian Smith wrote: > ... > > ipfw(8) at 7.1-RELEASE: > > > > delay ms-delay > > Propagation delay, measured in milliseconds. The value is > > rounded to the next multiple of the clock tick (typically 10ms, > > but it is a good practice to run kernels with ``options HZ=1000'' > > to reduce the granularity to 1ms or less). Default value is 0, > > meaning no delay. > > > > Firstly, this is well out of date; the default has been HZ=1000 since > > 6.1-R or earlier, a ten-fold increase on the old 100Hz. I'm not sure > > however that 10000 would be a suitable suggestion, even with today's > > processor speeds? > > You can bump it up HZ but there are things that do not scale as well > as CPU clock frequencies. E.g. the access to slow peripherals on > the PCI or ISA buses is still as slow as it was 15 years ago, > and if your timer-driven routine needs to access one of those > peripherals it might consume a significant number of microseconds. > At HZ=1000 this is probably negligible; at HZ=10k you might start > noticing. Indeed. HZ=1000 is a bit busy (like ~+10% CPU) on a Celeron 300 laptop, now at 250Hz, no dummynet. I expect 10kHz slicing would drown it, ie without some qualification re CPU clock, suggested defaults are risky. > > Secondly, apropos Sebastian's experience, should this say "The value > > (even if 0) is rounded to the next multiple of the clock tick .." ? > > ^^^^^^^^^^^ > > 0 is rounded to 0 so that's not an issue. > The delay Sebastian is seeing comes from the babdnwidth limitation, > which is causing a non-zero "transmission time" which is rounded up. Think I've almost starting to get this, thanks. cheers, Ian From olli at lurza.secnetix.de Fri Mar 6 10:59:07 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Mar 6 10:59:14 2009 Subject: ipfw (dummynet) adds delay, but not configured to do so In-Reply-To: <64393.62.206.221.107.1236323210.squirrel@anubis.getmyip.com> Message-ID: <200903061859.n26Ix4QA070286@lurza.secnetix.de> Sebastian Mellmann wrote: > Luigi Rizzo wrote: > > The delay Sebastian is seeing comes from the babdnwidth limitation, > > which is causing a non-zero "transmission time" which is rounded up. > > Let me get this right: > > When I configure a pipe with bandwidth limitations, I'll always get some > additional delay when a packet passes this pipe? Yes, of course. That's expected. Transmitting a packet through a 10 Mbit link takes longer than transmitting the same packet through a 100 Mbit link. Dummynet correctly emulates that behaviour, but it is limited by the granularity of the kernel clock, which runs at 1000 Hz by default, so the delays are rounded to 1 ms. For example, transferring a 1 KB data packet (that's about 10 kbits including headers of the various protocols) will take about 1 ms on a 10 Mbit link, and 0.1 ms on 100 Mbit. Voila. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "In My Egoistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton From bettina at apoteelia.net Sat Mar 7 10:36:50 2009 From: bettina at apoteelia.net (Bettina Schmidtberger) Date: Sat Mar 7 10:37:11 2009 Subject: Der versprochene Geheimtipp Message-ID: <66c8068d0bb63321e1305c4a809b72f8@localhost.localdomain> Hi Du! Wie ich es Dir versprochen habe, wollte ich Dir ja noch die Adresse sagen wo wir die Dinger bestellt haben. Gibt ja viele Seiten wo man echt nur ?bers Ohr gehauen wird. Aber bei der Adresse bekommen wir immer nur Originalware und das innheralb k?rzester Zeit zugeschickt. Mit dem Zoll hatten wir da auch nie Probleme, da der Versand direkt aus Europa erfolgt. Klasse oder? Also hier nun die Adresse: http://www.apoteelia.net Viel Spass w?nsch ich Dir und das es gut funktioniert! Gru?, Deine Bettina . . - . . . . . . . . . . : . Gib Acht! Man hatte dir eingeredet, du h?ttest es schwer, dein Leben sei verpfuscht, das Leben sei eine Schuld, sei schlecht, ohne Sinn, ohne Wert; man wollte dich ducken, dich in die gro?e Armee der Leidenden schmuggeln, du solltest bemitleidenswert werden und bemitleiden: und du glaubtest ihnen ? wie ungern! ? und wieder nicht ? wie gern! Denn du bist stark, aber warst krank ? wo? wie? was wei? ich. Und deine Sehnsucht war, herauszukommen aus allen diesen m?den Verneinungen, diesen t?richten Formeln, die im Nein ihr Ja haben, diesen t?nenden Wissenschaften, diesen Worten ?. Deswegen sprangst du von Buch zu Buch, spieltest mit ihren Formeln und lie?est sie wieder fallen, die Neins und Wenns, um selber eine zu finden, aber ein Ja! sollte sie klingen ? denn du wolltest leben! Aber nicht wie der P?bel lebt ? einen Grund, ein Ziel, eine Lebensformel suchtest du. Nun, hier ist sie: Wei?t du: das Himmelsweinglas, das du ausschl?rfen wolltest ? ? nun niete dir die Formel: Die Welt schaffst du. Du vergeistigst das Chaos zur Welt; das Andere, das Noch-nicht-Du, das alte Ding an sich, ist nur das, was von dir noch nicht geschaffen, vermenschlicht, noch nicht dein Eigentum geworden ist. ? Du schaffst die Welt: nun lebe, lebe! ? Die kleine blaue Blume l?utete so froh und stark ? warum soll ich ihr nicht glauben? Und dann bin ich baden gegangen ? ? ? und habe stundenlang im Grase gelegen; und w?hrend die wei?en Wolken durch den Himmel segelten und der Flu? geruhig durch Schilfduft und Ried und schwatzendes Vogelvolk hinstr?mte, habe ich das Ding an sich, den Intellekt und den Willen verlacht und mir ein Ich-wei?-nicht-was? gew?nscht. Gegen Abend entstiegen Schw?rme von Eintagsfliegen dem Flu?, an den Gr?sern, Halmen und Pfosten kletterten sie hoch und warfen aus der H?lle sich in die Luft zum kurzen Hochzeitsleben. Die Luft war wei? ?ber den Wassern von den auf und nieder tanzenden Massen ? und die sinkende Sonne in dem H?henrauch, den der Nordwind gebracht hatte, rot wie ein Rubin: das h?tte mich fast bezwungen, da? ich schon begann, die stundenkurze Existenz der Imago zu beklagen und daran sentimentale Folgerungen zu kn?pfen ? aber da h?rte ich den Enzian l?uten und ich lachte: Das Tier freut sich jahrelang seines R?uberlebens, und dieser Liebesflug ist sein taumelnder H?hepunkt. Es lebe das Leben und seine ewige Br?cke: Venus genetrix! Vor acht Tagen h?tte ich ihr geflucht und geklagt: Was ist das Leben? So ist das Leben: es flie?t dahin wie Wellenschaum, kommt u From bugmaster at FreeBSD.org Mon Mar 9 10:15:07 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 9 10:16:27 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200903091715.n29HF6BK045282@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/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 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 55 problems total. From linimon at FreeBSD.org Wed Mar 11 23:23:35 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Mar 11 23:23:41 2009 Subject: kern/132553: [ipfw] ipfw doesn't understand ftp-data port Message-ID: <200903120623.n2C6NVcW070059@freefall.freebsd.org> Old Synopsis: ipfw doesnt understand ftp-data port New Synopsis: [ipfw] ipfw doesn't understand ftp-data port Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 12 06:22:56 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132553 From sebastian.mellmann at net.t-labs.tu-berlin.de Fri Mar 13 06:31:19 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Fri Mar 13 06:31:27 2009 Subject: ipfw: Can't see other flows in pipe In-Reply-To: <20090306234700.F71460@sola.nimnet.asn.au> References: <5431.62.206.221.107.1236336345.squirrel@anubis.getmyip.com> <20090306234700.F71460@sola.nimnet.asn.au> Message-ID: <49BA6027.3020004@net.t-labs.tu-berlin.de> > On Fri, 6 Mar 2009, Sebastian Mellmann wrote: > [.. after merciless snippage ..] > > > $cmd pipe 500 config bw $bottleneck_bandwidth > > $cmd add pipe 500 all from any to any via $in_if > > > > $cmd pipe 510 config bw $bottleneck_bandwidth > > $cmd add pipe 510 all from any to any via $out_if > > > ipfw pipe show gives me the following: > > > > 00510: 100.000 Mbit/s 0 ms 50 sl. 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 192.168.5.4/47753 192.168.7.1/22 610244 609078476 2 > > 104 1 > > > 00500: 100.000 Mbit/s 0 ms 50 sl. 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 192.168.5.4/47753 192.168.7.1/22 609337 607754332 2 > > 1552 0 > > > Why do I only see ONE connection inside the 500/510 pipe? > > I thought I could see any connection going through that pipe. > > With no masking specified, all flows use the same bucket (0) so totals > shown are of all packets through that pipe. src/dest addr/ports shown > are those of the first packet using that bucket, not the most recent. > > Ok that makes sense. But when I have a look at the "drop" value does it tell me the overall drops in that pipe or only the drops for the specific flow (in this case between 192.168.5.4 and 192.168.7.1)? > You may also find http://info.iet.unipi.it/~luigi/ip_dummynet/ helpful. > > cheers, Ian > Thanks for the help! Regards, Sebastian From dima_bsd at inbox.lv Fri Mar 13 14:06:20 2009 From: dima_bsd at inbox.lv (Dmitriy Demidov) Date: Fri Mar 13 14:06:28 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? Message-ID: <200903132246.49159.dima_bsd@inbox.lv> Hi list. I'm using DNS cache server Unbound-1.2.1. I want to start using DNSSEC via DLV (unbound gracefully allows it). My system is FreeBSD7-STABLE. I'm using ipfw. Original ipfw configuration: add check-state add deny icmp from any to any frag add allow icmp from any to me icmptypes 0,3,11 add allow icmp from me to any out keep-state add allow tcp from me to any out keep-state add allow udp from me to any out keep-state add deny ip from any to any /etc/sysctl.conf net.inet.ip.fw.dyn_udp_lifetime=60 The problem is that Unbound can't do DNSSEC validation using this firewall configuration. It blames some thing like this: [1236970569] unbound[9096:3] info: resolving [1236970569] unbound[9096:3] info: failed to prime trust anchor -- could not fetch DNSKEY rrset [1236970569] unbound[9096:3] info: Could not establish a chain of trust to keys for Unbound starts working only then I put in ipfw this set of rules to handle all UDP packets outside from keep-state rules: add allow udp from any to any add check-state add deny icmp from any to any frag add allow icmp from any to me icmptypes 0,3,11 add allow icmp from me to any out keep-state add allow tcp from me to any out keep-state add allow udp from me to any out keep-state add deny ip from any to any It looks like dynamicaly created rules some how inadequately handles big UDP packets (DNSSEC answers are big). Is there any who can help to investigate this issue (looks like I can't do it myself)? Can it be ipfw related issue? Thanks. From rizzo at iet.unipi.it Fri Mar 13 14:38:13 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Fri Mar 13 14:38:20 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <200903132246.49159.dima_bsd@inbox.lv> References: <200903132246.49159.dima_bsd@inbox.lv> Message-ID: <20090313214327.GA1675@onelab2.iet.unipi.it> On Fri, Mar 13, 2009 at 10:46:48PM +0200, Dmitriy Demidov wrote: > Hi list. > > I'm using DNS cache server Unbound-1.2.1. I want to start using DNSSEC via DLV (unbound gracefully allows it). > My system is FreeBSD7-STABLE. I'm using ipfw. > > Original ipfw configuration: > add check-state > add deny icmp from any to any frag > add allow icmp from any to me icmptypes 0,3,11 > add allow icmp from me to any out keep-state > add allow tcp from me to any out keep-state > add allow udp from me to any out keep-state > add deny ip from any to any > > /etc/sysctl.conf > net.inet.ip.fw.dyn_udp_lifetime=60 > > The problem is that Unbound can't do DNSSEC validation using this firewall configuration. It blames some thing like this: > [1236970569] unbound[9096:3] info: resolving > [1236970569] unbound[9096:3] info: failed to prime trust anchor -- could not fetch DNSKEY rrset > [1236970569] unbound[9096:3] info: Could not establish a chain of trust to keys for > > Unbound starts working only then I put in ipfw this set of rules to handle all UDP packets outside from keep-state rules: > add allow udp from any to any > add check-state > add deny icmp from any to any frag > add allow icmp from any to me icmptypes 0,3,11 > add allow icmp from me to any out keep-state > add allow tcp from me to any out keep-state > add allow udp from me to any out keep-state > add deny ip from any to any > > It looks like dynamicaly created rules some how inadequately handles big UDP packets (DNSSEC answers are big). > Is there any who can help to investigate this issue (looks like I can't do it myself)? > Can it be ipfw related issue? it is not related to dynamic rules, but to the fact that that the firewall is called before reassembling packets. The info (port numbers especially) is not available in the fragments so the firewall cannot do anything. The only solution would be to call the firewall after reassembly. I am not sure if there is any work in progress for that. cheers luigi From sem at FreeBSD.org Sat Mar 14 07:38:19 2009 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Sat Mar 14 07:38:26 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <200903132246.49159.dima_bsd@inbox.lv> References: <200903132246.49159.dima_bsd@inbox.lv> Message-ID: <49BBB94A.7040208@FreeBSD.org> Dmitriy Demidov wrote: > Unbound starts working only then I put in ipfw this set of rules to handle all UDP packets outside from keep-state rules: > add allow udp from any to any What if you add: add allow ip from any to any frag instead the line above? > add check-state > add deny icmp from any to any frag I'm not sure the line above is correct. > add allow icmp from any to me icmptypes 0,3,11 > add allow icmp from me to any out keep-state > add allow tcp from me to any out keep-state > add allow udp from me to any out keep-state > add deny ip from any to any > > It looks like dynamicaly created rules some how inadequately handles big UDP packets (DNSSEC answers are big). > Is there any who can help to investigate this issue (looks like I can't do it myself)? > Can it be ipfw related issue? -- Dixi. Sem. From dima_bsd at inbox.lv Sat Mar 14 11:31:57 2009 From: dima_bsd at inbox.lv (Dmitriy Demidov) Date: Sat Mar 14 11:32:04 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <49BBB94A.7040208@FreeBSD.org> References: <200903132246.49159.dima_bsd@inbox.lv> <49BBB94A.7040208@FreeBSD.org> Message-ID: <200903142031.53326.dima_bsd@inbox.lv> On Saturday 14 March 2009, Sergey Matveychuk wrote: > What if you add: > > add allow ip from any to any frag > > instead the line above? Hi Sergey. Yes, it works this way. Unbound can do DNSSEC queues via this rule (and can not without it). Here is a example (both ipfw and unbound is just restarted) before DNSSEC queue 00100 106 22184 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 0 0 allow ip from any to any frag 00500 0 0 check-state 00600 0 0 allow icmp from any to me icmptypes 0,3,11 00700 0 0 allow icmp from me to any out keep-state 00800 0 0 allow tcp from me to any out keep-state 00900 1 76 allow udp from me to any out keep-state 01000 30 1882 deny ip from any to any 65535 20 3300 deny ip from any to any after DNSSEC queue 00100 164 33830 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 1 461 allow ip from any to any frag 00500 0 0 check-state 00600 0 0 allow icmp from any to me icmptypes 0,3,11 00700 0 0 allow icmp from me to any out keep-state 00800 0 0 allow tcp from me to any out keep-state 00900 67 16551 allow udp from me to any out keep-state 01000 50 3134 deny ip from any to any 65535 20 3300 deny ip from any to any --- Hi Luigi. Thank you for answer. It is a big "surprise" for me that reassembling of IP datagrams is done not *before* they go into firewall, but *after* :( I have two questions. 1) Do modern Ethernet cards with enabled hardware offloading functions (and supported driver) can help in this situation (can they do reassembling)? 2) How hard it would be to extend ipfw functionality with feature that will enable him to make at least IP reassembling (just like pf scrub do it)? About my second question. If there is no any other way to solve this problem using current ipfw/FreeBSD implementation, then I can offer 500 WMZ (webmoney) bounty to any one who will extend ipfw (or FreeBSD ip stack?) functionality with "scrubber" that can do at least IP reassembling, and which code quality will be good enough for including him in official FreeBSD code base. Unfortunately 500$ is my upper limit at this moment. :) From on at cs.ait.ac.th Sat Mar 14 23:22:48 2009 From: on at cs.ait.ac.th (Olivier Nicole) Date: Sat Mar 14 23:22:54 2009 Subject: ipfw amd bridge Message-ID: <200903150605.n2F653Uw021328@banyan.cs.ait.ac.th> Hi, I remember reqading in the past (4.x) that on a machine with bridged interfaces, only layer 2 rules of ipfw would apply. Is this still the case with 6.4, 7.1? best regards, Olivier From julian at elischer.org Sat Mar 14 23:46:14 2009 From: julian at elischer.org (Julian Elischer) Date: Sat Mar 14 23:46:20 2009 Subject: ipfw amd bridge In-Reply-To: <200903150605.n2F653Uw021328@banyan.cs.ait.ac.th> References: <200903150605.n2F653Uw021328@banyan.cs.ait.ac.th> Message-ID: <49BCA1AC.7080905@elischer.org> Olivier Nicole wrote: > Hi, > > I remember reqading in the past (4.x) that on a machine with bridged > interfaces, only layer 2 rules of ipfw would apply. not quite. there are rules that do not work when called from a layer two point. e.g. divert does not work, nor does 'fwd' (without patches). Rules not specifically labeled "layer2" will still process packets, but rules labeled "not layer2" will not do so. (as expected). note if_bridge and bridge are different and may have behavioral differences in this regard. > > Is this still the case with 6.4, 7.1? > > best regards, > > Olivier > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From on at cs.ait.ac.th Sun Mar 15 00:36:55 2009 From: on at cs.ait.ac.th (Olivier Nicole) Date: Sun Mar 15 00:37:01 2009 Subject: ipfw amd bridge In-Reply-To: <49BCA1AC.7080905@elischer.org> (message from Julian Elischer on Sat, 14 Mar 2009 23:35:24 -0700) References: <200903150605.n2F653Uw021328@banyan.cs.ait.ac.th> <49BCA1AC.7080905@elischer.org> Message-ID: <200903150736.n2F7acad033835@banyan.cs.ait.ac.th> Thanks, > > I remember reqading in the past (4.x) that on a machine with bridged > > interfaces, only layer 2 rules of ipfw would apply. > > not quite. > there are rules that do not work when called from a layer two > point. e.g. divert does not work, nor does 'fwd' (without patches). And what would be the patches (if any exists)? > note if_bridge and bridge are different and may have > behavioral differences in this regard. I think it will be if_bridge (as bridge is obsolete). Bests, Olivier From julian at elischer.org Sun Mar 15 01:07:53 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Mar 15 01:08:00 2009 Subject: ipfw amd bridge In-Reply-To: <200903150736.n2F7acad033835@banyan.cs.ait.ac.th> References: <200903150605.n2F653Uw021328@banyan.cs.ait.ac.th> <49BCA1AC.7080905@elischer.org> <200903150736.n2F7acad033835@banyan.cs.ait.ac.th> Message-ID: <49BCB75D.60408@elischer.org> Olivier Nicole wrote: > Thanks, > >>> I remember reqading in the past (4.x) that on a machine with bridged >>> interfaces, only layer 2 rules of ipfw would apply. >> not quite. >> there are rules that do not work when called from a layer two >> point. e.g. divert does not work, nor does 'fwd' (without patches). > > And what would be the patches (if any exists)? > >> note if_bridge and bridge are different and may have >> behavioral differences in this regard. > > I think it will be if_bridge (as bridge is obsolete). > > Bests, > > Olivier > > I gave some to adrian (cc'd).. I don't have them available right now.. From sem at FreeBSD.org Sun Mar 15 02:38:43 2009 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Sun Mar 15 02:38:51 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <200903142031.53326.dima_bsd@inbox.lv> References: <200903132246.49159.dima_bsd@inbox.lv> <49BBB94A.7040208@FreeBSD.org> <200903142031.53326.dima_bsd@inbox.lv> Message-ID: <49BCCC9D.30109@FreeBSD.org> Dmitriy Demidov wrote: > Hi Luigi. Thank you for answer. > It is a big "surprise" for me that reassembling of IP datagrams is done not *before* they go into firewall, but *after* :( But what's wrong with it? A fragment got from net, pass firewall and store. After all fragments we got, OS reassembly a packet and pass it through firewall again. -- Dixi. Sem. From rizzo at iet.unipi.it Sun Mar 15 02:56:50 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sun Mar 15 02:56:56 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <49BCCC9D.30109@FreeBSD.org> References: <200903132246.49159.dima_bsd@inbox.lv> <49BBB94A.7040208@FreeBSD.org> <200903142031.53326.dima_bsd@inbox.lv> <49BCCC9D.30109@FreeBSD.org> Message-ID: <20090315100206.GA63505@onelab2.iet.unipi.it> On Sun, Mar 15, 2009 at 12:38:37PM +0300, Sergey Matveychuk wrote: > Dmitriy Demidov wrote: > >Hi Luigi. Thank you for answer. > >It is a big "surprise" for me that reassembling of IP datagrams is done > >not *before* they go into firewall, but *after* :( > > But what's wrong with it? A fragment got from net, pass firewall and > store. After all fragments we got, OS reassembly a packet and pass it > through firewall again. Currently we don't have a way to re-invoke the firewall after reassembly. In fact, we should probably provide hooks before and after reassembly, and use them in a configurable way. cheers luigi From dima_bsd at inbox.lv Sun Mar 15 02:59:06 2009 From: dima_bsd at inbox.lv (Dmitriy Demidov) Date: Sun Mar 15 02:59:12 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <49BCCC9D.30109@FreeBSD.org> References: <200903132246.49159.dima_bsd@inbox.lv> <200903142031.53326.dima_bsd@inbox.lv> <49BCCC9D.30109@FreeBSD.org> Message-ID: <200903151158.54572.dima_bsd@inbox.lv> On Sunday 15 March 2009, Sergey Matveychuk wrote: > Dmitriy Demidov wrote: > > Hi Luigi. Thank you for answer. > > It is a big "surprise" for me that reassembling of IP datagrams is done not *before* they go into firewall, but *after* :( > > But what's wrong with it? A fragment got from net, pass firewall and > store. After all fragments we got, OS reassembly a packet and pass it > through firewall again. > >>it is not related to dynamic rules, but to the fact that >>that the firewall is called before reassembling packets. >>The info (port numbers especially) is not available >>in the fragments so the firewall cannot do anything. >>The only solution would be to call the firewall >>after reassembly. I am not sure if there is any work in progress >>for that. If I got it right from Luigi explanation, then problem we see here happens this way: ipfw receivs fragmented IP datagrams what contains splited UDP packet insight (IP-fragment1/UDP-head) + (IP-fragment2/UDP-tail), and it can not procead second one because of lack of UDP header? IP reassembling happens after ipfw? From sem at FreeBSD.org Sun Mar 15 03:40:18 2009 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Sun Mar 15 03:40:24 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <20090315100206.GA63505@onelab2.iet.unipi.it> References: <200903132246.49159.dima_bsd@inbox.lv> <49BBB94A.7040208@FreeBSD.org> <200903142031.53326.dima_bsd@inbox.lv> <49BCCC9D.30109@FreeBSD.org> <20090315100206.GA63505@onelab2.iet.unipi.it> Message-ID: <49BCDB0D.6070608@FreeBSD.org> Luigi Rizzo wrote: > On Sun, Mar 15, 2009 at 12:38:37PM +0300, Sergey Matveychuk wrote: >> Dmitriy Demidov wrote: >>> Hi Luigi. Thank you for answer. >>> It is a big "surprise" for me that reassembling of IP datagrams is done >>> not *before* they go into firewall, but *after* :( >> But what's wrong with it? A fragment got from net, pass firewall and >> store. After all fragments we got, OS reassembly a packet and pass it >> through firewall again. > > Currently we don't have a way to re-invoke the firewall after > reassembly. In fact, we should probably provide hooks before and > after reassembly, and use them in a configurable way. It sounds like a security issue. We can construct any packet that pass through firewall? -- Dixi. Sem. From sem at FreeBSD.org Sun Mar 15 04:12:00 2009 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Sun Mar 15 04:12:07 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <49BCDB0D.6070608@FreeBSD.org> References: <200903132246.49159.dima_bsd@inbox.lv> <49BBB94A.7040208@FreeBSD.org> <200903142031.53326.dima_bsd@inbox.lv> <49BCCC9D.30109@FreeBSD.org> <20090315100206.GA63505@onelab2.iet.unipi.it> <49BCDB0D.6070608@FreeBSD.org> Message-ID: <49BCE276.1050509@FreeBSD.org> Sergey Matveychuk wrote: > Luigi Rizzo wrote: >> On Sun, Mar 15, 2009 at 12:38:37PM +0300, Sergey Matveychuk wrote: >>> Dmitriy Demidov wrote: >>>> Hi Luigi. Thank you for answer. >>>> It is a big "surprise" for me that reassembling of IP datagrams is >>>> done not *before* they go into firewall, but *after* :( >>> But what's wrong with it? A fragment got from net, pass firewall and >>> store. After all fragments we got, OS reassembly a packet and pass it >>> through firewall again. >> >> Currently we don't have a way to re-invoke the firewall after >> reassembly. In fact, we should probably provide hooks before and >> after reassembly, and use them in a configurable way. > > It sounds like a security issue. We can construct any packet that pass > through firewall? > Well, I see a first fragment will be checked. But anyway I think the reassembled package must pass firewall again. -- Dixi. Sem. From bugmaster at FreeBSD.org Mon Mar 16 04:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 16 04:08:22 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200903161106.n2GB6uQ1043284@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/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 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 56 problems total. From ale at FreeBSD.org Tue Mar 17 02:06:51 2009 From: ale at FreeBSD.org (Alex Dupre) Date: Tue Mar 17 02:06:57 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <20090313214327.GA1675@onelab2.iet.unipi.it> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> Message-ID: <49BF61E7.7020305@FreeBSD.org> Luigi Rizzo ha scritto: > it is not related to dynamic rules, but to the fact that > that the firewall is called before reassembling packets. > The info (port numbers especially) is not available > in the fragments so the firewall cannot do anything. > The only solution would be to call the firewall > after reassembly. I am not sure if there is any work in progress > for that. FWIW pf has "traffic normalization" feature ("scrub" keyword), that reassembles packets before inspection. Unfortunately, it works with IPv4 packets, but lacks IPv6 support. -- Alex Dupre From p.pisati at oltrelinux.com Tue Mar 17 08:12:42 2009 From: p.pisati at oltrelinux.com (Paolo Pisati) Date: Tue Mar 17 08:12:48 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <49BF61E7.7020305@FreeBSD.org> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> Message-ID: <49BFB9B2.9090909@oltrelinux.com> Alex Dupre wrote: > Luigi Rizzo ha scritto: >> it is not related to dynamic rules, but to the fact that >> that the firewall is called before reassembling packets. >> The info (port numbers especially) is not available >> in the fragments so the firewall cannot do anything. >> The only solution would be to call the firewall >> after reassembly. I am not sure if there is any work in progress >> for that. > > FWIW pf has "traffic normalization" feature ("scrub" keyword), that > reassembles packets before inspection. Unfortunately, it works with > IPv4 packets, but lacks IPv6 support. > FYI i have a patch for ipfw nat that reassemble a packet before nat[*], but if the idea of an explicit packet reassembly action sounds good, i could move the code over there. [*] actually the patch is really simple, it's just a call to ip_reass() with some glue code, but nonetheless it could be used more globally. -- bye, P. From steve at ibctech.ca Tue Mar 17 10:02:08 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Tue Mar 17 10:02:15 2009 Subject: [Fwd: uRPF] Message-ID: <49BFD13F.8000608@ibctech.ca> [ I tried this over at -net, but with no response, thought I'd try here] Hi everyone, I've implemented RTBH within our network, but I have one small issue. I've got one FreeBSD/Quagga edge router that has an interface which contains a default route out. Although this will change in the next while, at this time, it is preventing me from doing reverse path check, thereby breaking source-based black-holing. It appears to me that IPFW's verrevpath (and it's kin) do not provide the ability to perform the RPF check and allow default. Have there been any advancements in this regard? Am I missing something, or is there another approach to allowing default with reverse path? Regards, Steve _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From dima_bsd at inbox.lv Tue Mar 17 11:33:20 2009 From: dima_bsd at inbox.lv (Dmitriy Demidov) Date: Tue Mar 17 11:33:26 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <49BFB9B2.9090909@oltrelinux.com> References: <200903132246.49159.dima_bsd@inbox.lv> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> Message-ID: <200903172033.09731.dima_bsd@inbox.lv> On Tuesday 17 March 2009, Paolo Pisati wrote: > FYI i have a patch for ipfw nat that reassemble a packet before nat[*], > but if the idea of an explicit packet reassembly action sounds good, i > could move the code over there. > > [*] actually the patch is really simple, it's just a call to ip_reass() > with some glue code, but nonetheless it could be used more globally. It's sounds like the thing I'm looking for! How hard it would be to make it? If it is unacceptable to turn it on by default (for some reasons, if any) then can it be implemented as additional ipfw rule allowing to turn him on/off when needed? Something like: ipfw add 100 scrub-ip ip from any to me From rizzo at iet.unipi.it Tue Mar 17 11:56:03 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Mar 17 11:56:10 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <49BFB9B2.9090909@oltrelinux.com> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> Message-ID: <20090317190123.GB89417@onelab2.iet.unipi.it> On Tue, Mar 17, 2009 at 03:54:42PM +0100, Paolo Pisati wrote: > Alex Dupre wrote: > >Luigi Rizzo ha scritto: > >>it is not related to dynamic rules, but to the fact that > >>that the firewall is called before reassembling packets. > >>The info (port numbers especially) is not available > >>in the fragments so the firewall cannot do anything. > >>The only solution would be to call the firewall > >>after reassembly. I am not sure if there is any work in progress > >>for that. > > > >FWIW pf has "traffic normalization" feature ("scrub" keyword), that > >reassembles packets before inspection. Unfortunately, it works with > >IPv4 packets, but lacks IPv6 support. > > > FYI i have a patch for ipfw nat that reassemble a packet before nat[*], > but if the idea of an explicit packet reassembly action sounds good, i > could move the code over there. > > [*] actually the patch is really simple, it's just a call to ip_reass() > with some glue code, but nonetheless it could be used more globally. Thinking more about it, i believe that calling reass as an explicit firewall action is useless, because if ip_reass fails due to lack of all fragments you are back to square one: what do I do with this fragment ? And the answer can only be the same that you would implement without the mechanism: unconditionally accept all fragments past the first one, and do the actual filtering on the first fragment. If you drop the fragments, you would be unable to rebuild the full packet. The only thing that would actually make a difference, i believe, is the ability to call the firewall after ip_reass() instead of just before (of course you'd need some microinstruction to check who is calling you, and make different decisions in the various cases). cheers luigi From p.pisati at oltrelinux.com Tue Mar 17 15:14:10 2009 From: p.pisati at oltrelinux.com (Paolo Pisati) Date: Tue Mar 17 15:14:17 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <20090317190123.GB89417@onelab2.iet.unipi.it> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> <20090317190123.GB89417@onelab2.iet.unipi.it> Message-ID: <49C01E08.9050709@oltrelinux.com> Luigi Rizzo wrote: > > Thinking more about it, i believe that calling reass as an explicit > firewall action is useless, because if ip_reass fails due to lack of > all fragments you are back to square one: > what do I do with this fragment ? > AFAIK ip_reass() never fails: if it's the last fragment it reassembles the packet and return it, else it queues the fragment for later reassembly. and i guess we must extend ip fragment detection together with the reass action because 'frag' matches only packet with a non-zero offset (aka not the first fragment). bye, P. From rizzo at iet.unipi.it Tue Mar 17 15:29:50 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Mar 17 15:29:56 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <49C01E08.9050709@oltrelinux.com> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> <20090317190123.GB89417@onelab2.iet.unipi.it> <49C01E08.9050709@oltrelinux.com> Message-ID: <20090317223511.GB95451@onelab2.iet.unipi.it> On Tue, Mar 17, 2009 at 11:02:48PM +0100, Paolo Pisati wrote: > Luigi Rizzo wrote: > > > >Thinking more about it, i believe that calling reass as an explicit > >firewall action is useless, because if ip_reass fails due to lack of > >all fragments you are back to square one: > > what do I do with this fragment ? > > > > AFAIK ip_reass() never fails: if it's the last fragment it reassembles > the packet and return it, else it queues the fragment for later > reassembly. Ok then we may have a plan: you could do is implement REASS as an action (not as a microinstruction), with the following behaviour: - if the packet is a complete one, the rule behaves as a "count" (i.e. the firewall continues with the next rule); - if the packet is a fragment and can be reassembled, the rule behaves as a "count" and the mbuf is replaced with the full packet; - if the packet is a fragment and cannot be reassembled, the rule behaves as a "drop" (i.e. processing stops) and the packet is swallowed by ipfw. This seems a useful behaviour, but it must be documented very clearly because it is not completely intuitive. Perhaps we should find a more descriptive name. Good progress! cheers luigi From julian at elischer.org Tue Mar 17 15:39:38 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Mar 17 15:39:44 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <20090317223511.GB95451@onelab2.iet.unipi.it> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> <20090317190123.GB89417@onelab2.iet.unipi.it> <49C01E08.9050709@oltrelinux.com> <20090317223511.GB95451@onelab2.iet.unipi.it> Message-ID: <49C026B1.8010108@elischer.org> Luigi Rizzo wrote: > On Tue, Mar 17, 2009 at 11:02:48PM +0100, Paolo Pisati wrote: >> Luigi Rizzo wrote: >>> Thinking more about it, i believe that calling reass as an explicit >>> firewall action is useless, because if ip_reass fails due to lack of >>> all fragments you are back to square one: >>> what do I do with this fragment ? >>> >> AFAIK ip_reass() never fails: if it's the last fragment it reassembles >> the packet and return it, else it queues the fragment for later >> reassembly. > > Ok then we may have a plan: > > you could do is implement REASS as an action (not as a microinstruction), > with the following behaviour: > > - if the packet is a complete one, the rule behaves as a "count" > (i.e. the firewall continues with the next rule); > > - if the packet is a fragment and can be reassembled, the rule > behaves as a "count" and the mbuf is replaced with the full packet; > > - if the packet is a fragment and cannot be reassembled, the > rule behaves as a "drop" (i.e. processing stops) > and the packet is swallowed by ipfw. > > This seems a useful behaviour, but it must be documented very > clearly because it is not completely intuitive. Perhaps we should > find a more descriptive name. So what is the behaviour when you reassemble a 5K packet, and then it has to be forwarded out another interface with 1500 MTU. > > Good progress! > > cheers > luigi > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From rizzo at iet.unipi.it Tue Mar 17 16:07:01 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Mar 17 16:07:07 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <49C026B1.8010108@elischer.org> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> <20090317190123.GB89417@onelab2.iet.unipi.it> <49C01E08.9050709@oltrelinux.com> <20090317223511.GB95451@onelab2.iet.unipi.it> <49C026B1.8010108@elischer.org> Message-ID: <20090317231222.GD95451@onelab2.iet.unipi.it> On Tue, Mar 17, 2009 at 03:39:45PM -0700, Julian Elischer wrote: ... > >Ok then we may have a plan: > > > >you could do is implement REASS as an action (not as a microinstruction), > >with the following behaviour: > > > >- if the packet is a complete one, the rule behaves as a "count" > > (i.e. the firewall continues with the next rule); > > > >- if the packet is a fragment and can be reassembled, the rule > > behaves as a "count" and the mbuf is replaced with the full packet; > > > >- if the packet is a fragment and cannot be reassembled, the > > rule behaves as a "drop" (i.e. processing stops) > > and the packet is swallowed by ipfw. > > > >This seems a useful behaviour, but it must be documented very > >clearly because it is not completely intuitive. Perhaps we should > >find a more descriptive name. > > So what is the behaviour when you reassemble a 5K packet, > and then it has to be forwarded out another interface with 1500 MTU. Good point. One option would be that when REASS is called from the output path, it always act as "count" and never calls ip_reass() Would that work ? The firewall in the output path is called before fragment, locally generated packets are not fragmented, and if don't want stray fragment you should have already called "reass" in the inbound path through the firewall ? cheers luigi From qwe at qwe.net.ua Tue Mar 17 18:44:14 2009 From: qwe at qwe.net.ua (Eugene L Kovalenja) Date: Tue Mar 17 18:44:21 2009 Subject: FreeBSD 7.0: dummynet 99% cpu Message-ID: <49C04CA3.1070100@qwe.net.ua> Hello. My OS: FreeBSD *** 7.0-RELEASE FreeBSD 7.0-RELEASE #6: Sun Nov 23 14:32:31 EET 2008 root@***:/usr/src/sys/i386/compile/QWEKRN70 i386 Machine: HP Proliant DL560 (Xeon 2.5GHzX8, 4Gb RAM) /etc/sysctl.conf kern.polling.enable=0 net.inet.tcp.sendspace=1048576 net.inet.tcp.recvspace=1048576 net.inet.icmp.icmplim=100 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.tcp.msl=15000 net.inet.ip.fastforwarding=1 net.inet.ip.maxfragsperpacket=45 net.inet.tcp.log_in_vain=0 kern.ipc.maxsockets=204800 kern.ipc.maxsockbuf=16777216 kern.polling.each_burst=150 kern.polling.burst_max=1000 net.inet.tcp.syncookies=1 kern.ipc.nmbclusters=262144 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 security.bsd.see_other_uids=0 security.bsd.see_other_gids=0 security.bsd.unprivileged_read_msgbuf=0 net.inet.ip.random_id=1 kern.logsigexit=0 kern.ipc.somaxconn=24096 net.inet.ip.intr_queue_maxlen=1024 net.inet.tcp.mssdflt=1460 net.inet.tcp.slowstart_flightsize=54 net.inet.ip.fw.one_pass=0 net.inet.icmp.drop_redirect=1 net.inet.icmp.log_redirect=1 kern.maxfilesperproc=104856 kern.maxfiles=65535 net.inet.tcp.rfc1323=1 net.inet.ip.dummynet.hash_size=512 net.graph.maxdgram=128000 net.graph.recvspace=128000 net.inet.ip.intr_queue_maxlen=10240 I'm use this machine as VPN-server for access my clients into Internet. VPN-server: mpd4.3 Shaper: dummynet (pipes) Example of shaper rules: 01111 0 0 pipe 1231 ip from table(123) to any via ng* 01111 0 0 pipe 1232 ip from any to table(123) via ng* Pipes: ipfw pipe 1231 config bw XXXXKbit/s mask src-ip 0xffffffff ipfw pipe 1232 config bw XXXXKbit/s mask dst-ip 0xffffffff Time in three days traffic via ipfw doesn't go. In top: 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% dummynet (this is example, not copy\paste) Also sw1: net increases from 5-10% to 30-35%... I am helped only by reboot. In what can consist the problem? Thanks. From olli at lurza.secnetix.de Wed Mar 18 03:23:20 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Mar 18 03:23:26 2009 Subject: FreeBSD 7.0: dummynet 99% cpu In-Reply-To: <49C04CA3.1070100@qwe.net.ua> Message-ID: <200903181022.n2IAMsWs038026@lurza.secnetix.de> Eugene L Kovalenja wrote: > FreeBSD *** 7.0-RELEASE FreeBSD 7.0-RELEASE #6: Sun Nov 23 14:32:31 EET > [...] > Time in three days traffic via ipfw doesn't go. In top: > 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% dummynet > (this is example, not copy\paste) There are a few problems that have been fixed (or worked around) after the release of 7.0. For example, look at PR kern/113548 which has a work-around in 7.1. Your problem description sounds like it could be caused by the same problem. Therefore I recommend you update to 7.1 or 7-stable. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn From olli at lurza.secnetix.de Wed Mar 18 03:34:10 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Mar 18 03:34:16 2009 Subject: keep-state rules inadequately handles big UDP ?packets?or?fragmented IP packets? In-Reply-To: <20090317231222.GD95451@onelab2.iet.unipi.it> Message-ID: <200903181033.n2IAXieV038438@lurza.secnetix.de> I'm just curious ... Is it really worth the effort to add fragment reassembly to IPFW? What advantage does it have? It would be much easier to simply pass all fragments with offset > 1, and drop all fragments with offset 0 that are smaller than a certain reasonable minimum length. What would be the problem with this approach? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper." -- Ralf Hildebrandt From julian at elischer.org Wed Mar 18 08:52:42 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Mar 18 08:52:50 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <20090317231222.GD95451@onelab2.iet.unipi.it> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> <20090317190123.GB89417@onelab2.iet.unipi.it> <49C01E08.9050709@oltrelinux.com> <20090317223511.GB95451@onelab2.iet.unipi.it> <49C026B1.8010108@elischer.org> <20090317231222.GD95451@onelab2.iet.unipi.it> Message-ID: <49C118B2.5050002@elischer.org> Luigi Rizzo wrote: > On Tue, Mar 17, 2009 at 03:39:45PM -0700, Julian Elischer wrote: > ... >>> Ok then we may have a plan: >>> >>> you could do is implement REASS as an action (not as a microinstruction), >>> with the following behaviour: >>> >>> - if the packet is a complete one, the rule behaves as a "count" >>> (i.e. the firewall continues with the next rule); >>> >>> - if the packet is a fragment and can be reassembled, the rule >>> behaves as a "count" and the mbuf is replaced with the full packet; >>> >>> - if the packet is a fragment and cannot be reassembled, the >>> rule behaves as a "drop" (i.e. processing stops) >>> and the packet is swallowed by ipfw. >>> >>> This seems a useful behaviour, but it must be documented very >>> clearly because it is not completely intuitive. Perhaps we should >>> find a more descriptive name. >> So what is the behaviour when you reassemble a 5K packet, >> and then it has to be forwarded out another interface with 1500 MTU. > > Good point. One option would be that when REASS is called from the > output path, it always act as "count" and never calls ip_reass() > > Would that work ? The firewall in the output path is called before > fragment, locally generated packets are not fragmented, and if > don't want stray fragment you should have already called "reass" > in the inbound path through the firewall ? yeah but what if you reassemble on input, and then the packet is routed? > > cheers > luigi From rizzo at iet.unipi.it Wed Mar 18 09:10:41 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Wed Mar 18 09:10:48 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <49C118B2.5050002@elischer.org> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> <20090317190123.GB89417@onelab2.iet.unipi.it> <49C01E08.9050709@oltrelinux.com> <20090317223511.GB95451@onelab2.iet.unipi.it> <49C026B1.8010108@elischer.org> <20090317231222.GD95451@onelab2.iet.unipi.it> <49C118B2.5050002@elischer.org> Message-ID: <20090318161524.GA11771@onelab2.iet.unipi.it> On Wed, Mar 18, 2009 at 08:52:18AM -0700, Julian Elischer wrote: > Luigi Rizzo wrote: > >On Tue, Mar 17, 2009 at 03:39:45PM -0700, Julian Elischer wrote: > >... > >>>Ok then we may have a plan: > >>> > >>>you could do is implement REASS as an action (not as a microinstruction), > >>>with the following behaviour: > >>> > >>>- if the packet is a complete one, the rule behaves as a "count" > >>> (i.e. the firewall continues with the next rule); > >>> > >>>- if the packet is a fragment and can be reassembled, the rule > >>> behaves as a "count" and the mbuf is replaced with the full packet; > >>> > >>>- if the packet is a fragment and cannot be reassembled, the > >>> rule behaves as a "drop" (i.e. processing stops) > >>> and the packet is swallowed by ipfw. > >>> > >>>This seems a useful behaviour, but it must be documented very > >>>clearly because it is not completely intuitive. Perhaps we should > >>>find a more descriptive name. > >>So what is the behaviour when you reassemble a 5K packet, > >>and then it has to be forwarded out another interface with 1500 MTU. > > > >Good point. One option would be that when REASS is called from the > >output path, it always act as "count" and never calls ip_reass() > > > >Would that work ? The firewall in the output path is called before > >fragment, locally generated packets are not fragmented, and if > >don't want stray fragment you should have already called "reass" > >in the inbound path through the firewall ? > > yeah but what if you reassemble on input, and then the packet is routed? it should work -- ip_output() gets the full packet, the firewall is called on line 441 before ip_fragment() which is on line 568. cheers luigi From linzhao at ustc.edu.cn Wed Mar 18 19:51:58 2009 From: linzhao at ustc.edu.cn (Lin Zhao) Date: Wed Mar 18 19:52:06 2009 Subject: pls help on 3 interfaces Message-ID: <437430175.25503@ustc.edu.cn> hi all, wish my english is enough :-) my freebsd has 3 interfaces, like this, ---- ----switch1 | ---------- fxp0 | | | |--------- internal |--------|freebsd71 | | rl0 | |--------- | ---------- fxp1 | ---- ----switch2 we're in the internal and want to visit outside we use fxp0 for default outside address and it works well but for some reason, i want to use fxp1 for some special outside address how can i do for it? thanks a lot. Lin Zhao SCGY,USTC,PRC From julian at elischer.org Wed Mar 18 20:49:41 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Mar 18 20:49:47 2009 Subject: pls help on 3 interfaces In-Reply-To: <437430175.25503@ustc.edu.cn> References: <437430175.25503@ustc.edu.cn> Message-ID: <49C1C0D8.2060206@elischer.org> Lin Zhao wrote: > hi all, wish my english is enough :-) > my freebsd has 3 interfaces, like this, > > ---- ----switch1 > | ---------- fxp0 | > | | |--------- > internal |--------|freebsd71 | > | rl0 | |--------- > | ---------- fxp1 | > ---- ----switch2 first set your routingtable so that teh 'special' addresses go via switch2, then set up NAT as follows: like this: ---- ----switch1 | ---------- fxp0 | | | NAT1(*)|--------- internal |--------|freebsd71 | | rl0 | NAT2|--------- | ---------- fxp1 | ---- ----switch2 (*) If you want, NAT1 may be left out if you use routable addresses on your internal network. The reason for the NAT is to make sure that outgoing packets have a source address that will make the return packets come back through switch2, otherwise, even if you have a route making the outgoing packets go via switch2, the return packets will still comeback via switch1. > > we're in the internal and want to visit outside > we use fxp0 for default outside address and it works well > but for some reason, i want to use fxp1 for some special outside address > how can i do for it? > thanks a lot. > > > Lin Zhao > SCGY,USTC,PRC > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From lists at jnielsen.net Wed Mar 18 20:49:57 2009 From: lists at jnielsen.net (John Nielsen) Date: Wed Mar 18 20:50:03 2009 Subject: pls help on 3 interfaces In-Reply-To: <437430175.25503@ustc.edu.cn> References: <437430175.25503@ustc.edu.cn> Message-ID: <200903182323.56585.lists@jnielsen.net> On Wednesday 18 March 2009 10:36:15 pm Lin Zhao wrote: > hi all, wish my english is enough :-) > my freebsd has 3 interfaces, like this, > > ---- ----switch1 > > | ---------- fxp0 | > | > | | |--------- > > internal |--------|freebsd71 | > > | rl0 | |--------- > | ---------- fxp1 | > > ---- ----switch2 > > we're in the internal and want to visit outside > we use fxp0 for default outside address and it works well > but for some reason, i want to use fxp1 for some special outside > address how can i do for it? > thanks a lot. Is the FreeBSD box performing network address translation (NAT)? I'm going to assume that it is and everything is being aliased through fxp0. I'm also assuming you're using ipfw since you wrote to the ipfw list. If the IP addresses which you'd like to reach via fxp1 are static, you should be able to do something like the following: Configure static routes on the FreeBSD machine for the the special outside addresses using the gateway of fxp1's network as the router. Configure an additional NAT rule (if still using natd now might be a good time to switch to in-kernel ipfw NAT..) to alias through fxp1. Configure ipfw to direct traffic to/from the special outside addresses to the new NAT instance instead of the default. I actually used a similar setup recently. If you care to confirm my assumptions above I can give you a more step-by-step guide. JN From linzhao at ustc.edu.cn Thu Mar 19 00:13:53 2009 From: linzhao at ustc.edu.cn (Lin Zhao) Date: Thu Mar 19 00:14:01 2009 Subject: pls help on 3 interfaces Message-ID: <437446889.08051@ustc.edu.cn> too much thx for Julian Elischer & John Nielsen..... i've tried it, and it seems working now, but i don't know if i'm right in setting natd2.... i just add one line in /etc/services as "natd2 8669" and run a command: natd -n fxp1 -p 8669 seems so stupid Lin 在您的来信中曾经提到: >From: John Nielsen >Reply-To: >To: freebsd-ipfw@freebsd.org, Lin Zhao >Subject: Re: pls help on 3 interfaces >Date:Wed, 18 Mar 2009 23:23:56 -0400 > >On Wednesday 18 March 2009 10:36:15 pm Lin Zhao wrote: > > hi all, wish my english is enough :-) > > my freebsd has 3 interfaces, like this, > > > > ---- ----switch1 > > > > | ---------- fxp0 | > > | > > | | |--------- > > > > internal |--------|freebsd71 | > > > > | rl0 | |--------- > > | ---------- fxp1 | > > > > ---- ----switch2 > > > > we're in the internal and want to visit outside > > we use fxp0 for default outside address and it works well > > but for some reason, i want to use fxp1 for some special outside > > address how can i do for it? > > thanks a lot. > > Is the FreeBSD box performing network address translation (NAT)? I'm going > to assume that it is and everything is being aliased through fxp0. I'm > also assuming you're using ipfw since you wrote to the ipfw list. > > If the IP addresses which you'd like to reach via fxp1 are static, you > should be able to do something like the following: > > Configure static routes on the FreeBSD machine for the the special outside > addresses using the gateway of fxp1's network as the router. > Configure an additional NAT rule (if still using natd now might be a good > time to switch to in-kernel ipfw NAT..) to alias through fxp1. > Configure ipfw to direct traffic to/from the special outside addresses to > the new NAT instance instead of the default. > > I actually used a similar setup recently. If you care to confirm my > assumptions above I can give you a more step-by-step guide. > > JN > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From julian at elischer.org Thu Mar 19 00:34:59 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Mar 19 00:35:06 2009 Subject: pls help on 3 interfaces In-Reply-To: <437446889.08051@ustc.edu.cn> References: <437446889.08051@ustc.edu.cn> Message-ID: <49C1F593.2050009@elischer.org> Lin Zhao wrote: > too much thx for Julian Elischer & John Nielsen..... > i've tried it, and it seems working now, > but i don't know if i'm right in setting natd2.... > i just add one line in /etc/services as "natd2 8669" > and run a command: natd -n fxp1 -p 8669 > seems so stupid. I assume you mean "simple" instead of stupid... :-) I don't think you need natd2 in /etc/services... but as long as the ipfw and natd agree in the port number it should work. You didn't say if you have nat already. but if you do then I believe natd can do more than one nat with a single instance now. (phk added that some time ago) but I have never done it, so I can not tell you how... read the man page... also the in-kernel nat available in ipfw can do this and you can also do multiple NATS with that too but once again, I haven't done it myself. > > Lin > > ????????????????????: >> From: John Nielsen >> Reply-To: >> To: freebsd-ipfw@freebsd.org, Lin Zhao >> Subject: Re: pls help on 3 interfaces >> Date:Wed, 18 Mar 2009 23:23:56 -0400 >> >> On Wednesday 18 March 2009 10:36:15 pm Lin Zhao wrote: >>> hi all, wish my english is enough :-) >>> my freebsd has 3 interfaces, like this, >>> >>> ---- ----switch1 >>> >>> | ---------- fxp0 | >>> | >>> | | |--------- >>> >>> internal |--------|freebsd71 | >>> >>> | rl0 | |--------- >>> | ---------- fxp1 | >>> >>> ---- ----switch2 >>> >>> we're in the internal and want to visit outside >>> we use fxp0 for default outside address and it works well >>> but for some reason, i want to use fxp1 for some special outside >>> address how can i do for it? >>> thanks a lot. >> Is the FreeBSD box performing network address translation (NAT)? I'm going >> to assume that it is and everything is being aliased through fxp0. I'm >> also assuming you're using ipfw since you wrote to the ipfw list. >> >> If the IP addresses which you'd like to reach via fxp1 are static, you >> should be able to do something like the following: >> >> Configure static routes on the FreeBSD machine for the the special outside >> addresses using the gateway of fxp1's network as the router. >> Configure an additional NAT rule (if still using natd now might be a good >> time to switch to in-kernel ipfw NAT..) to alias through fxp1. >> Configure ipfw to direct traffic to/from the special outside addresses to >> the new NAT instance instead of the default. >> >> I actually used a similar setup recently. If you care to confirm my >> assumptions above I can give you a more step-by-step guide. >> >> JN >> >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From dima_bsd at inbox.lv Thu Mar 19 12:29:07 2009 From: dima_bsd at inbox.lv (Dmitriy Demidov) Date: Thu Mar 19 12:29:14 2009 Subject: keep-state rules inadequately handles big UDP ?packets?or?fragmented IP packets? In-Reply-To: <200903181033.n2IAXieV038438@lurza.secnetix.de> References: <200903181033.n2IAXieV038438@lurza.secnetix.de> Message-ID: <200903192129.03360.dima_bsd@inbox.lv> On Wednesday 18 March 2009, Oliver Fromme wrote: > I'm just curious ... Is it really worth the effort to add > fragment reassembly to IPFW? What advantage does it have? > > It would be much easier to simply pass all fragments with > offset > 1, and drop all fragments with offset 0 that are > smaller than a certain reasonable minimum length. What > would be the problem with this approach? > > Best regards > Oliver Please wait... If I got it right (and dont missing something) then this rule: ipfw add allow ip from any to me frag have dissadvantage - I'm unabled to filter data by UDP/TCP ports. All IP packets is just passing through firewall to me. No UDP/TCP filtering here? From qwe at qwe.net.ua Thu Mar 19 20:42:44 2009 From: qwe at qwe.net.ua (Eugene L Kovalenja) Date: Thu Mar 19 20:42:52 2009 Subject: FreeBSD 7.0: dummynet 99% cpu In-Reply-To: <200903181022.n2IAMsWs038026@lurza.secnetix.de> References: <200903181022.n2IAMsWs038026@lurza.secnetix.de> Message-ID: <49C310A9.6020102@qwe.net.ua> Oliver Fromme ?????: > Eugene L Kovalenja wrote: > > FreeBSD *** 7.0-RELEASE FreeBSD 7.0-RELEASE #6: Sun Nov 23 14:32:31 EET > > [...] > > Time in three days traffic via ipfw doesn't go. In top: > > 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% dummynet > > (this is example, not copy\paste) > > There are a few problems that have been fixed (or worked > around) after the release of 7.0. For example, look at > PR kern/113548 which has a work-around in 7.1. Your > problem description sounds like it could be caused by > the same problem. > > Therefore I recommend you update to 7.1 or 7-stable. > > Best regards > Oliver > > Hello. System updated to: [root@taurus /usr/home/qwe]# uname -a FreeBSD *** 7.1-RELEASE-p3 FreeBSD 7.1-RELEASE-p3 #0: Thu Mar 19 16:31:53 EET 2009 root@***:/usr/obj/usr/src/sys/QWEKRN70 i386 but once trouble has repeated (30 mins ago). After that I change my sysctl variables: net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.debug=1 net.inet.ip.dummynet.hash_size=16384 (from 512) What can I'll to do? Sorry for my bad English :( From sem at FreeBSD.org Fri Mar 20 02:15:48 2009 From: sem at FreeBSD.org (Sergey Matveyhcuk) Date: Fri Mar 20 02:15:54 2009 Subject: FreeBSD 7.0: dummynet 99% cpu In-Reply-To: <49C04CA3.1070100@qwe.net.ua> References: <49C04CA3.1070100@qwe.net.ua> Message-ID: <49C35EB3.6040508@FreeBSD.org> Could you test an included patch? Eugene L Kovalenja wrote: > > Time in three days traffic via ipfw doesn't go. In top: > 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% dummynet > (this is example, not copy\paste) > > Also sw1: net increases from 5-10% to 30-35%... > > I am helped only by reboot. > > In what can consist the problem? > -------------- next part -------------- --- sys/netinet/ip_dummynet.c.orig 2009-03-20 12:08:47.000000000 +0300 +++ sys/netinet/ip_dummynet.c 2009-03-20 12:09:31.000000000 +0300 @@ -145,8 +145,8 @@ static void ready_event_wfq(struct dn_pipe *p, struct mbuf **head, struct mbuf **tail); -#define HASHSIZE 16 -#define HASH(num) ((((num) >> 8) ^ ((num) >> 4) ^ (num)) & 0x0f) +#define HASHSIZE 255 +#define HASH(num) ((((num) >> 8) ^ ((num) >> 4) ^ (num)) & 0xff) static struct dn_pipe_head pipehash[HASHSIZE]; /* all pipes */ static struct dn_flow_set_head flowsethash[HASHSIZE]; /* all flowsets */ From sebastian.mellmann at net.t-labs.tu-berlin.de Fri Mar 20 08:53:27 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Fri Mar 20 08:53:34 2009 Subject: ipfw dummynet - delay distributions when using config masks Message-ID: <49C3BBF6.7040104@net.t-labs.tu-berlin.de> Hi! I'm using pipe masks for defining multiple queues per traffic flow, e.g. $cmd pipe 100 config mask all bw $webclient_upload_bandwidth queue $queue_size delay $client_rtt_delay $cmd pipe 200 config mask all bw $webclient_download_bandwidth queue $queue_size delay $client_rtt_delay $cmd add pipe 100 all from $client1_subnet to $server1_subnet in recv $in_if $cmd add pipe 200 all from $server1_subnet to $client1_subnet out xmit $in_if As you can see in the example above I'm defining a fixed delay value for all queues. Is it possible to define a delay distribution, e.g. min. 20ms, mean 50ms and max. 80ms for the pipe? I had a look at the ipfw howto (http://www.freebsd-howto.com/HOWTO/Ipfw-HOWTO), but couldn't find anything there nor via google. Thanks in advance for any help! Regards, Sebastian From rizzo at iet.unipi.it Fri Mar 20 08:57:07 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Fri Mar 20 08:57:13 2009 Subject: ipfw dummynet - delay distributions when using config masks In-Reply-To: <49C3BBF6.7040104@net.t-labs.tu-berlin.de> References: <49C3BBF6.7040104@net.t-labs.tu-berlin.de> Message-ID: <20090320160154.GA92207@onelab2.iet.unipi.it> On Fri, Mar 20, 2009 at 04:53:26PM +0100, Sebastian Mellmann wrote: > Hi! > > > I'm using pipe masks for defining multiple queues per traffic flow, e.g. > > $cmd pipe 100 config mask all bw $webclient_upload_bandwidth queue $queue_size delay $client_rtt_delay > $cmd pipe 200 config mask all bw $webclient_download_bandwidth queue $queue_size delay $client_rtt_delay > > $cmd add pipe 100 all from $client1_subnet to $server1_subnet in recv $in_if > $cmd add pipe 200 all from $server1_subnet to $client1_subnet out xmit $in_if > > > As you can see in the example above I'm defining a fixed delay value for > all queues. > Is it possible to define a delay distribution, e.g. min. 20ms, mean 50ms > and max. 80ms for the pipe? we do have something that does the thing you are asking for, and should be committed soon to head (and easily backported to RELENG_7). Please be patient a couple of week, the code is already working and we only need to address some binary compatibility issue. cheers luigi From olli at lurza.secnetix.de Fri Mar 20 16:47:23 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Mar 20 16:47:30 2009 Subject: keep-state rules inadequately handles big UDP ??packets?or?fragmented IP packets? In-Reply-To: <200903192129.03360.dima_bsd@inbox.lv> Message-ID: <200903202346.n2KNkvQu011749@lurza.secnetix.de> Dmitriy Demidov wrote: > Oliver Fromme wrote: > > I'm just curious ... Is it really worth the effort to add > > fragment reassembly to IPFW? What advantage does it have? > > > > It would be much easier to simply pass all fragments with > > offset > 1, and drop all fragments with offset 0 that are > > smaller than a certain reasonable minimum length. What > > would be the problem with this approach? > > Please wait... If I got it right (and dont missing something) then this rule: > ipfw add allow ip from any to me frag > have dissadvantage - I'm unabled to filter data by UDP/TCP ports. All IP > packets is just passing through firewall to me. No UDP/TCP filtering here? >From the ipfw(8) manual page: frag Matches packets that are fragments and not the first fragment of an IP datagram. That rule does _not_ pass the first fragment of a fragmented packet. So you can still filter by TCP and UDP ports. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "We will perhaps eventually be writing only small modules which are identi- fied by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language." -- Donald E. Knuth, 1974 From qwe at qwe.net.ua Sat Mar 21 07:04:32 2009 From: qwe at qwe.net.ua (Eugene L Kovalenja) Date: Sat Mar 21 07:04:39 2009 Subject: FreeBSD 7.0: dummynet 99% cpu In-Reply-To: <49C35EB3.6040508@FreeBSD.org> References: <49C04CA3.1070100@qwe.net.ua> <49C35EB3.6040508@FreeBSD.org> Message-ID: <49C4F3EE.2080903@qwe.net.ua> Sergey Matveyhcuk ?????: > Could you test an included patch? > > Eugene L Kovalenja wrote: >> >> Time in three days traffic via ipfw doesn't go. In top: >> 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% >> dummynet >> (this is example, not copy\paste) >> >> Also sw1: net increases from 5-10% to 30-35%... >> >> I am helped only by reboot. >> >> In what can consist the problem? >> > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" Hello. Thank you for this patch. After kernel patching trouble changes: Mar 21 13:58:45 taurus kernel: bge0: watchdog timeout -- resetting Mar 21 13:58:45 taurus kernel: bge0: link state changed to DOWN In top utility 99% cpu on irq bge0. Changing of network adapter (on board 2 adapters: bge0 && bge1) didn't decide problem. my /boot/loader.conf [root@taurus /usr/home/login]# cat /boot/loader.conf kern.ipc.maxpipekva=67108864 net.graph.maxalloc=2048 #vm.kmem_size_max="512M" #vm.kmem_size="512M" kern.maxusers="512" :( From sem at FreeBSD.org Sat Mar 21 10:14:44 2009 From: sem at FreeBSD.org (Sergey Matveyhcuk) Date: Sat Mar 21 10:14:52 2009 Subject: FreeBSD 7.0: dummynet 99% cpu In-Reply-To: <49C4F3EE.2080903@qwe.net.ua> References: <49C04CA3.1070100@qwe.net.ua> <49C35EB3.6040508@FreeBSD.org> <49C4F3EE.2080903@qwe.net.ua> Message-ID: <49C52060.6060504@FreeBSD.org> Well, I did not test the patch. Quick idea was to decrease hash buckets increasing of hash size. I did not dig deeper dummynet. Eugene L Kovalenja wrote: > Sergey Matveyhcuk ?????: >> Could you test an included patch? >> >> Eugene L Kovalenja wrote: >>> >>> Time in three days traffic via ipfw doesn't go. In top: >>> 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% >>> dummynet >>> (this is example, not copy\paste) >>> >>> Also sw1: net increases from 5-10% to 30-35%... >>> >>> I am helped only by reboot. >>> >>> In what can consist the problem? >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > Hello. > > Thank you for this patch. > > After kernel patching trouble changes: > Mar 21 13:58:45 taurus kernel: bge0: watchdog timeout -- resetting > Mar 21 13:58:45 taurus kernel: bge0: link state changed to DOWN > > In top utility 99% cpu on irq bge0. > > Changing of network adapter (on board 2 adapters: bge0 && bge1) didn't > decide problem. > > my /boot/loader.conf > [root@taurus /usr/home/login]# cat /boot/loader.conf > kern.ipc.maxpipekva=67108864 > net.graph.maxalloc=2048 > > #vm.kmem_size_max="512M" > #vm.kmem_size="512M" > kern.maxusers="512" > > :( From bugmaster at FreeBSD.org Mon Mar 23 04:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 23 04:08:23 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200903231106.n2NB6vlU004036@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/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 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 56 problems total. From oleg at FreeBSD.org Wed Mar 25 01:29:27 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Wed Mar 25 01:29:33 2009 Subject: FreeBSD 7.0: dummynet 99% cpu In-Reply-To: <49C310A9.6020102@qwe.net.ua> References: <200903181022.n2IAMsWs038026@lurza.secnetix.de> <49C310A9.6020102@qwe.net.ua> Message-ID: <20090325082925.GA13280@lath.rinet.ru> On Fri, Mar 20, 2009 at 05:42:33AM +0200, Eugene L Kovalenja wrote: > Oliver Fromme ?????: > > Eugene L Kovalenja wrote: > > > FreeBSD *** 7.0-RELEASE FreeBSD 7.0-RELEASE #6: Sun Nov 23 14:32:31 EET > > > [...] > > > Time in three days traffic via ipfw doesn't go. In top: > > > 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% dummynet > > > (this is example, not copy\paste) > > > > There are a few problems that have been fixed (or worked > > around) after the release of 7.0. For example, look at > > PR kern/113548 which has a work-around in 7.1. Your > > problem description sounds like it could be caused by > > the same problem. > > > > Therefore I recommend you update to 7.1 or 7-stable. > > > > Best regards > > Oliver > > > > > Hello. > > System updated to: > [root@taurus /usr/home/qwe]# uname -a > FreeBSD *** 7.1-RELEASE-p3 FreeBSD 7.1-RELEASE-p3 #0: Thu Mar 19 > 16:31:53 EET 2009 root@***:/usr/obj/usr/src/sys/QWEKRN70 i386 > > but once trouble has repeated (30 mins ago). > > > After that I change my sysctl variables: > net.inet.ip.dummynet.io_fast=1 > net.inet.ip.dummynet.debug=1 > net.inet.ip.dummynet.hash_size=16384 (from 512) > > What can I'll to do? > > Sorry for my bad English :( > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" Please do the following (when dummynet will hang next time): 1) Grab the output of follwing commands: sysctl net.inet.ip.dummynet ipfw pipe show 2) wait a bit (30 seconds should be enough) 3) do 1) once again. Examining counters may help in understanding problem. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From qwe at qwe.net.ua Wed Mar 25 04:12:30 2009 From: qwe at qwe.net.ua (Eugene L Kovalenja) Date: Wed Mar 25 04:12:38 2009 Subject: FreeBSD 7.0: dummynet 99% cpu In-Reply-To: <20090325082925.GA13280@lath.rinet.ru> References: <200903181022.n2IAMsWs038026@lurza.secnetix.de> <49C310A9.6020102@qwe.net.ua> <20090325082925.GA13280@lath.rinet.ru> Message-ID: <49CA119D.7090304@qwe.net.ua> Oleg Bulyzhin ?????: > On Fri, Mar 20, 2009 at 05:42:33AM +0200, Eugene L Kovalenja wrote: > >> Oliver Fromme ?????: >> >>> Eugene L Kovalenja wrote: >>> > FreeBSD *** 7.0-RELEASE FreeBSD 7.0-RELEASE #6: Sun Nov 23 14:32:31 EET >>> > [...] >>> > Time in three days traffic via ipfw doesn't go. In top: >>> > 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% dummynet >>> > (this is example, not copy\paste) >>> >>> There are a few problems that have been fixed (or worked >>> around) after the release of 7.0. For example, look at >>> PR kern/113548 which has a work-around in 7.1. Your >>> problem description sounds like it could be caused by >>> the same problem. >>> >>> Therefore I recommend you update to 7.1 or 7-stable. >>> >>> Best regards >>> Oliver >>> >>> >>> >> Hello. >> >> System updated to: >> [root@taurus /usr/home/qwe]# uname -a >> FreeBSD *** 7.1-RELEASE-p3 FreeBSD 7.1-RELEASE-p3 #0: Thu Mar 19 >> 16:31:53 EET 2009 root@***:/usr/obj/usr/src/sys/QWEKRN70 i386 >> >> but once trouble has repeated (30 mins ago). >> >> >> After that I change my sysctl variables: >> net.inet.ip.dummynet.io_fast=1 >> net.inet.ip.dummynet.debug=1 >> net.inet.ip.dummynet.hash_size=16384 (from 512) >> >> What can I'll to do? >> >> Sorry for my bad English :( >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> > > Please do the following (when dummynet will hang next time): > 1) Grab the output of follwing commands: > sysctl net.inet.ip.dummynet > ipfw pipe show > 2) wait a bit (30 seconds should be enough) > 3) do 1) once again. > > Examining counters may help in understanding problem. > > before: sysctl net.inet.ip.dummynet net.inet.ip.dummynet.debug: 0 net.inet.ip.dummynet.pipe_byte_limit: 1048576 net.inet.ip.dummynet.pipe_slot_limit: 100 net.inet.ip.dummynet.io_pkt_drop: 14138 net.inet.ip.dummynet.io_pkt_fast: 610276 net.inet.ip.dummynet.io_pkt: 1789875 net.inet.ip.dummynet.io_fast: 1 net.inet.ip.dummynet.tick_lost: 0 net.inet.ip.dummynet.tick_diff: -891 net.inet.ip.dummynet.tick_adjustment: 9797 net.inet.ip.dummynet.tick_delta_sum: 449 net.inet.ip.dummynet.tick_delta: 0 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: 1798977 net.inet.ip.dummynet.searches: 1788798 net.inet.ip.dummynet.extract_heap: 0 net.inet.ip.dummynet.ready_heap: 48 net.inet.ip.dummynet.curr_time: 138355446 net.inet.ip.dummynet.hash_size: 512 ipfw pipe show | grep -v ip 01241: 2.048 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail 01122: 4.096 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail 00801: 9.000 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 01242: 2.048 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail 01212: 256.000 Kbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 01121: 4.096 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail 01091: 512.000 Kbit/s 0 ms 50 sl. 46 queues (512 buckets) droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 00802: 9.000 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 01211: 256.000 Kbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 01092: 512.000 Kbit/s 0 ms 50 sl. 45 queues (512 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 00701: 9.000 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail 00821: 9.000 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 00791: 9.000 Mbit/s 0 ms 50 sl. 5 queues (512 buckets) droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 01111: 2.048 Mbit/s 0 ms 50 sl. 5 queues (512 buckets) droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 00822: 9.000 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 01231: 1.024 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 01072: 1.024 Mbit/s 0 ms 50 sl. 3 queues (512 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 00702: 9.000 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail 01251: 1.024 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail 01232: 1.024 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 01112: 2.048 Mbit/s 0 ms 50 sl. 5 queues (512 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 01071: 1.024 Mbit/s 0 ms 50 sl. 3 queues (512 buckets) droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 00811: 9.000 Mbit/s 0 ms 50 sl. 2 queues (512 buckets) droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 00792: 9.000 Mbit/s 0 ms 50 sl. 5 queues (512 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 01221: 512.000 Kbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 01202: 128.000 Kbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail 01101: 1.024 Mbit/s 0 ms 50 sl. 18 queues (512 buckets) droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 01082: 256.000 Kbit/s 0 ms 50 sl. 18 queues (512 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 00812: 9.000 Mbit/s 0 ms 50 sl. 2 queues (512 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 00722: 9.000 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail 01252: 1.024 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail 01222: 512.000 Kbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 01201: 128.000 Kbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail 01102: 1.024 Mbit/s 0 ms 50 sl. 16 queues (512 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 01081: 256.000 Kbit/s 0 ms 50 sl. 19 queues (512 buckets) droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 00721: 9.000 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail after: sysctl net.inet.ip.dummynet net.inet.ip.dummynet.debug: 0 net.inet.ip.dummynet.pipe_byte_limit: 1048576 net.inet.ip.dummynet.pipe_slot_limit: 100 net.inet.ip.dummynet.io_pkt_drop: 15177 net.inet.ip.dummynet.io_pkt_fast: 634143 net.inet.ip.dummynet.io_pkt: 1873018 net.inet.ip.dummynet.io_fast: 1 net.inet.ip.dummynet.tick_lost: 0 net.inet.ip.dummynet.tick_diff: -884 net.inet.ip.dummynet.tick_adjustment: 9803 net.inet.ip.dummynet.tick_delta_sum: 320 net.inet.ip.dummynet.tick_delta: -1 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: 1882134 net.inet.ip.dummynet.searches: 1871939 net.inet.ip.dummynet.extract_heap: 0 net.inet.ip.dummynet.ready_heap: 48 net.inet.ip.dummynet.curr_time: 138373128 net.inet.ip.dummynet.hash_size: 512 dummynet cpu load now - 56% From brucec at FreeBSD.org Wed Mar 25 10:19:13 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Wed Mar 25 10:19:18 2009 Subject: bin/117214: ipfw(8) fwd with IPv6 treats input as IPv4 Message-ID: <200903251719.n2PHJBZe004547@freefall.freebsd.org> Synopsis: ipfw(8) fwd with IPv6 treats input as IPv4 Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: brucec Responsible-Changed-When: Wed Mar 25 17:18:47 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=117214 From oleg at FreeBSD.org Thu Mar 26 03:08:29 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Thu Mar 26 03:08:35 2009 Subject: FreeBSD 7.0: dummynet 99% cpu In-Reply-To: <49CA119D.7090304@qwe.net.ua> References: <200903181022.n2IAMsWs038026@lurza.secnetix.de> <49C310A9.6020102@qwe.net.ua> <20090325082925.GA13280@lath.rinet.ru> <49CA119D.7090304@qwe.net.ua> Message-ID: <20090326100826.GA44053@lath.rinet.ru> On Wed, Mar 25, 2009 at 01:12:29PM +0200, Eugene L Kovalenja wrote: > Oleg Bulyzhin ?????: > > On Fri, Mar 20, 2009 at 05:42:33AM +0200, Eugene L Kovalenja wrote: > > > >> Oliver Fromme ?????: > >> > >>> Eugene L Kovalenja wrote: > >>> > FreeBSD *** 7.0-RELEASE FreeBSD 7.0-RELEASE #6: Sun Nov 23 14:32:31 EET > >>> > [...] > >>> > Time in three days traffic via ipfw doesn't go. In top: > >>> > 21 root 1 -44 - 0K 8K WAIT 7 2:15 99.02% dummynet > >>> > (this is example, not copy\paste) > >>> > >>> There are a few problems that have been fixed (or worked > >>> around) after the release of 7.0. For example, look at > >>> PR kern/113548 which has a work-around in 7.1. Your > >>> problem description sounds like it could be caused by > >>> the same problem. > >>> > >>> Therefore I recommend you update to 7.1 or 7-stable. > >>> > >>> Best regards > >>> Oliver > >>> > >>> > >>> > >> Hello. > >> > >> System updated to: > >> [root@taurus /usr/home/qwe]# uname -a > >> FreeBSD *** 7.1-RELEASE-p3 FreeBSD 7.1-RELEASE-p3 #0: Thu Mar 19 > >> 16:31:53 EET 2009 root@***:/usr/obj/usr/src/sys/QWEKRN70 i386 > >> > >> but once trouble has repeated (30 mins ago). > >> > >> > >> After that I change my sysctl variables: > >> net.inet.ip.dummynet.io_fast=1 > >> net.inet.ip.dummynet.debug=1 > >> net.inet.ip.dummynet.hash_size=16384 (from 512) > >> > >> What can I'll to do? > >> > >> Sorry for my bad English :( > >> _______________________________________________ > >> freebsd-ipfw@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > >> > > > > Please do the following (when dummynet will hang next time): > > 1) Grab the output of follwing commands: > > sysctl net.inet.ip.dummynet > > ipfw pipe show > > 2) wait a bit (30 seconds should be enough) > > 3) do 1) once again. > > > > Examining counters may help in understanding problem. > > > > > before: > > sysctl net.inet.ip.dummynet > net.inet.ip.dummynet.debug: 0 > net.inet.ip.dummynet.pipe_byte_limit: 1048576 > net.inet.ip.dummynet.pipe_slot_limit: 100 > net.inet.ip.dummynet.io_pkt_drop: 14138 > net.inet.ip.dummynet.io_pkt_fast: 610276 > net.inet.ip.dummynet.io_pkt: 1789875 > net.inet.ip.dummynet.io_fast: 1 > net.inet.ip.dummynet.tick_lost: 0 > net.inet.ip.dummynet.tick_diff: -891 > net.inet.ip.dummynet.tick_adjustment: 9797 > net.inet.ip.dummynet.tick_delta_sum: 449 > net.inet.ip.dummynet.tick_delta: 0 > 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: 1798977 > net.inet.ip.dummynet.searches: 1788798 > net.inet.ip.dummynet.extract_heap: 0 > net.inet.ip.dummynet.ready_heap: 48 > net.inet.ip.dummynet.curr_time: 138355446 > net.inet.ip.dummynet.hash_size: 512 > > ipfw pipe show | grep -v ip > > 01241: 2.048 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail > 01122: 4.096 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail > 00801: 9.000 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail > mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 01242: 2.048 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail > 01212: 256.000 Kbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 01121: 4.096 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail > 01091: 512.000 Kbit/s 0 ms 50 sl. 46 queues (512 buckets) droptail > mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 00802: 9.000 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 01211: 256.000 Kbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail > mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 01092: 512.000 Kbit/s 0 ms 50 sl. 45 queues (512 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 00701: 9.000 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail > 00821: 9.000 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail > mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 00791: 9.000 Mbit/s 0 ms 50 sl. 5 queues (512 buckets) droptail > mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 01111: 2.048 Mbit/s 0 ms 50 sl. 5 queues (512 buckets) droptail > mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 00822: 9.000 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 01231: 1.024 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail > mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 01072: 1.024 Mbit/s 0 ms 50 sl. 3 queues (512 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 00702: 9.000 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail > 01251: 1.024 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail > 01232: 1.024 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 01112: 2.048 Mbit/s 0 ms 50 sl. 5 queues (512 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 01071: 1.024 Mbit/s 0 ms 50 sl. 3 queues (512 buckets) droptail > mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 00811: 9.000 Mbit/s 0 ms 50 sl. 2 queues (512 buckets) droptail > mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 00792: 9.000 Mbit/s 0 ms 50 sl. 5 queues (512 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 01221: 512.000 Kbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail > mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 01202: 128.000 Kbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail > 01101: 1.024 Mbit/s 0 ms 50 sl. 18 queues (512 buckets) droptail > mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 01082: 256.000 Kbit/s 0 ms 50 sl. 18 queues (512 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 00812: 9.000 Mbit/s 0 ms 50 sl. 2 queues (512 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 00722: 9.000 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail > 01252: 1.024 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail > 01222: 512.000 Kbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 01201: 128.000 Kbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail > 01102: 1.024 Mbit/s 0 ms 50 sl. 16 queues (512 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 01081: 256.000 Kbit/s 0 ms 50 sl. 19 queues (512 buckets) droptail > mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 00721: 9.000 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail > > after: > sysctl net.inet.ip.dummynet > net.inet.ip.dummynet.debug: 0 > net.inet.ip.dummynet.pipe_byte_limit: 1048576 > net.inet.ip.dummynet.pipe_slot_limit: 100 > net.inet.ip.dummynet.io_pkt_drop: 15177 > net.inet.ip.dummynet.io_pkt_fast: 634143 > net.inet.ip.dummynet.io_pkt: 1873018 > net.inet.ip.dummynet.io_fast: 1 > net.inet.ip.dummynet.tick_lost: 0 > net.inet.ip.dummynet.tick_diff: -884 > net.inet.ip.dummynet.tick_adjustment: 9803 > net.inet.ip.dummynet.tick_delta_sum: 320 > net.inet.ip.dummynet.tick_delta: -1 > 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: 1882134 > net.inet.ip.dummynet.searches: 1871939 > net.inet.ip.dummynet.extract_heap: 0 > net.inet.ip.dummynet.ready_heap: 48 > net.inet.ip.dummynet.curr_time: 138373128 > net.inet.ip.dummynet.hash_size: 512 > > dummynet cpu load now - 56% As i can see things looks normal except high cpu usage. Though i think it's not dummynet's problem - i guess most cpu cycles wasted outside dummynet's code. Could you do some hwpmc profiling? (short how-to: http://freebsd.rambler.ru/bsdmail/freebsd-current_2006/msg01582.html) -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From bugmaster at FreeBSD.org Mon Mar 30 04:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 30 04:08:20 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200903301106.n2UB6sai054776@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/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 57 problems total. From zgabe84 at gmail.com Tue Mar 31 01:08:16 2009 From: zgabe84 at gmail.com (zgabe) Date: Tue Mar 31 01:08:34 2009 Subject: FreeBSD 7.1 IPv6 multihoming problem Message-ID: <22800054.post@talk.nabble.com> Hi All, I am using laptop, FreeBSD 7.1 connecting to two ISPs (wlan and ppp) and I have IPv6 addresses. 'netstat -rn' says there is only one default gateway (for example wlan's default gateway). My problem is the following: If I ping the ppp tunnel from an other computer, my laptop recieves the ICMP6 echo request over the ppp tunnel, but it answers over the wlan interface. I read some similar posts (only ipv4) about forwarding with IPFW, but I was unable to solve my problem until now. I built a kernel with the following options: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD and put these lines to my rc.conf firewall_enable="YES" firewall_type="open" as the handbook says. I use the following command as root: ipfw add 101 fwd pppgateway ipv6 from pppaddress to any (pppgateway and pppaddress ipv6 addresses) It throws "getsockopt(IP_FW_ADD): Invalid argument" error! I have tried to set the following variables but the problem is still the same. sysctl -w net.inet.ip.forwarding=1 and sysctl -w net.inet6.ip6.forwarding=1 Thoughts? -- View this message in context: http://www.nabble.com/FreeBSD-7.1-IPv6-multihoming-problem-tp22800054p22800054.html Sent from the freebsd-ipfw mailing list archive at Nabble.com. From zgabe84 at gmail.com Tue Mar 31 01:08:16 2009 From: zgabe84 at gmail.com (zgabe) Date: Tue Mar 31 01:08:35 2009 Subject: FreeBSD 7.1 IPv6 multihoming problem Message-ID: <22800054.post@talk.nabble.com> Hi All, I am using laptop, FreeBSD 7.1 connecting to two ISPs (wlan and ppp) and I have IPv6 addresses. 'netstat -rn' says there is only one default gateway (for example wlan's default gateway). My problem is the following: If I ping the ppp tunnel from an other computer, my laptop recieves the ICMP6 echo request over the ppp tunnel, but it answers over the wlan interface. I read some similar posts (only ipv4) about forwarding with IPFW, but I was unable to solve my problem until now. I built a kernel with the following options: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD and put these lines to my rc.conf firewall_enable="YES" firewall_type="open" as the handbook says. I use the following command as root: ipfw add 101 fwd pppgateway ipv6 from pppaddress to any (pppgateway and pppaddress ipv6 addresses) It throws "getsockopt(IP_FW_ADD): Invalid argument" error! I have tried to set the following variables but the problem is still the same. sysctl -w net.inet.ip.forwarding=1 and sysctl -w net.inet6.ip6.forwarding=1 Can anybody help me? -- View this message in context: http://www.nabble.com/FreeBSD-7.1-IPv6-multihoming-problem-tp22800054p22800054.html Sent from the freebsd-ipfw mailing list archive at Nabble.com. From fabian at wenks.ch Tue Mar 31 10:15:33 2009 From: fabian at wenks.ch (Fabian Wenk) Date: Tue Mar 31 10:15:41 2009 Subject: FreeBSD 7.1 IPv6 multihoming problem In-Reply-To: <22800054.post@talk.nabble.com> References: <22800054.post@talk.nabble.com> Message-ID: <49D24FA8.5040904@wenks.ch> Hello On 31.03.09 09:51, zgabe wrote: > I use the following command as root: > ipfw add 101 fwd pppgateway ipv6 from pppaddress to any > > (pppgateway and pppaddress ipv6 addresses) > > It throws "getsockopt(IP_FW_ADD): Invalid argument" error! > Thoughts? I do have a similar setup, which works fine with IPv4, but with similar problems on FreeBSD 6.x with IPv6, see "bin/117214: ipfw(8) fwd with IPv6 treats input as IPv4" [1] for the bug report I had submitted. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=117214 Probably I should try my setup with 7.1 once, currently it is still running with 6.x. bye Fabian From julian at elischer.org Tue Mar 31 13:38:29 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Mar 31 13:38:36 2009 Subject: FreeBSD 7.1 IPv6 multihoming problem In-Reply-To: <22800054.post@talk.nabble.com> References: <22800054.post@talk.nabble.com> Message-ID: <49D27F5C.7030506@elischer.org> zgabe wrote: > Hi All, > > I am using laptop, FreeBSD 7.1 connecting to two ISPs (wlan and ppp) and I > have IPv6 addresses. 'netstat -rn' says there is only one default gateway > (for example wlan's default gateway). My problem is the following: > If I ping the ppp tunnel from an other computer, my laptop recieves the > ICMP6 echo request over the ppp tunnel, but it answers over the wlan > interface. I read some similar posts (only ipv4) about forwarding with IPFW, > but I was unable to solve my problem until now. > > I built a kernel with the following options: > options IPFIREWALL > options IPFIREWALL_VERBOSE > options IPFIREWALL_DEFAULT_TO_ACCEPT > options IPFIREWALL_FORWARD > > and put these lines to my rc.conf > firewall_enable="YES" > firewall_type="open" > > as the handbook says. > > I use the following command as root: > ipfw add 101 fwd pppgateway ipv6 from pppaddress to any > > (pppgateway and pppaddress ipv6 addresses) > > It throws "getsockopt(IP_FW_ADD): Invalid argument" error! > > I have tried to set the following variables but the problem is still the > same. > sysctl -w net.inet.ip.forwarding=1 and > sysctl -w net.inet6.ip6.forwarding=1 > > Can anybody help me? > the theory with multihoming is that unless you are the holder of a class-C (/24) you basically have to do it using NAT. You have to make some subset of your traffic use one NAT while the remainder uses another (or is untranslated). Unfortunately we don't have NAT for IPV6. I don't know how that gets solved..