From bugmaster at FreeBSD.org Mon Sep 1 11:06:57 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 1 11:08:05 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200809011106.m81B6uQ0068459@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 o kern/126980 ipfw ipfw(8) hangs system 16 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 linimon at FreeBSD.org Wed Sep 3 03:20:53 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Sep 3 03:20:59 2008 Subject: bin/127058: [patch] add "all" command line option to ipfw(8) table listing Message-ID: <200809030320.m833Krek072237@freefall.freebsd.org> Old Synopsis: add "all" command line option to ipfw table listing New Synopsis: [patch] add "all" command line option to ipfw(8) table listing Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 3 03:19:50 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127058 From ganbold at freebsd.org Wed Sep 3 03:50:03 2008 From: ganbold at freebsd.org (ganbold) Date: Wed Sep 3 03:50:10 2008 Subject: bin/127058: add "all" command line option to ipfw table listing Message-ID: <200809030350.m833o3sY074995@freefall.freebsd.org> The following reply was made to PR bin/127058; it has been noted by GNATS. From: ganbold To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/127058: add "all" command line option to ipfw table listing Date: Wed, 03 Sep 2008 11:45:06 +0800 I guess more complete ipfw(8) part of patch is here: --- ipfw.8-original 2008-09-01 17:08:35.000000000 +0800 +++ ipfw.8 2008-09-03 11:33:30.000000000 +0800 @@ -51,7 +51,9 @@ .Nm .Cm table Ar number Cm flush .Nm -.Cm table Ar number Cm list +.Cm table +.Brq Ar number | all +.Cm list .Pp .Nm .Brq Cm pipe | queue @@ -2207,6 +2209,8 @@ .It Em net.inet.ip.fw.debug : No 1 Controls debugging messages produced by .Nm . +.It Em net.inet.ip.fw.tables_max : No 128 +Maximum number of tables. .It Em net.inet.ip.fw.dyn_buckets : No 256 The number of buckets in the hash table for dynamic rules. Must be a power of 2, up to 65536. thanks, Ganbold Ganbold wrote: >> Number: 127058 >> Category: bin >> Synopsis: add "all" command line option to ipfw table listing >> Confidential: no >> Severity: non-critical >> Priority: low >> Responsible: freebsd-bugs >> State: open >> Quarter: >> Keywords: >> Date-Required: >> Class: sw-bug >> Submitter-Id: current-users >> Arrival-Date: Wed Sep 03 02:50:00 UTC 2008 >> Closed-Date: >> Last-Modified: >> Originator: Ganbold >> Release: RELENG_7 >> Organization: >> Environment: >> Description: >> > Following patches add possibility to list IP addresses from all defined ipfw tables. > > For example: > > v02# ipfw table all list > ---table(1)--- > 202.179.18.7/32 0 > 202.179.27.132/32 0 > 208.48.2.0/24 0 > ---table(2)--- > 202.72.244.226/32 0 > ---table(3)--- > 61.222.9.212/32 0 > 74.53.215.0/24 0 > 75.125.150.0/24 0 > 75.125.150.18/32 0 > 75.126.214.0/24 0 > 121.156.57.4/32 0 > 163.29.176.20/32 0 > 212.37.111.0/24 0 > ---table(4)--- > 64.202.163.213/32 0 > ---table(5)--- > 165.146.30.119/32 0 > 196.207.13.5/32 0 > . > > Patches are fully tested on RELENG_7 (FreeBSD 7.1-PRERELEASE #6: Wed Sep 3 10:02:27 ULAT 2008). > > Also these patches successfully applies to CURRENT. > > >> How-To-Repeat: >> > > >> Fix: >> > --- ip_fw2.c.orig 2008-08-20 03:58:42.000000000 +0800 > +++ ip_fw2.c 2008-09-03 09:53:29.000000000 +0800 > @@ -254,7 +254,10 @@ > static u_int32_t static_len; /* size in bytes of static rules */ > static u_int32_t dyn_count; /* # of dynamic rules */ > static u_int32_t dyn_max = 4096; /* max # of dynamic rules */ > +static u_int32_t tables_max = IPFW_TABLES_MAX; /* max # of tables */ > > +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, tables_max, CTLFLAG_RD, > + &tables_max, 0, "Max number of tables"); > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_buckets, CTLFLAG_RW, > &dyn_buckets, 0, "Number of dyn. buckets"); > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, curr_dyn_buckets, CTLFLAG_RD, > > > > > --- ipfw2.c.orig 2008-09-03 09:58:22.000000000 +0800 > +++ ipfw2.c 2008-09-03 10:19:20.000000000 +0800 > @@ -5860,22 +5860,27 @@ > * ipfw table N add addr[/masklen] [value] > * ipfw table N delete addr[/masklen] > * ipfw table N flush > - * ipfw table N list > + * ipfw table N|all list > */ > static void > table_handler(int ac, char *av[]) > { > ipfw_table_entry ent; > ipfw_table *tbl; > - int do_add; > + int do_add, is_all = 0; > char *p; > socklen_t l; > - uint32_t a; > + uint32_t a, b, c; > + size_t len; > > ac--; av++; > if (ac && isdigit(**av)) { > ent.tbl = atoi(*av); > ac--; av++; > + } else if (_substrcmp(*av, "all") == 0) { > + ent.tbl = 0; > + is_all = 1; > + ac--; av++; > } else > errx(EX_USAGE, "table number required"); > NEED1("table needs command"); > @@ -5931,33 +5936,48 @@ > if (do_cmd(IP_FW_TABLE_FLUSH, &ent.tbl, sizeof(ent.tbl)) < 0) > err(EX_OSERR, "setsockopt(IP_FW_TABLE_FLUSH)"); > } else if (_substrcmp(*av, "list") == 0) { > - a = ent.tbl; > - l = sizeof(a); > - if (do_cmd(IP_FW_TABLE_GETSIZE, &a, (uintptr_t)&l) < 0) > - err(EX_OSERR, "getsockopt(IP_FW_TABLE_GETSIZE)"); > - l = sizeof(*tbl) + a * sizeof(ipfw_table_entry); > - tbl = malloc(l); > - if (tbl == NULL) > - err(EX_OSERR, "malloc"); > - tbl->tbl = ent.tbl; > - if (do_cmd(IP_FW_TABLE_LIST, tbl, (uintptr_t)&l) < 0) > - err(EX_OSERR, "getsockopt(IP_FW_TABLE_LIST)"); > - for (a = 0; a < tbl->cnt; a++) { > - unsigned int tval; > - tval = tbl->ent[a].value; > - if (do_value_as_ip) { > - char tbuf[128]; > - strncpy(tbuf, inet_ntoa(*(struct in_addr *) > - &tbl->ent[a].addr), 127); > - /* inet_ntoa expects network order */ > - tval = htonl(tval); > - printf("%s/%u %s\n", tbuf, tbl->ent[a].masklen, > - inet_ntoa(*(struct in_addr *)&tval)); > - } else { > - printf("%s/%u %u\n", > - inet_ntoa(*(struct in_addr *)&tbl->ent[a].addr), > - tbl->ent[a].masklen, tval); > + c = ent.tbl; > + if (is_all) { > + len = sizeof(uint32_t); > + /* get IPFW_TABLES_MAX */ > + if (sysctlbyname("net.inet.ip.fw.tables_max", > + &c, &len, NULL, 0) == -1) > + errx(1, "sysctlbyname(\"%s\")", > + "net.inet.ip.fw.tables_max"); > + c -= 1; > + } > + for (b = ent.tbl; b <= c; b++) { > + a = b; > + l = sizeof(b); > + if (do_cmd(IP_FW_TABLE_GETSIZE, &a, (uintptr_t)&l) < 0) > + err(EX_OSERR, "getsockopt(IP_FW_TABLE_GETSIZE)"); > + l = sizeof(*tbl) + a * sizeof(ipfw_table_entry); > + tbl = malloc(l); > + if (tbl == NULL) > + err(EX_OSERR, "malloc"); > + tbl->tbl = b; > + if (do_cmd(IP_FW_TABLE_LIST, tbl, (uintptr_t)&l) < 0) > + err(EX_OSERR, "getsockopt(IP_FW_TABLE_LIST)"); > + if (tbl->cnt && is_all) > + printf("---table(%d)---\n", b); > + for (a = 0; a < tbl->cnt; a++) { > + unsigned int tval; > + tval = tbl->ent[a].value; > + if (do_value_as_ip) { > + char tbuf[128]; > + strncpy(tbuf, inet_ntoa(*(struct in_addr *) > + &tbl->ent[a].addr), 127); > + /* inet_ntoa expects network order */ > + tval = htonl(tval); > + printf("%s/%u %s\n", tbuf, tbl->ent[a].masklen, > + inet_ntoa(*(struct in_addr *)&tval)); > + } else { > + printf("%s/%u %u\n", > + inet_ntoa(*(struct in_addr *)&tbl->ent[a].addr), > + tbl->ent[a].masklen, tval); > + } > } > + free(tbl); > } > } else > errx(EX_USAGE, "invalid table command %s", *av); > > > > > > --- ipfw.8-original 2008-09-01 17:08:35.000000000 +0800 > +++ ipfw.8 2008-09-03 10:26:07.000000000 +0800 > @@ -51,7 +51,9 @@ > .Nm > .Cm table Ar number Cm flush > .Nm > -.Cm table Ar number Cm list > +.Cm table > +.Brq Ar number | all > +.Cm list > .Pp > .Nm > .Brq Cm pipe | queue > > > > > >> Release-Note: >> Audit-Trail: >> Unformatted: >> > _______________________________________________ > freebsd-bugs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" > > > > -- The difference between a misfortune and a calamity? If Gladstone fell into the Thames, it would be a misfortune. But if someone dragged him out again, it would be a calamity. -- Benjamin Disraeli From ganbold at micom.mng.net Wed Sep 3 12:10:04 2008 From: ganbold at micom.mng.net (Ganbold) Date: Wed Sep 3 12:10:11 2008 Subject: bin/127058: add "all" command line option to ipfw table listing Message-ID: <200809031210.m83CA3ju083746@freefall.freebsd.org> The following reply was made to PR bin/127058; it has been noted by GNATS. From: Ganbold To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/127058: add "all" command line option to ipfw table listing Date: Wed, 03 Sep 2008 19:26:19 +0800 The patches are at: http://www.mnbsd.org/ganbold/ip_fw2.c.patch http://www.mnbsd.org/ganbold/ipfw.8.patch http://www.mnbsd.org/ganbold/ipfw2.c.patch thanks, Ganbold Ganbold wrote: >> Number: 127058 >> Category: bin >> Synopsis: add "all" command line option to ipfw table listing >> Confidential: no >> Severity: non-critical >> Priority: low >> Responsible: freebsd-bugs >> State: open >> Quarter: >> Keywords: >> Date-Required: >> Class: sw-bug >> Submitter-Id: current-users >> Arrival-Date: Wed Sep 03 02:50:00 UTC 2008 >> Closed-Date: >> Last-Modified: >> Originator: Ganbold >> Release: RELENG_7 >> Organization: >> Environment: >> Description: >> > Following patches add possibility to list IP addresses from all defined ipfw tables. > > For example: > > v02# ipfw table all list > ---table(1)--- > 202.179.18.7/32 0 > 202.179.27.132/32 0 > 208.48.2.0/24 0 > ---table(2)--- > 202.72.244.226/32 0 > ---table(3)--- > 61.222.9.212/32 0 > 74.53.215.0/24 0 > 75.125.150.0/24 0 > 75.125.150.18/32 0 > 75.126.214.0/24 0 > 121.156.57.4/32 0 > 163.29.176.20/32 0 > 212.37.111.0/24 0 > ---table(4)--- > 64.202.163.213/32 0 > ---table(5)--- > 165.146.30.119/32 0 > 196.207.13.5/32 0 > . > > Patches are fully tested on RELENG_7 (FreeBSD 7.1-PRERELEASE #6: Wed Sep 3 10:02:27 ULAT 2008). > > Also these patches successfully applies to CURRENT. > > >> How-To-Repeat: >> > > >> Fix: >> > --- ip_fw2.c.orig 2008-08-20 03:58:42.000000000 +0800 > +++ ip_fw2.c 2008-09-03 09:53:29.000000000 +0800 > @@ -254,7 +254,10 @@ > static u_int32_t static_len; /* size in bytes of static rules */ > static u_int32_t dyn_count; /* # of dynamic rules */ > static u_int32_t dyn_max = 4096; /* max # of dynamic rules */ > +static u_int32_t tables_max = IPFW_TABLES_MAX; /* max # of tables */ > > +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, tables_max, CTLFLAG_RD, > + &tables_max, 0, "Max number of tables"); > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_buckets, CTLFLAG_RW, > &dyn_buckets, 0, "Number of dyn. buckets"); > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, curr_dyn_buckets, CTLFLAG_RD, > > > > > --- ipfw2.c.orig 2008-09-03 09:58:22.000000000 +0800 > +++ ipfw2.c 2008-09-03 10:19:20.000000000 +0800 > @@ -5860,22 +5860,27 @@ > * ipfw table N add addr[/masklen] [value] > * ipfw table N delete addr[/masklen] > * ipfw table N flush > - * ipfw table N list > + * ipfw table N|all list > */ > static void > table_handler(int ac, char *av[]) > { > ipfw_table_entry ent; > ipfw_table *tbl; > - int do_add; > + int do_add, is_all = 0; > char *p; > socklen_t l; > - uint32_t a; > + uint32_t a, b, c; > + size_t len; > > ac--; av++; > if (ac && isdigit(**av)) { > ent.tbl = atoi(*av); > ac--; av++; > + } else if (_substrcmp(*av, "all") == 0) { > + ent.tbl = 0; > + is_all = 1; > + ac--; av++; > } else > errx(EX_USAGE, "table number required"); > NEED1("table needs command"); > @@ -5931,33 +5936,48 @@ > if (do_cmd(IP_FW_TABLE_FLUSH, &ent.tbl, sizeof(ent.tbl)) < 0) > err(EX_OSERR, "setsockopt(IP_FW_TABLE_FLUSH)"); > } else if (_substrcmp(*av, "list") == 0) { > - a = ent.tbl; > - l = sizeof(a); > - if (do_cmd(IP_FW_TABLE_GETSIZE, &a, (uintptr_t)&l) < 0) > - err(EX_OSERR, "getsockopt(IP_FW_TABLE_GETSIZE)"); > - l = sizeof(*tbl) + a * sizeof(ipfw_table_entry); > - tbl = malloc(l); > - if (tbl == NULL) > - err(EX_OSERR, "malloc"); > - tbl->tbl = ent.tbl; > - if (do_cmd(IP_FW_TABLE_LIST, tbl, (uintptr_t)&l) < 0) > - err(EX_OSERR, "getsockopt(IP_FW_TABLE_LIST)"); > - for (a = 0; a < tbl->cnt; a++) { > - unsigned int tval; > - tval = tbl->ent[a].value; > - if (do_value_as_ip) { > - char tbuf[128]; > - strncpy(tbuf, inet_ntoa(*(struct in_addr *) > - &tbl->ent[a].addr), 127); > - /* inet_ntoa expects network order */ > - tval = htonl(tval); > - printf("%s/%u %s\n", tbuf, tbl->ent[a].masklen, > - inet_ntoa(*(struct in_addr *)&tval)); > - } else { > - printf("%s/%u %u\n", > - inet_ntoa(*(struct in_addr *)&tbl->ent[a].addr), > - tbl->ent[a].masklen, tval); > + c = ent.tbl; > + if (is_all) { > + len = sizeof(uint32_t); > + /* get IPFW_TABLES_MAX */ > + if (sysctlbyname("net.inet.ip.fw.tables_max", > + &c, &len, NULL, 0) == -1) > + errx(1, "sysctlbyname(\"%s\")", > + "net.inet.ip.fw.tables_max"); > + c -= 1; > + } > + for (b = ent.tbl; b <= c; b++) { > + a = b; > + l = sizeof(b); > + if (do_cmd(IP_FW_TABLE_GETSIZE, &a, (uintptr_t)&l) < 0) > + err(EX_OSERR, "getsockopt(IP_FW_TABLE_GETSIZE)"); > + l = sizeof(*tbl) + a * sizeof(ipfw_table_entry); > + tbl = malloc(l); > + if (tbl == NULL) > + err(EX_OSERR, "malloc"); > + tbl->tbl = b; > + if (do_cmd(IP_FW_TABLE_LIST, tbl, (uintptr_t)&l) < 0) > + err(EX_OSERR, "getsockopt(IP_FW_TABLE_LIST)"); > + if (tbl->cnt && is_all) > + printf("---table(%d)---\n", b); > + for (a = 0; a < tbl->cnt; a++) { > + unsigned int tval; > + tval = tbl->ent[a].value; > + if (do_value_as_ip) { > + char tbuf[128]; > + strncpy(tbuf, inet_ntoa(*(struct in_addr *) > + &tbl->ent[a].addr), 127); > + /* inet_ntoa expects network order */ > + tval = htonl(tval); > + printf("%s/%u %s\n", tbuf, tbl->ent[a].masklen, > + inet_ntoa(*(struct in_addr *)&tval)); > + } else { > + printf("%s/%u %u\n", > + inet_ntoa(*(struct in_addr *)&tbl->ent[a].addr), > + tbl->ent[a].masklen, tval); > + } > } > + free(tbl); > } > } else > errx(EX_USAGE, "invalid table command %s", *av); > > > > > > --- ipfw.8-original 2008-09-01 17:08:35.000000000 +0800 > +++ ipfw.8 2008-09-03 10:26:07.000000000 +0800 > @@ -51,7 +51,9 @@ > .Nm > .Cm table Ar number Cm flush > .Nm > -.Cm table Ar number Cm list > +.Cm table > +.Brq Ar number | all > +.Cm list > .Pp > .Nm > .Brq Cm pipe | queue > > > > > >> Release-Note: >> Audit-Trail: >> Unformatted: >> > _______________________________________________ > freebsd-bugs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" > > > > -- Only someone with nothing to be sorry for smiles back at the rear of an elephant. From thavinci at thavinci.za.net Wed Sep 3 12:27:03 2008 From: thavinci at thavinci.za.net (Marcel Grandemange) Date: Wed Sep 3 12:27:11 2008 Subject: FW: IPFW In FreeBSD Message-ID: <02e801c90dba$fa65bf20$ef313d60$@za.net> Ok so I know this is a newbie question.. But ive for years now wanted to know how to only nat certain traffic or maby only across a certain ip. Ive tried many examples all not working.. Maby im just doing something stupid.. But, below is a example of a machine that is natting everything on em0. Id like to know how to change that to everything on say 196.212.65.186 instead of entire interface. Or better yet.. Stop natting everything and say only nat web traffic. Im having issues where certain traffic is being nated that MUSTN be! Would be REALLY greatfull for input and working examples! 00013 6613581 1024484770 fwd 127.0.0.1,3128 tcp from not me to not me dst-port 80 via em1 00015 3678 424024 fwd 127.0.0.1,3128 tcp from not me to not me dst-port 8080 via em1 00025 24596697 12747712371 divert 8668 ip from any to any via em0 00600 0 0 deny ip from any to 196.212.65.186 dst-port 3306 via em0 00600 0 0 deny ip from any to 196.212.65.187 dst-port 3306 via em0 00600 7 408 deny ip from any to 196.212.65.187 dst-port 22 via em0 00600 0 0 deny ip from any to 196.212.65.187 dst-port 199 via em0 00600 0 0 deny ip from any to me dst-port 3401 via em0 00600 0 0 deny ip from any to 192.168.239.1 dst-port 3306 via em1 00600 883 49232 deny icmp from any to 196.212.65.187 via em0 00660 86202 39746084 deny udp from me to any dst-port 520 not via em1 00700 46353458 25934143975 allow ip from any to any 65535 0 0 deny ip from any to any em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:90:c8:28 inet 196.212.65.186 netmask 0xfffffff8 broadcast 196.212.65.191 inet 196.212.65.187 netmask 0xfffffff8 broadcast 196.212.65.191 media: Ethernet autoselect (100baseTX ) status: active #Nat natd_enable="YES" # Enable NATD function natd_flags="-dynamic" natd_interface="em0" # interface name of public Internet NIC _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" __________ NOD32 3407 (20080902) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com From bugmaster at FreeBSD.org Mon Sep 8 02:22:22 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 8 02:23:21 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200809080222.m882MLfI006707@freefall.freebsd.org> 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 bin/127058 ipfw [patch] add "all" command line option to ipfw(8) table o kern/126980 ipfw ipfw(8) hangs system o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher 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 speci 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 47 problems total. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. From rik at FreeBSD.org Mon Sep 8 06:07:30 2008 From: rik at FreeBSD.org (rik@FreeBSD.org) Date: Mon Sep 8 06:07:40 2008 Subject: bin/127058: [patch] add "all" command line option to ipfw(8) table listing Message-ID: <200809080607.m8867THa035202@freefall.freebsd.org> Synopsis: [patch] add "all" command line option to ipfw(8) table listing Responsible-Changed-From-To: freebsd-ipfw->rik Responsible-Changed-By: rik Responsible-Changed-When: Mon Sep 8 06:04:48 UTC 2008 Responsible-Changed-Why: I'll take care of it. http://www.freebsd.org/cgi/query-pr.cgi?pr=127058 From linimon at FreeBSD.org Mon Sep 8 22:17:55 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Sep 8 22:18:07 2008 Subject: kern/127209: [ipfw] IPFW table become corrupted after many changes Message-ID: <200809082217.m88MHtX1053360@freefall.freebsd.org> Old Synopsis: IPFW table become corrupted after many changes New Synopsis: [ipfw] IPFW table become corrupted after many changes Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Mon Sep 8 22:17:26 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127209 From remko at FreeBSD.org Tue Sep 9 08:34:08 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Tue Sep 9 08:34:20 2008 Subject: kern/127230: [ipfw]: Feature request to add UID and/or GID logging data to ipfw logging with uid rules. Message-ID: <200809090834.m898Y88t042169@freefall.freebsd.org> Old Synopsis: Feature request to add UID and/or GID logging data to ipfw logging with uid rules. New Synopsis: [ipfw]: Feature request to add UID and/or GID logging data to ipfw logging with uid rules. Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: remko Responsible-Changed-When: Tue Sep 9 08:33:44 UTC 2008 Responsible-Changed-Why: Reassign to IPFW team. http://www.freebsd.org/cgi/query-pr.cgi?pr=127230 From Daan at vehosting.nl Tue Sep 9 13:20:05 2008 From: Daan at vehosting.nl (Daan Vreeken) Date: Tue Sep 9 13:20:15 2008 Subject: kern/127230: Feature request to add UID and/or GID logging data to ipfw logging with uid rules. Message-ID: <200809091320.m89DK4mj069654@freefall.freebsd.org> The following reply was made to PR kern/127230; it has been noted by GNATS. From: Daan Vreeken To: freebsd-bugs@freebsd.org, Dan Mahoney Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/127230: Feature request to add UID and/or GID logging data to ipfw logging with uid rules. Date: Tue, 9 Sep 2008 14:36:42 +0200 On Tuesday 09 September 2008 08:36:02 Dan Mahoney wrote: > >Number: 127230 > >Category: kern > >Synopsis: Feature request to add UID and/or GID logging data to ipfw > > logging with uid rules. Confidential: no > >Severity: non-critical > >Priority: medium > >Responsible: freebsd-bugs > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: change-request > >Submitter-Id: current-users > >Arrival-Date: Tue Sep 09 07:00:12 UTC 2008 > >Closed-Date: > >Last-Modified: > >Originator: Dan Mahoney > >Release: FreeBSD 6.2-PRERELEASE i386 > >Organization: > > Gushi Systems > > >Environment: > > System: FreeBSD prime.gushi.org 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: > Thu Jan 18 02:05:07 EST 2007 > danm@prime.gushi.org:/usr/src/sys/i386/compile/PRIME6 i386 > > Note: The system I'm on is 6.2, but this will likely apply to -CURRENT or > -STABLE (although a patch for 6.x would be appreciated). > > I have the following rule set up in ipfw to limit the exposure of bad php > scripts and trojans that try to send mail directly. > > allow tcp from any to any dst-port 25 uid root > deny log tcp from any to any dst-port 25 out > > However, the log messages I get look like this: > > Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP > 72.9.101.130:58117 209.85.133.114:25 out via em0 > Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP > 72.9.101.130:56672 202.12.31.144:25 out via em0 > > Which is to say, they don't include the UID -- and I have several hundred > sites, each with its own UID. > > Yes, I could go ahead and set up a thousand "deny" rules, one for each UID > -- but being able to log this info (since it IS being checked) would be > great. > > >Description: > > > >How-To-Repeat: > > Per jeremy chadwick, I am referenceing the following thread on the mailing > lists: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/025920.ht >ml Just for the record : I've created two patches (against -HEAD) that implement this which can be found here : http://vehosting.nl/pub_diffs/ -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From julian at elischer.org Thu Sep 11 20:08:19 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Sep 11 20:08:25 2008 Subject: anyone have a netgraph node to do ipfw filtering? Message-ID: <48C97AB3.6040907@elischer.org> I think someone sent me a link to an ng_ipfw_filter node once but I've lost it... (I think it was called ng_ipfw but that name is now taken by the netgraph/ipfw 'ipfw netgraph' packet divert option). Something that lets you do ipfw filtering on packets as they travel across a graph. As I said,I've seen one but lost it... Julian From bzeeb-lists at lists.zabbadoz.net Fri Sep 12 06:09:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Sep 12 06:09:15 2008 Subject: anyone have a netgraph node to do ipfw filtering? In-Reply-To: <48C97AB3.6040907@elischer.org> References: <48C97AB3.6040907@elischer.org> Message-ID: <20080912054832.Q65801@maildrop.int.zabbadoz.net> On Thu, 11 Sep 2008, Julian Elischer wrote: Hi, > I think someone sent me a link to an ng_ipfw_filter node once > but I've lost it... > > (I think it was called ng_ipfw but that name is now taken by the > netgraph/ipfw 'ipfw netgraph' packet divert option). > > Something that lets you do ipfw filtering on packets as they > travel across a graph. > > As I said,I've seen one but lost it... I could be wrong but did you mean? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_ipfw.c -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From julian at elischer.org Fri Sep 12 06:12:31 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 12 06:12:42 2008 Subject: anyone have a netgraph node to do ipfw filtering? In-Reply-To: <20080912054832.Q65801@maildrop.int.zabbadoz.net> References: <48C97AB3.6040907@elischer.org> <20080912054832.Q65801@maildrop.int.zabbadoz.net> Message-ID: <48CA084D.1050406@elischer.org> Bjoern A. Zeeb wrote: > On Thu, 11 Sep 2008, Julian Elischer wrote: > > Hi, > >> I think someone sent me a link to an ng_ipfw_filter node once >> but I've lost it... >> >> (I think it was called ng_ipfw but that name is now taken by the >> netgraph/ipfw 'ipfw netgraph' packet divert option). >> >> Something that lets you do ipfw filtering on packets as they >> travel across a graph. >> >> As I said,I've seen one but lost it... > > I could be wrong but did you mean? > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_ipfw.c > no that's the one I refer to in themail wiich is the inverse of what I want that one allows ipfw to send things to netgraph. I want one to allow a netgraph graph to filter things with ipfw... From bzeeb-lists at lists.zabbadoz.net Fri Sep 12 06:15:06 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Sep 12 06:15:18 2008 Subject: anyone have a netgraph node to do ipfw filtering? In-Reply-To: <20080912054832.Q65801@maildrop.int.zabbadoz.net> References: <48C97AB3.6040907@elischer.org> <20080912054832.Q65801@maildrop.int.zabbadoz.net> Message-ID: <20080912061314.H65801@maildrop.int.zabbadoz.net> On Fri, 12 Sep 2008, Bjoern A. Zeeb wrote: > On Thu, 11 Sep 2008, Julian Elischer wrote: > > Hi, > >> I think someone sent me a link to an ng_ipfw_filter node once >> but I've lost it... >> >> (I think it was called ng_ipfw but that name is now taken by the >> netgraph/ipfw 'ipfw netgraph' packet divert option). >> >> Something that lets you do ipfw filtering on packets as they >> travel across a graph. >> >> As I said,I've seen one but lost it... > > I could be wrong but did you mean? baeh, ignore this... -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From andrew at modulus.org Fri Sep 12 06:32:45 2008 From: andrew at modulus.org (Andrew Snow) Date: Fri Sep 12 06:32:52 2008 Subject: anyone have a netgraph node to do ipfw filtering? In-Reply-To: <20080912054832.Q65801@maildrop.int.zabbadoz.net> References: <48C97AB3.6040907@elischer.org> <20080912054832.Q65801@maildrop.int.zabbadoz.net> Message-ID: <48CA0952.50804@modulus.org> I think what you ask can be done by: 1. sending the packet through ng_mbuf to tag it 2. sending it to ng_ipfw to be sent through IPFW 3. use IPFW rules to operate on packets with the particular tag you attached in #1 4. as the final IPFW rule, pass the packet back in to netgraph via a 'netgraph' IPFW rule. I have not tried this, no idea if it would work Best of luck! :-) - Andrew From julian at elischer.org Fri Sep 12 06:48:51 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 12 06:49:03 2008 Subject: anyone have a netgraph node to do ipfw filtering? In-Reply-To: <20080912061628.GA46340@svzserv.kemerovo.su> References: <48C97AB3.6040907@elischer.org> <20080912054832.Q65801@maildrop.int.zabbadoz.net> <48CA084D.1050406@elischer.org> <20080912061628.GA46340@svzserv.kemerovo.su> Message-ID: <48CA10D2.4040807@elischer.org> Eugene Grosbein wrote: > On Thu, Sep 11, 2008 at 11:12:29PM -0700, Julian Elischer wrote: > >> that one allows ipfw to send things to netgraph. I want one >> to allow a netgraph graph to filter things with ipfw... > > ng_bpf? not exactly ipfw filtering, but filtering :-) > No it needs to be ifpw for the job I'm doing..there is already a lot of code that manipulate ipfw rules that I want to reuse. (heavy use of tables etc.). From eugen at kuzbass.ru Fri Sep 12 06:51:17 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Fri Sep 12 06:51:24 2008 Subject: anyone have a netgraph node to do ipfw filtering? In-Reply-To: <48CA084D.1050406@elischer.org> References: <48C97AB3.6040907@elischer.org> <20080912054832.Q65801@maildrop.int.zabbadoz.net> <48CA084D.1050406@elischer.org> Message-ID: <20080912061628.GA46340@svzserv.kemerovo.su> On Thu, Sep 11, 2008 at 11:12:29PM -0700, Julian Elischer wrote: > that one allows ipfw to send things to netgraph. I want one > to allow a netgraph graph to filter things with ipfw... ng_bpf? not exactly ipfw filtering, but filtering :-) Eugene Grosbein From eugen at kuzbass.ru Fri Sep 12 06:56:03 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Fri Sep 12 06:56:16 2008 Subject: anyone have a netgraph node to do ipfw filtering? References: <48C97AB3.6040907@elischer.org> <20080912054832.Q65801@maildrop.int.zabbadoz.net> <48CA084D.1050406@elischer.org> <20080912061628.GA46340@svzserv.kemerovo.su> <48CA10D2.4040807@elischer.org> Message-ID: <48CA127E.9BDA9C22@kuzbass.ru> Julian Elischer wrote: > >> that one allows ipfw to send things to netgraph. I want one > >> to allow a netgraph graph to filter things with ipfw... > > > > ng_bpf? not exactly ipfw filtering, but filtering :-) > > No it needs to be ifpw for the job I'm doing..there is already a lot > of code that manipulate ipfw rules that I want to reuse. > (heavy use of tables etc.). I think there is no such node at present, I did some search recently. From bugmaster at FreeBSD.org Mon Sep 15 15:18:50 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 15 15:20:04 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200809151518.m8FFInZ3018911@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/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 kern/126980 ipfw ipfw(8) hangs system o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher 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 speci 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 48 problems total. From jbut at swin.edu.au Fri Sep 19 03:08:49 2008 From: jbut at swin.edu.au (Jason But) Date: Fri Sep 19 03:08:56 2008 Subject: Code release of ipfw NAT support for SCTP in FreeBSD-8 Message-ID: <48D31427.3080708@swin.edu.au> The Centre for Advanced Internet Architectures (CAIA http://caia.swin.edu.au) is proud to announce the release of alias_sctp version 0.2, an SCTP NAT patch to FreeBSD 8.x. Alias_sctp provides SCTP NAT functionality to the ipfw/ipfw_nat/libalias suite. Alias_sctp version 0.2 is a fully functional NAT for SCTP. It is part of the CAIA SONATA project (http://caia.swin.edu.au/urp/sonata). The code has been intentionally kept as separate as possible from the base modules to aid testing and debugging, and make it easier to port to other systems. We welcome and value feedback and comments. Please forward feedback to dahayes@swin.edu.au and jbut@swin.edu.au Download patch from http://caia.swin.edu.au/urp/sonata/downloads.html Features of alias_sctp version 0.2: - Support for global multi-homing - Support for multi-homed privately addressed hosts using ASCONF modifications from the Internet Draft (R. Stewart and M. Tuexen, "Stream control transmission protocol (SCTP) network address translation", draft-stewart-behave-sctpnat-04, Jul. 2008) - Support for forwarding of T-flagged packets - Generation and delivery of AbortM/ErrorM packets upon detection of NAT collisions - Per-port forwarding rules - Dynamic configuration (via sysctl interface) of: o Logging and statistic gathering o Timer management o Hash Table sizes o Global address storage and other processing limits - Configuration via use of the "ipfw nat ... config" - Stateful SCTP association management. This project has been made possible in part by a grant from the Cisco University Research Program Fund at Community Foundation Silicon Valley. Jason -- ---------- Dr. Jason But Lecturer Telecommunications Engineering Academic Group Faculty of Information and Communication Technologies Swinburne University of Technology http://www.swinburne.edu.au/ict/telecommshome.htm From bugmaster at FreeBSD.org Mon Sep 22 11:06:56 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 22 11:07:21 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200809221106.m8MB6s2B015400@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/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 kern/126980 ipfw ipfw(8) hangs system o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher 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 speci 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 48 problems total. From ganbold at micom.mng.net Tue Sep 23 08:26:07 2008 From: ganbold at micom.mng.net (Ganbold) Date: Tue Sep 23 08:26:09 2008 Subject: question related to /sbin/ipfw/ipfw2.c Message-ID: <48D8A814.7030607@micom.mng.net> Hi, What does following part of src/sbin/ipfw/ipfw2.c code? ... static void fill_ip(ipfw_insn_ip *cmd, char *av) { int len = 0; uint32_t *d = ((ipfw_insn_u32 *)cmd)->d; cmd->o.len &= ~F_LEN_MASK; /* zero len */ ----------------------------------- if (strncmp(av, "table(", 6) == 0) { char *p = strchr(av + 6, ','); if (p) *p++ = '\0'; cmd->o.opcode = O_IP_DST_LOOKUP; cmd->o.arg1 = strtoul(av + 6, NULL, 0); if (p) { cmd->o.len |= F_INSN_SIZE(ipfw_insn_u32); d[0] = strtoul(p, NULL, 0); } else cmd->o.len |= F_INSN_SIZE(ipfw_insn); return; } ----------------------------------- Specially, what does following code? ... cmd->o.opcode = O_IP_DST_LOOKUP; cmd->o.arg1 = strtoul(av + 6, NULL, 0); if (p) { cmd->o.len |= F_INSN_SIZE(ipfw_insn_u32); d[0] = strtoul(p, NULL, 0); } else cmd->o.len |= F_INSN_SIZE(ipfw_insn); ... thanks, Ganbold -- This is clearly another case of too many mad scientists, and not enough hunchbacks. From rik at inse.ru Tue Sep 23 09:52:55 2008 From: rik at inse.ru (Roman Kurakin) Date: Tue Sep 23 09:52:57 2008 Subject: question related to /sbin/ipfw/ipfw2.c In-Reply-To: <48D8A814.7030607@micom.mng.net> References: <48D8A814.7030607@micom.mng.net> Message-ID: <48D8B8F0.8020900@localhost.inse.ru> Ganbold wrote: > Hi, > > What does following part of src/sbin/ipfw/ipfw2.c code? > ... > static void > fill_ip(ipfw_insn_ip *cmd, char *av) > { > int len = 0; > uint32_t *d = ((ipfw_insn_u32 *)cmd)->d; > > cmd->o.len &= ~F_LEN_MASK; /* zero len */ > ----------------------------------- > if (strncmp(av, "table(", 6) == 0) { match the beginning of the "table(entry,value)" > char *p = strchr(av + 6, ','); find the ',' if any > > if (p) > *p++ = '\0'; and replace it with '\0' eq "table(entry\0value)" so as a string it is now "table(entry" and make p point to 'value', eq p = 'value' now > cmd->o.opcode = O_IP_DST_LOOKUP; > cmd->o.arg1 = strtoul(av + 6, NULL, 0); av+6 is the "entry" string arg1=(unsigned long)entry > > if (p) { if we have a 'value ' part > cmd->o.len |= F_INSN_SIZE(ipfw_insn_u32); > d[0] = strtoul(p, NULL, 0); d[0] = (unsigned long)value > } else > cmd->o.len |= F_INSN_SIZE(ipfw_insn); > return; > } Is that what you need? rik > ----------------------------------- > > Specially, what does following code? > ... > cmd->o.opcode = O_IP_DST_LOOKUP; > cmd->o.arg1 = strtoul(av + 6, NULL, 0); > if (p) { > cmd->o.len |= F_INSN_SIZE(ipfw_insn_u32); > d[0] = strtoul(p, NULL, 0); > } else > cmd->o.len |= F_INSN_SIZE(ipfw_insn); > ... > > thanks, > > Ganbold > From ganbold at micom.mng.net Tue Sep 23 12:14:08 2008 From: ganbold at micom.mng.net (Ganbold) Date: Tue Sep 23 12:14:10 2008 Subject: question related to /sbin/ipfw/ipfw2.c In-Reply-To: <48D8B8F0.8020900@localhost.inse.ru> References: <48D8A814.7030607@micom.mng.net> <48D8B8F0.8020900@localhost.inse.ru> Message-ID: <48D8DD86.7000903@micom.mng.net> Roman Kurakin wrote: > Ganbold wrote: >> Hi, >> >> What does following part of src/sbin/ipfw/ipfw2.c code? >> ... >> static void >> fill_ip(ipfw_insn_ip *cmd, char *av) >> { >> int len = 0; >> uint32_t *d = ((ipfw_insn_u32 *)cmd)->d; >> >> cmd->o.len &= ~F_LEN_MASK; /* zero len */ >> ----------------------------------- >> if (strncmp(av, "table(", 6) == 0) { > match the beginning of the "table(entry,value)" >> char *p = strchr(av + 6, ','); > find the ',' if any >> >> if (p) >> *p++ = '\0'; > and replace it with '\0' eq "table(entry\0value)" so as a string it is > now "table(entry" > and make p point to 'value', eq p = 'value' now >> cmd->o.opcode = O_IP_DST_LOOKUP; >> cmd->o.arg1 = strtoul(av + 6, NULL, 0); > av+6 is the "entry" string > arg1=(unsigned long)entry >> >> if (p) { > if we have a 'value ' part >> cmd->o.len |= F_INSN_SIZE(ipfw_insn_u32); >> d[0] = strtoul(p, NULL, 0); > d[0] = (unsigned long)value Ok, now how do we know or choose the index of d[]? Basically I would like to store some value in d[]. How can I do that? thanks, Ganbold >> } else >> cmd->o.len |= F_INSN_SIZE(ipfw_insn); >> return; >> } > Is that what you need? > > rik >> ----------------------------------- >> >> Specially, what does following code? >> ... >> cmd->o.opcode = O_IP_DST_LOOKUP; >> cmd->o.arg1 = strtoul(av + 6, NULL, 0); >> if (p) { >> cmd->o.len |= F_INSN_SIZE(ipfw_insn_u32); >> d[0] = strtoul(p, NULL, 0); >> } else >> cmd->o.len |= F_INSN_SIZE(ipfw_insn); >> ... >> >> thanks, >> >> Ganbold >> > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > -- A little inaccuracy saves a world of explanation. -- C. E. Ayres From ganbold at micom.mng.net Wed Sep 24 10:50:17 2008 From: ganbold at micom.mng.net (Ganbold) Date: Wed Sep 24 10:50:21 2008 Subject: ipfw port lookup table patch for review Message-ID: <48DA1B65.8030106@micom.mng.net> Hi, I thought it might be useful to have port lookup table similar to existing IP lookup table in ipfw and I have made patch for that. The downside of the patch so far I'm seeing is the port entries are in linked list (no limitation yet, memory overhead), not sorted and it uses linear search to match (could be slow when lot of entries). Just after I've made the patch I saw http://www.freebsd.org/cgi/query-pr.cgi?pr=121807&cat= . :( I agree with PR's reply however for small number of port entries I thought this functionality is quite useful. It gives benefit like no need to modify existing rule, adding/deleting port entries is easy. I did some small tests and it seems like working. Patches are at: http://people.freebsd.org/~ganbold/ipfw_port_table/ The output of some usage samples is at: http://people.freebsd.org/~ganbold/ipfw_port_table/ipfw_port_table_usage_sample.txt Patches can be successfully applied to CURRENT. Didn't test RELENG_7 due to no RELENG_7 PC :) Please let me know your thoughts. I'm happy to discuss to improve the patch. Correct me if I'm doing something wrong here. thanks, Ganbold From ganbold at micom.mng.net Thu Sep 25 11:30:04 2008 From: ganbold at micom.mng.net (Ganbold) Date: Thu Sep 25 11:30:11 2008 Subject: kern/121807: Sugestion: TCP and UDP port_table in ipfw Message-ID: <200809251130.m8PBU4nH062121@freefall.freebsd.org> The following reply was made to PR kern/121807; it has been noted by GNATS. From: Ganbold To: bug-followup@FreeBSD.org Cc: goffredo@gmail.com, Vadim Goncharov Subject: Re: kern/121807: Sugestion: TCP and UDP port_table in ipfw Date: Thu, 25 Sep 2008 19:20:27 +0800 Hi, Vadim Goncharov wrote: > > > Why not exist a TCP/UDP port_table for IPFW? It can solve 30 itens limit in ipfw rule. It is good to use in QoS. > > Example > > ipfw add allow { tcp or udp } from any port_table(10) to any > > ipfw port_table 10 add 20,21,25,110,443,993,995,1025-65535 > > # Deny bad ports > > ipfw add deny { tcp or udp } from any to any port_table(11) > > ipfw port_table 11 add 135,137-139,445 > > ipfw add queue 100 udp from any port_table(20) to any > > ipfw port_table(20) add 123,53 > > For what puprose should it _really_ serve? Limit-upping? Per-packet speed > optimisation? More handy config preapring? Should that tables serve as > a collection-only, or do have tableargs, and for what practical purpose that > tableargs would be useful? > > If it is simply annoying to put long list in config several times, then it is > correctly solved by shell vars: > good_ports="20,21,25,110,443,993,995,1025-65535" > > ipfw add allow { tcp or udp } from any $good_ports to any > ipfw add allow { tcp or udp } from ant to $my_server $good_ports > > If you care about both value-repeating, limit of 30 items and slightly about > speed of packet processing, then you'd better classify your traffic with > or-blocks on start of ruleset with tags: > > ipfw add 1 count tag 1 { src-port 20,21,25,110,443,993,995,1025-65535 \ > or src-port 1,2,3,4,5,6,7,8,9,10,11,12,13,...long-list2...,29,30 \ > or src-port ...list3... } // can have up to 8 full 30-port blocks per rule > ipfw add 2 count tag 2 dst-port 135,137-139,445 // and so on > > Packet can have more than one tag at a time, so then you can write like: > > ipfw add queue 100 udp from any to any tagged 3 > ipfw add allow { tcp or udp } from any to any tagged 1,2 > > > And if your suggested port table is concerned on a per-packet performance, like > our IP tables do, then how do you suggest it to be implemented in-kernel? > Current tables for IP are radix trees, they consume a lot of kernel memory > (which is a scarce resource) and process in term of mask - but it is not > handy to specify ports in form like "128/8". And any form of tree will consume > to a lot of memory per entry. > > It can be thought as a bit set, one bit for every port, very fast, but will > consume 8K per one table - 1 meg for 128 such tables, unacceptable, again. > > So, I think it is best to use tags for your purposes. For small number of port entries I thought port lookup table functionality is quite useful. It gives benefit like no need to modify existing rule, adding/deleting port entries is easy. I did some small tests and it seems like working. Patches are at: http://people.freebsd.org/~ganbold/ipfw_port_table/ The output of some usage samples is at: http://people.freebsd.org/~ganbold/ipfw_port_table/ipfw_port_table_usage_sample.txt Patches can be successfully applied to CURRENT. Didn't test RELENG_7 due to no RELENG_7 PC :) Please let me know your thoughts. I'm happy to discuss to improve the patch. Correct me if I'm doing something wrong here. thanks, Ganbold From raffaele.delorenzo at libero.it Thu Sep 25 14:01:37 2008 From: raffaele.delorenzo at libero.it (raffaele.delorenzo@libero.it) Date: Thu Sep 25 14:01:48 2008 Subject: [IPFW add ARP support] - Request for testing Message-ID: Hi all, In the last 2 weeks i implemented a new filter method inside the ipfw firewall for ARP protocols. My idea for the new method was to create a new "proto" microinstruction exclusively for ARP protocol named "arp". This method permits filter tering from/to particular MAC address to be restricted to ARP protocol. Example: ipfw add deny arp from 52:54:00:12:34:56 to 00:11:43:cd:87:6t // Deny all ARP packets generated by "from" and destinated to "to". The wildcard "any" and "me" are supported; the semantic is the same for all old protocol rules: ipfw add deny arp from 00:11:43:cd:87:6t to any Moreover, I implemented some filter methods that restrict the filtering to some ARP header fields: 1) Source MAC address (srcmac-arp) 2) Source IP address (srcip-arp) 3) Destination MAC address (dstmac-arp) 4) Destination IP address (dstip-arp) Example: ./ipfw add deny arp from 00:11:43:cd:87:6e to 52:54:00:12:34:56 srcmac-arp 52:54:00:12:34:56 dstip-arp 192.9.217.29 To work properly, the ARP implementation requires that ipfw receives packets from Layer 2, In other words, you must set the sysctl variable "net.link.ether.ipfw=1". I attached the new sources and all diffs with reference to FreeBSD 7.0 Release source Tree. Please let me know what you think about this work and if possible eventually test it. Ciao Ciao Raffaele -------------- next part -------------- A non-text attachment was scrubbed... Name: =?iso-8859-1?Q?ipfw=5Farp=5Fext.tar.bz2?= Type: application/octet-stream Size: 118186 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20080925/f537a2f9/iso-8859-1Qipfw5Farp5Fext.tar-0001.obj From gbell72 at rogers.com Thu Sep 25 20:25:35 2008 From: gbell72 at rogers.com (Gardner Bell) Date: Thu Sep 25 20:25:42 2008 Subject: rate limit syn Message-ID: <92406.8902.qm@web88001.mail.re2.yahoo.com> Just a quick question: Does ipfw or dummynet have an option to rate limit the amount of syn packets sent to the same destination address, and port number in say 10 second period? Or is net.inet.tcp_syncookies enough protection in the case of a syn flood. Gardner Bell From gleb.kurtsou at gmail.com Fri Sep 26 09:12:03 2008 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Fri Sep 26 09:12:09 2008 Subject: [IPFW add ARP support] - Request for testing In-Reply-To: References: Message-ID: <4c1d27f20809260151u4e44bb8epee482eb0eafebd0a@mail.gmail.com> On Thu, Sep 25, 2008 at 4:49 PM, raffaele.delorenzo@libero.it wrote: > Hi all, > In the last 2 weeks i implemented a new filter method inside the ipfw firewall for ARP protocols. > My idea for the new method was to create a new "proto" microinstruction exclusively for ARP protocol named "arp". This method permits filter tering from/to particular MAC address to be restricted to ARP protocol. > > Example: > > ipfw add deny arp from 52:54:00:12:34:56 to 00:11:43:cd:87:6t // Deny all ARP packets generated by "from" and destinated to "to". > > The wildcard "any" and "me" are supported; the semantic is the same for all old protocol rules: > > ipfw add deny arp from 00:11:43:cd:87:6t to any > > > Moreover, I implemented some filter methods that restrict the filtering to some ARP header fields: > > 1) Source MAC address (srcmac-arp) > 2) Source IP address (srcip-arp) > 3) Destination MAC address (dstmac-arp) > 4) Destination IP address (dstip-arp) > > Example: > > ./ipfw add deny arp from 00:11:43:cd:87:6e to 52:54:00:12:34:56 srcmac-arp 52:54:00:12:34:56 dstip-arp 192.9.217.29 > > To work properly, the ARP implementation requires that ipfw receives packets from Layer 2, In other words, you must set the sysctl variable "net.link.ether.ipfw=1". > > I attached the new sources and all diffs with reference to FreeBSD 7.0 Release source Tree. Please let me know what you think about this work and if possible eventually test it. > > Ciao Ciao > Raffaele > > _______________________________________________ > 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" > Just my 2 cents. There is another implementation of ARP filtering with IPFW available. It was implemented as a part of Google Summer of Code'2008. I'm still waiting for a review by Max Laier Original message containing path to freebsd-net@: http://lists.freebsd.org/pipermail/freebsd-net/2008-September/019458.html From linimon at FreeBSD.org Mon Sep 29 09:31:34 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Sep 29 09:31:40 2008 Subject: bin/127707: ipfw(8): ipfw add 10 count ip from any to 172.16.0.1, me does not work Message-ID: <200809290931.m8T9VYxO032443@freefall.freebsd.org> Old Synopsis: ipfw add 10 count ip from any to 172.16.0.1,me New Synopsis: ipfw(8): ipfw add 10 count ip from any to 172.16.0.1,me does not work Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Mon Sep 29 09:30:46 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127707 From bugmaster at FreeBSD.org Mon Sep 29 11:06:52 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 29 11:07:55 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200809291106.m8TB6q8W040828@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 bin/127707 ipfw ipfw(8): ipfw add 10 count ip from any to 172.16.0.1,m 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 kern/126980 ipfw ipfw(8) hangs system o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher 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 speci 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 49 problems total. From kerbzo at gmail.com Mon Sep 29 20:57:52 2008 From: kerbzo at gmail.com (kerbzo) Date: Mon Sep 29 20:57:59 2008 Subject: pr kern/126980 fixed Message-ID: <917decf00809291325idec9e2an7a86215f8c16f307@mail.gmail.com> Hi, this patch: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=152621+0+current/cvs-src fixed kern/126980 . Thank you very much, best regards, KS From kerbzo at gmail.com Mon Sep 29 21:10:03 2008 From: kerbzo at gmail.com (kerbzo) Date: Mon Sep 29 21:10:10 2008 Subject: kern/126980: ipfw(8) hangs system Message-ID: <200809292110.m8TLA3dS093583@freefall.freebsd.org> The following reply was made to PR kern/126980; it has been noted by GNATS. From: kerbzo To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/126980: ipfw(8) hangs system Date: Mon, 29 Sep 2008 22:39:14 +0200 fixed by http://docs.freebsd.org/cgi/getmsg.cgi?fetch=152621+0+current/cvs-src From rwatson at FreeBSD.org Mon Sep 29 21:15:47 2008 From: rwatson at FreeBSD.org (rwatson@FreeBSD.org) Date: Mon Sep 29 21:15:53 2008 Subject: kern/126980: ipfw(8) hangs system Message-ID: <200809292115.m8TLFkRj095218@freefall.freebsd.org> Synopsis: ipfw(8) hangs system State-Changed-From-To: open->closed State-Changed-By: rwatson State-Changed-When: Mon Sep 29 21:14:14 UTC 2008 State-Changed-Why: Close at request of submitter - believed fixed by ip_fw2.c:1.175.2.12. If you epxerience further problems, please let me know, and thanks for the bug report and followup! http://www.freebsd.org/cgi/query-pr.cgi?pr=126980 From rwatson at FreeBSD.org Tue Sep 30 16:17:48 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Sep 30 16:17:53 2008 Subject: pr kern/126980 fixed In-Reply-To: <917decf00809291325idec9e2an7a86215f8c16f307@mail.gmail.com> References: <917decf00809291325idec9e2an7a86215f8c16f307@mail.gmail.com> Message-ID: On Mon, 29 Sep 2008, kerbzo wrote: > this patch: > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=152621+0+current/cvs-src > > fixed kern/126980 . I've gone ahead and closed the PR; thanks for the bug report! Robert N M Watson Computer Laboratory University of Cambridge