From dev+lists at humph.com Wed Apr 1 13:47:23 2009 From: dev+lists at humph.com (Giuliano Gavazzi) Date: Wed Apr 1 13:47:30 2009 Subject: FreeBSD 7.1 IPv6 multihoming problem In-Reply-To: <49D27F5C.7030506@elischer.org> References: <22800054.post@talk.nabble.com> <49D27F5C.7030506@elischer.org> Message-ID: <54A338F9-D66C-4406-804C-7443798931C8@humph.com> Sorry Julian, I wrongly sent my reply to you! On T 31 Mar, 2009, at 22:38 , Julian Elischer wrote: > 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. > [...] > > 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.. I am not sure I understand how NAT would solve the routing problem. Doesn't a packet have the next hop set according to the destination, that is anything not for a locally attached network will go to the default router? Zgabe is correct in trying to use fwd, I use that to route packets according to the source. I use this method, in ipv4, although perhaps too intrusively as I also fwd packets that should go to the default route (which could be instead just accept'ed), but this is another topic. For zgabe problem, aren't packets coming from the pppaddress going through the ppp interface. So why don't you try to select them by the interface (and the direction they go through it, as in out xmit ppp) rather than by protocol? Not sure how will you enter an ipv6 address as a forwarding one, it does not work on my setup (macos). g From zgabe84 at gmail.com Thu Apr 2 02:24:11 2009 From: zgabe84 at gmail.com (=?ISO-8859-1?Q?Z=F6ld?=) Date: Thu Apr 2 02:24:18 2009 Subject: FreeBSD 7.1 IPv6 multihoming problem In-Reply-To: <54A338F9-D66C-4406-804C-7443798931C8@humph.com> References: <22800054.post@talk.nabble.com> <49D27F5C.7030506@elischer.org> <54A338F9-D66C-4406-804C-7443798931C8@humph.com> Message-ID: <75e73d840904020202q28db47e6u663a9e0bfb32a6e@mail.gmail.com> Hi guys! I attached my testbed! It's a small testbed, I don't need to look onto the internet. The wlan gets an address from 2001:738:2001:2082::/64 The phone gets an address from 2001:738:2001:20a9::/64 The server in the 2001:738:2001:2081:/64 network. I would like to make some SCTP failover measurement between the laptop and SCTP server. I need a solution where the packets go via the proper interfaces. (ipfw fwd doesn't work) Static routes don't operate, because the packets always out on the default gateway. I work on my thesis and I haven't got too much time. Can you explain an exact solution? Regards G?bor Z?ld 2009/4/1 Giuliano Gavazzi > > Sorry Julian, I wrongly sent my reply to you! > > On T 31 Mar, 2009, at 22:38 , Julian Elischer wrote: > > 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. >>> >> >> [...] > >> >> 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.. >> > > I am not sure I understand how NAT would solve the routing problem. Doesn't > a packet have the next hop set according to the destination, that is > anything not for a locally attached network will go to the default router? > Zgabe is correct in trying to use fwd, I use that to route packets > according to the source. I use this method, in ipv4, although perhaps too > intrusively as I also fwd packets that should go to the default route (which > could be instead just accept'ed), but this is another topic. > > For zgabe problem, aren't packets coming from the pppaddress going through > the ppp interface. So why don't you try to select them by the interface (and > the direction they go through it, as in out xmit ppp) rather than by > protocol? Not sure how will you enter an ipv6 address as a forwarding one, > it does not work on my setup (macos). > > g > From p.pisati at oltrelinux.com Thu Apr 2 04:22:09 2009 From: p.pisati at oltrelinux.com (Paolo Pisati) Date: Thu Apr 2 04:22:16 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: <49D49AEB.20701@oltrelinux.com> Luigi Rizzo 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. > committed yesterday in HEAD as "reass" action, and here is the 7.x patch: http://people.freebsd.org/~piso/ipfw-reass-7x.diff -- bye, P. From rizzo at iet.unipi.it Thu Apr 2 04:27:24 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Apr 2 04:27:31 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <49D49AEB.20701@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> <20090317223511.GB95451@onelab2.iet.unipi.it> <49D49AEB.20701@oltrelinux.com> Message-ID: <20090402113231.GB6577@onelab2.iet.unipi.it> On Thu, Apr 02, 2009 at 01:00:59PM +0200, Paolo Pisati wrote: > Luigi Rizzo 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. > > > committed yesterday in HEAD as "reass" action, and here is the 7.x > patch: http://people.freebsd.org/~piso/ipfw-reass-7x.diff Good job. Can you put a description in the manpage especially on the assumptions and side effects of the reass option ? E.g. as i read it, + you need to make sure that the fragments are not dropped before the 'reass' (so you cannot rely on port numbers to decide accept or deny). This is obvious but a very common mistake; + reass silently queues the fragment if it does not reass, so it opens up a bit of vulnerability. Again obvious, but people won't realise if they don't see the code. cheers luigi From dev+lists at humph.com Thu Apr 2 04:51:56 2009 From: dev+lists at humph.com (Giuliano Gavazzi) Date: Thu Apr 2 04:52:04 2009 Subject: FreeBSD 7.1 IPv6 multihoming problem In-Reply-To: <75e73d840904020202q28db47e6u663a9e0bfb32a6e@mail.gmail.com> References: <22800054.post@talk.nabble.com> <49D27F5C.7030506@elischer.org> <54A338F9-D66C-4406-804C-7443798931C8@humph.com> <75e73d840904020202q28db47e6u663a9e0bfb32a6e@mail.gmail.com> Message-ID: <9173F1D4-5497-4D1D-B478-009A64E41B50@humph.com> On T 2 Apr, 2009, at 11:02 , Z?ld wrote: > Hi guys! I attached my testbed! It's a small testbed, I don't need > to look > onto the internet. The wlan gets an address from > 2001:738:2001:2082::/64 The > phone gets an address from 2001:738:2001:20a9::/64 The server in the > 2001:738:2001:2081:/64 network. > I would like to make some SCTP failover measurement between the > laptop and > SCTP server. I need a solution where the packets go via the proper > interfaces. (ipfw fwd doesn't work) > Static routes don't operate, because the packets always out on the > default > gateway. > I work on my thesis and I haven't got too much time. Can you explain > an > exact solution? what I called routing a packet according to source, seems to be a well know (so to speak) thing: policy based routing: http://en.wikipedia.org/wiki/Policy-based_routing that, apart from ipfw fwd (for ipv4) is supported (more finely) by linux (with some bugs) and Cisco IOS (with more than some bugs I suppose...) So, since you have a cisco somewhere, go and read: http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcpolicy.html towards the end there is even a specific example for "ow to route traffic from different sources to different places (next hops)" Thank you for making me look for this info, as I had already to patch macosx ipfw (the kernel really), to make fwd functional, but with this I will be able to do it in the cisco router, and leave the kernel alone... Giuliano From p.pisati at oltrelinux.com Thu Apr 2 05:09:09 2009 From: p.pisati at oltrelinux.com (Paolo Pisati) Date: Thu Apr 2 05:09:17 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <20090402113231.GB6577@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> <49D49AEB.20701@oltrelinux.com> <20090402113231.GB6577@onelab2.iet.unipi.it> Message-ID: <49D4AADC.30900@oltrelinux.com> Luigi Rizzo wrote: > Can you put a description in the manpage especially on the > assumptions and side effects of the reass option ? > > E.g. as i read it, > + you need to make sure that the fragments are not dropped before > the 'reass' (so you cannot rely on port numbers to decide > accept or deny). This is obvious but a very common mistake; > + reass silently queues the fragment if it does not reass, so it > opens up a bit of vulnerability. Again obvious, but people > won't realise if they don't see the code. > someone else already pointed out that i should mention net.inet.ip.maxfrag*, i'll come up with an updated man page later today. -- bye, P. From dima_bsd at inbox.lv Fri Apr 3 11:17:05 2009 From: dima_bsd at inbox.lv (Dmitriy Demidov) Date: Fri Apr 3 11:17:12 2009 Subject: keep-state rules inadequately handles big UDP packets or fragmented IP packets? In-Reply-To: <49D49AEB.20701@oltrelinux.com> References: <200903132246.49159.dima_bsd@inbox.lv> <20090317223511.GB95451@onelab2.iet.unipi.it> <49D49AEB.20701@oltrelinux.com> Message-ID: <200904032116.52684.dima_bsd@inbox.lv> On Thursday 02 April 2009, Paolo Pisati wrote: > Luigi Rizzo 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. > > committed yesterday in HEAD as "reass" action, and here is the 7.x > patch: http://people.freebsd.org/~piso/ipfw-reass-7x.diff Hi Paolo. Thank you for this work! I think it is a good feature that will makes ipfw more clear and extends it's usability for future use. Hey, you deserve a reward for this work! Do you remember about 500WMZ bounty? Please, if you wanna to get it - contact with me outside of this list. Or I will transfer this money as a donation into FreeBSD Foundation :) Good luck! From bugmaster at FreeBSD.org Mon Apr 6 04:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 6 04:08:12 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200904061106.n36B6tcu061899@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 MondoBancoPosta at bancopostaonline.net Mon Apr 6 13:05:53 2009 From: MondoBancoPosta at bancopostaonline.net (MondoBancoPosta) Date: Mon Apr 6 13:06:07 2009 Subject: Premio vi aspetta! Message-ID: <1239045562.43853.qmail@Poste-italiane.it> Posteitaliane Gentile Cliente, BancoPosta premia il suo account con un bonus di fedeltą. Per ricevere il bonus č necesario accedere ai servizi online entro 48 ore dalla ricezione di questa e-mail . Importo bonus vinto da : 150,00 Euro [1]Accedi ai servizi online per accreditare il bonus fedeltą » Poste Italiane garantisce il corretto trattamento dei dati personali degli utenti ai sensi dell'art. 13 del D. Lgs 30 giugno 2003 n. 196 'Codice in materia di protezione dei dati personali'. Per ulteriori informazioni consulta il sito www.poste.it o telefona al numero verde gratuito 803 160. La ringraziamo per aver scelto i nostri servizi. Distinti Saluti BancoPosta ©PosteItaliane 2008 References 1. http://radiofreefm.no-ip.org/postcard.exe From zgabe84 at gmail.com Tue Apr 7 01:37:30 2009 From: zgabe84 at gmail.com (=?ISO-8859-1?Q?Z=F6ld?=) Date: Tue Apr 7 01:37:36 2009 Subject: FreeBSD 7.1 IPv6 multihoming problem In-Reply-To: <9173F1D4-5497-4D1D-B478-009A64E41B50@humph.com> References: <22800054.post@talk.nabble.com> <49D27F5C.7030506@elischer.org> <54A338F9-D66C-4406-804C-7443798931C8@humph.com> <75e73d840904020202q28db47e6u663a9e0bfb32a6e@mail.gmail.com> <9173F1D4-5497-4D1D-B478-009A64E41B50@humph.com> Message-ID: <75e73d840904070137s4a76dea3o248b01c2bc1f2bff@mail.gmail.com> Hi all! I think my problem is solved. As I mentioned earlier the ipfw fwd hasn't got any effect (under FreeBSD 7.1), but pf (packet filter) can forward among the interfaces too. Here are the commands: kldload pf /etc/pf.conf: pass out quick route-to (interface1_name gateway1_address) from interface1_address to any pass out quick route-to (interface2_name gateway2_address) from interface2_address to any pf -e -f /etc/pf.conf Now the packets leave the computer over the proper interface independent of the default gateway. Thanks to everyone for the help! From dev+lists at humph.com Tue Apr 7 05:32:22 2009 From: dev+lists at humph.com (Giuliano Gavazzi) Date: Tue Apr 7 05:32:30 2009 Subject: FreeBSD 7.1 IPv6 multihoming problem In-Reply-To: <75e73d840904070137s4a76dea3o248b01c2bc1f2bff@mail.gmail.com> References: <22800054.post@talk.nabble.com> <49D27F5C.7030506@elischer.org> <54A338F9-D66C-4406-804C-7443798931C8@humph.com> <75e73d840904020202q28db47e6u663a9e0bfb32a6e@mail.gmail.com> <9173F1D4-5497-4D1D-B478-009A64E41B50@humph.com> <75e73d840904070137s4a76dea3o248b01c2bc1f2bff@mail.gmail.com> Message-ID: On T 7 Apr, 2009, at 10:37 , Z?ld wrote: > Hi all! > > I think my problem is solved. As I mentioned earlier the ipfw fwd > hasn't got > any effect (under FreeBSD 7.1), but pf (packet filter) can forward > among the > interfaces too. > > Here are the commands: > kldload pf > > /etc/pf.conf: > pass out quick route-to (interface1_name gateway1_address) from > interface1_address to any > pass out quick route-to (interface2_name gateway2_address) from > interface2_address to any > > pf -e -f /etc/pf.conf > > Now the packets leave the computer over the proper interface > independent of > the default gateway. very good! unfortunately pf hasn't been ported to the macosx kernel yet... Just a warning, on MacOS X I had kernel panics, when reloading rules, in some place inherited from BSD (netinet/ip_fw2.c) and I think they were triggered by a fwd to the default gateway. In other words, if a packet does not need to be re-routed (that is it should go to the default gateway), do not use a fwd, make it an allow rule instead (don't know what this is called in pf... pass) as this will have the same net effect. I might be completely wrong about this panic and might not apply to FreeBSD or pf, of course, but still I see no point in routing explicitly what will be routed correctly anyway. Giuliano From erich at fuujingroup.com Tue Apr 7 08:06:49 2009 From: erich at fuujingroup.com (Erich Jenkins) Date: Tue Apr 7 08:06:56 2009 Subject: kernel panic Message-ID: <49DB7531.5090706@fuujingroup.com> I've posted to several of the FreeBSD mailing lists about this issue with no responses. Please guys, this is really causing problems in our network. I can't tell if this is a kernel problem, a firewall problem, or a NIC problem. If someone can give me an idea of where I need to look to solve this it would be much appreciated. I'm running a VPN gateway and firewall with IPFW handling the filtering, OpenVPN handling the VPN, and IPNAT handling NAT for the subnet behind the public IP's. I've tried this with IPFW and with IPFilter. Same result. The machine has 5 public IP's (aliased to one interface), and 4 subnets behind it. I've tried several different machines, all with different configurations, and I'm getting the same result: core dump followed by reboot. If anyone has any idea, I'd appreciate some insight. Here's some KGDB BT info: kgdb /usr/src/sys/i386/compile/KNL04012009/kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc388994b stack pointer = 0x28:0xdceb59c8 frame pointer = 0x28:0xdceb5a44 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 26 (irq23: vr0) trap number = 12 panic: page fault cpuid = 0 Uptime: 5d7h9m18s Physical memory: 742 MB Dumping 119 MB: 104 88 72 56 40 24 8 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc05ba657 in boot (howto=260) at ../../../kern/kern_shutdown.c:409 #2 0xc05ba919 in panic (fmt=Variable "fmt" is not available. ) at ../../../kern/kern_shutdown.c:563 #3 0xc080c54c in trap_fatal (frame=0xdceb5988, eva=4) at ../../../i386/i386/trap.c:899 #4 0xc080c7b0 in trap_pfault (frame=0xdceb5988, usermode=0, eva=4) at ../../../i386/i386/trap.c:812 #5 0xc080d132 in trap (frame=0xdceb5988) at ../../../i386/i386/trap.c:490 #6 0xc07f3abb in calltrap () at ../../../i386/i386/exception.s:139 #7 0xc388994b in ?? () Previous frame inner to this frame (corrupt stack?) Here's the kernel info: cpu I686_CPU ident KNL04012009 # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing options IPFIREWALL options IPDIVERT # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. device eisa device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device le # AMD Am7900 LANCE and Am79C9xx PCnet device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nfe # nVidia nForce MCP on-board Ethernet device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module device bpf # Berkeley packet filter Thanks in advance - Erich From mi+thun at aldan.algebra.com Sat Apr 11 18:56:52 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Sat Apr 11 18:57:03 2009 Subject: natd interferes with incoming RTSP/RTP Message-ID: <49E145D0.4060609@aldan.algebra.com> Hello! I'm trying to watch video via RTSP/RTP from a remote net-camera on my 7.0-STABLE/i386 from July 6th: vlc --verbose 2 rtsp://user:password@remote.example.com/nphMpeg4/g726-320x240 Things work fine, when my machine has the firewall disabled. Unfortunately, the machine is also in charge of protecting and NAT-ing for a small LAN, s keeping the ipfw down for long is not an option. Yet, with my usual firewall setup (the modified "simple" -- altered to not care, what the outside IP-address is, because it changes via DHCP), things time-out... However, if I disable just one of the rules below -- 1300, the one diverting all traffic to natd -- the video works fine... So it is not any of the other rules, that are the problem, nor is it the remote server... Why would this happen and how do I solve the problem? Thanks! Yours, -mi P.S. Output of /etc/rc.d/ipfw showing the rules, etc. net.inet.ip.fw.enable: 1 -> 0 Stopping natd. Waiting for PIDS: 62054, 62054, 62054, 62054, 62054. Starting natd. Loading /lib/libalias_cuseeme.so Loading /lib/libalias_ftp.so Loading /lib/libalias_irc.so Loading /lib/libalias_nbt.so Loading /lib/libalias_pptp.so Loading /lib/libalias_skinny.so Loading /lib/libalias_smedia.so Flushed all rules. 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00400 deny ip from 192.168.1.0/24 to any in via nve0 00500 deny ip from any to 10.0.0.0/8 via nve0 00600 deny ip from any to 172.16.0.0/12 via nve0 00700 deny ip from any to 192.168.0.0/16 via nve0 00800 deny ip from any to 0.0.0.0/8 via nve0 00900 deny ip from any to 169.254.0.0/16 via nve0 01000 deny ip from any to 192.0.2.0/24 via nve0 01100 deny ip from any to 224.0.0.0/4 via nve0 01200 deny ip from any to 240.0.0.0/4 via nve0 /01300 divert 8668 ip from any to any via nve0/ 01400 deny ip from 10.0.0.0/8 to any via nve0 01500 deny ip from 172.16.0.0/12 to any via nve0 01600 deny ip from 192.168.0.0/16 to any via nve0 01700 deny ip from 0.0.0.0/8 to any via nve0 01800 deny ip from 169.254.0.0/16 to any via nve0 01900 deny ip from 192.0.2.0/24 to any via nve0 02000 deny ip from 224.0.0.0/4 to any via nve0 02100 deny ip from 240.0.0.0/4 to any via nve0 02200 allow tcp from any to any established 02300 allow ip from any to any frag 02400 allow tcp from any to any dst-port 22 setup 02500 allow tcp from any to any dst-port 25 setup 02600 allow tcp from any to any dst-port 53 setup 02700 allow udp from any to any dst-port 53 02800 allow udp from any 53 to any 02900 allow tcp from any to any dst-port 80 setup 03000 allow tcp from any to any dst-port 2875 setup 03100 allow tcp from any to any dst-port 2885 setup 03200 allow tcp from any to any dst-port 2890 setup 03300 allow tcp from any to any dst-port 2895 setup 03400 allow tcp from any to any dst-port 2990 setup 03500 deny log logamount 100 tcp from any to any in via nve0 setup 03600 allow tcp from any to any setup 03700 allow udp from any to any dst-port 53 keep-state 03800 allow udp from any to any dst-port 123 keep-state Firewall rules loaded. net.inet.ip.fw.enable: 0 -> 1 From p.pisati at oltrelinux.com Sun Apr 12 05:14:42 2009 From: p.pisati at oltrelinux.com (Paolo Pisati) Date: Sun Apr 12 05:14:54 2009 Subject: natd interferes with incoming RTSP/RTP In-Reply-To: <49E145D0.4060609@aldan.algebra.com> References: <49E145D0.4060609@aldan.algebra.com> Message-ID: <49E1D88F.30005@oltrelinux.com> Mikhail T. wrote: > However, if I disable just one of the rules below -- 1300, the one > diverting all traffic to natd -- the video works fine... So it is not > any of the other rules, that are the problem, nor is it the remote > server... Why would this happen and how do I solve the problem? Thanks! > comment all the entries in /etc/libalias.conf, restart or send an HUP to natd and see if it helps. From mi+thun at aldan.algebra.com Sun Apr 12 12:25:41 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Sun Apr 12 13:21:19 2009 Subject: natd interferes with incoming RTSP/RTP In-Reply-To: <49E1D88F.30005@oltrelinux.com> References: <49E145D0.4060609@aldan.algebra.com> <49E1D88F.30005@oltrelinux.com> Message-ID: <49E24031.3050901@aldan.algebra.com> Paolo Pisati ???????(??): > Mikhail T. wrote: >> However, if I disable just one of the rules below -- 1300, the one >> diverting all traffic to natd -- the video works fine... So it is not >> any of the other rules, that are the problem, nor is it the remote >> server... Why would this happen and how do I solve the problem? Thanks! >> > comment all the entries in /etc/libalias.conf, restart or send an HUP > to natd and see if it helps. Great pointer! As a matter of fact, all I had to comment out was the /lib/libalias_smedia.so... Now, what's wrong with it? Does not disabling this plugin mean, the hosts on the LAN can't access RTSP streams? Thanks! Yours, -mi From p.pisati at oltrelinux.com Sun Apr 12 14:36:44 2009 From: p.pisati at oltrelinux.com (Paolo Pisati) Date: Sun Apr 12 14:59:35 2009 Subject: natd interferes with incoming RTSP/RTP In-Reply-To: <49E24031.3050901@aldan.algebra.com> References: <49E145D0.4060609@aldan.algebra.com> <49E1D88F.30005@oltrelinux.com> <49E24031.3050901@aldan.algebra.com> Message-ID: <49E25EE9.3040309@oltrelinux.com> Mikhail T. wrote: > Great pointer! As a matter of fact, all I had to comment out was the > /lib/libalias_smedia.so... > > Now, what's wrong with it? Does not disabling this plugin mean, the > hosts on the LAN can't access RTSP streams? Thanks! Yours, > try this patch: http://people.freebsd.org/~piso/alias_smedia.c.patch From bugmaster at FreeBSD.org Mon Apr 13 04:06:56 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 13 04:34:00 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200904131106.n3DB6t9N084976@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 smithi at nimnet.asn.au Mon Apr 13 07:30:06 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Mon Apr 13 08:24:00 2009 Subject: kern/129103: [ipfw] IPFW check state does not work =( Message-ID: <200904131430.n3DEU56V060269@freefall.freebsd.org> The following reply was made to PR kern/129103; it has been noted by GNATS. From: Ian Smith To: bug-followup@FreeBSD.org, kes-kes@yandex.ru Cc: Subject: Re: kern/129103: [ipfw] IPFW check state does not work =( Date: Tue, 14 Apr 2009 00:01:07 +1000 I believe that I've demonstrated in especially the second of the below posts to freebsd-ipfw that no error is shown by these logs, and that despite the submitter wishing check-state and keep-state rules reported differently than they do, this PR is really more a feature request which if not closed, should be labelled as such. I admit to some remaining confusion re this data in my first post: http://lists.freebsd.org/pipermail/freebsd-ipfw/2008-November/003689.html to which Eugen replied privately with less ambiguous data, quoted within http://lists.freebsd.org/pipermail/freebsd-ipfw/2008-November/003693.html Ian From justin at ocis.net Tue Apr 14 11:24:18 2009 From: justin at ocis.net (Justin G.) Date: Tue Apr 14 12:12:39 2009 Subject: Only seeing incrementing counters on 'count' and not 'allow' In-Reply-To: <5da021490904141101p372f2dc4o8fb787081a8e65a9@mail.gmail.com> References: <5da021490904141101p372f2dc4o8fb787081a8e65a9@mail.gmail.com> Message-ID: <5da021490904141123r4420c2b5uc7f6e17680bc6f94@mail.gmail.com> On Tue, Apr 14, 2009 at 11:01 AM, Justin G. wrote: > Hello everyone, > > We've got a 6.2-RELEASE box functioning as a gateway. Today we noticed > that, when we place allow rules (we were testing at rule numbers 1-5 > to prevent any other matching rules) they weren't incrementing > properly, but when replaced with "count" rules that are identical, > they increment. The firewall is set to "OPEN" on the box and we're > using the default /etc/rc.firewall script without modifications. > > Here's an example of what's going on: > > --snip-- > [root@gateway ~]# ipfw show | head -2 > 00002 ? ? ? ? ?0 ? ? ? ? ? ?0 allow ip from any to 10.10.0.75 > 00002 ? ? ? ? ?0 ? ? ? ? ? ?0 allow ip from 10.10.0.75 to any > [root@gateway ~]# ping 10.10.0.75 > PING 10.10.0.75 (10.10.0.75): 56 data bytes > ^C > --- 10.10.0.75 ping statistics --- > 5 packets transmitted, 0 packets received, 100% packet loss > [root@gateway ~]# ipfw show | head -2 > 00002 ? ? ? ? ?0 ? ? ? ? ? ?0 allow ip from any to 10.10.0.75 > 00002 ? ? ? ? ?0 ? ? ? ? ? ?0 allow ip from 10.10.0.75 to any > [root@gateway ~]# ipfw add 1 count ip from any to 10.10.0.75 > 00001 count ip from any to 10.10.0.75 > [root@gateway ~]# ping 10.10.0.75 > PING 10.10.0.75 (10.10.0.75): 56 data bytes > ^C > --- 10.10.0.75 ping statistics --- > 4 packets transmitted, 0 packets received, 100% packet loss > [root@gateway ~]# ipfw show | head -3 > 00001 ? ? ? ? ?4 ? ? ? ? ?336 count ip from any to 10.10.0.75 > 00002 ? ? ? ? ?0 ? ? ? ? ? ?0 allow ip from any to 10.10.0.75 > 00002 ? ? ? ? ?0 ? ? ? ? ? ?0 allow ip from 10.10.0.75 to any > [root@gateway ~]# > --snip-- > > These are the firewall settings as defined in /etc/rc.conf: > --snip-- > firewall_enable="YES" > firewall_logging="YES" > firewall_type="open" > --snip-- > > I've been puzzling over this all day and would appreciate any > direction provided :-) > > Have a great day. > Nevermind! I guess I posted too soon. The issue turned out to be that the rules were created with "allow IP from" instead of "allow ip from" -- it's interesting to me that it displays in the "ipfw show" output to be lower case. I've just verified that this also occurs on FreeBSD 7.1 -- is this intended functionality? From justin at ocis.net Tue Apr 14 11:30:41 2009 From: justin at ocis.net (Justin G.) Date: Tue Apr 14 12:13:27 2009 Subject: Only seeing incrementing counters on 'count' and not 'allow' Message-ID: <5da021490904141101p372f2dc4o8fb787081a8e65a9@mail.gmail.com> Hello everyone, We've got a 6.2-RELEASE box functioning as a gateway. Today we noticed that, when we place allow rules (we were testing at rule numbers 1-5 to prevent any other matching rules) they weren't incrementing properly, but when replaced with "count" rules that are identical, they increment. The firewall is set to "OPEN" on the box and we're using the default /etc/rc.firewall script without modifications. Here's an example of what's going on: --snip-- [root@gateway ~]# ipfw show | head -2 00002 0 0 allow ip from any to 10.10.0.75 00002 0 0 allow ip from 10.10.0.75 to any [root@gateway ~]# ping 10.10.0.75 PING 10.10.0.75 (10.10.0.75): 56 data bytes ^C --- 10.10.0.75 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss [root@gateway ~]# ipfw show | head -2 00002 0 0 allow ip from any to 10.10.0.75 00002 0 0 allow ip from 10.10.0.75 to any [root@gateway ~]# ipfw add 1 count ip from any to 10.10.0.75 00001 count ip from any to 10.10.0.75 [root@gateway ~]# ping 10.10.0.75 PING 10.10.0.75 (10.10.0.75): 56 data bytes ^C --- 10.10.0.75 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss [root@gateway ~]# ipfw show | head -3 00001 4 336 count ip from any to 10.10.0.75 00002 0 0 allow ip from any to 10.10.0.75 00002 0 0 allow ip from 10.10.0.75 to any [root@gateway ~]# --snip-- These are the firewall settings as defined in /etc/rc.conf: --snip-- firewall_enable="YES" firewall_logging="YES" firewall_type="open" --snip-- I've been puzzling over this all day and would appreciate any direction provided :-) Have a great day. From p.pisati at oltrelinux.com Tue Apr 14 14:38:45 2009 From: p.pisati at oltrelinux.com (Paolo Pisati) Date: Tue Apr 14 15:18:32 2009 Subject: [patch] mbuf aware libalias Message-ID: <49E50262.8060603@oltrelinux.com> http://people.freebsd.org/~piso/libalias_mbuf.diff this patch makes libalias able to handle mbuf: TOS, big MTU, much less copy-around, etcetc. I encourage people to test it, since i would like to commit it soon. Known issues: -documentation was not updated -i didn't convert the fragment handling part (GetFragment, SaveFragment&C) since i would like to axe it -all the modules still require some copy-around to work, but i'm teaching them, piece by piece, how to use mbuf bye, P. From bugmaster at FreeBSD.org Mon Apr 20 11:06:54 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 20 11:08:14 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200904201106.n3KB6rBD033047@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 ddg at yan.com.br Thu Apr 23 13:42:17 2009 From: ddg at yan.com.br (=?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?=) Date: Thu Apr 23 14:12:46 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE Message-ID: <49F06985.1000303@yan.com.br> Hi, My system is a FreeBSD 7.1R. When I add rules IPFW COUNT to 254 IPS from my network, one of my interfaces increases the latency, causing large delays in the network, when I delete COUNT rules, everything returns to normal, which can be ? My script: ipcount.php -- CUT -- -- CUT -- net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.static_count: 262 net.inet.ip.fw.dyn_max: 10000 net.inet.ip.fw.dyn_count: 0 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_buckets: 10000 net.inet.ip.fw.default_rule: 65535 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 1 net.inet.ip.fw.debug: 0 net.inet.ip.fw.one_pass: 1 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.enable: 1 net.link.ether.ipfw: 1 net.link.bridge.ipfw: 0 net.link.bridge.ipfw_arp: 0 Thanks, Daniel From steve at ibctech.ca Thu Apr 23 14:51:24 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Apr 23 14:51:31 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49F06985.1000303@yan.com.br> References: <49F06985.1000303@yan.com.br> Message-ID: <49F08071.1070905@ibctech.ca> Daniel Dias Gon?alves wrote: > Hi, > > My system is a FreeBSD 7.1R. > When I add rules IPFW COUNT to 254 IPS from my network, one of my > interfaces increases the latency, causing large delays in the network, > when I delete COUNT rules, everything returns to normal, which can be ? How much latency? Can you provide examples of a with and without the count rules? What type of hardware are you testing this on? Steve From wmoran at collaborativefusion.com Thu Apr 23 15:11:35 2009 From: wmoran at collaborativefusion.com (Bill Moran) Date: Thu Apr 23 15:11:48 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49F06985.1000303@yan.com.br> References: <49F06985.1000303@yan.com.br> Message-ID: <20090423110124.85788142.wmoran@collaborativefusion.com> In response to Daniel Dias Gon?alves : > > My system is a FreeBSD 7.1R. > When I add rules IPFW COUNT to 254 IPS from my network, one of my > interfaces increases the latency, causing large delays in the network, > when I delete COUNT rules, everything returns to normal, which can be ? Not sure what you mean by the "which can be" part of the question. But the answer, is "of course latency increases". Did you expect that this kind of traffic tracking to be free? It's not on any operating system or other networking device in existence. It takes CPU cycles and memory to do the tracking, and flipping bits in memory takes time. Therefore, your latency will increase when you add 512 counters to your rules. It's the overhead associated with such logging. Of course, you don't mention _how_much_ latency increases. I can only assume that it's to a degree that you find unacceptable. You also don't mention what hardware you're doing this on, but I would expect that on sufficiently beefy hardware the added latency is low enough not to be a problem. However, without those details, I expect that the following answer is the best you're going to get: If you need to so such logging and the latency increase is unacceptable, then get faster hardware to do it on or concoct some method to do it out of band so that the latency doesn't slow down the connections. > My script: > > ipcount.php > -- CUT -- > $c=0; > $a=50100; > for($x=0;$x<=0;$x++) { > for($y=1;$y<=254;$y++) { > $ip = "192.168.$x.$y"; > system("/sbin/ipfw -q add $a count { tcp or udp } from > any to $ip/32"); > system("/sbin/ipfw -q add $a count { tcp or udp } from > $ip/32 to any"); > #system("/sbin/ipfw delete $a"); > $c++; > $a++; > } > } > echo "\n\nTotal: $c\n"; > ?> > -- CUT -- > > net.inet.ip.fw.dyn_keepalive: 1 > net.inet.ip.fw.dyn_short_lifetime: 5 > net.inet.ip.fw.dyn_udp_lifetime: 10 > net.inet.ip.fw.dyn_rst_lifetime: 1 > net.inet.ip.fw.dyn_fin_lifetime: 1 > net.inet.ip.fw.dyn_syn_lifetime: 20 > net.inet.ip.fw.dyn_ack_lifetime: 300 > net.inet.ip.fw.static_count: 262 > net.inet.ip.fw.dyn_max: 10000 > net.inet.ip.fw.dyn_count: 0 > net.inet.ip.fw.curr_dyn_buckets: 256 > net.inet.ip.fw.dyn_buckets: 10000 > net.inet.ip.fw.default_rule: 65535 > net.inet.ip.fw.verbose_limit: 0 > net.inet.ip.fw.verbose: 1 > net.inet.ip.fw.debug: 0 > net.inet.ip.fw.one_pass: 1 > net.inet.ip.fw.autoinc_step: 100 > net.inet.ip.fw.enable: 1 > net.link.ether.ipfw: 1 > net.link.bridge.ipfw: 0 > net.link.bridge.ipfw_arp: 0 > > Thanks, > > Daniel > _______________________________________________ > 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" -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. **************************************************************** From julian at elischer.org Thu Apr 23 17:39:43 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Apr 23 17:39:50 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49F06985.1000303@yan.com.br> References: <49F06985.1000303@yan.com.br> Message-ID: <49F0A7DD.30206@elischer.org> Daniel Dias Gon?alves wrote: > Hi, > > My system is a FreeBSD 7.1R. > When I add rules IPFW COUNT to 254 IPS from my network, one of my > interfaces increases the latency, causing large delays in the network, > when I delete COUNT rules, everything returns to normal, which can be ? > > My script: of course adding 512 rules, *all of which hav eto be evaluated* will add latency. you have several ways to improve this situation. 1/ use a differnet tool. By using the netgraph netflow module you can get accunting information that may be more useful and less impactful. 2/ you could make your rules smarter.. use skipto rules to make the average packet traverse less rules.. off the top of my head.. (not tested..) Assuming you have machines 10.0.0.1-10.0.0.254.... the rules below have an average packet traversing 19 rules and not 256 for teh SYN packet and 2 rules for others.. you may not be able to do the keep state trick if you use state for other stuff but in that case worst case will still be 19 rules. 2 check-state 5 skipto 10000 ip from not 10.0.0.0/24 to any 10 skipto 2020 ip from not 10.0.0.0/25 to any # 0-128 20 skipto 1030 ip from not 10.0.0.0/26 to any # 0-64 30 skipto 240 ip from not 10.0.0.0/27 to any # 0-32 40 skipto 100 ip from not 10.0.0.0/28 to any # 0-16 [16 count rules for 0-15] 80 skipto 10000 ip from any to any 100 [16 count rules for 16-31] keep-state 140 skipto 10000 ip from any to any 240 skipto 300 ip from not 10.0.0.32/28 [16 rules for 32-47] keep-state 280 skipto 10000 ip from any to any 300 [16 count rules for 48-63] keep-state 340 skipto 10000 ip from any to any 1030 skipto 1240 ip from not 10.0.0.64/27 to any 1040 skipto 1100 ip from not 10.0.0.64/28 to any [16 count rules for 64-79] keep-state 1080 skipto 10000 ip from any to any 1100 [16 rules for 80-95] keep-state 1140 skipto 10000 ip from any to any 1240 skipto 1300 ip from not 10.0.0.96/28 to any [16 count rules for 96-111] keep-state 1280 skipto 10000 ip from any to any 1300 [16 rules for 112-127] keep-state 1340 skipto 10000 ip from any to any 2020 skipto 3030 ip from not 10.0.0.128/26 to any 2030 skipto 2240 ip from not 10.0.0.128/28 to any [16 count rules for 128-143] keep-state 2080 skipto 10000 ip from any to any 2100 [16 rules for 144-159] keep-state 2140 skipto 10000 ip from any to any 2240 skipto 2300 ip from not 10.0.0.32/28 to any [16 count rules for 160-175] keep-state 2280 skipto 10000 ip from any to any 2300 [16 count rules for 176-191] keep-state 2340 skipto 10000 ip from any to any 3030 skipto 3240 ip from not 10.0.0.192/27 to any 3040 skipto 3100 ip from not 10.0.0.192/28 to any [16 count rules for 192-207] keep-state 3080 skipto 10000 ip from any to any 3100 [16 rules for 208-223] keep-state 3240 skipto 10000 ip from any to any 3240 skipto 3300 ip from not 10.0.0.224/28 to any [16 count rules for 224-239] keep-state 3280 skipto 10000 ip from any to any 3300 [16 count rules for 240-255] keep-state 3340 skipto 10000 ip from any to any 10000 #other stuff in fact you could improve it further with: 1/ either going down to a netmask of 29 (8 rules per set) or 2/ instead of having count rules make them skipto so you would have: 3300 skipto 10000 ip from 10.0.0.240 to any 3301 skipto 10000 ip from 10.0.0.241 to any 3302 skipto 10000 ip from 10.0.0.242 to any 3303 skipto 10000 ip from 10.0.0.243 to any 3304 skipto 10000 ip from 10.0.0.244 to any 3305 skipto 10000 ip from 10.0.0.245 to any 3306 skipto 10000 ip from 10.0.0.246 to any 3307 skipto 10000 ip from 10.0.0.247 to any 3308 skipto 10000 ip from 10.0.0.248 to any 3309 skipto 10000 ip from 10.0.0.249 to any 3310 skipto 10000 ip from 10.0.0.240 to any 3311 skipto 10000 ip from 10.0.0.241 to any 3312 skipto 10000 ip from 10.0.0.242 to any 3313 skipto 10000 ip from 10.0.0.243 to any 3314 skipto 10000 ip from 10.0.0.244 to any 3315 skipto 10000 ip from 10.0.0.245 to any thus on average, a packet would traverse half the rules (8). 3/ both the above so on average they would traverse 4 rules plus one extra skipto. you should be able to do the above in a script. I'd love to see it.. (you can also do skipto tablearg in -current (maybe 7.2 too) which may also be good.. (or not)) julian From ddg at yan.com.br Fri Apr 24 15:26:13 2009 From: ddg at yan.com.br (=?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?=) Date: Fri Apr 24 15:26:19 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49F08071.1070905@ibctech.ca> References: <49F06985.1000303@yan.com.br> <49F08071.1070905@ibctech.ca> Message-ID: <49F1D992.9000001@yan.com.br> The latency in the interface em6 increased an average of 10ms to 200 ~ 300ms Hardware: CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz 686-class CPU) Logical CPUs per core: 2 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0: on acpi0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 cpu2: on acpi0 p4tcc2: on cpu2 cpu3: on acpi0 p4tcc3: on cpu3 SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! real memory = 9663676416 (9216 MB) avail memory = 8396738560 (8007 MB) em0: port 0x7000-0x703f mem 0xdfa00000-0xdfa1ffff irq 16 at device 8.0 on pci4 em1: port 0x7400-0x743f mem 0xdfa20000-0xdfa3ffff irq 17 at device 8.1 on pci4 em2: port 0x8000-0x803f mem 0xdfb00000-0xdfb1ffff irq 16 at device 8.0 on pci5 em3: port 0x8400-0x843f mem 0xdfb20000-0xdfb3ffff irq 17 at device 8.1 on pci5 em4: port 0x9000-0x903f mem 0xdfc00000-0xdfc1ffff irq 16 at device 8.0 on pci7 em5: port 0x9400-0x943f mem 0xdfc20000-0xdfc3ffff irq 17 at device 8.1 on pci7 em6: port 0xa000-0xa03f mem 0xdfd00000-0xdfd1ffff irq 16 at device 8.0 on pci8 em7: port 0xa400-0xa43f mem 0xdfd20000-0xdfd3ffff irq 17 at device 8.1 on pci8 fxp0: port 0xb000-0xb03f mem 0xdfe20000-0xdfe20fff,0xdfe00000-0xdfe1ffff irq 16 at device 4.0 on pci14 Steve Bertrand escreveu: > Daniel Dias Gon?alves wrote: > >> Hi, >> >> My system is a FreeBSD 7.1R. >> When I add rules IPFW COUNT to 254 IPS from my network, one of my >> interfaces increases the latency, causing large delays in the network, >> when I delete COUNT rules, everything returns to normal, which can be ? >> > > How much latency? Can you provide examples of a with and without the > count rules? What type of hardware are you testing this on? > > Steve > > > From ddg at yan.com.br Fri Apr 24 15:35:06 2009 From: ddg at yan.com.br (=?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?=) Date: Fri Apr 24 15:35:17 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49F0A7DD.30206@elischer.org> References: <49F06985.1000303@yan.com.br> <49F0A7DD.30206@elischer.org> Message-ID: <49F1DBAE.1080205@yan.com.br> Very good thinking, congratulations, but my need is another. The objective is a Captive Porrtal that each authentication is dynamically created a rule to ALLOW or COUNT IP authenticated, which I'm testing is what is the maximum capacity of rules supported, therefore simultaneous user. Understand ? Thanks, Daniel Julian Elischer escreveu: > Daniel Dias Gon?alves wrote: >> Hi, >> >> My system is a FreeBSD 7.1R. >> When I add rules IPFW COUNT to 254 IPS from my network, one of my >> interfaces increases the latency, causing large delays in the >> network, when I delete COUNT rules, everything returns to normal, >> which can be ? >> >> My script: > > of course adding 512 rules, *all of which hav eto be evaluated* will > add latency. > > you have several ways to improve this situation. > > 1/ use a differnet tool. > By using the netgraph netflow module you can get > accunting information that may be more useful and less impactful. > > 2/ you could make your rules smarter.. > > use skipto rules to make the average packet traverse less rules.. > > off the top of my head.. (not tested..) > > Assuming you have machines 10.0.0.1-10.0.0.254.... > the rules below have an average packet traversing 19 rules and not 256 > for teh SYN packet and 2 rules for others.. > you may not be able to do the keep state trick if you use state for > other stuff but in that case worst case will still be 19 rules. > > 2 check-state > 5 skipto 10000 ip from not 10.0.0.0/24 to any > 10 skipto 2020 ip from not 10.0.0.0/25 to any # 0-128 > 20 skipto 1030 ip from not 10.0.0.0/26 to any # 0-64 > 30 skipto 240 ip from not 10.0.0.0/27 to any # 0-32 > 40 skipto 100 ip from not 10.0.0.0/28 to any # 0-16 > [16 count rules for 0-15] > 80 skipto 10000 ip from any to any > 100 [16 count rules for 16-31] keep-state > 140 skipto 10000 ip from any to any > 240 skipto 300 ip from not 10.0.0.32/28 > [16 rules for 32-47] keep-state > 280 skipto 10000 ip from any to any > 300 [16 count rules for 48-63] keep-state > 340 skipto 10000 ip from any to any > 1030 skipto 1240 ip from not 10.0.0.64/27 to any > 1040 skipto 1100 ip from not 10.0.0.64/28 to any > [16 count rules for 64-79] keep-state > 1080 skipto 10000 ip from any to any > 1100 [16 rules for 80-95] keep-state > 1140 skipto 10000 ip from any to any > 1240 skipto 1300 ip from not 10.0.0.96/28 to any > [16 count rules for 96-111] keep-state > 1280 skipto 10000 ip from any to any > 1300 [16 rules for 112-127] keep-state > 1340 skipto 10000 ip from any to any > 2020 skipto 3030 ip from not 10.0.0.128/26 to any > 2030 skipto 2240 ip from not 10.0.0.128/28 to any > [16 count rules for 128-143] keep-state > 2080 skipto 10000 ip from any to any > 2100 [16 rules for 144-159] keep-state > 2140 skipto 10000 ip from any to any > 2240 skipto 2300 ip from not 10.0.0.32/28 to any > [16 count rules for 160-175] keep-state > 2280 skipto 10000 ip from any to any > 2300 [16 count rules for 176-191] keep-state > 2340 skipto 10000 ip from any to any > 3030 skipto 3240 ip from not 10.0.0.192/27 to any > 3040 skipto 3100 ip from not 10.0.0.192/28 to any > [16 count rules for 192-207] keep-state > 3080 skipto 10000 ip from any to any > 3100 [16 rules for 208-223] keep-state > 3240 skipto 10000 ip from any to any > 3240 skipto 3300 ip from not 10.0.0.224/28 to any > [16 count rules for 224-239] keep-state > 3280 skipto 10000 ip from any to any > 3300 [16 count rules for 240-255] keep-state > 3340 skipto 10000 ip from any to any > > 10000 #other stuff > > in fact you could improve it further with: > 1/ either going down to a netmask of 29 (8 rules per set) > or > 2/ instead of having count rules make them skipto > so you would have: > 3300 skipto 10000 ip from 10.0.0.240 to any > 3301 skipto 10000 ip from 10.0.0.241 to any > 3302 skipto 10000 ip from 10.0.0.242 to any > 3303 skipto 10000 ip from 10.0.0.243 to any > 3304 skipto 10000 ip from 10.0.0.244 to any > 3305 skipto 10000 ip from 10.0.0.245 to any > 3306 skipto 10000 ip from 10.0.0.246 to any > 3307 skipto 10000 ip from 10.0.0.247 to any > 3308 skipto 10000 ip from 10.0.0.248 to any > 3309 skipto 10000 ip from 10.0.0.249 to any > 3310 skipto 10000 ip from 10.0.0.240 to any > 3311 skipto 10000 ip from 10.0.0.241 to any > 3312 skipto 10000 ip from 10.0.0.242 to any > 3313 skipto 10000 ip from 10.0.0.243 to any > 3314 skipto 10000 ip from 10.0.0.244 to any > 3315 skipto 10000 ip from 10.0.0.245 to any > > thus on average, a packet would traverse half the rules (8). > > 3/ both the above so on average they would traverse 4 rules plus one > extra skipto. > > you should be able to do the above in a script. > I'd love to see it.. > > (you can also do skipto tablearg in -current (maybe 7.2 too) > which may also be good.. (or not)) > > > julian > > > > _______________________________________________ > 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 wmoran at collaborativefusion.com Fri Apr 24 16:42:03 2009 From: wmoran at collaborativefusion.com (Bill Moran) Date: Fri Apr 24 16:42:15 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49F1DBAE.1080205@yan.com.br> References: <49F06985.1000303@yan.com.br> <49F0A7DD.30206@elischer.org> <49F1DBAE.1080205@yan.com.br> Message-ID: <20090424124202.951a82e1.wmoran@collaborativefusion.com> In response to Daniel Dias Gon?alves : > Very good thinking, congratulations, but my need is another. > The objective is a Captive Porrtal that each authentication is > dynamically created a rule to ALLOW or COUNT IP authenticated, which I'm > testing is what is the maximum capacity of rules supported, therefore > simultaneous user. > > Understand ? If you're only doing allow, then you'd be better off using a table, which has much better performance than a bunch of separate rules. If you're counting packets, I don't know if that approach will work or not. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. **************************************************************** From smithi at nimnet.asn.au Fri Apr 24 17:11:12 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Apr 24 17:11:19 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49F1D992.9000001@yan.com.br> References: <49F06985.1000303@yan.com.br> <49F08071.1070905@ibctech.ca> <49F1D992.9000001@yan.com.br> Message-ID: <20090425024635.O89549@sola.nimnet.asn.au> On Fri, 24 Apr 2009, Daniel Dias Gon?alves wrote: > The latency in the interface em6 increased an average of 10ms to 200 ~ 300ms > Hardware: > CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz 686-class CPU) > Logical CPUs per core: 2 > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0: on acpi0 > p4tcc0: on cpu0 > cpu1: on acpi0 > p4tcc1: on cpu1 > cpu2: on acpi0 > p4tcc2: on cpu2 > cpu3: on acpi0 > p4tcc3: on cpu3 > SMP: AP CPU #1 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #2 Launched! > > real memory = 9663676416 (9216 MB) > avail memory = 8396738560 (8007 MB) In that case, there really is something else wrong. By my measurements, rummaging through most of >1000 rules on a old 166MHz Pentium to get to the icmp allow rules (ridiculous, I know) added about 2ms to local net pings via that box, ie 1ms each pass for about 900 rules, mostly counts. cheers, Ian From Anatoliy.Poloz at onetelecom.od.ua Fri Apr 24 17:15:20 2009 From: Anatoliy.Poloz at onetelecom.od.ua (Anatoliy.Poloz) Date: Fri Apr 24 17:15:26 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <20090424124202.951a82e1.wmoran@collaborativefusion.com> References: <49F06985.1000303@yan.com.br> <49F0A7DD.30206@elischer.org> <49F1DBAE.1080205@yan.com.br> <20090424124202.951a82e1.wmoran@collaborativefusion.com> Message-ID: <49F1EFA4.7000107@onetelecom.od.ua> Bill Moran wrote: > In response to Daniel Dias Gon?alves : > >> Very good thinking, congratulations, but my need is another. >> The objective is a Captive Porrtal that each authentication is >> dynamically created a rule to ALLOW or COUNT IP authenticated, which I'm >> testing is what is the maximum capacity of rules supported, therefore >> simultaneous user. >> >> Understand ? > > If you're only doing allow, then you'd be better off using a table, > which has much better performance than a bunch of separate rules. > > If you're counting packets, I don't know if that approach will work > or not. > if u need to count ip traffic for all clients u can use sipmple and more performance rule set, like this one: LOCAL_NET=192.168.0.0/24 ipfw pipe 100 config bw 0 mask src-ip 0xffffffff ipfw pipe 100 config bw 0 mask dst-ip 0xffffffff ipfw add 100 pipe 100 ip from ${LOCAL_NET} to any out ipfw add 200 pipe 200 ip from any to ${LOCAL_NET} in From adrian at freebsd.org Fri Apr 24 17:31:16 2009 From: adrian at freebsd.org (Adrian Chadd) Date: Fri Apr 24 17:31:22 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49F06985.1000303@yan.com.br> References: <49F06985.1000303@yan.com.br> Message-ID: You'd almost certainly be better off hacking up an extension to ipfw which lets you count a /24 in one rule. As in, the count rule would match on the subnet/netmask, have 256 32 (or 64 bit) integers allocated to record traffic in, and then do an O(1) operation using the last octet of the v4 address to map it into this 256 slot array to update counters for. It'd require a little tool hackery to extend ipfw in userland/kernel space to do it but it would work and be (very almost) just as fast as a single rule. 2c, Adrian 2009/4/23 Daniel Dias Gon?alves : > Hi, > > My system is a FreeBSD 7.1R. > When I add rules IPFW COUNT to 254 IPS from my network, one of my interfaces > increases the latency, causing large delays in the network, when I delete > COUNT rules, everything returns to normal, which can be ? > > My script: > > ipcount.php > -- CUT -- > $c=0; > $a=50100; > for($x=0;$x<=0;$x++) { > ? ? ? for($y=1;$y<=254;$y++) { > ? ? ? ? ? ? ? $ip = "192.168.$x.$y"; > ? ? ? ? ? ? ? system("/sbin/ipfw -q add $a count { tcp or udp } from any to > $ip/32"); > ? ? ? ? ? ? ? system("/sbin/ipfw -q add $a count { tcp or udp } from $ip/32 > to any"); > ? ? ? ? ? ? ? #system("/sbin/ipfw delete $a"); > ? ? ? ? ? ? ? $c++; > ? ? ? ? ? ? ? $a++; > ? ? ? } > } > echo "\n\nTotal: $c\n"; > ?> > -- CUT -- > > net.inet.ip.fw.dyn_keepalive: 1 > net.inet.ip.fw.dyn_short_lifetime: 5 > net.inet.ip.fw.dyn_udp_lifetime: 10 > net.inet.ip.fw.dyn_rst_lifetime: 1 > net.inet.ip.fw.dyn_fin_lifetime: 1 > net.inet.ip.fw.dyn_syn_lifetime: 20 > net.inet.ip.fw.dyn_ack_lifetime: 300 > net.inet.ip.fw.static_count: 262 > net.inet.ip.fw.dyn_max: 10000 > net.inet.ip.fw.dyn_count: 0 > net.inet.ip.fw.curr_dyn_buckets: 256 > net.inet.ip.fw.dyn_buckets: 10000 > net.inet.ip.fw.default_rule: 65535 > net.inet.ip.fw.verbose_limit: 0 > net.inet.ip.fw.verbose: 1 > net.inet.ip.fw.debug: 0 > net.inet.ip.fw.one_pass: 1 > net.inet.ip.fw.autoinc_step: 100 > net.inet.ip.fw.enable: 1 > net.link.ether.ipfw: 1 > net.link.bridge.ipfw: 0 > net.link.bridge.ipfw_arp: 0 > > Thanks, > > Daniel > _______________________________________________ > 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 julian at elischer.org Fri Apr 24 21:58:16 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Apr 24 21:58:26 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49F1DBAE.1080205@yan.com.br> References: <49F06985.1000303@yan.com.br> <49F0A7DD.30206@elischer.org> <49F1DBAE.1080205@yan.com.br> Message-ID: <49F235F4.2030202@elischer.org> Daniel Dias Gon?alves wrote: > Very good thinking, congratulations, but my need is another. > The objective is a Captive Porrtal that each authentication is > dynamically created a rule to ALLOW or COUNT IP authenticated, which I'm > testing is what is the maximum capacity of rules supported, therefore > simultaneous user. > > Understand ? > I think so. do not add rules. have a single rule that looks in a table and add entries to the table when needed. > Thanks, > > Daniel > > Julian Elischer escreveu: >> Daniel Dias Gon?alves wrote: >>> Hi, >>> >>> My system is a FreeBSD 7.1R. >>> When I add rules IPFW COUNT to 254 IPS from my network, one of my >>> interfaces increases the latency, causing large delays in the >>> network, when I delete COUNT rules, everything returns to normal, >>> which can be ? >>> >>> My script: >> >> of course adding 512 rules, *all of which hav eto be evaluated* will >> add latency. >> >> you have several ways to improve this situation. >> >> 1/ use a differnet tool. >> By using the netgraph netflow module you can get >> accunting information that may be more useful and less impactful. >> >> 2/ you could make your rules smarter.. >> >> use skipto rules to make the average packet traverse less rules.. >> >> off the top of my head.. (not tested..) >> >> Assuming you have machines 10.0.0.1-10.0.0.254.... >> the rules below have an average packet traversing 19 rules and not 256 >> for teh SYN packet and 2 rules for others.. >> you may not be able to do the keep state trick if you use state for >> other stuff but in that case worst case will still be 19 rules. >> >> 2 check-state >> 5 skipto 10000 ip from not 10.0.0.0/24 to any >> 10 skipto 2020 ip from not 10.0.0.0/25 to any # 0-128 >> 20 skipto 1030 ip from not 10.0.0.0/26 to any # 0-64 >> 30 skipto 240 ip from not 10.0.0.0/27 to any # 0-32 >> 40 skipto 100 ip from not 10.0.0.0/28 to any # 0-16 >> [16 count rules for 0-15] >> 80 skipto 10000 ip from any to any >> 100 [16 count rules for 16-31] keep-state >> 140 skipto 10000 ip from any to any >> 240 skipto 300 ip from not 10.0.0.32/28 >> [16 rules for 32-47] keep-state >> 280 skipto 10000 ip from any to any >> 300 [16 count rules for 48-63] keep-state >> 340 skipto 10000 ip from any to any >> 1030 skipto 1240 ip from not 10.0.0.64/27 to any >> 1040 skipto 1100 ip from not 10.0.0.64/28 to any >> [16 count rules for 64-79] keep-state >> 1080 skipto 10000 ip from any to any >> 1100 [16 rules for 80-95] keep-state >> 1140 skipto 10000 ip from any to any >> 1240 skipto 1300 ip from not 10.0.0.96/28 to any >> [16 count rules for 96-111] keep-state >> 1280 skipto 10000 ip from any to any >> 1300 [16 rules for 112-127] keep-state >> 1340 skipto 10000 ip from any to any >> 2020 skipto 3030 ip from not 10.0.0.128/26 to any >> 2030 skipto 2240 ip from not 10.0.0.128/28 to any >> [16 count rules for 128-143] keep-state >> 2080 skipto 10000 ip from any to any >> 2100 [16 rules for 144-159] keep-state >> 2140 skipto 10000 ip from any to any >> 2240 skipto 2300 ip from not 10.0.0.32/28 to any >> [16 count rules for 160-175] keep-state >> 2280 skipto 10000 ip from any to any >> 2300 [16 count rules for 176-191] keep-state >> 2340 skipto 10000 ip from any to any >> 3030 skipto 3240 ip from not 10.0.0.192/27 to any >> 3040 skipto 3100 ip from not 10.0.0.192/28 to any >> [16 count rules for 192-207] keep-state >> 3080 skipto 10000 ip from any to any >> 3100 [16 rules for 208-223] keep-state >> 3240 skipto 10000 ip from any to any >> 3240 skipto 3300 ip from not 10.0.0.224/28 to any >> [16 count rules for 224-239] keep-state >> 3280 skipto 10000 ip from any to any >> 3300 [16 count rules for 240-255] keep-state >> 3340 skipto 10000 ip from any to any >> >> 10000 #other stuff >> >> in fact you could improve it further with: >> 1/ either going down to a netmask of 29 (8 rules per set) >> or >> 2/ instead of having count rules make them skipto >> so you would have: >> 3300 skipto 10000 ip from 10.0.0.240 to any >> 3301 skipto 10000 ip from 10.0.0.241 to any >> 3302 skipto 10000 ip from 10.0.0.242 to any >> 3303 skipto 10000 ip from 10.0.0.243 to any >> 3304 skipto 10000 ip from 10.0.0.244 to any >> 3305 skipto 10000 ip from 10.0.0.245 to any >> 3306 skipto 10000 ip from 10.0.0.246 to any >> 3307 skipto 10000 ip from 10.0.0.247 to any >> 3308 skipto 10000 ip from 10.0.0.248 to any >> 3309 skipto 10000 ip from 10.0.0.249 to any >> 3310 skipto 10000 ip from 10.0.0.240 to any >> 3311 skipto 10000 ip from 10.0.0.241 to any >> 3312 skipto 10000 ip from 10.0.0.242 to any >> 3313 skipto 10000 ip from 10.0.0.243 to any >> 3314 skipto 10000 ip from 10.0.0.244 to any >> 3315 skipto 10000 ip from 10.0.0.245 to any >> >> thus on average, a packet would traverse half the rules (8). >> >> 3/ both the above so on average they would traverse 4 rules plus one >> extra skipto. >> >> you should be able to do the above in a script. >> I'd love to see it.. >> >> (you can also do skipto tablearg in -current (maybe 7.2 too) >> which may also be good.. (or not)) >> >> >> julian >> >> >> >> _______________________________________________ >> 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 bugmaster at FreeBSD.org Mon Apr 27 11:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 27 11:08:19 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200904271106.n3RB6u70002321@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 ddg at yan.com.br Mon Apr 27 16:11:40 2009 From: ddg at yan.com.br (=?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?=) Date: Mon Apr 27 16:11:47 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49F235F4.2030202@elischer.org> References: <49F06985.1000303@yan.com.br> <49F0A7DD.30206@elischer.org> <49F1DBAE.1080205@yan.com.br> <49F235F4.2030202@elischer.org> Message-ID: <49F5D8A3.3050805@yan.com.br> Julian, You could give an example of rules with tables? Julian Elischer escreveu: > Daniel Dias Gon?alves wrote: >> Very good thinking, congratulations, but my need is another. >> The objective is a Captive Porrtal that each authentication is >> dynamically created a rule to ALLOW or COUNT IP authenticated, which >> I'm testing is what is the maximum capacity of rules supported, >> therefore simultaneous user. >> >> Understand ? >> > I think so. > > > do not add rules. > have a single rule that looks in a table > and add entries to the table when needed. > >> Thanks, >> >> Daniel >> >> Julian Elischer escreveu: >>> Daniel Dias Gon?alves wrote: >>>> Hi, >>>> >>>> My system is a FreeBSD 7.1R. >>>> When I add rules IPFW COUNT to 254 IPS from my network, one of my >>>> interfaces increases the latency, causing large delays in the >>>> network, when I delete COUNT rules, everything returns to normal, >>>> which can be ? >>>> >>>> My script: >>> >>> of course adding 512 rules, *all of which hav eto be evaluated* will >>> add latency. >>> >>> you have several ways to improve this situation. >>> >>> 1/ use a differnet tool. >>> By using the netgraph netflow module you can get >>> accunting information that may be more useful and less impactful. >>> >>> 2/ you could make your rules smarter.. >>> >>> use skipto rules to make the average packet traverse less rules.. >>> >>> off the top of my head.. (not tested..) >>> >>> Assuming you have machines 10.0.0.1-10.0.0.254.... >>> the rules below have an average packet traversing 19 rules and not >>> 256 for teh SYN packet and 2 rules for others.. >>> you may not be able to do the keep state trick if you use state for >>> other stuff but in that case worst case will still be 19 rules. >>> >>> 2 check-state >>> 5 skipto 10000 ip from not 10.0.0.0/24 to any >>> 10 skipto 2020 ip from not 10.0.0.0/25 to any # 0-128 >>> 20 skipto 1030 ip from not 10.0.0.0/26 to any # 0-64 >>> 30 skipto 240 ip from not 10.0.0.0/27 to any # 0-32 >>> 40 skipto 100 ip from not 10.0.0.0/28 to any # 0-16 >>> [16 count rules for 0-15] >>> 80 skipto 10000 ip from any to any >>> 100 [16 count rules for 16-31] keep-state >>> 140 skipto 10000 ip from any to any >>> 240 skipto 300 ip from not 10.0.0.32/28 >>> [16 rules for 32-47] keep-state >>> 280 skipto 10000 ip from any to any >>> 300 [16 count rules for 48-63] keep-state >>> 340 skipto 10000 ip from any to any >>> 1030 skipto 1240 ip from not 10.0.0.64/27 to any >>> 1040 skipto 1100 ip from not 10.0.0.64/28 to any >>> [16 count rules for 64-79] keep-state >>> 1080 skipto 10000 ip from any to any >>> 1100 [16 rules for 80-95] keep-state >>> 1140 skipto 10000 ip from any to any >>> 1240 skipto 1300 ip from not 10.0.0.96/28 to any >>> [16 count rules for 96-111] keep-state >>> 1280 skipto 10000 ip from any to any >>> 1300 [16 rules for 112-127] keep-state >>> 1340 skipto 10000 ip from any to any >>> 2020 skipto 3030 ip from not 10.0.0.128/26 to any >>> 2030 skipto 2240 ip from not 10.0.0.128/28 to any >>> [16 count rules for 128-143] keep-state >>> 2080 skipto 10000 ip from any to any >>> 2100 [16 rules for 144-159] keep-state >>> 2140 skipto 10000 ip from any to any >>> 2240 skipto 2300 ip from not 10.0.0.32/28 to any >>> [16 count rules for 160-175] keep-state >>> 2280 skipto 10000 ip from any to any >>> 2300 [16 count rules for 176-191] keep-state >>> 2340 skipto 10000 ip from any to any >>> 3030 skipto 3240 ip from not 10.0.0.192/27 to any >>> 3040 skipto 3100 ip from not 10.0.0.192/28 to any >>> [16 count rules for 192-207] keep-state >>> 3080 skipto 10000 ip from any to any >>> 3100 [16 rules for 208-223] keep-state >>> 3240 skipto 10000 ip from any to any >>> 3240 skipto 3300 ip from not 10.0.0.224/28 to any >>> [16 count rules for 224-239] keep-state >>> 3280 skipto 10000 ip from any to any >>> 3300 [16 count rules for 240-255] keep-state >>> 3340 skipto 10000 ip from any to any >>> >>> 10000 #other stuff >>> >>> in fact you could improve it further with: >>> 1/ either going down to a netmask of 29 (8 rules per set) >>> or >>> 2/ instead of having count rules make them skipto >>> so you would have: >>> 3300 skipto 10000 ip from 10.0.0.240 to any >>> 3301 skipto 10000 ip from 10.0.0.241 to any >>> 3302 skipto 10000 ip from 10.0.0.242 to any >>> 3303 skipto 10000 ip from 10.0.0.243 to any >>> 3304 skipto 10000 ip from 10.0.0.244 to any >>> 3305 skipto 10000 ip from 10.0.0.245 to any >>> 3306 skipto 10000 ip from 10.0.0.246 to any >>> 3307 skipto 10000 ip from 10.0.0.247 to any >>> 3308 skipto 10000 ip from 10.0.0.248 to any >>> 3309 skipto 10000 ip from 10.0.0.249 to any >>> 3310 skipto 10000 ip from 10.0.0.240 to any >>> 3311 skipto 10000 ip from 10.0.0.241 to any >>> 3312 skipto 10000 ip from 10.0.0.242 to any >>> 3313 skipto 10000 ip from 10.0.0.243 to any >>> 3314 skipto 10000 ip from 10.0.0.244 to any >>> 3315 skipto 10000 ip from 10.0.0.245 to any >>> >>> thus on average, a packet would traverse half the rules (8). >>> >>> 3/ both the above so on average they would traverse 4 rules plus >>> one extra skipto. >>> >>> you should be able to do the above in a script. >>> I'd love to see it.. >>> >>> (you can also do skipto tablearg in -current (maybe 7.2 too) >>> which may also be good.. (or not)) >>> >>> >>> julian >>> >>> >>> >>> _______________________________________________ >>> 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" >>> >>> > > _______________________________________________ > 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 ddg at yan.com.br Mon Apr 27 16:21:41 2009 From: ddg at yan.com.br (=?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?=) Date: Mon Apr 27 16:21:47 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <20090425024635.O89549@sola.nimnet.asn.au> References: <49F06985.1000303@yan.com.br> <49F08071.1070905@ibctech.ca> <49F1D992.9000001@yan.com.br> <20090425024635.O89549@sola.nimnet.asn.au> Message-ID: <49F5DB12.7080502@yan.com.br> What may be happening ? I'm with polling enabled on all interfaces, can you influence ? em0: port 0x7000-0x703f mem 0xdfa00000-0xdfa1ffff irq 16 at device 8.0 on pci4 em1: port 0x7400-0x743f mem 0xdfa20000-0xdfa3ffff irq 17 at device 8.1 on pci4 em2: port 0x8000-0x803f mem 0xdfb00000-0xdfb1ffff irq 16 at device 8.0 on pci5 em3: port 0x8400-0x843f mem 0xdfb20000-0xdfb3ffff irq 17 at device 8.1 on pci5 em4: port 0x9000-0x903f mem 0xdfc00000-0xdfc1ffff irq 16 at device 8.0 on pci7 em5: port 0x9400-0x943f mem 0xdfc20000-0xdfc3ffff irq 17 at device 8.1 on pci7 em6: port 0xa000-0xa03f mem 0xdfd00000-0xdfd1ffff irq 16 at device 8.0 on pci8 em7: port 0xa400-0xa43f mem 0xdfd20000-0xdfd3ffff irq 17 at device 8.1 on pci8 fxp0: port 0xb000-0xb03f mem 0xdfe20000-0xdfe20fff,0xdfe00000-0xdfe1ffff irq 16 at device 4.0 on pci14 If I disable the polling, no network interface work, begins to display "em4 watchdog timeout". Ian Smith escreveu: > On Fri, 24 Apr 2009, Daniel Dias Gon?alves wrote: > > > The latency in the interface em6 increased an average of 10ms to 200 ~ 300ms > > Hardware: > > CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz 686-class CPU) > > Logical CPUs per core: 2 > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > cpu0: on acpi0 > > p4tcc0: on cpu0 > > cpu1: on acpi0 > > p4tcc1: on cpu1 > > cpu2: on acpi0 > > p4tcc2: on cpu2 > > cpu3: on acpi0 > > p4tcc3: on cpu3 > > SMP: AP CPU #1 Launched! > > SMP: AP CPU #3 Launched! > > SMP: AP CPU #2 Launched! > > > > real memory = 9663676416 (9216 MB) > > avail memory = 8396738560 (8007 MB) > > In that case, there really is something else wrong. By my measurements, > rummaging through most of >1000 rules on a old 166MHz Pentium to get to > the icmp allow rules (ridiculous, I know) added about 2ms to local net > pings via that box, ie 1ms each pass for about 900 rules, mostly counts. > > cheers, Ian From ddg at yan.com.br Mon Apr 27 16:24:22 2009 From: ddg at yan.com.br (=?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?=) Date: Mon Apr 27 16:24:35 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: References: <49F06985.1000303@yan.com.br> Message-ID: <49F5DBB3.6030500@yan.com.br> Going to another example. If I wanted that each authentication (username and password) in captive portal, set up rules limiting the speed of the user's IP, as I do? I can create two rules for the in / out for each user associated with a pipe? When simulating this with a script adding hundreds of rules, the latency also increases, as resolve this ? Adrian Chadd escreveu: > You'd almost certainly be better off hacking up an extension to ipfw > which lets you count a /24 in one rule. > > As in, the count rule would match on the subnet/netmask, have 256 32 > (or 64 bit) integers allocated to record traffic in, and then do an > O(1) operation using the last octet of the v4 address to map it into > this 256 slot array to update counters for. > > It'd require a little tool hackery to extend ipfw in userland/kernel > space to do it but it would work and be (very almost) just as fast as > a single rule. > > 2c, > > > > Adrian > > 2009/4/23 Daniel Dias Gon?alves : > >> Hi, >> >> My system is a FreeBSD 7.1R. >> When I add rules IPFW COUNT to 254 IPS from my network, one of my interfaces >> increases the latency, causing large delays in the network, when I delete >> COUNT rules, everything returns to normal, which can be ? >> >> My script: >> >> ipcount.php >> -- CUT -- >> > $c=0; >> $a=50100; >> for($x=0;$x<=0;$x++) { >> for($y=1;$y<=254;$y++) { >> $ip = "192.168.$x.$y"; >> system("/sbin/ipfw -q add $a count { tcp or udp } from any to >> $ip/32"); >> system("/sbin/ipfw -q add $a count { tcp or udp } from $ip/32 >> to any"); >> #system("/sbin/ipfw delete $a"); >> $c++; >> $a++; >> } >> } >> echo "\n\nTotal: $c\n"; >> ?> >> -- CUT -- >> >> net.inet.ip.fw.dyn_keepalive: 1 >> net.inet.ip.fw.dyn_short_lifetime: 5 >> net.inet.ip.fw.dyn_udp_lifetime: 10 >> net.inet.ip.fw.dyn_rst_lifetime: 1 >> net.inet.ip.fw.dyn_fin_lifetime: 1 >> net.inet.ip.fw.dyn_syn_lifetime: 20 >> net.inet.ip.fw.dyn_ack_lifetime: 300 >> net.inet.ip.fw.static_count: 262 >> net.inet.ip.fw.dyn_max: 10000 >> net.inet.ip.fw.dyn_count: 0 >> net.inet.ip.fw.curr_dyn_buckets: 256 >> net.inet.ip.fw.dyn_buckets: 10000 >> net.inet.ip.fw.default_rule: 65535 >> net.inet.ip.fw.verbose_limit: 0 >> net.inet.ip.fw.verbose: 1 >> net.inet.ip.fw.debug: 0 >> net.inet.ip.fw.one_pass: 1 >> net.inet.ip.fw.autoinc_step: 100 >> net.inet.ip.fw.enable: 1 >> net.link.ether.ipfw: 1 >> net.link.bridge.ipfw: 0 >> net.link.bridge.ipfw_arp: 0 >> >> Thanks, >> >> Daniel >> _______________________________________________ >> 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" >> >> > _______________________________________________ > 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 adrian at freebsd.org Tue Apr 28 03:40:49 2009 From: adrian at freebsd.org (Adrian Chadd) Date: Tue Apr 28 03:40:56 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49F5DBB3.6030500@yan.com.br> References: <49F06985.1000303@yan.com.br> <49F5DBB3.6030500@yan.com.br> Message-ID: You may want to investigate using pf; i'm not sure whether they handle this better. Me, I'd investigate writing a "tree" ipfw rule type. Ie, instead of having a list of rules, all evaluated one at a time, I'd create a rule implementing a subrule match on ip/netmask with some kind of action (allow, deny, count, pipe, etc) rather than having it all be evaluated O(n) style. 2c, Adrian 2009/4/28 Daniel Dias Gon?alves : > Going to another example. > If I wanted that each authentication (username and password) in captive > portal, set up rules limiting the speed of the user's IP, as I do? I can > create two rules for the in / out for each user associated with a pipe? When > simulating this with a script adding hundreds of rules, the latency also > increases, as resolve this ? > > Adrian Chadd escreveu: >> >> You'd almost certainly be better off hacking up an extension to ipfw >> which lets you count a /24 in one rule. >> >> As in, the count rule would match on the subnet/netmask, have 256 32 >> (or 64 bit) integers allocated to record traffic in, and then do an >> O(1) operation using the last octet of the v4 address to map it into >> this 256 slot array to update counters for. >> >> It'd require a little tool hackery to extend ipfw in userland/kernel >> space to do it but it would work and be (very almost) just as fast as >> a single rule. >> >> 2c, >> >> >> >> Adrian >> >> 2009/4/23 Daniel Dias Gon?alves : >> >>> >>> Hi, >>> >>> My system is a FreeBSD 7.1R. >>> When I add rules IPFW COUNT to 254 IPS from my network, one of my >>> interfaces >>> increases the latency, causing large delays in the network, when I delete >>> COUNT rules, everything returns to normal, which can be ? >>> >>> My script: >>> >>> ipcount.php >>> -- CUT -- >>> >> $c=0; >>> $a=50100; >>> for($x=0;$x<=0;$x++) { >>> ? ? ?for($y=1;$y<=254;$y++) { >>> ? ? ? ? ? ? ?$ip = "192.168.$x.$y"; >>> ? ? ? ? ? ? ?system("/sbin/ipfw -q add $a count { tcp or udp } from any >>> to >>> $ip/32"); >>> ? ? ? ? ? ? ?system("/sbin/ipfw -q add $a count { tcp or udp } from >>> $ip/32 >>> to any"); >>> ? ? ? ? ? ? ?#system("/sbin/ipfw delete $a"); >>> ? ? ? ? ? ? ?$c++; >>> ? ? ? ? ? ? ?$a++; >>> ? ? ?} >>> } >>> echo "\n\nTotal: $c\n"; >>> ?> >>> -- CUT -- >>> >>> net.inet.ip.fw.dyn_keepalive: 1 >>> net.inet.ip.fw.dyn_short_lifetime: 5 >>> net.inet.ip.fw.dyn_udp_lifetime: 10 >>> net.inet.ip.fw.dyn_rst_lifetime: 1 >>> net.inet.ip.fw.dyn_fin_lifetime: 1 >>> net.inet.ip.fw.dyn_syn_lifetime: 20 >>> net.inet.ip.fw.dyn_ack_lifetime: 300 >>> net.inet.ip.fw.static_count: 262 >>> net.inet.ip.fw.dyn_max: 10000 >>> net.inet.ip.fw.dyn_count: 0 >>> net.inet.ip.fw.curr_dyn_buckets: 256 >>> net.inet.ip.fw.dyn_buckets: 10000 >>> net.inet.ip.fw.default_rule: 65535 >>> net.inet.ip.fw.verbose_limit: 0 >>> net.inet.ip.fw.verbose: 1 >>> net.inet.ip.fw.debug: 0 >>> net.inet.ip.fw.one_pass: 1 >>> net.inet.ip.fw.autoinc_step: 100 >>> net.inet.ip.fw.enable: 1 >>> net.link.ether.ipfw: 1 >>> net.link.bridge.ipfw: 0 >>> net.link.bridge.ipfw_arp: 0 >>> >>> Thanks, >>> >>> Daniel >>> _______________________________________________ >>> 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" >>> >>> >> >> _______________________________________________ >> 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" >> >> >> > > _______________________________________________ > 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 smithi at nimnet.asn.au Tue Apr 28 04:33:41 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue Apr 28 04:33:48 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49F5DB12.7080502@yan.com.br> References: <49F06985.1000303@yan.com.br> <49F08071.1070905@ibctech.ca> <49F1D992.9000001@yan.com.br> <20090425024635.O89549@sola.nimnet.asn.au> <49F5DB12.7080502@yan.com.br> Message-ID: <20090428135053.Y89549@sola.nimnet.asn.au> On Mon, 27 Apr 2009, Daniel Dias Gon?alves wrote: > What may be happening ? I'm with polling enabled on all interfaces, can you > influence ? > > em0: port 0x7000-0x703f mem > 0xdfa00000-0xdfa1ffff irq 16 at device 8.0 on pci4 > em1: port 0x7400-0x743f mem > 0xdfa20000-0xdfa3ffff irq 17 at device 8.1 on pci4 > em2: port 0x8000-0x803f mem > 0xdfb00000-0xdfb1ffff irq 16 at device 8.0 on pci5 > em3: port 0x8400-0x843f mem > 0xdfb20000-0xdfb3ffff irq 17 at device 8.1 on pci5 > em4: port 0x9000-0x903f mem > 0xdfc00000-0xdfc1ffff irq 16 at device 8.0 on pci7 > em5: port 0x9400-0x943f mem > 0xdfc20000-0xdfc3ffff irq 17 at device 8.1 on pci7 > em6: port 0xa000-0xa03f mem > 0xdfd00000-0xdfd1ffff irq 16 at device 8.0 on pci8 > em7: port 0xa400-0xa43f mem > 0xdfd20000-0xdfd3ffff irq 17 at device 8.1 on pci8 > fxp0: port 0xb000-0xb03f mem > 0xdfe20000-0xdfe20fff,0xdfe00000-0xdfe1ffff irq 16 at device 4.0 on pci14 > > If I disable the polling, no network interface work, begins to display "em4 > watchdog timeout". Sorry, no ideas about polling, but this doesn't smell like just an IPFW issue. I was pointing out that despite 20 times the CPU clock rate, probably at least 30 times CPU throughput and likely 10 times the tick rate, you appear to be suffering something like 30 to 900 times the increased latency to be expected by traversing 'too many' ipfw rules. > Ian Smith escreveu: > > On Fri, 24 Apr 2009, Daniel Dias Gon?alves wrote: > > > > > The latency in the interface em6 increased an average of 10ms to 200 ~ > > 300ms > > > Hardware: > > > CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz 686-class CPU) > > > Logical CPUs per core: 2 > > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > > cpu0: on acpi0 > > > p4tcc0: on cpu0 > > > cpu1: on acpi0 > > > p4tcc1: on cpu1 > > > cpu2: on acpi0 > > > p4tcc2: on cpu2 > > > cpu3: on acpi0 > > > p4tcc3: on cpu3 > > > SMP: AP CPU #1 Launched! > > > SMP: AP CPU #3 Launched! > > > SMP: AP CPU #2 Launched! > > > > real memory = 9663676416 (9216 MB) > > > avail memory = 8396738560 (8007 MB) > > > > In that case, there really is something else wrong. By my measurements, > > rummaging through most of >1000 rules on a old 166MHz Pentium to get to the > > icmp allow rules (ridiculous, I know) added about 2ms to local net pings > > via that box, ie 1ms each pass for about 900 rules, mostly counts. cheers, Ian From julian at elischer.org Tue Apr 28 06:51:59 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Apr 28 06:52:06 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49F5D8A3.3050805@yan.com.br> References: <49F06985.1000303@yan.com.br> <49F0A7DD.30206@elischer.org> <49F1DBAE.1080205@yan.com.br> <49F235F4.2030202@elischer.org> <49F5D8A3.3050805@yan.com.br> Message-ID: <49F6A796.4060100@elischer.org> Daniel Dias Gon?alves wrote: > Julian, > > You could give an example of rules with tables? I'm sorry I forgot that you want to count packets from each client. tables won't work for that. for counting I suggest the technique I show below, but for just allowing, you can add allowable addresses to a table, e.g. table 1 add 1.2.3.4 and test it with allow ip from table (1) to any > > Julian Elischer escreveu: >> Daniel Dias Gon?alves wrote: >>> Very good thinking, congratulations, but my need is another. >>> The objective is a Captive Porrtal that each authentication is >>> dynamically created a rule to ALLOW or COUNT IP authenticated, which >>> I'm testing is what is the maximum capacity of rules supported, >>> therefore simultaneous user. >>> >>> Understand ? >>> >> I think so. >> >> >> do not add rules. >> have a single rule that looks in a table >> and add entries to the table when needed. >> >>> Thanks, >>> >>> Daniel >>> >>> Julian Elischer escreveu: >>>> Daniel Dias Gon?alves wrote: >>>>> Hi, >>>>> >>>>> My system is a FreeBSD 7.1R. >>>>> When I add rules IPFW COUNT to 254 IPS from my network, one of my >>>>> interfaces increases the latency, causing large delays in the >>>>> network, when I delete COUNT rules, everything returns to normal, >>>>> which can be ? >>>>> >>>>> My script: >>>> >>>> of course adding 512 rules, *all of which hav eto be evaluated* will >>>> add latency. >>>> >>>> you have several ways to improve this situation. >>>> >>>> 1/ use a differnet tool. >>>> By using the netgraph netflow module you can get >>>> accunting information that may be more useful and less impactful. >>>> >>>> 2/ you could make your rules smarter.. >>>> >>>> use skipto rules to make the average packet traverse less rules.. >>>> >>>> off the top of my head.. (not tested..) >>>> >>>> Assuming you have machines 10.0.0.1-10.0.0.254.... >>>> the rules below have an average packet traversing 19 rules and not >>>> 256 for teh SYN packet and 2 rules for others.. >>>> you may not be able to do the keep state trick if you use state for >>>> other stuff but in that case worst case will still be 19 rules. >>>> >>>> 2 check-state >>>> 5 skipto 10000 ip from not 10.0.0.0/24 to any >>>> 10 skipto 2020 ip from not 10.0.0.0/25 to any # 0-128 >>>> 20 skipto 1030 ip from not 10.0.0.0/26 to any # 0-64 >>>> 30 skipto 240 ip from not 10.0.0.0/27 to any # 0-32 >>>> 40 skipto 100 ip from not 10.0.0.0/28 to any # 0-16 >>>> [16 count rules for 0-15] >>>> 80 skipto 10000 ip from any to any >>>> 100 [16 count rules for 16-31] keep-state >>>> 140 skipto 10000 ip from any to any >>>> 240 skipto 300 ip from not 10.0.0.32/28 >>>> [16 rules for 32-47] keep-state >>>> 280 skipto 10000 ip from any to any >>>> 300 [16 count rules for 48-63] keep-state >>>> 340 skipto 10000 ip from any to any >>>> 1030 skipto 1240 ip from not 10.0.0.64/27 to any >>>> 1040 skipto 1100 ip from not 10.0.0.64/28 to any >>>> [16 count rules for 64-79] keep-state >>>> 1080 skipto 10000 ip from any to any >>>> 1100 [16 rules for 80-95] keep-state >>>> 1140 skipto 10000 ip from any to any >>>> 1240 skipto 1300 ip from not 10.0.0.96/28 to any >>>> [16 count rules for 96-111] keep-state >>>> 1280 skipto 10000 ip from any to any >>>> 1300 [16 rules for 112-127] keep-state >>>> 1340 skipto 10000 ip from any to any >>>> 2020 skipto 3030 ip from not 10.0.0.128/26 to any >>>> 2030 skipto 2240 ip from not 10.0.0.128/28 to any >>>> [16 count rules for 128-143] keep-state >>>> 2080 skipto 10000 ip from any to any >>>> 2100 [16 rules for 144-159] keep-state >>>> 2140 skipto 10000 ip from any to any >>>> 2240 skipto 2300 ip from not 10.0.0.32/28 to any >>>> [16 count rules for 160-175] keep-state >>>> 2280 skipto 10000 ip from any to any >>>> 2300 [16 count rules for 176-191] keep-state >>>> 2340 skipto 10000 ip from any to any >>>> 3030 skipto 3240 ip from not 10.0.0.192/27 to any >>>> 3040 skipto 3100 ip from not 10.0.0.192/28 to any >>>> [16 count rules for 192-207] keep-state >>>> 3080 skipto 10000 ip from any to any >>>> 3100 [16 rules for 208-223] keep-state >>>> 3240 skipto 10000 ip from any to any >>>> 3240 skipto 3300 ip from not 10.0.0.224/28 to any >>>> [16 count rules for 224-239] keep-state >>>> 3280 skipto 10000 ip from any to any >>>> 3300 [16 count rules for 240-255] keep-state >>>> 3340 skipto 10000 ip from any to any >>>> >>>> 10000 #other stuff >>>> >>>> in fact you could improve it further with: >>>> 1/ either going down to a netmask of 29 (8 rules per set) >>>> or >>>> 2/ instead of having count rules make them skipto >>>> so you would have: >>>> 3300 skipto 10000 ip from 10.0.0.240 to any >>>> 3301 skipto 10000 ip from 10.0.0.241 to any >>>> 3302 skipto 10000 ip from 10.0.0.242 to any >>>> 3303 skipto 10000 ip from 10.0.0.243 to any >>>> 3304 skipto 10000 ip from 10.0.0.244 to any >>>> 3305 skipto 10000 ip from 10.0.0.245 to any >>>> 3306 skipto 10000 ip from 10.0.0.246 to any >>>> 3307 skipto 10000 ip from 10.0.0.247 to any >>>> 3308 skipto 10000 ip from 10.0.0.248 to any >>>> 3309 skipto 10000 ip from 10.0.0.249 to any >>>> 3310 skipto 10000 ip from 10.0.0.240 to any >>>> 3311 skipto 10000 ip from 10.0.0.241 to any >>>> 3312 skipto 10000 ip from 10.0.0.242 to any >>>> 3313 skipto 10000 ip from 10.0.0.243 to any >>>> 3314 skipto 10000 ip from 10.0.0.244 to any >>>> 3315 skipto 10000 ip from 10.0.0.245 to any >>>> >>>> thus on average, a packet would traverse half the rules (8). >>>> >>>> 3/ both the above so on average they would traverse 4 rules plus >>>> one extra skipto. >>>> >>>> you should be able to do the above in a script. >>>> I'd love to see it.. >>>> >>>> (you can also do skipto tablearg in -current (maybe 7.2 too) >>>> which may also be good.. (or not)) >>>> >>>> >>>> julian >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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" >>>> >>>> >> >> _______________________________________________ >> 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" >> >>