From julian at elischer.org Fri Aug 1 02:02:45 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Aug 1 02:02:51 2008 Subject: ipfw add skipto tablearg.... Message-ID: <48926C02.6030308@elischer.org> looking int he code I noticed that the following command gave no error but didn't work.. ipfw add 1000 skipto tablearg ip from any to table(31) and as I have a use for that, I implemented it.. see attached patch... (hopefully not stripped) Of course it is hoped that the rules you are skipping to are nearby as it iterates through the rules following the skipto to find the target, but.... if you had a thousand table entries and wanted to sort them into 20 buckets, it could save you puting them into 20 different tables and doing 20 table lookups on them. here I sort into two categories.. possibly already a win.. julian@trafmon2:cat ipfw-test.sh #!/bin/sh ipfw add 100 skipto 10000 ip from any to not 1.1.1.0/24 ipfw add 1000 skipto tablearg ip from any to "table(31)" ipfw add 2000 drop ip from any to any ipfw add 2001 drop ip from any to any ipfw add 3000 drop ip from any to any ipfw add 3001 drop ip from any to any ipfw add 10000 count ip from any to any ipfw table 31 add 1.1.1.1 2000 ipfw table 31 add 1.1.1.2 3000 julian@trafmon2: ping 1.1.1.1 [...] (2 packets bounced) julian@trafmon2: ping 1.1.1.2 [...] (12 packets bounced) julian@trafmon2: ipfw show 00100 220 19633 skipto 10000 ip from any to not 1.1.1.0/24 01000 14 1176 skipto tablearg ip from any to table(31) 02000 2 168 deny ip from any to any 02001 0 0 deny ip from any to any 03000 12 1008 deny ip from any to any 03001 0 0 deny ip from any to any 10000 209 18549 count ip from any to any 65535 1751 153792 allow ip from any to any comments? -------------- next part -------------- Index: ip_fw2.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/netinet/ip_fw2.c,v retrieving revision 1.186 diff -u -r1.186 ip_fw2.c --- ip_fw2.c 9 May 2008 23:02:57 -0000 1.186 +++ ip_fw2.c 1 Aug 2008 01:15:06 -0000 @@ -1738,10 +1738,11 @@ */ static struct ip_fw * -lookup_next_rule(struct ip_fw *me) +lookup_next_rule(struct ip_fw *me, u_int32_t tablearg) { struct ip_fw *rule = NULL; ipfw_insn *cmd; + u_int16_t rulenum; /* look for action, in case it is a skipto */ cmd = ACTION_PTR(me); @@ -1751,10 +1752,18 @@ cmd += F_LEN(cmd); if (cmd->opcode == O_TAG) cmd += F_LEN(cmd); - if ( cmd->opcode == O_SKIPTO ) - for (rule = me->next; rule ; rule = rule->next) - if (rule->rulenum >= cmd->arg1) + if (cmd->opcode == O_SKIPTO ) { + if (tablearg != 0) { + rulenum = (u_int16_t)tablearg; + } else { + rulenum = cmd->arg1; + } + for (rule = me->next; rule ; rule = rule->next) { + if (rule->rulenum >= rulenum) { break; + } + } + } if (rule == NULL) /* failure or not a skipto */ rule = me->next; me->next_rule = rule; @@ -2475,7 +2484,7 @@ f = args->rule->next_rule; if (f == NULL) - f = lookup_next_rule(args->rule); + f = lookup_next_rule(args->rule, 0); } else { /* * Find the starting rule. It can be either the first @@ -3226,9 +3235,13 @@ if (cmd->opcode == O_COUNT) goto next_rule; /* handle skipto */ - if (f->next_rule == NULL) - lookup_next_rule(f); - f = f->next_rule; + if (cmd->arg1 == IP_FW_TABLEARG) { + f = lookup_next_rule(f, tablearg); + } else { + if (f->next_rule == NULL) + lookup_next_rule(f, 0); + f = f->next_rule; + } goto again; case O_REJECT: From bugmaster at FreeBSD.org Mon Aug 4 11:06:57 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 4 11:07:59 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200808041106.m74B6ugs082093@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit 30 problems total. From matt at chronos.org.uk Tue Aug 5 14:33:10 2008 From: matt at chronos.org.uk (Matt Dawson) Date: Tue Aug 5 14:33:17 2008 Subject: IPv6 tables? Message-ID: <200808051533.05352.matt@chronos.org.uk> Just a quick question: What would it take to have similar functionality to the IPv4 tables in ipfw for v6? Is there a specific reason it isn't there (other than the fact that I haven't got my finger out and learnt the neccessary to add it myself ;) )? -- Matt Dawson. matt@chronos.org.uk MTD15-RIPE From max at love2party.net Tue Aug 5 14:55:04 2008 From: max at love2party.net (Max Laier) Date: Tue Aug 5 14:55:10 2008 Subject: IPv6 tables? In-Reply-To: <200808051533.05352.matt@chronos.org.uk> References: <200808051533.05352.matt@chronos.org.uk> Message-ID: <200808051642.25758.max@love2party.net> On Tuesday 05 August 2008 16:33:04 Matt Dawson wrote: > Just a quick question: What would it take to have similar functionality to > the IPv4 tables in ipfw for v6? Is there a specific reason it isn't there > (other than the fact that I haven't got my finger out and learnt the > neccessary to add it myself ;) )? In FreeBSD 7 and above all three firewall packages included with FreeBSD understand both IPv4 and IPv6. Read the ipfw(8) man page for details on how to setup IPv6 rules. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From max at love2party.net Tue Aug 5 14:56:17 2008 From: max at love2party.net (Max Laier) Date: Tue Aug 5 14:56:24 2008 Subject: IPv6 tables? In-Reply-To: <200808051642.25758.max@love2party.net> References: <200808051533.05352.matt@chronos.org.uk> <200808051642.25758.max@love2party.net> Message-ID: <200808051643.41441.max@love2party.net> On Tuesday 05 August 2008 16:42:25 Max Laier wrote: > On Tuesday 05 August 2008 16:33:04 Matt Dawson wrote: > > Just a quick question: What would it take to have similar functionality > > to the IPv4 tables in ipfw for v6? Is there a specific reason it isn't > > there (other than the fact that I haven't got my finger out and learnt > > the neccessary to add it myself ;) )? > > In FreeBSD 7 and above all three firewall packages included with FreeBSD > understand both IPv4 and IPv6. Read the ipfw(8) man page for details on > how to setup IPv6 rules. Oh wait ... you asked something different. Yeah, that would be nice to have. pf does it. If you need a reference. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From proks at logos.sky.od.ua Tue Aug 5 16:11:57 2008 From: proks at logos.sky.od.ua (Prokofiev S.P.) Date: Tue Aug 5 16:12:04 2008 Subject: ipfw nat/natd Message-ID: <20080805191040.N31591@logos.sky.od.ua> I have a problem at the scheme: ( gw ) <-----> ( nat_router ) <-----> ( https ) real.ip0 real.ip1 10.19.90.1 10.19.90.2 If I use ipfw+natd on nat_router then redirect to https server and to nat_router local address 10.19.90.1 is well, but if ipfw+nat - redirect to nat_router local address is fail. This is bug ? ipfw+nat schema - on nat_router - ipfw rules ipfw nat 1 config if vlan2 log redirect_port tcp 10.19.90.1:5000 5000 \ redirect_port tcp 10.19.90.2:443 443 ipfw add 500 nat 1 log ip from any to any via vlan2 // nat - iperf -s -p 5000 - on gw - iperf -p 5000 -c real.ip1 tcpdump -np -i vlan2 host real.ip0 18:36:08.170034 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:08.170093 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:11.170239 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:11.208523 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:11.208554 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:14.208712 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:14.448772 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:14.448802 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:17.449225 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:17.689771 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:17.689801 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:20.689736 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:20.944763 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:20.944794 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:23.945252 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 Thanks all! From proks at logos.sky.od.ua Tue Aug 5 16:15:27 2008 From: proks at logos.sky.od.ua (Prokofiev S.P.) Date: Tue Aug 5 16:15:33 2008 Subject: ipfw nat/natd Message-ID: <20080805181839.T23842@logos.sky.od.ua> I have a problem at the scheme: ( gw ) <-----> ( nat_router ) <-----> ( https ) real.ip0 real.ip1 10.19.90.1 10.19.90.2 If I use ipfw+natd on nat_router then redirect to https server and to nat_router local address 10.19.90.1 is well, but if ipfw+nat - redirect to nat_router local address is fail. This is bug ? ipfw+nat schema - on nat_router - ipfw rules ipfw nat 1 config if vlan2 log redirect_port tcp 10.19.90.1:5000 5000 \ redirect_port tcp 10.19.90.2:443 443 ipfw add 500 nat 1 log ip from any to any via vlan2 // nat - iperf -s -p 5000 - on gw - iperf -p 5000 -c real.ip1 tcpdump -np -i vlan2 host real.ip0 18:36:08.170034 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:08.170093 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:11.170239 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:11.208523 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:11.208554 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:14.208712 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:14.448772 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:14.448802 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:17.449225 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:17.689771 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:17.689801 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:20.689736 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:20.944763 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:20.944794 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:23.945252 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 Thanks all! From julian at elischer.org Tue Aug 5 18:28:25 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 5 18:28:31 2008 Subject: IPv6 tables? In-Reply-To: <200808051533.05352.matt@chronos.org.uk> References: <200808051533.05352.matt@chronos.org.uk> Message-ID: <48989BC9.4070504@elischer.org> Matt Dawson wrote: > Just a quick question: What would it take to have similar functionality to the > IPv4 tables in ipfw for v6? Is there a specific reason it isn't there (other > than the fact that I haven't got my finger out and learnt the neccessary to > add it myself ;) )? there is no reason except that is hasn't been done :-) From matt at chronos.org.uk Wed Aug 6 14:41:44 2008 From: matt at chronos.org.uk (Matt Dawson) Date: Wed Aug 6 14:41:52 2008 Subject: IPv6 tables? In-Reply-To: <20080806120017.1D3921065744@hub.freebsd.org> References: <20080806120017.1D3921065744@hub.freebsd.org> Message-ID: <200808061541.39381.matt@chronos.org.uk> On Wednesday 06 Aug 2008, freebsd-ipfw-request@freebsd.org wrote: > On Tuesday 05 August 2008 16:42:25 Max Laier wrote: > > On Tuesday 05 August 2008 16:33:04 Matt Dawson wrote: > > > Just a quick question: What would it take to have similar functionality > > > to the IPv4 tables in ipfw for v6? Is there a specific reason it isn't > > > there (other than the fact that I haven't got my finger out and learnt > > > the neccessary to add it myself ;) )? > > > > In FreeBSD 7 and above all three firewall packages included with FreeBSD > > understand both IPv4 and IPv6. ?Read the ipfw(8) man page for details on > > how to setup IPv6 rules. > > Oh wait ... you asked something different. ?Yeah, that would be nice to > have. ? pf does it. ?If you need a reference. I did notice pf had tables that can handle both v4 and v6. I hadn't thought of reading pf's code to see how it's done, although pf's tables seem to handle handle both versions (without looking at the code, just the manpage). I'm now wondering which approach would be less resource-hungry: Adding a separate "table6" structure or modifying tables to accept v6. The former, to my mind, is more economical with large tables. Thanks to you and Julian for the replies. Looks like I have some code and things to read through. -- Matt Dawson. matt@chronos.org.uk MTD15-RIPE From julian at elischer.org Wed Aug 6 17:11:58 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Aug 6 17:12:08 2008 Subject: IPv6 tables? In-Reply-To: <200808061541.39381.matt@chronos.org.uk> References: <20080806120017.1D3921065744@hub.freebsd.org> <200808061541.39381.matt@chronos.org.uk> Message-ID: <4899DB5D.7030902@elischer.org> Matt Dawson wrote: > On Wednesday 06 Aug 2008, freebsd-ipfw-request@freebsd.org wrote: >> On Tuesday 05 August 2008 16:42:25 Max Laier wrote: >>> On Tuesday 05 August 2008 16:33:04 Matt Dawson wrote: >>>> Just a quick question: What would it take to have similar functionality >>>> to the IPv4 tables in ipfw for v6? Is there a specific reason it isn't >>>> there (other than the fact that I haven't got my finger out and learnt >>>> the neccessary to add it myself ;) )? >>> In FreeBSD 7 and above all three firewall packages included with FreeBSD >>> understand both IPv4 and IPv6. Read the ipfw(8) man page for details on >>> how to setup IPv6 rules. >> Oh wait ... you asked something different. Yeah, that would be nice to >> have. pf does it. If you need a reference. > > I did notice pf had tables that can handle both v4 and v6. I hadn't thought of > reading pf's code to see how it's done, although pf's tables seem to handle > handle both versions (without looking at the code, just the manpage). I'm > now wondering which approach would be less resource-hungry: Adding a > separate "table6" structure or modifying tables to accept v6. The former, to > my mind, is more economical with large tables. > > Thanks to you and Julian for the replies. Looks like I have some code and > things to read through. I think I'd go for a single table structure, that only instantiates the ipv4 or ipv6 table part of itself when you add anentry of that type.. then when you do a compare, it only looks in the apropriate half.. Since you always know which you have... but it would be note to be able do a test against both types with one ipfw rule. From info at tecodryer.com Wed Aug 6 21:20:41 2008 From: info at tecodryer.com (TECO DRYER) Date: Wed Aug 6 21:20:53 2008 Subject: Teco Industry is in the business of corn, wheat, paddy, and Message-ID: <20080806212041.056F78FC08@mx1.freebsd.org> vegetable dr Sender: "TECO DRYER" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Thu, 7 Aug 2008 00:12:23 +0300 Message-ID: <20080806211223192.57EB19BE79843444@erkan-e90bf8060> X-Priority: 3 (Normal) Importance: Normal Teco Industry is in the business of corn, wheat, paddy, and vegetable drying machines and the production and marketing of silo & steel construction. Related to the machines that our company produce; Teco Industry has the representatives in Bulgaria, Albania, Ukraine, Tatarstan, Kazakhstan, Russia, Angola and Indonesia. Our partners in these countries are accepted as the leaders in the steel industry. The quality of produced machines is approved by international standards. Teco is guaranteed by CE and ISO 9001-2000 certificates. Teco also contributes to the national economy by creating jobs in designing, project, production, import and export. Teco materializes R&D activities with its professional staff. Quality results are presented to the customers during the production, import and export. Our company takes the leadership of producing and marketing nationally and internationally. For Grain, Oily Seeds, and Pulses: Silos Corn and Soybean Drying Machines Handling Systems like Bucket Elevator, Chain Conveyor and Helix Prop Towers and Catwalks for Handling Systems Unloading Truck Lifts Industrial Foundations, Steel Construction With the expert staff; we take an important target like ‘’Customer Satisfaction and Service Quality’’ and perform service and counseling duties successfully. -------------------------------------------------------------------------------- Contact Us , Teco Dryer Company is ready for a long partnership with you. Sales Engineer Erkan AYMAN eayman@tecodryer.com From bugmaster at FreeBSD.org Mon Aug 11 11:06:59 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 11 11:07:57 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200808111106.m7BB6wMa047220@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit 30 problems total. From fportnoy at mail.plymouth.edu Mon Aug 11 20:47:30 2008 From: fportnoy at mail.plymouth.edu (Fred Portnoy) Date: Mon Aug 11 20:47:36 2008 Subject: ipv4 diffserv entry Message-ID: <142385261.269891218486614044.JavaMail.root@cygnus.plymouth.edu> By using Sniffer and tcpdump together, it appears that the entry in the "TOS" field of the IPv4 header is getting stripped off as the packet leaves the external facing interface of the firewall. Is this known behavior? Is there a way to preserve the TOS? thanks -fp Fred Portnoy Network Analyst Plymouth State University "unfettered by edgy modernisms, or classical influences" From ady at freebsd.ady.ro Tue Aug 12 11:48:27 2008 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Tue Aug 12 11:48:34 2008 Subject: ipv4 diffserv entry In-Reply-To: <142385261.269891218486614044.JavaMail.root@cygnus.plymouth.edu> References: <142385261.269891218486614044.JavaMail.root@cygnus.plymouth.edu> Message-ID: <78cb3d3f0808120421i334c483fm7aecddd30aed22d@mail.gmail.com> Hi, On Mon, Aug 11, 2008 at 10:30 PM, Fred Portnoy wrote: > By using Sniffer and tcpdump together, it appears that the entry in the "TOS" field of the IPv4 header is getting stripped off as the packet leaves the external facing interface of the firewall. Is this known behavior? Is there a way to preserve the TOS? Which firewall framework are we talking about (ipfw / pf / ipf) ? Does it reproduce with all/other firewalls ? If you completely disable the firewall, does the issue stop reproducing ? Regards, Adrian. From fportnoy at mail.plymouth.edu Tue Aug 12 12:22:29 2008 From: fportnoy at mail.plymouth.edu (Fred Portnoy) Date: Tue Aug 12 12:22:36 2008 Subject: ipv4 diffserv entry In-Reply-To: <1837587044.311191218543618034.JavaMail.root@cygnus.plymouth.edu> Message-ID: <666535032.311481218543743824.JavaMail.root@cygnus.plymouth.edu> First question, ipfw on FreeBSD 5.4-RELEASE. Other questions are more difficult, since we're dealing with a production network.... thanks Fred Portnoy Network Analyst Plymouth State University "unfettered by edgy modernisms, or classical influences" ----- Original Message ----- From: "Adrian Penisoara" To: "Fred Portnoy" Cc: "freebsd-ipfw" Sent: Tuesday, August 12, 2008 7:21:45 AM GMT -05:00 US/Canada Eastern Subject: Re: ipv4 diffserv entry Hi, On Mon, Aug 11, 2008 at 10:30 PM, Fred Portnoy wrote: > By using Sniffer and tcpdump together, it appears that the entry in the "TOS" field of the IPv4 header is getting stripped off as the packet leaves the external facing interface of the firewall. Is this known behavior? Is there a way to preserve the TOS? Which firewall framework are we talking about (ipfw / pf / ipf) ? Does it reproduce with all/other firewalls ? If you completely disable the firewall, does the issue stop reproducing ? Regards, Adrian. From ady at freebsd.ady.ro Tue Aug 12 12:29:27 2008 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Tue Aug 12 12:29:41 2008 Subject: ipv4 diffserv entry In-Reply-To: <666535032.311481218543743824.JavaMail.root@cygnus.plymouth.edu> References: <1837587044.311191218543618034.JavaMail.root@cygnus.plymouth.edu> <666535032.311481218543743824.JavaMail.root@cygnus.plymouth.edu> Message-ID: <78cb3d3f0808120529i29408660v43b6430179b4fd47@mail.gmail.com> Hi, On Tue, Aug 12, 2008 at 2:22 PM, Fred Portnoy wrote: > First question, ipfw on FreeBSD 5.4-RELEASE. Other questions are more difficult, since we're dealing with a production network.... Are you able to setup a test environment with the same FreeBSD release and configuration and to reproduce the issue ? It would be a good start to make these tests. Regards, Adrian. > > thanks > > Fred Portnoy > Network Analyst > Plymouth State University > > "unfettered by edgy modernisms, or classical influences" > > ----- Original Message ----- > From: "Adrian Penisoara" > To: "Fred Portnoy" > Cc: "freebsd-ipfw" > Sent: Tuesday, August 12, 2008 7:21:45 AM GMT -05:00 US/Canada Eastern > Subject: Re: ipv4 diffserv entry > > Hi, > > On Mon, Aug 11, 2008 at 10:30 PM, Fred Portnoy > wrote: >> By using Sniffer and tcpdump together, it appears that the entry in the "TOS" field of the IPv4 header is getting stripped off as the packet leaves the external facing interface of the firewall. Is this known behavior? Is there a way to preserve the TOS? > > Which firewall framework are we talking about (ipfw / pf / ipf) ? > Does it reproduce with all/other firewalls ? > If you completely disable the firewall, does the issue stop reproducing ? > > Regards, > Adrian. > From bugmaster at FreeBSD.org Mon Aug 18 11:06:51 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 18 11:07:57 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200808181106.m7IB6pkU079834@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit 30 problems total. From smithi at nimnet.asn.au Tue Aug 19 13:22:29 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue Aug 19 13:22:35 2008 Subject: ipfw add skipto tablearg.... In-Reply-To: <48926C02.6030308@elischer.org> Message-ID: On Thu, 31 Jul 2008, Julian Elischer wrote: > looking int he code I noticed that the following command gave > no error but didn't work.. > > > ipfw add 1000 skipto tablearg ip from any to table(31) Content addressible branching is an elegant and useful idea, thanks for making it work. A simple example in ipfw(8) might promote 'uptake'? > and as I have a use for that, I implemented it.. MFC to 6 possible? likely? I know there's lots of other stuff that hasn't / won't / can't be, but this one looked perhaps stand-alone .. > see attached patch... (hopefully not stripped) > > Of course it is hoped that the rules you are skipping to are nearby > as it iterates through the rules following the skipto to find the > target, Until $someone adds a direct skipto target jump at the virtual machine code level - big recalc hit when adding/deleting rules/sets I suppose - it's still the fastest way to get from a to b, where b > a Speaking of which, should ipfw whinge when asked to skip backwards, which it can't, confirmed on a recent browse re Mike's ipfw-classifyd and a local test months ago. > but.... > if you had a thousand table entries and wanted to sort them into > 20 buckets, it could save you puting them into 20 different > tables and doing 20 table lookups on them. Or even just for quick basic traffic-splitting, bogon lists, whatever .. > here I sort into two categories.. possibly already a win.. > > > julian@trafmon2:cat ipfw-test.sh > #!/bin/sh > ipfw add 100 skipto 10000 ip from any to not 1.1.1.0/24 > ipfw add 1000 skipto tablearg ip from any to "table(31)" > ipfw add 2000 drop ip from any to any > ipfw add 2001 drop ip from any to any > ipfw add 3000 drop ip from any to any > ipfw add 3001 drop ip from any to any > ipfw add 10000 count ip from any to any > ipfw table 31 add 1.1.1.1 2000 > ipfw table 31 add 1.1.1.2 3000 > > julian@trafmon2: ping 1.1.1.1 > [...] (2 packets bounced) > julian@trafmon2: ping 1.1.1.2 > [...] (12 packets bounced) > > julian@trafmon2: ipfw show > 00100 220 19633 skipto 10000 ip from any to not 1.1.1.0/24 > 01000 14 1176 skipto tablearg ip from any to table(31) > 02000 2 168 deny ip from any to any > 02001 0 0 deny ip from any to any > 03000 12 1008 deny ip from any to any > 03001 0 0 deny ip from any to any > 10000 209 18549 count ip from any to any > 65535 1751 153792 allow ip from any to any > > > comments? I like it, FWIW. > + if (tablearg != 0) { > + rulenum = (u_int16_t)tablearg; Should we check that tablearg is < 64K before merrily casting? cheers, Ian From rizzo at iet.unipi.it Tue Aug 19 13:47:03 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Aug 19 13:47:14 2008 Subject: ipfw add skipto tablearg.... In-Reply-To: References: <48926C02.6030308@elischer.org> Message-ID: <20080819133101.GA23276@onelab2.iet.unipi.it> On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > On Thu, 31 Jul 2008, Julian Elischer wrote: ... > > ipfw add 1000 skipto tablearg ip from any to table(31) ... > > see attached patch... (hopefully not stripped) > > > > Of course it is hoped that the rules you are skipping to are nearby > > as it iterates through the rules following the skipto to find the > > target, > > Until $someone adds a direct skipto target jump at the virtual machine > code level - big recalc hit when adding/deleting rules/sets I suppose - > it's still the fastest way to get from a to b, where b > a you mean with tables-based skipto targets ? Because the regular skipto has been a constant-time op forever, even in ipfw1 i believe, invalidating the target cache on a change and recomputing it the fly at the first request. > Speaking of which, should ipfw whinge when asked to skip backwards, > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > and a local test months ago. right... but the error can only be reliably detected in the kernel, as the rule number is not always known when the rule is added. cheers luigi From rizzo at iet.unipi.it Tue Aug 19 18:21:07 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Aug 19 18:21:19 2008 Subject: ipfw add skipto tablearg.... In-Reply-To: <20080820031409.V41971@sola.nimnet.asn.au> References: <48926C02.6030308@elischer.org> <20080819133101.GA23276@onelab2.iet.unipi.it> <20080820031409.V41971@sola.nimnet.asn.au> Message-ID: <20080819182337.GA25703@onelab2.iet.unipi.it> On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote: > On Tue, 19 Aug 2008, Luigi Rizzo wrote: > > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: ... > > > Until $someone adds a direct skipto target jump at the virtual machine > > > code level - big recalc hit when adding/deleting rules/sets I suppose - > > > it's still the fastest way to get from a to b, where b > a > > > > you mean with tables-based skipto targets ? Because the regular > > skipto has been a constant-time op forever, even in ipfw1 i believe, > > invalidating the target cache on a change and recomputing it the > > fly at the first request. > > Thanks; I'd completely missed the caching of skipto targets before, and > it's all so well commented too. blushing, but glad for the good news. > > But yes I was pondering Julian's patch, which has to lookup_next_rule > every time, and also Mike's bending of divert reentry rule number in > ipfw-classifyd with similar intent, which also has to hunt forward in > linear time for its target rule - or am I missing something else here? well, you can use a hash table to support that. It shouldn't be so bad to implement, flow tables already use hash tables so one can reuse the same code. > > > Speaking of which, should ipfw whinge when asked to skip backwards, > > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > > > and a local test months ago. > > > > right... but the error can only be reliably detected in the kernel, > > as the rule number is not always known when the rule is added. > > Yes I meant at run-time. On second thoughts, it'd be too easy a way to actually you can do it at insertion time, it's just that you cannot do it in userland as other checks before inserting the rule. cheers luigi From julian at elischer.org Tue Aug 19 18:38:04 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 19 18:38:18 2008 Subject: ipfw add skipto tablearg.... In-Reply-To: <20080819182337.GA25703@onelab2.iet.unipi.it> References: <48926C02.6030308@elischer.org> <20080819133101.GA23276@onelab2.iet.unipi.it> <20080820031409.V41971@sola.nimnet.asn.au> <20080819182337.GA25703@onelab2.iet.unipi.it> Message-ID: <48AB1313.5080405@elischer.org> Luigi Rizzo wrote: > On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote: >> On Tue, 19 Aug 2008, Luigi Rizzo wrote: >> > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > ... >> > > Until $someone adds a direct skipto target jump at the virtual machine >> > > code level - big recalc hit when adding/deleting rules/sets I suppose - >> > > it's still the fastest way to get from a to b, where b > a >> > >> > you mean with tables-based skipto targets ? Because the regular >> > skipto has been a constant-time op forever, even in ipfw1 i believe, >> > invalidating the target cache on a change and recomputing it the >> > fly at the first request. >> >> Thanks; I'd completely missed the caching of skipto targets before, and >> it's all so well commented too. blushing, but glad for the good news. >> >> But yes I was pondering Julian's patch, which has to lookup_next_rule >> every time, and also Mike's bending of divert reentry rule number in >> ipfw-classifyd with similar intent, which also has to hunt forward in >> linear time for its target rule - or am I missing something else here? > > well, you can use a hash table to support that. It shouldn't be so bad > to implement, flow tables already use hash tables so one can reuse the same code. one COULD, but I know I use this feature only with a number (20 or less) following rules, each of which is a skipto itself to some further awat location...or a simple drop.. Shall we say we "leave it as an exercise for the reader" ? > >> > > Speaking of which, should ipfw whinge when asked to skip backwards, >> > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd >> > > and a local test months ago. >> > >> > right... but the error can only be reliably detected in the kernel, >> > as the rule number is not always known when the rule is added. >> >> Yes I meant at run-time. On second thoughts, it'd be too easy a way to > > actually you can do it at insertion time, it's just that you cannot > do it in userland as other checks before inserting the rule. > > cheers > luigi From julian at elischer.org Tue Aug 19 18:39:21 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 19 18:39:33 2008 Subject: ipfw add skipto tablearg.... In-Reply-To: <20080819182337.GA25703@onelab2.iet.unipi.it> References: <48926C02.6030308@elischer.org> <20080819133101.GA23276@onelab2.iet.unipi.it> <20080820031409.V41971@sola.nimnet.asn.au> <20080819182337.GA25703@onelab2.iet.unipi.it> Message-ID: <48AB1360.7060908@elischer.org> Luigi Rizzo wrote: > On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote: >> On Tue, 19 Aug 2008, Luigi Rizzo wrote: >> > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > ... >> > > Until $someone adds a direct skipto target jump at the virtual machine >> > > code level - big recalc hit when adding/deleting rules/sets I suppose - >> > > it's still the fastest way to get from a to b, where b > a >> > >> > you mean with tables-based skipto targets ? Because the regular >> > skipto has been a constant-time op forever, even in ipfw1 i believe, >> > invalidating the target cache on a change and recomputing it the >> > fly at the first request. >> >> Thanks; I'd completely missed the caching of skipto targets before, and >> it's all so well commented too. blushing, but glad for the good news. >> >> But yes I was pondering Julian's patch, which has to lookup_next_rule >> every time, and also Mike's bending of divert reentry rule number in >> ipfw-classifyd with similar intent, which also has to hunt forward in >> linear time for its target rule - or am I missing something else here? > > well, you can use a hash table to support that. It shouldn't be so bad > to implement, flow tables already use hash tables so one can reuse the same code. > >> > > Speaking of which, should ipfw whinge when asked to skip backwards, >> > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd >> > > and a local test months ago. >> > >> > right... but the error can only be reliably detected in the kernel, >> > as the rule number is not always known when the rule is added. >> >> Yes I meant at run-time. On second thoughts, it'd be too easy a way to > > actually you can do it at insertion time, it's just that you cannot > do it in userland as other checks before inserting the rule. you can't do it at insertion time if it's a tablearg style skipto.. but such a rule will simply continue at the next rule as if it did not match. > > cheers > luigi From smithi at nimnet.asn.au Tue Aug 19 18:44:16 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue Aug 19 18:44:23 2008 Subject: ipfw add skipto tablearg.... In-Reply-To: <20080819133101.GA23276@onelab2.iet.unipi.it> References: <48926C02.6030308@elischer.org> <20080819133101.GA23276@onelab2.iet.unipi.it> Message-ID: <20080820031409.V41971@sola.nimnet.asn.au> On Tue, 19 Aug 2008, Luigi Rizzo wrote: > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > > On Thu, 31 Jul 2008, Julian Elischer wrote: > ... > > > ipfw add 1000 skipto tablearg ip from any to table(31) > ... > > > see attached patch... (hopefully not stripped) > > > > > > Of course it is hoped that the rules you are skipping to are nearby > > > as it iterates through the rules following the skipto to find the > > > target, > > > > Until $someone adds a direct skipto target jump at the virtual machine > > code level - big recalc hit when adding/deleting rules/sets I suppose - > > it's still the fastest way to get from a to b, where b > a > > you mean with tables-based skipto targets ? Because the regular > skipto has been a constant-time op forever, even in ipfw1 i believe, > invalidating the target cache on a change and recomputing it the > fly at the first request. Thanks; I'd completely missed the caching of skipto targets before, and it's all so well commented too. blushing, but glad for the good news. But yes I was pondering Julian's patch, which has to lookup_next_rule every time, and also Mike's bending of divert reentry rule number in ipfw-classifyd with similar intent, which also has to hunt forward in linear time for its target rule - or am I missing something else here? > > Speaking of which, should ipfw whinge when asked to skip backwards, > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > > and a local test months ago. > > right... but the error can only be reliably detected in the kernel, > as the rule number is not always known when the rule is added. Yes I meant at run-time. On second thoughts, it'd be too easy a way to spam syslogd in the general case, but maybe reporting target < current rule for such dynamic forms of skipto might highlight config errors? I should STFU and resume lurking unless I can contribute code, I know. cheers, Ian From bugmaster at FreeBSD.org Mon Aug 25 11:06:52 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 25 11:08:03 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200808251106.m7PB6pQP027784@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit 30 problems total. From ganbold at micom.mng.net Fri Aug 29 09:06:16 2008 From: ganbold at micom.mng.net (Ganbold) Date: Fri Aug 29 09:06:22 2008 Subject: IPFW_TABLES_MAX in src/sbin/ipfw/ipfw2.c Message-ID: <48B7B606.2040802@micom.mng.net> Hi, I'm trying to make small changes in ipfw2.c code, but make fails with following error: v02# make cc -O2 -fno-strict-aliasing -pipe -Wno-pointer-sign -c /usr/src/sbin/ipfw/ipfw2.c /usr/src/sbin/ipfw/ipfw2.c: In function 'table_handler': /usr/src/sbin/ipfw/ipfw2.c:5941: error: 'IPFW_TABLES_MAX' undeclared (first use in this function) /usr/src/sbin/ipfw/ipfw2.c:5941: error: (Each undeclared identifier is reported only once /usr/src/sbin/ipfw/ipfw2.c:5941: error: for each function it appears in.) *** Error code 1 IPFW_TABLES_MAX seems like defined in netinet/ip_fw.h, which is included in ipfw2.c: #define IPFW_INTERNAL /* Access to protected structures in ip_fw.h. */ ... #include ... Any idea how to solve this problem? Basically I'm trying to add small feature (list all tables) to ipfw something like: ipfw table all list I know it is possible to write small shell script to display all the tables and IPs. However I thought it might be useful to have such small feature in ipfw2 code. Correct me if I'm wrong here. thanks, Ganbold -- With listening comes wisdom, with speaking repentance. From ganbold at micom.mng.net Fri Aug 29 09:32:37 2008 From: ganbold at micom.mng.net (Ganbold) Date: Fri Aug 29 09:32:43 2008 Subject: IPFW_TABLES_MAX in src/sbin/ipfw/ipfw2.c Message-ID: <48B7B97A.7090203@micom.mng.net> Hi, I'm trying to make small changes in ipfw2.c code, but make fails with following error: v02# make cc -O2 -fno-strict-aliasing -pipe -Wno-pointer-sign -c /usr/src/sbin/ipfw/ipfw2.c /usr/src/sbin/ipfw/ipfw2.c: In function 'table_handler': /usr/src/sbin/ipfw/ipfw2.c:5941: error: 'IPFW_TABLES_MAX' undeclared (first use in this function) /usr/src/sbin/ipfw/ipfw2.c:5941: error: (Each undeclared identifier is reported only once /usr/src/sbin/ipfw/ipfw2.c:5941: error: for each function it appears in.) *** Error code 1 IPFW_TABLES_MAX seems like defined in netinet/ip_fw.h, which is included in ipfw2.c: #define IPFW_INTERNAL /* Access to protected structures in ip_fw.h. */ ... #include ... Any idea how to solve this problem? Basically I'm trying to add small feature (list all tables) to ipfw something like: ipfw table all list I know it is possible to write small shell script to display all the tables and IPs. However I thought it might be useful to have such small feature in ipfw2 code. Correct me if I'm wrong here. thanks, Ganbold -- Say many of cameras focused t'us, Our middle-aged shots do us justice. No justice, please, curse ye! We really want mercy: You see, 'tis the justice, disgusts us. -- Thomas H. Hildebrandt From linimon at FreeBSD.org Sat Aug 30 20:07:09 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Aug 30 20:07:15 2008 Subject: kern/126980: ipfw(8) hangs system Message-ID: <200808302007.m7UK79T2077031@freefall.freebsd.org> Old Synopsis: ipfw hangs system New Synopsis: ipfw(8) hangs system Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Sat Aug 30 20:06:45 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126980