From owner-freebsd-ipfw Mon Jan 14 13:51:43 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from chk.phattydomain.com (12-225-230-182.client.attbi.com [12.225.230.182]) by hub.freebsd.org (Postfix) with ESMTP id 483EC37B405 for ; Mon, 14 Jan 2002 13:51:36 -0800 (PST) Received: (from chuck@localhost) by chk.phattydomain.com (8.11.6/8.11.4) id g0ELqrR99190; Mon, 14 Jan 2002 13:52:54 -0800 (PST) (envelope-from chuck) Date: Mon, 14 Jan 2002 13:52:54 -0800 (PST) From: chk no Message-Id: <200201142152.g0ELqrR99190@chk.phattydomain.com> To: freebsd-ipfw@freebsd.org Subject: ip_dummynet.c:"*** OUCH! pipe should have been idle!" Cc: chkno@dork.com Reply-To: chkno@dork.com Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG $ grep OUCH /var/log/messages Jan 12 23:45:46 chk /kernel: *** OUCH! pipe should have been idle! Running the error message through 5 popular search engines hit only on mirrors of the source. I gather that it is not common for this to occur. This machine is running 4.4-STABLE, cvsuped Wed Dec 19 15:02:20 PST 2001. There have been some other issues with ipfw+natd packet loops (more packets pass through the system than enter it) if the pipe queue is set too low, packet loops if the network activity gets too hectic (mutella). I was about to cvsup & reinstall, but i'll hold off if anyone wants to look at it. It's still up & crunching packets... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jan 14 14:15:48 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 6CF3537B416 for ; Mon, 14 Jan 2002 14:15:42 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.3/8.11.3) id g0EMFd470387; Mon, 14 Jan 2002 14:15:39 -0800 (PST) (envelope-from rizzo) Date: Mon, 14 Jan 2002 14:15:39 -0800 From: Luigi Rizzo To: chkno@dork.com Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: ip_dummynet.c:"*** OUCH! pipe should have been idle!" Message-ID: <20020114141539.A70340@iguana.icir.org> References: <200201142152.g0ELqrR99190@chk.phattydomain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201142152.g0ELqrR99190@chk.phattydomain.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG what kind of dummynet configuration are you using ? (ipfw show ; ipfw pipe show) Also, if the problem is easily reproducible, please let me know if you are interested in testing some patches cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- On Mon, Jan 14, 2002 at 01:52:54PM -0800, chk no wrote: > > $ grep OUCH /var/log/messages > Jan 12 23:45:46 chk /kernel: *** OUCH! pipe should have been idle! > > Running the error message through 5 popular search engines hit only > on mirrors of the source. I gather that it is not common for this > to occur. > > This machine is running 4.4-STABLE, cvsuped Wed Dec 19 15:02:20 PST > 2001. There have been some other issues with ipfw+natd packet loops > (more packets pass through the system than enter it) if the pipe > queue is set too low, packet loops if the network activity gets too > hectic (mutella). I was about to cvsup & reinstall, but i'll hold > off if anyone wants to look at it. It's still up & crunching > packets... > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jan 14 14:45:21 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from chk.phattydomain.com (12-225-230-182.client.attbi.com [12.225.230.182]) by hub.freebsd.org (Postfix) with ESMTP id 483FF37B400 for ; Mon, 14 Jan 2002 14:45:16 -0800 (PST) Received: (from chuck@localhost) by chk.phattydomain.com (8.11.6/8.11.4) id g0EMkXC05128; Mon, 14 Jan 2002 14:46:33 -0800 (PST) (envelope-from chuck) Date: Mon, 14 Jan 2002 14:46:33 -0800 (PST) From: chk no Message-Id: <200201142246.g0EMkXC05128@chk.phattydomain.com> To: chkno@dork.com, rizzo@icir.org Subject: Re: ip_dummynet.c:"*** OUCH! pipe should have been idle!" Cc: freebsd-ipfw@FreeBSD.ORG Reply-To: chkno@dork.com In-Reply-To: <20020114141539.A70340@iguana.icir.org> Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > $ grep OUCH /var/log/messages > > Jan 12 23:45:46 chk /kernel: *** OUCH! pipe should have been idle! > > > > Running the error message through 5 popular search engines hit only > > on mirrors of the source. I gather that it is not common for this > > to occur. > > > > This machine is running 4.4-STABLE, cvsuped Wed Dec 19 15:02:20 PST > > 2001. There have been some other issues with ipfw+natd packet loops > > (more packets pass through the system than enter it) if the pipe > > queue is set too low, packet loops if the network activity gets too > > hectic (mutella). I was about to cvsup & reinstall, but i'll hold > > off if anyone wants to look at it. It's still up & crunching > > packets... > > what kind of dummynet configuration are you using ? > (ipfw show ; ipfw pipe show) I'm using a bit of a crazy ruleset atm. I'm on a limited bandwidth connection, & I've been toying with the idea of writing a wrapper for ftpd with the same idea as natd's -punch_fw for dynamic bandwidth management of ftp users while not slowing down the connection for other types of traffic. I'm sure there's a much cleaner way to do all this, but I'm atm I'm just playing around. Also, I can't seem to get large port ranges (49152-65535, specifically) to work as expected, which was further motivation. Anyway, please excuse my ruleset: 00049 83862 53010432 count ip from any to any 00050 83517 52949119 divert 8668 ip from any to any via ed1 00051 83862 53010432 count ip from any to any 00100 144 18292 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 01000 0 0 deny ip from 212.169.172.130 to any 01001 0 0 deny ip from 80.134.79.183 to any 01002 0 0 deny ip from 80.134.93.244 to any 01003 0 0 deny ip from 24.101.41.14 to any 01004 0 0 deny ip from 24.42.1.213 to any 01005 0 0 deny ip from 62.31.149.70 to any 01006 0 0 deny ip from 24.222.68.178 to any 01007 0 0 deny ip from 213.118.43.124 to any 01008 0 0 deny ip from 63.202.174.248 to any 01009 0 0 deny ip from 63.202.174.25 to any 01010 0 0 deny ip from 213.224.83.27 to any 01011 0 0 deny ip from 213.73.130.120 to any 01012 0 0 deny ip from 213.96.243.151 to any 01013 0 0 deny ip from 217.85.160.29 to any 01014 0 0 deny ip from 212.120.156.4 to any 01015 0 0 deny ip from 213.118.62.216 to any 01016 4 192 deny ip from 80.63.18.111 to any 10000 0 0 queue 100 ip from any to 141.56.135.29 out xmit ed1 10002 0 0 queue 100 ip from any to 80.133.105.193 out xmit ed1 10004 0 0 queue 110 ip from any to 24.156.167.145 out xmit ed1 10006 0 0 queue 100 ip from any to 217.82.234.229 out xmit ed1 10008 34461 50035960 queue 100 ip from any to 80.133.107.251 out xmit ed1 19999 22122 1323692 queue 190 ip from any to any out xmit ed1 60000 26930 1589275 count ip from any to any in recv ed1 60001 0 0 count ip from any to any out xmit ed1 60010 117 23184 count ip from any to any in recv rl0 60011 84 19837 count ip from any to any out xmit rl0 65000 27131 1632296 allow ip from any to any 65535 0 0 deny ip from any to any 00010: 125.000 Kbit/s 0 ms 100 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 12.225.230.182/20 65.8.88.230/2822 84447092 94084152055 0 0 80774191 q00100: weight 1 pipe 10 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 12.225.230.182/53299 141.56.135.29/50474 1615024 2237963167 8 11616 700551 q00110: weight 2 pipe 10 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 12.225.230.182/60186 24.156.167.145/1696 92806 31691943 0 0 0 q00190: weight 99 pipe 10 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 12.225.230.182/2198 209.73.225.9/80 930515 697347225 0 0 437372 The topology is internet--ed1--|box|--rl0--internal_net I'm running natd for clients on the internal net. Rules 49 & 51 are in place because of my other issue. By setting the pipe's queue value to less than 20 slots I can make rule 51 count orders of magnitude more packets than rule 49. I was wondering if this was standard behavior. The problem seems to dissapear as long as I keep the pipe queue large. See -questions for that thread. > > Also, if the problem is easily reproducible, please > let me know if you are interested in testing some patches The OUCH event is not reproduceable. It happened in the middle of the night, & has only happened once so far. The packet loop is easily reproduceable. The large port range issue seems more related to ipfw than dummynet, & I haven't tried to isolate it much. I could just be doing something stupid. That said, if you've got patches, I'm more than willing to try them out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jan 14 14:58:57 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 847A537B41C for ; Mon, 14 Jan 2002 14:58:51 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.3/8.11.3) id g0EMwnB70611; Mon, 14 Jan 2002 14:58:49 -0800 (PST) (envelope-from rizzo) Date: Mon, 14 Jan 2002 14:58:49 -0800 From: Luigi Rizzo To: chkno@dork.com Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: ip_dummynet.c:"*** OUCH! pipe should have been idle!" Message-ID: <20020114145849.A70496@iguana.icir.org> References: <20020114141539.A70340@iguana.icir.org> <200201142246.g0EMkXC05128@chk.phattydomain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201142246.g0EMkXC05128@chk.phattydomain.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Rules 49 & 51 are in place because of my other issue. By setting > the pipe's queue value to less than 20 slots I can make rule 51 > count orders of magnitude more packets than rule 49. I was wondering > if this was standard behavior. The problem seems to dissapear as > long as I keep the pipe queue large. See -questions for that thread. I have an explaination for this. When the queue overflows, you get an ENOBUFS error, which natd detects and handles by retransmitting the packet at a later time (not a very good idea, I'd say that natd should just drop the packet in this case. The "fix" might be trapping the ENOBUFS error in usr/src/sbin/natd.c:FlushPacketBuffer() and returning as if the transmission was successful). > > Also, if the problem is easily reproducible, please > > let me know if you are interested in testing some patches > > The OUCH event is not reproduceable. It happened in the middle of > the night, & has only happened once so far. eh, then all i can say is wait and see if it happens again... in the meantime i will have a closer look at the code. > The large port range issue seems more related to ipfw than dummynet, i am not sure what is the issue there... do thing work if you reduce the upper limit to 65534 ? In this case it might just be a problem with unsigned short comparisons... cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jan 14 15:39:11 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from chk.phattydomain.com (12-225-230-182.client.attbi.com [12.225.230.182]) by hub.freebsd.org (Postfix) with ESMTP id ADFD837B404 for ; Mon, 14 Jan 2002 15:39:08 -0800 (PST) Received: (from chuck@localhost) by chk.phattydomain.com (8.11.6/8.11.4) id g0ENeRq10353; Mon, 14 Jan 2002 15:40:27 -0800 (PST) (envelope-from chuck) Date: Mon, 14 Jan 2002 15:40:27 -0800 (PST) From: chk no Message-Id: <200201142340.g0ENeRq10353@chk.phattydomain.com> To: chkno@dork.com, rizzo@icir.org Subject: Re: ip_dummynet.c:"*** OUCH! pipe should have been idle!" Cc: freebsd-ipfw@FreeBSD.ORG In-Reply-To: <20020114145849.A70496@iguana.icir.org> Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Rules 49 & 51 are in place because of my other issue. By setting > > the pipe's queue value to less than 20 slots I can make rule 51 > > count orders of magnitude more packets than rule 49. I was wondering > > if this was standard behavior. The problem seems to dissapear as > > long as I keep the pipe queue large. See -questions for that thread. > > I have an explaination for this. > > When the queue overflows, you get an ENOBUFS error, which natd > detects and handles by retransmitting the packet at a later time > (not a very good idea, I'd say that natd should just drop the packet > in this case. The "fix" might be trapping the ENOBUFS error in > usr/src/sbin/natd.c:FlushPacketBuffer() and returning as if the > transmission was successful). Cool. This was driving me batty until I figured out to leave the queue large. ipfw(8) says to keep it small... > > > > Also, if the problem is easily reproducible, please > > > let me know if you are interested in testing some patches > > > > The OUCH event is not reproduceable. It happened in the middle of > > the night, & has only happened once so far. > > eh, then all i can say is wait and see if it happens again... > in the meantime i will have a closer look at the code. ok. > > > The large port range issue seems more related to ipfw than dummynet, > > i am not sure what is the issue there... do thing work if you > reduce the upper limit to 65534 ? In this case it might just be > a problem with unsigned short comparisons... Bla, it's working fine. I must have been doing something stupid earlier. *Sorry* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jan 15 2: 7:11 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id C7F9D37B405 for ; Tue, 15 Jan 2002 02:06:59 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0FA5Vh63409; Tue, 15 Jan 2002 12:05:31 +0200 (EET) (envelope-from ru) Date: Tue, 15 Jan 2002 12:05:31 +0200 From: Ruslan Ermilov To: Luigi Rizzo Cc: chkno@dork.com, freebsd-ipfw@FreeBSD.ORG Subject: Re: ip_dummynet.c:"*** OUCH! pipe should have been idle!" Message-ID: <20020115120531.C46269@sunbay.com> References: <20020114141539.A70340@iguana.icir.org> <200201142246.g0EMkXC05128@chk.phattydomain.com> <20020114145849.A70496@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020114145849.A70496@iguana.icir.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 14, 2002 at 02:58:49PM -0800, Luigi Rizzo wrote: > > Rules 49 & 51 are in place because of my other issue. By setting > > the pipe's queue value to less than 20 slots I can make rule 51 > > count orders of magnitude more packets than rule 49. I was wondering > > if this was standard behavior. The problem seems to dissapear as > > long as I keep the pipe queue large. See -questions for that thread. > > I have an explaination for this. > > When the queue overflows, you get an ENOBUFS error, which natd > detects and handles by retransmitting the packet at a later time > (not a very good idea, I'd say that natd should just drop the packet > in this case. The "fix" might be trapping the ENOBUFS error in > usr/src/sbin/natd.c:FlushPacketBuffer() and returning as if the > transmission was successful). > ENOBUFS may be returned by sendto(2) when no socket buffer space is available. In this case, natd(8) retransmits the packet only after select(2) says that the socket is writable again. Dropping the packet in this case would be bogus, and natd.c has fixed this in revision 1.2. > > > Also, if the problem is easily reproducible, please > > > let me know if you are interested in testing some patches > > > > The OUCH event is not reproduceable. It happened in the middle of > > the night, & has only happened once so far. > > eh, then all i can say is wait and see if it happens again... > in the meantime i will have a closer look at the code. > > > The large port range issue seems more related to ipfw than dummynet, > > i am not sure what is the issue there... do thing work if you > reduce the upper limit to 65534 ? In this case it might just be > a problem with unsigned short comparisons... > Also, does the open right bound work, like "49192-"? Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jan 15 2:18:43 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 9A4D937B41C; Tue, 15 Jan 2002 02:18:40 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.3/8.11.3) id g0FAIe074463; Tue, 15 Jan 2002 02:18:40 -0800 (PST) (envelope-from rizzo) Date: Tue, 15 Jan 2002 02:18:40 -0800 From: Luigi Rizzo To: Ruslan Ermilov Cc: chkno@dork.com, freebsd-ipfw@FreeBSD.ORG Subject: Re: ip_dummynet.c:"*** OUCH! pipe should have been idle!" Message-ID: <20020115021839.A74391@iguana.icir.org> References: <20020114141539.A70340@iguana.icir.org> <200201142246.g0EMkXC05128@chk.phattydomain.com> <20020114145849.A70496@iguana.icir.org> <20020115120531.C46269@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020115120531.C46269@sunbay.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jan 15, 2002 at 12:05:31PM +0200, Ruslan Ermilov wrote: > On Mon, Jan 14, 2002 at 02:58:49PM -0800, Luigi Rizzo wrote: > > When the queue overflows, you get an ENOBUFS error, which natd > > detects and handles by retransmitting the packet at a later time > > (not a very good idea, I'd say that natd should just drop the packet > > in this case. The "fix" might be trapping the ENOBUFS error in > > usr/src/sbin/natd.c:FlushPacketBuffer() and returning as if the > > transmission was successful). > > > ENOBUFS may be returned by sendto(2) when no socket buffer space > is available. In this case, natd(8) retransmits the packet only > after select(2) says that the socket is writable again. Dropping > the packet in this case would be bogus, and natd.c has fixed this > in revision 1.2. Sorry Ruslan, but I think you are wrong. For udp/datagram sockets, the i[output] socket buffer has no role other than limit the max datagram size, and it is entirely bypassed by the sendto/write routines. So, select() sees the socket as always writable, and natd in this case loop forever. This is why i said retrying is broken. And it is severely broken, indeed. Look at the sendto() manpage: ERRORS ... [ENOBUFS] The system was unable to allocate an internal buffer. The operation may succeed when buffers become avail- able. [ENOBUFS] The output queue for a network interface was full. This generally indicates that the interface has stopped sending, but may be caused by transient con- gestion. and also at the source code for sendto(). The reason why you cannot queue in the socket buffer is that there is no way to trigger the transmission when the device becomes available again -- for TCP this is supported by incoming acks or timeouts, but there is no equivalent for UDP. Sure you could think of queueing the socket on the output device, but apart that there is no infrastructure for that, which interface to use depends on routing info, and then you might have multiple ones because of multicast... cheers luigi (who discovered this during fall 2000) ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jan 15 4:42:11 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id D282D37B416; Tue, 15 Jan 2002 04:41:39 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0FCejZ87777; Tue, 15 Jan 2002 14:40:45 +0200 (EET) (envelope-from ru) Date: Tue, 15 Jan 2002 14:40:45 +0200 From: Ruslan Ermilov To: Luigi Rizzo Cc: chkno@dork.com, freebsd-ipfw@FreeBSD.ORG, Ari Suutari , Brian Somers Subject: Re: ip_dummynet.c:"*** OUCH! pipe should have been idle!" Message-ID: <20020115144045.J46269@sunbay.com> References: <20020114141539.A70340@iguana.icir.org> <200201142246.g0EMkXC05128@chk.phattydomain.com> <20020114145849.A70496@iguana.icir.org> <20020115120531.C46269@sunbay.com> <20020115021839.A74391@iguana.icir.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gj572EiMnwbLXET9" Content-Disposition: inline In-Reply-To: <20020115021839.A74391@iguana.icir.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 15, 2002 at 02:18:40AM -0800, Luigi Rizzo wrote: > On Tue, Jan 15, 2002 at 12:05:31PM +0200, Ruslan Ermilov wrote: > > On Mon, Jan 14, 2002 at 02:58:49PM -0800, Luigi Rizzo wrote: > > > When the queue overflows, you get an ENOBUFS error, which natd > > > detects and handles by retransmitting the packet at a later time > > > (not a very good idea, I'd say that natd should just drop the packet > > > in this case. The "fix" might be trapping the ENOBUFS error in > > > usr/src/sbin/natd.c:FlushPacketBuffer() and returning as if the > > > transmission was successful). > > > > > ENOBUFS may be returned by sendto(2) when no socket buffer space > > is available. In this case, natd(8) retransmits the packet only > > after select(2) says that the socket is writable again. Dropping > > the packet in this case would be bogus, and natd.c has fixed this > > in revision 1.2. > > Sorry Ruslan, but I think you are wrong. > > For udp/datagram sockets, the i[output] socket buffer has no role > other than limit the max datagram size, and it is entirely bypassed > by the sendto/write routines. So, select() sees the socket as always > writable, and natd in this case loop forever. This is why i said > retrying is broken. And it is severely broken, indeed. > Right, this is well documented in Stevens TCP/IP Illustrated Vol. 2 in section 16.7, subsection "Unreliable Protocol Buffering". > Look at the sendto() manpage: > > ERRORS > ... > > [ENOBUFS] The system was unable to allocate an internal buffer. > The operation may succeed when buffers become avail- > able. > > [ENOBUFS] The output queue for a network interface was full. > This generally indicates that the interface has > stopped sending, but may be caused by transient con- > gestion. > > and also at the source code for sendto(). > Been there, confirmed that. Even for TCP, sendto() doesn't allocate a socket buffer space -- it's the responsibility of the protocol's output function, tcp_output(). > The reason why you cannot queue in the socket buffer is that there > is no way to trigger the transmission when the device becomes available > again -- for TCP this is supported by incoming acks or timeouts, but > there is no equivalent for UDP. > > Sure you could think of queueing the socket on the output device, but > apart that there is no infrastructure for that, which interface to > use depends on routing info, and then you might have multiple > ones because of multicast... > That makes pretty much sense, thanks for the info! Please find the patch attached (which backs the corresponding rev. 1.2 changes out). Also CC:ed to Brian Somers (who committed that change) and Ari Suutari who originally wrote natd(8). Cheers, Ruslan (who now wonders if the problem fixed in natd.c,v 1.2 was false). --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: natd.c =================================================================== RCS file: /home/ncvs/src/sbin/natd/natd.c,v retrieving revision 1.38 diff -u -p -r1.38 natd.c --- natd.c 2001/11/27 11:06:02 1.38 +++ natd.c 2002/01/15 12:37:04 @@ -97,7 +97,6 @@ static int StrToPortRange (const ch static int StrToProto (const char* str); static int StrToAddrAndPortRange (const char* str, struct in_addr* addr, char* proto, port_range *portRange); static void ParseArgs (int argc, char** argv); -static void FlushPacketBuffer (int fd); static void SetupPunchFW(const char *strValue); /* @@ -118,11 +117,6 @@ static int dynamicMode; static int ifMTU; static int aliasOverhead; static int icmpSock; -static char packetBuf[IP_MAXPACKET]; -static int packetLen; -static struct sockaddr_in packetAddr; -static int packetSock; -static int packetDirection; static int dropIgnoredIncoming; static int logDropped; static int logFacility; @@ -136,7 +130,6 @@ int main (int argc, char** argv) int routeSock; struct sockaddr_in addr; fd_set readMask; - fd_set writeMask; int fdMax; /* * Initialize packet aliasing software. @@ -162,11 +155,6 @@ int main (int argc, char** argv) logDropped = 0; logFacility = LOG_DAEMON; logIpfwDenied = -1; -/* - * Mark packet buffer empty. - */ - packetSock = -1; - packetDirection = DONT_KNOW; ParseArgs (argc, argv); /* @@ -330,7 +318,7 @@ int main (int argc, char** argv) while (running) { - if (divertInOut != -1 && !ifName && packetSock == -1) { + if (divertInOut != -1 && !ifName) { /* * When using only one socket, just call * DoAliasing repeatedly to process packets. @@ -342,30 +330,17 @@ int main (int argc, char** argv) * Build read mask from socket descriptors to select. */ FD_ZERO (&readMask); - FD_ZERO (&writeMask); - -/* - * If there is unsent packet in buffer, use select - * to check when socket comes writable again. - */ - if (packetSock != -1) { - - FD_SET (packetSock, &writeMask); - } - else { /* - * No unsent packet exists - safe to check if - * new ones are available. + * Check if new packets are available. */ - if (divertIn != -1) - FD_SET (divertIn, &readMask); + if (divertIn != -1) + FD_SET (divertIn, &readMask); - if (divertOut != -1) - FD_SET (divertOut, &readMask); + if (divertOut != -1) + FD_SET (divertOut, &readMask); - if (divertInOut != -1) - FD_SET (divertInOut, &readMask); - } + if (divertInOut != -1) + FD_SET (divertInOut, &readMask); /* * Routing info is processed always. */ @@ -374,8 +349,8 @@ int main (int argc, char** argv) if (select (fdMax + 1, &readMask, - &writeMask, NULL, + NULL, NULL) == -1) { if (errno == EINTR) @@ -384,10 +359,6 @@ int main (int argc, char** argv) Quit ("Select failed."); } - if (packetSock != -1) - if (FD_ISSET (packetSock, &writeMask)) - FlushPacketBuffer (packetSock); - if (divertIn != -1) if (FD_ISSET (divertIn, &readMask)) DoAliasing (divertIn, INPUT); @@ -470,9 +441,13 @@ static void DoAliasing (int fd, int dire { int bytes; int origBytes; + char buf[IP_MAXPACKET]; + struct sockaddr_in addr; + int wrote; int status; int addrSize; struct ip* ip; + char msgBuf[80]; if (assignAliasAddr) { @@ -482,12 +457,12 @@ static void DoAliasing (int fd, int dire /* * Get packet from socket. */ - addrSize = sizeof packetAddr; + addrSize = sizeof addr; origBytes = recvfrom (fd, - packetBuf, - sizeof packetBuf, + buf, + sizeof buf, 0, - (struct sockaddr*) &packetAddr, + (struct sockaddr*) &addr, &addrSize); if (origBytes == -1) { @@ -500,9 +475,9 @@ static void DoAliasing (int fd, int dire /* * This is a IP packet. */ - ip = (struct ip*) packetBuf; + ip = (struct ip*) buf; if (direction == DONT_KNOW) { - if (packetAddr.sin_addr.s_addr == INADDR_ANY) + if (addr.sin_addr.s_addr == INADDR_ANY) direction = OUTPUT; else direction = INPUT; @@ -541,14 +516,14 @@ static void DoAliasing (int fd, int dire /* * Outgoing packets. Do aliasing. */ - PacketAliasOut (packetBuf, IP_MAXPACKET); + PacketAliasOut (buf, IP_MAXPACKET); } else { /* * Do aliasing. */ - status = PacketAliasIn (packetBuf, IP_MAXPACKET); + status = PacketAliasIn (buf, IP_MAXPACKET); if (status == PKT_ALIAS_IGNORED && dropIgnoredIncoming) { @@ -583,42 +558,24 @@ static void DoAliasing (int fd, int dire printf ("\n"); } - packetLen = bytes; - packetSock = fd; - packetDirection = direction; - - FlushPacketBuffer (fd); -} - -static void FlushPacketBuffer (int fd) -{ - int wrote; - char msgBuf[80]; /* * Put packet back for processing. */ wrote = sendto (fd, - packetBuf, - packetLen, + buf, + bytes, 0, - (struct sockaddr*) &packetAddr, - sizeof packetAddr); + (struct sockaddr*) &addr, + sizeof addr); - if (wrote != packetLen) { -/* - * If buffer space is not available, - * just return. Main loop will take care of - * retrying send when space becomes available. - */ - if (errno == ENOBUFS) - return; + if (wrote != bytes) { if (errno == EMSGSIZE) { - if (packetDirection == OUTPUT && + if (direction == OUTPUT && ifMTU != -1) SendNeedFragIcmp (icmpSock, - (struct ip*) packetBuf, + (struct ip*) buf, ifMTU - aliasOverhead); } else if (errno == EACCES && logIpfwDenied) { @@ -627,8 +584,6 @@ static void FlushPacketBuffer (int fd) Warn (msgBuf); } } - - packetSock = -1; } static void HandleRoutingInfo (int fd) --gj572EiMnwbLXET9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jan 15 4:43:36 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 1278437B416; Tue, 15 Jan 2002 04:43:25 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0FCg8l88003; Tue, 15 Jan 2002 14:42:08 +0200 (EET) (envelope-from ru) Date: Tue, 15 Jan 2002 14:42:08 +0200 From: Ruslan Ermilov To: Luigi Rizzo Cc: chkno@dork.com, freebsd-ipfw@FreeBSD.ORG, Ari Suutari , Brian Somers Subject: Re: ip_dummynet.c:"*** OUCH! pipe should have been idle!" Message-ID: <20020115144208.K46269@sunbay.com> References: <20020114141539.A70340@iguana.icir.org> <200201142246.g0EMkXC05128@chk.phattydomain.com> <20020114145849.A70496@iguana.icir.org> <20020115120531.C46269@sunbay.com> <20020115021839.A74391@iguana.icir.org> <20020115144045.J46269@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020115144045.J46269@sunbay.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jan 15, 2002 at 02:40:45PM +0200, Ruslan Ermilov wrote: [...] > Been there, confirmed that. Even for TCP, sendto() doesn't allocate Err, that should have said sosend(), for explicity. :-) > a socket buffer space -- it's the responsibility of the protocol's > output function, tcp_output(). Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jan 15 5:11:32 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.19]) by hub.freebsd.org (Postfix) with ESMTP id C376837B405; Tue, 15 Jan 2002 05:11:24 -0800 (PST) Received: from there (coffee.syncrontech.com [62.71.8.37]) by guinness.syncrontech.com (8.11.1/8.11.1) with SMTP id g0FD2dw92151; Tue, 15 Jan 2002 15:02:39 +0200 (EET) (envelope-from ari.suutari@syncrontech.com) Message-Id: <200201151302.g0FD2dw92151@guinness.syncrontech.com> Content-Type: text/plain; charset="iso-8859-1" From: Ari Suutari To: Ruslan Ermilov , Luigi Rizzo Subject: Re: ip_dummynet.c:"*** OUCH! pipe should have been idle!" Date: Tue, 15 Jan 2002 15:11:18 +0200 X-Mailer: KMail [version 1.3.2] Cc: chkno@dork.com, freebsd-ipfw@FreeBSD.ORG, Brian Somers References: <20020114141539.A70340@iguana.icir.org> <20020115021839.A74391@iguana.icir.org> <20020115144045.J46269@sunbay.com> In-Reply-To: <20020115144045.J46269@sunbay.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, > > Also CC:ed to Brian Somers (who committed that change) and > Ari Suutari who originally wrote natd(8). > > > Cheers, > Ruslan (who now wonders if the problem fixed in natd.c,v 1.2 was false). > If I remember correctly I was just wondering about getting an ENOBUFS error when the internet link was a slow one (because packets could be arriving from local ethernet much faster then a modem link can serve). Maybe I did think that waiting with select would be better than just drop the packet. Thinking it again it seems that dropping is not a bad thing since it would occur also if there were no natd running in similar situation. The correct fix would have been to silently drop the packet. But we have it corrected now :-) Ari S. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jan 15 9:10:14 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 8076137B400; Tue, 15 Jan 2002 09:10:03 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0FH8PJ32480; Tue, 15 Jan 2002 19:08:25 +0200 (EET) (envelope-from ru) Date: Tue, 15 Jan 2002 19:08:24 +0200 From: Ruslan Ermilov To: Ari Suutari Cc: Luigi Rizzo , chkno@dork.com, freebsd-ipfw@FreeBSD.ORG, Brian Somers Subject: Re: ip_dummynet.c:"*** OUCH! pipe should have been idle!" Message-ID: <20020115190824.C26495@sunbay.com> References: <20020114141539.A70340@iguana.icir.org> <20020115021839.A74391@iguana.icir.org> <20020115144045.J46269@sunbay.com> <200201151302.g0FD2dw92151@guinness.syncrontech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201151302.g0FD2dw92151@guinness.syncrontech.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jan 15, 2002 at 03:11:18PM +0200, Ari Suutari wrote: > Hi, > > > > Also CC:ed to Brian Somers (who committed that change) and > > Ari Suutari who originally wrote natd(8). > > > > > > Cheers, > > Ruslan (who now wonders if the problem fixed in natd.c,v 1.2 was false). > > > > If I remember correctly I was just wondering about getting an > ENOBUFS error when the internet link was a slow one > (because packets could be arriving from local ethernet > much faster then a modem link can serve). Maybe I did think > that waiting with select would be better than just drop the > packet. Thinking it again it seems that dropping is not > a bad thing since it would occur also if there were no > natd running in similar situation. > > The correct fix would have been to silently drop the packet. > > But we have it corrected now :-) > OK, I have committed the "fix" in natd.c,v 1.39. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jan 17 9:39:26 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 2328B37B420; Thu, 17 Jan 2002 09:39:12 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.3/8.11.3) id g0HHdBK98436; Thu, 17 Jan 2002 09:39:11 -0800 (PST) (envelope-from rizzo) Date: Thu, 17 Jan 2002 09:39:11 -0800 From: Luigi Rizzo To: ipfw@freebsd.org Subject: dummynet byte counters Message-ID: <20020117093911.C98289@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, i got request from some people on how can i know how many bytes were used by a dummynet pipe -- essentially i guess for accounting reasons, or to export these values with mrtg as some people do, etc. For this to work you would need to count packets and bytes coming out of the queue. But at the moment, dummynet pipes only count packets and bytes _in_, plus packet drops. There are two ways to implement this feature (which i think is useful): + add to struct dn_flow_queue a counter for bytes dropped (and while we are at it, extend the packet drop counter to 64 bits). This has the problem of requiring a reinstallation of /sbin/ipfw because the size of structures passed with getsockopt changes; + use the tot_pkts/tot_bytes field to count traffic _out_ of the pipe instead of traffic going in. This way the size of dn_flow_queue does not change, but the meaning of these two fields changes; on the other hand, some people who wrote me already thought these field counted data out. For what is worth, the wording in /sbin/ipfw's output is sufficiently vague not to require any change in that program. Obviously I am not thinking of changing before 4.5 is released, but right after that it is definitely something to do. Any preference on the solution to use ? I see some good in both of them, and the second one is to some degree a bit more transparet than the first one. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jan 17 12: 2:22 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.24]) by hub.freebsd.org (Postfix) with ESMTP id C5E6D37B420 for ; Thu, 17 Jan 2002 12:02:09 -0800 (PST) Received: from emss01g01.ems.lmco.com ([129.197.181.54]) by mailgw3a.lmco.com (8.8.8/8.8.8) with ESMTP id PAA27870; Thu, 17 Jan 2002 15:02:07 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-33 #38886) id <0GQ300O01M8HPM@lmco.com>; Thu, 17 Jan 2002 12:00:17 -0800 (PST) Received: from cui1.lmms.lmco.com ([129.197.1.64]) by lmco.com (PMDF V5.2-33 #38886) with ESMTP id <0GQ300E8LM8D6L@lmco.com>; Thu, 17 Jan 2002 12:00:13 -0800 (PST) Received: from lmco.com (CONNECTICUT1.lmms.lmco.com [129.197.99.14]) by cui1.lmms.lmco.com (8.11.0/8.9.2) with ESMTP id g0HK0C627798; Thu, 17 Jan 2002 12:00:12 -0800 (PST) Date: Thu, 17 Jan 2002 11:59:30 -0800 From: rick norman Subject: Re: dummynet byte counters To: Luigi Rizzo Cc: ipfw@freebsd.org Message-id: <3C472D22.A1BECD0D@lmco.com> MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20020117093911.C98289@iguana.icir.org> Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG For what it's worth, I currently use a pipe with an ipfw 'in' rule to monitor the bw fanning in to a pipe from several variable sources. In this case I'm interested in the total delivered from several external nodes. I like the ability to drop a pipe into any data stream I choose in a potentially complex test bed and monitor it without perturbing it significantly. It would seem that there might be occasions where one would want to monitor the data stream both coming to the queue and leaving depending on your test setup. Rick Luigi Rizzo wrote: > Hi, > i got request from some people on how can i know how many > bytes were used by a dummynet pipe -- essentially i guess > for accounting reasons, or to export these values with > mrtg as some people do, etc. > > For this to work you would need to count packets and bytes > coming out of the queue. But at the moment, dummynet pipes > only count packets and bytes _in_, plus packet drops. > > There are two ways to implement this feature (which i > think is useful): > > + add to struct dn_flow_queue a counter for bytes dropped (and while we > are at it, extend the packet drop counter to 64 bits). > This has the problem of requiring a reinstallation of /sbin/ipfw > because the size of structures passed with getsockopt changes; > > + use the tot_pkts/tot_bytes field to count traffic _out_ > of the pipe instead of traffic going in. > This way the size of dn_flow_queue does not change, but the > meaning of these two fields changes; on the other hand, some > people who wrote me already thought these field counted data > out. For what is worth, the wording in /sbin/ipfw's output is > sufficiently vague not to require any change in that program. > > Obviously I am not thinking of changing before 4.5 is released, > but right after that it is definitely something to do. > Any preference on the solution to use ? > I see some good in both of them, and the second one is to some > degree a bit more transparet than the first one. > > cheers > luigi > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jan 17 14:13:19 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from blackbox.greystork.com (sub27-6.member.dsl-only.net [63.105.27.6]) by hub.freebsd.org (Postfix) with ESMTP id 62A8437B404 for ; Thu, 17 Jan 2002 14:13:16 -0800 (PST) Received: (from nobody@localhost) by blackbox.greystork.com (8.11.3/8.11.3) id g0HMDFW21975 for ipfw@freebsd.org; Thu, 17 Jan 2002 14:13:15 -0800 (PST) (envelope-from flemming@froekjaer.org) X-Authentication-Warning: blackbox.greystork.com: nobody set sender to flemming@froekjaer.org using -f To: ipfw@freebsd.org Subject: ipfw and nat Message-ID: <1011305595.3c474c7ba1e17@greystork.com> Date: Thu, 17 Jan 2002 14:13:15 -0800 (PST) From: =?ISO-8859-1?Q?Flemming_Fr=F8kj=E6r?= MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.7 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I cant get thrue my firewall. If I try to ping the firewall or anything outside I get a no response, and if I try to ping from the firewall to a ip behind it I get a permission denied, or something like that. I tryed to go to grab a web page outside the firewall, and it seemed like after droping a lot of the packages I got something thrue, but it was only a small fragment of the packages. Any hints to what I'm doing wrong would be most wellcome. /Flemming Kernel is 4.5RC and I have added: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100options IPDIVERT In RC.conf I have: ifconfig_fxp0="inet xxx.xxx.xxx.xxx netmask 255.255.255.252" ifconfig_fxp0="inet 192.168.111.1 netmask 255.255.255.0"defaultrouter="xxx.xxx.xxx.xxy" gateway_enable="YES" firewall_enable="YES" firewall_type="simple" natd_enable="YES" natd_interface="fxp0" If I set the firewall_type to open then I can get out, but I would like a little more security than that. in rc.firewall I have edited the following: oif="fxp0" onet="xxx.xxx.xxx.xxz" omask="255.255.255.252" oip="xxx.xxx.xxx.xxx" iif="fxp1" inet="192.168.111.0" imask="255.255.255.0" iip="192.168.111.1" Everything else is left to default. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jan 17 15:49:32 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 7C89237B404 for ; Thu, 17 Jan 2002 15:49:30 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.3/8.11.3) id g0HNnMj00895; Thu, 17 Jan 2002 15:49:22 -0800 (PST) (envelope-from rizzo) Date: Thu, 17 Jan 2002 15:49:22 -0800 From: Luigi Rizzo To: rick norman Cc: ipfw@FreeBSD.ORG Subject: Re: dummynet byte counters Message-ID: <20020117154921.E99085@iguana.icir.org> References: <20020117093911.C98289@iguana.icir.org> <3C472D22.A1BECD0D@lmco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C472D22.A1BECD0D@lmco.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jan 17, 2002 at 11:59:30AM -0800, rick norman wrote: > For what it's worth, I currently use a pipe with an ipfw 'in' rule to > monitor the bw fanning in to a pipe from several variable sources. In this > case I'm > interested in the total delivered from several external nodes. I like the > ability to drop a pipe into any data stream I choose in a potentially > complex test bed and monitor it without perturbing it significantly. > > It would seem that there might be occasions where one would want to > monitor the data stream both coming to the queue and leaving depending on > your test setup. so you call for the first method, though note that if the pipe does not have any bw limit then in and out are the same thing cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jan 17 15:55:36 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.24]) by hub.freebsd.org (Postfix) with ESMTP id CEE5337B419 for ; Thu, 17 Jan 2002 15:55:32 -0800 (PST) Received: from emss01g01.ems.lmco.com ([129.197.181.54]) by mailgw3a.lmco.com (8.8.8/8.8.8) with ESMTP id SAA17769; Thu, 17 Jan 2002 18:55:31 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-33 #38886) id <0GQ300J01X4IEN@lmco.com>; Thu, 17 Jan 2002 15:55:30 -0800 (PST) Received: from cui1.lmms.lmco.com ([129.197.1.64]) by lmco.com (PMDF V5.2-33 #38886) with ESMTP id <0GQ3005NQX4DAU@lmco.com>; Thu, 17 Jan 2002 15:55:25 -0800 (PST) Received: from lmco.com (CONNECTICUT1.lmms.lmco.com [129.197.99.14]) by cui1.lmms.lmco.com (8.11.0/8.9.2) with ESMTP id g0HNtO618040; Thu, 17 Jan 2002 15:55:24 -0800 (PST) Date: Thu, 17 Jan 2002 15:54:44 -0800 From: rick norman Subject: Re: dummynet byte counters To: Luigi Rizzo Cc: ipfw@freebsd.org Message-id: <3C476444.F8297B8B@lmco.com> MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20020117093911.C98289@iguana.icir.org> <3C472D22.A1BECD0D@lmco.com> <20020117154921.E99085@iguana.icir.org> Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Actually I would like to see counters on in and out, though I can easily adapt to whatever you do. Rick Luigi Rizzo wrote: > On Thu, Jan 17, 2002 at 11:59:30AM -0800, rick norman wrote: > > For what it's worth, I currently use a pipe with an ipfw 'in' rule to > > monitor the bw fanning in to a pipe from several variable sources. In this > > case I'm > > interested in the total delivered from several external nodes. I like the > > ability to drop a pipe into any data stream I choose in a potentially > > complex test bed and monitor it without perturbing it significantly. > > > > It would seem that there might be occasions where one would want to > > monitor the data stream both coming to the queue and leaving depending on > > your test setup. > > so you call for the first method, though note that if the > pipe does not have any bw limit then in and out are the same thing > > cheers > luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jan 17 15:57:30 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 72D9837B402 for ; Thu, 17 Jan 2002 15:57:25 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.3/8.11.3) id g0HNvMh01027; Thu, 17 Jan 2002 15:57:22 -0800 (PST) (envelope-from rizzo) Date: Thu, 17 Jan 2002 15:57:22 -0800 From: Luigi Rizzo To: rick norman Cc: ipfw@freebsd.org Subject: Re: dummynet byte counters Message-ID: <20020117155722.A978@iguana.icir.org> References: <20020117093911.C98289@iguana.icir.org> <3C472D22.A1BECD0D@lmco.com> <20020117154921.E99085@iguana.icir.org> <3C476444.F8297B8B@lmco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C476444.F8297B8B@lmco.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jan 17, 2002 at 03:54:44PM -0800, rick norman wrote: > Actually I would like to see counters on in and out, though I can > easily adapt to whatever you do. the first method includes all -- in, in-transit, drops and by difference you can compute the out luigi > Rick > > Luigi Rizzo wrote: > > > On Thu, Jan 17, 2002 at 11:59:30AM -0800, rick norman wrote: > > > For what it's worth, I currently use a pipe with an ipfw 'in' rule to > > > monitor the bw fanning in to a pipe from several variable sources. In this > > > case I'm > > > interested in the total delivered from several external nodes. I like the > > > ability to drop a pipe into any data stream I choose in a potentially > > > complex test bed and monitor it without perturbing it significantly. > > > > > > It would seem that there might be occasions where one would want to > > > monitor the data stream both coming to the queue and leaving depending on > > > your test setup. > > > > so you call for the first method, though note that if the > > pipe does not have any bw limit then in and out are the same thing > > > > cheers > > luigi > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jan 17 23:27:11 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 2DCF137B405 for ; Thu, 17 Jan 2002 23:27:08 -0800 (PST) Received: from dialup-209.244.107.191.dial1.sanjose1.level3.net ([209.244.107.191] helo=blossom.cjclark.org) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16RTQO-0004Oi-00; Thu, 17 Jan 2002 23:27:00 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id g0I7Q7k42377; Thu, 17 Jan 2002 23:26:07 -0800 (PST) (envelope-from cjc) Date: Thu, 17 Jan 2002 23:26:04 -0800 From: "Crist J . Clark" To: =?iso-8859-1?Q?Flemming_Fr=F8kj=E6r?= Cc: ipfw@FreeBSD.ORG Subject: Re: ipfw and nat Message-ID: <20020117232604.D40472@blossom.cjclark.org> References: <1011305595.3c474c7ba1e17@greystork.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <1011305595.3c474c7ba1e17@greystork.com>; from flemming@froekjaer.org on Thu, Jan 17, 2002 at 02:13:15PM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jan 17, 2002 at 02:13:15PM -0800, Flemming Frøkjær wrote: [snip] > In RC.conf I have: > ifconfig_fxp0="inet xxx.xxx.xxx.xxx netmask 255.255.255.252" > ifconfig_fxp0="inet 192.168.111.1 netmask > 255.255.255.0"defaultrouter="xxx.xxx.xxx.xxy" A few typos and cut-n-paste problems here? Is it really, ifconfig_fxp0="inet xxx.xxx.xxx.xxx netmask 255.255.255.252" ifconfig_fxp1="inet 192.168.111.1 netmask 255.255.255.0" defaultrouter="xxx.xxx.xxx.xxy" (Changed the second interface name and put the default router on its own line.) -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message