From chris at smartt.com Thu Oct 1 21:46:21 2009 From: chris at smartt.com (Chris St Denis) Date: Thu Oct 1 21:46:27 2009 Subject: ipfw: install_state: entry already present, done Message-ID: <4AC51F18.5050703@smartt.com> Haven't gotten any response on -questions so trying here. I've also opened a PR (kern/139226) but it's gotten no replies so I figured I should try here since I'm not certain if it's a bug or not. Regardless I am hoping for at least a work-around -- a few extra rules or settings to keep my console from being flooded by errors. So far only option I found is commenting out the error display line in the kernel source which is far from optimal. I'm trying to setup a stateful firewall for my server such that any traffic can go out, and it's reply come back -- a fairly typical workstation setup. However I'm getting the error message "ipfw: install_state: entry already present, done" repeated many times in my logs (tho the rules seemed to work fine otherwise). I stripped down the rules to the minimum I could and discovered the line causing it is "allow udp from me to any keep-state". Only seems to happen when I have bind running as a slave dns server (not publicly listed, just the zone replication traffic causes the error) but I assume any other large source of UDP traffic would also do it. Full firewall rules: dns2# ipfw list 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00400 allow udp from me to any keep-state 65535 deny ip from any to any I found some search results for this error message, but none seem to have a solution to the problem. I also tried adding at the start "allow { tcp or udp } from any to me dst-port 53" and "allow { tcp or udp } from me to any uid bind" which means the keepstate rule shouldn't even be getting hit much, but I still get a flood of errors. System info: dns2# uname -a FreeBSD dns2 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Hardware: virtual server under vmWare ESXi (not that that should matter) network card: em0 -- Chris St Denis Programmer SmarttNet (www.smartt.com) Ph: 604-473-9700 Ext. 200 ------------------------------------------- "Smart Internet Solutions For Businesses" From fjwcash at gmail.com Thu Oct 1 21:55:13 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Thu Oct 1 21:55:19 2009 Subject: ipfw: install_state: entry already present, done In-Reply-To: <4AC51F18.5050703@smartt.com> References: <4AC51F18.5050703@smartt.com> Message-ID: On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis wrote: > Haven't gotten any response on -questions so trying here. I've also opened > a PR (kern/139226) but it's gotten no replies so I figured I should try here > since I'm not certain if it's a bug or not. Regardless I am hoping for at > least a work-around -- a few extra rules or settings to keep my console from > being flooded by errors. So far only option I found is commenting out the > error display line in the kernel source which is far from optimal. > > I'm trying to setup a stateful firewall for my server such that any traffic > can go out, and it's reply come back -- a fairly typical workstation setup. > However I'm getting the error message "ipfw: install_state: entry already > present, done" repeated many times in my logs (tho the rules seemed to work > fine otherwise). > > I stripped down the rules to the minimum I could and discovered the line > causing it is "allow udp from me to any keep-state". > > Only seems to happen when I have bind running as a slave dns server (not > publicly listed, just the zone replication traffic causes the error) but I > assume any other large source of UDP traffic would also do it. > > Full firewall rules: > > dns2# ipfw list > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 00400 allow udp from me to any keep-state > 65535 deny ip from any to any > > If you add "out xmit em0" to the udp rule, do the errors stop? -- Freddie Cash fjwcash@gmail.com From chris at smartt.com Thu Oct 1 22:11:32 2009 From: chris at smartt.com (Chris St Denis) Date: Thu Oct 1 22:11:38 2009 Subject: ipfw: install_state: entry already present, done In-Reply-To: References: <4AC51F18.5050703@smartt.com> Message-ID: <4AC52918.2020705@smartt.com> Freddie Cash wrote: > On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis wrote: > > >> Haven't gotten any response on -questions so trying here. I've also opened >> a PR (kern/139226) but it's gotten no replies so I figured I should try here >> since I'm not certain if it's a bug or not. Regardless I am hoping for at >> least a work-around -- a few extra rules or settings to keep my console from >> being flooded by errors. So far only option I found is commenting out the >> error display line in the kernel source which is far from optimal. >> >> I'm trying to setup a stateful firewall for my server such that any traffic >> can go out, and it's reply come back -- a fairly typical workstation setup. >> However I'm getting the error message "ipfw: install_state: entry already >> present, done" repeated many times in my logs (tho the rules seemed to work >> fine otherwise). >> >> I stripped down the rules to the minimum I could and discovered the line >> causing it is "allow udp from me to any keep-state". >> >> Only seems to happen when I have bind running as a slave dns server (not >> publicly listed, just the zone replication traffic causes the error) but I >> assume any other large source of UDP traffic would also do it. >> >> Full firewall rules: >> >> dns2# ipfw list >> 00100 allow ip from any to any via lo0 >> 00200 deny ip from any to 127.0.0.0/8 >> 00300 deny ip from 127.0.0.0/8 to any >> 00400 allow udp from me to any keep-state >> 65535 deny ip from any to any >> >> >> > If you add "out xmit em0" to the udp rule, do the errors stop I added that and restarted bind (thus generating a bunch of UDP traffic) and the error still floods the console. Current rule set: 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00400 allow udp from me to any out xmit em0 keep-state 00500 allow ip from any to any 65535 deny ip from any to any From bugmaster at FreeBSD.org Mon Oct 5 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 5 11:08:40 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200910051106.n95B6sfi088709@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/139226 ipfw [ipfw] install_state: entry already present, done o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 63 problems total. From apauljoe at gmail.com Wed Oct 7 20:14:35 2009 From: apauljoe at gmail.com (Joe R) Date: Wed Oct 7 20:14:41 2009 Subject: Extension of dummynet/ipfw to support userspace packet classification Message-ID: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> We at ironport have a requirement to do bandwidth management, but the traffic classification (and selection of bandwidth pipes) is done in userspace. The reason classification is done in userspace is because the traffic classifications are something like streaming audio traffic, video traffic, based on website categories etc. Our appliance is based on FreeBSD, and so we decided to look at dummynet to support our requirement. We could not use dummynet as such because it uses ipfw for packet classification, where packet classification (and pipe selection) is done in kernel based on tcp/ip parameters like IP and port. So we decided to extended dummynet/ipfw to support packet classification in userspace. Our idea is to extended socket structure to have a pipe number and have a setsockoption to associate the pipe number to a socket structure. Then have a new ipfw target (mappedpipe), which will pass the packet to dummynet (similar to pipe target) but with the pipe number in the socket structure if it is non-zero. I would like to know your comments on this proposal and if people are interested, I will be happy to submit a patch on this. Thanks, Joe. From ghelmer at palisadesys.com Wed Oct 7 21:55:23 2009 From: ghelmer at palisadesys.com (Guy Helmer) Date: Wed Oct 7 21:55:29 2009 Subject: Extension of dummynet/ipfw to support userspace packet classification In-Reply-To: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> References: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> Message-ID: <4ACD04E5.50806@palisadesys.com> Joe R wrote: > We at ironport have a requirement to do bandwidth management, but the > traffic classification (and selection of bandwidth pipes) is done in > userspace. The reason classification is done in userspace is because the > traffic classifications are something like streaming audio traffic, video > traffic, based on website categories etc. > > > > Our appliance is based on FreeBSD, and so we decided to look at dummynet to > support our requirement. We could not use dummynet as such because it uses > ipfw for packet classification, where packet classification (and pipe > selection) is done in kernel based on tcp/ip parameters like IP and port. > > > > So we decided to extended dummynet/ipfw to support packet classification in > userspace. > > Our idea is to extended socket structure to have a pipe number and have a > setsockoption to associate the pipe number to a socket structure. Then have > a new ipfw target (mappedpipe), which will pass the packet to dummynet > (similar to pipe target) but with the pipe number in the socket structure if > it is non-zero. > > > > I would like to know your comments on this proposal and if people are > interested, I will be happy to submit a patch on this. > > I think it would be a very useful capability to apply a dummynet pipe to a stream. My thinking was that it would be nice to be able to build a dynamic table of connections in ipfw and then ipfw could pass packets that matched the dynamic connections list through a specified dummynet pipe. I think that is different than your design, though -- as I understand it, your design would apply dummynet to packets written to a socket. Guy From julian at elischer.org Wed Oct 7 22:40:32 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Oct 7 22:40:43 2009 Subject: Extension of dummynet/ipfw to support userspace packet classification In-Reply-To: <4ACD04E5.50806@palisadesys.com> References: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> <4ACD04E5.50806@palisadesys.com> Message-ID: <4ACD18E1.3040901@elischer.org> Guy Helmer wrote: > Joe R wrote: >> We at ironport have a requirement to do bandwidth management, but the >> traffic classification (and selection of bandwidth pipes) is done in >> userspace. The reason classification is done in userspace is because the >> traffic classifications are something like streaming audio traffic, video >> traffic, based on website categories etc. >> >> >> >> Our appliance is based on FreeBSD, and so we decided to look at >> dummynet to >> support our requirement. We could not use dummynet as such because it >> uses >> ipfw for packet classification, where packet classification (and pipe >> selection) is done in kernel based on tcp/ip parameters like IP and port. >> >> >> >> So we decided to extended dummynet/ipfw to support packet >> classification in >> userspace. >> >> Our idea is to extended socket structure to have a pipe number and have a >> setsockoption to associate the pipe number to a socket structure. Then >> have >> a new ipfw target (mappedpipe), which will pass the packet to dummynet >> (similar to pipe target) but with the pipe number in the socket >> structure if >> it is non-zero. >> >> >> >> I would like to know your comments on this proposal and if people are >> interested, I will be happy to submit a patch on this. >> >> > I think it would be a very useful capability to apply a dummynet pipe to > a stream. > > My thinking was that it would be nice to be able to build a dynamic > table of connections in ipfw and then ipfw could pass packets that > matched the dynamic connections list through a specified dummynet pipe. > I think that is different than your design, though -- as I understand > it, your design would apply dummynet to packets written to a socket. > > Guy What they want to do is what I was going to do before I "left" there .. which is to allow a userland process (e.g. proxy) classify the session using some un-named method , assign some session key to the socket that can be attached to the mbufs in some way as they are generated. an in-kernel flow control module (e.g. dummynet) could then be left to enforce the bandwidth usage by that session. When I originally laid this out I thought we'd need the following parts working to allow this to happen: * ioctl to add value to a new field in the socket. * a place to store a copy of the field in the mbuf, OR a way to reference the one in the socket. * a way to get such packets to the right dummynet pipe. e.g. a new ipfw rule type. * A frontend to set up the pipes (not our problem). From rizzo at iet.unipi.it Wed Oct 7 22:48:10 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Wed Oct 7 22:48:17 2009 Subject: Extension of dummynet/ipfw to support userspace packet classification In-Reply-To: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> References: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> Message-ID: <20091007225452.GA37005@onelab2.iet.unipi.it> On Wed, Oct 07, 2009 at 12:46:24PM -0700, Joe R wrote: > We at ironport have a requirement to do bandwidth management, but the > traffic classification (and selection of bandwidth pipes) is done in > userspace. The reason classification is done in userspace is because the > traffic classifications are something like streaming audio traffic, video > traffic, based on website categories etc. > > > > Our appliance is based on FreeBSD, and so we decided to look at dummynet to > support our requirement. We could not use dummynet as such because it uses > ipfw for packet classification, where packet classification (and pipe > selection) is done in kernel based on tcp/ip parameters like IP and port. > > > > So we decided to extended dummynet/ipfw to support packet classification in > userspace. > > Our idea is to extended socket structure to have a pipe number and have a > setsockoption to associate the pipe number to a socket structure. Then have > a new ipfw target (mappedpipe), which will pass the packet to dummynet > (similar to pipe target) but with the pipe number in the socket structure if > it is non-zero. > > > > I would like to know your comments on this proposal and if people are > interested, I will be happy to submit a patch on this. i think the feature is useful. However I would implement it as an ipfw 'option' called "sockarg" (or similar) as follows: ipfw pipe tablearg sockarg where 'sockarg' succeeds ONLY if the packet is associated to a socket for which the special setsockoption has been issued, and in this case sets the 'tablearg' to the value of the setsockopt. This is somewhat similar to the 'uid' and 'gid' options (except for setting tablearg). This way the mechanism can be very general (not limited to pipes) and the implementation is probably simpler than the one you propose. In terms of runtime costs, we can look at check_uidgid() function, and there are two ways to implement this feature: - as in check_uidgid() , actively lookup for a matching socket if one is not available. This is expensive but would allow the feature to match also incoming packets; - only match if the args->inp parameter is non-null, otherwise do not call in_pcblookup_hash(). This is cheaper but clearly only works for locally generated packets. Perhaps we could use an argument for 'sockarg' so we can decide whether to call or not the in_pcblookup_hash() on a case-by-case basis. cheers luigi From rizzo at iet.unipi.it Wed Oct 7 23:02:27 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Wed Oct 7 23:02:34 2009 Subject: Extension of dummynet/ipfw to support userspace packet classification In-Reply-To: <20091007225452.GA37005@onelab2.iet.unipi.it> References: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> <20091007225452.GA37005@onelab2.iet.unipi.it> Message-ID: <20091007230909.GB37005@onelab2.iet.unipi.it> On Thu, Oct 08, 2009 at 12:54:52AM +0200, Luigi Rizzo wrote: > On Wed, Oct 07, 2009 at 12:46:24PM -0700, Joe R wrote: > > We at ironport have a requirement to do bandwidth management, but the > > traffic classification (and selection of bandwidth pipes) is done in > > userspace. The reason classification is done in userspace is because the > > traffic classifications are something like streaming audio traffic, video > > traffic, based on website categories etc. > > > > > > > > Our appliance is based on FreeBSD, and so we decided to look at dummynet to > > support our requirement. We could not use dummynet as such because it uses > > ipfw for packet classification, where packet classification (and pipe > > selection) is done in kernel based on tcp/ip parameters like IP and port. > > > > > > > > So we decided to extended dummynet/ipfw to support packet classification in > > userspace. > > > > Our idea is to extended socket structure to have a pipe number and have a > > setsockoption to associate the pipe number to a socket structure. Then have > > a new ipfw target (mappedpipe), which will pass the packet to dummynet > > (similar to pipe target) but with the pipe number in the socket structure if > > it is non-zero. > > > > > > > > I would like to know your comments on this proposal and if people are > > interested, I will be happy to submit a patch on this. > > i think the feature is useful. However I would implement it as an > ipfw 'option' called "sockarg" (or similar) as follows: > > ipfw pipe tablearg sockarg > > where 'sockarg' succeeds ONLY if the packet is associated to a socket > for which the special setsockoption has been issued, and in this > case sets the 'tablearg' to the value of the setsockopt. This is > somewhat similar to the 'uid' and 'gid' options (except for setting > tablearg). This way the mechanism can be very general (not limited > to pipes) and the implementation is probably > simpler than the one you propose. > > In terms of runtime costs, we can look at check_uidgid() function, > and there are two ways to implement this feature: > - as in check_uidgid() , actively lookup for a matching socket if one > is not available. This is expensive but would allow the feature to > match also incoming packets; > - only match if the args->inp parameter is non-null, otherwise do not > call in_pcblookup_hash(). This is cheaper but clearly only works > for locally generated packets. > Perhaps we could use an argument for 'sockarg' so we can decide > whether to call or not the in_pcblookup_hash() on a case-by-case > basis. To complete the analysis, I must say that I don't know how intrusive is the setsockopt that can attach a classification tag to the socket. This is my main concern for merging your proposal into the system (and i am only concerned about the socket part, the ipfw change is trivial). Also for completeness, there is also another possible approach to address your problem, which is more general and fully contained in ipfw (so less intrusive for the OS): add a 'hashtable' structure to ipfw, which works in a way similar to the 'table' with the difference that entries would be the whole 5-tuple of the packet. There is already a hash table in ipfw (used for dynamic rules) so it would be only a matter of adding the necessary glue to manipulate the hash table from /sbin/ipfw. An additional bonus of this approach is that one could use this new code to 'prime' the dynamic rule table after a reboot, which is a feature that people ask from time to time. cheers luigi From me at sharktooth.org Thu Oct 8 03:18:50 2009 From: me at sharktooth.org (Jason Lewis) Date: Thu Oct 8 03:18:57 2009 Subject: ipfw: install_state: entry already present, done In-Reply-To: <4AC52918.2020705@smartt.com> References: <4AC51F18.5050703@smartt.com> <4AC52918.2020705@smartt.com> Message-ID: <8d923f617db88c873c63bb2038752147.squirrel@users.sharktooth.org> Did you try a check_state? I am using this same rule structure on BSD6 without a problem. Thanks, Jason http://jasonlewis.yaritz.net > Freddie Cash wrote: >> On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis wrote: >> >> >>> Haven't gotten any response on -questions so trying here. I've also >>> opened >>> a PR (kern/139226) but it's gotten no replies so I figured I should try >>> here >>> since I'm not certain if it's a bug or not. Regardless I am hoping for >>> at >>> least a work-around -- a few extra rules or settings to keep my console >>> from >>> being flooded by errors. So far only option I found is commenting out >>> the >>> error display line in the kernel source which is far from optimal. >>> >>> I'm trying to setup a stateful firewall for my server such that any >>> traffic >>> can go out, and it's reply come back -- a fairly typical workstation >>> setup. >>> However I'm getting the error message "ipfw: install_state: entry >>> already >>> present, done" repeated many times in my logs (tho the rules seemed to >>> work >>> fine otherwise). >>> >>> I stripped down the rules to the minimum I could and discovered the >>> line >>> causing it is "allow udp from me to any keep-state". >>> >>> Only seems to happen when I have bind running as a slave dns server >>> (not >>> publicly listed, just the zone replication traffic causes the error) >>> but I >>> assume any other large source of UDP traffic would also do it. >>> >>> Full firewall rules: >>> >>> dns2# ipfw list >>> 00100 allow ip from any to any via lo0 >>> 00200 deny ip from any to 127.0.0.0/8 >>> 00300 deny ip from 127.0.0.0/8 to any >>> 00400 allow udp from me to any keep-state >>> 65535 deny ip from any to any >>> >>> >>> >> If you add "out xmit em0" to the udp rule, do the errors stop > I added that and restarted bind (thus generating a bunch of UDP traffic) > and the error still floods the console. > > Current rule set: > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 00400 allow udp from me to any out xmit em0 keep-state > 00500 allow ip from any to any > 65535 deny ip from any to any > > _______________________________________________ > 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 chris at smartt.com Fri Oct 9 19:47:08 2009 From: chris at smartt.com (Chris St Denis) Date: Fri Oct 9 19:47:37 2009 Subject: ipfw: install_state: entry already present, done In-Reply-To: <8d923f617db88c873c63bb2038752147.squirrel@users.sharktooth.org> References: <4AC51F18.5050703@smartt.com> <4AC52918.2020705@smartt.com> <8d923f617db88c873c63bb2038752147.squirrel@users.sharktooth.org> Message-ID: <4ACF9341.2040406@smartt.com> check_state doesn't help. The error is also generated from the rc.conf firewall_type="workstation" rule set which includes check_state among several other rules. I made a copy of this server (it's a virtual server under WMware) and downgraded it to 6.4-RELEASE-p7 and I no longer get the error. I downgraded another copy to 7.2-RELEASE (no patches) by copying the generic kernel off the CD. Still gets errors. Downgraded it to 7.0-RELEASE and the message stopped. I'm going to try going to 7.1 and see which behavior it has. Looks like there may have been a regression in 7.2 (or maybe 7.1 pending the results of my further testing) Jason Lewis wrote: > Did you try a check_state? I am using this same rule structure on BSD6 > without a problem. > > Thanks, > Jason > http://jasonlewis.yaritz.net > > >> Freddie Cash wrote: >> >>> On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis wrote: >>> >>> >>> >>>> Haven't gotten any response on -questions so trying here. I've also >>>> opened >>>> a PR (kern/139226) but it's gotten no replies so I figured I should try >>>> here >>>> since I'm not certain if it's a bug or not. Regardless I am hoping for >>>> at >>>> least a work-around -- a few extra rules or settings to keep my console >>>> from >>>> being flooded by errors. So far only option I found is commenting out >>>> the >>>> error display line in the kernel source which is far from optimal. >>>> >>>> I'm trying to setup a stateful firewall for my server such that any >>>> traffic >>>> can go out, and it's reply come back -- a fairly typical workstation >>>> setup. >>>> However I'm getting the error message "ipfw: install_state: entry >>>> already >>>> present, done" repeated many times in my logs (tho the rules seemed to >>>> work >>>> fine otherwise). >>>> >>>> I stripped down the rules to the minimum I could and discovered the >>>> line >>>> causing it is "allow udp from me to any keep-state". >>>> >>>> Only seems to happen when I have bind running as a slave dns server >>>> (not >>>> publicly listed, just the zone replication traffic causes the error) >>>> but I >>>> assume any other large source of UDP traffic would also do it. >>>> >>>> Full firewall rules: >>>> >>>> dns2# ipfw list >>>> 00100 allow ip from any to any via lo0 >>>> 00200 deny ip from any to 127.0.0.0/8 >>>> 00300 deny ip from 127.0.0.0/8 to any >>>> 00400 allow udp from me to any keep-state >>>> 65535 deny ip from any to any >>>> >>>> >>>> >>>> >>> If you add "out xmit em0" to the udp rule, do the errors stop >>> >> I added that and restarted bind (thus generating a bunch of UDP traffic) >> and the error still floods the console. >> >> Current rule set: >> 00100 allow ip from any to any via lo0 >> 00200 deny ip from any to 127.0.0.0/8 >> 00300 deny ip from 127.0.0.0/8 to any >> 00400 allow udp from me to any out xmit em0 keep-state >> 00500 allow ip from any to any >> 65535 deny ip from any to any >> >> _______________________________________________ >> 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" >> >> > > > _______________________________________________ > 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" > -- Chris St Denis Programmer SmarttNet (www.smartt.com) Ph: 604-473-9700 Ext. 200 ------------------------------------------- "Smart Internet Solutions For Businesses" From bugmaster at FreeBSD.org Mon Oct 12 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 12 11:08:30 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200910121106.n9CB6tkM036440@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/139226 ipfw [ipfw] install_state: entry already present, done o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 63 problems total. From gavin at FreeBSD.org Wed Oct 14 20:19:39 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Wed Oct 14 20:19:46 2009 Subject: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth Message-ID: <200910142019.n9EKJdkv078859@freefall.freebsd.org> Old Synopsis: ipfw pipe New Synopsis: [ipfw] "ipfw pipe" not limiting bandwidth Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: gavin Responsible-Changed-When: Wed Oct 14 20:17:06 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=139581 From chris at smartt.com Fri Oct 16 23:11:59 2009 From: chris at smartt.com (Chris St Denis) Date: Fri Oct 16 23:12:06 2009 Subject: ipfw: install_state: entry already present, done In-Reply-To: <4ACF9341.2040406@smartt.com> References: <4AC51F18.5050703@smartt.com> <4AC52918.2020705@smartt.com> <8d923f617db88c873c63bb2038752147.squirrel@users.sharktooth.org> <4ACF9341.2040406@smartt.com> Message-ID: <4AD8FDD0.30008@smartt.com> This is definitely a regression in 7.2. Downgrades to 6.4, 7.0, 7.1 did not show this symptom. Upgrade the test server back to 7.2 and the messages come back. Chris St Denis wrote: > check_state doesn't help. The error is also generated from the rc.conf > firewall_type="workstation" rule set which includes check_state among > several other rules. > > I made a copy of this server (it's a virtual server under WMware) and > downgraded it to 6.4-RELEASE-p7 and I no longer get the error. > > I downgraded another copy to 7.2-RELEASE (no patches) by copying the > generic kernel off the CD. Still gets errors. > > Downgraded it to 7.0-RELEASE and the message stopped. > > I'm going to try going to 7.1 and see which behavior it has. > > Looks like there may have been a regression in 7.2 (or maybe 7.1 > pending the results of my further testing) > > > Jason Lewis wrote: >> Did you try a check_state? I am using this same rule structure on BSD6 >> without a problem. >> >> Thanks, >> Jason >> http://jasonlewis.yaritz.net >> >> >>> Freddie Cash wrote: >>> >>>> On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis >>>> wrote: >>>> >>>> >>>> >>>>> Haven't gotten any response on -questions so trying here. I've also >>>>> opened >>>>> a PR (kern/139226) but it's gotten no replies so I figured I >>>>> should try >>>>> here >>>>> since I'm not certain if it's a bug or not. Regardless I am hoping >>>>> for >>>>> at >>>>> least a work-around -- a few extra rules or settings to keep my >>>>> console >>>>> from >>>>> being flooded by errors. So far only option I found is commenting out >>>>> the >>>>> error display line in the kernel source which is far from optimal. >>>>> >>>>> I'm trying to setup a stateful firewall for my server such that any >>>>> traffic >>>>> can go out, and it's reply come back -- a fairly typical workstation >>>>> setup. >>>>> However I'm getting the error message "ipfw: install_state: entry >>>>> already >>>>> present, done" repeated many times in my logs (tho the rules >>>>> seemed to >>>>> work >>>>> fine otherwise). >>>>> >>>>> I stripped down the rules to the minimum I could and discovered the >>>>> line >>>>> causing it is "allow udp from me to any keep-state". >>>>> >>>>> Only seems to happen when I have bind running as a slave dns server >>>>> (not >>>>> publicly listed, just the zone replication traffic causes the error) >>>>> but I >>>>> assume any other large source of UDP traffic would also do it. >>>>> >>>>> Full firewall rules: >>>>> >>>>> dns2# ipfw list >>>>> 00100 allow ip from any to any via lo0 >>>>> 00200 deny ip from any to 127.0.0.0/8 >>>>> 00300 deny ip from 127.0.0.0/8 to any >>>>> 00400 allow udp from me to any keep-state >>>>> 65535 deny ip from any to any >>>>> >>>>> >>>>> >>>>> >>>> If you add "out xmit em0" to the udp rule, do the errors stop >>>> >>> I added that and restarted bind (thus generating a bunch of UDP >>> traffic) >>> and the error still floods the console. >>> >>> Current rule set: >>> 00100 allow ip from any to any via lo0 >>> 00200 deny ip from any to 127.0.0.0/8 >>> 00300 deny ip from 127.0.0.0/8 to any >>> 00400 allow udp from me to any out xmit em0 keep-state >>> 00500 allow ip from any to any >>> 65535 deny ip from any to any >>> >>> _______________________________________________ >>> 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" >>> >>> >> >> >> _______________________________________________ >> 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" >> > > -- Chris St Denis Programmer SmarttNet (www.smartt.com) Ph: 604-473-9700 Ext. 200 ------------------------------------------- "Smart Internet Solutions For Businesses" From chris at smartt.com Fri Oct 16 23:30:07 2009 From: chris at smartt.com (Chris St Denis) Date: Fri Oct 16 23:30:13 2009 Subject: kern/139226: [ipfw] install_state: entry already present, done Message-ID: <200910162330.n9GNU6vq067517@freefall.freebsd.org> The following reply was made to PR kern/139226; it has been noted by GNATS. From: Chris St Denis To: bug-followup@FreeBSD.org, chris@smartt.com Cc: Subject: Re: kern/139226: [ipfw] install_state: entry already present, done Date: Fri, 16 Oct 2009 16:21:31 -0700 I tested this in other versions of FreeBSD by downgrading to 6.4, 7.0, & 7.1 with freebsd-update. None of the other version experianced this behavior. However when going back to 7.2 (with freebsd-update) the error returned. Seems to be a regression in 7.2 -- Chris St Denis Programmer SmarttNet (www.smartt.com) Ph: 604-473-9700 Ext. 200 ------------------------------------------- "Smart Internet Solutions For Businesses" From smithi at nimnet.asn.au Sat Oct 17 06:42:00 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Sat Oct 17 06:42:09 2009 Subject: ipfw: install_state: entry already present, done In-Reply-To: <4AD8FDD0.30008@smartt.com> References: <4AC51F18.5050703@smartt.com> <4AC52918.2020705@smartt.com> <8d923f617db88c873c63bb2038752147.squirrel@users.sharktooth.org> <4ACF9341.2040406@smartt.com> <4AD8FDD0.30008@smartt.com> Message-ID: <20091017171148.T70724@sola.nimnet.asn.au> On Fri, 16 Oct 2009, Chris St Denis wrote: > > This is definitely a regression in 7.2. > > Downgrades to 6.4, 7.0, 7.1 did not show this symptom. Upgrade the test > server back to 7.2 and the messages come back. I notice neither your rules shown below nor the "workstation" rules - unlike the "client" and "simple" rulesets - allow IP fragments to pass, and I'm not sure what happens to frags that are associated with stateful DNS rules. The only frags I usually see here are associated with DNS responses from my forwarders, usually huge lists of NS for spamhaus.org that are almost always fragmented (around 2Kbytes). You could maybe try a specific 'allow log all from any to any frag' ? Just a wild stab in the dark, cheers, Ian > Chris St Denis wrote: > > check_state doesn't help. The error is also generated from the rc.conf > > firewall_type="workstation" rule set which includes check_state among > > several other rules. > > > > I made a copy of this server (it's a virtual server under WMware) and > > downgraded it to 6.4-RELEASE-p7 and I no longer get the error. > > > > I downgraded another copy to 7.2-RELEASE (no patches) by copying the > > generic kernel off the CD. Still gets errors. > > > > Downgraded it to 7.0-RELEASE and the message stopped. > > > > I'm going to try going to 7.1 and see which behavior it has. > > > > Looks like there may have been a regression in 7.2 (or maybe 7.1 pending > > the results of my further testing) > > > > > > Jason Lewis wrote: > > > Did you try a check_state? I am using this same rule structure on BSD6 > > > without a problem. > > > > > > Thanks, > > > Jason > > > http://jasonlewis.yaritz.net > > > > > > > > > > Freddie Cash wrote: > > > > > > > > > On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Haven't gotten any response on -questions so trying here. I've also > > > > > > opened > > > > > > a PR (kern/139226) but it's gotten no replies so I figured I should > > > > > > try > > > > > > here > > > > > > since I'm not certain if it's a bug or not. Regardless I am hoping > > > > > > for > > > > > > at > > > > > > least a work-around -- a few extra rules or settings to keep my > > > > > > console > > > > > > from > > > > > > being flooded by errors. So far only option I found is commenting > > > > > > out > > > > > > the > > > > > > error display line in the kernel source which is far from optimal. > > > > > > > > > > > > I'm trying to setup a stateful firewall for my server such that any > > > > > > traffic > > > > > > can go out, and it's reply come back -- a fairly typical > > > > > > workstation > > > > > > setup. > > > > > > However I'm getting the error message "ipfw: install_state: entry > > > > > > already > > > > > > present, done" repeated many times in my logs (tho the rules seemed > > > > > > to > > > > > > work > > > > > > fine otherwise). > > > > > > > > > > > > I stripped down the rules to the minimum I could and discovered the > > > > > > line > > > > > > causing it is "allow udp from me to any keep-state". > > > > > > > > > > > > Only seems to happen when I have bind running as a slave dns server > > > > > > (not > > > > > > publicly listed, just the zone replication traffic causes the > > > > > > error) > > > > > > but I > > > > > > assume any other large source of UDP traffic would also do it. > > > > > > > > > > > > Full firewall rules: > > > > > > > > > > > > dns2# ipfw list > > > > > > 00100 allow ip from any to any via lo0 > > > > > > 00200 deny ip from any to 127.0.0.0/8 > > > > > > 00300 deny ip from 127.0.0.0/8 to any > > > > > > 00400 allow udp from me to any keep-state > > > > > > 65535 deny ip from any to any > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you add "out xmit em0" to the udp rule, do the errors stop > > > > > > > > > I added that and restarted bind (thus generating a bunch of UDP > > > > traffic) > > > > and the error still floods the console. > > > > > > > > Current rule set: > > > > 00100 allow ip from any to any via lo0 > > > > 00200 deny ip from any to 127.0.0.0/8 > > > > 00300 deny ip from 127.0.0.0/8 to any > > > > 00400 allow udp from me to any out xmit em0 keep-state > > > > 00500 allow ip from any to any > > > > 65535 deny ip from any to any > > > > > > > > _______________________________________________ > > > > 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" > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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" > > > > > > > > > > -- > Chris St Denis > Programmer > SmarttNet (www.smartt.com) > Ph: 604-473-9700 Ext. 200 > ------------------------------------------- > "Smart Internet Solutions For Businesses" > _______________________________________________ > 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 bugmaster at FreeBSD.org Mon Oct 19 11:06:56 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 19 11:08:36 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200910191106.n9JB6tw8063480@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth o kern/139226 ipfw [ipfw] install_state: entry already present, done o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 64 problems total. From smithi at nimnet.asn.au Mon Oct 19 14:50:03 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Mon Oct 19 14:50:09 2009 Subject: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth Message-ID: <200910191450.n9JEo2fx057396@freefall.freebsd.org> The following reply was made to PR kern/139581; it has been noted by GNATS. From: Ian Smith To: bug-followup@FreeBSD.org, freebsd@alexus.org Cc: Subject: Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth Date: Tue, 20 Oct 2009 01:24:17 +1100 May be a usage issue; I'll have a go. Partial quoting, out of order. : I'm trying to limit my apache that runs under daemon to up 2Mbit/s : when I do "ipfw pipe show" I don't see anything in my slots other then : very first entry that never chage, nor does it limits my traffic, as : if I look at my MRTG i see way more traffic then 2Mbit/s Unless you specify masks on your pipes you'll only ever see the first connection that used that pipe, that's normal. MRTG sees all traffic on an interface, and your ipfw stats indicate at least 25% more traffic than that due to your webserver, so it's not clear how you could tell if your pipe was exceeding 2Mbit/s or not? Also, it's recommended not to run your inbound and outbound traffic through the one pipe, unless simulating half-duplex connections; see explanation in ipfw(8), EXAMPLES section under TRAFFIC SHAPING. : su-3.2# ipfw show : 00100 1249368 205115325 allow ip from any to any via lo0 : 00200 0 0 deny ip from any to 127.0.0.0/8 : 00300 0 0 deny ip from 127.0.0.0/8 to any : 08380 2838075 3586421013 pipe 1 tcp from any 80 to any uid daemon : 08380 2097473 136454502 pipe 1 tcp from any to any dst-port 80 uid daemon : 65000 5740679 4716157064 allow ip from any to any : 65535 0 0 deny ip from any to any 3.586 GiB outbound from the webserver (served data) 0.136 GiB inbound to the webserver (requests, acks) + --- 3.722 GiB through the pipe. but 4.716 GiB passed from any to any, either way. So there's about 1 Gig of extra traffic shown here, assuming you have net.inet.ip.fw.one_pass=0 and all traffic eventually hits rule 65000 (and 4.7G extra traffic if net.inet.ip.fw.one_pass=1) but there's not enough info to see whether or not it's on the interface MRTG watches? : su-3.2# ipfw pipe show : 00001: 2.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail : mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 : BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp : 0 tcp 64.237.55.83/59388 208.80.152.3/80 4936077 3723134341 0 0 30179 Total packets and bytes match the above, indicating that this was done just after the ipfw show. 0.6% dropped packets indicates some limiting happening, but with a shared in/outbound pipe, not in which direction. If this is still an issue, please: . be more precise than "way more traffic" if you have more data? . say whether the extra ~25% traffic shown is on the same interface as the webserver, ie the interface MRTG monitors, or not? . the value of sysctl net.inet.ip.fw.one_pass ? cheers, Ian From alexus at alexus.org Mon Oct 19 16:30:06 2009 From: alexus at alexus.org (alexus) Date: Mon Oct 19 16:30:12 2009 Subject: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth Message-ID: <200910191630.n9JGU5cc042779@freefall.freebsd.org> The following reply was made to PR kern/139581; it has been noted by GNATS. From: alexus To: Ian Smith Cc: bug-followup@FreeBSD.org, freebsd@alexus.org Subject: Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth Date: Mon, 19 Oct 2009 11:58:41 -0400 On Oct 19, 2009, at 10:24 AM, Ian Smith wrote: > May be a usage issue; I'll have a go. Partial quoting, out of order. > > : I'm trying to limit my apache that runs under daemon to up 2Mbit/s > : when I do "ipfw pipe show" I don't see anything in my slots other > then > : very first entry that never chage, nor does it limits my traffic, as > : if I look at my MRTG i see way more traffic then 2Mbit/s > > Unless you specify masks on your pipes you'll only ever see the first > connection that used that pipe, that's normal. ok new set of rules su-3.2# cat /etc/ipfw.rules flush pipe flush pipe 1 config bw 1Mbit/s mask src-port www pipe 2 config bw 1Mbit/s mask src-port www add 100 allow ip from any to any via lo0 add 200 deny ip from any to 127.0.0.0/8 add 300 deny ip from 127.0.0.0/8 to any add 8381 pipe 1 tcp from any to any dst-port www uid daemon add 8382 pipe 2 tcp from any to any src-port www uid daemon add 65000 pass all from any to any su-3.2# ipfw show 00100 1476 230632 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 08381 482 36368 pipe 1 tcp from any to any dst-port 80 uid daemon 08382 620 743113 pipe 2 tcp from any 80 to any uid daemon 65000 6832 5040856 allow ip from any to any 65535 0 0 deny ip from any to any su-3.2# ipfw pipe show 00001: 1.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/ Byte Drp 0 tcp 64.237.55.83/49492 66.230.133.69/80 509 38156 0 0 0 00002: 1.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/ Byte Drp 0 tcp 66.230.133.69/80 64.237.55.83/49492 656 785292 1 1500 1 su-3.2# ipfw pipe show 00001: 1.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/ Byte Drp 0 tcp 64.237.55.83/49492 66.230.133.69/80 1247 98023 0 0 0 00002: 1.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/ Byte Drp 0 tcp 66.230.133.69/80 64.237.55.83/49492 1475 1453606 0 0 1 su-3.2# in this case i did specify mask for pipe, yet when I'm issuing ipfw pipe show I still don't see anything in terms of slots that being in use su-3.2# sysctl net.inet.ip.dummynet.pipe_slot_limit net.inet.ip.dummynet.pipe_slot_limit: 100 su-3.2# seems like at all time I see only 1 slot being utilized and as I mention before it never changes. > > MRTG sees all traffic on an interface, and your ipfw stats indicate at > least 25% more traffic than that due to your webserver, so it's not > clear how you could tell if your pipe was exceeding 2Mbit/s or not? > I obviously do have other traffic then www, but majority of it is www. but I see why you coming with this, so let me just give you an example. if I at peak time shutdown my apache, my traffic drops dramatically and by dramatically i mean at least 90% (and in most cases more) my traffic went to as much as 10mbps with supposedly limited pipe of 2mbps, when I set it to 1mbps it seems to be almost there... > Also, it's recommended not to run your inbound and outbound traffic > through the one pipe, unless simulating half-duplex connections; see > explanation in ipfw(8), EXAMPLES section under TRAFFIC SHAPING. i thought about that and as you suggested i did separate them into 2 separate pipes (see on top) > > : su-3.2# ipfw show > : 00100 1249368 205115325 allow ip from any to any via lo0 > : 00200 0 0 deny ip from any to 127.0.0.0/8 > : 00300 0 0 deny ip from 127.0.0.0/8 to any > : 08380 2838075 3586421013 pipe 1 tcp from any 80 to any uid daemon > : 08380 2097473 136454502 pipe 1 tcp from any to any dst-port 80 uid > daemon > : 65000 5740679 4716157064 allow ip from any to any > : 65535 0 0 deny ip from any to any > > 3.586 GiB outbound from the webserver (served data) > 0.136 GiB inbound to the webserver (requests, acks) > + --- > 3.722 GiB through the pipe. > but > 4.716 GiB passed from any to any, either way. > > So there's about 1 Gig of extra traffic shown here, assuming you have > net.inet.ip.fw.one_pass=0 and all traffic eventually hits rule 65000 > (and 4.7G extra traffic if net.inet.ip.fw.one_pass=1) but there's not > enough info to see whether or not it's on the interface MRTG watches? > > : su-3.2# ipfw pipe show > : 00001: 2.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail > : mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > : BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > : 0 tcp 64.237.55.83/59388 208.80.152.3/80 4936077 3723134341 0 0 > 30179 > > Total packets and bytes match the above, indicating that this was done > just after the ipfw show. 0.6% dropped packets indicates some > limiting > happening, but with a shared in/outbound pipe, not in which direction. > > If this is still an issue, please: > > . be more precise than "way more traffic" if you have more data? > . say whether the extra ~25% traffic shown is on the same interface > as the webserver, ie the interface MRTG monitors, or not? > . the value of sysctl net.inet.ip.fw.one_pass ? > > cheers, Ian > From chris at smartt.com Mon Oct 19 17:38:07 2009 From: chris at smartt.com (Chris St Denis) Date: Mon Oct 19 17:38:16 2009 Subject: ipfw: install_state: entry already present, done In-Reply-To: <20091017171148.T70724@sola.nimnet.asn.au> References: <4AC51F18.5050703@smartt.com> <4AC52918.2020705@smartt.com> <8d923f617db88c873c63bb2038752147.squirrel@users.sharktooth.org> <4ACF9341.2040406@smartt.com> <4AD8FDD0.30008@smartt.com> <20091017171148.T70724@sola.nimnet.asn.au> Message-ID: <4ADCA3FD.5080004@smartt.com> Interesting idea, but doesn't seem to help any :( I added it into the workstation set I had with it loading between the 127.0.0.1 rules and the check-state. Message didn't stop and "ipfw show" doesn't show anything hitting that rule. What "ipfw show" does show is a lot on the "allow tcp .... setup keep-state" and "allow udp .... keep-state" rules hitting all the packets (plus one each on 2 of the abuse ones farther down) I tried rolling back my sys/netinet/ip_fw2.c to the latest revision from 7.1 and that didn't help either, so I don't think it was a change to that file. Unless there is a kernel developer aroun who is more familiar with the network stack to fix this or point me in a better direction, I'll keep rolling back individual files trying to find which commit caused this. Ian Smith wrote: > On Fri, 16 Oct 2009, Chris St Denis wrote: > > > > This is definitely a regression in 7.2. > > > > Downgrades to 6.4, 7.0, 7.1 did not show this symptom. Upgrade the test > > server back to 7.2 and the messages come back. > > I notice neither your rules shown below nor the "workstation" rules - > unlike the "client" and "simple" rulesets - allow IP fragments to pass, > and I'm not sure what happens to frags that are associated with stateful > DNS rules. > > The only frags I usually see here are associated with DNS responses from > my forwarders, usually huge lists of NS for spamhaus.org that are almost > always fragmented (around 2Kbytes). > > You could maybe try a specific 'allow log all from any to any frag' ? > > Just a wild stab in the dark, > > cheers, Ian > > > Chris St Denis wrote: > > > check_state doesn't help. The error is also generated from the rc.conf > > > firewall_type="workstation" rule set which includes check_state among > > > several other rules. > > > > > > I made a copy of this server (it's a virtual server under WMware) and > > > downgraded it to 6.4-RELEASE-p7 and I no longer get the error. > > > > > > I downgraded another copy to 7.2-RELEASE (no patches) by copying the > > > generic kernel off the CD. Still gets errors. > > > > > > Downgraded it to 7.0-RELEASE and the message stopped. > > > > > > I'm going to try going to 7.1 and see which behavior it has. > > > > > > Looks like there may have been a regression in 7.2 (or maybe 7.1 pending > > > the results of my further testing) > > > > > > > > > Jason Lewis wrote: > > > > Did you try a check_state? I am using this same rule structure on BSD6 > > > > without a problem. > > > > > > > > Thanks, > > > > Jason > > > > http://jasonlewis.yaritz.net > > > > > > > > > > > > > Freddie Cash wrote: > > > > > > > > > > > On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Haven't gotten any response on -questions so trying here. I've also > > > > > > > opened > > > > > > > a PR (kern/139226) but it's gotten no replies so I figured I should > > > > > > > try > > > > > > > here > > > > > > > since I'm not certain if it's a bug or not. Regardless I am hoping > > > > > > > for > > > > > > > at > > > > > > > least a work-around -- a few extra rules or settings to keep my > > > > > > > console > > > > > > > from > > > > > > > being flooded by errors. So far only option I found is commenting > > > > > > > out > > > > > > > the > > > > > > > error display line in the kernel source which is far from optimal. > > > > > > > > > > > > > > I'm trying to setup a stateful firewall for my server such that any > > > > > > > traffic > > > > > > > can go out, and it's reply come back -- a fairly typical > > > > > > > workstation > > > > > > > setup. > > > > > > > However I'm getting the error message "ipfw: install_state: entry > > > > > > > already > > > > > > > present, done" repeated many times in my logs (tho the rules seemed > > > > > > > to > > > > > > > work > > > > > > > fine otherwise). > > > > > > > > > > > > > > I stripped down the rules to the minimum I could and discovered the > > > > > > > line > > > > > > > causing it is "allow udp from me to any keep-state". > > > > > > > > > > > > > > Only seems to happen when I have bind running as a slave dns server > > > > > > > (not > > > > > > > publicly listed, just the zone replication traffic causes the > > > > > > > error) > > > > > > > but I > > > > > > > assume any other large source of UDP traffic would also do it. > > > > > > > > > > > > > > Full firewall rules: > > > > > > > > > > > > > > dns2# ipfw list > > > > > > > 00100 allow ip from any to any via lo0 > > > > > > > 00200 deny ip from any to 127.0.0.0/8 > > > > > > > 00300 deny ip from 127.0.0.0/8 to any > > > > > > > 00400 allow udp from me to any keep-state > > > > > > > 65535 deny ip from any to any > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you add "out xmit em0" to the udp rule, do the errors stop > > > > > > > > > > > I added that and restarted bind (thus generating a bunch of UDP > > > > > traffic) > > > > > and the error still floods the console. > > > > > > > > > > Current rule set: > > > > > 00100 allow ip from any to any via lo0 > > > > > 00200 deny ip from any to 127.0.0.0/8 > > > > > 00300 deny ip from 127.0.0.0/8 to any > > > > > 00400 allow udp from me to any out xmit em0 keep-state > > > > > 00500 allow ip from any to any > > > > > 65535 deny ip from any to any > > > > > > > > > > _______________________________________________ > > > > > 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" > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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" > > > > > > > > > > > > > > > > -- > > Chris St Denis > > Programmer > > SmarttNet (www.smartt.com) > > Ph: 604-473-9700 Ext. 200 > > ------------------------------------------- > > "Smart Internet Solutions For Businesses" > > _______________________________________________ > > 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" > > > _______________________________________________ > 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" > -- Chris St Denis Programmer SmarttNet (www.smartt.com) Ph: 604-473-9700 Ext. 200 ------------------------------------------- "Smart Internet Solutions For Businesses" From PeterJ4ones at hotmail.co.uk Mon Oct 19 20:14:14 2009 From: PeterJ4ones at hotmail.co.uk (PeterJJ) Date: Mon Oct 19 20:14:20 2009 Subject: IPFW closing range of ports Message-ID: <25964869.post@talk.nabble.com> I'm new to this, so go easy please. I have put in place a very basic ipfw ruleset in my place of employment. To this i have been asked to block out all peer to peer sharing to ports in the range of 14500-65000. Is it doable? I am currently experiencing issues with users where I work running a music streaming service which at first runs from the free service's own servers, then starts running peer to peer. I am not allowed to block the application. I would like to as it is hogging bandwidth, but have been told I am not permitted. Is there anything I can do? The application will run with the peer to peer option disabled, relying only on the company's server, before eventually getting kicked off after an hour or so (but I don't care about that). Thank you all in advance -- View this message in context: http://www.nabble.com/IPFW-closing-range-of-ports-tp25964869p25964869.html Sent from the freebsd-ipfw mailing list archive at Nabble.com. From drinking.coffee at gmail.com Mon Oct 19 21:30:09 2009 From: drinking.coffee at gmail.com (Matthew Walker) Date: Mon Oct 19 21:30:15 2009 Subject: IPFW closing range of ports In-Reply-To: <25964869.post@talk.nabble.com> References: <25964869.post@talk.nabble.com> Message-ID: <4ADCD388.5040109@gmail.com> You could starve it by using a pipe, allocate 16 kbit/sec. Then technically you aren't blocking it. ipfw add 1000 pipe 10 tcp from any to any 14500-65535 out ipfw pipe 10 config bw 16k queue 100 mask dst-ip 0xff000000 Otherwise, you can block the ports: ipfw add 1000 deny tcp from any to any 14500-65535 out Depends on how much of a BOFH mood your are in that day. -- Matthew PeterJJ wrote: > I'm new to this, so go easy please. > > I have put in place a very basic ipfw ruleset in my place of employment. > To this i have been asked to block out all peer to peer sharing to ports in > the range of 14500-65000. > > From smithi at nimnet.asn.au Thu Oct 22 12:20:03 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Oct 22 12:20:20 2009 Subject: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth Message-ID: <200910221220.n9MCK2eC088858@freefall.freebsd.org> The following reply was made to PR kern/139581; it has been noted by GNATS. From: Ian Smith To: alexus Cc: bug-followup@FreeBSD.org, freebsd@alexus.org Subject: Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth Date: Thu, 22 Oct 2009 23:17:23 +1100 (EST) On Mon, 19 Oct 2009, alexus wrote: > new set of rules > pipe 1 config bw 1Mbit/s mask src-port www > pipe 2 config bw 1Mbit/s mask src-port www Wrong mask syntax entirely. You can see from your pipe masks as shown, it's taken as meaning no mask at all: > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 Anyway, masking pipes creates dynamic pipes per masked flow, each of which gets ALL of the specified bandwidth. If you want to limit total bandwidth to 1Mbit/s, you likely want to use dynamic queues instead. ipfw(8) is a precise reference, but very terse. Suggested reading: http://info.iet.unipi.it/~luigi/dummynet/ and especially the last link from that page: http://info.iet.unipi.it/~luigi/ip_dummynet/original.html for clear examples of sharing evenly a single link - though noting that page is outdated re the sysctls for dummynet, bridging etc. Still looking more like a usage issue than describing a bug, but: > > If this is still an issue, please: > > . say whether the extra ~25% traffic shown is on the same interface > > as the webserver, ie the interface MRTG monitors, or not? > > . the value of sysctl net.inet.ip.fw.one_pass ? cheers, Ian From bugmaster at FreeBSD.org Mon Oct 26 11:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 26 11:08:33 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200910261107.n9QB71cl043797@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth o kern/139226 ipfw [ipfw] install_state: entry already present, done o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 64 problems total. From dado at korolev-net.ru Tue Oct 27 07:57:34 2009 From: dado at korolev-net.ru (Evgenii Davidov) Date: Tue Oct 27 07:58:21 2009 Subject: dummynet cpu usage Message-ID: <20091027074022.GE88744@korolev-net.ru> Hello! sometimes i see "dummynet" process eating 50% of cpu, but not all the time, at the same values of pps and traffic, how can i help it maybe? my rules are: 00040 5684913 4633951201 queue tablearg ip from any to table(80) out via bge1 00050 147394453 116505899626 pipe tablearg ip from any to table(2) out via bge1 00070 36989671 23121793602 pipe 16 ip from table(16) to any in via bge1 00071 192817060 91846274165 pipe 5 ip from not table(16) to any in via bge1 i have about 164 pipes and queues thank you! -- Evgenii V Davidov From dado at korolev-net.ru Tue Oct 27 16:29:29 2009 From: dado at korolev-net.ru (Evgenii Davidov) Date: Tue Oct 27 16:29:35 2009 Subject: dummynet cpu usage In-Reply-To: <20091027074022.GE88744@korolev-net.ru> References: <20091027074022.GE88744@korolev-net.ru> Message-ID: <20091027162924.GF88744@korolev-net.ru> ????????????, and i forgot to say -- on freebsd 6 it worked fine with same config, problem appeared on 7.2-STABLE, i've upgraded to use IPFIREWALL_NAT On Tue, Oct 27, 2009 at 10:40:22AM +0300, Evgenii Davidov ?????: > > Hello! > > sometimes i see "dummynet" process eating 50% of cpu, but not all the time, at the same values of pps and traffic, how can i help it maybe? > > my rules are: > > 00040 5684913 4633951201 queue tablearg ip from any to table(80) out via bge1 > 00050 147394453 116505899626 pipe tablearg ip from any to table(2) out via bge1 > 00070 36989671 23121793602 pipe 16 ip from table(16) to any in via bge1 > 00071 192817060 91846274165 pipe 5 ip from not table(16) to any in via bge1 > > i have about 164 pipes and queues > > thank you! > > -- > Evgenii V Davidov > _______________________________________________ > 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" -- Evgenii V Davidov