From marta at freebsd.org Fri May 1 20:22:34 2009 From: marta at freebsd.org (Marta Carbone) Date: Fri May 1 20:23:09 2009 Subject: SoC2009: Ipfw and dummyent improvements Message-ID: <20090501200931.GA55379@onelab2.iet.unipi.it> Hello, my name is Marta Carbone, I am at the first year of my PhD program in Information Engineering at the University of Pisa. As part of the Google SoC I will work on FreeBSD ipfw and dummynet. My mentor is Luigi Rizzo. The main goal of the project is to revise and improve the ipfw and dummynet subsystems. The project will mainly involve: - the kernel source code, making it more manageable, splitting large functions, improving the microinstruction compiler; - the userland kernel-interface, identifying locking issues or performance problems. A more detailed version of the proposal can be found on the FreeBSD Wiki page: http://wiki.freebsd.org/SOC2009MartaCarbone marta From fabian at wenks.ch Sun May 3 14:26:30 2009 From: fabian at wenks.ch (Fabian Wenk) Date: Sun May 3 14:26:35 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49F5DB12.7080502@yan.com.br> References: <49F06985.1000303@yan.com.br> <49F08071.1070905@ibctech.ca> <49F1D992.9000001@yan.com.br> <20090425024635.O89549@sola.nimnet.asn.au> <49F5DB12.7080502@yan.com.br> Message-ID: <49FDA98B.6020105@wenks.ch> Hello Daniel On 27.04.09 18:19, Daniel Dias Gon?alves wrote: > What may be happening ? I'm with polling enabled on all interfaces, can > you influence ? > If I disable the polling, no network interface work, begins to display > "em4 watchdog timeout". If you are using polling on the Ethernet interfaces you need to increase the HZ to around 2000 - 5000 (more details in the polling(4) manpage). Set it either in the /boot/loder.conf with "kern.hz=5000" and reboot or in the kernel config with "options HZ=5000" and rebuild kernel and reboot. bye Fabian From pchychi at gmail.com Sun May 3 20:55:06 2009 From: pchychi at gmail.com (Payam Chychi) Date: Sun May 3 20:55:12 2009 Subject: IPFW MAX RULES COUNT PERFORMANCE In-Reply-To: <49FDA98B.6020105@wenks.ch> References: <49F06985.1000303@yan.com.br> <49F08071.1070905@ibctech.ca> <49F1D992.9000001@yan.com.br> <20090425024635.O89549@sola.nimnet.asn.au> <49F5DB12.7080502@yan.com.br> <49FDA98B.6020105@wenks.ch> Message-ID: On Sun, May 3, 2009 at 7:26 AM, Fabian Wenk wrote: > Hello Daniel > > On 27.04.09 18:19, Daniel Dias Gon?alves wrote: >> >> What may be happening ? I'm with polling enabled on all interfaces, can >> you influence ? > >> If I disable the polling, no network interface work, begins to display >> "em4 watchdog timeout". > > If you are using polling on the Ethernet interfaces you need to increase the > HZ to around 2000 - 5000 (more details in the polling(4) manpage). Set it > either in the /boot/loder.conf with "kern.hz=5000" and reboot or in the > kernel config with "options HZ=5000" and rebuild kernel and reboot. > > > bye > Fabian > _______________________________________________ > 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" > what i never understood is why run acl and accounting on the same box and kill your network? run one box for acl building and another on a span (monitor port) to do accounting on the site. For your span port, do both RX/TX so you can see bi-directional and since this is done on the network layer, you will not have as much latency... maybe 10%, if even that. -- Payam Tarverdyan Chychi Network Security Specialist / Network Engineer From bugmaster at FreeBSD.org Mon May 4 11:07:54 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 4 11:08:59 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200905041107.n44B7qrD098622@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 57 problems total. From msurucu at karaelmas.edu.tr Thu May 7 19:00:15 2009 From: msurucu at karaelmas.edu.tr (=?iso-8859-9?B?TXVyYXQgU/xy/GP8?=) Date: Thu May 7 19:00:47 2009 Subject: kern/131601: [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) Message-ID: <200905071900.n47J09II075261@freefall.freebsd.org> The following reply was made to PR kern/131601; it has been noted by GNATS. From: =?iso-8859-9?B?TXVyYXQgU/xy/GP8?= To: , Cc: Subject: Re: kern/131601: [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) Date: Thu, 7 May 2009 21:41:58 +0300 Bu, MIME biçiminde bir çok parçalı iletidir. ------=_NextPart_000_0001_01C9CF5C.A8DF7F10 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: 7bit FreeBSD 7.2 - i386 # kgdb kernel.debug /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 06 fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc5abe98b stack pointer = 0x28:0xe58109ac frame pointer = 0x28:0xe5810a28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 30 (em1 taskq) trap number = 12 panic: page fault cpuid = 2 Uptime: 1d3h25m11s Physical memory: 2035 MB Dumping 209 MB: 194 178 162 146 130 114 98 82 66 50 34 18 2 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/ipl.ko...Reading symbols from /boot/kernel/ipl.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipl.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) list *0xc5abe98b 0xc5abe98b is in nat_new (/usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c:2577) . 2572 nat->nat_ifps[1] = np->in_ifps[1]; 2573 nat->nat_ptr = np; 2574 nat->nat_p = fin->fin_p; 2575 nat->nat_mssclamp = np->in_mssclamp; 2576 if (nat->nat_p == IPPROTO_TCP) 2577 nat->nat_seqnext[0] = ntohl(tcp->th_seq); 2578 2579 if ((np->in_apr != NULL) && ((ni->nai_flags & NAT_SLAVE) == 0)) 2580 if (appr_new(fin, nat) == -1) 2581 return -1; (kgdb) backtrace #0 doadump () at pcpu.h:196 #1 0xc07dfa4f in boot (howto=260) at ../../../kern/kern_shutdown.c:418 #2 0xc07dfd32 in panic (fmt=Variable "fmt" is not available. ) at ../../../kern/kern_shutdown.c:574 #3 0xc0ae8573 in trap_fatal (frame=0xe581096c, eva=4) at ../../../i386/i386/trap.c:939 #4 0xc0ae8763 in trap_pfault (frame=0xe581096c, usermode=0, eva=4) at ../../../i386/i386/trap.c:852 #5 0xc0ae90e8 in trap (frame=0xe581096c) at ../../../i386/i386/trap.c:530 #6 0xc0acd16b in calltrap () at ../../../i386/i386/exception.s:159 #7 0xc5abe98b in nat_new (fin=0xe5810a84, np=0xc5b13400, natsave=0x0, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c:2577 #8 0xc5ac2654 in fr_checknatin (fin=0xe5810a84, passp=0xe5810b30) at /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c:4122 #9 0xc5adb833 in fr_check (ip=0xc5ba5010, hlen=20, ifp=0xc567a800, out=0, mp=0xe5810b7c) at /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/fil.c:2572 #10 0xc5ad37ee in fr_check_wrapper (arg=0x0, mp=0xe5810b7c, ifp=0xc567a800, dir=1) at /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil_freebsd. c:178 #11 0xc08894a8 in pfil_run_hooks (ph=0xc0ce5580, mp=0xe5810bcc, ifp=0xc567a800, dir=1, inp=0x0) at ../../../net/pfil.c:78 #12 0xc08cf801 in ip_input (m=0xc6c8de00) at ../../../netinet/ip_input.c:416 #13 0xc0887903 in netisr_dispatch (num=2, m=0xc6c8de00) at ../../../net/netisr.c:185 #14 0xc087b9c1 in ether_demux (ifp=0xc567a800, m=0xc6c8de00) at ../../../net/if_ethersubr.c:834 #15 0xc087be2f in ether_input (ifp=0xc567a800, m=0xc6c8de00) at ../../../net/if_ethersubr.c:692 #16 0xc05bf099 in em_rxeof (adapter=0xc567d000, count=99) at ../../../dev/e1000/if_em.c:4539 #17 0xc05bf21e in em_handle_rxtx (context=0xc567d000, pending=1) at ../../../dev/e1000/if_em.c:1702 ---Type to continue, or q to quit--- #18 0xc0815eab in taskqueue_run (queue=0xc566c480) at ../../../kern/subr_taskqueue.c:282 #19 0xc0816008 in taskqueue_thread_loop (arg=0xc568135c) at ../../../kern/subr_taskqueue.c:401 #20 0xc07bc298 in fork_exit (callout=0xc0815fa0 , arg=0xc568135c, frame=0xe5810d38) at ../../../kern/kern_fork.c:810 #21 0xc0acd1e0 in fork_trampoline () at ../../../i386/i386/exception.s:264 ------=_NextPart_000_0001_01C9CF5C.A8DF7F10 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable

FreeBSD 7.2 – i386

# kgdb kernel.debug /var/crash/vmcore.0 =

GNU gdb 6.1.1 [FreeBSD]

Copyright 2004 Free Software Foundation, = Inc.

GDB is free software, covered by the GNU General = Public License, and you are

welcome to change it and/or distribute copies of it = under certain conditions.

Type "show copying" to see the = conditions.

There is absolutely no warranty for GDB.=A0 Type = "show warranty" for details.

This GDB was configured as "i386-marcel-freebsd"...

 

Unread portion of the kernel message = buffer:

 

 

Fatal trap 12: page fault while in kernel = mode

cpuid =3D 2; apic id =3D 06

fault virtual address=A0=A0 =3D 0x4

fault code=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =3D supervisor read, page not present

instruction pointer=A0=A0=A0=A0 =3D = 0x20:0xc5abe98b

stack pointer=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D = 0x28:0xe58109ac

frame pointer=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D = 0x28:0xe5810a28

code segment=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D = base 0x0, limit 0xfffff, type 0x1b

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 =3D DPL 0, pres 1, def32 1, gran 1

processor eflags=A0=A0=A0=A0=A0=A0=A0 =3D interrupt = enabled, resume, IOPL =3D 0

current process=A0=A0=A0=A0=A0=A0=A0=A0 =3D 30 (em1 = taskq)

trap number=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D = 12

panic: page fault

cpuid =3D 2

Uptime: 1d3h25m11s

Physical memory: 2035 MB

Dumping 209 MB: 194 178 162 146 130 114 98 82 66 50 = 34 18 2

 

Reading symbols from /boot/kernel/acpi.ko...Reading = symbols from /boot/kernel/acpi.ko.symbols...done.

done.

Loaded symbols for = /boot/kernel/acpi.ko

Reading symbols from /boot/kernel/ipl.ko...Reading = symbols from /boot/kernel/ipl.ko.symbols...done.

done.

Loaded symbols for = /boot/kernel/ipl.ko

#0=A0 doadump () at pcpu.h:196

196=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __asm = __volatile("movl %%fs:0,%0" : "=3Dr" (td));

 

 

(kgdb) list *0xc5abe98b

0xc5abe98b is in nat_new (/usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c:25= 77).

2572=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = nat->nat_ifps[1] =3D np->in_ifps[1];

2573=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = nat->nat_ptr =3D np;

2574=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 nat->nat_p = =3D fin->fin_p;

2575=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = nat->nat_mssclamp =3D np->in_mssclamp;

2576=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if = (nat->nat_p =3D=3D IPPROTO_TCP)

2577=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 nat->nat_seqnext[0] =3D ntohl(tcp->th_seq);

2578

2579=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if = ((np->in_apr !=3D NULL) && ((ni->nai_flags & NAT_SLAVE) =3D=3D 0))

2580=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 if (appr_new(fin, nat) =3D=3D -1)

2581=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return -1;

 

 

(kgdb) backtrace

#0=A0 doadump () at pcpu.h:196

#1=A0 0xc07dfa4f in boot (howto=3D260) at ../../../kern/kern_shutdown.c:418

#2=A0 0xc07dfd32 in panic (fmt=3DVariable = "fmt" is not available.

) at = ../../../kern/kern_shutdown.c:574

#3=A0 0xc0ae8573 in trap_fatal (frame=3D0xe581096c, = eva=3D4) at ../../../i386/i386/trap.c:939

#4=A0 0xc0ae8763 in trap_pfault = (frame=3D0xe581096c, usermode=3D0, eva=3D4) at ../../../i386/i386/trap.c:852

#5=A0 0xc0ae90e8 in trap (frame=3D0xe581096c) at ../../../i386/i386/trap.c:530

#6=A0 0xc0acd16b in calltrap () at ../../../i386/i386/exception.s:159

#7=A0 0xc5abe98b in nat_new (fin=3D0xe5810a84, = np=3D0xc5b13400, natsave=3D0x0, flags=3DVariable "flags" is not = available.

)

=A0=A0=A0 at /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c:257= 7

#8=A0 0xc5ac2654 in fr_checknatin = (fin=3D0xe5810a84, passp=3D0xe5810b30)

=A0=A0=A0 at /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c:412= 2

#9=A0 0xc5adb833 in fr_check (ip=3D0xc5ba5010, = hlen=3D20, ifp=3D0xc567a800, out=3D0, mp=3D0xe5810b7c)

=A0=A0=A0 at /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/fil.c:2572

#10 0xc5ad37ee in fr_check_wrapper (arg=3D0x0, = mp=3D0xe5810b7c, ifp=3D0xc567a800, dir=3D1)

=A0=A0=A0 at /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil_freeb= sd.c:178

#11 0xc08894a8 in pfil_run_hooks (ph=3D0xc0ce5580, mp=3D0xe5810bcc, ifp=3D0xc567a800, dir=3D1, inp=3D0x0)

=A0=A0=A0 at ../../../net/pfil.c:78

#12 0xc08cf801 in ip_input (m=3D0xc6c8de00) at ../../../netinet/ip_input.c:416

#13 0xc0887903 in netisr_dispatch (num=3D2, = m=3D0xc6c8de00) at ../../../net/netisr.c:185

#14 0xc087b9c1 in ether_demux (ifp=3D0xc567a800, = m=3D0xc6c8de00) at ../../../net/if_ethersubr.c:834

#15 0xc087be2f in ether_input (ifp=3D0xc567a800, = m=3D0xc6c8de00) at ../../../net/if_ethersubr.c:692

#16 0xc05bf099 in em_rxeof (adapter=3D0xc567d000, = count=3D99) at ../../../dev/e1000/if_em.c:4539

#17 0xc05bf21e in em_handle_rxtx = (context=3D0xc567d000, pending=3D1) at ../../../dev/e1000/if_em.c:1702

---Type <return> to continue, or q = <return> to quit---

#18 0xc0815eab in taskqueue_run = (queue=3D0xc566c480) at ../../../kern/subr_taskqueue.c:282

#19 0xc0816008 in taskqueue_thread_loop = (arg=3D0xc568135c) at ../../../kern/subr_taskqueue.c:401

#20 0xc07bc298 in fork_exit (callout=3D0xc0815fa0 <taskqueue_thread_loop>, arg=3D0xc568135c, = frame=3D0xe5810d38)

=A0=A0=A0 at = ../../../kern/kern_fork.c:810

#21 0xc0acd1e0 in fork_trampoline () at ../../../i386/i386/exception.s:264

 

 



__________ ESET NOD32 Antivirus Ak=FDll=FD G=FCvenlik = taraf=FDndan sa=F0lanan bilgiler, vir=FCs imza veritaban=FD = s=FCr=FCm=FC: 4056 (20090506) __________

=DDleti ESET NOD32 = Antivirus Ak=FDll=FD G=FCvenlik taraf=FDndan denetlendi.

http://www.nod32.com.tr
------=_NextPart_000_0001_01C9CF5C.A8DF7F10-- From raffaele.delorenzo at libero.it Thu May 7 20:23:01 2009 From: raffaele.delorenzo at libero.it (Raffaele De Lorenzo) Date: Thu May 7 20:23:09 2009 Subject: [ipfw patch - add ipv6 support for table mechanism] request for testing/commit Message-ID: <3233DB7C-06E8-4AFE-9704-0F900925DAE3@libero.it> Hi all, I extended the ipfw table mechanism to IPv6 protocol and now i need some people for testing and next commit it. The code is stable but you must be careful about possible ambiguous parser semantics. Now you must insert IPv6 addresses inside a table: ipfw table 1 add fe80::1 And you can create IPv6 rules about this table: ipfw add deny tcp from table6(1) to any dst-port 22 ipfw add deny icmp6 from any to table6(1) The "table6" semantic tell the difference betwen the IPv4 semantic ("table"). The following changes are made on the ipfw2 sources: KERNEL SPACE: ip_fw.h 1) Added 2 new OPCODES: O_IP6_SRC_LOOKUP, O_IP6_DST_LOOKUP 2) Added the follow fields in "ipfw_table_entry" structure: struct in6_addr addr6, mask6; uint8_t proto; ip_fw2.c -------------- next part -------------- 1) Added the follow fields in "struct table_entry" structure: struct sockaddr_in6 addr6, mask6; uint8_t proto; 2) Some changes inside the "add_table_entry" function. 3) Some changes inside the "del_table_entry" function. 4) Some changes inside the "flush_table_entry" function. 5) Some changes inside the "lookup_table" function. 6) Some changes inside the "dump_table_entry" function. 7) Added a new function named "set_proto_table". 8) Added the two new OPCODES inside the "ipfw_check()" function. 9) Added the two new OPCODES inside the "check_ipfw_struct" function. USER SPACE: ipfw2.c 1) Added some changes on "table_handler" function 2) Added some changes on "show_ipfw" function 3) Added some changes on "print_ip6" function 4) Added some changes on "fill_ip6" function 5) Added some changes on "add_dstip6" function 6) Added some changes on "add_srcip6" function 7) Added some changes on "add_src" function 8) Added some changes on "add_dst" function I updated the man pages. INSTALLATION INSTRUCTIONS: Put the "ip_fw2.c" and "ip_fw.h" files inside the "/sys/netinet/ directory" Put the "ipfw2.c" file inside the /src/sbin/ipfw/ directory Rebuild the ipfw kernel module or rebuild you kernel Rebuild the ipfw bin or the entire SBIN. The Sources was tested on FreeBSD 7.2 Release. Let me know any troubles Ciao Raffaele From steve at ibctech.ca Thu May 7 20:47:24 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu May 7 20:47:31 2009 Subject: [ipfw patch - add ipv6 support for table mechanism] request for testing/commit In-Reply-To: <3233DB7C-06E8-4AFE-9704-0F900925DAE3@libero.it> References: <3233DB7C-06E8-4AFE-9704-0F900925DAE3@libero.it> Message-ID: <4A0348D2.5050906@ibctech.ca> Raffaele De Lorenzo wrote: > Put the "ip_fw2.c" and "ip_fw.h" files inside the "/sys/netinet/ > directory" > Put the "ipfw2.c" file inside the /src/sbin/ipfw/ directory > > Rebuild the ipfw kernel module or rebuild you kernel > Rebuild the ipfw bin or the entire SBIN. > > The Sources was tested on FreeBSD 7.2 Release. > > Let me know any troubles Excellent work! However, the kernel module builds fine, but the userland binary does not. fbsd1# uname -a FreeBSD fbsd1 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009 root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 ===> ipfw (all) Warning: Object directory not changed from original /usr/src/sbin/ipfw cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c ipfw2.c ipfw2.c: In function 'print_ip6': ipfw2.c:1215: error: 'O_IP6_SRC_LOOKUP' undeclared (first use in this function) ipfw2.c:1215: error: (Each undeclared identifier is reported only once ipfw2.c:1215: error: for each function it appears in.) ipfw2.c:1216: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this function) ipfw2.c:1219: warning: format '%u' expects type 'unsigned int', but argument 2 has type 'struct in6_addr' ipfw2.c: In function 'show_prerequisites': ipfw2.c:1453: warning: suggest explicit braces to avoid ambiguous 'else' ipfw2.c: In function 'show_ipfw': ipfw2.c:1742: error: 'O_IP6_SRC_LOOKUP' undeclared (first use in this function) ipfw2.c:1756: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this function) ipfw2.c: In function 'fill_ip6': ipfw2.c:3061: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this function) ipfw2.c: In function 'add_srcip6': ipfw2.c:3190: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this function) ipfw2.c:3191: error: 'O_IP6_SRC_LOOKUP' undeclared (first use in this function) ipfw2.c: In function 'add_dstip6': ipfw2.c:3211: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this function) ipfw2.c: In function 'setup_redir_addr': ipfw2.c:3607: warning: unused variable 'i' ipfw2.c: In function 'setup_redir_proto': ipfw2.c:3826: warning: unused variable 'i' ipfw2.c: In function 'config_nat': ipfw2.c:4013: warning: unused variable 'ip' ipfw2.c: In function 'table_handler': ipfw2.c:5928: error: 'ipfw_table_entry' has no member named 'proto' ipfw2.c:5928: error: 'IPFW_IPV4' undeclared (first use in this function) ipfw2.c:5938: error: 'ipfw_table_entry' has no member named 'addr6' ipfw2.c:5943: error: 'ipfw_table_entry' has no member named 'proto' ipfw2.c:5943: error: 'IPFW_IPV6' undeclared (first use in this function) ipfw2.c:5944: error: 'ipfw_table_entry' has no member named 'mask6' ipfw2.c:6005: error: 'struct _ipfw_table_entry' has no member named 'proto' ipfw2.c:6024: error: 'struct _ipfw_table_entry' has no member named 'mask6' ipfw2.c:6025: error: 'struct _ipfw_table_entry' has no member named 'addr6' ipfw2.c:6030: error: 'struct _ipfw_table_entry' has no member named 'proto' ipfw2.c: In function 'show_nat': ipfw2.c:6046: warning: unused variable 'lav' *** Error code 1 Stop in /usr/src/sbin/ipfw. *** Error code 1 Steve From raffaele.delorenzo at libero.it Thu May 7 21:23:20 2009 From: raffaele.delorenzo at libero.it (Raffaele De Lorenzo) Date: Thu May 7 21:23:27 2009 Subject: [ipfw patch - add ipv6 support for table mechanism] request for testing/commit In-Reply-To: <4A0348D2.5050906@ibctech.ca> References: <3233DB7C-06E8-4AFE-9704-0F900925DAE3@libero.it> <4A0348D2.5050906@ibctech.ca> Message-ID: <5E7FA6DC-E311-406D-8F9A-D832BC80FA98@libero.it> Thank you Steve. I think that this is a header problem (O_IP6_SRC_LOOKUP ecc are defined inside the header).... are you posted the new "ip_fw.h" file in "/sys/netinet/" directory? Next type "make clean && make" to recompile the userland binary. Raffaele On 07/mag/09, at 22:47, Steve Bertrand wrote: > Raffaele De Lorenzo wrote: > >> Put the "ip_fw2.c" and "ip_fw.h" files inside the "/sys/netinet/ >> directory" >> Put the "ipfw2.c" file inside the /src/sbin/ipfw/ directory >> >> Rebuild the ipfw kernel module or rebuild you kernel >> Rebuild the ipfw bin or the entire SBIN. >> >> The Sources was tested on FreeBSD 7.2 Release. >> >> Let me know any troubles > > Excellent work! However, the kernel module builds fine, but the > userland > binary does not. > > fbsd1# uname -a > > FreeBSD fbsd1 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 > UTC 2009 root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/ > GENERIC i386 > > ===> ipfw (all) > Warning: Object directory not changed from original /usr/src/sbin/ipfw > cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Wall > -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c ipfw2.c > ipfw2.c: In function 'print_ip6': > ipfw2.c:1215: error: 'O_IP6_SRC_LOOKUP' undeclared (first use in this > function) > ipfw2.c:1215: error: (Each undeclared identifier is reported only once > ipfw2.c:1215: error: for each function it appears in.) > ipfw2.c:1216: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this > function) > ipfw2.c:1219: warning: format '%u' expects type 'unsigned int', but > argument 2 has type 'struct in6_addr' > ipfw2.c: In function 'show_prerequisites': > ipfw2.c:1453: warning: suggest explicit braces to avoid ambiguous > 'else' > ipfw2.c: In function 'show_ipfw': > ipfw2.c:1742: error: 'O_IP6_SRC_LOOKUP' undeclared (first use in this > function) > ipfw2.c:1756: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this > function) > ipfw2.c: In function 'fill_ip6': > ipfw2.c:3061: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this > function) > ipfw2.c: In function 'add_srcip6': > ipfw2.c:3190: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this > function) > ipfw2.c:3191: error: 'O_IP6_SRC_LOOKUP' undeclared (first use in this > function) > ipfw2.c: In function 'add_dstip6': > ipfw2.c:3211: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this > function) > ipfw2.c: In function 'setup_redir_addr': > ipfw2.c:3607: warning: unused variable 'i' > ipfw2.c: In function 'setup_redir_proto': > ipfw2.c:3826: warning: unused variable 'i' > ipfw2.c: In function 'config_nat': > ipfw2.c:4013: warning: unused variable 'ip' > ipfw2.c: In function 'table_handler': > ipfw2.c:5928: error: 'ipfw_table_entry' has no member named 'proto' > ipfw2.c:5928: error: 'IPFW_IPV4' undeclared (first use in this > function) > ipfw2.c:5938: error: 'ipfw_table_entry' has no member named 'addr6' > ipfw2.c:5943: error: 'ipfw_table_entry' has no member named 'proto' > ipfw2.c:5943: error: 'IPFW_IPV6' undeclared (first use in this > function) > ipfw2.c:5944: error: 'ipfw_table_entry' has no member named 'mask6' > ipfw2.c:6005: error: 'struct _ipfw_table_entry' has no member named > 'proto' > ipfw2.c:6024: error: 'struct _ipfw_table_entry' has no member named > 'mask6' > ipfw2.c:6025: error: 'struct _ipfw_table_entry' has no member named > 'addr6' > ipfw2.c:6030: error: 'struct _ipfw_table_entry' has no member named > 'proto' > ipfw2.c: In function 'show_nat': > ipfw2.c:6046: warning: unused variable 'lav' > *** Error code 1 > > Stop in /usr/src/sbin/ipfw. > *** Error code 1 > > Steve > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw- > unsubscribe@freebsd.org" From steve at ibctech.ca Thu May 7 22:40:08 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu May 7 22:40:14 2009 Subject: [ipfw patch - add ipv6 support for table mechanism] request for testing/commit In-Reply-To: <5E7FA6DC-E311-406D-8F9A-D832BC80FA98@libero.it> References: <3233DB7C-06E8-4AFE-9704-0F900925DAE3@libero.it> <4A0348D2.5050906@ibctech.ca> <5E7FA6DC-E311-406D-8F9A-D832BC80FA98@libero.it> Message-ID: <4A03633E.40302@ibctech.ca> Raffaele De Lorenzo wrote: > Thank you Steve. > I think that this is a header problem (O_IP6_SRC_LOOKUP ecc are defined > inside the header).... are you posted the new "ip_fw.h" file in > "/sys/netinet/" directory? I did: fbsd1# ll /usr/src/sys/netinet | grep ip_fw.h -rw-r--r-- 1 root wheel 20916 May 7 16:38 ip_fw.h fbsd1# grep O_IP6 /usr/src/sys/netinet/ip_fw.h O_IP6_SRC_LOOKUP, /* arg1=table number, u32=value */ O_IP6_DST_LOOKUP, /* arg1=table number, u32=value */ O_IP6_SRC, /* address without mask */ O_IP6_SRC_ME, /* my addresses */ O_IP6_SRC_MASK, /* address with the mask */ O_IP6_DST, O_IP6_DST_ME, O_IP6_DST_MASK, O_IP6, fbsd1# cd /usr/src/sbin/ipfw fbsd1# make clean rm -f ipfw ipfw2.o dummynet.o ipv6.o main.o nat.o altq.o ipfw.8.gz ipfw.8.cat.gz ...but the problem persists with "make". I don't do a lot of custom patching, so I'm hoping that this is my fault. I can provide SSH access to the box if you can help me figure out the problem. Cheers, Steve From vk at kbb.ru Fri May 8 01:30:04 2009 From: vk at kbb.ru (Vladimir Kurtukov) Date: Fri May 8 01:30:10 2009 Subject: kern/131601: [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) Message-ID: <200905080130.n481U34D099797@freefall.freebsd.org> The following reply was made to PR kern/131601; it has been noted by GNATS. From: Vladimir Kurtukov To: bug-followup@FreeBSD.org Cc: Subject: kern/131601: [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) Date: Fri, 8 May 2009 08:46:33 +0800 use my patch, it works also, these who using ipnat ftp proxy, need to apply this patch. --- ip_ftp_pxy.c.orig 2007-06-04 10:54:35.000000000 +0800 +++ ip_ftp_pxy.c 2009-05-08 08:48:04.000000000 +0800 @@ -1010,6 +1010,8 @@ return 0; } else if (mlen < 0) { return 0; + } else if (nat->nat_aps == NULL) { + return 0; } aps = nat->nat_aps; --- Best regards, Vladimir From joost at jodocus.org Fri May 8 05:27:32 2009 From: joost at jodocus.org (Joost Bekkers) Date: Fri May 8 05:27:42 2009 Subject: [ipfw patch - add ipv6 support for table mechanism] request for testing/commit In-Reply-To: <4A03633E.40302@ibctech.ca> References: <3233DB7C-06E8-4AFE-9704-0F900925DAE3@libero.it> <4A0348D2.5050906@ibctech.ca> <5E7FA6DC-E311-406D-8F9A-D832BC80FA98@libero.it> <4A03633E.40302@ibctech.ca> Message-ID: <59474.192.168.100.250.1241759416.squirrel@jodocus.org> On Fri, May 8, 2009 00:39, Steve Bertrand wrote: > Raffaele De Lorenzo wrote: >> Thank you Steve. >> I think that this is a header problem (O_IP6_SRC_LOOKUP ecc are defined >> inside the header).... are you posted the new "ip_fw.h" file in >> "/sys/netinet/" directory? > > ...but the problem persists with "make". > I'm guessing /usr/include/ip_fw.h hasn't been updated. It should be the same is /usr/src/sys/netinet/ip_fw.h Joost. From steve at ibctech.ca Fri May 8 06:08:55 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri May 8 06:09:10 2009 Subject: [ipfw patch - add ipv6 support for table mechanism] request for testing/commit In-Reply-To: <59474.192.168.100.250.1241759416.squirrel@jodocus.org> References: <3233DB7C-06E8-4AFE-9704-0F900925DAE3@libero.it> <4A0348D2.5050906@ibctech.ca> <5E7FA6DC-E311-406D-8F9A-D832BC80FA98@libero.it> <4A03633E.40302@ibctech.ca> <59474.192.168.100.250.1241759416.squirrel@jodocus.org> Message-ID: <4A03CC6E.1030506@ibctech.ca> Joost Bekkers wrote: > On Fri, May 8, 2009 00:39, Steve Bertrand wrote: >> Raffaele De Lorenzo wrote: >>> Thank you Steve. >>> I think that this is a header problem (O_IP6_SRC_LOOKUP ecc are defined >>> inside the header).... are you posted the new "ip_fw.h" file in >>> "/sys/netinet/" directory? >> ...but the problem persists with "make". >> > > I'm guessing /usr/include/ip_fw.h hasn't been updated. It should be the > same is /usr/src/sys/netinet/ip_fw.h ... ip_fw.h doesn't appear in my /usr/include: fbsd1# cd /usr/include fbsd1# ll | grep ip_fw fbsd1# ...I'll copy it: fbsd1# cp /usr/src/sys/netinet/ip_fw.h /usr/include fbsd1# ll /usr/include | grep ip_fw.h -rw-r--r-- 1 root wheel 20916 May 8 02:04 ip_fw.h ... try again: fbsd1# cd /usr/src/sbin/ipfw fbsd1# make clean rm -f ipfw ipfw2.o dummynet.o ipv6.o main.o nat.o altq.o ipfw.8.gz ipfw.8.cat.gz fbsd1# make Warning: Object directory not changed from original /usr/src/sbin/ipfw cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c ipfw2.c ipfw2.c: In function 'print_ip6': ipfw2.c:1215: error: 'O_IP6_SRC_LOOKUP' undeclared (first use in this function) ipfw2.c:1215: error: (Each undeclared identifier is reported only once ipfw2.c:1215: error: for each function it appears in.) ipfw2.c:1216: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this function) ipfw2.c:1219: warning: format '%u' expects type 'unsigned int', but argument 2 has type 'struct in6_addr' ipfw2.c: In function 'show_prerequisites': ipfw2.c:1453: warning: suggest explicit braces to avoid ambiguous 'else' ipfw2.c: In function 'show_ipfw': ipfw2.c:1742: error: 'O_IP6_SRC_LOOKUP' undeclared (first use in this function) ipfw2.c:1756: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this function) ipfw2.c: In function 'fill_ip6': ipfw2.c:3061: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this function) ipfw2.c: In function 'add_srcip6': ipfw2.c:3190: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this function) ipfw2.c:3191: error: 'O_IP6_SRC_LOOKUP' undeclared (first use in this function) ipfw2.c: In function 'add_dstip6': ipfw2.c:3211: error: 'O_IP6_DST_LOOKUP' undeclared (first use in this function) ipfw2.c: In function 'setup_redir_addr': ipfw2.c:3607: warning: unused variable 'i' ipfw2.c: In function 'setup_redir_proto': ipfw2.c:3826: warning: unused variable 'i' ipfw2.c: In function 'config_nat': ipfw2.c:4013: warning: unused variable 'ip' ipfw2.c: In function 'table_handler': ipfw2.c:5928: error: 'ipfw_table_entry' has no member named 'proto' ipfw2.c:5928: error: 'IPFW_IPV4' undeclared (first use in this function) ipfw2.c:5938: error: 'ipfw_table_entry' has no member named 'addr6' ipfw2.c:5943: error: 'ipfw_table_entry' has no member named 'proto' ipfw2.c:5943: error: 'IPFW_IPV6' undeclared (first use in this function) ipfw2.c:5944: error: 'ipfw_table_entry' has no member named 'mask6' ipfw2.c:6005: error: 'struct _ipfw_table_entry' has no member named 'proto' ipfw2.c:6024: error: 'struct _ipfw_table_entry' has no member named 'mask6' ipfw2.c:6025: error: 'struct _ipfw_table_entry' has no member named 'addr6' ipfw2.c:6030: error: 'struct _ipfw_table_entry' has no member named 'proto' ipfw2.c: In function 'show_nat': ipfw2.c:6046: warning: unused variable 'lav' *** Error code 1 Stop in /usr/src/sbin/ipfw. Steve ps. I'll re-csup my sources and try again... From jhay at meraka.org.za Fri May 8 06:55:59 2009 From: jhay at meraka.org.za (John Hay) Date: Fri May 8 06:56:06 2009 Subject: [ipfw patch - add ipv6 support for table mechanism] request for testing/commit In-Reply-To: <4A03CC6E.1030506@ibctech.ca> References: <3233DB7C-06E8-4AFE-9704-0F900925DAE3@libero.it> <4A0348D2.5050906@ibctech.ca> <5E7FA6DC-E311-406D-8F9A-D832BC80FA98@libero.it> <4A03633E.40302@ibctech.ca> <59474.192.168.100.250.1241759416.squirrel@jodocus.org> <4A03CC6E.1030506@ibctech.ca> Message-ID: <20090508065551.GA5976@zibbi.meraka.csir.co.za> On Fri, May 08, 2009 at 02:08:46AM -0400, Steve Bertrand wrote: > Joost Bekkers wrote: > > On Fri, May 8, 2009 00:39, Steve Bertrand wrote: > >> Raffaele De Lorenzo wrote: > >>> Thank you Steve. > >>> I think that this is a header problem (O_IP6_SRC_LOOKUP ecc are defined > >>> inside the header).... are you posted the new "ip_fw.h" file in > >>> "/sys/netinet/" directory? > >> ...but the problem persists with "make". > >> > > > > I'm guessing /usr/include/ip_fw.h hasn't been updated. It should be the > > same is /usr/src/sys/netinet/ip_fw.h > > ... ip_fw.h doesn't appear in my /usr/include: > > fbsd1# cd /usr/include > fbsd1# ll | grep ip_fw > fbsd1# > > ...I'll copy it: > > fbsd1# cp /usr/src/sys/netinet/ip_fw.h /usr/include > fbsd1# ll /usr/include | grep ip_fw.h > -rw-r--r-- 1 root wheel 20916 May 8 02:04 ip_fw.h > You are looking in the wrong place: # find /usr/include -name ip_fw.h /usr/include/netinet/ip_fw.h That is the file you should replace. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From raffaele.delorenzo at libero.it Fri May 8 07:35:51 2009 From: raffaele.delorenzo at libero.it (raffaele.delorenzo@libero.it) Date: Fri May 8 11:26:54 2009 Subject: [ipfw patch - add ipv6 support for table mechanism] request for testing/commit Message-ID: Hi, The solution suggested by John is the best way and work. I attached a new archive with a new directory "compiled_i386" that contains the compiled sources (ipfw.ko and ipfw). Ciao Raffaele > On Fri, May 08, 2009 at 02:08:46AM -0400, Steve Bertrand wrote: > > Joost Bekkers wrote: > > > On Fri, May 8, 2009 00:39, Steve Bertrand wrote: > > >> Raffaele De Lorenzo wrote: > > >>> Thank you Steve. > > >>> I think that this is a header problem (O_IP6_SRC_LOOKUP ecc are defined > > >>> inside the header).... are you posted the new "ip_fw.h" file in > > >>> "/sys/netinet/" directory? > > >> ...but the problem persists with "make". > > >> > > > > > > I'm guessing /usr/include/ip_fw.h hasn't been updated. It should be the > > > same is /usr/src/sys/netinet/ip_fw.h > > > > ... ip_fw.h doesn't appear in my /usr/include: > > > > fbsd1# cd /usr/include > > fbsd1# ll | grep ip_fw > > fbsd1# > > > > ...I'll copy it: > > > > fbsd1# cp /usr/src/sys/netinet/ip_fw.h /usr/include > > fbsd1# ll /usr/include | grep ip_fw.h > > -rw-r--r-- 1 root wheel 20916 May 8 02:04 ip_fw.h > > > > You are looking in the wrong place: > > # find /usr/include -name ip_fw.h > /usr/include/netinet/ip_fw.h > > That is the file you should replace. > > John > -- > John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > -------------- next part -------------- A non-text attachment was scrubbed... Name: =?iso-8859-1?Q?ipfw=5Ftable6.tar.bz2?= Type: application/octet-stream Size: 160370 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20090508/707bcd0f/iso-8859-1Qipfw5Ftable6.tar-0001.obj From steve at ibctech.ca Fri May 8 12:55:08 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri May 8 12:55:15 2009 Subject: [ipfw patch - add ipv6 support for table mechanism] request for testing/commit In-Reply-To: <20090508065551.GA5976@zibbi.meraka.csir.co.za> References: <3233DB7C-06E8-4AFE-9704-0F900925DAE3@libero.it> <4A0348D2.5050906@ibctech.ca> <5E7FA6DC-E311-406D-8F9A-D832BC80FA98@libero.it> <4A03633E.40302@ibctech.ca> <59474.192.168.100.250.1241759416.squirrel@jodocus.org> <4A03CC6E.1030506@ibctech.ca> <20090508065551.GA5976@zibbi.meraka.csir.co.za> Message-ID: <4A042BA4.1030501@ibctech.ca> John Hay wrote: > On Fri, May 08, 2009 at 02:08:46AM -0400, Steve Bertrand wrote: >> Joost Bekkers wrote: >>> On Fri, May 8, 2009 00:39, Steve Bertrand wrote: >>>> Raffaele De Lorenzo wrote: >>>>> Thank you Steve. >>>>> I think that this is a header problem (O_IP6_SRC_LOOKUP ecc are defined >>>>> inside the header).... are you posted the new "ip_fw.h" file in >>>>> "/sys/netinet/" directory? >>>> ...but the problem persists with "make". >>>> >>> I'm guessing /usr/include/ip_fw.h hasn't been updated. It should be the >>> same is /usr/src/sys/netinet/ip_fw.h >> ... ip_fw.h doesn't appear in my /usr/include: >> >> fbsd1# cd /usr/include >> fbsd1# ll | grep ip_fw >> fbsd1# >> >> ...I'll copy it: >> >> fbsd1# cp /usr/src/sys/netinet/ip_fw.h /usr/include >> fbsd1# ll /usr/include | grep ip_fw.h >> -rw-r--r-- 1 root wheel 20916 May 8 02:04 ip_fw.h >> > > You are looking in the wrong place: > > # find /usr/include -name ip_fw.h > /usr/include/netinet/ip_fw.h > > That is the file you should replace. Thank you, that did the trick ;) Cheers! Steve From info at lottery.co.uk Sun May 10 15:51:31 2009 From: info at lottery.co.uk (UK NATIONAL LOTTERY) Date: Sun May 10 15:52:12 2009 Subject: National Lottery: Your Email Won Message-ID: <20090510153350.038593C17F@hm1207.locaweb.com.br> United Kingdom National Lottery 101 Bovill Road, London SE23 1EL United Kingdom File #: EGS/2251256003/02 Congratulations, we are pleased to inform you of the result of the United Kingdom National Lottery Award Winners. Your email address have been randomly selected as a winner in the ongoing United Kingdom National Lottery Online program, the draw was held on 30th April, 2009 using a computerized balloting system of selection. The United Kingdom National Lottery is aimed and focused at global development and improvement of living standard across the world. Free £77 Million Pounds won including *four* Ten Million Pounds Winners and *fourteen* Millionaires plus thousands of other cash prizes. Winner from all over the world, India, France, Singapore, USA, United Kingdom, Spain, South America, Malaysia, Indonesia, South Africa, Belgium, Denmark, Ireland and many more. We wish to express our sincere apologies for the late notification, this free award online program is been conducted bi-quarterly. United Kingdom National Lottery Free Award draw was conducted at the Europe Issuing Centre, you were selected from an exclusive list of 1,000,000,000 e-mail addresses of internet users from the following categories; consumers, professionals and corporate bodies picked by an advanced automated random computer ballot search from the internet 'NO TICKETS OR DRAFTS WERE SOLD'. Your email address attached to Security File #: EGS/2251256003/02 with Serial number No: 002839 emerged as a winner of Six Hundred Thousand Pounds (£600.000.00 GBP), therefore you are eligible to file claim for your prize as one of our lucky winners for the payout of your total sum after a thorough verification that will be conducted by our various credible financial institutions. This online program is precisely aimed at enabling all internet users across the world benefit from the United Kingdom National Lottery, your email address falls within the First Category Winner as such your file has been designated to our European Centre, where the complete verification and payout will be conducted only if there are no exceptions during the claims process, to file your claim immediately please contact our International Programs Director Anderson Spencer with the following information: 1. Name in full----------------------------------------- 2. Phone/Fax------------------------------------------- 3. Occupation------------------------------------------ TO: Contact Person: Anderson Spencer European Payment Issuing Office Tel: +447024065192 (8am - 5pm GMT) Fax: +447092894160 Email: zonal.anderson-spencer@msn.com NOTE: In order to benefit from this program, you are advised in your own best interest to file your claim not later than 7days days from the date of this notification to avoid disqualification; anybody under the age of 18 is automatically disqualified. Please include this File #: EGS/2251256003/02 in every of your correspondence with our Foreign Service Director Anderson Spencer. IMPORTANT: Solemn confidentiality should be ensured until successful remittance of your prize to you to avoid undue taking of advantage, unwarranted claim and abuse of program, any breach of confidentiality on the part of the winner will result to automatic disqualification. Sincerely Yours, Mrs. Julie Van Hans, Executive Director. United Kingdom National Lottery. From bugmaster at FreeBSD.org Mon May 11 11:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 11 11:08:24 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200905111106.n4BB6weB085993@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 57 problems total. From bugmaster at FreeBSD.org Mon May 18 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 18 11:08:32 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200905181106.n4IB6srV075692@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 57 problems total. From ermal.luci at gmail.com Thu May 21 14:53:02 2009 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Thu May 21 14:53:09 2009 Subject: Does ipfw support interface groups? Message-ID: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> Hello, can ipfw use somehow interface groups as pf(4) can? >From a quick glance at documentation and not so through look at code it does not but i am sending this just if i missed something during my search! Thanks, -- Ermal From rizzo at iet.unipi.it Thu May 21 15:12:15 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu May 21 15:12:23 2009 Subject: Does ipfw support interface groups? In-Reply-To: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> References: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> Message-ID: <20090521150113.GA47160@onelab2.iet.unipi.it> On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote: > Hello, > > can ipfw use somehow interface groups as pf(4) can? > >From a quick glance at documentation and not so through look at code > it does not but i am sending this just if i missed something during my > search! something like ... { recv ed0 or recv xl1 or recv ath4 or recv vlan0 } ... is perhaps not so nice but does the job. cheers luigi From ermal.luci at gmail.com Thu May 21 15:45:22 2009 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Thu May 21 15:45:29 2009 Subject: Does ipfw support interface groups? In-Reply-To: <20090521150113.GA47160@onelab2.iet.unipi.it> References: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> <20090521150113.GA47160@onelab2.iet.unipi.it> Message-ID: <9a542da30905210845g1f9c15een24855a34ce1d79e1@mail.gmail.com> On Thu, May 21, 2009 at 5:01 PM, Luigi Rizzo wrote: > On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote: >> Hello, >> >> can ipfw use somehow interface groups as pf(4) can? >> >From a quick glance at documentation and not so through look at code >> it does not but i am sending this just if i missed something during my >> search! > > something like > > ? ? ? ?... { recv ed0 or recv xl1 or recv ath4 or recv vlan0 } ... > is perhaps not so nice but does the job. > Hmmm forgot about glob(3) goodness. Thanks, -- Ermal From dado at korolev-net.ru Thu May 21 16:06:17 2009 From: dado at korolev-net.ru (Evgenii Davidov) Date: Thu May 21 16:06:24 2009 Subject: Does ipfw support interface groups? In-Reply-To: <20090521150113.GA47160@onelab2.iet.unipi.it> References: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> <20090521150113.GA47160@onelab2.iet.unipi.it> Message-ID: <20090521154334.GJ84154@korolev-net.ru> ????????????, On Thu, May 21, 2009 at 05:01:13PM +0200, Luigi Rizzo ?????: > > can ipfw use somehow interface groups as pf(4) can? > > ... { recv ed0 or recv xl1 or recv ath4 or recv vlan0 } ... i use vlan20* :) -- Evgenii V Davidov From fjwcash at gmail.com Thu May 21 16:21:41 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Thu May 21 16:21:48 2009 Subject: Does ipfw support interface groups? In-Reply-To: <20090521150113.GA47160@onelab2.iet.unipi.it> References: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> <20090521150113.GA47160@onelab2.iet.unipi.it> Message-ID: On Thu, May 21, 2009 at 8:01 AM, Luigi Rizzo wrote: > On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote: >> can ipfw use somehow interface groups as pf(4) can? >> From a quick glance at documentation and not so through look at code >> it does not but i am sending this just if i missed something during my >> search! > > something like > ? ? ? ?... { recv ed0 or recv xl1 or recv ath4 or recv vlan0 } ... > is perhaps not so nice but does the job. Seriously??!! Luigi, you just made my day. :) Writing duplicate sets of rules for multi-homed firewalls where the only thing that's different is the incoming interface has been a pain ... Thanks for the info!! -- Freddie Cash fjwcash@gmail.com From rizzo at iet.unipi.it Thu May 21 16:36:55 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu May 21 16:37:02 2009 Subject: Does ipfw support interface groups? In-Reply-To: References: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> <20090521150113.GA47160@onelab2.iet.unipi.it> Message-ID: <20090521164225.GB50606@onelab2.iet.unipi.it> On Thu, May 21, 2009 at 08:49:30AM -0700, Freddie Cash wrote: > On Thu, May 21, 2009 at 8:01 AM, Luigi Rizzo wrote: > > On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote: > >> can ipfw use somehow interface groups as pf(4) can? > >> From a quick glance at documentation and not so through look at code > >> it does not but i am sending this just if i missed something during my > >> search! > > > > something like > > ?? ?? ?? ??... { recv ed0 or recv xl1 or recv ath4 or recv vlan0 } ... > > is perhaps not so nice but does the job. > > Seriously??!! > > Luigi, you just made my day. :) Writing duplicate sets of rules for > multi-homed firewalls where the only thing that's different is the > incoming interface has been a pain ... you can always put multiple rules that check the variant part and skipto the common one ipfw add 100 skipto 2000 in recv xl1 ipfw add 100 skipto 2000 in recv bge0 ... ipfw add 100 count // interface not recognised ipfw add 2000 ... // do the common part cheers luigi From steve at ibctech.ca Thu May 21 17:08:13 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu May 21 17:08:20 2009 Subject: Does ipfw support interface groups? In-Reply-To: References: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> <20090521150113.GA47160@onelab2.iet.unipi.it> Message-ID: <4A158432.5050303@ibctech.ca> Freddie Cash wrote: > On Thu, May 21, 2009 at 8:01 AM, Luigi Rizzo wrote: >> On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote: >>> can ipfw use somehow interface groups as pf(4) can? >>> From a quick glance at documentation and not so through look at code >>> it does not but i am sending this just if i missed something during my >>> search! >> something like >> ? ? ? ? ... { recv ed0 or recv xl1 or recv ath4 or recv vlan0 } ... >> is perhaps not so nice but does the job. > > Seriously??!! > > Luigi, you just made my day. :) Writing duplicate sets of rules for > multi-homed firewalls where the only thing that's different is the > incoming interface has been a pain ... Aside from Luigi's piece of trickery, if you are accustomed to making frequent changes to live rulesets (and then promptly forgetting/neglecting to add them into your startup scripts), might I recommend something that has become very useful to me: I have /etc/ipfw.rules which contains the variable definitions and all table configurations as my primary startup script. At the bottom of that file, I have: . /etc/ipfw.include This instructs the sh script to pick up the data from the ipfw.include file, and process it as well. Instead of implementing the rules live, and then adding them into the startup script manually, I simply (from time-to-time) run this (copy/paste into CLI): ipfw list | \ perl -nle 's/table\((\d+)\)/\"table($1)"/g; print "\$cmd $_";' \ > /etc/ipfw.include chown root:wheel /etc/ipfw.include && chmod 400 /etc/ipfw.include That then makes a copy of your current live ruleset into your /etc/ipfw.include file, which will be loaded upon next reboot. Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20090521/70f68f37/smime.bin From fjwcash at gmail.com Thu May 21 17:20:42 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Thu May 21 17:20:48 2009 Subject: Does ipfw support interface groups? In-Reply-To: <4A158432.5050303@ibctech.ca> References: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> <20090521150113.GA47160@onelab2.iet.unipi.it> <4A158432.5050303@ibctech.ca> Message-ID: On Thu, May 21, 2009 at 9:41 AM, Steve Bertrand wrote: > Freddie Cash wrote: >> On Thu, May 21, 2009 at 8:01 AM, Luigi Rizzo wrote: >>> On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote: >>>> can ipfw use somehow interface groups as pf(4) can? >>>> From a quick glance at documentation and not so through look at code >>>> it does not but i am sending this just if i missed something during my >>>> search! >>> something like >>> ? ?? ?? ?? ... { recv ed0 or recv xl1 or recv ath4 or recv vlan0 } ... >>> is perhaps not so nice but does the job. >> >> Seriously??!! >> >> Luigi, you just made my day. ?:) ?Writing duplicate sets of rules for >> multi-homed firewalls where the only thing that's different is the >> incoming interface has been a pain ... > > Aside from Luigi's piece of trickery, if you are accustomed to making > frequent changes to live rulesets (and then promptly > forgetting/neglecting to add them into your startup scripts), might I > recommend something that has become very useful to me: > > I have /etc/ipfw.rules which contains the variable definitions and all > table configurations as my primary startup script. At the bottom of that > file, I have: > > . /etc/ipfw.include > > This instructs the sh script to pick up the data from the ipfw.include > file, and process it as well. We do something similar, with a global config file with all the common variables, tables, queues, etc; and a master script with the rules for the firewall itself and the master NAT setup, which then pulls in separate scripts for each 1-to-1 NAT for servers at the sites. We make very heavy use of shell variables, tables, and the like. > Instead of implementing the rules live, and then adding them into the > startup script manually, I simply (from time-to-time) run this > (copy/paste into CLI): > > ipfw list | \ > perl -nle 's/table\((\d+)\)/\"table($1)"/g; print "\$cmd $_";' \ >> /etc/ipfw.include > chown root:wheel /etc/ipfw.include && chmod 400 /etc/ipfw.include > > That then makes a copy of your current live ruleset into your > /etc/ipfw.include file, which will be loaded upon next reboot. We do something similar every now and again to keep a backup of the live rules, just in case. But it's only used to compare against the live rules at a later date. Due to the heavy use of variables and formatting in our scripts, there's no way we'd consider using this output as an input script. :) It's hard enough to read the output of ipfw when it's running ... I wouldn't want to have to wade through that to add/update rules saved to a file. :) -- Freddie Cash fjwcash@gmail.com From fjwcash at gmail.com Thu May 21 17:22:59 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Thu May 21 17:23:05 2009 Subject: Does ipfw support interface groups? In-Reply-To: <20090521164225.GB50606@onelab2.iet.unipi.it> References: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> <20090521150113.GA47160@onelab2.iet.unipi.it> <20090521164225.GB50606@onelab2.iet.unipi.it> Message-ID: On Thu, May 21, 2009 at 9:42 AM, Luigi Rizzo wrote: > On Thu, May 21, 2009 at 08:49:30AM -0700, Freddie Cash wrote: >> On Thu, May 21, 2009 at 8:01 AM, Luigi Rizzo wrote: >> > On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote: >> >> can ipfw use somehow interface groups as pf(4) can? >> >> From a quick glance at documentation and not so through look at code >> >> it does not but i am sending this just if i missed something during my >> >> search! >> > >> > something like >> > ?? ?? ?? ??... { recv ed0 or recv xl1 or recv ath4 or recv vlan0 } ... >> > is perhaps not so nice but does the job. >> >> Seriously??!! >> >> Luigi, you just made my day. ?:) ?Writing duplicate sets of rules for >> multi-homed firewalls where the only thing that's different is the >> incoming interface has been a pain ... > > you can always put multiple rules that check the variant part > and skipto the common one > > ? ? ? ?ipfw add 100 skipto 2000 in recv xl1 > ? ? ? ?ipfw add 100 skipto 2000 in recv bge0 > ? ? ? ?... > ? ? ? ?ipfw add 100 count // interface not recognised > ? ? ? ?ipfw add 2000 ... ?// do the common part Skipto is very powerful, and we use it in some cases. But I try not to use it very often, as it can lead to spaghetti rules that are hard to follow. :) We have one firewall where it takes a good 10 minutes to track the path a packet takes through the rulelist, as there are so many skipto rules and multiple interfaces/vlans (it's scheduled for a rewrite this summer). -- Freddie Cash fjwcash@gmail.com From julian at elischer.org Thu May 21 17:54:32 2009 From: julian at elischer.org (Julian Elischer) Date: Thu May 21 17:54:39 2009 Subject: Does ipfw support interface groups? In-Reply-To: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> References: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> Message-ID: <4A159558.5030608@elischer.org> Ermal Lu?i wrote: > Hello, > > can ipfw use somehow interface groups as pf(4) can? >>From a quick glance at documentation and not so through look at code > it does not but i am sending this just if i missed something during my > search! > > Thanks, no, but you can do "em*" From julian at elischer.org Thu May 21 18:12:40 2009 From: julian at elischer.org (Julian Elischer) Date: Thu May 21 18:12:47 2009 Subject: Does ipfw support interface groups? In-Reply-To: References: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> <20090521150113.GA47160@onelab2.iet.unipi.it> <20090521164225.GB50606@onelab2.iet.unipi.it> Message-ID: <4A159997.9080604@elischer.org> Freddie Cash wrote: > Skipto is very powerful, and we use it in some cases. But I try not > to use it very often, as it can lead to spaghetti rules that are hard > to follow. :) We have one firewall where it takes a good 10 minutes > to track the path a packet takes through the rulelist, as there are so > many skipto rules and multiple interfaces/vlans (it's scheduled for a > rewrite this summer). don't forget you can now do a skipto tablearg :-) From fjwcash at gmail.com Fri May 22 18:41:24 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Fri May 22 18:41:33 2009 Subject: Does ipfw support interface groups? In-Reply-To: <20090521150113.GA47160@onelab2.iet.unipi.it> References: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> <20090521150113.GA47160@onelab2.iet.unipi.it> Message-ID: On Thu, May 21, 2009 at 8:01 AM, Luigi Rizzo wrote: > On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote: >> can ipfw use somehow interface groups as pf(4) can? >> >From a quick glance at documentation and not so through look at code >> it does not but i am sending this just if i missed something during my >> search! > > something like > > ? ? ? ?... { recv ed0 or recv xl1 or recv ath4 or recv vlan0 } ... > is perhaps not so nice but does the job. Just tested this on one off our firewalls, and can report that it works wonderfully. Now to compress the rules a bit using this. :) Thanks again, Luigi!! -- Freddie Cash fjwcash@gmail.com From bugmaster at FreeBSD.org Mon May 25 11:06:54 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 25 11:08:29 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200905251106.n4PB6sKc092838@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 57 problems total. From sebastian.mellmann at net.t-labs.tu-berlin.de Tue May 26 09:56:10 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Tue May 26 09:56:17 2009 Subject: FreeBSD 7.2 in bridge mode with net.inet.ip.fw.one_pass=0 Message-ID: <24c1af11d506e0eca99922849cd5823c.squirrel@anubis.getmyip.com> Hi everyone! I've a FreeBSD 7.2 machine with the following kernel options compiled: device if_bridge options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET options HZ=1000 I'm thinking of using this machine as a bridge with ipfw dummynet rules. I've seen in this [1] thread that there might be a problem with using ipfw with the net.inet.ip.fw.one_pass=0 option in bridge mode. Is this still an issue? Regards, Sebastian [1] http://www.mavetju.org/mail/view_message.php?list=freebsd-ipfw&id=971437 From sebastian.mellmann at net.t-labs.tu-berlin.de Wed May 27 19:13:19 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Wed May 27 19:13:26 2009 Subject: Increase maximum queue size in ipfw dummynet Message-ID: <4A1D90D4.3@net.t-labs.tu-berlin.de> Hi everyone! Is there any chance to increase the maximum size of the ipfw dummynet queue (maximum is 100 slots right now)? Do I've to change it in the code? If yes, where? Thanks for help in advance! Cheers, Sebastian From sebastian.mellmann at net.t-labs.tu-berlin.de Fri May 29 07:52:18 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Fri May 29 07:52:26 2009 Subject: Increase maximum queue size in ipfw dummynet In-Reply-To: <4A1D90D4.3@net.t-labs.tu-berlin.de> References: <4A1D90D4.3@net.t-labs.tu-berlin.de> Message-ID: > Is there any chance to increase the maximum size of the ipfw dummynet > queue (maximum is 100 slots right now)? > Do I've to change it in the code? > If yes, where? > After searching the net I could find a thread [1] about this issue. Can someone please clarify if this is still a problem and what needs to be done to increase the queue slot size? Cheers, Sebastian [1] http://osdir.com/ml/os.freebsd.devel.ipfw/2006-10/msg00009.html