From plaxo at mx.plaxo.com Fri Jul 3 20:16:36 2009 From: plaxo at mx.plaxo.com (Jean Dupre) Date: Fri Jul 3 20:17:16 2009 Subject: =?utf-8?q?Jean_Dupre_a_partag=C3=A9_un_message_avec_vous_sur_Pul?= =?utf-8?q?se?= Message-ID: <3dba5d00b7617e2086f8fb5e706bfcd1@xpertmailer.com> Jean Dupre a partagé un message avec vous sur Pulse et souhaitait vous le faire savoir. http://www.plaxo.com/public/event/189178955319?src=email&et=6&el=fr_o1&key=70634ecb3f154d61ab941ea5fed30e573283e72f&email=freebsd-ipfw%40freebsd.org&share_id=4662473&share_key=1973782934&name=&webmailfix=1&lang=fr Besoin de prêt ? Bonjour, Je suis DUPRE JEAN ALBERT. Ancien thérapeute, financier suisse et Directeur d’étude de projets dans une banque. J'octroie des prêts à toute personne désireuse selon les critères suivants: Choix du montant : à partir de 15.000 € Choix de la durée de remboursement : 8 ans maximum TEG annuel fixe : 2,15%* (*offre soumise à condition) En option : l’assurance e... http://www.plaxo.com/public/event/189178955319?src=email&et=6&el=fr_o1&key=70634ecb3f154d61ab941ea5fed30e573283e72f&email=freebsd-ipfw%40freebsd.org&share_id=4662473&share_key=1973782934&name=&webmailfix=1&lang=fr Merci ! L'équipe Plaxo Plus de 20 millions de personnes utilisent Plaxo pour rester en contact avec leur entourage dans le cadre privé comme professionnel. Vous ne voulez plus recevoir d'e-mails de Plaxo ? Rendez-vous sur : http://www.plaxo.com/stop?src=email&et=6&el=fr_o1&email=freebsd-ipfw%40freebsd.org From update+kju~w1md at facebookmail.com Sat Jul 4 21:40:16 2009 From: update+kju~w1md at facebookmail.com (Facebook) Date: Sat Jul 4 21:40:23 2009 Subject: Reminder: Michael invited you to join Facebook... Message-ID: ======================================= To sign up for Facebook, follow the link below: http://www.facebook.com/r.php?re=99d4e672e080ba96cc0d0e79dab01e38&mid=b9c5e8G41d79197G44b6a8G46 ======================================= Hi Ipfw, The following person recently invited you to be their friend on Facebook: Michael Sierchio Other people you may know on Facebook: Lynn Strough (East Bay, CA) Ishara Hudson (Santa Cruz, CA) Ericka Lutz (East Bay, CA) Gina Podesta Danny Santos (Berkeley) Helga Veideman (San Francisco, CA) Facebook is a great place to keep in touch with friends, post photos, videos and create events. But first you need to join! Sign up today to create a profile and connect with the people you know. Thanks, The Facebook Team To sign up for Facebook, follow the link below: http://www.facebook.com/r.php?re=99d4e672e080ba96cc0d0e79dab01e38&mid=b9c5e8G41d79197G44b6a8G46 ======================================= This message was intended for ipfw@freebsd.org. If you do not wish to receive this type of email from Facebook in the future, please click on the link below to unsubscribe. http://www.facebook.com/o.php?c&k=86cbe6&u=1104646551&mid=b9c5e8G41d79197G44b6a8G46 Facebook's offices are located at 1601 S. California Ave., Palo Alto, CA 94304. From freealson at gmail.com Mon Jul 6 06:46:37 2009 From: freealson at gmail.com (Alson Black) Date: Mon Jul 6 06:46:44 2009 Subject: freebsd-ipfw Digest, Vol 323, Issue 4 In-Reply-To: <20090705120023.8845410656D4@hub.freebsd.org> References: <20090705120023.8845410656D4@hub.freebsd.org> Message-ID: Nice message ever got... On Sun, Jul 5, 2009 at 8:00 PM, wrote: > Send freebsd-ipfw mailing list submissions to > freebsd-ipfw@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > or, via email, send a message with subject or body 'help' to > freebsd-ipfw-request@freebsd.org > > You can reach the person managing the list at > freebsd-ipfw-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-ipfw digest..." > > > Today's Topics: > > 1. Reminder: Michael invited you to join Facebook... (Facebook) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 4 Jul 2009 14:25:14 -0700 > From: Facebook > Subject: Reminder: Michael invited you to join Facebook... > To: Ipfw > Message-ID: > Content-Type: text/plain; charset = "UTF-8" > > ======================================= > To sign up for Facebook, follow the link below: > > http://www.facebook.com/r.php?re=99d4e672e080ba96cc0d0e79dab01e38&mid=b9c5e8G41d79197G44b6a8G46 > ======================================= > > Hi Ipfw, > > The following person recently invited you to be their friend on Facebook: > > Michael Sierchio > > > Other people you may know on Facebook: > Lynn Strough (East Bay, CA) > Ishara Hudson (Santa Cruz, CA) > Ericka Lutz (East Bay, CA) > Gina Podesta > Danny Santos (Berkeley) > Helga Veideman (San Francisco, CA) > > > Facebook is a great place to keep in touch with friends, post photos, > videos and create events. But first you need to join! Sign up today to > create a profile and connect with the people you know. > > Thanks, > The Facebook Team > > To sign up for Facebook, follow the link below: > > http://www.facebook.com/r.php?re=99d4e672e080ba96cc0d0e79dab01e38&mid=b9c5e8G41d79197G44b6a8G46 > > ======================================= > This message was intended for ipfw@freebsd.org. If you do not wish to > receive this type of email from Facebook in the future, please click on the > link below to unsubscribe. > > http://www.facebook.com/o.php?c&k=86cbe6&u=1104646551&mid=b9c5e8G41d79197G44b6a8G46 > Facebook's offices are located at 1601 S. California Ave., Palo Alto, CA > 94304. > > > > ------------------------------ > > _______________________________________________ > 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" > > End of freebsd-ipfw Digest, Vol 323, Issue 4 > ******************************************** > From kim.attree at playsafesa.com Mon Jul 6 08:35:40 2009 From: kim.attree at playsafesa.com (Kim Attree) Date: Mon Jul 6 08:35:47 2009 Subject: Problem with source based policy routing Message-ID: <00265389C30B444288C246DF37651D0C37637A1893@server-02.playsafesa.com> Hey Guys, I'm having a problem with source-based policy routing in IPFW, I'm trying to run a load-balanced SMTP System over two links. Primary link is re0, lets give it an ip of 192.168.1.1 Secondary link is re1, with an ip of 192.168.2.1 Default gateway for the box is 192.168.1.254 (so ALL outgoing traffic goes out of re0, unless hardcoded into the routing table for destinations instead) Default gateway for re1 is 192.168.2.254 I want re1 to be able to accept SMTP, but respond to the originating IP over the same link re1 (instead of the default gateway). With this in mind, I setup my NAT accordingly: port 8669 alias_address 192.168.2.1 same_ports yes use_sockets yes log_ipfw_denied yes redirect_port tcp 10.0.0.1:25 192.168.2.1:25 And the IPFW rules such: # NATD Statements add 00097 divert 8668 all from any to any via re0 add 00097 divert 8669 all from any to any via re1 # Testing incoming SMTP over re1 add 00098 skipto 00100 tcp from any to not 192.168.2.1 add 00099 fwd 192.168.2.254 tcp from any to any Tcpdump shows packets coming in: #>Tcpdump -n -i re1 port 25 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on re1, link-type EN10MB (Ethernet), capture size 96 bytes 11:15:41.594659 IP xxx.xxx.xxx.xxx.2097 > 192.168.2.1.25: S 842708044:842708044(0) win 65535 11:15:44.596798 IP xxx.xxx.xxx.xxx.2097 > 192.168.2.1.25: S 842708044:842708044(0) win 65535 11:15:50.617271 IP xxx.xxx.xxx.xxx.2097 > 192.168.2.1.25: S 842708044:842708044(0) win 65535 ^C 3 packets captured 566 packets received by filter 0 packets dropped by kernel But nothing going out: What am I doing wrong ??? From bugmaster at FreeBSD.org Mon Jul 6 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 6 11:08:35 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200907061107.n66B70oE010812@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/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 59 problems total. From dev+lists at humph.com Mon Jul 6 13:33:59 2009 From: dev+lists at humph.com (Giuliano Gavazzi) Date: Mon Jul 6 13:34:07 2009 Subject: Problem with source based policy routing In-Reply-To: <00265389C30B444288C246DF37651D0C37637A1893@server-02.playsafesa.com> References: <00265389C30B444288C246DF37651D0C37637A1893@server-02.playsafesa.com> Message-ID: On M 6 Jul, 2009, at 10:36 , Kim Attree wrote: > > Hey Guys, > > > > I'm having a problem with source-based policy routing in IPFW, I'm > trying to run a load-balanced SMTP System over two links. > > Primary link is re0, lets give it an ip of 192.168.1.1 > Secondary link is re1, with an ip of 192.168.2.1 > > Default gateway for the box is 192.168.1.254 (so ALL outgoing > traffic goes out of re0, unless hardcoded into the routing table for > destinations instead) > Default gateway for re1 is 192.168.2.254 > > I want re1 to be able to accept SMTP, but respond to the originating > IP over the same link re1 (instead of the default gateway). > With this in mind, I setup my NAT accordingly: > > > port 8669 > alias_address 192.168.2.1 > same_ports yes > use_sockets yes > log_ipfw_denied yes > redirect_port tcp 10.0.0.1:25 192.168.2.1:25 > > > And the IPFW rules such: > > > # NATD Statements > add 00097 divert 8668 all from any to any via re0 > add 00097 divert 8669 all from any to any via re1 > why NAT? Unless you also want to spread outgoing traffic from internal hosts, presumably based on dest port or network, then NAT is of no use (except the one via re0 that is presumably used for internal hosts). Incoming packets don't need any rules as the gw 192.168.2.254 knows how to reach your host, you only need to fwd (that is to route) your outgoing packets according to the source. I have a similar setup (with also 2 NATs because I do use both gateways also for natted hosts). The fwd rule would be very early, just after the loopback rules, UNLESS you want to block outgoing traffic on some ports: add 50 fwd 192.168.2.254 src-ip 192.168.2.1 not dst-ip 192.168.2.1/24 That should do it. NOTE: if you also do NAT on that port (re1), then you need this also after the corresponding nat rule. But I urge you to distinguish between necessarily natted traffic (that is traffic coming from internal hosts) and traffic coming from the host itself, by using an alias on the same subnet (say 192.168.2.2) for the natted traffic. This way you avoid natting traffic that does not need it, and can easily distinguish between incoming traffic for your host (192.168.2.1) and for natted hosts (192.168.2.2). Giuliano From kim.attree at playsafesa.com Mon Jul 6 13:34:39 2009 From: kim.attree at playsafesa.com (Kim Attree) Date: Mon Jul 6 13:34:49 2009 Subject: Problem with source based policy routing In-Reply-To: References: <00265389C30B444288C246DF37651D0C37637A1893@server-02.playsafesa.com> Message-ID: <00265389C30B444288C246DF37651D0C37698F3933@server-02.playsafesa.com> > -----Original Message----- > From: Giuliano Gavazzi [mailto:dev+lists@humph.com] > Sent: 06 July 2009 03:13 PM > To: Kim Attree > Cc: freebsd-ipfw@freebsd.org > Subject: Re: Problem with source based policy routing > > > On M 6 Jul, 2009, at 10:36 , Kim Attree wrote: > > > > > Hey Guys, > > > > > > > > I'm having a problem with source-based policy routing in IPFW, I'm > > trying to run a load-balanced SMTP System over two links. > > > > Primary link is re0, lets give it an ip of 192.168.1.1 > > Secondary link is re1, with an ip of 192.168.2.1 > > > > Default gateway for the box is 192.168.1.254 (so ALL outgoing > > traffic goes out of re0, unless hardcoded into the routing table for > > destinations instead) > > Default gateway for re1 is 192.168.2.254 > > > > I want re1 to be able to accept SMTP, but respond to the originating > > IP over the same link re1 (instead of the default gateway). > > With this in mind, I setup my NAT accordingly: > > > > > > port 8669 > > alias_address 192.168.2.1 > > same_ports yes > > use_sockets yes > > log_ipfw_denied yes > > redirect_port tcp 10.0.0.1:25 192.168.2.1:25 > > > > > > And the IPFW rules such: > > > > > > # NATD Statements > > add 00097 divert 8668 all from any to any via re0 > > add 00097 divert 8669 all from any to any via re1 > > > > why NAT? Unless you also want to spread outgoing traffic from internal > hosts, presumably based on dest port or network, then NAT is of no use > (except the one via re0 that is presumably used for internal hosts). > Incoming packets don't need any rules as the gw 192.168.2.254 knows > how to reach your host, you only need to fwd (that is to route) your > outgoing packets according to the source. I have a similar setup (with > also 2 NATs because I do use both gateways also for natted hosts). I have one Internal Exchange server (don't laugh), and NAT handles the static mapping of IP/Port to that server. The original point here is to have two mapped NAT port 25's to the same internal Mail server, hence the addition of the NAT before and during the forward logic (obviously wrong though). > The fwd rule would be very early, just after the loopback rules, > UNLESS you want to block outgoing traffic on some ports: > > add 50 fwd 192.168.2.254 src-ip 192.168.2.1 not dst-ip 192.168.2.1/24 > > That should do it. Because the incoming traffic traverses NAT, this wont work: 192.168.2.254 --> 192.168.2.1(NAT:25) --> 10.0.0.1:25 --> 192.168.2.1(NAT) --> 192.168.2.254 --> World The forward ends firewall rule processing, meaning the traffic can not carry on outbound by my logic. > NOTE: if you also do NAT on that port (re1), then you need this also > after the corresponding nat rule. > But I urge you to distinguish between necessarily natted traffic (that > is traffic coming from internal hosts) and traffic coming from the > host itself, by using an alias on the same subnet (say 192.168.2.2) > for the natted traffic. This way you avoid natting traffic that does > not need it, and can easily distinguish between incoming traffic for > your host (192.168.2.1) and for natted hosts (192.168.2.2). > > > Giuliano Thanks for your assistance, any further help would be greatly appreciated !!! Kim From dev+lists at humph.com Mon Jul 6 16:53:47 2009 From: dev+lists at humph.com (Giuliano Gavazzi) Date: Mon Jul 6 16:53:54 2009 Subject: Problem with source based policy routing In-Reply-To: <00265389C30B444288C246DF37651D0C37698F3933@server-02.playsafesa.com> References: <00265389C30B444288C246DF37651D0C37637A1893@server-02.playsafesa.com> <00265389C30B444288C246DF37651D0C37698F3933@server-02.playsafesa.com> Message-ID: On M 6 Jul, 2009, at 15:35 , Kim Attree wrote: > I have one Internal Exchange server (don't laugh), and NAT handles > the static mapping of IP/Port to that server. The original point > here is to have two mapped NAT port 25's to the same internal Mail > server, hence the addition of the NAT before and during the forward > logic (obviously wrong though). > ah, if you want to have an internal server to be reachable on both public addresses, via the corresponding two firewall interfaces, you must have a way to tell the firewall how to distinguish the return packets in order to use the correct natd instance. If the internal exchange server port is the same, there is no way telling that. At most you could use the peer port, but even that would not be failproof, and I would not know how to proceed (I think dynamic rules can only establish holes - allow action - in the firewall, not a fwd action). So you must use two different ports or alias addresses on the exchange server, and divert to the appropriate outgoing natd instance on the basis of that. I have not enough time at the moment to write down a complete workflow, but I hope this, with the remarks in my previous post, gives you enough hints. Giuliano From kim.attree at playsafesa.com Tue Jul 7 07:19:52 2009 From: kim.attree at playsafesa.com (Kim Attree) Date: Tue Jul 7 07:19:59 2009 Subject: Problem with source based policy routing In-Reply-To: References: <00265389C30B444288C246DF37651D0C37637A1893@server-02.playsafesa.com> <00265389C30B444288C246DF37651D0C37698F3933@server-02.playsafesa.com> Message-ID: <00265389C30B444288C246DF37651D0C37698F395A@server-02.playsafesa.com> > -----Original Message----- > From: Giuliano Gavazzi [mailto:dev+lists@humph.com] > Sent: 06 July 2009 06:54 PM > To: Kim Attree > Cc: freebsd-ipfw@freebsd.org > Subject: Re: Problem with source based policy routing > > > On M 6 Jul, 2009, at 15:35 , Kim Attree wrote: > > > I have one Internal Exchange server (don't laugh), and NAT handles > > the static mapping of IP/Port to that server. The original point > > here is to have two mapped NAT port 25's to the same internal Mail > > server, hence the addition of the NAT before and during the forward > > logic (obviously wrong though). > > > > > ah, if you want to have an internal server to be reachable on both > public addresses, via the corresponding two firewall interfaces, you > must have a way to tell the firewall how to distinguish the return > packets in order to use the correct natd instance. If the internal > exchange server port is the same, there is no way telling that. At > most you could use the peer port, but even that would not be > failproof, and I would not know how to proceed (I think dynamic rules > can only establish holes - allow action - in the firewall, not a fwd > action). So you must use two different ports or alias addresses on the > exchange server, and divert to the appropriate outgoing natd instance > on the basis of that. > > I have not enough time at the moment to write down a complete > workflow, but I hope this, with the remarks in my previous post, gives > you enough hints. It has, I realised that the return traffic needs differing source IP's - I've added another IP and SMTP Connector to exchange and will test the theory out today. > > Giuliano Thanks, Kim From beastie24 at gmail.com Wed Jul 8 07:57:20 2009 From: beastie24 at gmail.com (Beastie) Date: Wed Jul 8 07:57:26 2009 Subject: ipfw nat proxy rules Message-ID: <1b1e1dee0907080036n1c854a4aoaca54a74a410029@mail.gmail.com> Hi list. I would like to put a question about ipfw nat proxy rules. man page say's that there is "proxy_only" rule available. I know that ipfw nat use the same libalias like natd do. man page por natd say that we can use "proxy_rule" to define proxing settings, but I do not see this option in ipfw nat man page. Is proxing is implemented in ipfw nat? How to use it (is "proxy_rule" available)? Thanks. From nicolas-2009 at rachinsky.de Sun Jul 12 17:00:04 2009 From: nicolas-2009 at rachinsky.de (Nicolas Rachinsky) Date: Sun Jul 12 17:00:11 2009 Subject: kern/112561: [ipfw] ipfw fwd does not work with some TCP packets Message-ID: <200907121700.n6CH035U059284@freefall.freebsd.org> The following reply was made to PR kern/112561; it has been noted by GNATS. From: Nicolas Rachinsky To: bug-followup@FreeBSD.org, myz@csu.ru Cc: Subject: Re: kern/112561: [ipfw] ipfw fwd does not work with some TCP packets Date: Sun, 12 Jul 2009 18:38:44 +0200 Hallo, this might be solved by the patch in kern/136695. Nicolas From bugmaster at FreeBSD.org Mon Jul 13 11:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 13 11:08:41 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200907131106.n6DB6uld040646@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/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 59 problems total. From bz at FreeBSD.org Tue Jul 14 08:12:47 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Tue Jul 14 08:12:53 2009 Subject: kern/136695: [ipfw] [patch] fwd reached after skipto in dynamic rules does not work in every case Message-ID: <200907140812.n6E8CkPX076050@freefall.freebsd.org> Old Synopsis: [ip] [patch] fwd reached after skipto in dynamic rules does not work in every case New Synopsis: [ipfw] [patch] fwd reached after skipto in dynamic rules does not work in every case Responsible-Changed-From-To: freebsd-net->freebsd-ipfw Responsible-Changed-By: bz Responsible-Changed-When: Tue Jul 14 08:12:22 UTC 2009 Responsible-Changed-Why: Re-assign to the right list. http://www.freebsd.org/cgi/query-pr.cgi?pr=136695 From dhorvay at 4whitetiger.com Tue Jul 14 20:17:06 2009 From: dhorvay at 4whitetiger.com (David A. Horvay - MRINetwork ) Date: Tue Jul 14 20:17:24 2009 Subject: Atheros wireless device driver developer Message-ID: <80CE6EE175AE42CC96E6C14733FA58C3@scmedina17> Hello Everyone, I have an opportunity for a device driver developer with a heavy wireless Atheros background. Please let me know if anyone is interested or might know someone. Please see job description below. Thank you very much.... -Dave Senior Software Engineer with WLAN Device Driver Development Experience The ideal candidate will have several years of communication experience as well as experience programming low level hardware drivers. Requirements: * BSCS or BSEE or relevant experience * 5+ years of experience in development of WLAN device drivers * Fluency in coding and debugging C * Experience with Atheros drivers a plus * Expertise in one or more of these protocols: ? 802.11 ? ATM ? Sonet/SDH ? NDIS ? Bluetooth ? Ethernet, GBit Ethernet * Experience with one or more of the following operating systems: ? MS Windows, WinCE ? Linux ? Embedded RTOS David A. Horvay Sr. Account Executive Technology Solutions Division MRINetwork Ultimate Placements, LLC One Park Centre Drive, Suite 305A TF:877-334-0285 ext. 202 dhorvay@4whitetiger.com http://www.linkedin.com/in/davidhorvay www.MRINetwork.com BUILDING THE HEART OF BUSINESS (TM) Please understand my mission at MRI Ultimate Placements is to partner with those select clients where there is a philosophical fit. My goal has never been to be all things to all people. ?As a client-focused search consultant I evaluate each potential assignment based on alignment with my area of expertise and the timing and urgency of each search.? From dima_bsd at inbox.lv Tue Jul 14 21:55:41 2009 From: dima_bsd at inbox.lv (Dmitriy Demidov) Date: Tue Jul 14 21:55:49 2009 Subject: ipfw nat and localy initiated UDP traffic Message-ID: <200907142355.34973.dima_bsd@inbox.lv> Hi list. I have a problems with ipfw nat. It makes me crazy (I realy have no idea how to troubleshoot this problem). Looks like ipfw nat do not pass through itself localy initiated UDP traffic! Is there any hint that I do not know about ipfw nat? Any clue please :( ipfw configuration: (fxp0 - is local network, and em0 is ISP side) === add allow ip from any to any via fxp0 add allow udp from any 68 to any 67 add allow udp from any 67 to any 68 nat 1 config log if em0 reset same_ports deny_in add nat 1 all from any to any via em0 === When I start nslookup and do queue from NAT machine, I got: === (tcpdump on em0) 23:24:10.591959 IP (tos 0x0, ttl 64, id 2646, offset 0, flags [none], proto UDP (17), length 64) 87.110.118.70.52697 > 91.198.156.20.53: 58731+ A? forums.freebsd.org. (36) 23:24:15.591009 IP (tos 0x0, ttl 64, id 2647, offset 0, flags [none], proto UDP (17), length 64) 87.110.118.70.52697 > 91.198.156.20.53: 58731+ A? forums.freebsd.org. (36) 23:24:20.591563 IP (tos 0x0, ttl 64, id 2674, offset 0, flags [none], proto UDP (17), length 64) 87.110.118.70.52697 > 91.198.156.20.53: 58731+ A? forums.freebsd.org. (36) (nslookup) > server Default server: 91.198.156.20 Address: 91.198.156.20#53 > forums.freebsd.org. ;; connection timed out; no servers could be reached === In the same time, if I make a queue from machine that is in 192.168.1.0/24 network (behind nat) I got correct result: === (tcpdump on em0) 23:24:59.360796 IP (tos 0x0, ttl 63, id 581, offset 0, flags [none], proto UDP (17), length 64) 87.110.118.70.61735 > 91.198.156.20.53: 16871+ A? forums.freebsd.org. (36) 23:25:01.052611 IP (tos 0x0, ttl 60, id 49380, offset 0, flags [none], proto UDP (17), length 224) 91.198.156.20.53 > 87.110.118.70.61735: 16871 2/3/3 forums.freebsd.org. CNAME[|domain] (nslookup) > server Default server: 91.198.156.20 Address: 91.198.156.20#53 > forums.freebsd.org. Server: 91.198.156.20 Address: 91.198.156.20#53 Non-authoritative answer: forums.freebsd.org canonical name = freebsd-forums.liquidneon.com. Name: freebsd-forums.liquidneon.com Address: 149.20.54.209 === On NAT machine I'm using FreeBSD 7.2-STABLE (FreeBSD 7.2-STABLE #0: Wed Jun 24 12:59:06 EEST 2009 i386). GENERIC kernel with extra options: === options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=10 options IPFIREWALL_NAT options LIBALIAS options DUMMYNET options HZ="1000" device vlan === From kim.attree at playsafesa.com Thu Jul 16 10:11:55 2009 From: kim.attree at playsafesa.com (Kim Attree) Date: Thu Jul 16 10:12:02 2009 Subject: Problem with source based policy routing In-Reply-To: <00265389C30B444288C246DF37651D0C37698F395A@server-02.playsafesa.com> References: <00265389C30B444288C246DF37651D0C37637A1893@server-02.playsafesa.com> <00265389C30B444288C246DF37651D0C37698F3933@server-02.playsafesa.com> <00265389C30B444288C246DF37651D0C37698F395A@server-02.playsafesa.com> Message-ID: <00265389C30B444288C246DF37651D0C37970A1028@server-02.playsafesa.com> > -----Original Message----- > From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd- > ipfw@freebsd.org] On Behalf Of Kim Attree > Sent: 07 July 2009 09:21 AM > To: Giuliano Gavazzi > Cc: freebsd-ipfw@freebsd.org > Subject: RE: Problem with source based policy routing > > > -----Original Message----- > > From: Giuliano Gavazzi [mailto:dev+lists@humph.com] > > Sent: 06 July 2009 06:54 PM > > To: Kim Attree > > Cc: freebsd-ipfw@freebsd.org > > Subject: Re: Problem with source based policy routing > > > > > > On M 6 Jul, 2009, at 15:35 , Kim Attree wrote: > > > > > I have one Internal Exchange server (don't laugh), and NAT handles > > > the static mapping of IP/Port to that server. The original point > > > here is to have two mapped NAT port 25's to the same internal Mail > > > server, hence the addition of the NAT before and during the forward > > > logic (obviously wrong though). > > > > > > > > > ah, if you want to have an internal server to be reachable on both > > public addresses, via the corresponding two firewall interfaces, you > > must have a way to tell the firewall how to distinguish the return > > packets in order to use the correct natd instance. If the internal > > exchange server port is the same, there is no way telling that. At > > most you could use the peer port, but even that would not be > > failproof, and I would not know how to proceed (I think dynamic rules > > can only establish holes - allow action - in the firewall, not a fwd > > action). So you must use two different ports or alias addresses on > the > > exchange server, and divert to the appropriate outgoing natd instance > > on the basis of that. > > > > I have not enough time at the moment to write down a complete > > workflow, but I hope this, with the remarks in my previous post, > gives > > you enough hints. > > It has, I realised that the return traffic needs differing source IP's > - I've added another IP and SMTP Connector to exchange and will test > the theory out today. SUCCESS !!!!! I setup the Microsoft server to have a second SMTP connector on 10.0.0.2:588 NATD setup as follows: port 8669 alias_address 192.168.2.1 same_ports yes use_sockets yes log_ipfw_denied yes redirect_port tcp 10.0.0.2:588 192.168.2.1:25 Then, in IPFW: (Making sure packets hit the NAT first...:) add 00079 divert 8669 all from any to any via re1 add 00080 skipto 00082 all from 10.0.0.2 to 10.0.0.0/20 add 00080 skipto 00082 all from not 10.0.0.2 to any add 00081 fwd 192.168.2.254 all from 10.0.0.2 to any And a quick test from an outside server 12000 miles away: [root@bubbles ~]# telnet 192.168.2.1 25 Trying 192.168.2.1... Connected to 192.168.2.1. Escape character is '^]'. 220 xxx.xxx.com Microsoft ESMTP MAIL Service ready at Thu, 16 Jul 2009 12:10:51 +0200 quit 221 2.0.0 Service closing transmission channel Connection closed by foreign host. Thanks again Giuliano !!! Kim Attree > > > > > > Giuliano > > Thanks, > > Kim > _______________________________________________ > 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 dima_bsd at inbox.lv Thu Jul 16 19:19:09 2009 From: dima_bsd at inbox.lv (Dmitriy Demidov) Date: Thu Jul 16 19:19:16 2009 Subject: ipfw nat and localy initiated UDP traffic (bad udp cksum) In-Reply-To: <200907142355.34973.dima_bsd@inbox.lv> References: <200907142355.34973.dima_bsd@inbox.lv> Message-ID: <200907162219.04986.dima_bsd@inbox.lv> On Tuesday 14 July 2009, Dmitriy Demidov wrote: > Hi list. > > I have a problems with ipfw nat. It makes me crazy (I realy have no idea > how to troubleshoot this problem). Looks like ipfw nat do not pass through > itself localy initiated UDP traffic! Is there any hint that I do not know > about ipfw nat? Any clue please :( > Update about this issue. There is somthing wrong with UDP pass through - ipfw nat makes it "bad cksum". tcpdump on ISP-side nic (tcpdump -i 2 -X -vvv -n -l ip) shows this: for localy initiated UDP/DNS trafic: ==== 21:58:30.116680 IP (tos 0x0, ttl 64, id 6212, offset 0, flags [none], proto UDP (17), length 61) 87.110.108.74.62365 > 91.198.156.20.53: [bad udp cksum aa89!] 50277+ A? www.freebsd.org. (33) 0x0000: 4500 003d 1844 0000 4011 a6d9 576e 6c4a E..=.D..@...WnlJ 0x0010: 5bc6 9c14 f39d 0035 0029 bbcd c465 0100 [......5.)...e.. 0x0020: 0001 0000 0000 0000 0377 7777 0766 7265 .........www.fre 0x0030: 6562 7364 036f 7267 0000 0100 01 ebsd.org..... 21:58:35.116809 IP (tos 0x0, ttl 64, id 6239, offset 0, flags [none], proto UDP (17), length 61) 87.110.108.74.62365 > 91.198.156.20.53: [bad udp cksum aa89!] 50277+ A? www.freebsd.org. (33) 0x0000: 4500 003d 185f 0000 4011 a6be 576e 6c4a E..=._..@...WnlJ 0x0010: 5bc6 9c14 f39d 0035 0029 bbcd c465 0100 [......5.)...e.. 0x0020: 0001 0000 0000 0000 0377 7777 0766 7265 .........www.fre 0x0030: 6562 7364 036f 7267 0000 0100 01 ebsd.org..... 21:58:40.117744 IP (tos 0x0, ttl 64, id 6240, offset 0, flags [none], proto UDP (17), length 61) 87.110.108.74.62365 > 91.198.156.20.53: [bad udp cksum ==== for UDP/DNS trafic that pass via nat from local network: ==== 21:58:21.925741 IP (tos 0x0, ttl 63, id 632, offset 0, flags [none], proto UDP (17), length 61) 87.110.108.74.58124 > 91.198.156.20.53: [udp sum ok] 36465+ A? www.freebsd.org. (33) 0x0000: 4500 003d 0278 0000 3f11 bda5 576e 6c4a E..=.x..?...WnlJ 0x0010: 5bc6 9c14 e30c 0035 0029 8bfd 8e71 0100 [......5.)...q.. 0x0020: 0001 0000 0000 0000 0377 7777 0766 7265 .........www.fre 0x0030: 6562 7364 036f 7267 0000 0100 01 ebsd.org..... 21:58:21.932623 IP (tos 0x0, ttl 59, id 39585, offset 0, flags [none], proto UDP (17), length 165) 91.198.156.20.53 > 87.110.108.74.58124: 36465 q: A? www.freebsd.org. 1/3/0 www.freebsd.org. A 69.147.83.33 ns: freebsd.org.[| domain] 0x0000: 4500 00a5 9aa1 0000 3b11 2914 5bc6 9c14 E.......;.).[... 0x0010: 576e 6c4a 0035 e30c 0091 8f66 8e71 8180 WnlJ.5.....f.q.. 0x0020: 0001 0001 0003 0000 0377 7777 0766 7265 .........www.fre 0x0030: 6562 7364 036f 7267 0000 0100 01c0 0c00 ebsd.org........ 0x0040: 0100 0100 000b 6600 0445 9353 21c0 1000 ......f..E.S!... 0x0050: 0200 .. ==== ipfw config: ==== add allow ip from any to any via fxp0 add allow udp from any 68 to any 67 add allow udp from any 67 to any 68 add count ip from any to any nat 1 config log if em0 reset same_ports deny_in nat 2 config log if em0 nat 3 config log if em0 reset same_ports deny_in add count ip from any to any add nat 1 tcp from any to any out xmit em0 add nat 2 udp from any to any out xmit em0 add nat 3 icmp from any to any out xmit em0 add nat 1 tcp from any to me in recv em0 add nat 2 udp from any to me in recv em0 add nat 3 icmp from any to me in recv em0 add count ip from any to any ==== ipfw show ==== 00100 1642 372640 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 00400 9 990 allow ip from any to any via fxp0 00500 0 0 allow udp from any 68 to any dst-port 67 00600 0 0 allow udp from any 67 to any dst-port 68 00700 25 1404 count ip from any to any 00800 25 1404 count ip from any to any 00900 0 0 nat 1 tcp from any to any out xmit em0 01000 7 427 nat 2 udp from any to any out xmit em0 01100 0 0 nat 3 icmp from any to any out xmit em0 01200 17 812 nat 1 tcp from any to me in recv em0 01300 1 165 nat 2 udp from any to me in recv em0 01400 0 0 nat 3 icmp from any to me in recv em0 01500 0 0 count ip from any to any 65535 3 520 deny ip from any to any ==== uname -a FreeBSD hius.local.home 7.2-STABLE FreeBSD 7.2-STABLE #0: Wed Jul 15 20:59:17 EEST 2009 root@hius.local.home:/usr/obj/usr/src/sys/STABLE i386 From dima_bsd at inbox.lv Thu Jul 16 19:50:54 2009 From: dima_bsd at inbox.lv (Dmitriy Demidov) Date: Thu Jul 16 19:51:01 2009 Subject: ipfw nat and localy initiated UDP traffic (bad udp cksum) In-Reply-To: <2CE3CD12-D430-4378-92C1-591227888428@mac.com> References: <200907142355.34973.dima_bsd@inbox.lv> <200907162219.04986.dima_bsd@inbox.lv> <2CE3CD12-D430-4378-92C1-591227888428@mac.com> Message-ID: <200907162250.51585.dima_bsd@inbox.lv> On Thursday 16 July 2009, Chuck Swiger wrote: > On Jul 16, 2009, at 12:19 PM, Dmitriy Demidov wrote: > > Update about this issue. > > There is somthing wrong with UDP pass through - ipfw nat makes it > > "bad cksum". > > tcpdump receives local network traffic before the checksums are > computed (especially if hardware checksums are enabled); this is a non- > issue, although you could confirm by sniffing the traffic from an > external machine like a laptop. > > Regards, Wow! :) Thank you Chuck for this hint! I catch the problem! My em0 have offload options on, so I turned them off and now all is working as expected. before: === em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:20:ed:91:97:93 inet 87.110.108.74 netmask 0xfffffe00 broadcast 255.255.255.255 media: Ethernet autoselect (100baseTX ) status: active === after: === em0: flags=8843 metric 0 mtu 1500 options=98 ether 00:20:ed:91:97:93 inet 87.110.108.74 netmask 0xfffffe00 broadcast 255.255.255.255 media: Ethernet autoselect (100baseTX ) status: active === dmesg | grep em0 === em0: port 0xa000-0xa03f mem 0xdb100000-0xdb11ffff irq 21 at device 9.0 on pci2 em0: [FILTER] em0: Ethernet address: 00:20:ed:91:97:93 === pciconf -lv === em0@pci0:2:9:0: class=0x020000 card=0x30138086 chip=0x100e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (82540EM)' class = network subclass = ethernet === Do this looks like a bug (em drivers, nat, etc...) or not? Should I make new PR for this problem? From cswiger at mac.com Thu Jul 16 20:22:45 2009 From: cswiger at mac.com (Chuck Swiger) Date: Thu Jul 16 20:22:53 2009 Subject: ipfw nat and localy initiated UDP traffic (bad udp cksum) In-Reply-To: <200907162219.04986.dima_bsd@inbox.lv> References: <200907142355.34973.dima_bsd@inbox.lv> <200907162219.04986.dima_bsd@inbox.lv> Message-ID: <2CE3CD12-D430-4378-92C1-591227888428@mac.com> On Jul 16, 2009, at 12:19 PM, Dmitriy Demidov wrote: > Update about this issue. > There is somthing wrong with UDP pass through - ipfw nat makes it > "bad cksum". tcpdump receives local network traffic before the checksums are computed (especially if hardware checksums are enabled); this is a non- issue, although you could confirm by sniffing the traffic from an external machine like a laptop. Regards, -- -Chuck From bjsptyltdstore at sify.com Sun Jul 19 03:00:36 2009 From: bjsptyltdstore at sify.com (Bryan James) Date: Sun Jul 19 03:00:46 2009 Subject: Order To New Zealand Message-ID: <200907182120.n6ILKqqB023752@n22.sivit.org> <<< No Message Collected >>> From bugmaster at FreeBSD.org Mon Jul 20 11:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 20 11:08:38 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200907201106.n6KB6vWY002320@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/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 60 problems total. From raffaele.delorenzo at libero.it Wed Jul 22 10:00:32 2009 From: raffaele.delorenzo at libero.it (raffaele.delorenzo@libero.it) Date: Wed Jul 22 10:00:39 2009 Subject: R: IPv6 and ipfw Message-ID: <3164304.442981248256119643.JavaMail.defaultUser@defaultHost> Hi all, You has found a parser bug. When the protocol is "ipv6" and you are a comma separated ipv6 addresses, the parser work fine because the "add_srcip6" function is called and recognize all addresses. When the protocol is "!=ipv6" (like TCP,UDP,ICMP6) the "add_src" fuction is called and it cause troubles because the "inet_pton()" fails and erroneously is called the "add_srcip" function (see the code below). (from "ipfw2.c") add_src(ipfw_insn *cmd, char *av, u_char proto) { struct in6_addr a; char *host, *ch; ipfw_insn *ret = NULL; if ((host = strdup(av)) == NULL) return NULL; if ((ch = strrchr (host, '/')) != NULL) *ch = '\0'; if (proto == IPPROTO_IPV6 || strcmp(av, "me6") == 0 || inet_pton(AF_INET6, host, &a)) ret = add_srcip6(cmd, av); /* XXX: should check for IPv4, not !IPv6 */ if (ret == NULL && (proto == IPPROTO_IP || strcmp(av, "me") == 0 || !inet_pton(AF_INET6, host, &a))) ret = add_srcip(cmd, av); if (ret == NULL && strcmp(av, "any") != 0) ret = cmd; free(host); return ret; } I think that possibles solutions are the follows: 1) Create a new protocols types UPD6,TCP6 only for IPv6 rules to avoid parser confusions, and check about this protocol inside the "add_src" fuction (easy to implement). 2) Check the comma separated ip/ipv6 addresses inside the "add_src" function (a little too hard to implement). I appreciate suggestions from the community experts about this problem. Ciao Raffaele >----Messaggio originale---- >Da: wjw@digiware.nl >Data: 22/07/2009 10.20 >A: >Ogg: IPv6 and ipfw > >Hi, > >Running 7.2 I tried to insert this into my IPFW rules > ># ipfw add allow udp from any to 2001:xxx:3:: 113,2001:xxxx:3::116 \ > dst-port 10001-10100 keep-state >ipfw: bad netmask ``xxxx:3::113'' > >also: ># ipfw add allow udp from any to trixbox.ip6 dst-port 10001-10100 keep-state >ipfw: hostname ``trixbox.ip6'' unknown >Exit 68 ># host trixbox.ip6 >trixbox.ip6.digiware.nl has IPv6 address 2001:4cb8:3::116 > >So it looks like what is in the manual is overly optimistic: >---- > addr6-list: ip6-addr[,addr6-list] > > ip6-addr: > A host or subnet specified one of the following ways: > > numeric-ip | hostname > Matches a single IPv6 address as allowed by inet_pton(3) > or a hostname. Hostnames are resolved at the time the > rule is added to the firewall list. > > addr/masklen > Matches all IPv6 addresses with base addr (specified as > allowed by inet_pton or a hostname) and mask width of > masklen bits. > > No support for sets of IPv6 addresses is provided because IPv6 > addresses are typically random past the initial prefix. >---- > >Anybody else ran into this? >Or should I file this as a PR. > >--WjW >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From wjw at digiware.nl Wed Jul 22 15:11:00 2009 From: wjw at digiware.nl (Willem Jan Withagen) Date: Wed Jul 22 15:11:12 2009 Subject: R: IPv6 and ipfw In-Reply-To: <3164304.442981248256119643.JavaMail.defaultUser@defaultHost> References: <3164304.442981248256119643.JavaMail.defaultUser@defaultHost> Message-ID: <4A672C79.3000006@digiware.nl> Reply below, and an also reorganised the yours... raffaele.delorenzo@libero.it wrote: >> Hi, >> >> Running 7.2 I tried to insert > this into my IPFW rules >> # ipfw add allow udp from any to 2001:xxx:3:: > 113,2001:xxxx:3::116 \ >> dst-port 10001-10100 keep-state >> ipfw: bad netmask > ``xxxx:3::113'' >> also: >> # ipfw add allow udp from any to trixbox.ip6 dst-port > 10001-10100 keep-state >> ipfw: hostname ``trixbox.ip6'' unknown >> Exit 68 >> # host > trixbox.ip6 >> trixbox.ip6.digiware.nl has IPv6 address 2001:4cb8:3::116 >> >> So it > looks like what is in the manual is overly optimistic: >> ---- >> addr6-list: > ip6-addr[,addr6-list] >> ip6-addr: >> A host or subnet > specified one of the following ways: >> numeric-ip | hostname > >> Matches a single IPv6 address as allowed by inet_pton(3) > >> or a hostname. Hostnames are resolved at the time the > >> rule is added to the firewall list. >> >> > addr/masklen >> Matches all IPv6 addresses with base addr > (specified as >> allowed by inet_pton or a hostname) and > mask width of >> masklen bits. >> >> No support > for sets of IPv6 addresses is provided because IPv6 >> addresses > are typically random past the initial prefix. >> ---- >> >> Anybody else ran into > this? >> Or should I file this as a PR. > Hi all, > You has found a parser bug. > When the protocol is "ipv6" and you are a > comma separated ipv6 addresses, the parser work fine because the "add_srcip6" > function is called and recognize all addresses. > When the protocol is "!=ipv6" > (like TCP,UDP,ICMP6) the "add_src" fuction is called and it cause troubles > because the "inet_pton()" fails and erroneously is called the "add_srcip" > function (see the code below). > > (from "ipfw2.c") > add_src(ipfw_insn *cmd, char > *av, u_char proto) > { > struct in6_addr a; > char *host, *ch; > ipfw_insn *ret = > NULL; > > if ((host = strdup(av)) == NULL) > return NULL; > if ((ch = strrchr > (host, '/')) != NULL) > *ch = '\0'; > > if (proto == IPPROTO_IPV6 || strcmp(av, > "me6") == 0 || > inet_pton(AF_INET6, host, &a)) > ret = add_srcip6(cmd, av); > > /* XXX: should check for IPv4, not !IPv6 */ > if (ret == NULL && (proto == > IPPROTO_IP || strcmp(av, "me") == 0 || > !inet_pton(AF_INET6, host, &a))) > > ret = add_srcip(cmd, av); > if (ret == NULL && strcmp(av, "any") != 0) > ret = > cmd; > > free(host); > return ret; > } > > I think that possibles solutions are the > follows: > > 1) Create a new protocols types UPD6,TCP6 only for IPv6 rules to > avoid parser confusions, and check about this protocol inside the "add_src" > fuction (easy to implement). > 2) Check the comma separated ip/ipv6 addresses > inside the "add_src" function (a little too hard to implement). > > I appreciate > suggestions from the community experts about this problem. I would prefer not to make seperate tcp6 and udp6 items, since what i would like to do is things like: hostlist="a.b.c.d,A:B:C:D::F" and then in the firewall something like ipfw add allow tcp from any to ${hostlist} dst-port 80 setup and if tcp now goes into tcp and tcp6 I need to double my rules etc. Which raises one other point: using a FQDN with more A and AAAA records also just inserts the first reply in the list. Now I don't use FQDN since most of the time in the Firewall DNS is not quite up yet. --WjW From ipfw at mayhem.sportsline.com Fri Jul 24 12:19:00 2009 From: ipfw at mayhem.sportsline.com (ipfw) Date: Fri Jul 24 12:19:07 2009 Subject: Problem Posting to League 'ipfw' Message-ID: <200907241152.n6OBquHI006910@proxy1073.tm.cbsig.net> In order to send an e-mail to your league, the e-mail address which you are sending from must be associated with your team. You will need to update your e-mail address within the league, otherwise, your correspondence will be denied. To update your e-mail address, enter your league home page and select Options, Personal. You can enter more than one e-mail address by separating them with a comma and a space. From bugmaster at FreeBSD.org Mon Jul 27 11:06:56 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 27 11:08:43 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200907271106.n6RB6tgP018980@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/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 60 problems total. From j.m.sandford at hotmail.co.uk Mon Jul 27 13:20:22 2009 From: j.m.sandford at hotmail.co.uk (Mark Sandford) Date: Mon Jul 27 13:20:29 2009 Subject: Using dummynet to restrict bandwidth with more than 2 active pipes / queues Message-ID: Hi all, I've been using dummynet for a while to perform degraded network testing which has been really useful. Recently, we wanted to measure the performance limits of it on our hardware. To do this we setup a machine with 8 interfaces paired into 4 ethernet bridges. We are having throughput issues when more than 2 pipes are being used simultaneously. These issues appear to be independent of the bandwidths specified. For example: We set two traffic generators transmitting at 30Mbps across two of the bridges (pipes), sending 1000 byte UDP packets (1042 bytes on the wire) for a 20 second period. These are passed through dummynet pipes set up to restrict the bandwidth to 20Mbps at the bridge and we can see from the ipfw counters that all the packets hit the right rules and only the right rules. We the capture on the far end and can see that bandwidth has been restricted to 20Mbps as specified. All good! :o) The problem comes when we add any extra flows. The above example is repeated but with two extra traffic generators transmitting at just one packet per second each across a further two pipes. Again we can see from the counters that the packets all arrive at ipfw, however we only get 10Mbps at the receiving end (and we get a number of packet_drops logged at dummynet). We feel we must have missed something obvious but after over a week of reading / testing we're running out of ideas. Is anyone able / willing to help? ~~~~~~~~~~~~~~~~~~~~~~~~ Mark Sandford email: j.m.sandford@hotmail.co.uk mob: 07990 565976 ~~~~~~~~~~~~~~~~~~~~~~~~ _________________________________________________________________ Celebrate a decade of Messenger with free winks, emoticons, display pics, and more. http://clk.atdmt.com/UKM/go/157562755/direct/01/ From raffaele.delorenzo at libero.it Mon Jul 27 17:02:13 2009 From: raffaele.delorenzo at libero.it (Raffaele De Lorenzo) Date: Mon Jul 27 17:02:22 2009 Subject: R: IPv6 and ipfw In-Reply-To: <4A672C79.3000006@digiware.nl> References: <3164304.442981248256119643.JavaMail.defaultUser@defaultHost> <4A672C79.3000006@digiware.nl> Message-ID: <11956F97-0C87-456F-A769-70BEDBA351BE@libero.it> Hi all, I attached a patch that solve this problem. I will send a PR as soon as possible. Instructions: Patch the follow files: /usr/src/sbin/ipfw/ipfw2.c (patch is ipfw2.c.diff) /usr/src/sbin/ipfw/ipfw2.h (patch is ipfw2.h.diff) /usr/src/sbin/ipfw/ipv6.c (patch is ipv6.c.diff) This patch was tested on FreeBSD 8 Beta 2 AMD64 and official FreeBSD 8 BETA 2 Sources. Let me know any suggestion or problem. Regards Raffaele On Jul 22, 2009, at 5:12 PM, Willem Jan Withagen wrote: > Reply below, and an also reorganised the yours... > raffaele.delorenzo@libero.it wrote: >>> Hi, >>> >>> Running 7.2 I tried to insert >> this into my IPFW rules >>> # ipfw add allow udp from any to 2001:xxx:3:: -------------- next part -------------- >> 113,2001:xxxx:3::116 \ >>> dst-port 10001-10100 keep-state >>> ipfw: bad netmask >> ``xxxx:3::113'' >>> also: >>> # ipfw add allow udp from any to trixbox.ip6 dst-port >> 10001-10100 keep-state >>> ipfw: hostname ``trixbox.ip6'' unknown >>> Exit 68 >>> # host >> trixbox.ip6 >>> trixbox.ip6.digiware.nl has IPv6 address 2001:4cb8:3::116 >>> >>> So it >> looks like what is in the manual is overly optimistic: >>> ---- >>> addr6-list: >> ip6-addr[,addr6-list] >>> ip6-addr: >>> A host or subnet >> specified one of the following ways: >>> numeric-ip | hostname >>> Matches a single IPv6 address as allowed by >>> inet_pton(3) >>> or a hostname. Hostnames are resolved at the >>> time the >>> rule is added to the firewall list. >>> >>> >> addr/masklen >>> Matches all IPv6 addresses with base addr >> (specified as >>> allowed by inet_pton or a hostname) and >> mask width of >>> masklen bits. >>> >>> No support >> for sets of IPv6 addresses is provided because IPv6 >>> addresses >> are typically random past the initial prefix. >>> ---- >>> >>> Anybody else ran into >> this? >>> Or should I file this as a PR. > > > Hi all, > > You has found a parser bug. > > When the protocol is "ipv6" and you are a > > comma separated ipv6 addresses, the parser work fine because the > "add_srcip6" > > function is called and recognize all addresses. > > When the protocol is "!=ipv6" > > (like TCP,UDP,ICMP6) the "add_src" fuction is called and it cause > troubles > > because the "inet_pton()" fails and erroneously is called the > "add_srcip" > > function (see the code below). > > > > (from "ipfw2.c") > > add_src(ipfw_insn *cmd, char > > *av, u_char proto) > > { > > struct in6_addr a; > > char *host, *ch; > > ipfw_insn *ret = > > NULL; > > > > if ((host = strdup(av)) == NULL) > > return NULL; > > if ((ch = strrchr > > (host, '/')) != NULL) > > *ch = '\0'; > > > > if (proto == IPPROTO_IPV6 || strcmp(av, > > "me6") == 0 || > > inet_pton(AF_INET6, host, &a)) > > ret = add_srcip6(cmd, av); > > > > /* XXX: should check for IPv4, not !IPv6 */ > > if (ret == NULL && (proto == > > IPPROTO_IP || strcmp(av, "me") == 0 || > > !inet_pton(AF_INET6, host, &a))) > > > > ret = add_srcip(cmd, av); > > if (ret == NULL && strcmp(av, "any") != 0) > > ret = > > cmd; > > > > free(host); > > return ret; > > } > > > > I think that possibles solutions are the > > follows: > > > > 1) Create a new protocols types UPD6,TCP6 only for IPv6 rules to > > avoid parser confusions, and check about this protocol inside the > "add_src" > > fuction (easy to implement). > > 2) Check the comma separated ip/ipv6 addresses > > inside the "add_src" function (a little too hard to implement). > > > > I appreciate > > suggestions from the community experts about this problem. > > I would prefer not to make seperate tcp6 and udp6 items, since what > i would like to do is things like: > > hostlist="a.b.c.d,A:B:C:D::F" > > and then in the firewall something like > ipfw add allow tcp from any to ${hostlist} dst-port 80 setup > > and if tcp now goes into tcp and tcp6 I need to double my rules etc. > > Which raises one other point: > using a FQDN with more A and AAAA records also just inserts the > first reply in the list. > Now I don't use FQDN since most of the time in the Firewall DNS > is not quite up yet. > > --WjW > _______________________________________________ > 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 j.m.sandford at hotmail.co.uk Tue Jul 28 06:15:33 2009 From: j.m.sandford at hotmail.co.uk (Mark Sandford) Date: Tue Jul 28 06:15:39 2009 Subject: Using dummynet to restrict bandwidth with more than 2 active pipes / queues In-Reply-To: References: Message-ID: Sorry if anyone's wasted time looking at this. The problem appears to be with the traffic generator. Once we get above two generation processes we think that the data is being sent in bursts so although it appears to be right averaged over a second at a finer granularity the burstiness is meaning it's either exceeding the bandwidth or idle at each point. ~~~~~~~~~~~~~~~~~~~~~~~~ Mark Sandford email: j.m.sandford@hotmail.co.uk mob: 07990 565976 ~~~~~~~~~~~~~~~~~~~~~~~~ > From: j.m.sandford@hotmail.co.uk > To: freebsd-ipfw@freebsd.org > Date: Mon, 27 Jul 2009 14:08:22 +0100 > Subject: Using dummynet to restrict bandwidth with more than 2 active pipes / queues > > > Hi all, > > > > I've been using dummynet for a while to perform degraded network testing which has been really useful. > > > > Recently, we wanted to measure the performance limits of it on our > hardware. To do this we setup a machine with 8 interfaces paired into 4 > ethernet bridges. > > > > We are having throughput issues when more than 2 pipes are being used > simultaneously. These issues appear to be independent of the bandwidths > specified. > > For example: > We set two traffic generators transmitting at 30Mbps across two of the bridges (pipes), sending 1000 byte UDP packets (1042 bytes on the wire) for a 20 second period. > > These are passed through dummynet pipes set up to restrict the bandwidth to 20Mbps at the bridge and we can see from the ipfw counters that all the packets hit the right rules and only the right rules. > > We the capture on the far end and can see that bandwidth has been restricted to 20Mbps as specified. All good! :o) > > The problem comes when we add any extra flows. > > The above example is repeated but with two extra traffic generators transmitting at just one packet per second each across a further two pipes. > > Again we can see from the counters that the packets all arrive at ipfw, however we only get 10Mbps at the receiving end (and we get a number of packet_drops logged at dummynet). > > We feel we must have missed something obvious but after over a week of reading / testing we're running out of ideas. > > Is anyone able / willing to help? > > ~~~~~~~~~~~~~~~~~~~~~~~~ > Mark Sandford > > email: j.m.sandford@hotmail.co.uk > mob: 07990 565976 > > ~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > _________________________________________________________________ > Celebrate a decade of Messenger with free winks, emoticons, display pics, and more. > http://clk.atdmt.com/UKM/go/157562755/direct/01/_______________________________________________ > 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" _________________________________________________________________ Windows Live Messenger: Celebrate 10 amazing years with free winks and emoticons. http://clk.atdmt.com/UKM/go/157562755/direct/01/ From julian at elischer.org Tue Jul 28 06:36:36 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Jul 28 06:36:42 2009 Subject: Using dummynet to restrict bandwidth with more than 2 active pipes / queues In-Reply-To: References: Message-ID: <4A6E990E.6090800@elischer.org> Mark Sandford wrote: > Sorry if anyone's wasted time looking at this. The problem appears > to be with the traffic generator. Once we get above two generation > processes we think that the data is being sent in bursts so although > it appears to be right averaged over a second at a finer granularity > the burstiness is meaning it's either exceeding the bandwidth or idle > at each point. > what are you using to generate traffic? and what kind of traffic? From j.m.sandford at hotmail.co.uk Tue Jul 28 06:44:35 2009 From: j.m.sandford at hotmail.co.uk (Mark Sandford) Date: Tue Jul 28 06:44:41 2009 Subject: Using dummynet to restrict bandwidth with more than 2 active pipes / queues In-Reply-To: <4A6E990E.6090800@elischer.org> References: <4A6E990E.6090800@elischer.org> Message-ID: It's a home grown tool using libnet. We've re-tested using one packet generation process to create 4 flows going across the four pipes and see pretty much what we were expecting. In this case we were just firing 1000 byte udp packets (1042 bytes on the wire). ~~~~~~~~~~~~~~~~~~~~~~~~ Mark Sandford email: j.m.sandford@hotmail.co.uk mob: 07990 565976 ~~~~~~~~~~~~~~~~~~~~~~~~ > Date: Mon, 27 Jul 2009 23:22:06 -0700 > From: julian@elischer.org > To: j.m.sandford@hotmail.co.uk > CC: freebsd-ipfw@freebsd.org > Subject: Re: Using dummynet to restrict bandwidth with more than 2 active pipes / queues > > Mark Sandford wrote: > > Sorry if anyone's wasted time looking at this. The problem appears > > to be with the traffic generator. Once we get above two generation > > processes we think that the data is being sent in bursts so although > > it appears to be right averaged over a second at a finer granularity > > the burstiness is meaning it's either exceeding the bandwidth or idle > > at each point. > > > > what are you using to generate traffic? > and what kind of traffic? > > _______________________________________________ > 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" _________________________________________________________________ Celebrate a decade of Messenger with free winks, emoticons, display pics, and more. http://clk.atdmt.com/UKM/go/157562755/direct/01/ From wjw at digiware.nl Wed Jul 29 10:44:33 2009 From: wjw at digiware.nl (Willem Jan Withagen) Date: Wed Jul 29 10:44:46 2009 Subject: R: IPv6 and ipfw In-Reply-To: <11956F97-0C87-456F-A769-70BEDBA351BE@libero.it> References: <3164304.442981248256119643.JavaMail.defaultUser@defaultHost> <4A672C79.3000006@digiware.nl> <11956F97-0C87-456F-A769-70BEDBA351BE@libero.it> Message-ID: <4A702885.5080803@digiware.nl> Raffaele De Lorenzo wrote: > Hi all, > I attached a patch that solve this problem. I will send a PR as soon as > possible. > > Instructions: > > Patch the follow files: > > /usr/src/sbin/ipfw/ipfw2.c (patch is ipfw2.c.diff) > /usr/src/sbin/ipfw/ipfw2.h (patch is ipfw2.h.diff) > /usr/src/sbin/ipfw/ipv6.c (patch is ipv6.c.diff) > > This patch was tested on FreeBSD 8 Beta 2 AMD64 and official FreeBSD 8 > BETA 2 Sources. > > Let me know any suggestion or problem. Patch worked fine on 7.2-stable as well. Multiple ipv6 addresses are now accepted in one go. But it still does not really works as well as I would like ;): ipfw add 11101 allow udp from any to 192.168.10.67,2001:dddd:c::67 dst-port 45457 keep-state ipfw: bad netmask ``dddd:c::67'' Which from your comment seems correct: + * Pre-Check multi address rules to avoid parser confusion about IPv4/IPv6 addresses. + * XXX I assume the first know address is the reference address (You cannot use both IPv4/IPv6 addresses inside + * a multi-addresses rule). But looking at the code, why not fist parse chunks seperated by ',' and then test them for all possible variants, because as far as I understand there are no ',''s allowed in the adresspec. Thanx for the work thusfar, --WjW From linimon at FreeBSD.org Wed Jul 29 16:06:01 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Jul 29 16:06:12 2009 Subject: kern/137232: [ipfw] parser troubles Message-ID: <200907291606.n6TG60kQ051524@freefall.freebsd.org> Synopsis: [ipfw] parser troubles Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 29 16:05:41 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137232