From budiyt at gmail.com Sun May 4 16:07:59 2008 From: budiyt at gmail.com (budsz) Date: Sun May 4 16:08:02 2008 Subject: Syntax base IP Message-ID: <4d4dc3640805040840t5725fb4ejfd19da3c3f78ec73@mail.gmail.com> Hallo, I've rule in /etc/rc.firewall like this: ifint0="rl0" ippriviix="192.168.0.0/24" ipunlimit="192.168.0.100/32,10.35.4.1/32,202.129.189.42/32,\ 202.129.189.45/32,125.163.77.180/32,202.43.167.70/32,\ 202.43.167.72/32,202.43.161.119/32,202.10.32.10/32,202.93.20.22/32,\ 202.93.20.23/32,202.93.20.24/32,122.102.49.132/32,\ 202.43.161.124/32,202.93.247.26/32,202.93.247.28/32" portlim="20-21,80,88,443,2009,8080,8088,10007,18755" bwunlimit="197Kbit/s" ${fwcmd} add 100 pipe 1 ip from ${ippriviix} to { not ${ipunlimit} } ${portlim} via ${ifint0} ${fwcmd} add 101 pipe 1 ip from { not ${ipunlimit} } ${portlim} to ${ippriviix} via ${ifint0} ${fwcmd} pipe 1 config bw ${bwunlimit} Executing firewall I got error message like this: #sh /etc/rc.firewall ipfw: opcode 6 size 33 wrong ipfw: getsockopt(IP_FW_ADD): Invalid argument ipfw: opcode 2 size 33 wrong ipfw: getsockopt(IP_FW_ADD): Invalid argument This error happened after I adding new IP Address 202.93.247.28/32 on $ipunlimit variable. It that correct to add 202.93.247.26/32 and 202.93.247.28/32 together? or I should rewrite like 202.93.247.26/29?. But already same on $ipunlimit variable like 202.93.20.22/32 and 202.93.20.23/32 this is no problem. Any clue or suggestion about this syntax? Thanks You -- budsz From bugmaster at FreeBSD.org Mon May 5 11:07:07 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 5 11:07:15 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200805051107.m45B76p1070726@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/106534 ipfw [ipfw] [panic] ipfw + dummynet 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 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 [ipfw] [patch] ipfw verbosity locks machine if /etc/rc 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/111713 ipfw [dummynet] [request] Too few dummynet queue slots 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 30 problems total. From bu7cher at yandex.ru Tue May 6 09:00:49 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Tue May 6 09:00:57 2008 Subject: Syntax base IP In-Reply-To: <4d4dc3640805040840t5725fb4ejfd19da3c3f78ec73@mail.gmail.com> References: <4d4dc3640805040840t5725fb4ejfd19da3c3f78ec73@mail.gmail.com> Message-ID: <48201E0D.60803@yandex.ru> budsz wrote: > ipunlimit="192.168.0.100/32,10.35.4.1/32,202.129.189.42/32,\ > 202.129.189.45/32,125.163.77.180/32,202.43.167.70/32,\ > 202.43.167.72/32,202.43.161.119/32,202.10.32.10/32,202.93.20.22/32,\ > 202.93.20.23/32,202.93.20.24/32,122.102.49.132/32,\ > 202.43.161.124/32,202.93.247.26/32,202.93.247.28/32" > ${fwcmd} add 100 pipe 1 ip from ${ippriviix} to { not ${ipunlimit} } > ${portlim} via ${ifint0} > ${fwcmd} add 101 pipe 1 ip from { not ${ipunlimit} } ${portlim} to > ${ippriviix} via ${ifint0} > Executing firewall I got error message like this: > #sh /etc/rc.firewall > ipfw: opcode 6 size 33 wrong > ipfw: getsockopt(IP_FW_ADD): Invalid argument > ipfw: opcode 2 size 33 wrong > ipfw: getsockopt(IP_FW_ADD): Invalid argument It means that your src and dst addresses are too long. > Any clue or suggestion about this syntax? Try to use lookup tables. -- WBR, Andrey V. Elsukov From asstec at matik.com.br Tue May 6 11:50:56 2008 From: asstec at matik.com.br (AT Matik) Date: Tue May 6 11:51:01 2008 Subject: Syntax base IP In-Reply-To: <4d4dc3640805040840t5725fb4ejfd19da3c3f78ec73@mail.gmail.com> References: <4d4dc3640805040840t5725fb4ejfd19da3c3f78ec73@mail.gmail.com> Message-ID: <200805060748.18487.asstec@matik.com.br> On Sunday 04 May 2008 12:40:24 budsz wrote: > Hallo, > > I've rule in /etc/rc.firewall like this: > > ifint0="rl0" > ippriviix="192.168.0.0/24" > ipunlimit="192.168.0.100/32,10.35.4.1/32,202.129.189.42/32,\ > 202.129.189.45/32,125.163.77.180/32,202.43.167.70/32,\ > > 202.43.167.72/32,202.43.161.119/32,202.10.32.10/32,202.93.20.22/32,\ > 202.93.20.23/32,202.93.20.24/32,122.102.49.132/32,\ > 202.43.161.124/32,202.93.247.26/32,202.93.247.28/32" if you can not use tables you can write a for loop with skipto pefore the pipe for items in $ipunlimit; do ipfw add 100 skipto $rulenumber_after_pipe ip from $items to any done pipe rules (where you like to add in or out to via) > portlim="20-21,80,88,443,2009,8080,8088,10007,18755" > bwunlimit="197Kbit/s" > > ${fwcmd} add 100 pipe 1 ip from ${ippriviix} to { not ${ipunlimit} } > ${portlim} via ${ifint0} > ${fwcmd} add 101 pipe 1 ip from { not ${ipunlimit} } ${portlim} to > ${ippriviix} via ${ifint0} > ${fwcmd} pipe 1 config bw ${bwunlimit} > > Executing firewall I got error message like this: > #sh /etc/rc.firewall > ipfw: opcode 6 size 33 wrong > ipfw: getsockopt(IP_FW_ADD): Invalid argument > ipfw: opcode 2 size 33 wrong > ipfw: getsockopt(IP_FW_ADD): Invalid argument > > This error happened after I adding new IP Address 202.93.247.28/32 on > $ipunlimit variable. > It that correct to add 202.93.247.26/32 and 202.93.247.28/32 together? > or I should rewrite like > 202.93.247.26/29?. But already same on $ipunlimit variable like > 202.93.20.22/32 and 202.93.20.23/32 this is no problem. > > Any clue or suggestion about this syntax? > > Thanks You -- Participe no BAIXO ASSINADO SCM: http://info.matik.com.br -- Atenciosamente, J.M. Respons?vel Plant?o Site Support Matik Infomatik Internet Technology (18)3551.8155 ?(18)8112.7007 A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From mpope at oanda.com Tue May 6 19:25:15 2008 From: mpope at oanda.com (Matthew Pope) Date: Tue May 6 19:25:19 2008 Subject: dummynet queue size relative to bw setting? Message-ID: <4820AB8F.2000204@oanda.com> Hello, I've been reading about dummynet for 2 weeks, including the seminal ACM paper & I'm very impressed. I've configured and run some preliminary simulations that have my colleagues quite interested too. However, I'm finding my delay settings are yielding delays of about two orders of magnitude larger that requested. I believe I don't understand the relationship very well that defines the setting of the queue size to relative to the bandwidth setting (and plr?) Can someone explain or point me to a source for this? I recall reading that with lower bandwidths one should use lower queue sizes to avoid long queuing delays. So I presume that is why my delays are so long. So I've run some tests with various queue sizes. With Queue sizes of 100, 80, 60, 40, 10 slots on a pipe with a bw of 48Kbits/s, delay of 5ms, and plr 0.025 defined in each direction, I'm consistently getting RT delays of 500-600ms with a ping test, packet loss does come out around 5%. The target I'm pinging is normally a 40 ms latency. At Queue size 120 I get 100% packet loss (but I can ignore that). I am not a networking specialist, so I realize my question is ignorant :-) I'm running this in VMWare Server on a dual core 2 GHz with 2 GB RAM using a modification of the dummynet test network design described at codefromthe70s.org Thanks, Matthew From mpope at oanda.com Tue May 6 19:34:24 2008 From: mpope at oanda.com (Matthew Pope) Date: Tue May 6 19:34:28 2008 Subject: dummynet queue size relative to bw setting? In-Reply-To: <4820AB8F.2000204@oanda.com> References: <4820AB8F.2000204@oanda.com> Message-ID: <4820B2BF.6090608@oanda.com> I must correct my test parameters: In one of the two pipes, the bw was 4K, not 48K as stated. When I just now moved it up to 48K to match the other pipe size, my ping times plummeted to 129-139ms throughout the Queue sizes listed below, again with Q=120 getting total packet loss. I thought a ping sent packets slowly, so that the 4K bw on the one pipe would not slow things down, but it seems I was wrong. Still I'm wondering why the measured delay is 130, without dummynet its 40, and I've set it to 5ms in each direction, so it should be measured as 50, not 130. Thx, Matthew > Hello, > I've been reading about dummynet for 2 weeks, including the seminal > ACM paper & I'm very impressed. I've configured and run some > preliminary simulations that have my colleagues quite interested too. > > However, I'm finding my delay settings are yielding delays of about > two orders of magnitude larger that requested. I believe I don't > understand the relationship very well that defines the setting of the > queue size to relative to the bandwidth setting (and plr?) Can > someone explain or point me to a source for this? > > I recall reading that with lower bandwidths one should use lower queue > sizes to avoid long queuing delays. So I presume that is why my > delays are so long. So I've run some tests with various queue sizes. > > With Queue sizes of 100, 80, 60, 40, 10 slots on a pipe with a bw of > 48Kbits/s, delay of 5ms, and plr 0.025 defined in each direction, I'm > consistently getting RT delays of 500-600ms with a ping test, packet > loss does come out around 5%. The target I'm pinging is normally a 40 > ms latency. At Queue size 120 I get 100% packet loss (but I can > ignore that). > > I am not a networking specialist, so I realize my question is ignorant > :-) I'm running this in VMWare Server on a dual core 2 GHz with 2 GB > RAM using a modification of the dummynet test network design described > at codefromthe70s.org > Thanks, > Matthew > > From rizzo at iet.unipi.it Tue May 6 20:21:52 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue May 6 20:21:55 2008 Subject: dummynet queue size relative to bw setting? In-Reply-To: <4820B2BF.6090608@oanda.com> References: <4820AB8F.2000204@oanda.com> <4820B2BF.6090608@oanda.com> Message-ID: <20080506200651.GA57251@onelab2.iet.unipi.it> On Tue, May 06, 2008 at 03:34:23PM -0400, Matthew Pope wrote: > I must correct my test parameters: In one of the two pipes, the bw was > 4K, not 48K as stated. > When I just now moved it up to 48K to match the other pipe size, my ping > times plummeted to 129-139ms throughout the Queue sizes listed below, > again with Q=120 getting total packet loss. > I thought a ping sent packets slowly, so that the 4K bw on the one pipe > would not slow things down, but it seems I was wrong. Still I'm > wondering why the measured delay is 130, without dummynet its 40, and > I've set it to 5ms in each direction, so it should be measured as 50, > not 130. Thx, Matthew part of the delay is the time it takes for the bits of the packet to go through the bandwidth-limited channel - this is called "transmission delay" and is transmission_delay = packet_size_in_bits/bandwidth_in_bits_per_second Also, depending on how you configure dummynet, your ping request and response can go through a pipe multiple times (for a proper configuration, usually you traverse one pipe downstream and one pipe upstream; if the system is misconfigured, e.g. as a router with dummynet intercepting traffic on both interfaces, you will traverse two pipes on each direction). The typical ping packet is around 64 bytes or 512 bits, at 48Kbit/s this makes an additional 12ms each way, so you should see no less than 40+(5+12)*2 = 74 ms for a proper configuration, and 40+(5+12)*4 = 108 ms if misconfigured, the latter is very similar to the numbers you are seeing. On top of this, VMware doesn't emulate well enough the timing, so it is likely that the clock ticks every 10ms instead of the 1ms expected by the hardware, so some of the individual delays (5ms for the pipe, 12ms for the transmission time) could be further rounded to the next multiple of the clock tick, which would increase the delay even further. cheers luigi From mpope at oanda.com Tue May 6 20:31:47 2008 From: mpope at oanda.com (Matthew Pope) Date: Tue May 6 20:31:53 2008 Subject: dummynet queue size relative to bw setting? In-Reply-To: <20080506200651.GA57251@onelab2.iet.unipi.it> References: <4820AB8F.2000204@oanda.com> <4820B2BF.6090608@oanda.com> <20080506200651.GA57251@onelab2.iet.unipi.it> Message-ID: <4820C031.4000707@oanda.com> Luigi Rizzo wrote: > On Tue, May 06, 2008 at 03:34:23PM -0400, Matthew Pope wrote: > >> I must correct my test parameters: In one of the two pipes, the bw was >> 4K, not 48K as stated. >> When I just now moved it up to 48K to match the other pipe size, my ping >> times plummeted to 129-139ms throughout the Queue sizes listed below, >> again with Q=120 getting total packet loss. >> I thought a ping sent packets slowly, so that the 4K bw on the one pipe >> would not slow things down, but it seems I was wrong. Still I'm >> wondering why the measured delay is 130, without dummynet its 40, and >> I've set it to 5ms in each direction, so it should be measured as 50, >> not 130. Thx, Matthew >> > > part of the delay is the time it takes for the bits of the packet > to go through the bandwidth-limited channel - this is called > "transmission delay" and is > > transmission_delay = packet_size_in_bits/bandwidth_in_bits_per_second > > Also, depending on how you configure dummynet, your ping request > and response can go through a pipe multiple times (for a proper > configuration, usually you traverse one pipe downstream and one > pipe upstream; if the system is misconfigured, e.g. as a router > with dummynet intercepting traffic on both interfaces, > you will traverse two pipes on each direction). > > > The typical ping packet is around 64 bytes or 512 bits, at 48Kbit/s > this makes an additional 12ms each way, so you should see > no less than 40+(5+12)*2 = 74 ms for a proper configuration, and > 40+(5+12)*4 = 108 ms if misconfigured, the latter is very similar to > the numbers you are seeing. > > On top of this, VMware doesn't emulate well enough the timing, > so it is likely that the clock ticks every 10ms instead of the 1ms > expected by the hardware, so some of the individual delays > (5ms for the pipe, 12ms for the transmission time) could be > further rounded to the next multiple of the clock tick, > which would increase the delay even further. > > cheers > luigi > > Thanks so much Luigi! This little tutorial (and VMWare comment) is exactly what I needed to understand what was going on. And thank you for Dummynet, a very significant contribution to multi-cast routing and simulation. Matthew From marconemlt at gmail.com Tue May 6 21:11:55 2008 From: marconemlt at gmail.com (Marcone Theisen) Date: Tue May 6 21:11:59 2008 Subject: Redirect internal traffic (only port 80) to another link Message-ID: Hi, I have 2 links, one em0 and other in vlan2 interface. My default route is em0. The problem is: I want to direct all internal Internet traffic (port 80) for the link in vlan2 interface. How to do it with the IPFW? Some information: Link em0 interface - 10.40.1.0 Interna network: em1 interface - 10.10.18.0 Link vlan2 interface - 192.168.7.0 The vlan2 interface is on Trunk port in switch. It's work. We have tried the following alternatives: I created another route: Route ADD 192.168.7.107 192.168.7.105 ipfw add 00019 divert from 8668 ip 10.10.18.0/24 to any 80 via vlan2 Traffic continued through dedicated link. ipfw add 00019 fwd 192.168.7.105 tcp from 10.10.18.0/24 to any 80 redirect the traffic on the link vlan2, but did not return anything. ipfw add 00019 divert from 8669 ip 10.10.18.0/24 to any 80 via vlan2 natd-s-m-n-vlan2 p 8669 Anything! All attempts without success. Thus, how I can redirect my internal Internet traffic to the VLAN2 link with IPFW ? Thank's, Marcone From eenpint at hotmail.com Wed May 7 09:57:07 2008 From: eenpint at hotmail.com (Tom Wuyts) Date: Wed May 7 09:57:10 2008 Subject: Redirect internal traffic (only port 80) to another link In-Reply-To: References: Message-ID: set in your rc.conf next line natd_flags="-f /etc/natd.conf" and then add the file natd.conf in your etc/ folder interface em0 (if i'm not mistaking, i don't completely get your question) use_sockets yes dynamic yes redirect_port tcp 192.168.7.105:80 80 this should send all packets arriving at port 80 from your 10.0.0.0 network to 192.168.7.105 and then restart your network /etc/netstart restart if he complains about natd, while restarting your network, kill natd with "pkill natd" and then restart your network hope it helps, tom > Date: Tue, 6 May 2008 17:46:06 -0300 > From: marconemlt@gmail.com > To: freebsd-ipfw@freebsd.org > Subject: Redirect internal traffic (only port 80) to another link > > Hi, > > I have 2 links, one em0 and other in vlan2 interface. > My default route is em0. > > The problem is: > I want to direct all internal Internet traffic (port 80) for the link in > vlan2 interface. > How to do it with the IPFW? > > Some information: > > Link em0 interface - 10.40.1.0 > Interna network: em1 interface - 10.10.18.0 > Link vlan2 interface - 192.168.7.0 > > The vlan2 interface is on Trunk port in switch. It's work. > > We have tried the following alternatives: > > I created another route: > Route ADD 192.168.7.107 192.168.7.105 > > ipfw add 00019 divert from 8668 ip 10.10.18.0/24 to any 80 via vlan2 > Traffic continued through dedicated link. > > ipfw add 00019 fwd 192.168.7.105 tcp from 10.10.18.0/24 to any 80 > redirect the traffic on the link vlan2, but did not return anything. > > ipfw add 00019 divert from 8669 ip 10.10.18.0/24 to any 80 via vlan2 > natd-s-m-n-vlan2 p 8669 > Anything! > > All attempts without success. > Thus, how I can redirect my internal Internet traffic to the VLAN2 link with > IPFW ? > > Thank's, > Marcone > _______________________________________________ > 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" _________________________________________________________________ Nieuwe lente...Een nieuw online leven...Gratis dankzij Windows Live http://get.live.com From marconemlt at gmail.com Wed May 7 21:55:28 2008 From: marconemlt at gmail.com (Marcone Theisen) Date: Wed May 7 21:55:36 2008 Subject: Redirect internal traffic (only port 80) to another link In-Reply-To: References: Message-ID: Hi Tom, Thank's for the help, but not worked with the procedures below. The natd.conf file is ok, I'm restart the netstart and the natd. I think it may be the vlan. It's works fine, I can ping the gateway. But, I can route my internal traffic by vlan? With the command "trafshow -i vlan2" anything I can see. em0: flags=8843 mtu 1500 options=b inet6 fe80::211:43ff:fefd:3ff6%em0 prefixlen 64 scopeid 0x1 inet 10.40.4.1 netmask 0xffffff00 broadcast 10.40.4.255 ether 00:11:43:fd:3f:f6 media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8843 mtu 1500 options=b inet 10.10.18.3 netmask 0xffffff00 broadcast 10.10.18.255 inet6 fe80::211:43ff:fefd:3ff7%em1 prefixlen 64 scopeid 0x2 ether 00:11:43:fd:3f:f7 media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 vlan2: flags=8843 mtu 1500 inet6 fe80::211:43ff:fefd:3ff6%vlan2 prefixlen 64 duplicated scopeid 0x4 inet 192.168.7.106 netmask 0xfffffff8 broadcast 192.168.7.111 ether 00:11:43:fd:3f:f7 media: Ethernet autoselect (1000baseTX ) status: active vlan: 2 parent interface: em1 portal# ping 192.168.7.105 PING 192.168.7.105 (192.168.7.105): 56 data bytes 64 bytes from 192.168.7.105: icmp_seq=0 ttl=30 time=0.839 ms 64 bytes from 192.168.7.105: icmp_seq=1 ttl=30 time=0.763 ms Have any other alternative to test ? Thank's, Marcone 2008/5/7 Tom Wuyts : > set in your rc.conf next line > > natd_flags="-f /etc/natd.conf" > > and then add the file natd.conf in your etc/ folder > > interface em0 (if i'm not mistaking, i don't completely get your question) > use_sockets yes > dynamic yes > redirect_port tcp 192.168.7.105:80 80 > > this should send all packets arriving at port 80 from your 10.0.0.0network to > 192.168.7.105 > > and then restart your network > /etc/netstart restart > > if he complains about natd, while restarting your network, kill natd with > "pkill natd" and then restart your network > > hope it helps, > > tom > > > > ------------------------------ > > Date: Tue, 6 May 2008 17:46:06 -0300 > > From: marconemlt@gmail.com > > To: freebsd-ipfw@freebsd.org > > Subject: Redirect internal traffic (only port 80) to another link > > > > Hi, > > > > I have 2 links, one em0 and other in vlan2 interface. > > My default route is em0. > > > > The problem is: > > I want to direct all internal Internet traffic (port 80) for the link in > > vlan2 interface. > > How to do it with the IPFW? > > > > Some information: > > > > Link em0 interface - 10.40.1.0 > > Interna network: em1 interface - 10.10.18.0 > > Link vlan2 interface - 192.168.7.0 > > > > The vlan2 interface is on Trunk port in switch. It's work. > > > > We have tried the following alternatives: > > > > I created another route: > > Route ADD 192.168.7.107 192.168.7.105 > > > > ipfw add 00019 divert from 8668 ip 10.10.18.0/24 to any 80 via vlan2 > > Traffic continued through dedicated link. > > > > ipfw add 00019 fwd 192.168.7.105 tcp from 10.10.18.0/24 to any 80 > > redirect the traffic on the link vlan2, but did not return anything. > > > > ipfw add 00019 divert from 8669 ip 10.10.18.0/24 to any 80 via vlan2 > > natd-s-m-n-vlan2 p 8669 > > Anything! > > > > All attempts without success. > > Thus, how I can redirect my internal Internet traffic to the VLAN2 link > with > > IPFW ? > > > > Thank's, > > Marcone > > _______________________________________________ > > 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" > > ------------------------------ > Nieuwe lente...Een nieuw online leven...Helemaal gratis! Windows Live > > From 482254ac at razorfever.net Thu May 8 01:42:28 2008 From: 482254ac at razorfever.net (Derek (freebsd-ipfw)) Date: Thu May 8 01:42:34 2008 Subject: Dummynet, gif, and ipsec Message-ID: <48225A43.3080909@razorfever.net> Hello, I am trying to do some traffic shaping on my router using dummynet. The router is one endpoint in an ipsec tunnel (configured as the handbook suggests). I'm running voip inside ipsec, so the goal here is to minimize the delay in transmitting the encapsulated voip packets. I'd like to be able to classify other traffic inside ipsec as well. I currently have my outgoing pipe configured with 5 queues: pipe 10 config delay 0 #outgoing pipe send queue 101 config pipe 10 weight 100 #highest priority queue 102 config pipe 10 weight 20 queue 103 config pipe 10 weight 5 queue 104 config pipe 10 weight 1 #lowest priority I have all of my outgoing ipsec queued into queue 101, with most of my other traffic hitting the other queues. I have set up additional queues to run over top of my gif interfaces: pipe 20 config delay 0 #VPN outgoing pipe (gif*) send queue 201 config pipe 20 weight 100 #highest priority queue 202 config pipe 20 weight 20 queue 203 config pipe 20 weight 5 queue 204 config pipe 20 weight 1 #lowest priority As I'm running a tunnel, I have specific subnets that are communicating over the gif interfaces. If I simply allow the traffic, everything works fine: add 7200 allow ip from table(1) to table(1) If I try to queue traffic going out, packets disappear right after the queue: add 7020 queue 203 ip from table(1) to table(1) out via gif* add 7025 count ip from table(1) to table(1) out via gif* add 7200 allow ip from table(1) to table(1) I zero my stats, and let the traffic run for a little while. When I show my stats again, there is a gross discrepancy in the counts at 7020, and 7025. Packets that normally show up on the other end of the tunnel, don't. If I remove the count, the packets still don't show up. If anyone can recognize why this is happening, or provide suggestions on how to troubleshoot it, I'd greatly appreciate it. If your are doing a similar approach successfully, I'd like to know. If you have alternative suggestions on how to shape traffic based on what is inside an ipsec tunnel, that is also appreciated. I tried using IPFW's tag command, and I think that is the best way to do what I want to do, period. Tag the unencrypted data as it is going out the gif interface, and queue the IPSEC traffic based on the packet tag, but the tag disappears after IPSEC processing. Also, I'm aware of using the IP TOS flags for this, and I may have to go that route (based on the research I've done), but I want to know why what I'm currently is failing the way it is. The TOS flags don't seem as flexible, as there are only a few classes that I can use, and there isn't any built-in way to modify these flags. I'd have to use netgraph, or divert, and I'm not too keen on either of these approaches right now. Best regards, and thanks! -- Derek More details about the machine: Running 6.3-RELEASE /etc/sysctl.conf: net.inet.ip.fw.one_pass=0 Kernel: include SMP ident GW2 options MPTABLE_FORCE_HTT options NO_F00F_HACK options DEVICE_POLLING options AUTO_EOI_1 options IPSEC options IPSEC_ESP options IPSEC_FILTERGIF device carp device disc options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPDIVERT options IPSTEALTH options TCP_DROP_SYNFIN options DUMMYNET options ZERO_COPY_SOCKETS options HZ=1000 device snp From ermal.luci at gmail.com Thu May 8 16:12:19 2008 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Thu May 8 16:12:21 2008 Subject: Dummynet, gif, and ipsec Message-ID: <9a542da30805080844t395c8c81sd313fc2fd1780fcb@mail.gmail.com> > Date: Wed, 07 May 2008 21:41:23 -0400 > From: "Derek (freebsd-ipfw)" <482254ac@razorfever.net> > Subject: Dummynet, gif, and ipsec > To: freebsd-ipfw@freebsd.org > Message-ID: <48225A43.3080909@razorfever.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, > > I am trying to do some traffic shaping on my router using dummynet. The > router is one endpoint in an ipsec tunnel (configured as the handbook > suggests). > > I'm running voip inside ipsec, so the goal here is to minimize the delay > in transmitting the encapsulated voip packets. I'd like to be able to > classify other traffic inside ipsec as well. > > I currently have my outgoing pipe configured with 5 queues: > > pipe 10 config delay 0 #outgoing pipe send > queue 101 config pipe 10 weight 100 #highest priority > queue 102 config pipe 10 weight 20 > queue 103 config pipe 10 weight 5 > queue 104 config pipe 10 weight 1 #lowest priority > > I have all of my outgoing ipsec queued into queue 101, with most of my > other traffic hitting the other queues. > > I have set up additional queues to run over top of my > gif interfaces: > > pipe 20 config delay 0 #VPN outgoing pipe (gif*) send > queue 201 config pipe 20 weight 100 #highest priority > queue 202 config pipe 20 weight 20 > queue 203 config pipe 20 weight 5 > queue 204 config pipe 20 weight 1 #lowest priority > > As I'm running a tunnel, I have specific subnets that are communicating > over the gif interfaces. > > If I simply allow the traffic, everything works fine: > > add 7200 allow ip from table(1) to table(1) > > If I try to queue traffic going out, packets disappear right after the > queue: > > add 7020 queue 203 ip from table(1) to table(1) out via gif* > add 7025 count ip from table(1) to table(1) out via gif* > add 7200 allow ip from table(1) to table(1) > > I zero my stats, and let the traffic run for a little while. When I > show my stats again, there is a gross discrepancy in the counts at 7020, > and 7025. Packets that normally show up on the other end of the tunnel, > don't. If I remove the count, the packets still don't show up. > > If anyone can recognize why this is happening, or provide suggestions on > how to troubleshoot it, I'd greatly appreciate it. > > If your are doing a similar approach successfully, I'd like to know. > > If you have alternative suggestions on how to shape traffic based on > what is inside an ipsec tunnel, that is also appreciated. > > I tried using IPFW's tag command, and I think that is the best way to do > what I want to do, period. Tag the unencrypted data as it is going out > the gif interface, and queue the IPSEC traffic based on the packet tag, > but the tag disappears after IPSEC processing. > > Also, I'm aware of using the IP TOS flags for this, and I may have to go > that route (based on the research I've done), but I want to know why > what I'm currently is failing the way it is. The TOS flags don't seem > as flexible, as there are only a few classes that I can use, and there > isn't any built-in way to modify these flags. I'd have to use netgraph, > or divert, and I'm not too keen on either of these approaches right now. > Well this is a patch to shape IPSec tunnels with ALTQ and FreeBSD 6.3 as you are running. It is another alternative to dummynet though it have been tested with pf but should work with ipfw too since it knows about ALTQ. Hope it helps! Ermal Index: sys/net/if_enc.c =================================================================== RCS file: /home/eri/FreeBSD/src/sys/net/if_enc.c,v retrieving revision 1.5.2.2.2.1 diff -u -r1.5.2.2.2.1 if_enc.c --- sys/net/if_enc.c 29 Dec 2007 17:29:11 -0000 1.5.2.2.2.1 +++ sys/net/if_enc.c 10 Feb 2008 01:19:41 -0000 @@ -48,6 +48,8 @@ #include #include +#include + #include #include #include @@ -194,10 +196,12 @@ } int -ipsec_filter(struct mbuf **mp, int dir) +ipsec_filter(struct mbuf **mp, struct secasindex *saidx, int dir) { int error, i; struct ip *ip; + struct m_tag *t; + struct altq_tag *atag; KASSERT(encif != NULL, ("%s: encif is null", __func__)); @@ -267,6 +271,11 @@ if (error != 0) goto bad; + if (saidx && (t = m_tag_find(*mp, PACKET_TAG_PF_QID, NULL)) != NULL) { + atag = (struct altq_tag *)(t + 1); + saidx->qid = atag->qid; + } + return (error); bad: Index: sys/netipsec/ipsec.h =================================================================== RCS file: /home/eri/FreeBSD/src/sys/netipsec/ipsec.h,v retrieving revision 1.8.2.2 diff -u -r1.8.2.2 ipsec.h --- sys/netipsec/ipsec.h 24 Jul 2006 23:20:59 -0000 1.8.2.2 +++ sys/netipsec/ipsec.h 8 Feb 2008 17:13:03 -0000 @@ -413,7 +413,7 @@ extern struct mbuf *m_makespace(struct mbuf *m0, int skip, int hlen, int *off); extern caddr_t m_pad(struct mbuf *m, int n); extern int m_striphdr(struct mbuf *m, int skip, int hlen); -extern int ipsec_filter(struct mbuf **, int); +extern int ipsec_filter(struct mbuf **, struct secasindex *, int); extern void ipsec_bpf(struct mbuf *, struct secasvar *, int); #endif /* _KERNEL */ Index: sys/netipsec/ipsec_input.c =================================================================== RCS file: /home/eri/FreeBSD/src/sys/netipsec/ipsec_input.c,v retrieving revision 1.9.2.2 diff -u -r1.9.2.2 ipsec_input.c --- sys/netipsec/ipsec_input.c 24 Jul 2006 23:20:59 -0000 1.9.2.2 +++ sys/netipsec/ipsec_input.c 8 Feb 2008 16:53:05 -0000 @@ -451,7 +451,7 @@ ipsec_bpf(m, sav, AF_INET); if (prot != IPPROTO_IPIP) - if ((error = ipsec_filter(&m, 1)) != 0) + if ((error = ipsec_filter(&m, &sav->sah->saidx, 1)) != 0) return (error); #endif Index: sys/netipsec/ipsec_output.c =================================================================== RCS file: /home/eri/FreeBSD/src/sys/netipsec/ipsec_output.c,v retrieving revision 1.10.8.1 diff -u -r1.10.8.1 ipsec_output.c --- sys/netipsec/ipsec_output.c 24 Jul 2006 23:20:59 -0000 1.10.8.1 +++ sys/netipsec/ipsec_output.c 9 Feb 2008 17:49:47 -0000 @@ -44,6 +44,9 @@ #include #include +#ifdef DEV_ENC +#include +#endif #include #include @@ -160,6 +163,25 @@ } key_sa_recordxfer(sav, m); /* record data transfer */ +#ifdef DEV_ENC + /* + * Restore previous queue selected by the classifier for the + * packet. + */ + if (saidx->qid) { + mtag = m_tag_get(PACKET_TAG_PF_QID, sizeof(struct altq_tag), + M_NOWAIT); + if (mtag != NULL) { /* Safe to ignore */ + struct altq_tag *atag; + atag = (struct altq_tag *)(mtag + 1); + atag->qid = saidx->qid; + /* add hints for ecn */ + atag->af = saidx->dst.sa.sa_family; + atag->hdr = NULL; /* This should be safe! */ + m_tag_prepend(m, mtag); + } + } +#endif /* * We're done with IPsec processing, transmit the packet using the * appropriate network protocol (IP or IPv6). SPD lookup will be @@ -362,7 +384,7 @@ #ifdef DEV_ENC /* pass the mbuf to enc0 for packet filtering */ - if ((error = ipsec_filter(&m, 2)) != 0) + if ((error = ipsec_filter(&m, &sav->sah->saidx, 2)) != 0) goto bad; #endif Index: sys/netipsec/keydb.h =================================================================== RCS file: /home/eri/FreeBSD/src/sys/netipsec/keydb.h,v retrieving revision 1.5 diff -u -r1.5 keydb.h --- sys/netipsec/keydb.h 7 Jan 2005 01:45:46 -0000 1.5 +++ sys/netipsec/keydb.h 8 Feb 2008 17:12:01 -0000 @@ -58,6 +58,9 @@ u_int8_t mode; /* mode of protocol, see ipsec.h */ u_int32_t reqid; /* reqid id who owned this SA */ /* see IPSEC_MANUAL_REQID_MAX. */ + u_int32_t qid; /* used for ALTQ shaping inside */ + /* tunnel */ + }; /* Security Association Data Base */ Index: sys/netipsec/xform_ipip.c =================================================================== RCS file: /home/eri/FreeBSD/src/sys/netipsec/xform_ipip.c,v retrieving revision 1.11.2.2 diff -u -r1.11.2.2 xform_ipip.c --- sys/netipsec/xform_ipip.c 24 Jul 2006 23:20:59 -0000 1.11.2.2 +++ sys/netipsec/xform_ipip.c 8 Feb 2008 16:54:41 -0000 @@ -348,7 +348,7 @@ #ifdef DEV_ENC /* pass the mbuf to enc0 for packet filtering */ - if (ipsec_filter(&m, 1) != 0) + if (ipsec_filter(&m, NULL, 1) != 0) return; #endif > Best regards, and thanks! > -- Derek > > > > More details about the machine: > > Running 6.3-RELEASE > > /etc/sysctl.conf: > net.inet.ip.fw.one_pass=0 > > Kernel: > include SMP > ident GW2 > > options MPTABLE_FORCE_HTT > options NO_F00F_HACK > options DEVICE_POLLING > options AUTO_EOI_1 > > options IPSEC > options IPSEC_ESP > options IPSEC_FILTERGIF > > device carp > device disc > > options IPFIREWALL > options IPFIREWALL_VERBOSE > options IPFIREWALL_FORWARD > options IPDIVERT > options IPSTEALTH > options TCP_DROP_SYNFIN > options DUMMYNET > options ZERO_COPY_SOCKETS > options HZ=1000 From 482254ac at razorfever.net Fri May 9 16:17:07 2008 From: 482254ac at razorfever.net (Derek (freebsd-ipfw)) Date: Fri May 9 16:17:11 2008 Subject: Dummynet, gif, and ipsec In-Reply-To: <9a542da30805080844t395c8c81sd313fc2fd1780fcb@mail.gmail.com> References: <9a542da30805080844t395c8c81sd313fc2fd1780fcb@mail.gmail.com> Message-ID: <48247901.3000706@razorfever.net> Ermal Lu?i wrote: > Well this is a patch to shape IPSec tunnels with ALTQ and FreeBSD 6.3 > as you are running. It is another alternative to dummynet though it > have been tested with pf but should work with ipfw too since it knows > about ALTQ. > Hope it helps! > Hi Ermal, Thanks for the response! I'm looking to roll this out on 5-7 machines, so I'm really looking for a solution where we wouldn't have to make changes to the kernel code and would be supported by the base system moving forward. Are you planning to submit a PR with this patch? Also are the m_tag, or altq_tag the same tags created with the ipfw tag command? -- Derek From ermal.luci at gmail.com Fri May 9 16:36:53 2008 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Fri May 9 16:36:58 2008 Subject: Dummynet, gif, and ipsec In-Reply-To: <48247901.3000706@razorfever.net> References: <9a542da30805080844t395c8c81sd313fc2fd1780fcb@mail.gmail.com> <48247901.3000706@razorfever.net> Message-ID: <9a542da30805090936l222a58bcy5b926cba01d62ce6@mail.gmail.com> On Fri, May 9, 2008 at 6:17 PM, Derek (freebsd-ipfw) <482254ac@razorfever.net> wrote: > Ermal Lu?i wrote: >> >> Well this is a patch to shape IPSec tunnels with ALTQ and FreeBSD 6.3 >> as you are running. It is another alternative to dummynet though it >> have been tested with pf but should work with ipfw too since it knows >> about ALTQ. >> Hope it helps! >> > > Hi Ermal, > > Thanks for the response! > > I'm looking to roll this out on 5-7 machines, so I'm really looking for a > solution where we wouldn't have to make changes to the kernel code and would > be supported by the base system moving forward. > > Are you planning to submit a PR with this patch? > > Also are the m_tag, or altq_tag the same tags created with the ipfw tag > command? > As far as i am aware this should be transparent to ipfw. Meaning it should work since ipfw speaks ALTQ tags so no problems should arise. It is in use in production machines as a patch so you can be sure it works reliably. I can submit the PR but i think it is better if somebody with ipsec competence comments about its eligibility. I CC'd freebsd-net@ so somebody will speak for this more rather than place it on PR that nobody would look at. Ermal > -- Derek > From mpope at teksavvy.com Sat May 10 06:13:43 2008 From: mpope at teksavvy.com (Matthew) Date: Sat May 10 06:13:47 2008 Subject: Dummynet on Bridge on FreeBSD in VMware, its possible right? Message-ID: <48253CDD.6090702@teksavvy.com> Hello, I have been pointed in the right direction that I need to run dummynet in a bridge configuration rather than a router configuration. I have carefully followed the instructions for setting up a bridge in http://www.freebsd.org/doc/en/articles/filtering-bridges/article.html and read numerous man pages, Usenet postings, internet postings, etc. Here's a crude schematic of my setup: (switch to fixed width font) [gateway(.1)]--ether--[le0 (.175) FreeBSD bridge le1]<-->VMNet2<-->[(.176)Ubuntu client] |---------------- H O S T Ubuntu P C at (.174)-------------------| The (left) outside end of the bridge (le0) has IP 192.168.111.175 gw 192.168.111.1, using a VMware Bridged Adapter. The inside end of the bridge (on right side) does not have an IP (le1) and is a VMNet2 adaptor. My (VMware) Ubuntu client connects to the inside end of the bridge via its own VMNet2 adapter at 192.168.111.176. The bridge is up with both interfaces promiscuous, and in discovery mode. Indeed I can: - ping OK from the FreeBSD-vm to the gateway(.1), to the Ubuntu client (.176), and to the host PC (.174) - ping OK from the Ubuntu client to the outside end of the bridge (.175), and no further - ping OK from the host PC (.174) to the bridge outside IP (.175) but not further to the client I tried an experiment of using VMNet1 host-only networking for the outside-end of the bridge, and adding 3 lines of undecipherable iptable commands that had the effect of making the host pc act as a gateway. It worked, but I got exactly the same results as above (except gateway was local PC (.174)), so I reverted to the more straightforward VMNet Bridged adapter architecture for the outside end of the bridge(.175). I am running 7.0-RELEASE #0, original kernel. /boot/loader.conf loads these modules only: if_bridge_load="YES" dummynet_load="YES" /etc/sysctl.conf: sysctl net.inet.ip.fw.enable=1 sysctl net.link.bridge.ipfw=1 sysctl net.inet.ip.fw.one_pass=1 /etc/rc.conf: (relevant parts) hostname="freebsdvm" defaultrouter="192.168.111.1" gateway_enable="NO" cloned_interfaces="bridge0" ifconfig_bridge0="addm le0 addm le1 up" ifconfig_le0="inet 192.168.111.175 netmask 255.255.255.0 up" ifconfig_le1="up" firewall_enable="YES" firewall_type="open" firewall_logging="YES" ifconfig output: le0: flags=8943 metric 0 mtu 1500 options=8 ether 00:50:56:84:52:ac inet 192.168.111.175 netmask 0xffffff00 broadcast 192.168.111.255 media: Ethernet autoselect status: active le1: flags=8943 metric 0 mtu 1500 options=8 ether 00:0c:29:5c:5e:7f media: Ethernet autoselect status: active plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 bridge0: flags=8843 metric 0 mtu 1500 ether 7a:e4:f7:21:7a:14 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: le1 flags=143 netstat -rn (ipv4 part only): Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.111.1 UGS 0 52 le0 127.0.0.1 127.0.0.1 UH 0 0 lo0 192.168.111.0/24 link#1 UC 0 0 le0 192.168.111.1 00:0b:46:57:c7:bc UHLW 2 2 le0 1037 192.168.111.174 00:1d:60:b9:40:07 UHLW 1 98 le0 1199 192.168.111.175 00:50:56:84:52:ac UHLW 1 4 lo0 192.168.111.176 00:0c:29:96:6c:59 UHLW 1 7 le0 1064 The only thing that seems amiss to me is the above routes indicate the Ubuntu client (.176) was reached by the bridge via le0 (outside interface) rather than le1 (inside interface) to which the Ubuntu client is directly connected via a VMNet2 adapter. Since the Ubuntu client has only the single (VMnet2) interface, it seems impossible, or at least undesired, that the FreeBSD bridge host reached the Ubuntu client via the outside interface (le0) as indicated in the 'netstat -rn' output, but I'm not a networking specialist so its quite possible I'm missing something here. I've regressed from specifying dummynet pipes and queues to plain firewall rules (canned from the article quoted above) until I can solve this 'FreeBSD bridge on VMWare' networking working. rc.firewall: ipfw add 100 pass all from any to any via lo0 ipfw add 200 deny all from any to 127.0.0.0/8 ipfw add 300 deny ip from 127.0.0.0/8 to any # allow bridge machine to say anything it wants ipfw add pass tcp from 192.168.111.175 to any setup keep-state ipfw add pass ip from 192.168.111.175 to any # allow the inside hosts to say anything they want ipfw add pass tcp from any to any in via le1 setup keep-state ipfw add pass ip from any to any in via le1 # UDP section # allow DNS only toward the name server ipfw add pass udp from any to 69.39.192.130 53 in via le1 keep-state # ICMP section # pass ping ipfw add pass icmp from any to any icmptypes 8 keep-state # pass error messages generated by 'traceroute' ipfw add pass icmp from any to any icmptypes 3 ipfw add pass icmp from any to any icmptypes 11 ipfw add 65000 allow log all from any to any BTW, when I say some pings fail, I mean they return the message: 'Destination Host Unreachable' Thank you, Matthew (in Toronto) From mpope at teksavvy.com Sat May 10 14:11:56 2008 From: mpope at teksavvy.com (Matthew) Date: Sat May 10 14:12:01 2008 Subject: Dummynet on Bridge on FreeBSD in VMware, its possible right? In-Reply-To: <48253CDD.6090702@teksavvy.com> References: <48253CDD.6090702@teksavvy.com> Message-ID: <4825AD32.9040309@teksavvy.com> I should add that the Ubuntu VMware client has its gateway set to 192.168.111.1 Also below I've added a line I missed when pasting in the ifconfig output. -Thx, Matthew > Hello, > I have been pointed in the right direction that I need to run dummynet > in a bridge configuration rather than a router configuration. I have > carefully followed the instructions for setting up a bridge in > http://www.freebsd.org/doc/en/articles/filtering-bridges/article.html > and read numerous man pages, Usenet postings, internet postings, etc. > Here's a crude schematic of my setup: (switch to fixed width font) > > [gateway(.1)]--ether--[le0 (.175) FreeBSD bridge > le1]<-->VMNet2<-->[(.176)Ubuntu client] > |---------------- H O S T Ubuntu P C at > (.174)-------------------| > > The (left) outside end of the bridge (le0) has IP 192.168.111.175 gw > 192.168.111.1, using a VMware Bridged Adapter. The inside end of the > bridge (on right side) does not have an IP (le1) and is a VMNet2 > adaptor. My (VMware) Ubuntu client connects to the inside end of the > bridge via its own VMNet2 adapter at 192.168.111.176. > > The bridge is up with both interfaces promiscuous, and in discovery > mode. Indeed I can: > - ping OK from the FreeBSD-vm to the gateway(.1), to the Ubuntu client > (.176), and to the host PC (.174) > - ping OK from the Ubuntu client to the outside end of the bridge > (.175), and no further > - ping OK from the host PC (.174) to the bridge outside IP (.175) but > not further to the client > > I tried an experiment of using VMNet1 host-only networking for the > outside-end of the bridge, and adding 3 lines of undecipherable > iptable commands that had the effect of making the host pc act as a > gateway. It worked, but I got exactly the same results as above > (except gateway was local PC (.174)), so I reverted to the more > straightforward VMNet Bridged adapter architecture for the outside end > of the bridge(.175). > > I am running 7.0-RELEASE #0, original kernel. /boot/loader.conf loads > these modules only: > if_bridge_load="YES" > dummynet_load="YES" > > /etc/sysctl.conf: > sysctl net.inet.ip.fw.enable=1 > sysctl net.link.bridge.ipfw=1 > sysctl net.inet.ip.fw.one_pass=1 > > /etc/rc.conf: (relevant parts) > hostname="freebsdvm" > defaultrouter="192.168.111.1" > gateway_enable="NO" > cloned_interfaces="bridge0" > ifconfig_bridge0="addm le0 addm le1 up" > ifconfig_le0="inet 192.168.111.175 netmask 255.255.255.0 up" > ifconfig_le1="up" > firewall_enable="YES" > firewall_type="open" > firewall_logging="YES" > > ifconfig output: > le0: flags=8943 metric > 0 mtu 1500 > options=8 > ether 00:50:56:84:52:ac > inet 192.168.111.175 netmask 0xffffff00 broadcast 192.168.111.255 > media: Ethernet autoselect > status: active > le1: flags=8943 metric > 0 mtu 1500 > options=8 > ether 00:0c:29:5c:5e:7f > media: Ethernet autoselect > status: active > plip0: flags=108810 metric 0 > mtu 1500 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > bridge0: flags=8843 metric 0 > mtu 1500 > ether 7a:e4:f7:21:7a:14 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: le1 flags=143 and member: le0 flags=143 > > > netstat -rn (ipv4 part only): > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default 192.168.111.1 UGS 0 52 le0 > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > 192.168.111.0/24 link#1 UC 0 0 le0 > 192.168.111.1 00:0b:46:57:c7:bc UHLW 2 2 le0 > 1037 > 192.168.111.174 00:1d:60:b9:40:07 UHLW 1 98 le0 > 1199 > 192.168.111.175 00:50:56:84:52:ac UHLW 1 4 lo0 > 192.168.111.176 00:0c:29:96:6c:59 UHLW 1 7 le0 > 1064 > > The only thing that seems amiss to me is the above routes indicate the > Ubuntu client (.176) was reached by the bridge via le0 (outside > interface) rather than le1 (inside interface) to which the Ubuntu > client is directly connected via a VMNet2 adapter. Since the Ubuntu > client has only the single (VMnet2) interface, it seems impossible, or > at least undesired, that the FreeBSD bridge host reached the Ubuntu > client via the outside interface (le0) as indicated in the 'netstat > -rn' output, but I'm not a networking specialist so its quite possible > I'm missing something here. > > I've regressed from specifying dummynet pipes and queues to plain > firewall rules (canned from the article quoted above) until I can > solve this 'FreeBSD bridge on VMWare' networking working. > > rc.firewall: > ipfw add 100 pass all from any to any via lo0 > ipfw add 200 deny all from any to 127.0.0.0/8 > ipfw add 300 deny ip from 127.0.0.0/8 to any > # allow bridge machine to say anything it wants > ipfw add pass tcp from 192.168.111.175 to any setup keep-state > ipfw add pass ip from 192.168.111.175 to any > > # allow the inside hosts to say anything they want > ipfw add pass tcp from any to any in via le1 setup keep-state > ipfw add pass ip from any to any in via le1 > > # UDP section > # allow DNS only toward the name server > ipfw add pass udp from any to 69.39.192.130 53 in via le1 keep-state > > # ICMP section > # pass ping > ipfw add pass icmp from any to any icmptypes 8 keep-state > # pass error messages generated by 'traceroute' > ipfw add pass icmp from any to any icmptypes 3 > ipfw add pass icmp from any to any icmptypes 11 > > ipfw add 65000 allow log all from any to any > > BTW, when I say some pings fail, I mean they return the message: > 'Destination Host Unreachable' > Thank you, > Matthew (in Toronto) > > > > > > > > > > > > _______________________________________________ > 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 joost at jodocus.org Mon May 12 06:40:03 2008 From: joost at jodocus.org (Joost Bekkers) Date: Mon May 12 06:40:05 2008 Subject: kern/117234: [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't seem to support IPV6 Message-ID: <200805120640.m4C6e3Uu012661@freefall.freebsd.org> The following reply was made to PR kern/117234; it has been noted by GNATS. From: "Joost Bekkers" To: "Max Laier" , bug-followup@FreeBSD.org Cc: john.w.court@nokia.com Subject: Re: kern/117234: [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't seem to support IPV6 Date: Mon, 12 May 2008 08:40:04 +0200 (CEST) Hello I've just tried the patch in this PR and found it not to work (yet). The keep-alive packets that are sent for IPv6 have their tcp port octets in the wrong order. Eg. if a dynamic rule exists for a connetion to port 4000 (0x0FA0), the keepalives are sent to 40975 (0xA00F) I haven't looked into where this difference between ipv4 and ipv6 originates, but forcing the byte-swap in send_pkt() makes everything work. I'd post the change I made, but I'm fairly sertain it's The Wrong Way (tm) to fix this. Greetings Joost. From bugmaster at FreeBSD.org Mon May 12 11:06:59 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 12 11:07:05 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200805121106.m4CB6wOW038030@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/106534 ipfw [ipfw] [panic] ipfw + dummynet 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 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 [ipfw] [patch] ipfw verbosity locks machine if /etc/rc 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/111713 ipfw [dummynet] [request] Too few dummynet queue slots 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 30 problems total. From madan.feedback at gmail.com Wed May 14 08:24:31 2008 From: madan.feedback at gmail.com (Madan Thapa) Date: Wed May 14 08:24:33 2008 Subject: issues : FreeBSD kernel compile for ipfw support Message-ID: <3a4237470805140100k4eeecb4aja4f6449b6a93ffb6@mail.gmail.com> Hi to all, I am freebsd newbie at the moment and want your help on the following issues : 1) I compiled bsd kernel for ipfw support using the doc at http://www.cyberciti.biz/faq/howto-setup-freebsd-ipfw-firewall/ and upon reboot, the system did not allow connections from outside. I could login to the server remotely via IPMI but not via ssh, although, ipfw entries were not setup in /etc/rc.conf to start on boot. So I ended up booting into old kernel ( generic ) , instead of IPFWKERNEL Now I want to know how to change the boot loader to boot the Generic kernel on subsequent reboots. Like in linux we do it in grub.conf 2) Can you also let me know the steps to add ipfw support in kernel? 3) How do I check that ipfw support is already there? # ipfw list will do ? Thanks From bu7cher at yandex.ru Wed May 14 09:02:49 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Wed May 14 09:02:57 2008 Subject: issues : FreeBSD kernel compile for ipfw support In-Reply-To: <3a4237470805140100k4eeecb4aja4f6449b6a93ffb6@mail.gmail.com> References: <3a4237470805140100k4eeecb4aja4f6449b6a93ffb6@mail.gmail.com> Message-ID: <482AAAAD.9090809@yandex.ru> Madan Thapa wrote: > 1) I compiled bsd kernel for ipfw support using the doc at > http://www.cyberciti.biz/faq/howto-setup-freebsd-ipfw-firewall/ and upon I prefer an official documentation: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html > reboot, the system did not allow connections from outside. Yes, the default configuration blocks any packets. > I could login to > the server remotely via IPMI but not via ssh, although, ipfw entries were > not setup in /etc/rc.conf to start on boot. You compiled ipfw(9) into kernel and it works by default. > on subsequent reboots. Like in linux we do it in grub.conf You can install grub on the FreeBSD too. > 2) Can you also let me know the steps to add ipfw support in kernel? Read the Handbook's article. -- WBR, Andrey V. Elsukov From madan.feedback at gmail.com Wed May 14 13:47:06 2008 From: madan.feedback at gmail.com (Madan Thapa) Date: Wed May 14 13:47:11 2008 Subject: issues : FreeBSD kernel compile for ipfw support In-Reply-To: <482AAAAD.9090809@yandex.ru> References: <3a4237470805140100k4eeecb4aja4f6449b6a93ffb6@mail.gmail.com> <482AAAAD.9090809@yandex.ru> Message-ID: <3a4237470805140647u4d38ebfaw797ab004afd63912@mail.gmail.com> Thanks a ton Andrey > WBR, Andrey V. Elsukov > From madan.feedback at gmail.com Thu May 15 04:27:43 2008 From: madan.feedback at gmail.com (Madan Thapa) Date: Thu May 15 04:27:47 2008 Subject: issues : FreeBSD kernel compile for ipfw support In-Reply-To: <482B7030.6090402@elischer.org> References: <3a4237470805140100k4eeecb4aja4f6449b6a93ffb6@mail.gmail.com> <482B7030.6090402@elischer.org> Message-ID: <3a4237470805142127p2642590j6d39376701762ea9@mail.gmail.com> Julian, Thank you very much for your help. ################################################################ you can do it via grub if you sodesire, or you can change the file > /boot/loader.conf to select a different kernel > (google should be able to tell you the right syntax) > > look for "loader.conf kernel" > > you can disable the firewall during boot by adding: > net.ip.fw.enable=0 > in a file called /etc/sysctl.conf > then it will not be turned on until you turn it on. > I suggest that you load it with rules that allow you to get into the > machine before you turn it on however.. > ################################################################ > >> >> >> From bu7cher at yandex.ru Thu May 15 09:52:40 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Thu May 15 09:52:45 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> References: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> Message-ID: <482C07DE.3090504@yandex.ru> Vivek Khera wrote: > I had a box run out of dynamic state space yesterday. I found I can > increase the number of dynamic rules by increasing the sysctl parameter > net.inet.ip.fw.dyn_max. I can't find, however, how this affects memory > usage on the system. Is it dyanamically allocated and de-allocated, or > is it a static memory buffer? Each dynamic rule allocated dynamically. Be careful, too many dynamic rules will work very slow. -- WBR, Andrey V. Elsukov From bms at FreeBSD.org Thu May 15 10:19:21 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu May 15 10:19:43 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: <482C07DE.3090504@yandex.ru> References: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> <482C07DE.3090504@yandex.ru> Message-ID: <482C0A89.104@FreeBSD.org> Andrey V. Elsukov wrote: > Vivek Khera wrote: >> I had a box run out of dynamic state space yesterday. I found I can >> increase the number of dynamic rules by increasing the sysctl >> parameter net.inet.ip.fw.dyn_max. I can't find, however, how this >> affects memory usage on the system. Is it dyanamically allocated and >> de-allocated, or is it a static memory buffer? > > Each dynamic rule allocated dynamically. Be careful, too many dynamic > rules will work very slow. Got any figures for this? I took a quick glance and it looks like it just uses a hash over dst/src/dport/sport. If there are a lot of raw IP or ICMP flows then that's going to result in hash collisions. It might be a good project for someone to optimize if it isn't scaling for folk. "Bloomier" filters are probably worth a look -- bloom filters are a class of probabilistic hash which may return a false positive, "bloomier" filters are a refinement which tries to limit the false positives. Having said that the default tunable of 256 state entries is probably quite low for use cases other than "home/small office NAT gateway". cheers BMS From vivek at khera.org Thu May 15 16:28:52 2008 From: vivek at khera.org (Vivek Khera) Date: Thu May 15 16:28:57 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: <482C0A89.104@FreeBSD.org> References: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> <482C07DE.3090504@yandex.ru> <482C0A89.104@FreeBSD.org> Message-ID: <6ADAB997-FAA4-43B8-AB57-3CC4A04F3700@khera.org> On May 15, 2008, at 6:03 AM, Bruce M. Simpson wrote: > Having said that the default tunable of 256 state entries is > probably quite low for use cases other than "home/small office NAT > gateway". The deafult on my systems seems to be 4096. My steady state on a pretty popular web server is about 400, on a busy inbound mail server, around 800 states. I need to account for peaks much higher, though. Luckily most of my connections are short-lived. Thanks for the answers! From koitsu at FreeBSD.org Thu May 15 16:38:55 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu May 15 16:38:59 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: <482C0A89.104@FreeBSD.org> References: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> <482C07DE.3090504@yandex.ru> <482C0A89.104@FreeBSD.org> Message-ID: <20080515162056.GA17187@eos.sc1.parodius.com> On Thu, May 15, 2008 at 11:03:53AM +0100, Bruce M. Simpson wrote: > Andrey V. Elsukov wrote: >> Vivek Khera wrote: >>> I had a box run out of dynamic state space yesterday. I found I can >>> increase the number of dynamic rules by increasing the sysctl parameter >>> net.inet.ip.fw.dyn_max. I can't find, however, how this affects memory >>> usage on the system. Is it dyanamically allocated and de-allocated, or >>> is it a static memory buffer? >> >> Each dynamic rule allocated dynamically. Be careful, too many dynamic >> rules will work very slow. > > Got any figures for this? I took a quick glance and it looks like it just > uses a hash over dst/src/dport/sport. If there are a lot of raw IP or ICMP > flows then that's going to result in hash collisions. > > It might be a good project for someone to optimize if it isn't scaling for > folk. "Bloomier" filters are probably worth a look -- bloom filters are a > class of probabilistic hash which may return a false positive, "bloomier" > filters are a refinement which tries to limit the false positives. > > Having said that the default tunable of 256 state entries is probably quite > low for use cases other than "home/small office NAT gateway". It's far too low for home/small office. Standard Linux NAT routers, such as the Linksys WRT54G/GL, come with a default state table count of 2048, and often is increased by third-party firmwares to 8192 based on justified necessity. Search for "conntrack" below: http://www.polarcloud.com/firmware 256 can easily be exhausted by more than one user loading multiple HTTP 1.0 web pages at one time (such is the case with many users now have browsers that load 7-8 web pages into separate tabs during startup). And if that's not enough reason, consider torrents, which is quite often what results in a home or office router exhausting its state table. Bottom line: the 256 default is too low. It needs to be increased to at least 2048. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sem at FreeBSD.org Thu May 15 17:57:01 2008 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Thu May 15 17:57:05 2008 Subject: Strange swap values in top(1) on 7.0-RELEASE Message-ID: <482C7043.3080901@FreeBSD.org> I see strange top(1) output for swap: Swap: 8064K Total, 8168K Used, K Free, 101% Inuse swapinfo output looks good: Device 1K-blocks Used Avail Capacity /dev/mirror/m1b 8192 8168 24 100% -- Dixi. Sem. From smithi at nimnet.asn.au Fri May 16 04:20:40 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri May 16 04:20:46 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: <20080515162056.GA17187@eos.sc1.parodius.com> Message-ID: On Thu, 15 May 2008, Jeremy Chadwick wrote: > On Thu, May 15, 2008 at 11:03:53AM +0100, Bruce M. Simpson wrote: > > Andrey V. Elsukov wrote: > >> Vivek Khera wrote: > >>> I had a box run out of dynamic state space yesterday. I found I can > >>> increase the number of dynamic rules by increasing the sysctl parameter > >>> net.inet.ip.fw.dyn_max. I can't find, however, how this affects memory > >>> usage on the system. Is it dyanamically allocated and de-allocated, or > >>> is it a static memory buffer? > >> > >> Each dynamic rule allocated dynamically. Be careful, too many dynamic > >> rules will work very slow. > > > > Got any figures for this? I took a quick glance and it looks like it just > > uses a hash over dst/src/dport/sport. If there are a lot of raw IP or ICMP > > flows then that's going to result in hash collisions. > > > > It might be a good project for someone to optimize if it isn't scaling for > > folk. "Bloomier" filters are probably worth a look -- bloom filters are a > > class of probabilistic hash which may return a false positive, "bloomier" > > filters are a refinement which tries to limit the false positives. > > > > Having said that the default tunable of 256 state entries is probably quite > > low for use cases other than "home/small office NAT gateway". > > It's far too low for home/small office. Standard Linux NAT routers, > such as the Linksys WRT54G/GL, come with a default state table count of > 2048, and often is increased by third-party firmwares to 8192 based on > justified necessity. Search for "conntrack" below: > > http://www.polarcloud.com/firmware > > 256 can easily be exhausted by more than one user loading multiple HTTP > 1.0 web pages at one time (such is the case with many users now have > browsers that load 7-8 web pages into separate tabs during startup). > > And if that's not enough reason, consider torrents, which is quite often > what results in a home or office router exhausting its state table. > > Bottom line: the 256 default is too low. It needs to be increased to at > least 2048. I think there may be some confusion in terms. Looking at defaults on my older 5.5 system - sure, call it a "home/small office NAT gateway": net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_count: 212 net.inet.ip.fw.dyn_max: 4096 net.inet.ip.fw.static_count: 153 What defaults to 256 is the number of hash table buckets, not the max number of dynamic rules, here 4096 (though the 5.5 manual says 8192). On hash collisions, a linked list is used for duplicate hashes of: i = (id->dst_ip) ^ (id->src_ip) ^ (id->dst_port) ^ (id->src_port); i &= (curr_dyn_buckets - 1); So while 256 may well be too few buckets for many systems, and like Bruce I wonder about the effectiveness of the xor hash for raw IP & ICMP and wouldn't mind seeing some stats on bucket use vs linked list lengths for various workloads, it doesn't determine the max no. of dynamic rules available, which is adjustable up without any apparent static memory allocation, and is moderated by the various expiry timeout sysctls. For reference, I admin a 4.8 filtering bridge with up to 20 boxes behind it, that has only very rarely reported exceeding the max no. of dynamic rules with the (4.8) default net.inet.ip.fw.dyn_max of 1000 .. however it only keeps state for UDP connections (and yes, it only ever hits that limit on torrents or skype, which are generally admin. prohib. :) cheers, Ian (not subscribed to -ipfw) From bu7cher at yandex.ru Fri May 16 04:33:18 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Fri May 16 04:33:22 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: <482C0A89.104@FreeBSD.org> References: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> <482C07DE.3090504@yandex.ru> <482C0A89.104@FreeBSD.org> Message-ID: <482D0E87.6000003@yandex.ru> Bruce M. Simpson wrote: > Got any figures for this? I took a quick glance and it looks like it > just uses a hash over dst/src/dport/sport. If there are a lot of raw IP > or ICMP flows then that's going to result in hash collisions. It's my guess, i haven't any figures.. Yes, hash collisions will trigger many searching in buckets lists. And increasing only dyn_max without increasing dyn_buckets will grow collisions. > It might be a good project for someone to optimize if it isn't scaling > for folk. "Bloomier" filters are probably worth a look -- bloom filters > are a class of probabilistic hash which may return a false positive, > "bloomier" filters are a refinement which tries to limit the false > positives. There were some ideas from Vadim Goncharov about rewriting dynamic rules implementation.. -- WBR, Andrey V. Elsukov From vivek at khera.org Fri May 16 14:53:08 2008 From: vivek at khera.org (Vivek Khera) Date: Fri May 16 14:53:13 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: <6ADAB997-FAA4-43B8-AB57-3CC4A04F3700@khera.org> References: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> <482C07DE.3090504@yandex.ru> <482C0A89.104@FreeBSD.org> <6ADAB997-FAA4-43B8-AB57-3CC4A04F3700@khera.org> Message-ID: How are the buckets used? Are they hashed per rule number or some other mechanism? Nearly all of my states are from the same rule (eg, on a mail server for the SMTP port rule). How should I scale the buckets with the max rules? The default seems to be 4096 rules and 256 buckets. Should I maintain that ratio? From smithi at nimnet.asn.au Sun May 18 07:26:48 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun May 18 07:26:51 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: Message-ID: On Fri, 16 May 2008, Vivek Khera wrote: > How are the buckets used? Are they hashed per rule number or some > other mechanism? Nearly all of my states are from the same rule (eg, > on a mail server for the SMTP port rule). /sys/netinet/ip_fw.h /sys/netinet/ip_fw2.c Hashed per flow, (srcip^destip^srcport^dstport) mod curr_dyn_buckets, so packets for both directions of a given flow hash to the same bucket. In the case you mention, you could likely expect reasonable distribution by src_ip/src_port. The rule number doesn't contribute to the hash, but is contained in the dynamic rule entry, ie a matched flow resolves to its rule at the first check_state or keep_state rule encountered. Try searching for '_STATE'. Each bucket just contains a pointer, so on i386 I'd expect 1KB per 256 buckets, see realloc_dynamic_table. The 'pointees', ipfw_dyn_rule, are around 70? bytes each with 32-bit pointers, so 4K current dynamic rules should use around 280KB? Somebody yell if I'm badly miscalculating .. > How should I scale the buckets with the max rules? The default seems > to be 4096 rules and 256 buckets. Should I maintain that ratio? Sounds reasonable. Extra buckets look cheap, if I'm reading it right, and memory otherwise appears to be only allocated on use, per new flow, but I'm ignorant of any other memory allocation overheads. caveats: 5.5 sources; C is read-only here; not subscribed to -ipfw cheers, Ian From oleksandr at samoylyk.sumy.ua Sun May 18 19:09:12 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sun May 18 19:09:16 2008 Subject: ipfw and smtp port rewriting Message-ID: <48307AAE.9010906@samoylyk.sumy.ua> Hello freebsd-ipfw, I'd like to make smtp port rewriting for any destination by means of ipfw. With iptables I just used this rule in order to achieve this functionality: iptables -t nat -A PREROUTING -i ppp+ -p tcp --dport 2525 -j DNAT --to-destination :25 Reading man ipfw and playing a bit with rules I composed this rule, which doesn't however work: ipfw add fwd any,2525 tcp from any to any 25 via ${tun} How to achieve the same functionality as in iptables for smtp port rewriting for any destination? Thanks! -- Oleksandr Samoylyk OVS-RIPE From julian at elischer.org Sun May 18 23:05:51 2008 From: julian at elischer.org (Julian Elischer) Date: Sun May 18 23:05:57 2008 Subject: ipfw and smtp port rewriting In-Reply-To: <48307AAE.9010906@samoylyk.sumy.ua> References: <48307AAE.9010906@samoylyk.sumy.ua> Message-ID: <4830B37F.3020207@elischer.org> Oleksandr Samoylyk wrote: > Hello freebsd-ipfw, > > I'd like to make smtp port rewriting for any destination by means of ipfw. > > With iptables I just used this rule in order to achieve this functionality: > > iptables -t nat -A PREROUTING -i ppp+ -p tcp --dport 2525 -j DNAT > --to-destination :25 > > Reading man ipfw and playing a bit with rules I composed this rule, > which doesn't however work: > > ipfw add fwd any,2525 tcp from any to any 25 via ${tun} > > How to achieve the same functionality as in iptables for smtp port > rewriting for any destination? > > Thanks! > in current (and I think 7.0) you can use the 'nat' keyword and may be able to achieve something with that.. just an idea. fwd doesn't change the packet, jsut what you DO with the packet so 'fwd'ing to a different port is only effective if you are accepting the packet yourself, and not if you are sending it to the next hop. From bugmaster at FreeBSD.org Mon May 19 11:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 19 11:07:25 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200805191106.m4JB6r5H011599@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/106534 ipfw [ipfw] [panic] ipfw + dummynet 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 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 [ipfw] [patch] ipfw verbosity locks machine if /etc/rc 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/111713 ipfw [dummynet] [request] Too few dummynet queue slots 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 30 problems total. From oleksandr at samoylyk.sumy.ua Mon May 19 14:18:32 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Mon May 19 14:18:36 2008 Subject: ipfw and smtp port rewriting In-Reply-To: <20080519141602.GB7648@tin.it> References: <48307AAE.9010906@samoylyk.sumy.ua> <20080519141602.GB7648@tin.it> Message-ID: <48318C25.2090703@samoylyk.sumy.ua> Paolo Pisati wrote: > On Sun, May 18, 2008 at 09:51:26PM +0300, Oleksandr Samoylyk wrote: >> Hello freebsd-ipfw, >> >> I'd like to make smtp port rewriting for any destination by means of ipfw. >> >> With iptables I just used this rule in order to achieve this functionality: >> >> iptables -t nat -A PREROUTING -i ppp+ -p tcp --dport 2525 -j DNAT >> --to-destination :25 > > ipfw nat 123 config redirect_port tcp YOURIP:2525 25 > ipfw add nat 123 tcp from any to any > > or something along the line. > Will it work for any destination? -- Oleksandr Samoylyk OVS-RIPE From piso at FreeBSD.org Mon May 19 14:38:34 2008 From: piso at FreeBSD.org (Paolo Pisati) Date: Mon May 19 14:38:38 2008 Subject: ipfw and smtp port rewriting In-Reply-To: <48318C25.2090703@samoylyk.sumy.ua> References: <48307AAE.9010906@samoylyk.sumy.ua> <20080519141602.GB7648@tin.it> <48318C25.2090703@samoylyk.sumy.ua> Message-ID: <20080519143839.GA8082@tin.it> On Mon, May 19, 2008 at 05:18:13PM +0300, Oleksandr Samoylyk wrote: > > Will it work for any destination? redirect_port tcp $fooip:666 999 incoming tcp packets destined for port 999 will be redirected to $fooip port 666. See redirect modes in natd(8) for more info. -- bye, P. From piso at freebsd.org Mon May 19 14:45:55 2008 From: piso at freebsd.org (Paolo Pisati) Date: Mon May 19 14:46:02 2008 Subject: ipfw and smtp port rewriting In-Reply-To: <48307AAE.9010906@samoylyk.sumy.ua> References: <48307AAE.9010906@samoylyk.sumy.ua> Message-ID: <20080519141602.GB7648@tin.it> On Sun, May 18, 2008 at 09:51:26PM +0300, Oleksandr Samoylyk wrote: > Hello freebsd-ipfw, > > I'd like to make smtp port rewriting for any destination by means of ipfw. > > With iptables I just used this rule in order to achieve this functionality: > > iptables -t nat -A PREROUTING -i ppp+ -p tcp --dport 2525 -j DNAT > --to-destination :25 ipfw nat 123 config redirect_port tcp YOURIP:2525 25 ipfw add nat 123 tcp from any to any or something along the line. -- bye, P. From vivek at khera.org Mon May 19 16:13:21 2008 From: vivek at khera.org (Vivek Khera) Date: Mon May 19 16:13:30 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: References: Message-ID: <43327C1A-AF98-4076-AAE4-3A59F6FC074E@khera.org> On May 18, 2008, at 3:26 AM, Ian Smith wrote: > Hashed per flow, (srcip^destip^srcport^dstport) mod > curr_dyn_buckets, so > packets for both directions of a given flow hash to the same > bucket. In > the case you mention, you could likely expect reasonable > distribution by > src_ip/src_port. Thanks for the detailed info. This really helps. From joost at jodocus.org Mon May 19 20:20:04 2008 From: joost at jodocus.org (Joost Bekkers) Date: Mon May 19 20:20:07 2008 Subject: kern/117234: [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't seem to support IPV6 Message-ID: <200805192020.m4JKK4Cd063838@freefall.freebsd.org> The following reply was made to PR kern/117234; it has been noted by GNATS. From: "Joost Bekkers" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/117234: [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't seem to support IPV6 Date: Mon, 19 May 2008 22:15:20 +0200 (CEST) ------=_20080519221520_63844 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Found the problem. Two hton() statements went missing with the original patch from mlaier@. I've attatched a corrected version of the original diff and one against 7.0R ------=_20080519221520_63844 Content-Type: application/octet-stream; name="ipfw_v6send.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw_v6send.diff" SW5kZXg6IGlwX2Z3Mi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9u ZXRpbmV0L2lwX2Z3Mi5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjE3NQpkaWZmIC11IC1yMS4x NzUgaXBfZncyLmMKLS0tIGlwX2Z3Mi5jCTcgT2N0IDIwMDcgMjA6NDQ6MjMgLTAwMDAJMS4xNzUK KysrIGlwX2Z3Mi5jCTE5IE9jdCAyMDA3IDEyOjM4OjE2IC0wMDAwCkBAIC05OCw2ICs5OCw3IEBA CiAjaW5jbHVkZSA8bmV0aW5ldC9pcDYuaD4KICNpbmNsdWRlIDxuZXRpbmV0L2ljbXA2Lmg+CiAj aWZkZWYgSU5FVDYKKyNpbmNsdWRlIDxuZXRpbmV0Ni9pcDZfdmFyLmg+CiAjaW5jbHVkZSA8bmV0 aW5ldDYvc2NvcGU2X3Zhci5oPgogI2VuZGlmCiAKQEAgLTI0MSw2ICsyNDIsOSBAQAogI2RlZmlu ZQlJUEZXX0RZTl9VTkxPQ0soKQltdHhfdW5sb2NrKCZpcGZ3X2R5bl9tdHgpCiAjZGVmaW5lCUlQ RldfRFlOX0xPQ0tfQVNTRVJUKCkJbXR4X2Fzc2VydCgmaXBmd19keW5fbXR4LCBNQV9PV05FRCkK IAorc3RhdGljIHN0cnVjdCBtYnVmICpzZW5kX3BrdChzdHJ1Y3QgbWJ1ZiAqLCBzdHJ1Y3QgaXBm d19mbG93X2lkICosCisgICAgdV9pbnQzMl90LCB1X2ludDMyX3QsIGludCk7CisKIC8qCiAgKiBU aW1lb3V0cyBmb3IgdmFyaW91cyBldmVudHMgaW4gaGFuZGluZyBkeW5hbWljIHJ1bGVzLgogICov CkBAIC02NzEsNjcgKzY3NSwyNSBAQAogfQogCiBzdGF0aWMgdm9pZAotc2VuZF9yZWplY3Q2KHN0 cnVjdCBpcF9md19hcmdzICphcmdzLCBpbnQgY29kZSwgdV9pbnQgaGxlbiwgc3RydWN0IGlwNl9o ZHIgKmlwNikKK3NlbmRfcmVqZWN0NihzdHJ1Y3QgaXBfZndfYXJncyAqYXJncywgaW50IGNvZGUs IHVfaW50IGhsZW4sCisgICAgc3RydWN0IGlwNl9oZHIgKmlwNikKIHsKIAlzdHJ1Y3QgbWJ1ZiAq bTsKIAogCW0gPSBhcmdzLT5tOwogCWlmIChjb2RlID09IElDTVA2X1VOUkVBQ0hfUlNUICYmIGFy Z3MtPmZfaWQucHJvdG8gPT0gSVBQUk9UT19UQ1ApIHsKIAkJc3RydWN0IHRjcGhkciAqdGNwOwot CQl0Y3Bfc2VxIGFjaywgc2VxOwotCQlpbnQgZmxhZ3M7Ci0JCXN0cnVjdCB7Ci0JCQlzdHJ1Y3Qg aXA2X2hkciBpcDY7Ci0JCQlzdHJ1Y3QgdGNwaGRyIHRoOwotCQl9IHRpOwogCQl0Y3AgPSAoc3Ry dWN0IHRjcGhkciAqKSgoY2hhciAqKWlwNiArIGhsZW4pOwogCi0JCWlmICgodGNwLT50aF9mbGFn cyAmIFRIX1JTVCkgIT0gMCkgewotCQkJbV9mcmVlbShtKTsKLQkJCWFyZ3MtPm0gPSBOVUxMOwot CQkJcmV0dXJuOwotCQl9Ci0KLQkJdGkuaXA2ID0gKmlwNjsKLQkJdGkudGggPSAqdGNwOwotCQl0 aS50aC50aF9zZXEgPSBudG9obCh0aS50aC50aF9zZXEpOwotCQl0aS50aC50aF9hY2sgPSBudG9o bCh0aS50aC50aF9hY2spOwotCQl0aS5pcDYuaXA2X254dCA9IElQUFJPVE9fVENQOwotCi0JCWlm ICh0aS50aC50aF9mbGFncyAmIFRIX0FDSykgewotCQkJYWNrID0gMDsKLQkJCXNlcSA9IHRpLnRo LnRoX2FjazsKLQkJCWZsYWdzID0gVEhfUlNUOwotCQl9IGVsc2UgewotCQkJYWNrID0gdGkudGgu dGhfc2VxOwotCQkJaWYgKChtLT5tX2ZsYWdzICYgTV9QS1RIRFIpICE9IDApIHsKLQkJCQkvKgot CQkJCSAqIHRvdGFsIG5ldyBkYXRhIHRvIEFDSyBpczoKLQkJCQkgKiB0b3RhbCBwYWNrZXQgbGVu Z3RoLAotCQkJCSAqIG1pbnVzIHRoZSBoZWFkZXIgbGVuZ3RoLAotCQkJCSAqIG1pbnVzIHRoZSB0 Y3AgaGVhZGVyIGxlbmd0aC4KLQkJCQkgKi8KLQkJCQlhY2sgKz0gbS0+bV9wa3RoZHIubGVuIC0g aGxlbgotCQkJCQktICh0aS50aC50aF9vZmYgPDwgMik7Ci0JCQl9IGVsc2UgaWYgKGlwNi0+aXA2 X3BsZW4pIHsKLQkJCQlhY2sgKz0gbnRvaHMoaXA2LT5pcDZfcGxlbikgKyBzaXplb2YoKmlwNikg LQotCQkJCSAgICBobGVuIC0gKHRpLnRoLnRoX29mZiA8PCAyKTsKLQkJCX0gZWxzZSB7Ci0JCQkJ bV9mcmVlbShtKTsKLQkJCQlyZXR1cm47Ci0JCQl9Ci0JCQlpZiAodGNwLT50aF9mbGFncyAmIFRI X1NZTikKLQkJCQlhY2srKzsKLQkJCXNlcSA9IDA7Ci0JCQlmbGFncyA9IFRIX1JTVHxUSF9BQ0s7 CisJCWlmICgodGNwLT50aF9mbGFncyAmIFRIX1JTVCkgPT0gMCkgeworCQkJc3RydWN0IG1idWYg Km0wOworCQkJbTAgPSBzZW5kX3BrdChhcmdzLT5tLCAmKGFyZ3MtPmZfaWQpLAorCQkJCW50b2hs KHRjcC0+dGhfc2VxKSwgbnRvaGwodGNwLT50aF9hY2spLAorCQkJCXRjcC0+dGhfZmxhZ3MgfCBU SF9SU1QpOworCQkJaWYgKG0wICE9IE5VTEwpCisJCQkJaXA2X291dHB1dChtMCwgTlVMTCwgTlVM TCwgMCwgTlVMTCwgTlVMTCwgTlVMTCk7CiAJCX0KLQkJYmNvcHkoJnRpLCBpcDYsIHNpemVvZih0 aSkpOwotCQkvKgotCQkgKiBtIGlzIG9ubHkgdXNlZCB0byByZWN5Y2xlIHRoZSBtYnVmCi0JCSAq IFRoZSBkYXRhIGluIGl0IGlzIG5ldmVyIHJlYWQgc28gd2UgZG9uJ3QgbmVlZAotCQkgKiB0byBj b3JyZWN0IHRoZSBvZmZzZXRzIG9yIGFueXRoaW5nCi0JCSAqLwotCQl0Y3BfcmVzcG9uZChOVUxM LCBpcDYsIHRjcCwgbSwgYWNrLCBzZXEsIGZsYWdzKTsKKwkJbV9mcmVlbShtKTsKIAl9IGVsc2Ug aWYgKGNvZGUgIT0gSUNNUDZfVU5SRUFDSF9SU1QpIHsgLyogU2VuZCBhbiBJQ01QdjYgdW5yZWFj aC4gKi8KICNpZiAwCiAJCS8qCkBAIC0xNjA5LDEzICsxNTcxLDE2IEBACiAgICAgdV9pbnQzMl90 IGFjaywgaW50IGZsYWdzKQogewogCXN0cnVjdCBtYnVmICptOwotCXN0cnVjdCBpcCAqaXA7Ci0J c3RydWN0IHRjcGhkciAqdGNwOworCWludCBsZW4sIGRpcjsKKwlzdHJ1Y3QgaXAgKmggPSBOVUxM OwkJLyogc3R1cGlkIGNvbXBpbGVyICovCisjaWZkZWYgSU5FVDYKKwlzdHJ1Y3QgaXA2X2hkciAq aDYgPSBOVUxMOworI2VuZGlmCisJc3RydWN0IHRjcGhkciAqdGggPSBOVUxMOwogCiAJTUdFVEhE UihtLCBNX0RPTlRXQUlULCBNVF9EQVRBKTsKLQlpZiAobSA9PSAwKQorCWlmIChtID09IE5VTEwp CiAJCXJldHVybiAoTlVMTCk7Ci0JbS0+bV9wa3RoZHIucmN2aWYgPSAoc3RydWN0IGlmbmV0ICop MDsKIAogI2lmZGVmIE1BQwogCWlmIChyZXBseXRvICE9IE5VTEwpCkBAIC0xNjI2LDY3ICsxNTkx LDExOCBAQAogCSh2b2lkKXJlcGx5dG87CQkvKiBkb24ndCB3YXJuIGFib3V0IHVudXNlZCBhcmcg Ki8KICNlbmRpZgogCi0JbS0+bV9wa3RoZHIubGVuID0gbS0+bV9sZW4gPSBzaXplb2Yoc3RydWN0 IGlwKSArIHNpemVvZihzdHJ1Y3QgdGNwaGRyKTsKKwlzd2l0Y2ggKGlkLT5hZGRyX3R5cGUpIHsK KwljYXNlIDQ6CisJCWxlbiA9IHNpemVvZihzdHJ1Y3QgaXApICsgc2l6ZW9mKHN0cnVjdCB0Y3Bo ZHIpOworCQlicmVhazsKKyNpZmRlZiBJTkVUNgorCWNhc2UgNjoKKwkJbGVuID0gc2l6ZW9mKHN0 cnVjdCBpcDZfaGRyKSArIHNpemVvZihzdHJ1Y3QgdGNwaGRyKTsKKwkJYnJlYWs7CisjZW5kaWYK KwlkZWZhdWx0OgorCQkvKiBYWFg6IGxvZyBtZT8hPyAqLworCQltX2ZyZWVtKG0pOworCQlyZXR1 cm4gKE5VTEwpOworCX0KKwlkaXIgPSAoKGZsYWdzICYgKFRIX1NZTiB8IFRIX1JTVCkpID09IFRI X1NZTik7CisKIAltLT5tX2RhdGEgKz0gbWF4X2xpbmtoZHI7CisJbS0+bV9mbGFncyB8PSBNX1NL SVBfRklSRVdBTEw7CisJbS0+bV9wa3RoZHIubGVuID0gbS0+bV9sZW4gPSBsZW47CisJbS0+bV9w a3RoZHIucmN2aWYgPSBOVUxMOworCWJ6ZXJvKG0tPm1fZGF0YSwgbGVuKTsKKworCXN3aXRjaCAo aWQtPmFkZHJfdHlwZSkgeworCWNhc2UgNDoKKwkJaCA9IG10b2QobSwgc3RydWN0IGlwICopOwor CisJCS8qIHByZXBhcmUgZm9yIGNoZWNrc3VtICovCisJCWgtPmlwX3AgPSBJUFBST1RPX1RDUDsK KwkJaC0+aXBfbGVuID0gaHRvbnMoc2l6ZW9mKHN0cnVjdCB0Y3BoZHIpKTsKKwkJaWYgKGRpcikg eworCQkJaC0+aXBfc3JjLnNfYWRkciA9IGh0b25sKGlkLT5zcmNfaXApOworCQkJaC0+aXBfZHN0 LnNfYWRkciA9IGh0b25sKGlkLT5kc3RfaXApOworCQl9IGVsc2UgeworCQkJaC0+aXBfc3JjLnNf YWRkciA9IGh0b25sKGlkLT5kc3RfaXApOworCQkJaC0+aXBfZHN0LnNfYWRkciA9IGh0b25sKGlk LT5zcmNfaXApOworCQl9CiAKLQlpcCA9IG10b2QobSwgc3RydWN0IGlwICopOwotCWJ6ZXJvKGlw LCBtLT5tX2xlbik7Ci0JdGNwID0gKHN0cnVjdCB0Y3BoZHIgKikoaXAgKyAxKTsgLyogbm8gSVAg b3B0aW9ucyAqLwotCWlwLT5pcF9wID0gSVBQUk9UT19UQ1A7Ci0JdGNwLT50aF9vZmYgPSA1Owot CS8qCi0JICogQXNzdW1lIHdlIGFyZSBzZW5kaW5nIGEgUlNUIChvciBhIGtlZXBhbGl2ZSBpbiB0 aGUgcmV2ZXJzZQotCSAqIGRpcmVjdGlvbiksIHN3YXAgc3JjIGFuZCBkZXN0aW5hdGlvbiBhZGRy ZXNzZXMgYW5kIHBvcnRzLgotCSAqLwotCWlwLT5pcF9zcmMuc19hZGRyID0gaHRvbmwoaWQtPmRz dF9pcCk7Ci0JaXAtPmlwX2RzdC5zX2FkZHIgPSBodG9ubChpZC0+c3JjX2lwKTsKLQl0Y3AtPnRo X3Nwb3J0ID0gaHRvbnMoaWQtPmRzdF9wb3J0KTsKLQl0Y3AtPnRoX2Rwb3J0ID0gaHRvbnMoaWQt PnNyY19wb3J0KTsKLQlpZiAoZmxhZ3MgJiBUSF9SU1QpIHsJLyogd2UgYXJlIHNlbmRpbmcgYSBS U1QgKi8KKwkJdGggPSAoc3RydWN0IHRjcGhkciAqKShoICsgMSk7CisJCWJyZWFrOworI2lmZGVm IElORVQ2CisJY2FzZSA2OgorCQloNiA9IG10b2QobSwgc3RydWN0IGlwNl9oZHIgKik7CisKKwkJ LyogcHJlcGFyZSBmb3IgY2hlY2tzdW0gKi8KKwkJaDYtPmlwNl9ueHQgPSBJUFBST1RPX1RDUDsK KwkJaDYtPmlwNl9wbGVuID0gaHRvbnMoc2l6ZW9mKHN0cnVjdCB0Y3BoZHIpKTsKKwkJaWYgKGRp cikgeworCQkJaDYtPmlwNl9zcmMgPSBpZC0+c3JjX2lwNjsKKwkJCWg2LT5pcDZfZHN0ID0gaWQt PmRzdF9pcDY7CisJCX0gZWxzZSB7CisJCQloNi0+aXA2X3NyYyA9IGlkLT5kc3RfaXA2OworCQkJ aDYtPmlwNl9kc3QgPSBpZC0+c3JjX2lwNjsKKwkJfQorCisJCXRoID0gKHN0cnVjdCB0Y3BoZHIg KikoaDYgKyAxKTsKKwkJYnJlYWs7CisjZW5kaWYKKwl9CisKKwlpZiAoZGlyKSB7CisJCXRoLT50 aF9zcG9ydCA9IGh0b25zKGlkLT5zcmNfcG9ydCk7CisJCXRoLT50aF9kcG9ydCA9IGh0b25zKGlk LT5kc3RfcG9ydCk7CisJfSBlbHNlIHsKKwkJdGgtPnRoX3Nwb3J0ID0gaHRvbnMoaWQtPmRzdF9w b3J0KTsKKwkJdGgtPnRoX2Rwb3J0ID0gaHRvbnMoaWQtPnNyY19wb3J0KTsKKwl9CisJdGgtPnRo X29mZiA9IHNpemVvZihzdHJ1Y3QgdGNwaGRyKSA+PiAyOworCisJaWYgKGZsYWdzICYgVEhfUlNU KSB7CiAJCWlmIChmbGFncyAmIFRIX0FDSykgewotCQkJdGNwLT50aF9zZXEgPSBodG9ubChhY2sp OwotCQkJdGNwLT50aF9hY2sgPSBodG9ubCgwKTsKLQkJCXRjcC0+dGhfZmxhZ3MgPSBUSF9SU1Q7 CisJCQl0aC0+dGhfc2VxID0gaHRvbmwoYWNrKTsKKwkJCXRoLT50aF9mbGFncyA9IFRIX1JTVDsK IAkJfSBlbHNlIHsKIAkJCWlmIChmbGFncyAmIFRIX1NZTikKIAkJCQlzZXErKzsKLQkJCXRjcC0+ dGhfc2VxID0gaHRvbmwoMCk7Ci0JCQl0Y3AtPnRoX2FjayA9IGh0b25sKHNlcSk7Ci0JCQl0Y3At PnRoX2ZsYWdzID0gVEhfUlNUIHwgVEhfQUNLOworCQkJdGgtPnRoX2FjayA9IGh0b25sKHNlcSk7 CisJCQl0aC0+dGhfZmxhZ3MgPSBUSF9SU1QgfCBUSF9BQ0s7CiAJCX0KIAl9IGVsc2UgewogCQkv KgotCQkgKiBXZSBhcmUgc2VuZGluZyBhIGtlZXBhbGl2ZS4gZmxhZ3MgJiBUSF9TWU4gZGV0ZXJt aW5lcwotCQkgKiB0aGUgZGlyZWN0aW9uLCBmb3J3YXJkIGlmIHNldCwgcmV2ZXJzZSBpZiBjbGVh ci4KLQkJICogTk9URTogc2VxIGFuZCBhY2sgYXJlIGFsd2F5cyBhc3N1bWVkIHRvIGJlIGNvcnJl Y3QKLQkJICogYXMgc2V0IGJ5IHRoZSBjYWxsZXIuIFRoaXMgbWF5IGJlIGNvbmZ1c2luZy4uLgor CQkgKiBLZWVwYWxpdmUgLSB1c2UgY2FsbGVyIHByb3ZpZGVkIHNlcXVlbmNlIG51bWJlcnMKIAkJ ICovCi0JCWlmIChmbGFncyAmIFRIX1NZTikgewotCQkJLyoKLQkJCSAqIHdlIGhhdmUgdG8gcmV3 cml0ZSB0aGUgY29ycmVjdCBhZGRyZXNzZXMhCi0JCQkgKi8KLQkJCWlwLT5pcF9kc3Quc19hZGRy ID0gaHRvbmwoaWQtPmRzdF9pcCk7Ci0JCQlpcC0+aXBfc3JjLnNfYWRkciA9IGh0b25sKGlkLT5z cmNfaXApOwotCQkJdGNwLT50aF9kcG9ydCA9IGh0b25zKGlkLT5kc3RfcG9ydCk7Ci0JCQl0Y3At PnRoX3Nwb3J0ID0gaHRvbnMoaWQtPnNyY19wb3J0KTsKLQkJfQotCQl0Y3AtPnRoX3NlcSA9IGh0 b25sKHNlcSk7Ci0JCXRjcC0+dGhfYWNrID0gaHRvbmwoYWNrKTsKLQkJdGNwLT50aF9mbGFncyA9 IFRIX0FDSzsKKwkJdGgtPnRoX3NlcSA9IGh0b25sKHNlcSk7CisJCXRoLT50aF9hY2sgPSBodG9u bChhY2spOworCQl0aC0+dGhfZmxhZ3MgPSBUSF9BQ0s7CisJfQorCisJc3dpdGNoIChpZC0+YWRk cl90eXBlKSB7CisJY2FzZSA0OgorCQl0aC0+dGhfc3VtID0gaW5fY2tzdW0obSwgbGVuKTsKKwor CQkvKiBmaW5pc2ggdGhlIGlwIGhlYWRlciAqLworCQloLT5pcF92ID0gNDsKKwkJaC0+aXBfaGwg PSBzaXplb2YoKmgpID4+IDI7CisJCWgtPmlwX3RvcyA9IElQVE9TX0xPV0RFTEFZOworCQloLT5p cF9vZmYgPSAwOworCQloLT5pcF9sZW4gPSBsZW47CisJCWgtPmlwX3R0bCA9IGlwX2RlZnR0bDsK KwkJaC0+aXBfc3VtID0gMDsKKwkJYnJlYWs7CisjaWZkZWYgSU5FVDYKKwljYXNlIDY6CisJCXRo LT50aF9zdW0gPSBpbjZfY2tzdW0obSwgSVBQUk9UT19UQ1AsIHNpemVvZigqaDYpLAorCQkgICAg c2l6ZW9mKHN0cnVjdCB0Y3BoZHIpKTsKKworCQkvKiBmaW5pc2ggdGhlIGlwNiBoZWFkZXIgKi8K KwkJaDYtPmlwNl92ZmMgfD0gSVBWNl9WRVJTSU9OOworCQloNi0+aXA2X2hsaW0gPSBJUFY2X0RF RkhMSU07CisJCWJyZWFrOworI2VuZGlmCiAJfQotCS8qCi0JICogc2V0IGlwX2xlbiB0byB0aGUg cGF5bG9hZCBzaXplIHNvIHdlIGNhbiBjb21wdXRlCi0JICogdGhlIHRjcCBjaGVja3N1bSBvbiB0 aGUgcHNldWRvaGVhZGVyCi0JICogWFhYIGNoZWNrIHRoaXMsIGNvdWxkIHNhdmUgYSBjb3VwbGUg b2Ygd29yZHMgPwotCSAqLwotCWlwLT5pcF9sZW4gPSBodG9ucyhzaXplb2Yoc3RydWN0IHRjcGhk cikpOwotCXRjcC0+dGhfc3VtID0gaW5fY2tzdW0obSwgbS0+bV9wa3RoZHIubGVuKTsKLQkvKgot CSAqIG5vdyBmaWxsIGZpZWxkcyBsZWZ0IG91dCBlYXJsaWVyCi0JICovCi0JaXAtPmlwX3R0bCA9 IGlwX2RlZnR0bDsKLQlpcC0+aXBfbGVuID0gbS0+bV9wa3RoZHIubGVuOwotCW0tPm1fZmxhZ3Mg fD0gTV9TS0lQX0ZJUkVXQUxMOworCiAJcmV0dXJuIChtKTsKIH0KIApAQCAtNDg2MCw2ICs0ODc2 LDkgQEAKIGlwZndfdGljayh2b2lkICogX191bnVzZWQgdW51c2VkKQogewogCXN0cnVjdCBtYnVm ICptMCwgKm0sICptbmV4dCwgKiptdGFpbHA7CisjaWZkZWYgSU5FVDYKKwlzdHJ1Y3QgbWJ1ZiAq bTYsICoqbTZfdGFpbHA7CisjZW5kaWYKIAlpbnQgaTsKIAlpcGZ3X2R5bl9ydWxlICpxOwogCkBA IC00ODc0LDYgKzQ4OTMsMTAgQEAKIAkgKi8KIAltMCA9IE5VTEw7CiAJbXRhaWxwID0gJm0wOwor I2lmZGVmIElORVQ2CisJbTYgPSBOVUxMOworCW02X3RhaWxwID0gJm02OworI2VuZGlmCiAJSVBG V19EWU5fTE9DSygpOwogCWZvciAoaSA9IDAgOyBpIDwgY3Vycl9keW5fYnVja2V0cyA7IGkrKykg ewogCQlmb3IgKHEgPSBpcGZ3X2R5bl92W2ldIDsgcSA7IHEgPSBxLT5uZXh0ICkgewpAQCAtNDg4 OSwxNCArNDkxMiwzNyBAQAogCQkJaWYgKFRJTUVfTEVRKHEtPmV4cGlyZSwgdGltZV91cHRpbWUp KQogCQkJCWNvbnRpbnVlOwkvKiB0b28gbGF0ZSwgcnVsZSBleHBpcmVkICovCiAKLQkJCSptdGFp bHAgPSBzZW5kX3BrdChOVUxMLCAmKHEtPmlkKSwgcS0+YWNrX3JldiAtIDEsCisJCQltID0gc2Vu ZF9wa3QoTlVMTCwgJihxLT5pZCksIHEtPmFja19yZXYgLSAxLAogCQkJCXEtPmFja19md2QsIFRI X1NZTik7Ci0JCQlpZiAoKm10YWlscCAhPSBOVUxMKQotCQkJCW10YWlscCA9ICYoKm10YWlscCkt Pm1fbmV4dHBrdDsKLQkJCSptdGFpbHAgPSBzZW5kX3BrdChOVUxMLCAmKHEtPmlkKSwgcS0+YWNr X2Z3ZCAtIDEsCisJCQltbmV4dCA9IHNlbmRfcGt0KE5VTEwsICYocS0+aWQpLCBxLT5hY2tfZndk IC0gMSwKIAkJCQlxLT5hY2tfcmV2LCAwKTsKLQkJCWlmICgqbXRhaWxwICE9IE5VTEwpCi0JCQkJ bXRhaWxwID0gJigqbXRhaWxwKS0+bV9uZXh0cGt0OworCisJCQlzd2l0Y2ggKHEtPmlkLmFkZHJf dHlwZSkgeworCQkJY2FzZSA0OgorCQkJCWlmIChtICE9IE5VTEwpIHsKKwkJCQkJKm10YWlscCA9 IG07CisJCQkJCW10YWlscCA9ICYoKm10YWlscCktPm1fbmV4dHBrdDsKKwkJCQl9CisJCQkJaWYg KG1uZXh0ICE9IE5VTEwpIHsKKwkJCQkJKm10YWlscCA9IG1uZXh0OworCQkJCQltdGFpbHAgPSAm KCptdGFpbHApLT5tX25leHRwa3Q7CisJCQkJfQorCQkJCWJyZWFrOworI2lmZGVmIElORVQ2CisJ CQljYXNlIDY6CisJCQkJaWYgKG0gIT0gTlVMTCkgeworCQkJCQkqbTZfdGFpbHAgPSBtOworCQkJ CQltNl90YWlscCA9ICYoKm02X3RhaWxwKS0+bV9uZXh0cGt0OworCQkJCX0KKwkJCQlpZiAobW5l eHQgIT0gTlVMTCkgeworCQkJCQkqbTZfdGFpbHAgPSBtbmV4dDsKKwkJCQkJbTZfdGFpbHAgPSAm KCptNl90YWlscCktPm1fbmV4dHBrdDsKKwkJCQl9CisJCQkJYnJlYWs7CisjZW5kaWYKKwkJCX0K KworCQkJbSA9IG1uZXh0ID0gTlVMTDsKIAkJfQogCX0KIAlJUEZXX0RZTl9VTkxPQ0soKTsKQEAg LTQ5MDUsNiArNDk1MSwxMyBAQAogCQltLT5tX25leHRwa3QgPSBOVUxMOwogCQlpcF9vdXRwdXQo bSwgTlVMTCwgTlVMTCwgMCwgTlVMTCwgTlVMTCk7CiAJfQorI2lmZGVmIElORVQ2CisJZm9yICht ID0gbW5leHQgPSBtNjsgbSAhPSBOVUxMOyBtID0gbW5leHQpIHsKKwkJbW5leHQgPSBtLT5tX25l eHRwa3Q7CisJCW0tPm1fbmV4dHBrdCA9IE5VTEw7CisJCWlwNl9vdXRwdXQobSwgTlVMTCwgTlVM TCwgMCwgTlVMTCwgTlVMTCwgTlVMTCk7CisJfQorI2VuZGlmCiBkb25lOgogCWNhbGxvdXRfcmVz ZXQoJmlwZndfdGltZW91dCwgZHluX2tlZXBhbGl2ZV9wZXJpb2QqaHosIGlwZndfdGljaywgTlVM TCk7CiB9CgotLUJvdW5kYXJ5LTAwPV9vd09JSFFXSmxoOEwxNWgtLQo= ------=_20080519221520_63844 Content-Type: application/octet-stream; name="ipfw_v6send_70R.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw_v6send_70R.diff" LS0tIGlwX2Z3Mi5jLm9yaWcJMjAwOC0wMS0yOCAxNzo0NDozMC4wMDAwMDAwMDAgKzAwMDAKKysr IGlwX2Z3Mi5jCTIwMDgtMDUtMTkgMjE6NDU6MjcuMDAwMDAwMDAwICswMDAwCkBAIC0xMDEsNiAr MTAxLDcgQEAKICNpbmNsdWRlIDxuZXRpbmV0L2lwNi5oPgogI2luY2x1ZGUgPG5ldGluZXQvaWNt cDYuaD4KICNpZmRlZiBJTkVUNgorI2luY2x1ZGUgPG5ldGluZXQ2L2lwNl92YXIuaD4KICNpbmNs dWRlIDxuZXRpbmV0Ni9zY29wZTZfdmFyLmg+CiAjZW5kaWYKIApAQCAtMjQ0LDYgKzI0NSw5IEBA CiAjZGVmaW5lCUlQRldfRFlOX1VOTE9DSygpCW10eF91bmxvY2soJmlwZndfZHluX210eCkKICNk ZWZpbmUJSVBGV19EWU5fTE9DS19BU1NFUlQoKQltdHhfYXNzZXJ0KCZpcGZ3X2R5bl9tdHgsIE1B X09XTkVEKQogCitzdGF0aWMgc3RydWN0IG1idWYgKnNlbmRfcGt0KHN0cnVjdCBtYnVmICosIHN0 cnVjdCBpcGZ3X2Zsb3dfaWQgKiwKKyAgICB1X2ludDMyX3QsIHVfaW50MzJfdCwgaW50KTsKKwog LyoKICAqIFRpbWVvdXRzIGZvciB2YXJpb3VzIGV2ZW50cyBpbiBoYW5kaW5nIGR5bmFtaWMgcnVs ZXMuCiAgKi8KQEAgLTY3NCw2NyArNjc4LDI1IEBACiB9CiAKIHN0YXRpYyB2b2lkCi1zZW5kX3Jl amVjdDYoc3RydWN0IGlwX2Z3X2FyZ3MgKmFyZ3MsIGludCBjb2RlLCB1X2ludCBobGVuLCBzdHJ1 Y3QgaXA2X2hkciAqaXA2KQorc2VuZF9yZWplY3Q2KHN0cnVjdCBpcF9md19hcmdzICphcmdzLCBp bnQgY29kZSwgdV9pbnQgaGxlbiwKKyAgICBzdHJ1Y3QgaXA2X2hkciAqaXA2KQogewogCXN0cnVj dCBtYnVmICptOwogCiAJbSA9IGFyZ3MtPm07CiAJaWYgKGNvZGUgPT0gSUNNUDZfVU5SRUFDSF9S U1QgJiYgYXJncy0+Zl9pZC5wcm90byA9PSBJUFBST1RPX1RDUCkgewogCQlzdHJ1Y3QgdGNwaGRy ICp0Y3A7Ci0JCXRjcF9zZXEgYWNrLCBzZXE7Ci0JCWludCBmbGFnczsKLQkJc3RydWN0IHsKLQkJ CXN0cnVjdCBpcDZfaGRyIGlwNjsKLQkJCXN0cnVjdCB0Y3BoZHIgdGg7Ci0JCX0gdGk7CiAJCXRj cCA9IChzdHJ1Y3QgdGNwaGRyICopKChjaGFyICopaXA2ICsgaGxlbik7CiAKLQkJaWYgKCh0Y3At PnRoX2ZsYWdzICYgVEhfUlNUKSAhPSAwKSB7Ci0JCQltX2ZyZWVtKG0pOwotCQkJYXJncy0+bSA9 IE5VTEw7Ci0JCQlyZXR1cm47Ci0JCX0KLQotCQl0aS5pcDYgPSAqaXA2OwotCQl0aS50aCA9ICp0 Y3A7Ci0JCXRpLnRoLnRoX3NlcSA9IG50b2hsKHRpLnRoLnRoX3NlcSk7Ci0JCXRpLnRoLnRoX2Fj ayA9IG50b2hsKHRpLnRoLnRoX2Fjayk7Ci0JCXRpLmlwNi5pcDZfbnh0ID0gSVBQUk9UT19UQ1A7 Ci0KLQkJaWYgKHRpLnRoLnRoX2ZsYWdzICYgVEhfQUNLKSB7Ci0JCQlhY2sgPSAwOwotCQkJc2Vx ID0gdGkudGgudGhfYWNrOwotCQkJZmxhZ3MgPSBUSF9SU1Q7Ci0JCX0gZWxzZSB7Ci0JCQlhY2sg PSB0aS50aC50aF9zZXE7Ci0JCQlpZiAoKG0tPm1fZmxhZ3MgJiBNX1BLVEhEUikgIT0gMCkgewot CQkJCS8qCi0JCQkJICogdG90YWwgbmV3IGRhdGEgdG8gQUNLIGlzOgotCQkJCSAqIHRvdGFsIHBh Y2tldCBsZW5ndGgsCi0JCQkJICogbWludXMgdGhlIGhlYWRlciBsZW5ndGgsCi0JCQkJICogbWlu dXMgdGhlIHRjcCBoZWFkZXIgbGVuZ3RoLgotCQkJCSAqLwotCQkJCWFjayArPSBtLT5tX3BrdGhk ci5sZW4gLSBobGVuCi0JCQkJCS0gKHRpLnRoLnRoX29mZiA8PCAyKTsKLQkJCX0gZWxzZSBpZiAo aXA2LT5pcDZfcGxlbikgewotCQkJCWFjayArPSBudG9ocyhpcDYtPmlwNl9wbGVuKSArIHNpemVv ZigqaXA2KSAtCi0JCQkJICAgIGhsZW4gLSAodGkudGgudGhfb2ZmIDw8IDIpOwotCQkJfSBlbHNl IHsKLQkJCQltX2ZyZWVtKG0pOwotCQkJCXJldHVybjsKLQkJCX0KLQkJCWlmICh0Y3AtPnRoX2Zs YWdzICYgVEhfU1lOKQotCQkJCWFjaysrOwotCQkJc2VxID0gMDsKLQkJCWZsYWdzID0gVEhfUlNU fFRIX0FDSzsKKwkJaWYgKCh0Y3AtPnRoX2ZsYWdzICYgVEhfUlNUKSA9PSAwKSB7CisJCQlzdHJ1 Y3QgbWJ1ZiAqbTA7CisJCQltMCA9IHNlbmRfcGt0KGFyZ3MtPm0sICYoYXJncy0+Zl9pZCksCisJ CQkJbnRvaGwodGNwLT50aF9zZXEpLCBudG9obCh0Y3AtPnRoX2FjayksCisJCQkJdGNwLT50aF9m bGFncyB8IFRIX1JTVCk7CisJCQlpZiAobTAgIT0gTlVMTCkKKwkJCQlpcDZfb3V0cHV0KG0wLCBO VUxMLCBOVUxMLCAwLCBOVUxMLCBOVUxMLCBOVUxMKTsKIAkJfQotCQliY29weSgmdGksIGlwNiwg c2l6ZW9mKHRpKSk7Ci0JCS8qCi0JCSAqIG0gaXMgb25seSB1c2VkIHRvIHJlY3ljbGUgdGhlIG1i dWYKLQkJICogVGhlIGRhdGEgaW4gaXQgaXMgbmV2ZXIgcmVhZCBzbyB3ZSBkb24ndCBuZWVkCi0J CSAqIHRvIGNvcnJlY3QgdGhlIG9mZnNldHMgb3IgYW55dGhpbmcKLQkJICovCi0JCXRjcF9yZXNw b25kKE5VTEwsIGlwNiwgdGNwLCBtLCBhY2ssIHNlcSwgZmxhZ3MpOworCQltX2ZyZWVtKG0pOwog CX0gZWxzZSBpZiAoY29kZSAhPSBJQ01QNl9VTlJFQUNIX1JTVCkgeyAvKiBTZW5kIGFuIElDTVB2 NiB1bnJlYWNoLiAqLwogI2lmIDAKIAkJLyoKQEAgLTE2MTIsMTMgKzE1NzQsMTYgQEAKICAgICB1 X2ludDMyX3QgYWNrLCBpbnQgZmxhZ3MpCiB7CiAJc3RydWN0IG1idWYgKm07Ci0Jc3RydWN0IGlw ICppcDsKLQlzdHJ1Y3QgdGNwaGRyICp0Y3A7CisJaW50IGxlbiwgZGlyOworCXN0cnVjdCBpcCAq aCA9IE5VTEw7CQkvKiBzdHVwaWQgY29tcGlsZXIgKi8KKyNpZmRlZiBJTkVUNgorCXN0cnVjdCBp cDZfaGRyICpoNiA9IE5VTEw7CisjZW5kaWYKKwlzdHJ1Y3QgdGNwaGRyICp0aCA9IE5VTEw7CiAK IAlNR0VUSERSKG0sIE1fRE9OVFdBSVQsIE1UX0RBVEEpOwotCWlmIChtID09IDApCisJaWYgKG0g PT0gTlVMTCkKIAkJcmV0dXJuIChOVUxMKTsKLQltLT5tX3BrdGhkci5yY3ZpZiA9IChzdHJ1Y3Qg aWZuZXQgKikwOwogCiAjaWZkZWYgTUFDCiAJaWYgKHJlcGx5dG8gIT0gTlVMTCkKQEAgLTE2Mjks NjcgKzE1OTQsMTE4IEBACiAJKHZvaWQpcmVwbHl0bzsJCS8qIGRvbid0IHdhcm4gYWJvdXQgdW51 c2VkIGFyZyAqLwogI2VuZGlmCiAKLQltLT5tX3BrdGhkci5sZW4gPSBtLT5tX2xlbiA9IHNpemVv ZihzdHJ1Y3QgaXApICsgc2l6ZW9mKHN0cnVjdCB0Y3BoZHIpOworCXN3aXRjaCAoaWQtPmFkZHJf dHlwZSkgeworCWNhc2UgNDoKKwkJbGVuID0gc2l6ZW9mKHN0cnVjdCBpcCkgKyBzaXplb2Yoc3Ry dWN0IHRjcGhkcik7CisJCWJyZWFrOworI2lmZGVmIElORVQ2CisJY2FzZSA2OgorCQlsZW4gPSBz aXplb2Yoc3RydWN0IGlwNl9oZHIpICsgc2l6ZW9mKHN0cnVjdCB0Y3BoZHIpOworCQlicmVhazsK KyNlbmRpZgorCWRlZmF1bHQ6CisJCS8qIFhYWDogbG9nIG1lPyE/ICovCisJCW1fZnJlZW0obSk7 CisJCXJldHVybiAoTlVMTCk7CisJfQorCWRpciA9ICgoZmxhZ3MgJiAoVEhfU1lOIHwgVEhfUlNU KSkgPT0gVEhfU1lOKTsKKwogCW0tPm1fZGF0YSArPSBtYXhfbGlua2hkcjsKKwltLT5tX2ZsYWdz IHw9IE1fU0tJUF9GSVJFV0FMTDsKKwltLT5tX3BrdGhkci5sZW4gPSBtLT5tX2xlbiA9IGxlbjsK KwltLT5tX3BrdGhkci5yY3ZpZiA9IE5VTEw7CisJYnplcm8obS0+bV9kYXRhLCBsZW4pOworCisJ c3dpdGNoIChpZC0+YWRkcl90eXBlKSB7CisJY2FzZSA0OgorCQloID0gbXRvZChtLCBzdHJ1Y3Qg aXAgKik7CisKKwkJLyogcHJlcGFyZSBmb3IgY2hlY2tzdW0gKi8KKwkJaC0+aXBfcCA9IElQUFJP VE9fVENQOworCQloLT5pcF9sZW4gPSBodG9ucyhzaXplb2Yoc3RydWN0IHRjcGhkcikpOworCQlp ZiAoZGlyKSB7CisJCQloLT5pcF9zcmMuc19hZGRyID0gaHRvbmwoaWQtPnNyY19pcCk7CisJCQlo LT5pcF9kc3Quc19hZGRyID0gaHRvbmwoaWQtPmRzdF9pcCk7CisJCX0gZWxzZSB7CisJCQloLT5p cF9zcmMuc19hZGRyID0gaHRvbmwoaWQtPmRzdF9pcCk7CisJCQloLT5pcF9kc3Quc19hZGRyID0g aHRvbmwoaWQtPnNyY19pcCk7CisJCX0KIAotCWlwID0gbXRvZChtLCBzdHJ1Y3QgaXAgKik7Ci0J Ynplcm8oaXAsIG0tPm1fbGVuKTsKLQl0Y3AgPSAoc3RydWN0IHRjcGhkciAqKShpcCArIDEpOyAv KiBubyBJUCBvcHRpb25zICovCi0JaXAtPmlwX3AgPSBJUFBST1RPX1RDUDsKLQl0Y3AtPnRoX29m ZiA9IDU7Ci0JLyoKLQkgKiBBc3N1bWUgd2UgYXJlIHNlbmRpbmcgYSBSU1QgKG9yIGEga2VlcGFs aXZlIGluIHRoZSByZXZlcnNlCi0JICogZGlyZWN0aW9uKSwgc3dhcCBzcmMgYW5kIGRlc3RpbmF0 aW9uIGFkZHJlc3NlcyBhbmQgcG9ydHMuCi0JICovCi0JaXAtPmlwX3NyYy5zX2FkZHIgPSBodG9u bChpZC0+ZHN0X2lwKTsKLQlpcC0+aXBfZHN0LnNfYWRkciA9IGh0b25sKGlkLT5zcmNfaXApOwot CXRjcC0+dGhfc3BvcnQgPSBodG9ucyhpZC0+ZHN0X3BvcnQpOwotCXRjcC0+dGhfZHBvcnQgPSBo dG9ucyhpZC0+c3JjX3BvcnQpOwotCWlmIChmbGFncyAmIFRIX1JTVCkgewkvKiB3ZSBhcmUgc2Vu ZGluZyBhIFJTVCAqLworCQl0aCA9IChzdHJ1Y3QgdGNwaGRyICopKGggKyAxKTsKKwkJYnJlYWs7 CisjaWZkZWYgSU5FVDYKKwljYXNlIDY6CisJCWg2ID0gbXRvZChtLCBzdHJ1Y3QgaXA2X2hkciAq KTsKKworCQkvKiBwcmVwYXJlIGZvciBjaGVja3N1bSAqLworCQloNi0+aXA2X254dCA9IElQUFJP VE9fVENQOworCQloNi0+aXA2X3BsZW4gPSBodG9ucyhzaXplb2Yoc3RydWN0IHRjcGhkcikpOwor CQlpZiAoZGlyKSB7CisJCQloNi0+aXA2X3NyYyA9IGlkLT5zcmNfaXA2OworCQkJaDYtPmlwNl9k c3QgPSBpZC0+ZHN0X2lwNjsKKwkJfSBlbHNlIHsKKwkJCWg2LT5pcDZfc3JjID0gaWQtPmRzdF9p cDY7CisJCQloNi0+aXA2X2RzdCA9IGlkLT5zcmNfaXA2OworCQl9CisKKwkJdGggPSAoc3RydWN0 IHRjcGhkciAqKShoNiArIDEpOworCQlicmVhazsKKyNlbmRpZgorCX0KKworCWlmIChkaXIpIHsK KwkJdGgtPnRoX3Nwb3J0ID0gaHRvbnMoaWQtPnNyY19wb3J0KTsKKwkJdGgtPnRoX2Rwb3J0ID0g aHRvbnMoaWQtPmRzdF9wb3J0KTsKKwl9IGVsc2UgeworCQl0aC0+dGhfc3BvcnQgPSBodG9ucyhp ZC0+ZHN0X3BvcnQpOworCQl0aC0+dGhfZHBvcnQgPSBodG9ucyhpZC0+c3JjX3BvcnQpOworCX0K Kwl0aC0+dGhfb2ZmID0gc2l6ZW9mKHN0cnVjdCB0Y3BoZHIpID4+IDI7CisKKwlpZiAoZmxhZ3Mg JiBUSF9SU1QpIHsKIAkJaWYgKGZsYWdzICYgVEhfQUNLKSB7Ci0JCQl0Y3AtPnRoX3NlcSA9IGh0 b25sKGFjayk7Ci0JCQl0Y3AtPnRoX2FjayA9IGh0b25sKDApOwotCQkJdGNwLT50aF9mbGFncyA9 IFRIX1JTVDsKKwkJCXRoLT50aF9zZXEgPSBodG9ubChhY2spOworCQkJdGgtPnRoX2ZsYWdzID0g VEhfUlNUOwogCQl9IGVsc2UgewogCQkJaWYgKGZsYWdzICYgVEhfU1lOKQogCQkJCXNlcSsrOwot CQkJdGNwLT50aF9zZXEgPSBodG9ubCgwKTsKLQkJCXRjcC0+dGhfYWNrID0gaHRvbmwoc2VxKTsK LQkJCXRjcC0+dGhfZmxhZ3MgPSBUSF9SU1QgfCBUSF9BQ0s7CisJCQl0aC0+dGhfYWNrID0gaHRv bmwoc2VxKTsKKwkJCXRoLT50aF9mbGFncyA9IFRIX1JTVCB8IFRIX0FDSzsKIAkJfQogCX0gZWxz ZSB7CiAJCS8qCi0JCSAqIFdlIGFyZSBzZW5kaW5nIGEga2VlcGFsaXZlLiBmbGFncyAmIFRIX1NZ TiBkZXRlcm1pbmVzCi0JCSAqIHRoZSBkaXJlY3Rpb24sIGZvcndhcmQgaWYgc2V0LCByZXZlcnNl IGlmIGNsZWFyLgotCQkgKiBOT1RFOiBzZXEgYW5kIGFjayBhcmUgYWx3YXlzIGFzc3VtZWQgdG8g YmUgY29ycmVjdAotCQkgKiBhcyBzZXQgYnkgdGhlIGNhbGxlci4gVGhpcyBtYXkgYmUgY29uZnVz aW5nLi4uCisJCSAqIEtlZXBhbGl2ZSAtIHVzZSBjYWxsZXIgcHJvdmlkZWQgc2VxdWVuY2UgbnVt YmVycwogCQkgKi8KLQkJaWYgKGZsYWdzICYgVEhfU1lOKSB7Ci0JCQkvKgotCQkJICogd2UgaGF2 ZSB0byByZXdyaXRlIHRoZSBjb3JyZWN0IGFkZHJlc3NlcyEKLQkJCSAqLwotCQkJaXAtPmlwX2Rz dC5zX2FkZHIgPSBodG9ubChpZC0+ZHN0X2lwKTsKLQkJCWlwLT5pcF9zcmMuc19hZGRyID0gaHRv bmwoaWQtPnNyY19pcCk7Ci0JCQl0Y3AtPnRoX2Rwb3J0ID0gaHRvbnMoaWQtPmRzdF9wb3J0KTsK LQkJCXRjcC0+dGhfc3BvcnQgPSBodG9ucyhpZC0+c3JjX3BvcnQpOwotCQl9Ci0JCXRjcC0+dGhf c2VxID0gaHRvbmwoc2VxKTsKLQkJdGNwLT50aF9hY2sgPSBodG9ubChhY2spOwotCQl0Y3AtPnRo X2ZsYWdzID0gVEhfQUNLOworCQl0aC0+dGhfc2VxID0gaHRvbmwoc2VxKTsKKwkJdGgtPnRoX2Fj ayA9IGh0b25sKGFjayk7CisJCXRoLT50aF9mbGFncyA9IFRIX0FDSzsKKwl9CisKKwlzd2l0Y2gg KGlkLT5hZGRyX3R5cGUpIHsKKwljYXNlIDQ6CisJCXRoLT50aF9zdW0gPSBpbl9ja3N1bShtLCBs ZW4pOworCisJCS8qIGZpbmlzaCB0aGUgaXAgaGVhZGVyICovCisJCWgtPmlwX3YgPSA0OworCQlo LT5pcF9obCA9IHNpemVvZigqaCkgPj4gMjsKKwkJaC0+aXBfdG9zID0gSVBUT1NfTE9XREVMQVk7 CisJCWgtPmlwX29mZiA9IDA7CisJCWgtPmlwX2xlbiA9IGxlbjsKKwkJaC0+aXBfdHRsID0gaXBf ZGVmdHRsOworCQloLT5pcF9zdW0gPSAwOworCQlicmVhazsKKyNpZmRlZiBJTkVUNgorCWNhc2Ug NjoKKwkJdGgtPnRoX3N1bSA9IGluNl9ja3N1bShtLCBJUFBST1RPX1RDUCwgc2l6ZW9mKCpoNiks CisJCSAgICBzaXplb2Yoc3RydWN0IHRjcGhkcikpOworCisJCS8qIGZpbmlzaCB0aGUgaXA2IGhl YWRlciAqLworCQloNi0+aXA2X3ZmYyB8PSBJUFY2X1ZFUlNJT047CisJCWg2LT5pcDZfaGxpbSA9 IElQVjZfREVGSExJTTsKKwkJYnJlYWs7CisjZW5kaWYKIAl9Ci0JLyoKLQkgKiBzZXQgaXBfbGVu IHRvIHRoZSBwYXlsb2FkIHNpemUgc28gd2UgY2FuIGNvbXB1dGUKLQkgKiB0aGUgdGNwIGNoZWNr c3VtIG9uIHRoZSBwc2V1ZG9oZWFkZXIKLQkgKiBYWFggY2hlY2sgdGhpcywgY291bGQgc2F2ZSBh IGNvdXBsZSBvZiB3b3JkcyA/Ci0JICovCi0JaXAtPmlwX2xlbiA9IGh0b25zKHNpemVvZihzdHJ1 Y3QgdGNwaGRyKSk7Ci0JdGNwLT50aF9zdW0gPSBpbl9ja3N1bShtLCBtLT5tX3BrdGhkci5sZW4p OwotCS8qCi0JICogbm93IGZpbGwgZmllbGRzIGxlZnQgb3V0IGVhcmxpZXIKLQkgKi8KLQlpcC0+ aXBfdHRsID0gaXBfZGVmdHRsOwotCWlwLT5pcF9sZW4gPSBtLT5tX3BrdGhkci5sZW47Ci0JbS0+ bV9mbGFncyB8PSBNX1NLSVBfRklSRVdBTEw7CisKIAlyZXR1cm4gKG0pOwogfQogCkBAIC00ODYz LDYgKzQ4NzksOSBAQAogaXBmd190aWNrKHZvaWQgKiBfX3VudXNlZCB1bnVzZWQpCiB7CiAJc3Ry dWN0IG1idWYgKm0wLCAqbSwgKm1uZXh0LCAqKm10YWlscDsKKyNpZmRlZiBJTkVUNgorCXN0cnVj dCBtYnVmICptNiwgKiptNl90YWlscDsKKyNlbmRpZgogCWludCBpOwogCWlwZndfZHluX3J1bGUg KnE7CiAKQEAgLTQ4NzcsNiArNDg5NiwxMCBAQAogCSAqLwogCW0wID0gTlVMTDsKIAltdGFpbHAg PSAmbTA7CisjaWZkZWYgSU5FVDYKKwltNiA9IE5VTEw7CisJbTZfdGFpbHAgPSAmbTY7CisjZW5k aWYKIAlJUEZXX0RZTl9MT0NLKCk7CiAJZm9yIChpID0gMCA7IGkgPCBjdXJyX2R5bl9idWNrZXRz IDsgaSsrKSB7CiAJCWZvciAocSA9IGlwZndfZHluX3ZbaV0gOyBxIDsgcSA9IHEtPm5leHQgKSB7 CkBAIC00ODkyLDE0ICs0OTE1LDM3IEBACiAJCQlpZiAoVElNRV9MRVEocS0+ZXhwaXJlLCB0aW1l X3VwdGltZSkpCiAJCQkJY29udGludWU7CS8qIHRvbyBsYXRlLCBydWxlIGV4cGlyZWQgKi8KIAot CQkJKm10YWlscCA9IHNlbmRfcGt0KE5VTEwsICYocS0+aWQpLCBxLT5hY2tfcmV2IC0gMSwKKwkJ CW0gPSBzZW5kX3BrdChOVUxMLCAmKHEtPmlkKSwgcS0+YWNrX3JldiAtIDEsCiAJCQkJcS0+YWNr X2Z3ZCwgVEhfU1lOKTsKLQkJCWlmICgqbXRhaWxwICE9IE5VTEwpCi0JCQkJbXRhaWxwID0gJigq bXRhaWxwKS0+bV9uZXh0cGt0OwotCQkJKm10YWlscCA9IHNlbmRfcGt0KE5VTEwsICYocS0+aWQp LCBxLT5hY2tfZndkIC0gMSwKKwkJCW1uZXh0ID0gc2VuZF9wa3QoTlVMTCwgJihxLT5pZCksIHEt PmFja19md2QgLSAxLAogCQkJCXEtPmFja19yZXYsIDApOwotCQkJaWYgKCptdGFpbHAgIT0gTlVM TCkKLQkJCQltdGFpbHAgPSAmKCptdGFpbHApLT5tX25leHRwa3Q7CisKKwkJCXN3aXRjaCAocS0+ aWQuYWRkcl90eXBlKSB7CisJCQljYXNlIDQ6CisJCQkJaWYgKG0gIT0gTlVMTCkgeworCQkJCQkq bXRhaWxwID0gbTsKKwkJCQkJbXRhaWxwID0gJigqbXRhaWxwKS0+bV9uZXh0cGt0OworCQkJCX0K KwkJCQlpZiAobW5leHQgIT0gTlVMTCkgeworCQkJCQkqbXRhaWxwID0gbW5leHQ7CisJCQkJCW10 YWlscCA9ICYoKm10YWlscCktPm1fbmV4dHBrdDsKKwkJCQl9CisJCQkJYnJlYWs7CisjaWZkZWYg SU5FVDYKKwkJCWNhc2UgNjoKKwkJCQlpZiAobSAhPSBOVUxMKSB7CisJCQkJCSptNl90YWlscCA9 IG07CisJCQkJCW02X3RhaWxwID0gJigqbTZfdGFpbHApLT5tX25leHRwa3Q7CisJCQkJfQorCQkJ CWlmIChtbmV4dCAhPSBOVUxMKSB7CisJCQkJCSptNl90YWlscCA9IG1uZXh0OworCQkJCQltNl90 YWlscCA9ICYoKm02X3RhaWxwKS0+bV9uZXh0cGt0OworCQkJCX0KKwkJCQlicmVhazsKKyNlbmRp ZgorCQkJfQorCisJCQltID0gbW5leHQgPSBOVUxMOwogCQl9CiAJfQogCUlQRldfRFlOX1VOTE9D SygpOwpAQCAtNDkwOCw2ICs0OTU0LDEzIEBACiAJCW0tPm1fbmV4dHBrdCA9IE5VTEw7CiAJCWlw X291dHB1dChtLCBOVUxMLCBOVUxMLCAwLCBOVUxMLCBOVUxMKTsKIAl9CisjaWZkZWYgSU5FVDYK Kwlmb3IgKG0gPSBtbmV4dCA9IG02OyBtICE9IE5VTEw7IG0gPSBtbmV4dCkgeworCQltbmV4dCA9 IG0tPm1fbmV4dHBrdDsKKwkJbS0+bV9uZXh0cGt0ID0gTlVMTDsKKwkJaXA2X291dHB1dChtLCBO VUxMLCBOVUxMLCAwLCBOVUxMLCBOVUxMLCBOVUxMKTsKKwl9CisjZW5kaWYKIGRvbmU6CiAJY2Fs bG91dF9yZXNldCgmaXBmd190aW1lb3V0LCBkeW5fa2VlcGFsaXZlX3BlcmlvZCpoeiwgaXBmd190 aWNrLCBOVUxMKTsKIH0K ------=_20080519221520_63844-- From marconemlt at gmail.com Mon May 19 21:22:19 2008 From: marconemlt at gmail.com (Marcone Theisen) Date: Mon May 19 21:22:22 2008 Subject: Fwd traffic Message-ID: Hi, I'm forward all my traffic (port 80) from internal network to other IP (router), but I'm will not forward the traffic with 10.40.0.0 destination. How I can do ? 00018 fwd 10.10.18.254 tcp from 10.10.18.0/24 to any dst-port 80 00020 divert 8668 ip from any to any via em0 00021 allow ip from any to any Thank's, Marcone From fedex_courierbenin201 at yahoo.fr Sat May 24 02:38:39 2008 From: fedex_courierbenin201 at yahoo.fr (Barr Daniel Obiora (ESQ)) Date: Sat May 24 02:38:46 2008 Subject: ATTENTION Message-ID: <20080523154348.95B78879646@austin.pins-web.net> Hello Dear, I have Paid the fee for your Cheque Draft.but the manager of Eko Bankn Benin told me that before the check will get to you that it will expire.So i told him to cash $1.5M USA DOLLar all the necessary arrangement of delivering the $1.5M USA DOLLar in cash was made with FedEX DELIVERY COURIER COMPANY. This is the information they need to delivery your package to you.with FEDEX DELIVERY COURIER COMPANY, contact them now. NAME:FEDEX COURIER DELIVERING COMPANY. ATTANTION: PERSON: DR.JERRY LAWRENCE POSITION: FOREIGN DELIVERY DEPARTMENT. ADDRESS: COTONOU BENIN REPUBLIC E-MAIL:fedex_courierbenin201@yahoo.fr Phone number: PHONE NUMBER: +229 9374 0412 Please, Send them your contacts information to able them locate you immediately they arrived in your country with your BOX .This is what they need from you. 1.YOUR FULL NAME 2.YOUR HOME ADDRESS. 3.YOUR CURRENT HOME TELEPHONE NUMBER. 4.YOUR CURRENT OFFICE TELEPHONE. 5. YOUR CURRENT HOME TELEPHONE NUMBER. 6.A COPY OF YOUR PICTURE Note that this is there E-mail contact (fedex_courierbenin201@yahoo.fr) Please make sure you send this needed info's to the Director general of FEDEX DELIVERY COURIER COMPANY BENIN REPUBLIC,DR.JERRY Lawrence with the address given to you. Note. The Fedex Delivery Courier Company don't know the contents of the Box. I registered it as a Box of an African cloths. They don't know it contents money, this is to avoid them delaying with the Box.don't let them know that is money that is in that Box. Thanks and Remain Blessed. Barr Daniel Obiora (ESQ) From lysergius2001 at gmail.com Sat May 24 21:35:58 2008 From: lysergius2001 at gmail.com (lysergius2001) Date: Sat May 24 21:36:02 2008 Subject: ipfw rules problem Message-ID: Hi I am having a problem with my rule set. For some reason the who accesses from my local host, router and other machine on my local net are are being rejected. I have tried opening the port 513 but somehow the rules set does not see this. Any ideas? ---------------------------------------------------------------# # # # IPFW Firewall Rules (ipfw.rules_180508) # # # #-----------------------------------------------------------------------# #!/bin/sh #-----------------------------------------------------------------------# # Flush out the list before we begin. # #-----------------------------------------------------------------------# ipfw -q -f flush #-----------------------------------------------------------------------# # Reset logging # #-----------------------------------------------------------------------# ipfw -q resetlog #-----------------------------------------------------------------------# # Set rules command prefix # #-----------------------------------------------------------------------# cmd="ipfw -q add" #-----------------------------------------------------------------------# # Interface names # #-----------------------------------------------------------------------# pif="ath0" # public interface name of NIC facing the public Internet iif="nve0" # public interface name of NIC facing the private LAN lif="lo0" # Loopback #-----------------------------------------------------------------------# # DYNAMIC RULES # #-----------------------------------------------------------------------# $cmd 0010 check-state #-----------------------------------------------------------------------# # LOOPBACK INTERFACE 127.0.0.1 (lo0) "$lif" # # # # Purpose : allow Loopback and Deny Loopback Spoofing # #-----------------------------------------------------------------------# #---------------# # INBOUND # #---------------# $cmd 0020 allow all from 127.0.0.1 to me in via "$lif" $cmd 0030 allow all from me to 127.0.0.1 out via "$lif" $cmd 0040 allow tcp from 127.0.0.1 to 127.0.0.1 111 keep-state # Allow RPC from Loopback $cmd 0050 allow tcp from 127.0.0.1 to 127.0.0.1 113 keep-state # Allow Identd from loopback #---------------# # OUTBOUND # #---------------# $cmd 0060 allow all from 127.0.0.1 to me in via "$lif" $cmd 0070 allow all from me to 127.0.0.1 out via "$lif" #-----------------------------------------------------------------------# # INTERNAL NETWORK 10.0.0.4 (nve0) "$iif" # # # # Object : No restrictions on LAN Interface # #-----------------------------------------------------------------------# #---------------# # INBOUND # #---------------# $cmd 0100 allow all from 10.0.0.0/8 to me in via $iif $cmd 0200 deny all from 192.168.2.1 to any in via $iif #---------------# # OUTBOUND # #---------------# $cmd 0300 allow all from me to 10.0.0.0/8 out via $iif #-----------------------------------------------------------------------# # EXTERNAL NETWORK 192.168.2.1 (ath0) "$pif" # # # # Object : # #-----------------------------------------------------------------------# #---------------# # INBOUND # #---------------# $cmd 01000 allow tcp from any to me established $cmd 01010 allow tcp from any to me 21 in via $pif # FTP $cmd 01020 allow tcp from any to me 22 in via $pif setup keep-state # SSH $cmd 01030 allow udp from any to me 25 in via $pif setup keep-state # SMTP $cmd 01040 allow tcp from any to me 53 in via $ pif setup keep-state # DNS $cmd 01050 allow udp from any to me 53 in via $pif keep-state $cmd 01060 allow tcp from any to me 80 in via $pif setup keep-state # HTTP/WWW $cmd 01070 allow tcp from any to me 110 in via $pif setup keep-state # POP3 $cmd 01080 allow udp from any to me 161 in via $pif keep-state # SNMP $cmd 01090 allow udp from any to me 27015 in via $pif keep-state # Unassigned # Allow all IPv6 packets through - they are handled by the separate # ipv6 firewall rules in rc.firewall6. $cmd 01100 deny ipv6 from any to any $cmd 01110 deny all from 0.0.0.0/8 to me in via $pif #loopback $cmd 01120 deny all from any to 0.0.0.0/8 in via $pif $cmd 01130 deny all from any to 127.0.0.1/8 in via $pif $cmd 01140 deny all from 127.0.0.0/8 to me in via $pif #loopback $cmd 01150 deny all from any to 10.0.0.0/8 in via $pif $cmd 01160 deny all from 10.0.0.4 to any in via $pif $cmd 01170 deny all from 10.0.0.0/8 to me in via $pif #RFC 1918 private IP $cmd 01180 deny all from any to 172.16.0.0/12 in via $pif $cmd 01190 deny all from 172.16.0.0/12 to me in via $pif #RFC 1918 private IP $cmd 01200 deny all from any to 169.254.0.0/16 in via $pif $cmd 01210 deny all from 192.168.0.0/16 to me in via $pif #RFC 1918 private IP $cmd 01220 deny all from any to 224.0.0.0/4 in via $pif $cmd 01230 deny all from any to 240.0.0.0/4 in via $pif $cmd 01240 deny all from 169.254.0.0/16 to me in via $pif #DHCP auto-config $cmd 01250 deny all from 192.0.2.0/24 to me in via $pif #reserved for docs $cmd 01260 deny all from any to 192.0.2.0/24 in via $pif $cmd 01270 deny all from 204.152.64.0/23 to me in via $pif #Sun cluster interconnect $cmd 01280 deny all from 224.0.0.0/3 to me in via $pif #Class D & E multicast $cmd 01290 deny icmp from any to me in via $pif # Deny public pings $cmd 01300 deny tcp from any to me 113 in via $pif # Deny ident $cmd 01310 deny tcp from any to me 137 in via $pif # Netbios service=name $cmd 01320 deny tcp from any to me 138 in via $pif # Netbios service=datagram $cmd 01330 deny tcp from any to me 139 in via $pif # Netbios service=session $cmd 01340 deny tcp from any to me 81 in via $pif # Unassigned $cmd 01350 deny all from any to me frag in via $pif # Deny any late arriving packets $cmd 01360 deny tcp from any to me established in via $pif #---------------# # OUTBOUND # #---------------# $cmd 01370 deny all from 0.0.0.0/8 to any out via $pif $cmd 01380 deny log all from 127.0.0.1/8 to any out via $pif $cmd 01390 deny log all from 10.0.0.0/8 to any out via $pif $cmd 01400 deny tcp from any to me 25 out via $pif setup keep-state $cmd 01419 deny tcp from any to me 110 out via $pif setup keep-state $cmd 01420 allow all from me to any out via $pif keep-state $cmd 01430 allow icmp from me to any out via $pif $cmd 01440 allow tcp from 192.168.2.1 53 out via $pif setup keep-state # DNS $cmd 01450 allow udp from 192.168.2.1 53 out via $pif keep-state # DNS $cmd 01460 allow udp from any 68 to 192.168.2.1 67 out via $pif keep-state # Bootstrap Protocol Server $cmd 01470 allow tcp from me to any 21 out via $pif # FTP $cmd 01480 allow udp from me to any 53 out via $pif keep-state # DNS $cmd 01490 allow udp from me to any 53 out keep-state $cmd 01500 allow tcp from me to any 80 out via $pif setup keep-state # Allow out non-secure standard www function $cmd 01510 allow tcp from any to any 443 out via $pif setup keep-state # Allow out secure www function https over TLS SSL $cmd 01520 allow tcp from me to any out via $pif setup keep-state uid root # Allow out FBSD (make install & CVSUP) functions $cmd 01530 allow icmp from me to any out via $pif keep-state # Allow out ping $cmd 01540 allow tcp from me to any 37 out via $pif setup keep-state # Allow out Time $cmd 01550 allow tcp from me to any 119 out via $pif setup keep-state # Allow out nntp news (i.e. news groups 119)) $cmd 01560 allow tcp from me to any 22 out via $pif setup keep-state # Allow out secure FTP, Telnet, and SCP $cmd 01570 allow tcp from me to any 43 out via $pif setup keep-state # Allow out whois $cmd 01580 deny log udp from any to me in $cmd 01590 deny log udp from any to me out $cmd 01600 deny log udp from me to any in $cmd 01610 deny log udp from me to any out $cmd 01620 deny log ip from any to me in $cmd 01630 deny log ip from any to me out $cmd 01640 deny log ip from me to any in $cmd 01650 deny log ip from me to any out #-------------------------------------------------------------------------------# # Everything else is denied by default # # deny and log all packets that fell through to see what they are # #-------------------------------------------------------------------------------# $cmd 02000 deny log all from any to any #-------------------------# End of IPFW rules file #----------------------------# -- Lysergius says "Stay light and trust gravity" From bugmaster at FreeBSD.org Mon May 26 11:06:50 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 26 11:07:21 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200805261106.m4QB6n57064920@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/106534 ipfw [ipfw] [panic] ipfw + dummynet 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 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/111713 ipfw [dummynet] [request] Too few dummynet queue slots 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 30 problems total. From goffredo at gmail.com Mon May 26 19:05:26 2008 From: goffredo at gmail.com (Joao Rocha Braga Filho) Date: Mon May 26 19:05:58 2008 Subject: PR kern/111713 Message-ID: The solution for PR kern/111713 is very good. Using sysctl and creating "net.inet.ip.dummynet.pipe_slot_limit" parameter. It much is better than my idea. I will try it today. With a big queue I can use my "QoS with ACK Negative Feedback" without problems. Thanks, Jo?o Rocha -- goffredo@gmail.com From goffredo at gmail.com Wed May 28 19:50:17 2008 From: goffredo at gmail.com (Joao Rocha Braga Filho) Date: Wed May 28 19:50:20 2008 Subject: PR kern/111713 Message-ID: The sysctl solution worked VERY FINE. Thanks. The PR kern/111713 can be closed. Thanks, Jo?o -- goffredo@gmail.com From rihad at mail.ru Sat May 31 10:12:29 2008 From: rihad at mail.ru (rihad) Date: Sat May 31 10:12:33 2008 Subject: tablearg q'n Message-ID: <484113B4.4010006@mail.ru> ipfw add pipe tablearg ip from 'table(0)' to 'table(1)' Which of the two tables will tablearg come from? Any way to make the choice explicit? OS: FreeBSD 7.0 Thanks.