From owner-freebsd-net Sun Jun 18 5:34:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from mms.mine.nu (ppp55.adl.iweb.net.au [202.12.71.119]) by hub.freebsd.org (Postfix) with ESMTP id E016137B9E7 for ; Sun, 18 Jun 2000 05:34:40 -0700 (PDT) (envelope-from matts@thepentagon.com) Received: from matt2 (matt.mms.mine.nu [10.1.1.100]) by mms.mine.nu (8.9.3/8.9.3) with ESMTP id WAA30874 for ; Sun, 18 Jun 2000 22:08:07 +0930 (CST) (envelope-from matts@thepentagon.com) Message-ID: <200006182206450618.2040B2A2@10.1.1.105> X-Mailer: Calypso Version 3.00.00.13 (1) Date: Sun, 18 Jun 2000 22:06:45 +0930 Reply-To: matts@thepentagon.com From: "Matt" To: freebsd-net@FreeBSD.ORG Subject: ppp bandwidth monitoring Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I'm after a small utility to keep track of the amount of data downloaded over a ppp connection, throughout all sessions (user ppp, in ddial mode) until cleared or reset. Thanks for your help, Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 18 9: 7:58 2000 Delivered-To: freebsd-net@freebsd.org Received: from WEBSI.com (websi.com [216.156.137.66]) by hub.freebsd.org (Postfix) with ESMTP id 441F337B6C8; Sun, 18 Jun 2000 09:07:45 -0700 (PDT) (envelope-from shashi@WEBSI.com) Received: (from shashi@localhost) by WEBSI.com (8.9.3/8.9.3) id MAA11464; Sun, 18 Jun 2000 12:28:28 -0400 (EDT) (envelope-from shashi) Date: Sun, 18 Jun 2000 12:28:28 -0400 From: shashi To: freebsd-net@freebsd.org Subject: 4.0 and ppp not working? Message-ID: <20000618122828.A11420@Shift-F1.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I am not sure exactly which list this belongs to, so I am posting it on net, isp and stable. Forgive me for the extra bandwidth used. I have been using FreeBSD for 3 years now, and touch wood, things have always been smooth enough. So I haven't made much use of the mailing lists. For the current issue I have spent over 5 hours in the archives with no success. I found similar situations but no answers to the problem, at least none that apply to my situation. Here is the description: 1. ppp has always worked for dialing out on previous versions, 2x, 3.2(?) 2. I installed 4.0 from CD 2 days back. I must say there are a few new things that I am not sure of that may have caused problem, maybe? e.g. in install it asked if this machine will be a leaf node. I answered it "NO". Also, is IPv6 or IPsec the cause of any problems? Meaning does that need different handling all over the network commands? 3. this is what I did: % cd /dev % ./MAKEDEV tun0 % cp /usr/share/examples/ppp/ppp.conf.sample /etc/ppp/ppp.conf ----- /etc/ppp/ppp.conf after modification: ---- ########################################################### default: set log Phase Chat LCP IPCP CCP tun command set device /dev/cuaa1 set speed 115200 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT \ OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" set redial 10 5 deny lqr set phone _PHONENUMBERHERE_ set login "ABORT NO\\sCARRIER TIMEOUT 5 ogin:--ogin: _USERID_ word: _PASSWORD_" set timeout 120 set ifaddr 10.0.0.1/0 delete ALL add default HISADDR pmdemand: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 delete ALL set redial 10 20 add default HISADDR enable dns ########################################################### % ppp -ddial pmdemand 4. The thing is the SAME file works on 3.2 with same modem, same jack, same isp. Now, first time, the modem dials, makes connection then it says "Warning: Chat script failed".A After that, I do pppctl and a "quit all", then retry by % ppp -ddial pmdemand and the modem doesn't even ring. and gives the same errors. Any help will be highly appreciated. I am using default kernel right now, and I need ppp to CVS to latest upgrade. Thanks, Shashi Here is ppp.log: ( I have replaced _USERID_, _PASSWORD_ and _PHONENUM_) Jun 18 11:20:44 ugrads ppp[806]: Phase: Using interface: tun0 Jun 18 11:20:44 ugrads ppp[806]: Phase: deflink: Created in closed state Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: default: set device /dev/cuaa1 Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: default: set speed 115200 Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: default: set dial ABORT BUSY ABORT NO\sCARRIER TIMEOUT 5 "" AT OK-AT-OK ATE1Q0 OK \dATDT\T TIMEOUT 40 CONNECT Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: default: set redial 10 5 Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: default: deny lqr Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: default: set phone _PHONE_NUM_ Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: default: set login ABORT NO\sCARRIER TIMEOUT 5 ogin:--ogin: _USERID_ word: _PASSWORD_ Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: default: set timeout 120 Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: default: set ifaddr 10.0.0.1/0 Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: default: delete ALL Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: default: add default HISADDR Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: default: set server +3000 ******** Jun 18 11:20:44 ugrads ppp[806]: tun0: Phase: Listening at port 3000. Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: pmdemand: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: pmdemand: delete ALL Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: pmdemand: set redial 10 20 Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: pmdemand: add default HISADDR Jun 18 11:20:44 ugrads ppp[806]: tun0: Command: pmdemand: enable dns Jun 18 11:20:44 ugrads ppp[807]: tun0: Phase: PPP Started (ddial mode). Jun 18 11:20:44 ugrads ppp[807]: tun0: Phase: bundle: Establish Jun 18 11:20:44 ugrads ppp[807]: tun0: Phase: deflink: closed -> opening Jun 18 11:20:44 ugrads ppp[807]: tun0: Phase: deflink: Connected! Jun 18 11:20:44 ugrads ppp[807]: tun0: Phase: deflink: opening -> dial Jun 18 11:20:44 ugrads ppp[807]: tun0: Phase: Phone: _PHONE_NUM_ Jun 18 11:20:44 ugrads ppp[807]: tun0: Chat: Send: AT^M Jun 18 11:20:44 ugrads ppp[807]: tun0: Chat: Expect(5): OK Jun 18 11:20:45 ugrads ppp[807]: tun0: Chat: Received: AT^M^M Jun 18 11:20:45 ugrads ppp[807]: tun0: Chat: Received: OK^M Jun 18 11:20:45 ugrads ppp[807]: tun0: Chat: Send: ATE1Q0^M Jun 18 11:20:45 ugrads ppp[807]: tun0: Chat: Expect(5): OK Jun 18 11:20:45 ugrads ppp[807]: tun0: Chat: Received: ATE1Q0^M^M Jun 18 11:20:45 ugrads ppp[807]: tun0: Chat: Received: OK^M Jun 18 11:20:45 ugrads ppp[807]: tun0: Chat: Send: ATDT_PHONE_NUM_^M Jun 18 11:20:47 ugrads ppp[807]: tun0: Chat: Expect(40): CONNECT Jun 18 11:21:28 ugrads ppp[807]: tun0: Chat: Expect timeout Jun 18 11:21:28 ugrads ppp[807]: tun0: Warning: Chat script failed Jun 18 11:21:28 ugrads ppp[807]: tun0: Phase: deflink: dial -> hangup Jun 18 11:21:28 ugrads ppp[807]: tun0: Phase: deflink: Disconnected! Jun 18 11:21:28 ugrads ppp[807]: tun0: Phase: deflink: Connect time: 44 secs: 0 octets in, 0 octets out Jun 18 11:21:28 ugrads ppp[807]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Sun Jun 18 11:21:28 2000 Jun 18 11:21:28 ugrads ppp[807]: tun0: Phase: deflink: hangup -> opening Jun 18 11:21:28 ugrads ppp[807]: tun0: Phase: deflink: Enter pause (10) for redialing. Jun 18 11:21:38 ugrads ppp[807]: tun0: Phase: deflink: Redial timer expired. Jun 18 11:21:38 ugrads ppp[807]: tun0: Phase: deflink: Connected! Jun 18 11:21:38 ugrads ppp[807]: tun0: Phase: deflink: opening -> dial Jun 18 11:21:38 ugrads ppp[807]: tun0: Phase: Phone: _PHONE_NUM_ Jun 18 11:21:38 ugrads ppp[807]: tun0: Chat: Send: AT^M Jun 18 11:21:38 ugrads ppp[807]: tun0: Chat: Expect(5): OK Jun 18 11:21:43 ugrads ppp[807]: tun0: Chat: Expect timeout Jun 18 11:21:43 ugrads ppp[807]: tun0: Chat: Send: AT^M Jun 18 11:21:43 ugrads ppp[807]: tun0: Chat: Expect(5): OK Jun 18 11:21:48 ugrads ppp[807]: tun0: Chat: Expect timeout Jun 18 11:21:48 ugrads ppp[807]: tun0: Warning: Chat script failed Jun 18 11:21:48 ugrads ppp[807]: tun0: Phase: deflink: dial -> hangup Jun 18 11:21:48 ugrads ppp[807]: tun0: Phase: deflink: Disconnected! Jun 18 11:21:48 ugrads ppp[807]: tun0: Phase: deflink: Connect time: 10 secs: 0 octets in, 0 octets out Jun 18 11:21:48 ugrads ppp[807]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Sun Jun 18 11:21:48 2000 Jun 18 11:21:48 ugrads ppp[807]: tun0: Phase: deflink: hangup -> opening Jun 18 11:21:48 ugrads ppp[807]: tun0: Phase: deflink: Enter pause (10) for redialing. Jun 18 11:21:58 ugrads ppp[807]: tun0: Phase: deflink: Redial timer expired. Jun 18 11:21:58 ugrads ppp[807]: tun0: Phase: deflink: Connected! Jun 18 11:21:58 ugrads ppp[807]: tun0: Phase: deflink: opening -> dial Jun 18 11:21:58 ugrads ppp[807]: tun0: Phase: Phone: _PHONE_NUM_ Jun 18 11:21:58 ugrads ppp[807]: tun0: Chat: Send: AT^M Jun 18 11:21:58 ugrads ppp[807]: tun0: Chat: Expect(5): OK ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 18 9:58:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id 9092937B62C for ; Sun, 18 Jun 2000 09:58:42 -0700 (PDT) (envelope-from pherman@frenchfries.net) Received: from bagabeedaboo.security.at12.de (dial-194-8-205-146.netcologne.de [194.8.205.146]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id SAA23019; Sun, 18 Jun 2000 18:58:36 +0200 (MET DST) Received: from localhost (localhost.security.at12.de [127.0.0.1]) by bagabeedaboo.security.at12.de (8.10.1/8.10.1) with ESMTP id e5IGvq300382; Sun, 18 Jun 2000 18:57:52 +0200 (CEST) Date: Sun, 18 Jun 2000 18:57:51 +0200 (CEST) From: Paul Herman To: Matt Cc: freebsd-net@FreeBSD.ORG Subject: Re: ppp bandwidth monitoring In-Reply-To: <200006182206450618.2040B2A2@10.1.1.105> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 18 Jun 2000, Matt wrote: > I'm after a small utility to keep track of the amount of data > downloaded over a ppp connection, throughout all sessions (user > ppp, in ddial mode) until cleared or reset. There are a few ways to do this, all have ways of showing the amount of data. * user ppp a 'show proto' will give you a breakdown of all kindsa protocols. * 'netstat 5' will show you the *total* amount of traffic on the machine (probably not what you want.) * /usr/ports/net/ntop will show you the current bandwidth on a particular interface (like tun0, for example.) * tcpstat will monitor a particular interface (or tcpdump file) and give you statistics on a particular interface (bandwidth, packets per second, avg. packet size, protocol breakdowns, etc.) pretty powerful/configurable. http://www.frenchfries.net/paul/tcpstat/ * MRTG will graph all this for you (if you aren't looking for numbers) http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html All do basically the same thing in very different ways, if you are looking to count bytes over an interface. -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 18 12: 3:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id 6AB1337B5FC for ; Sun, 18 Jun 2000 12:03:29 -0700 (PDT) (envelope-from ras@e-gerbil.net) Received: from localhost (ras@localhost) by overlord.e-gerbil.net (8.9.3/8.9.3) with ESMTP id PAA75753 for ; Sun, 18 Jun 2000 15:03:28 -0400 (EDT) (envelope-from ras@e-gerbil.net) X-Authentication-Warning: overlord.e-gerbil.net: ras owned process doing -bs Date: Sun, 18 Jun 2000 15:03:28 -0400 (EDT) From: "Richard A. Steenbergen" To: freebsd-net@freebsd.org Subject: Auto-scaling socket buffers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org PREAMBLE: I had an interesting thought. As we all know, thruput is a product of bandwidth and delay, and achieving high thruput across high latency high bandwidth pipes is accomplished by using large TCP windows to keep sufficient packets in flight while awaiting ACKs (see rfc1323). Maximium TCP window size is limited by socket buffer size, which by default is set to 16k each in send and recv direction (net.inet.ip.sendspace/recvspace), changable by setsockopt() SO_SNDBUF SO_RCVBUF, up to a maximium of 256k total for BOTH buffers (kern.ipc.maxsockbuf). The maximium value for a TCP window without using rfc1323 window scaling is 2**16 (64k) as limited by the window field in the tcp header. An application expecting to do high performance transfers should consider increasing this value on the data sockets (ftp/ftpd for example, which currently does not do this). Even Linux has caught on and now defaults to 64k buffers with rfc1323 features enabled by default. Unfortunantly one of the arguements against simply increasing the default to something like 64k (or higher, I increase my maxsockbuf and send/recv space to 256k in each direction for good transfer speeds from europe to the USA), is that it reserves this much buffer memory in sbreserve() calls for every socket. For some sockets this is an absurdly high number (for example, an irc server with 10,000 client sockets which would probably be quite content at 4k, and a few server sockets which need to eat a connect burst quickly, though this is a poor example because any such sane server should be doing this itself), and wastes memory. IDEA: Which leads to my idea. Automatically scale the socket buffer when the TCP window is exausted and the reason it cannot be extended is the sockbuf. This would allow the default recvspace/sendspace to be set to something like 4k, but still allow performance sockets to quickly scale upwards to a set limit, to achieve maximium thruput. -- Richard A Steenbergen http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 18 12:39:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 2FB6A37B997 for ; Sun, 18 Jun 2000 12:39:19 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id MAA15444; Sun, 18 Jun 2000 12:30:24 -0700 (PDT) Message-Id: <200006181930.MAA15444@implode.root.com> To: "Richard A. Steenbergen" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Auto-scaling socket buffers In-reply-to: Your message of "Sun, 18 Jun 2000 15:03:28 EDT." From: David Greenman Reply-To: dg@root.com Date: Sun, 18 Jun 2000 12:30:24 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >IDEA: > >Which leads to my idea. Automatically scale the socket buffer when the TCP >window is exausted and the reason it cannot be extended is the sockbuf. >This would allow the default recvspace/sendspace to be set to something >like 4k, but still allow performance sockets to quickly scale upwards to a >set limit, to achieve maximium thruput. This idea sounds familiar and I think it has been suggested before. It does seem like a good idea. One concern that I have is the case of a saturated local (ethernet) circuit, causing the delay to increase due to buffering in the network device driver and perhaps in the nearby upstream switches. Since the problem is lack of bandwidth that is causing the delay to increase, it seems that the new algorithm would behave badly - increasing the socket buffer space on all connections needlessly. In other words, it might be a bad assumption that delay is caused by speed of light lag when it might instead be caused by network congestion which isn't helped by increasing the amount of buffering. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 18 13:13:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id DE0E637B574 for ; Sun, 18 Jun 2000 13:13:09 -0700 (PDT) (envelope-from ras@e-gerbil.net) Received: from localhost (ras@localhost) by overlord.e-gerbil.net (8.9.3/8.9.3) with ESMTP id QAA19547; Sun, 18 Jun 2000 16:13:07 -0400 (EDT) (envelope-from ras@e-gerbil.net) X-Authentication-Warning: overlord.e-gerbil.net: ras owned process doing -bs Date: Sun, 18 Jun 2000 16:13:06 -0400 (EDT) From: "Richard A. Steenbergen" To: David Greenman Cc: freebsd-net@FreeBSD.ORG Subject: Re: Auto-scaling socket buffers In-Reply-To: <200006181930.MAA15444@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 18 Jun 2000, David Greenman wrote: > >IDEA: > > > >Which leads to my idea. Automatically scale the socket buffer when the TCP > >window is exausted and the reason it cannot be extended is the sockbuf. > >This would allow the default recvspace/sendspace to be set to something > >like 4k, but still allow performance sockets to quickly scale upwards to a > >set limit, to achieve maximium thruput. > > This idea sounds familiar and I think it has been suggested before. It > does seem like a good idea. One concern that I have is the case of a saturated > local (ethernet) circuit, causing the delay to increase due to buffering > in the network device driver and perhaps in the nearby upstream switches. > Since the problem is lack of bandwidth that is causing the delay to increase, > it seems that the new algorithm would behave badly - increasing the socket > buffer space on all connections needlessly. In other words, it might be a bad > assumption that delay is caused by speed of light lag when it might instead be > caused by network congestion which isn't helped by increasing the amount of > buffering. This could affect our transmitions, and thus the send buffer, but not the recv buffer. if you've received so much data that you've maxed your socket buffer and are sending a window of 0 on your ACKs, you're confident that its not a lack of bandwidth but rather a lack of buffer space -- This can all be determined locally. In reality the recv buffer is the one we're concerned with anyways, as it would have to be the other side adjusting its recv buffer for our uploads to show any performance increases. -- Richard A Steenbergen http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 18 13:49:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 3E7C037BAA8 for ; Sun, 18 Jun 2000 13:49:34 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id NAA15590; Sun, 18 Jun 2000 13:40:36 -0700 (PDT) Message-Id: <200006182040.NAA15590@implode.root.com> To: "Richard A. Steenbergen" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Auto-scaling socket buffers In-reply-to: Your message of "Sun, 18 Jun 2000 16:13:06 EDT." From: David Greenman Reply-To: dg@root.com Date: Sun, 18 Jun 2000 13:40:36 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >On Sun, 18 Jun 2000, David Greenman wrote: > >> >IDEA: >> > >> >Which leads to my idea. Automatically scale the socket buffer when the TCP >> >window is exausted and the reason it cannot be extended is the sockbuf. >> >This would allow the default recvspace/sendspace to be set to something >> >like 4k, but still allow performance sockets to quickly scale upwards to a >> >set limit, to achieve maximium thruput. >> >> This idea sounds familiar and I think it has been suggested before. It >> does seem like a good idea. One concern that I have is the case of a saturated >> local (ethernet) circuit, causing the delay to increase due to buffering >> in the network device driver and perhaps in the nearby upstream switches. >> Since the problem is lack of bandwidth that is causing the delay to increase, >> it seems that the new algorithm would behave badly - increasing the socket >> buffer space on all connections needlessly. In other words, it might be a bad >> assumption that delay is caused by speed of light lag when it might instead be >> caused by network congestion which isn't helped by increasing the amount of >> buffering. > >This could affect our transmitions, and thus the send buffer, but not the >recv buffer. if you've received so much data that you've maxed your socket >buffer and are sending a window of 0 on your ACKs, you're confident that >its not a lack of bandwidth but rather a lack of buffer space -- This can >all be determined locally. In reality the recv buffer is the one we're >concerned with anyways, as it would have to be the other side adjusting >its recv buffer for our uploads to show any performance increases. FreeBSD rarely sends a window of 0. It usually only happens when the machine is so overloaded that it can't keep up with the input stream. I do agree, however, that advertising a larger receive window is needed in order for the transmitter to fill up a long pipe. The thing is that a dynamic adjustment that is based on a filled-up receiver isn't going to work for that. Of course it also 'takes two to tango', so not also increasing the transmitter socket buffer would defeat a larger receive buffer even if you could find a good algorithm for dynamically increasing the receive side socket space. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 18 14:13:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp2.maxim.net (smtp2.maxim.net [206.171.12.25]) by hub.freebsd.org (Postfix) with ESMTP id EBE2C37BB98; Sun, 18 Jun 2000 14:13:36 -0700 (PDT) (envelope-from Arabian@ArabChat.Org) Received: from qatar ([212.77.193.23]) by smtp2.maxim.net (8.8.4/8.6.9) with SMTP id OAA31709; Sun, 18 Jun 2000 14:13:21 -0700 Message-ID: <001901bfd969$5ddb2660$17c14dd4@qatar.net.qa> Reply-To: "Abdullah Bin Hamad" From: "Abdullah Bin Hamad" To: Cc: Subject: Free WebMail. Date: Mon, 19 Jun 2000 00:08:04 +0300 Organization: ArabChat IRC Network MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello folks, I'm about to run web mail and I need open source one. Please direct me to nice one. PS: I'm not on this list please email me directly. Best Regards, -Arabian aka Abdullah To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 18 15:38:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from pop.idx.com.au (pop.idx.com.au [203.14.30.10]) by hub.freebsd.org (Postfix) with ESMTP id 9C88637BA72; Sun, 18 Jun 2000 15:38:19 -0700 (PDT) (envelope-from dannyh@idx.com.au) Received: from desktop.freebsd.org (tntwc01-3-126.idx.com.au [203.166.3.126]) by pop.idx.com.au (8.9.3/8.9.3) with SMTP id IAA21260; Mon, 19 Jun 2000 08:37:58 +1000 From: Danny To: "Abdullah Bin Hamad" , "Abdullah Bin Hamad" , Subject: Re: Free WebMail. Date: Tue, 20 Jun 2000 08:44:46 +1000 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain Cc: References: <001901bfd969$5ddb2660$17c14dd4@qatar.net.qa> MIME-Version: 1.0 Message-Id: <00062008465504.00328@desktop.freebsd.org> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thre was this question only 2 days ago from another different person Anyway, Try www.atdot.org is a free email client written in PERL and is free for you to modify and customize to your own needs. Is very good once you have a understanding of PERL On Mon, 19 Jun 2000, Abdullah Bin Hamad wrote: > Hello folks, > > I'm about to run web mail and I need open source one. > > Please direct me to nice one. > > PS: I'm not on this list please email me directly. > > Best Regards, > > -Arabian aka Abdullah > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message -- ------------------------------------------------------------ You are not authorized to use my email address for spam or any purpose whatsoever. Remove my email address from your databases immediately and do not attempt to email me in any way. ------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 18 21:28:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id 46D4437BB34 for ; Sun, 18 Jun 2000 21:28:08 -0700 (PDT) (envelope-from ras@e-gerbil.net) Received: from localhost (ras@localhost) by overlord.e-gerbil.net (8.9.3/8.9.3) with ESMTP id AAA09762; Mon, 19 Jun 2000 00:28:04 -0400 (EDT) (envelope-from ras@e-gerbil.net) X-Authentication-Warning: overlord.e-gerbil.net: ras owned process doing -bs Date: Mon, 19 Jun 2000 00:28:04 -0400 (EDT) From: "Richard A. Steenbergen" To: David Greenman Cc: freebsd-net@FreeBSD.ORG Subject: Re: Auto-scaling socket buffers In-Reply-To: <200006182040.NAA15590@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 18 Jun 2000, David Greenman wrote: > >This could affect our transmitions, and thus the send buffer, but not the > >recv buffer. if you've received so much data that you've maxed your socket > >buffer and are sending a window of 0 on your ACKs, you're confident that > >its not a lack of bandwidth but rather a lack of buffer space -- This can > >all be determined locally. In reality the recv buffer is the one we're > >concerned with anyways, as it would have to be the other side adjusting > >its recv buffer for our uploads to show any performance increases. > > FreeBSD rarely sends a window of 0. It usually only happens when the > machine is so overloaded that it can't keep up with the input stream. I do > agree, however, that advertising a larger receive window is needed in order > for the transmitter to fill up a long pipe. The thing is that a dynamic > adjustment that is based on a filled-up receiver isn't going to work for > that. Of course it also 'takes two to tango', so not also increasing the > transmitter socket buffer would defeat a larger receive buffer even if > you could find a good algorithm for dynamically increasing the receive > side socket space. But you still know if you are receiving enough of an input stream to open up the window. Infact you know this part already, its simply a matter of extending it to opening up the socket buffer as well. As for the "two to tango", I'm trying to find the code related to this. It makes logical sense that you would need to have a socket buffer sufficient to store all the in-flight packets if you were called upon to do a retransmit, regardless of the window being advertised by the receiver, but the test numbers don't seem to match up with this (I get significantly reduced performance at 4k but equal performance with sendspace of 16k or 256k). At any rate, scaling the send buffer can only increase the potential for performance, not the congestion/buffering, as this is handled entirely by the TCP windows, which will shrink upon congestion. We're just talking about expanding the POTENTIAL for TCP windows to expand as needed by increasing socket buffers in a sensable fashion. -- Richard A Steenbergen http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 18 21:58:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from modemcable127.61-201-24.mtl.mc.videotron.net (modemcable127.61-201-24.mtl.mc.videotron.net [24.201.61.127]) by hub.freebsd.org (Postfix) with SMTP id 25CB237BBB9 for ; Sun, 18 Jun 2000 21:58:44 -0700 (PDT) (envelope-from patrick@mindstep.com) Received: (qmail 18441 invoked from network); 19 Jun 2000 04:58:43 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 19 Jun 2000 04:58:43 -0000 Message-ID: <00f201bfd9ab$06cd8330$040aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: Cc: "\"clemensF\"" , , References: <200006160812.JAA01790@hak.lan.Awfulhak.org> <20000616160623.A5968@spotteswoode.de> <013101bfd7aa$b2949f80$040aa8c0@local.mindstep.com> Subject: Re: "frag-anyways" knob. Date: Mon, 19 Jun 2000 00:58:36 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EF_01BFD989.7F9EBE40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_00EF_01BFD989.7F9EBE40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi All, As promised here is my set of patch that update the MSS option in outbound TCP packets based on a specified value for the MTU. The patch is for libalias and natd. The libalias part is where all the action takes place. The patch for natd is usefull for setting a specific value for the MTU. I have added an option called "-link_mtu ". If this option is not specified, the MTU of the interface indicated with "-n" is used instead. I have done some testing between 2 FreeBSD boxen and I observe the expected behavior: The MSS of the outbounds TCP packets is changed, the packets comming back honor the advertised max segment size. The inbound packets are left as is. I tried to update the userland PPP code to indicate the Link MTU to libalias, but I don't think I am succesfull with it yet. I have included the patch for PPP as well, but I don't think it works properly. I would appreciate help in that area. The patches are activated by defining "MSS_UPDATE_HACK" at compile time. Of course this hack can only help with the problem of "frag needed" notifications lost for TCP sessions. Other protocols (UDP and friends) are not modified in any way. Finally I am including the traces I have taken with tcpdump and natd for my tests. Please let me know what you think of this, and if it is working for you. Patrick. -- Patrick Bihan-Faou MindStep Corporation - MindBox Technologies ------=_NextPart_000_00EF_01BFD989.7F9EBE40 Content-Type: application/octet-stream; name="MSS_HACK_libalias.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="MSS_HACK_libalias.patch" --- alias.c.orig Fri Sep 10 11:27:34 1999=0A= +++ alias.c Mon Jun 19 00:11:54 2000=0A= @@ -1027,6 +1027,63 @@=0A= =0A= ADJUST_CHECKSUM(accumulate, pip->ip_sum)=0A= =0A= +#ifdef MSS_UPDATE_HACK=0A= +/* Change the MSS if needed */=0A= + if ( (tc->th_off * 4) > sizeof(*tc) ) {=0A= + u_char *cp;=0A= + int opt, datalen;=0A= + u_short alias_mtu;=0A= + int accumulate;=0A= + int hlen;=0A= + =0A= + alias_mtu =3D GetAliasMTU(link);=0A= +=0A= +#ifdef DEBUG=0A= + fprintf(stderr, "TCP OUT -> options present, max MSS is %u\n", = alias_mtu);=0A= +#endif=0A= + if (alias_mtu > 0) {=0A= + hlen =3D tc->th_off *4;=0A= + hlen -=3D sizeof(*tc);=0A= +=0A= + cp =3D (u_char *)tc + sizeof(*tc);=0A= + while (hlen > 0) {=0A= + opt =3D *cp++;=0A= + --hlen; /* account for type byte */=0A= + if (opt =3D=3D TCPOPT_EOL) {=0A= + break;=0A= + } else if (opt =3D=3D TCPOPT_NOP) {=0A= + continue;=0A= + }=0A= +=0A= + datalen =3D *cp++; /* total including type, len */=0A= + --hlen; /* account for length byte */=0A= + datalen -=3D 2; /* don't count the kind and len bytes */=0A= + if (datalen < 0 || datalen > hlen)=0A= + break;=0A= +=0A= + if (opt =3D=3D TCPOPT_MAXSEG) {=0A= +#ifdef DEBUG=0A= + fprintf(stderr, "TCP OUT -> got MSS option, value %u\n", = EXTRACT_16BITS(cp));=0A= +#endif=0A= + if (EXTRACT_16BITS(cp) > alias_mtu) {=0A= + accumulate =3D EXTRACT_16BITS_NET(cp);=0A= + ADJUST_16BITS(cp, alias_mtu);=0A= + accumulate -=3D EXTRACT_16BITS_NET(cp);=0A= + ADJUST_CHECKSUM(accumulate, tc->th_sum)=0A= +#ifdef DEBUG=0A= + fprintf(stderr, "TCP OUT -> adjusted MSS option, value %u\n", = EXTRACT_16BITS(cp));=0A= +#endif=0A= + }=0A= + }=0A= +=0A= + /* Account for the option's data */=0A= + cp +=3D datalen;=0A= + hlen -=3D datalen;=0A= + }=0A= + }=0A= + }=0A= +#endif /* MSS_UPDATE_HACK */=0A= +=0A= return(PKT_ALIAS_OK);=0A= }=0A= return(PKT_ALIAS_IGNORED);=0A= --- alias.h.orig Wed Feb 2 18:49:32 2000=0A= +++ alias.h Mon Jun 19 00:11:54 2000=0A= @@ -36,6 +36,11 @@=0A= extern unsigned int=0A= PacketAliasSetMode(unsigned int, unsigned int);=0A= =0A= +#ifdef MSS_UPDATE_HACK=0A= + extern void=0A= + PacketAliasSetMTU(u_short);=0A= +#endif=0A= +=0A= #ifndef NO_FW_PUNCH=0A= extern void=0A= PacketAliasSetFWBase(unsigned int, unsigned int);=0A= --- alias_db.c.orig Thu May 11 03:54:45 2000=0A= +++ alias_db.c Mon Jun 19 00:11:54 2000=0A= @@ -124,6 +124,9 @@=0A= #include =0A= #include =0A= #include =0A= +#ifdef MSS_UPDATE_HACK=0A= +#include =0A= +#endif=0A= #include =0A= =0A= #include "alias.h"=0A= @@ -247,6 +250,10 @@=0A= u_short alias_port;=0A= u_short proxy_port;=0A= =0A= +#ifdef MSS_UPDATE_HACK=0A= + u_short alias_mtu;=0A= +#endif /* MSS_UPDATE_HACK */=0A= +=0A= int link_type; /* Type of link: tcp, udp, icmp, frag = */=0A= =0A= /* values for link_type */=0A= @@ -316,6 +323,10 @@=0A= linkTableIn[LINK_TABLE_IN_SIZE]; /* into input and output lookup = */=0A= /* tables. = */=0A= =0A= +#ifdef MSS_UPDATE_HACK=0A= +static u_short aliasMTU;=0A= +#endif=0A= +=0A= static int icmpLinkCount; /* Link statistics = */=0A= static int udpLinkCount;=0A= static int tcpLinkCount;=0A= @@ -871,6 +882,9 @@=0A= link->sockfd =3D -1;=0A= link->flags =3D 0;=0A= link->timestamp =3D timeStamp;=0A= +#ifdef MSS_UPDATE_HACK=0A= + link->alias_mtu =3D aliasMTU - sizeof(struct ip); /* should be max = IPHLEN */=0A= +#endif=0A= =0A= /* Expiration time */=0A= switch (link_type)=0A= @@ -880,9 +894,15 @@=0A= break;=0A= case LINK_UDP:=0A= link->expire_time =3D UDP_EXPIRE_TIME;=0A= +#ifdef MSS_UPDATE_HACK=0A= + link->alias_mtu -=3D sizeof(struct udphdr);=0A= +#endif=0A= break;=0A= case LINK_TCP:=0A= link->expire_time =3D TCP_EXPIRE_INITIAL;=0A= +#ifdef MSS_UPDATE_HACK=0A= + link->alias_mtu -=3D sizeof(struct tcphdr);=0A= +#endif=0A= break;=0A= case LINK_FRAGMENT_ID:=0A= link->expire_time =3D FRAGMENT_ID_EXPIRE_TIME;=0A= @@ -2390,3 +2410,25 @@=0A= memset(fireWallField, 0, fireWallNumNums);=0A= }=0A= #endif=0A= +=0A= +=0A= +#ifdef MSS_UPDATE_HACK=0A= +void=0A= +PacketAliasSetMTU(u_short mtu)=0A= +{=0A= +#ifdef DEBUG=0A= + fprintf(stderr, "link MTU is %u\n", mtu);=0A= +#endif=0A= + aliasMTU =3D mtu;=0A= +}=0A= +=0A= +u_short=0A= +GetAliasMTU(struct alias_link *link)=0A= +{=0A= + if (link->alias_mtu =3D=3D 0)=0A= + return aliasMTU;=0A= + else=0A= + return(link->alias_mtu);=0A= +}=0A= +#endif MSS_UPDATE_HACK=0A= +=0A= --- alias_local.h.orig Sun Aug 29 19:17:04 1999=0A= +++ alias_local.h Mon Jun 19 00:11:54 2000=0A= @@ -49,6 +49,25 @@=0A= } \=0A= }=0A= =0A= +#define LBL_ALIGN=0A= +#ifdef LBL_ALIGN=0A= +#define EXTRACT_16BITS(p) \=0A= + ((u_short)*((u_char *)(p) + 0) << 8 | \=0A= + (u_short)*((u_char *)(p) + 1))=0A= +#define EXTRACT_16BITS_NET(p) \=0A= + ((u_short)*((u_char *)(p) + 0) | \=0A= + (u_short)*((u_char *)(p) + 1) << 8)=0A= +#define ADJUST_16BITS(p, val) \=0A= + (*(u_char *)(p) =3D (u_char)(((u_short)(val) >> 8) & 0xff), \=0A= + *((u_char *)(p) + 1) =3D (u_char)((u_short)(val) & 0xff))=0A= +#else=0A= +#define EXTRACT_16BITS(p) \=0A= + ((u_short)ntohs(*(u_short *)(p)))=0A= +#define ADJUST_16BITS(p, val) \=0A= + (*(u_short *)(p) =3D ntohs((u_short)(val)))=0A= +#endif=0A= +=0A= +=0A= =0A= /*=0A= Globals=0A= @@ -133,6 +152,9 @@=0A= void ClearCheckNewLink(void);=0A= #ifndef NO_FW_PUNCH=0A= void PunchFWHole(struct alias_link *);=0A= +#endif=0A= +#ifdef MSS_UPDATE_HACK=0A= +u_short GetAliasMTU(struct alias_link *);=0A= #endif=0A= =0A= =0A= ------=_NextPart_000_00EF_01BFD989.7F9EBE40 Content-Type: application/octet-stream; name="MSS_HACK_natd.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="MSS_HACK_natd.patch" --- natd.c.orig Fri Feb 25 06:34:38 2000=0A= +++ natd.c Mon Jun 19 00:11:55 2000=0A= @@ -302,6 +302,12 @@=0A= */=0A= if (aliasAddr.s_addr !=3D INADDR_NONE)=0A= PacketAliasSetAddress (aliasAddr);=0A= +=0A= +#ifdef MSS_UPDATE_HACK=0A= + if (ifMTU > 0)=0A= + PacketAliasSetMTU(ifMTU);=0A= +#endif=0A= +=0A= /*=0A= * We need largest descriptor number for select.=0A= */=0A= @@ -757,7 +763,12 @@=0A= if (strlen(ifn) =3D=3D sdl->sdl_nlen &&=0A= strncmp(ifn, sdl->sdl_data, sdl->sdl_nlen) =3D=3D 0) {=0A= ifIndex =3D ifm->ifm_index;=0A= +#ifdef MSS_UPDATE_HACK=0A= + if (ifMTU <=3D 0)=0A= + ifMTU =3D ifm->ifm_data.ifi_mtu;=0A= +#else=0A= ifMTU =3D ifm->ifm_data.ifi_mtu;=0A= +#endif=0A= break;=0A= }=0A= }=0A= @@ -800,6 +811,10 @@=0A= errx(1, "%s: cannot get interface address", ifn);=0A= =0A= PacketAliasSetAddress(sin->sin_addr);=0A= +#ifdef MSS_UPDATE_HACK=0A= + if (ifMTU > 0)=0A= + PacketAliasSetMTU(ifMTU);=0A= +#endif=0A= syslog(LOG_INFO, "Aliasing to %s, mtu %d bytes",=0A= inet_ntoa(sin->sin_addr), ifMTU);=0A= =0A= @@ -863,7 +878,10 @@=0A= PptpAlias,=0A= ProxyRule,=0A= LogDenied,=0A= - LogFacility=0A= + LogFacility,=0A= +#ifdef MSS_UPDATE_HACK=0A= + LinkMTU=0A= +#endif=0A= };=0A= =0A= enum Param {=0A= @@ -1065,7 +1083,17 @@=0A= "facility",=0A= "name of syslog facility to use for logging",=0A= "log_facility",=0A= + NULL },=0A= +=0A= +#ifdef MSS_UPDATE_HACK=0A= + { LinkMTU,=0A= + 0,=0A= + Numeric,=0A= + "mtu",=0A= + "MTU for the link, affects the MSS option of outbound TCP packets",=0A= + "link_mtu",=0A= NULL }=0A= +#endif=0A= =0A= };=0A= =0A= @@ -1242,6 +1270,14 @@=0A= errx(1, "Unknown log facility name: %s", strValue); =0A= =0A= break;=0A= +#ifdef MSS_UPDATE_HACK=0A= + case LinkMTU:=0A= +#ifdef DEBUG=0A= + fprintf(stderr, "config link MTU to %d\n", numValue);=0A= +#endif=0A= + ifMTU =3D numValue;=0A= + break;=0A= +#endif=0A= }=0A= }=0A= =0A= ------=_NextPart_000_00EF_01BFD989.7F9EBE40 Content-Type: application/octet-stream; name="MSS_HACK_ppp.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="MSS_HACK_ppp.patch" --- bundle.c.orig Thu Jun 15 13:08:27 2000=0A= +++ bundle.c Mon Jun 19 00:11:57 2000=0A= @@ -793,6 +793,9 @@=0A= bundle.phase =3D PHASE_DEAD;=0A= bundle.CleaningUp =3D 0;=0A= bundle.NatEnabled =3D 0;=0A= +#ifdef MSS_UPDATE_HACK=0A= + bundle.NatMTUEnabled =3D 0;=0A= +#endif=0A= =0A= bundle.fsm.LayerStart =3D bundle_LayerStart;=0A= bundle.fsm.LayerUp =3D bundle_LayerUp;=0A= --- bundle.h.orig Thu Jun 15 13:08:27 2000=0A= +++ bundle.h Mon Jun 19 00:11:57 2000=0A= @@ -83,6 +83,9 @@=0A= =0A= unsigned CleaningUp : 1; /* Going to exit.... */=0A= unsigned NatEnabled : 1; /* Are we using libalias ? */=0A= +#ifdef MSS_UPDATE_HACK=0A= + unsigned NatMTUEnabled : 1; /* Are we using the MSS rewrite hack ? */=0A= +#endif /* MSS_UPDATE_HACK */=0A= =0A= struct fsm_parent fsm; /* Our callback functions */=0A= struct datalink *links; /* Our data links */=0A= --- command.c.orig Thu Jun 15 13:08:27 2000=0A= +++ command.c Mon Jun 19 00:11:57 2000=0A= @@ -175,6 +175,9 @@=0A= #ifndef NONAT=0A= static int NatEnable(struct cmdargs const *);=0A= static int NatOption(struct cmdargs const *);=0A= +#ifdef MSS_UPDATE_HACK=0A= +static int nat_SetLinkMTU(struct cmdargs const *);=0A= +#endif=0A= #endif=0A= =0A= static const char *=0A= @@ -614,6 +617,10 @@=0A= (const void *) PKT_ALIAS_USE_SOCKETS},=0A= {"help", "?", HelpCommand, LOCAL_AUTH | LOCAL_NO_AUTH,=0A= "Display this message", "nat help|? [command]", NatCommands},=0A= +#ifdef MSS_UPDATE_HACK=0A= + {"force_mtu", NULL, nat_SetLinkMTU, LOCAL_AUTH, =0A= + "Update TCP MSS based on the link MTU", "nat force_mtu yes|no" },=0A= +#endif /* MSS_UPDATE_HACK */=0A= {NULL, NULL, NULL},=0A= };=0A= #endif=0A= @@ -2167,6 +2174,27 @@=0A= return -1;=0A= }=0A= =0A= +#ifdef MSS_UPDATE_HACK=0A= +static int=0A= +nat_SetLinkMTU(struct cmdargs const *arg)=0A= +{=0A= + if (arg->argc =3D=3D arg->argn+1) {=0A= + if (strcasecmp(arg->argv[arg->argn], "yes") =3D=3D 0) {=0A= + if (arg->bundle->NatEnabled) {=0A= + if (arg->bundle->cfg.mtu > 0)=0A= + PacketAliasSetMTU(arg->bundle->cfg.mtu);=0A= + arg->bundle->NatMTUEnabled =3D 1;=0A= + }=0A= + return 0;=0A= + } else if (strcasecmp(arg->argv[arg->argn], "no") =3D=3D 0) {=0A= + arg->bundle->NatMTUEnabled =3D 0;=0A= + return 0;=0A= + }=0A= + }=0A= +=0A= + return -1;=0A= +}=0A= +#endif /* MSS_UPDATE_HACK */=0A= =0A= static int=0A= NatOption(struct cmdargs const *arg)=0A= ------=_NextPart_000_00EF_01BFD989.7F9EBE40 Content-Type: text/plain; name="MSS_HACK_trace.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="MSS_HACK_trace.txt" Test setup: [ Penpro ] - rl0 -------Ethernet----- [ Web Server (nitro) ] Natd is running on penpro, tcpdump is running on nitro 1st test: using natd without specifying a link_mtu. In this case the=20 system is using the configured MTU for the link. In this case this is=20 an ethernet link with a normal MTU of 1500 root@penpro# ./natd -v -n rl0 link MTU is 1500 natd[2198]: Aliasing to 192.168.10.9, mtu 1500 bytes link MTU is 1500 TCP OUT -> checking for MSS option TCP OUT -> options present, max MSS is 1460 TCP OUT -> got MSS option, value 1460 Out [TCP] [TCP] 192.168.10.9:1038 -> 192.168.10.2:80 aliased to [TCP] 192.168.10.9:1038 -> 192.168.10.2:80 In [TCP] [TCP] 192.168.10.2:80 -> 192.168.10.9:1038 aliased to [TCP] 192.168.10.2:80 -> 192.168.10.9:1038 TCP OUT -> checking for MSS option Out [TCP] [TCP] 192.168.10.9:1038 -> 192.168.10.2:80 aliased to [TCP] 192.168.10.9:1038 -> 192.168.10.2:80 TCP OUT -> checking for MSS option Out [TCP] [TCP] 192.168.10.9:1038 -> 192.168.10.2:80 aliased to [TCP] 192.168.10.9:1038 -> 192.168.10.2:80 In [TCP] [TCP] 192.168.10.2:80 -> 192.168.10.9:1038 aliased to [TCP] 192.168.10.2:80 -> 192.168.10.9:1038 In [TCP] [TCP] 192.168.10.2:80 -> 192.168.10.9:1038 aliased to [TCP] 192.168.10.2:80 -> 192.168.10.9:1038 In [TCP] [TCP] 192.168.10.2:80 -> 192.168.10.9:1038 aliased to [TCP] 192.168.10.2:80 -> 192.168.10.9:1038 In [TCP] [TCP] 192.168.10.2:80 -> 192.168.10.9:1038 aliased to [TCP] 192.168.10.2:80 -> 192.168.10.9:1038 TCP OUT -> checking for MSS option Out [TCP] [TCP] 192.168.10.9:1038 -> 192.168.10.2:80 aliased to [TCP] 192.168.10.9:1038 -> 192.168.10.2:80 TCP OUT -> checking for MSS option Out [TCP] [TCP] 192.168.10.9:1038 -> 192.168.10.2:80 aliased to [TCP] 192.168.10.9:1038 -> 192.168.10.2:80 TCP OUT -> checking for MSS option Out [TCP] [TCP] 192.168.10.9:1038 -> 192.168.10.2:80 aliased to [TCP] 192.168.10.9:1038 -> 192.168.10.2:80 In [TCP] [TCP] 192.168.10.2:80 -> 192.168.10.9:1038 aliased to [TCP] 192.168.10.2:80 -> 192.168.10.9:1038 TCP DUMP on nitro (the web server) 13:15:32.842174 penpro.1038 > nitro.http: S 421436740:421436740(0) win = 16384 (DF) [tos 0x10] 13:15:32.842236 nitro.http > penpro.1038: S 2150088421:2150088421(0) ack = 421436741 win 17520 (DF) 13:15:32.844977 penpro.1038 > nitro.http: . ack 1 win 17520 (DF) [tos = 0x10]=20 13:15:38.174677 penpro.1038 > nitro.http: P 1:8(7) ack 1 win 17520 (DF) = [tos 0x10] 13:15:38.175404 nitro.http > penpro.1038: . 1:1461(1460) ack 8 win 17520 = (DF) 13:15:38.175426 nitro.http > penpro.1038: . 1461:2921(1460) ack 8 win = 17520 (DF) 13:15:38.175438 nitro.http > penpro.1038: P 2921:3576(655) ack 8 win = 17520 (DF) 13:15:38.175702 nitro.http > penpro.1038: F 3576:3576(0) ack 8 win 17520 = (DF) 13:15:38.185201 penpro.1038 > nitro.http: . ack 2921 win 17520 (DF) [tos = 0x10] 13:15:38.188695 penpro.1038 > nitro.http: . ack 3577 win 17520 (DF) [tos = 0x10] 13:15:38.189536 penpro.1038 > nitro.http: F 8:8(0) ack 3577 win 17520 = (DF) [tos 0x10] 13:15:38.189562 nitro.http > penpro.1038: . ack 9 win 17520 (DF) 2nd test: This time the link MTU is indicated as being smaller (1200 bytes). Same = test: a simple HTTP request from penpro to Nitro. root@penpro# ./natd -v -n rl0 -link_mtu 1200 config link MTU to 1200 link MTU is 1200 natd[2200]: Aliasing to 192.168.10.9, mtu 1200 bytes link MTU is 1200 TCP OUT -> checking for MSS option TCP OUT -> options present, max MSS is 1160 TCP OUT -> got MSS option, value 1460 TCP OUT -> adjsuted MSS option, value 1160 Out [TCP] [TCP] 192.168.10.9:1039 -> 192.168.10.2:80 aliased to [TCP] 192.168.10.9:1039 -> 192.168.10.2:80 In [TCP] [TCP] 192.168.10.2:80 -> 192.168.10.9:1039 aliased to [TCP] 192.168.10.2:80 -> 192.168.10.9:1039 TCP OUT -> checking for MSS option Out [TCP] [TCP] 192.168.10.9:1039 -> 192.168.10.2:80 aliased to [TCP] 192.168.10.9:1039 -> 192.168.10.2:80 TCP OUT -> checking for MSS option Out [TCP] [TCP] 192.168.10.9:1039 -> 192.168.10.2:80 aliased to [TCP] 192.168.10.9:1039 -> 192.168.10.2:80 In [TCP] [TCP] 192.168.10.2:80 -> 192.168.10.9:1039 aliased to [TCP] 192.168.10.2:80 -> 192.168.10.9:1039 In [TCP] [TCP] 192.168.10.2:80 -> 192.168.10.9:1039 aliased to [TCP] 192.168.10.2:80 -> 192.168.10.9:1039 In [TCP] [TCP] 192.168.10.2:80 -> 192.168.10.9:1039 aliased to [TCP] 192.168.10.2:80 -> 192.168.10.9:1039 In [TCP] [TCP] 192.168.10.2:80 -> 192.168.10.9:1039 aliased to [TCP] 192.168.10.2:80 -> 192.168.10.9:1039 In [TCP] [TCP] 192.168.10.2:80 -> 192.168.10.9:1039 aliased to [TCP] 192.168.10.2:80 -> 192.168.10.9:1039 TCP OUT -> checking for MSS option Out [TCP] [TCP] 192.168.10.9:1039 -> 192.168.10.2:80 aliased to [TCP] 192.168.10.9:1039 -> 192.168.10.2:80 TCP OUT -> checking for MSS option Out [TCP] [TCP] 192.168.10.9:1039 -> 192.168.10.2:80 aliased to [TCP] 192.168.10.9:1039 -> 192.168.10.2:80 TCP OUT -> checking for MSS option Out [TCP] [TCP] 192.168.10.9:1039 -> 192.168.10.2:80 aliased to [TCP] 192.168.10.9:1039 -> 192.168.10.2:80 In [TCP] [TCP] 192.168.10.2:80 -> 192.168.10.9:1039 aliased to [TCP] 192.168.10.2:80 -> 192.168.10.9:1039 TCPDUMP on nitro 13:15:58.360870 penpro.1039 > nitro.http: S 426240782:426240782(0) win = 16384 (DF) [tos 0x10] 13:15:58.360927 nitro.http > penpro.1039: S 2154861752:2154861752(0) ack = 426240783 win 17400 (DF) 13:15:58.363658 penpro.1039 > nitro.http: . ack 1 win 17520 (DF) [tos = 0x10] 13:16:00.426328 penpro.1039 > nitro.http: P 1:8(7) ack 1 win 17520 (DF) = [tos 0x10] 13:16:00.427073 nitro.http > penpro.1039: . 1:1161(1160) ack 8 win 17400 = (DF) 13:16:00.427094 nitro.http > penpro.1039: . 1161:2321(1160) ack 8 win = 17400 (DF) 13:16:00.427104 nitro.http > penpro.1039: . 2321:3481(1160) ack 8 win = 17400 (DF) 13:16:00.427112 nitro.http > penpro.1039: P 3481:3576(95) ack 8 win = 17400 (DF) 13:16:00.427243 nitro.http > penpro.1039: F 3576:3576(0) ack 8 win 17400 = (DF) 13:16:00.437633 penpro.1039 > nitro.http: . ack 3481 win 17384 (DF) [tos = 0x10] 13:16:00.441142 penpro.1039 > nitro.http: . ack 3577 win 17520 (DF) [tos = 0x10] 13:16:00.442015 penpro.1039 > nitro.http: F 8:8(0) ack 3577 win 17520 = (DF) [tos 0x10] 13:16:00.442039 nitro.http > penpro.1039: . ack 9 win 17400 (DF) This time we can observe that the MSS on the initial TCP packet from = penpro to nitro is 1160 (1200 - TCP/IP headers). Also the packets comming back from nitro = contain only 1160 bytes of data. ------=_NextPart_000_00EF_01BFD989.7F9EBE40-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 19 1:28: 2 2000 Delivered-To: freebsd-net@freebsd.org Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by hub.freebsd.org (Postfix) with ESMTP id AEC2C37B669 for ; Mon, 19 Jun 2000 01:27:58 -0700 (PDT) (envelope-from ino-waiting@gmx.net) Received: from [62.104.201.2] (helo=mx1.freenet.de) by mout0.freenet.de with esmtp (Exim 3.14 #3) id 133wuT-00085Q-00 for freebsd-net@freebsd.org; Mon, 19 Jun 2000 10:27:57 +0200 Received: from [213.6.10.188] (helo=spotteswoode.de) by mx1.freenet.de with smtp (Exim 3.14 #3) id 133wuS-0002bt-00 for freebsd-net@freebsd.org; Mon, 19 Jun 2000 10:27:56 +0200 Received: (qmail 310 invoked by uid 0); 19 Jun 2000 08:28:23 -0000 From: "clemensF" Date: Mon, 19 Jun 2000 10:28:23 +0200 To: freebsd-net@freebsd.org Subject: Re: 4.0 and ppp not working? Message-ID: <20000619102823.E217@spotteswoode.de> Mail-Followup-To: freebsd-net@freebsd.org References: <20000618122828.A11420@Shift-F1.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20000618122828.A11420@Shift-F1.com>; from shashi@shift-f1.com on Sun, Jun 18, 2000 at 12:28:28PM -0400 Organization: private X-PGP-ID: 0xD4685B88-4894C483/DH X-PGP-FPR: 0FAE 5F53 CEB9 49DE 9300 3035 D468 5B88 4894 C483 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > shashi: > Jun 18 11:20:45 ugrads ppp[807]: tun0: Chat: Expect(5): OK > Jun 18 11:20:45 ugrads ppp[807]: tun0: Chat: Received: ATE1Q0^M^M > Jun 18 11:20:45 ugrads ppp[807]: tun0: Chat: Received: OK^M > Jun 18 11:20:45 ugrads ppp[807]: tun0: Chat: Send: ATDT_PHONE_NUM_^M > Jun 18 11:20:47 ugrads ppp[807]: tun0: Chat: Expect(40): CONNECT > Jun 18 11:21:28 ugrads ppp[807]: tun0: Chat: Expect timeout > Jun 18 11:21:28 ugrads ppp[807]: tun0: Warning: Chat script failed did the phone number change? the chat script works until the number is dialed. i use a variation of this with "ppp -auto ", but that's not the point. i bet it's the phone number dialing part. check every character of the atdt-command and simulate it manually. clemens To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 19 1:42:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [212.74.0.25]) by hub.freebsd.org (Postfix) with ESMTP id C8E3537B6CC; Mon, 19 Jun 2000 01:42:30 -0700 (PDT) (envelope-from joe@pavilion.net) Received: from genius.systems.pavilion.net (genesis.tao.org.uk [194.242.131.254]) by florence.pavilion.net (8.9.3/8.8.8) with ESMTP id JAA37088; Mon, 19 Jun 2000 09:42:29 +0100 (BST) (envelope-from joe@pavilion.net) Received: by genius.systems.pavilion.net (Postfix, from userid 100) id 022B311E7F; Mon, 19 Jun 2000 09:42:52 +0100 (BST) Date: Mon, 19 Jun 2000 09:42:52 +0100 From: Josef Karthauser To: Patrick Bihan-Faou Cc: freebsd-net@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/sys sockio.h src/sys/net if.c src/sbin/ifconfig ifconfig.8 ifconfig.c Message-ID: <20000619094252.H22172@pavilion.net> References: <200006162014.NAA12344@freefall.freebsd.org> <20000617011757.C4271@pavilion.net> <010101bfd886$a4e23a50$040aa8c0@local.mindstep.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <010101bfd886$a4e23a50$040aa8c0@local.mindstep.com>; from patrick@mindstep.com on Sat, Jun 17, 2000 at 02:05:39PM -0400 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, Lees House, 21-23 Dyke Road, Brighton, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jun 17, 2000 at 02:05:39PM -0400, Patrick Bihan-Faou wrote: > > > Horray! At last there's some hope of getting dhcp to give me the same > > lease irrespective of which pccard ethernet card I plug in :). > > You can already to this by specifying the DHCP client-id for your machine. > Most DHCP servers will honor that and since it is under your control, you > don't need to hack the MAC address to obtain the same lease even when you > change you ethernet card. > How do I specify my unique key to dhclient? The version currently in FreeBSD doesn't appear to have any options for this. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 19 7:36:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id EA78737B505 for ; Mon, 19 Jun 2000 07:36:39 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id RAA11480; Mon, 19 Jun 2000 17:36:21 +0300 (EEST) Date: Mon, 19 Jun 2000 17:36:21 +0300 From: Ruslan Ermilov To: clefevre@citeweb.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: ipfw: about P:2 packets Message-ID: <20000619173621.B11284@sunbay.com> Mail-Followup-To: clefevre@citeweb.net, freebsd-net@FreeBSD.ORG References: <200006172350.BAA11791@gits.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200006172350.BAA11791@gits.dyndns.org>; from root@gits.dyndns.org on Sun, Jun 18, 2000 at 01:50:43AM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jun 18, 2000 at 01:50:43AM +0200, Cyrille Lefevre wrote: > at boot time, I've these messages when, I guess, the route daemon is stated. > > Jun 15 06:43:36 gits /kernel: ipfw: 65000 Deny P:2 195.132.XXX.65 224.0.0.2 out via ep0 > Jun 15 06:43:36 gits /kernel: ipfw: 65000 Deny P:2 195.132.XXX.65 224.0.0.2 in via ep0 > Jun 15 06:43:38 gits /kernel: ipfw: 65000 Deny P:2 195.132.XXX.65 224.0.0.9 out via ep0 > Jun 15 06:43:38 gits /kernel: ipfw: 65000 Deny P:2 195.132.XXX.65 224.0.0.9 in via ep0 > > in some words, what are thoses packets ? > > using ipfw, how to enable them to pass w/o a (not tested) generic rule like : > > add pass all from $oip to 224.0.0.0/24 > add pass all from 224.0.0.0/24 to $oip > > thanks by advance. > These are IGMP packets (IP protocol 2). You can `allow igmp from any to any' or something like this... -- 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-net" in the body of the message From owner-freebsd-net Mon Jun 19 10:41:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from game.over.net (game.over.net [193.189.189.100]) by hub.freebsd.org (Postfix) with ESMTP id 6756537BD32 for ; Mon, 19 Jun 2000 10:41:16 -0700 (PDT) (envelope-from tomaz.borstnar@over.net) Received: from [193.189.183.78] ([193.189.183.78]:28711 "EHLO user.over.net") by mail.over.net with ESMTP id ; Mon, 19 Jun 2000 19:40:57 +0200 Message-Id: <4.3.2.7.2.20000619193343.03422c50@193.189.189.100> X-Sender: tmail@193.189.189.100 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Jun 2000 19:40:46 -0100 To: freebsd-net@freebsd.org From: Tomaz Borstnar Subject: ppp and lqr - Warning: lqr_RecvEcho: Got packet size 54, expecting 12 ! In-Reply-To: <20000619102823.E217@spotteswoode.de> References: <20000618122828.A11420@Shift-F1.com> <20000618122828.A11420@Shift-F1.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello! Using FreeBSD4.0-STABLE's ppp as of today I get this error when turning on lqr for my PPPoE session: Jun 19 12:39:45 triglav ppp[116]: tun0: Warning: lqr_RecvEcho: Got packet size 54, expecting 12 ! Jun 19 12:40:16 triglav ppp[116]: tun0: Warning: lqr_RecvEcho: Got packet size 54, expecting 12 ! Seems like ppp doesn't like that and breaks the connection. According to docs: "When LQR is enabled, ppp sends the QUALPROTO option (see ``set lqrperiod'' below) as part of the LCP request. If the peer agrees, both sides will exchange LQR packets at the agreed frequency, allowing detailed link quality monitoring by enabling LQM logging. If the peer doesn't agree, ppp will send ECHO LQR requests instead. These packets pass no information of interest, but they MUST be replied to by the peer." ppp gets the replies, but doesn't like them and drops the session! Nortel Shasta 5000 with firmware 1.5.10 on the other side of PPPoE link. How much overhead does LQR have for provider? What kind of reports can I get if they turn it on? Thanks in advance. Tomaz ---- Tomaz Borstnar "Love is the answer to the final question you ask" - Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 19 10:43:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 34DD837BD32 for ; Mon, 19 Jun 2000 10:43:47 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id NAA30993; Mon, 19 Jun 2000 13:43:29 -0400 (EDT) (envelope-from wollman) Date: Mon, 19 Jun 2000 13:43:29 -0400 (EDT) From: Garrett Wollman Message-Id: <200006191743.NAA30993@khavrinen.lcs.mit.edu> To: "Kenneth D. Merry" Cc: net@FreeBSD.ORG Subject: zero copy sockets and NFS code for FreeBSD In-Reply-To: <20000616212545.A57840@panzer.kdm.org> References: <20000616212545.A57840@panzer.kdm.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Another problem with the current send side approach is that it requires > page sized and page aligned data in order to apply the COW mapping. Not > all data sets fit this requirement. Not necessarily. There is some threshold length above which it makes sense to flip the page, even if you are not transmitting the entire page. This is true even if the MTU is much less than a page (provided you implement reference counting for m_copym et al). Another possible optimization, which I've suggested a few times, is to provide a flag on send() which allows the sender to say ``I'm through with this page; please unmap it / give me a new ZFOD page'', which may make sense for some kinds of applications (e.g., ftpd). > One way to address both of the above problems is to implement an alternate > zero copy send scheme that uses async I/O. With async I/O semantics, it > will be clear to the userland program that the buffer in question is not to > be used until it is returned from the kernel. As with most networking optimizations, programs will have to be restructured in order to take maximal advantage -- no surprise there. > One way to get around the restriction is if it were possible to do > operations similar to a page flip on buffers that are less than a page > size. It is. You simply need flag to recv() which says ``the page I'm pointing to contains nothing of interest; you're free to trash it''. (Obviously you still have to be careful about flipping pages which contain data the user shouldn't see.) You might also consider a getsockopt() call which returns the preferred alignment and offset for buffers on this particular connection. > One drawback to this approach is that it requires support for RDMA on both > ends of the connection. Shades of trailers.... -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 19 11:15:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id BCD3937BD76 for ; Mon, 19 Jun 2000 11:15:07 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id MAA78802; Mon, 19 Jun 2000 12:14:51 -0600 (MDT) (envelope-from ken) Date: Mon, 19 Jun 2000 12:14:51 -0600 From: "Kenneth D. Merry" To: Garrett Wollman Cc: net@FreeBSD.ORG Subject: Re: zero copy sockets and NFS code for FreeBSD Message-ID: <20000619121450.A78756@panzer.kdm.org> References: <20000616212545.A57840@panzer.kdm.org> <200006191743.NAA30993@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006191743.NAA30993@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Mon, Jun 19, 2000 at 01:43:29PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jun 19, 2000 at 13:43:29 -0400, Garrett Wollman wrote: > < said: > > > Another problem with the current send side approach is that it requires > > page sized and page aligned data in order to apply the COW mapping. Not > > all data sets fit this requirement. > > Not necessarily. There is some threshold length above which it makes > sense to flip the page, even if you are not transmitting the entire > page. This is true even if the MTU is much less than a page (provided > you implement reference counting for m_copym et al). This would require the recv() flag you mention below. Otherwise, you would have to do a copy and flip operation. (i.e. copy part of the user's page into the kernel, and then flip the kernel page in place of the user's page.) > Another possible optimization, which I've suggested a few times, is to > provide a flag on send() which allows the sender to say ``I'm through > with this page; please unmap it / give me a new ZFOD page'', which may > make sense for some kinds of applications (e.g., ftpd). Yeah, that's another possible way to do it. > > One way to address both of the above problems is to implement an alternate > > zero copy send scheme that uses async I/O. With async I/O semantics, it > > will be clear to the userland program that the buffer in question is not to > > be used until it is returned from the kernel. > > As with most networking optimizations, programs will have to be > restructured in order to take maximal advantage -- no surprise there. Yeah, it's difficult to get things to work 100% without breaking the standard read/write semantics. > > One way to get around the restriction is if it were possible to do > > operations similar to a page flip on buffers that are less than a page > > size. > > It is. You simply need flag to recv() which says ``the page I'm > pointing to contains nothing of interest; you're free to trash it''. > (Obviously you still have to be careful about flipping pages which > contain data the user shouldn't see.) You might also consider a > getsockopt() call which returns the preferred alignment and offset for > buffers on this particular connection. > > > One drawback to this approach is that it requires support for RDMA on both > > ends of the connection. > > Shades of trailers.... Yep, but it is probably one of the cleaner ways of tackling the problem. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 19 11:15:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from mercury.spvi.com (h194.spvi.com [208.150.70.194]) by hub.freebsd.org (Postfix) with ESMTP id AC66F37BEC4; Mon, 19 Jun 2000 11:15:18 -0700 (PDT) (envelope-from steve@spvi.com) Received: (from steve@localhost) by mercury.spvi.com (8.9.3/8.9.3) id NAA31747; Mon, 19 Jun 2000 13:14:45 -0500 (EST) (envelope-from steve@spvi.com) Date: Mon, 19 Jun 2000 13:14:45 -0500 (EST) Message-Id: <200006191814.NAA31747@mercury.spvi.com> X-Authentication-Warning: mercury.spvi.com: steve set sender to steve@spvi.com using -f From: Steve Spicklemire To: freebsd-stable@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Cc: steve@spvi.com Subject: mpd problems..... is it possible my cvsup can be 'undone?' Reply-To: steve@spvi.com References: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Folks, I haven't seen any answers yet... maybe I'm barking up the wrong three here. I had mpd/pptp working. Now I'm getting all these Jun 18 17:25:20 mercury mpd: [pptp] CCP: state change Ack-Sent --> Opened Jun 18 17:25:20 mercury mpd: [pptp] CCP: LayerUp Jun 18 17:25:20 mercury mpd: [pptp] can't create mppc node: Device not configured Jun 18 17:25:20 mercury mpd: [pptp] CCP: parameter negotiation failed Jun 18 17:25:20 mercury mpd: [pptp] CCP: Close event Jun 18 17:25:20 mercury mpd: [pptp] CCP: state change Opened --> Closing Jun 18 17:25:20 mercury mpd: [pptp] CCP: SendTerminateReq #4 Jun 18 17:25:20 mercury mpd: [pptp] CCP: LayerDown Jun 18 17:25:20 mercury mpd: [pptp] CCP: state change Closing --> Closed Jun 18 17:25:20 mercury mpd: [pptp] CCP: LayerFinish Jun 18 17:25:20 mercury mpd: [pptp] CCP: rec'd Terminate Ack #4 link 0 (Closed) Jun 18 17:25:21 mercury mpd: [pptp] rec'd unexpected protocol COMPD on link 0 Jun 18 17:25:25 mercury last message repeated 13 times Jun 18 17:37:07 mercury mpd: [pptp] rec'd unexpected protocol COMPD on link 0 Jun 18 17:37:11 mercury last message repeated 3 times I'm wondering if my cvsup/make world has broken it. Is there any "simple" way to do a cvsup with the "cvs update '-D'" option? (I just checked the cvsup man page and -D doesn't mean the same thing there!) I'd like to cvsup 'as it was on May 29'. Or something to that effect... alternatively has anything happened to the crypto stuff, or netgraph that would explain all these "rec'd unexpected protocol COMPD on link 0" messages that I'm getting? thanks! -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 19 12:32:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 13E6937BD27 for ; Mon, 19 Jun 2000 12:32:32 -0700 (PDT) (envelope-from nick@rapidnet.com) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id NAA47905; Mon, 19 Jun 2000 13:31:02 -0600 (MDT) Date: Mon, 19 Jun 2000 13:31:02 -0600 (MDT) From: Nick Rogness To: "Ron 'The InSaNe One' Rosson" Cc: freebsd-net@freebsd.org Subject: Re: ppp -nat or ppp with ipf's ipnat ?? In-Reply-To: <20000615133454.A98489@lunatic.oneinsane.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 15 Jun 2000, Ron 'The InSaNe One' Rosson wrote: > I am building a simple straight forward machine fro a friend. Here is > what it is going to do. > Connect to the internet via a dial-up modem > Assign IP's to the LAN using DHCP > Provide internet access for the lan by using NAT > -- The Delimma -- > What is the better way of doing this? > - Use the builtin NAT in user-ppp > - Use IPFilter's ipnat The builtin NAT seems to work OK. I have also used natd/ipfw combo with success. Nick Rogness - Speak softly and carry a Gigabit switch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 19 16:31:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id F2C9237B899 for ; Mon, 19 Jun 2000 16:31:19 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id AAA00561; Tue, 20 Jun 2000 00:26:41 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id AAA54034; Tue, 20 Jun 2000 00:27:09 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006192327.AAA54034@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Tomaz Borstnar Cc: freebsd-net@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: ppp and lqr - Warning: lqr_RecvEcho: Got packet size 54, expecting 12 ! In-Reply-To: Message from Tomaz Borstnar of "Mon, 19 Jun 2000 19:40:46 -0100." <4.3.2.7.2.20000619193343.03422c50@193.189.189.100> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jun 2000 00:27:09 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hello! > > Using FreeBSD4.0-STABLE's ppp as of today I get this error when turning on > lqr for my PPPoE session: > > Jun 19 12:39:45 triglav ppp[116]: tun0: Warning: lqr_RecvEcho: Got packet > size 54, expecting 12 ! > Jun 19 12:40:16 triglav ppp[116]: tun0: Warning: lqr_RecvEcho: Got packet > size 54, expecting 12 ! These warnings are wrong and were fixed a few days ago. Ppp was warning about 54 byte (+ headers) packets with a 12 byte payload. > Seems like ppp doesn't like that and breaks the connection. According to docs: This is just a warning. Ppp adjusts the packet and continues processing it. > "When LQR is enabled, ppp sends > the QUALPROTO option (see ``set lqrperiod'' below) as part of the > LCP request. If the peer agrees, both sides will exchange LQR > packets at the agreed frequency, allowing detailed link quality > monitoring by enabling LQM logging. If the peer doesn't agree, > ppp will send ECHO LQR requests instead. These packets pass no > information of interest, but they MUST be replied to by the > peer." > > ppp gets the replies, but doesn't like them and drops the session! Nortel > Shasta 5000 with firmware 1.5.10 on the other side of PPPoE link. Were there any other error messages ? It may be worth turning up logging - maybe ``set log +debug lqm lcp''. > How much overhead does LQR have for provider? What kind of reports can I > get if they turn it on? Not much, and statistics concerning the link quality (if you enable lqm logging). Ppp has never done much with these stats though. > Thanks in advance. > > Tomaz > ---- > Tomaz Borstnar > "Love is the answer to the final question you ask" - Unknown Cheers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 19 17:48: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id 21FEA37B6C7 for ; Mon, 19 Jun 2000 17:48:01 -0700 (PDT) (envelope-from ino-waiting@gmx.net) Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout1.freenet.de with esmtp (Exim 3.14 #3) id 134CCt-00039D-00 for freebsd-net@freebsd.org; Tue, 20 Jun 2000 02:47:59 +0200 Received: from [213.6.2.82] (helo=spotteswoode.de) by mx3.freenet.de with smtp (Exim 3.14 #3) id 134CCt-000376-00 for freebsd-net@FreeBSD.ORG; Tue, 20 Jun 2000 02:47:59 +0200 Received: (qmail 5458 invoked by uid 0); 20 Jun 2000 00:48:39 -0000 From: "clemensF" Date: Tue, 20 Jun 2000 02:48:39 +0200 To: freebsd-net@FreeBSD.ORG Subject: Re: ipfw: about P:2 packets Message-ID: <20000620024839.D1447@spotteswoode.de> Mail-Followup-To: freebsd-net@FreeBSD.ORG References: <200006172350.BAA11791@gits.dyndns.org> <20000619173621.B11284@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20000619173621.B11284@sunbay.com>; from ru@sunbay.com on Mon, Jun 19, 2000 at 05:36:21PM +0300 Organization: private X-PGP-ID: 0xD4685B88-4894C483/DH X-PGP-FPR: 0FAE 5F53 CEB9 49DE 9300 3035 D468 5B88 4894 C483 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Ruslan Ermilov: > These are IGMP packets (IP protocol 2). > You can `allow igmp from any to any' or something like this... if ... it's implemented! clemens To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 19 20:12:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from gateway.cinar.com (gateway.cinar.com [207.107.104.128]) by hub.freebsd.org (Postfix) with SMTP id ED85637BAF4 for ; Mon, 19 Jun 2000 20:12:03 -0700 (PDT) (envelope-from mgignac@cinar.com) Received: (qmail 66197 invoked by uid 85); 19 Jun 2000 23:12:02 -0400 Received: from mgignac@cinar.com by gateway.cinar.com with scan4virus-0.52 (. Clean. Processed in 0.047671 secs); 19/06/2000 23:12:02 Received: from unknown (HELO freebsd.cinar.com) (172.16.1.134) by gateway.cinar.com with SMTP; 19 Jun 2000 23:12:01 -0400 Received: from martingignac ([172.16.1.216]) by freebsd.cinar.com (8.9.3/8.9.3) with SMTP id XAA15747; Mon, 19 Jun 2000 23:11:58 -0400 (EDT) (envelope-from mgignac@cinar.com) Message-ID: <004f01bfda65$4d52fe60$d80110ac@martingignac> From: "Martin Gignac" To: "Abdullah Bin Hamad" , Cc: References: <001901bfd969$5ddb2660$17c14dd4@qatar.net.qa> Subject: Re: Free WebMail. Date: Mon, 19 Jun 2000 23:11:55 -0400 Organization: Cinar Corporation MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org NeoMail at http://neomail.sourceforget.net -Martin ----- Original Message ----- From: "Abdullah Bin Hamad" To: Cc: Sent: Sunday, June 18, 2000 17:08 Subject: Free WebMail. > Hello folks, > > I'm about to run web mail and I need open source one. > > Please direct me to nice one. > > PS: I'm not on this list please email me directly. > > Best Regards, > > -Arabian aka Abdullah > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 19 22: 3: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from game.over.net (game.over.net [193.189.189.100]) by hub.freebsd.org (Postfix) with ESMTP id 5DA1637BAD4 for ; Mon, 19 Jun 2000 22:02:56 -0700 (PDT) (envelope-from tomaz.borstnar@over.net) Received: from [212.30.94.150] ([212.30.94.150]:7207 "EHLO user.over.net") by mail.over.net with ESMTP id ; Tue, 20 Jun 2000 07:02:39 +0200 Message-Id: <4.3.2.7.2.20000620065859.03d208f0@193.189.189.100> X-Sender: tmail@193.189.189.100 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Jun 2000 07:02:13 -0100 To: freebsd-net@FreeBSD.ORG, brian@hak.lan.Awfulhak.org From: Tomaz Borstnar Subject: Fwd: Re: ppp and lqr - Warning: lqr_RecvEcho: Got packet size 54, expecting 12 ! Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Jun 19 12:40:16 triglav ppp[116]: tun0: Warning: lqr_RecvEcho: Got packet > > size 54, expecting 12 ! > >These warnings are wrong and were fixed a few days ago. Ppp was I rebuilt everything yesterday with freshly cvsupped sources. Now I only get such messages if I enable lqr. >warning about 54 byte (+ headers) packets with a 12 byte payload. > > > Seems like ppp doesn't like that and breaks the connection. According > to docs: > >This is just a warning. Ppp adjusts the packet and continues >processing it. It still brekas the connection after few such messages. > > ppp gets the replies, but doesn't like them and drops the session! Nortel > > Shasta 5000 with firmware 1.5.10 on the other side of PPPoE link. > >Were there any other error messages ? It may be worth turning up >logging - maybe ``set log +debug lqm lcp''. I'll do it today. Tomaz ---- Tomaz Borstnar "Love is the answer to the final question you ask" - Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 2:21:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id C778B37BD94 for ; Tue, 20 Jun 2000 02:21:41 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id KAA14275; Tue, 20 Jun 2000 10:21:32 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id KAA59860; Tue, 20 Jun 2000 10:20:38 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006200920.KAA59860@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Tomaz Borstnar Cc: freebsd-net@FreeBSD.ORG, brian@Awfulhak.org, brian@hak.lan.Awfulhak.org Subject: Re: Fwd: Re: ppp and lqr - Warning: lqr_RecvEcho: Got packet size 54, expecting 12 ! In-Reply-To: Message from Tomaz Borstnar of "Tue, 20 Jun 2000 07:02:13 -0100." <4.3.2.7.2.20000620065859.03d208f0@193.189.189.100> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jun 2000 10:20:36 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Oops, I wasn't just being stupid in fsm.c WRT padding (the bit I fixed), I was also being stupid in lqr.c !!! I've now fixed that too. Thanks for your patience. > > > Jun 19 12:40:16 triglav ppp[116]: tun0: Warning: lqr_RecvEcho: Got packet > > > size 54, expecting 12 ! > > > >These warnings are wrong and were fixed a few days ago. Ppp was > > I rebuilt everything yesterday with freshly cvsupped sources. Now I only > get such messages if I enable lqr. > > > >warning about 54 byte (+ headers) packets with a 12 byte payload. > > > > > Seems like ppp doesn't like that and breaks the connection. According > > to docs: > > > >This is just a warning. Ppp adjusts the packet and continues > >processing it. > > It still brekas the connection after few such messages. > > > > ppp gets the replies, but doesn't like them and drops the session! Nortel > > > Shasta 5000 with firmware 1.5.10 on the other side of PPPoE link. > > > >Were there any other error messages ? It may be worth turning up > >logging - maybe ``set log +debug lqm lcp''. > > I'll do it today. > > Tomaz > ---- > Tomaz Borstnar > "Love is the answer to the final question you ask" - Unknown -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 6:24:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from pooh.aist-nara.ac.jp (inet1.aist-nara.ac.jp [163.221.52.121]) by hub.freebsd.org (Postfix) with ESMTP id 0934F37BE6A for ; Tue, 20 Jun 2000 06:24:44 -0700 (PDT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost by pooh.aist-nara.ac.jp (8.8.7/2.8Wb) id NAA00326; Tue, 20 Jun 2000 13:24:36 GMT From: Noritoshi Demizu To: freebsd-net@FreeBSD.ORG Subject: question on tcp_xmit_timer() of FreeBSD 4.0R X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 X-URL: http://infonet.aist-nara.ac.jp/member/nori-d/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000620222435Z.demizu@dd.iij4u.or.jp> Date: Tue, 20 Jun 2000 22:24:35 +0900 X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 25 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a question about the 2nd argument "rtt" of tcp_xmit_timer() of FreeBSD 4.0R. Why are the 2nd arguments in following code calculated differently ? i.e. for timestamp option, +1. l.1857, netinet/tcp_input.c, tcp_input() if (to.to_flag & TOF_TS) tcp_xmit_timer(tp, ticks - to.to_tsecr + 1); else if (tp->t_rtttime && SEQ_GT(th->th_ack, tp->t_rtseq)) tcp_xmit_timer(tp, ticks - tp->t_rtttime); Why is `1' subtracted from the 2nd argument "rtt" here ? l.2448, netinet/tcp_input.c, tcp_xmit_timer() delta = ((rtt - 1) << TCP_DELTA_SHIFT) - (tp->t_srtt >> (TCP_RTT_SHIFT - TCP_DELTA_SHIFT)); These codes works for 3.x and earlier versions. But I am not sure they are still OK for 4.0R. I could not explain to students, so,,, could somebody help us? Thank you very much. Noritoshi Demizu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 7:23:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from marsh.owlnet.rice.edu (marsh-49.owlnet.rice.edu [128.42.49.222]) by hub.freebsd.org (Postfix) with ESMTP id 1B64937B737 for ; Tue, 20 Jun 2000 07:23:17 -0700 (PDT) (envelope-from schlem@owlnet.rice.edu) Received: from jungle.owlnet.rice.edu (jungle.owlnet.rice.edu [128.42.49.103]) by marsh.owlnet.rice.edu (8.9.0/8.9.0) with ESMTP id JAA28287 for ; Tue, 20 Jun 2000 09:23:10 -0500 (CDT) Received: from localhost (schlem@localhost) by jungle.owlnet.rice.edu (8.9.0/8.9.0) with ESMTP id JAA18446 for ; Tue, 20 Jun 2000 09:23:10 -0500 (CDT) X-Authentication-Warning: jungle.owlnet.rice.edu: schlem owned process doing -bs Date: Tue, 20 Jun 2000 09:23:10 -0500 (CDT) From: Julie Elizabeth Schlembach To: freebsd-net@freebsd.org Subject: Using timestamp option of ip header (IPOPT_TS) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all - Does anyone out there know how to.. a) Activate the timestamp option of the ip header (IPOPT_TS) b) Read these timestamps at the destination machine (by modifying tcpdump...?) Thanks! Best regards, Julie *****julie schlembach***** rice university 2002 schlem@rice.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 8: 4:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 4C6FD37BEC9 for ; Tue, 20 Jun 2000 08:04:50 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA34550; Tue, 20 Jun 2000 11:04:36 -0400 (EDT) (envelope-from wollman) Date: Tue, 20 Jun 2000 11:04:36 -0400 (EDT) From: Garrett Wollman Message-Id: <200006201504.LAA34550@khavrinen.lcs.mit.edu> To: Julie Elizabeth Schlembach Cc: freebsd-net@FreeBSD.ORG Subject: Using timestamp option of ip header (IPOPT_TS) In-Reply-To: References: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > a) Activate the timestamp option of the ip header (IPOPT_TS) sysctl -w net.inet.tcp.rfc1323=1 (which should be the default state, but some ancient buggy PPP servers break when they see one and in any case it defeats VJ header compression). > b) Read these timestamps at the destination machine (by modifying > tcpdump...?) No modification required. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 8:43:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from marsh.owlnet.rice.edu (marsh-49.owlnet.rice.edu [128.42.49.222]) by hub.freebsd.org (Postfix) with ESMTP id 1EAD337BF0D for ; Tue, 20 Jun 2000 08:43:16 -0700 (PDT) (envelope-from schlem@owlnet.rice.edu) Received: from jungle.owlnet.rice.edu (jungle.owlnet.rice.edu [128.42.49.103]) by marsh.owlnet.rice.edu (8.9.0/8.9.0) with ESMTP id KAA18985; Tue, 20 Jun 2000 10:43:11 -0500 (CDT) Received: from localhost (schlem@localhost) by jungle.owlnet.rice.edu (8.9.0/8.9.0) with ESMTP id KAA04789; Tue, 20 Jun 2000 10:43:10 -0500 (CDT) X-Authentication-Warning: jungle.owlnet.rice.edu: schlem owned process doing -bs Date: Tue, 20 Jun 2000 10:43:10 -0500 (CDT) From: Julie Elizabeth Schlembach To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: Using timestamp option of ip header (IPOPT_TS) In-Reply-To: <200006201504.LAA34550@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, this would activate the timestamp of the tcp header, but we are hoping to turn on the timestamp option of the (lower level) IP header. It does not seem as though sysctl has an analogous mechanism for IP. Thank you -Julie On Tue, 20 Jun 2000, Garrett Wollman wrote: > < said: > > > a) Activate the timestamp option of the ip header (IPOPT_TS) > > sysctl -w net.inet.tcp.rfc1323=1 > > (which should be the default state, but some ancient buggy PPP servers > break when they see one and in any case it defeats VJ header > compression). > > > b) Read these timestamps at the destination machine (by modifying > > tcpdump...?) > > No modification required. > > -GAWollman > > -- > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same > wollman@lcs.mit.edu | O Siem / The fires of freedom > Opinions not those of| Dance in the burning flame > MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 9: 0:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from bart.esiee.fr (bart.esiee.fr [147.215.1.20]) by hub.freebsd.org (Postfix) with ESMTP id 053B537BF51 for ; Tue, 20 Jun 2000 09:00:20 -0700 (PDT) (envelope-from bonnetf@bart.esiee.fr) Received: (from bonnetf@localhost) by bart.esiee.fr (8.10.1/8.10.1) id e5KG0EI08765 for freebsd-net@freebsd.org; Tue, 20 Jun 2000 18:00:14 +0200 (MEST) From: Frank Bonnet Message-Id: <200006201600.e5KG0EI08765@bart.esiee.fr> Subject: Tuning a proxy-cache ? To: freebsd-net@freebsd.org Date: Tue, 20 Jun 2000 18:00:13 MEST X-Mailer: Elm [revision: 212.5] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I use a proxy-cache with Squid software and wonder if some gurus could help in "FreeBSD tuning" to make it as "efficient" as possible. The machine is a HP netserver 300 Mhz with 20 Gb SCSI disks and 256 Mb RAM running 4.0-20000608-STABLE Thanks -- Frank Bonnet Groupe ESIEE Paris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 10:24:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from game.over.net (game.over.net [193.189.189.100]) by hub.freebsd.org (Postfix) with ESMTP id 2852C37B5E5 for ; Tue, 20 Jun 2000 10:24:47 -0700 (PDT) (envelope-from tomaz.borstnar@over.net) Received: from [212.30.66.171] ([212.30.66.171]:7719 "EHLO user.over.net") by mail.over.net with ESMTP id ; Tue, 20 Jun 2000 19:24:23 +0200 Message-Id: <4.3.2.7.2.20000620191202.04bd2140@193.189.189.100> X-Sender: tmail@193.189.189.100 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Jun 2000 19:13:00 -0100 To: Brian Somers From: Tomaz Borstnar Subject: Re: Fwd: Re: ppp and lqr - Warning: lqr_RecvEcho: Got packet size 54, expecting 12 ! Cc: freebsd-net@FreeBSD.ORG, brian@Awfulhak.org, brian@hak.lan.Awfulhak.org In-Reply-To: <200006200920.KAA59860@hak.lan.Awfulhak.org> References: <4.3.2.7.2.20000620065859.03d208f0@193.189.189.100> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:20 AM 20/06/00, Brian Somers wrote the following message: >Oops, I wasn't just being stupid in fsm.c WRT padding (the bit I >fixed), I was also being stupid in lqr.c !!! Seems to work great now! >I've now fixed that too. Thanks for your patience. No, thanks for your time and service you do for all of us. Tomaz ---- Tomaz Borstnar "Love is the answer to the final question you ask" - Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 10:37:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 28F2F37C02C for ; Tue, 20 Jun 2000 10:37:07 -0700 (PDT) (envelope-from julian@elischer.org) Received: from marakesh-20.budapest.interware.hu ([195.70.50.148] helo=jules.elischer.org) by mail.interware.hu with smtp (Exim 3.12 #1 (Debian)) id 134SBy-0003ou-00; Tue, 20 Jun 2000 19:52:07 +0200 Message-ID: <394FAB91.794BDF32@elischer.org> Date: Tue, 20 Jun 2000 10:36:17 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Tarik Alj Cc: archie@whistle.com, gregoire@cholla.inrs-telecom.uquebec.ca, "Vitaly V. Belekhov" , net@freebsd.org Subject: Re: bridge + VLAN + netgraph References: <200006152006.QAA06392@cholla.INRS-Telecom.UQuebec.CA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tarik Alj wrote: > > Hi, > > we are interested in develloping a netgraph > bridge node following the > 802.1Q standard; that is a bridge with VLAN support > and eventually GARP applications support. I have read > the recent thread about bridging and netgraph, > and have also read the article on netgraph in daemonnews. > However it is not very clear if work is being done as to > devellop a bridge node or if it is scheduled > for later on. I would also be interested if you > had any advice or suggestions on > the matter. > > Sincerely, Archie will also comment but I may be able to help you too. There is VLAN support in FreeBSD but it is independent to the Netgraph framework as it was developed independently by other people. I have not looked at it closely. It would be noce if we could consolidate these things under the single framework. It would of course be possible to implement VLAN support using netgraph. There is also a 'backwards ethernet' netgraph node written by Vitaly V. Belekhov (CC'd)and available at www.riss-telecom.ru/~vitaly/ This node may be of some use to you.. The standard 'ethenet' node was recently re-written and will be checked in soon. check: ftp://ftp.whistle.com/pub/archie/misc/NGETHER.patch.2 the changed semantics may be of use to you also. These supercede changes at http://home.earthlink.net/~evmax/ng.tar.gz made by Maksim Yevmenkin In -current there is work to make bridging more suitable for inclusion into netgraph but it is not complete yet. Archie will have more info.. > > Tarik. > > -------------------------------------------------------------------------------- > > Tarik Alj > > INRS-Telecommunications > Place Bonaventure > 900 De La Gauchetierre Ouest > Niveau C, Case Postale 644 > Montreal, Qc, H5A 1C6 > Canada > > 514 875-1266 #2036 (email preferred) -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 )_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 11: 5:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id EE0CE37B941 for ; Tue, 20 Jun 2000 11:05:22 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA35181; Tue, 20 Jun 2000 14:05:18 -0400 (EDT) (envelope-from wollman) Date: Tue, 20 Jun 2000 14:05:18 -0400 (EDT) From: Garrett Wollman Message-Id: <200006201805.OAA35181@khavrinen.lcs.mit.edu> To: Julie Elizabeth Schlembach Cc: Garrett Wollman , freebsd-net@FreeBSD.ORG Subject: Re: Using timestamp option of ip header (IPOPT_TS) In-Reply-To: References: <200006201504.LAA34550@khavrinen.lcs.mit.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Well, this would activate the timestamp of the tcp header, but we are > hoping to turn on the timestamp option of the (lower level) IP header. It > does not seem as though sysctl has an analogous mechanism for IP. Sorry, I misread your original message. The only way to use the IP timestamp option under FreeBSD is to send raw packets (using the SOCK_RAW interface) with either header included (IP_HDRINCL) or by reading and writing the option explicitly (IP_RECVOPTS and IP_OPTIONS). -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 11:24:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from marsh.owlnet.rice.edu (marsh-49.owlnet.rice.edu [128.42.49.222]) by hub.freebsd.org (Postfix) with ESMTP id 2EA3937B829 for ; Tue, 20 Jun 2000 11:24:41 -0700 (PDT) (envelope-from schlem@owlnet.rice.edu) Received: from jungle.owlnet.rice.edu (jungle.owlnet.rice.edu [128.42.49.103]) by marsh.owlnet.rice.edu (8.9.0/8.9.0) with ESMTP id NAA04072; Tue, 20 Jun 2000 13:23:46 -0500 (CDT) Received: from localhost (schlem@localhost) by jungle.owlnet.rice.edu (8.9.0/8.9.0) with ESMTP id NAA11601; Tue, 20 Jun 2000 13:23:46 -0500 (CDT) X-Authentication-Warning: jungle.owlnet.rice.edu: schlem owned process doing -bs Date: Tue, 20 Jun 2000 13:23:46 -0500 (CDT) From: Julie Elizabeth Schlembach To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: Using timestamp option of ip header (IPOPT_TS) In-Reply-To: <200006201805.OAA35181@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > by reading and writing the option explicitly > (IP_RECVOPTS and IP_OPTIONS). Thanks for your input so far. This seems to be what we would like to do - how exactly do we go about doing it? What part of the code needs to be modified? We are using FreeBSD v3.2. Thanks -Julie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 12: 5:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 9E84E37BFCD for ; Tue, 20 Jun 2000 12:05:49 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id MAA26374; Tue, 20 Jun 2000 12:05:13 -0700 (PDT) From: Archie Cobbs Message-Id: <200006201905.MAA26374@bubba.whistle.com> Subject: Re: Patch review request (ng_ether(4)) In-Reply-To: <3938AA5E.15FB7483@elischer.org> from Julian Elischer at "Jun 2, 2000 11:49:02 pm" To: julian@elischer.org (Julian Elischer) Date: Tue, 20 Jun 2000 12:05:13 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer writes: > > > > > As soon as I can access freefall again I'll put up a new patch. > > > > > > > > OK, try this one: > > > > > > > > ftp://ftp.whistle.com/pub/archie/misc/NGETHER.patch.2 > > > > > > you need to block attaches to orphan if the lower hook is in use, > > > and visa versa. > > > > It should already do that.. they both use priv->lower. > > OK > > comment in ng_ether_input_orphan() is wrong. > > You can't use NG_SEND_DATA_RET() in an ethernet driver (on input) > because you need to use NG_QUEUE_DATA() (splimp, remember) > My thought is that you would supply a separate hook for > 'FILTER' operations which you would warn would have to > be run at splimp. The splnet and splimp graphs can only be joined > by queueing links (going up). I think this needs work, and there > is a possibility that we could put transfer characteristics > as a property on links so that the right thing happens. OK, back from vacation :-) Here's a new patch addressing the above problem: ftp://ftp.whistle.com/pub/archie/misc/NGETHER.patch.3 > The FILTER hooks would either have to be attached > to nodes that use NG_QUEUE_DATA(), or which > had no connection to the splnet universe. Automatic registration > of spl levels on hooks might lead to some automatic handling > of this but > a/ I think the programmer should know what is going on. > b/ this may all become moot with the removal of SPLs for > interrupts. I vote for option (b) :-) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 12:23: 1 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id EB2AD37BBAB for ; Tue, 20 Jun 2000 12:22:55 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id VAA02289; Tue, 20 Jun 2000 21:24:12 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200006201924.VAA02289@info.iet.unipi.it> Subject: Re: bridge + VLAN + netgraph In-Reply-To: <394FAB91.794BDF32@elischer.org> from Julian Elischer at "Jun 20, 2000 10:36:17 am" To: Julian Elischer Date: Tue, 20 Jun 2000 21:24:12 +0200 (CEST) Cc: Tarik Alj , archie@whistle.com, gregoire@cholla.inrs-telecom.uquebec.ca, "Vitaly V. Belekhov" , net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Tarik Alj wrote: > > > > Hi, > > > > we are interested in develloping a netgraph > > bridge node following the > > 802.1Q standard; that is a bridge with VLAN support If i can comment: i dod a VLAN bridge (between cards on the same VLAN and supporting TRUNK interfaces) back in 2.2.x times, and was looking at porting this to 3.x/4.x just this morning. The way i did it was within /sys/net/bridge.c and without the VLAN supoprt in RELENG_3 and above. The implementation within bridge.c is relatively straightforward (and tightly related to the idea of clusters of interfaces which is already in the source tree). The only problem is perhaps performance because the VLAN header insertion/deletion is done manually rather than resorting to the hardware support that some cards might have. On the other hand, i am not sure either if if_vlan.c does support it. I am not sure how easy would it be to make bridging see directly the "vlanX" interface because i think you cannot define a trunk interface, and also there is the problem that vlan_input() calls ether_input again so there is the need for some care in avoiding that the packet is forwarded twice. Plus, i am not really sure how vlan works with Archie's commits to simplify device drivers. 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-net" in the body of the message From owner-freebsd-net Tue Jun 20 12:57: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 9C24137BFC0 for ; Tue, 20 Jun 2000 12:57:06 -0700 (PDT) (envelope-from nick@rapidnet.com) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id NAA90562 for ; Tue, 20 Jun 2000 13:57:05 -0600 (MDT) Date: Tue, 20 Jun 2000 13:57:05 -0600 (MDT) From: Nick Rogness To: freebsd-net@freebsd.org Subject: Encrypted tunnel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello ya'll! Question #1: I have several tunnels (IPv4 -> IPv4) setup on several machines using nos style tunnels (nos-tun(8)). What are my options to add encryption to the existing framework? Question #2: Can someone point me to a website or give me some info on the IPSEC feature within the kernel. WHat does that allow me to do? I know how IPSEC works conceptually, how would I implement it's features? Question #3: Is there work in progress of a VPN style server/client package that would allow for dynamic tunnel updates? For exapmle: client -> authenticates --> server | client <- send tunnel updates <-| client updates local tunnels. I've looked at the source code for several routing protocols that essentially does this. However, I have just begun to play with network sockets and I've cranked out a weak version of this. Is anyone else even using tunnels? Is this worth the time to follow up? What other FreeBSD VPN implementations are available (with the exception of PPTP) ? Any ideas would be helpfull. Nick Rogness - Speak softly and carry a Gigabit switch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 14:32:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 3F92737BFB6 for ; Tue, 20 Jun 2000 14:32:36 -0700 (PDT) (envelope-from julian@elischer.org) Received: from mogadishu-49.budapest.interware.hu ([195.70.52.113] helo=jules.elischer.org) by mail.interware.hu with smtp (Exim 3.12 #1 (Debian)) id 134Vs9-0005Ra-00; Tue, 20 Jun 2000 23:47:54 +0200 Message-ID: <394FE2CE.1CFBAE39@elischer.org> Date: Tue, 20 Jun 2000 14:31:58 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: Patch review request (ng_ether(4)) References: <200006201905.MAA26374@bubba.whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs wrote: > > > You can't use NG_SEND_DATA_RET() in an ethernet driver (on input) > > because you need to use NG_QUEUE_DATA() (splimp, remember) > > My thought is that you would supply a separate hook for > > 'FILTER' operations which you would warn would have to > > be run at splimp. The splnet and splimp graphs can only be joined > > by queueing links (going up). I think this needs work, and there > > is a possibility that we could put transfer characteristics > > as a property on links so that the right thing happens. > > OK, back from vacation :-) > > Here's a new patch addressing the above problem: > > ftp://ftp.whistle.com/pub/archie/misc/NGETHER.patch.3 Not sure if using the stub code in output makes sense if it's not used on the input side.. looks good though I'm not the person to convince.... > > > The FILTER hooks would either have to be attached > > to nodes that use NG_QUEUE_DATA(), or which > > had no connection to the splnet universe. Automatic registration > > of spl levels on hooks might lead to some automatic handling > > of this but > > a/ I think the programmer should know what is going on. > > b/ this may all become moot with the removal of SPLs for > > interrupts. > > I vote for option (b) :-) yeah, hear no evil, see no..... > > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 )_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 15:58: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by hub.freebsd.org (Postfix) with SMTP id D8A6C37B660 for ; Tue, 20 Jun 2000 15:57:55 -0700 (PDT) (envelope-from root@gits.dyndns.org) Received: (qmail 5304999 invoked from network); 20 Jun 2000 22:57:53 -0000 Received: from r224m65.cybercable.tm.fr (HELO gits.dyndns.org) ([195.132.224.65]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 20 Jun 2000 22:57:53 -0000 Received: (from root@localhost) by gits.dyndns.org (8.9.3/8.9.3) id AAA04355; Wed, 21 Jun 2000 00:57:48 +0200 (CEST) (envelope-from root) Posted-Date: Wed, 21 Jun 2000 00:57:48 +0200 (CEST) To: net@FreeBSD.ORG Subject: Re: ipfw: about P:2 packets References: <200006172350.BAA11791@gits.dyndns.org> <20000619173621.B11284@sunbay.com> <20000620024839.D1447@spotteswoode.de> Reply-To: clefevre@citeweb.net X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C From: Cyrille Lefevre Date: 21 Jun 2000 00:57:46 +0200 In-Reply-To: "clemensF"'s message of "Tue, 20 Jun 2000 02:48:39 +0200" Message-ID: <66r42c5x.fsf@pc166.gits.fr> Lines: 19 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "clemensF" writes: > > Ruslan Ermilov: > > > These are IGMP packets (IP protocol 2). > > You can `allow igmp from any to any' or something like this... > > if ... it's implemented! $fwcmd add pass igmp from ${oip} to 224.0.0.0/24 seems to work for me. no more messages in /var/adm/security after killall routed/routed -s. Cyrille. -- home:mailto:clefevre@no-spam.citeweb.net Supprimer "no-spam." pour me repondre. work:mailto:Cyrille.Lefevre@no-spam.edf.fr Remove "no-spam." to answer me back. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 17:22:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 5E10537B904 for ; Tue, 20 Jun 2000 17:22:48 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id UAA27742; Tue, 20 Jun 2000 20:22:44 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200006210022.UAA27742@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Julie Elizabeth Schlembach Cc: Garrett Wollman , freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Using timestamp option of ip header (IPOPT_TS) References: In-reply-to: Your message of "Tue, 20 Jun 2000 13:23:46 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jun 2000 20:22:44 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > by reading and writing the option explicitly > > (IP_RECVOPTS and IP_OPTIONS). > > Thanks for your input so far. This seems to be what we would like to do - > how exactly do we go about doing it? What part of the code needs to be > modified? We are using FreeBSD v3.2. > You should really think twice about using this mechanism in any sort of application that you care about. Most routers which are used on the global Internet are optimized for forwarding "normal" traffic at very high rates of speed and completely insane packet-per-second forwarding rate. Processing the record route with timestamp IP option (and source route) will cause the packet to generally not be forwarded along the highly optimized (and in most cases, hardware assisted) path, but to be faulted up to a CPU to be processed as an exception in a the "slow" path. There are other mechanisms available to capture a timestamp of when the packet was received on the local FreeBSD box if that's the timestamp you're concerned with. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 17:53:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from pogo.caustic.org (pogo.caustic.org [208.44.193.69]) by hub.freebsd.org (Postfix) with ESMTP id B6E8A37B53A for ; Tue, 20 Jun 2000 17:53:33 -0700 (PDT) (envelope-from jan@caustic.org) Received: from localhost (jan@localhost) by pogo.caustic.org (8.10.0/ignatz) with ESMTP id e5L0rbg28847; Tue, 20 Jun 2000 17:53:37 -0700 (PDT) Date: Tue, 20 Jun 2000 17:53:36 -0700 (PDT) From: "f.johan.beisser" To: Nick Rogness Cc: freebsd-net@FreeBSD.ORG Subject: Re: Encrypted tunnel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org weee fun! On Tue, 20 Jun 2000, Nick Rogness wrote: > > > Hello ya'll! > > Question #1: > > I have several tunnels (IPv4 -> IPv4) setup on several machines > using nos style tunnels (nos-tun(8)). What are my options to add > encryption to the existing framework? option #1 seems to be ssh tunnels, via ppp through your existing tunnel. option #2 may be a replacement of the existing tunnels with IPSec (see below). > Question #2: > > Can someone point me to a website or give me some info on the IPSEC > feature within the kernel. WHat does that allow me to do? I know how > IPSEC works conceptually, how would I implement it's features? i'd suggest reading the RFC off of faqs.org, it's RFC 2401 (at least, that's the version i've been reading as a base reference). other places to look are www.kame.net (the KAME project), and in the freebsd source code itself. hope this helps a little bit. another resource i've found helpful, is netbsd's site on IPSec, which was (IMHO) decidedly better than freebsd's (i've not looked recently). -- jan +-----/ f. johan beisser /------------------------------+ email: jan[at]caustic.org web: http://www.caustic.org/~jan "knowledge is power. power corrupts. study hard, be evil." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 17:56:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id CCB2C37B9AC for ; Tue, 20 Jun 2000 17:56:08 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from modemcable009.62-201-24.mtl.mc.videotron.net ([24.201.62.9]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FWH00DIHAQ02A@field.videotron.net> for freebsd-net@freebsd.org; Tue, 20 Jun 2000 20:30:00 -0400 (EDT) Date: Tue, 20 Jun 2000 20:31:50 -0400 (EDT) From: Bosko Milekic Subject: mbuf re-write(s), v 0.1 (fwd) X-Sender: bmilekic@jehovah.technokratis.com To: freebsd-net@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What follows is what I sent to --hackers earlier today, but was told later that it would probably be more appropriate here. Regards, Bosko. _____________________________________________________________________________ Date: Tue, 20 Jun 2000 13:43:42 -0400 (EDT) From: Bosko Milekic To: freebsd-hackers@freebsd.org Subject: mbuf re-write(s), v 0.1 In an attempt to eliminate or significantly reduce the hogging of physical memory by unused mbufs, I have begun re-writing some of the mbuf subsystem. I've re-written the allocator and designed an actual free routine, and have also considerably re-written the MGET, MGETHDR, and MFREE macros. I still have some work to do with this, notably optimisation, but I have not been able to do any profiling whatsoever as profiling, I repeat, seems presently broken on -CURRENT. This is particularily useful for machines which see "peak" mbuf usage periods, where many mbufs are allocated, only to be freed a little while later, but which will unfortunately remain on the free list, holding on to physical memory (for a graphical example, see the THIRD graph at http://www.technokratis.com/stats/mbuf.html). Previously, we used to use the kernel malloc() to do mbuf allocations, coupled with the free() routine to do the freeing. However, the new allocator does not have to worry about chosing the right algorithm, and notably, variable sized objects. Of course, I still have some performance tuning to do, but need the profiling to work for that. Of course, there is an min_on_avail variable added to the code, which is yet to be made sysctl-tunable, and which represents the minimum amount of mbufs that must reside on the free lists, so that the system will not explicitly free pages on every occasion it gets. The reason I named this "v 0.1" has to do with the work that is left to be done here. I've, for the moment, removed the m_reclaim() and wait code for mbufs, but this will all have to be re-placed appropriately (not much voodoo involved here). However, I've moved the mclusters to their own map, mcl_map, which is the correct thing to do here, in order to avoid having to worry about fragmentation in the allocation routines (we want most efficiency possible). I'll go ahead and change the mcluster stuff soon, too, and hopefully fix up some of the mclrefcnt usage for clusters. I'll discuss more of this in time to come, and post the URL here. Also, I'm planning to write an optional "mbuf daemon" that can periodically walk the mbuf system's AVAIL_LST, and EMPTY_LST, and re-organize order of elements on, particularily, the AVAIL_LST, in order to minimize fragmentation during allocations, and augment % utilization for the allocator(s). It should also optionally do some other neat tasks, but I haven't exactly decided on which ones, although I'd like to avoid having it raise to splimp() for too long, though. Unlike what some of you may be thinking right now, this is not theoretical work, I have some diffs right here: http://www.technokratis.com/code/mbuf/ (you'll have to excuse my big tabs) The diffs provided for now are context diffs, and they do several things, among the which (not to go too much into details): 1* Implement new mbuf allocator, implement free routine, re-write mbuf allocation and free macros. Add necessary lists / structures for the new system. 2* Change to OID_AUTO for all sysctls in uipc_mbuf.c 3* Make /sys/sys/mbuf.h look nicer, more consistent comments, etc. 4* Have mbuf clusters remain the same for now, but move them over to mcl_map 5* Remove (temporarily) mbuf wait/reclaim stuff. The diffs are in working condition on -CURRENT (as of a couple of days ago, at least), and I'm running them with no apparent problems as we speak. % utilization is great, for now, and I hope that the daemon-to-come will bring it up even higher. I can also tune it with the min_on_avail variable. Of course, from the above 5 points, you'll quickly note that I still have to go around and rebuild userland stuff, but that will wait until the end of all mbuf system modifications. Comments welcome. Special thanks to Mike Silbersack for already discussing such issues with me. Regards, Bosko -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 bmilekic@technokratis.com * http://www.technokratis.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 21: 4:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from dustdevil.waterspout.com (dustdevil.waterspout.com [208.13.60.151]) by hub.freebsd.org (Postfix) with ESMTP id 7780737B62D for ; Tue, 20 Jun 2000 21:04:55 -0700 (PDT) (envelope-from csg@dustdevil.waterspout.com) Received: (from csg@localhost) by dustdevil.waterspout.com (8.9.3/8.9.3) id XAA01138; Tue, 20 Jun 2000 23:10:01 -0500 (EST) (envelope-from csg) Date: Tue, 20 Jun 2000 23:10:00 -0500 From: "C. Stephen Gunn" To: Luigi Rizzo Cc: freebsd-net@freebsd.org Subject: Re: bridge + VLAN + netgraph Message-ID: <20000620231000.A1128@waterspout.com> References: <394FAB91.794BDF32@elischer.org> <200006201924.VAA02289@info.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006201924.VAA02289@info.iet.unipi.it>; from luigi@info.iet.unipi.it on Tue, Jun 20, 2000 at 09:24:12PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jun 20, 2000 at 09:24:12PM +0200, Luigi Rizzo wrote: > Plus, i am not really sure how vlan works with Archie's commits > to simplify device drivers. Having poked my fingers around in if_vlan.c, and having reviewed some of Archie's Ethernet cleanups I wouldn't anticipate any problems. I've got some test-boxen around that I could muck with if we're interested in real data points. :) - Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 21:27:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from h2o.riss-telecom.ru (Relay1-ET0.riss-telecom.ru [195.239.105.2]) by hub.freebsd.org (Postfix) with SMTP id 44F3B37B7F2 for ; Tue, 20 Jun 2000 21:27:09 -0700 (PDT) (envelope-from vitaly@h2o.riss-telecom.ru) Received: (qmail 2294 invoked by uid 1000); 21 Jun 2000 04:27:06 -0000 Date: Wed, 21 Jun 2000 11:27:06 +0700 (NOVST) From: "Vitaly V. Belekhov" To: Julian Elischer Cc: Tarik Alj , archie@whistle.com, gregoire@cholla.inrs-telecom.uquebec.ca, net@freebsd.org Subject: Re: bridge + VLAN + netgraph In-Reply-To: <394FAB91.794BDF32@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi. On Tue, 20 Jun 2000, Julian Elischer wrote: > Tarik Alj wrote: > > > > Hi, > > > > we are interested in develloping a netgraph > > bridge node following the > > 802.1Q standard; that is a bridge with VLAN support > > and eventually GARP applications support. I have read > > the recent thread about bridging and netgraph, > > and have also read the article on netgraph in daemonnews. > > However it is not very clear if work is being done as to > > devellop a bridge node or if it is scheduled > > for later on. I would also be interested if you > > had any advice or suggestions on > > the matter. > > It would of course be possible to implement VLAN support using > netgraph. There is also a 'backwards ethernet' netgraph node > written by Vitaly V. Belekhov (CC'd)and > available at www.riss-telecom.ru/~vitaly/ > This node may be of some use to you.. > The standard 'ethenet' node was recently re-written > and will be checked in soon. My work with netgraph can be reused easily (I think) for bridge implementation. There is no need for 'backwards ethernet' node even (if your bridge dont need to recieve bridged packets itself :). Just see on graph on my page for example how to construct nodes chain for traffic capturing/processing. -- Vitaly Belekhov RISS-Telecom Networking Center, Novosibirsk Chief system administrator To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 21:28:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from dustdevil.waterspout.com (dustdevil.waterspout.com [208.13.60.151]) by hub.freebsd.org (Postfix) with ESMTP id AD19C37B85D for ; Tue, 20 Jun 2000 21:28:50 -0700 (PDT) (envelope-from csg@dustdevil.waterspout.com) Received: (from csg@localhost) by dustdevil.waterspout.com (8.9.3/8.9.3) id XAA01222; Tue, 20 Jun 2000 23:33:46 -0500 (EST) (envelope-from csg) Date: Tue, 20 Jun 2000 23:33:46 -0500 From: "C. Stephen Gunn" To: Julian Elischer Cc: Tarik Alj , archie@whistle.com, gregoire@cholla.inrs-telecom.uquebec.ca, "Vitaly V. Belekhov" , net@FreeBSD.ORG Subject: Re: bridge + VLAN + netgraph Message-ID: <20000620233346.B1128@waterspout.com> References: <200006152006.QAA06392@cholla.INRS-Telecom.UQuebec.CA> <394FAB91.794BDF32@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <394FAB91.794BDF32@elischer.org>; from julian@elischer.org on Tue, Jun 20, 2000 at 10:36:17AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jun 20, 2000 at 10:36:17AM -0700, Julian Elischer wrote: > There is VLAN support in FreeBSD but it is independent to > the Netgraph framework as it was developed independently by > other people. I have not looked at it closely. The VLAN driver was mostly written by Garrett Wollman. > It would be nice if we could consolidate these things under > the single framework. our 802.1q VLAN implementation is complicated by several issues: - 802.1q is a Layer-2 in Layer-2 encapsulation. Tagged frames are encapsulated with an ethertype of 0x8100, followed by a 16-bit field encoding VLAN and Priority. Since we have our VLAN devices masquerade to the rest of the system as regular ethernet interfaces (preserving the link header for things like BPF). We can't simply prepend/strip headers from the beginning of the mbuf like most netgraph modules. - Some hardware support tag insertion/extraction. I'm not sure that hardware tag insertion is a win, since we still have to store the tag somewhere for I/O to the card. We might as well just store the tag in the packet. Proably quicker than coding for the exceptional case of hardware support. - Since VLANs shove another 4-byte field in the Ethernet Frame, we bump the MTU by 4 bytes. Some cards/drivers reject frames larger than 1500 bytes as giants. This limits the interfaces recommended for user with VLANs. As someone pointed out in discussions with me, MTU is a TCP/IP concept, not an intrinsic property of an interface. > The standard 'ethenet' node was recently re-written > and will be checked in soon. > > check: > ftp://ftp.whistle.com/pub/archie/misc/NGETHER.patch.2 I think that ether_input2() is a horrible name. I would advocate naming ether_demux(). This accurately describes its function. It would take a pointer to an ifnet, a pointer to the link-header, and a the mbuf chain. It should update packet counters, and then appropriately dispatch the packet to upper protocol layers. We could then modify ether_input() to take the full mbuf, including the headers (like NetBSD). Drivers that want/need to optimize the selection of packets (NE2000 drivers?) could do their busywork and pass the packet to ether_demux(). - Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 20 21:37:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 8914337B935 for ; Tue, 20 Jun 2000 21:37:39 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id GAA04059; Wed, 21 Jun 2000 06:38:45 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200006210438.GAA04059@info.iet.unipi.it> Subject: Re: bridge + VLAN + netgraph In-Reply-To: <20000620233346.B1128@waterspout.com> from "C. Stephen Gunn" at "Jun 20, 2000 11:33:46 pm" To: "C. Stephen Gunn" Date: Wed, 21 Jun 2000 06:38:45 +0200 (CEST) Cc: Julian Elischer , Tarik Alj , archie@whistle.com, gregoire@cholla.inrs-telecom.uquebec.ca, "Vitaly V. Belekhov" , net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > - Since VLANs shove another 4-byte field in the Ethernet Frame, > we bump the MTU by 4 bytes. Some cards/drivers reject frames actually we should bump up not the MTU, but the max acceptable frame size in the device driver. I think most interfaces will accept the change just fine, it's just really boring to look after all interfaces and fix the initialization of the card. > We could then modify ether_input() to take the full mbuf, including > the headers (like NetBSD). Drivers that want/need to optimize I already suggested that, but no luck :( 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-net" in the body of the message From owner-freebsd-net Wed Jun 21 7:46: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from marsh.owlnet.rice.edu (marsh-49.owlnet.rice.edu [128.42.49.222]) by hub.freebsd.org (Postfix) with ESMTP id 6DDE337B832 for ; Wed, 21 Jun 2000 07:46:06 -0700 (PDT) (envelope-from skoe@owlnet.rice.edu) Received: from jungle.owlnet.rice.edu (jungle.owlnet.rice.edu [128.42.49.103]) by marsh.owlnet.rice.edu (8.9.0/8.9.0) with ESMTP id JAA22154; Wed, 21 Jun 2000 09:46:02 -0500 (CDT) Received: from localhost (skoe@localhost) by jungle.owlnet.rice.edu (8.9.0/8.9.0) with ESMTP id JAA10558; Wed, 21 Jun 2000 09:46:02 -0500 (CDT) X-Authentication-Warning: jungle.owlnet.rice.edu: skoe owned process doing -bs Date: Wed, 21 Jun 2000 09:46:02 -0500 (CDT) From: "Anders Chr. Skoe" To: freebsd-net@FreeBSD.ORG Cc: Julie Schlembach , louie@TransSys.COM Subject: Re: Using timestamp option of ip header (IPOPT_TS) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Processing the record route with timestamp IP option (and source route) will > cause the packet to generally not be forwarded along the highly optimized > (and in most cases, hardware assisted) path, but to be faulted up to > a CPU to be processed as an exception in a the "slow" path. Julie & I are attempting to implement an edge admission control algorithm (more specifically, the Egress Admission Control developed here at Rice - see http://www.ece.rice.edu/networks/publications.html). This approach only requires us to 'stamp' the packets at the ingress router - the intermediate routers should simply forward them. We read the timestamps at the egress router and perform some calculations (the routers are synchronized using NTP). Our idea was to 'activate' the timestamping only at the ingress, hopefully in a manner such that we only get the 'slow path' at the ingress (and eventually egress) router. We were thinking about using a flag analogous to IPOPT_TS_TSANDADDR (eg. IPOPT_TS_INGRESS) to indicate that the timestamping only be done at this edge router. Do you think this might work? -or will we be forced into the 'slow path' on the intermediate routers as long as there are options present? An alternative would be to use the ip_off and ip_tos bits for the timestamp, but we're particularly wary of using the ip_off bits - after all, they serve a purpose. If anyone knows of an example implementation of ip timestamping (online or printed), we would be most grateful. Once we get the timestamping going, we can start worrying about some of the other issues. > There are other mechanisms available to capture a timestamp of when > the packet was received on the local FreeBSD box if that's the > timestamp you're concerned with. libpcap & tcpdump ;-) Thanks for your help so far. Cheers! Anders To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 7:48:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id D7DE337B51B for ; Wed, 21 Jun 2000 07:48:49 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id KAA39286; Wed, 21 Jun 2000 10:48:46 -0400 (EDT) (envelope-from wollman) Date: Wed, 21 Jun 2000 10:48:46 -0400 (EDT) From: Garrett Wollman Message-Id: <200006211448.KAA39286@khavrinen.lcs.mit.edu> To: "C. Stephen Gunn" Cc: net@FreeBSD.ORG Subject: Re: bridge + VLAN + netgraph In-Reply-To: <20000620233346.B1128@waterspout.com> References: <200006152006.QAA06392@cholla.INRS-Telecom.UQuebec.CA> <394FAB91.794BDF32@elischer.org> <20000620233346.B1128@waterspout.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > - Since VLANs shove another 4-byte field in the Ethernet Frame, > we bump the MTU by 4 bytes. Some cards/drivers reject frames > larger than 1500 bytes as giants. This limits the interfaces > recommended for user with VLANs. As someone pointed out > in discussions with me, MTU is a TCP/IP concept, not an > intrinsic property of an interface. This paragraph is somewhat incorrect. Ethernet (that is, IEEE 802.3) defines a maximum packet length, which is 1518 octets, including header and CRC. In conjunction with IEEE 802.1p, this maximum packet length is increased to 1522 octets. Whether or not you use 802.1p/Q tagging, the MTU of an Ethernet is and remains 1500 octets; the increased maximum length of an 802.1p packet is entirely in the header. (If the MTU is not 1500 octets, it's not Ethernet.) Some network interfaces make it possible to directly configure the maximum packet length. Others consider 1522-octet frames to be errors, so the only way to enable reception of tagged frames on these interfaces is to accept error frames and then rely on additional software mechanism to distinguish long frames from those with other sorts of errors. (Typically on these types of interfaces it is necessary to manually trim off the CRC as well.) Still others are simply unable to participate in 802.1p/Q networks. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 8:37:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from nothing-going-on.demon.co.uk (dhcp120.conference.usenix.org [209.179.127.120]) by hub.freebsd.org (Postfix) with ESMTP id 0AA8137BED6 for ; Wed, 21 Jun 2000 08:37:19 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) id UAA00906 for net@freebsd.org; Tue, 20 Jun 2000 20:17:34 GMT (envelope-from nik) Date: Tue, 20 Jun 2000 20:17:34 +0000 From: Nik Clayton To: net@freebsd.org Subject: No route for 127/8 to lo0 Message-ID: <20000620201733.A665@kilt.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Organization: FreeBSD Project Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chaps, [ Not on -net, please cc: replies back to me ] This is a continuation of a discussion I started on -hackers some time ago (with the same subject line), but -net is probably the more appropriate forum. Why don't we automatically include a network route for 127/8 to lo0? I first noticed this when I saw Samba repeatedly triggering a PPP dialup. It turns out Samba is sending occasional broadcasts to 127.255.255.255. There's no route for that address on a 3.4/4.x system, so the packets end up going out of the default route. This is bad for PPP systems (or other systems that pay for outgoing traffic in some way). RFC1122 says [...] (g) { 127, } Internal host loopback address. Addresses of this form MUST NOT appear outside a host. [...] For most purposes, a datagram addressed to a broadcast or multicast destination is processed as if it had been addressed to one of the host's IP addresses; Is there some special-case for 127/8 that's covered by the "For most purposes" line? If you look in src/sys/netinet/in.c:in_ifinit() (around line 700) you'll see that IFF_LOOPBACK is special cased in the code to only add a host route, rather than a network route, and it's been like that for about 15 years or so. At the moment I just have a /usr/local/etc/rc.d/local-route.sh script which runs route add -net 127 -interface lo0 at startup. But it's a bit of a kludge. . . N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 8:58:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 44FFE37BEE6 for ; Wed, 21 Jun 2000 08:58:09 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id IAA86149; Wed, 21 Jun 2000 08:55:32 -0700 (PDT) From: Archie Cobbs Message-Id: <200006211555.IAA86149@bubba.whistle.com> Subject: Re: bridge + VLAN + netgraph In-Reply-To: <200006210438.GAA04059@info.iet.unipi.it> from Luigi Rizzo at "Jun 21, 2000 06:38:45 am" To: luigi@info.iet.unipi.it (Luigi Rizzo) Date: Wed, 21 Jun 2000 08:55:32 -0700 (PDT) Cc: csg@waterspout.com (C. Stephen Gunn), julian@elischer.org (Julian Elischer), aljtarik@cholla.inrs-telecom.uquebec.ca (Tarik Alj), archie@whistle.com, gregoire@cholla.inrs-telecom.uquebec.ca, vitaly@riss-telecom.ru (Vitaly V. Belekhov), net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo writes: > > We could then modify ether_input() to take the full mbuf, including > > the headers (like NetBSD). Drivers that want/need to optimize > > I already suggested that, but no luck :( I think this is a good idea too.. I didn't include it in the patch a couple of weeks ago to avoid changing too many things at once; this change is orthogonal from the BPF extraction stuff. After all, you'd think a function named "ether_input" would take an Ethernet frame as input.. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 9: 5:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 53B5837B887 for ; Wed, 21 Jun 2000 09:05:24 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id JAA86211; Wed, 21 Jun 2000 09:03:42 -0700 (PDT) From: Archie Cobbs Message-Id: <200006211603.JAA86211@bubba.whistle.com> Subject: Re: bridge + VLAN + netgraph In-Reply-To: <20000620233346.B1128@waterspout.com> from "C. Stephen Gunn" at "Jun 20, 2000 11:33:46 pm" To: csg@waterspout.com (C. Stephen Gunn) Date: Wed, 21 Jun 2000 09:03:42 -0700 (PDT) Cc: julian@elischer.org (Julian Elischer), aljtarik@cholla.inrs-telecom.uquebec.ca (Tarik Alj), archie@whistle.com, gregoire@cholla.inrs-telecom.uquebec.ca, vitaly@riss-telecom.ru (Vitaly V. Belekhov), net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org C. Stephen Gunn writes: > > The standard 'ethenet' node was recently re-written > > and will be checked in soon. > > > > check: > > ftp://ftp.whistle.com/pub/archie/misc/NGETHER.patch.2 > > I think that ether_input2() is a horrible name. I would advocate > naming ether_demux(). This accurately describes its function. Good point.. I've changed the name.. ftp://ftp.whistle.com/pub/archie/misc/NGETHER.patch.4 -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 9:57:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 91C2737BEF6; Wed, 21 Jun 2000 09:57:16 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id RAA21484; Wed, 21 Jun 2000 17:57:13 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id RAA45382; Wed, 21 Jun 2000 17:57:09 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006211657.RAA45382@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Nik Clayton Cc: net@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: No route for 127/8 to lo0 In-Reply-To: Message from Nik Clayton of "Tue, 20 Jun 2000 20:17:34 -0000." <20000620201733.A665@kilt.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jun 2000 17:57:08 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [.....] > Is there some special-case for 127/8 that's covered by the "For most > purposes" line? > > If you look in src/sys/netinet/in.c:in_ifinit() (around line 700) you'll > see that IFF_LOOPBACK is special cased in the code to only add a host > route, rather than a network route, and it's been like that for about 15 > years or so. > > At the moment I just have a /usr/local/etc/rc.d/local-route.sh script > which runs > > route add -net 127 -interface lo0 > > at startup. But it's a bit of a kludge. . . I think the real problem here is that the networking code in general treats IFF_LOOPBACK as a non-IFF_BROADCAST interface. I don't think anything would break if this was changed, but I'd definitely think that a ``remove the broadcast bit'' ioctl would be in order - so that the old behaviour could be achieved. > N > -- > Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. > Telephone line, $24.95 a month. Software, free. USENET transmission, > hundreds if not thousands of dollars. Thinking before posting, priceless. > Somethings in life you can't buy. For everything else, there's MasterCard. > -- Graham Reed, in the Scary Devil Monastery -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 12: 1:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id 6C93A37B6CA for ; Wed, 21 Jun 2000 12:01:27 -0700 (PDT) (envelope-from ras@e-gerbil.net) Received: from localhost (ras@localhost) by overlord.e-gerbil.net (8.9.3/8.9.3) with ESMTP id CAA25305; Tue, 11 Apr 2000 02:06:35 -0400 (EDT) (envelope-from ras@e-gerbil.net) X-Authentication-Warning: overlord.e-gerbil.net: ras owned process doing -bs Date: Tue, 11 Apr 2000 02:06:35 -0400 (EDT) From: "Richard A. Steenbergen" To: Garrett Wollman Cc: Julie Elizabeth Schlembach , freebsd-net@FreeBSD.ORG Subject: Re: Using timestamp option of ip header (IPOPT_TS) In-Reply-To: <200006201504.LAA34550@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 20 Jun 2000, Garrett Wollman wrote: > < said: > > > a) Activate the timestamp option of the ip header (IPOPT_TS) > > sysctl -w net.inet.tcp.rfc1323=1 > > (which should be the default state, but some ancient buggy PPP servers > break when they see one and in any case it defeats VJ header > compression). This enables the TCP option for timestamping, not the IP option. There is a significant difference. :P You really don't want to enable the IP option timestamping, or any IP options for that matter. -- Richard A Steenbergen http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 15:33:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id 6BFE337B69B for ; Wed, 21 Jun 2000 15:33:18 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id AAA01569; Thu, 22 Jun 2000 00:33:33 +0200 (CEST) (envelope-from assar) To: Josef Karthauser Cc: freebsd-net@FreeBSD.ORG Subject: Re: cvs commit: src/sys/sys sockio.h src/sys/net if.c src/sbin/ifconfig ifconfig.8 ifconfig.c References: <200006162014.NAA12344@freefall.freebsd.org> <20000617011757.C4271@pavilion.net> <010101bfd886$a4e23a50$040aa8c0@local.mindstep.com> <20000619094252.H22172@pavilion.net> From: Assar Westerlund Date: 22 Jun 2000 00:33:33 +0200 In-Reply-To: Josef Karthauser's message of "Mon, 19 Jun 2000 09:42:52 +0100" Message-ID: <5lzooek6ki.fsf@assaris.sics.se> Lines: 27 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Josef Karthauser writes: > On Sat, Jun 17, 2000 at 02:05:39PM -0400, Patrick Bihan-Faou wrote: > > > > > Horray! At last there's some hope of getting dhcp to give me the same > > > lease irrespective of which pccard ethernet card I plug in :). > > > > You can already to this by specifying the DHCP client-id for your machine. > > Most DHCP servers will honor that and since it is under your control, you > > don't need to hack the MAC address to obtain the same lease even when you > > change you ethernet card. > > > > How do I specify my unique key to dhclient? The version currently in FreeBSD > doesn't appear to have any options for this. > > Joe option dhcp-client-identifier ; or option host-name ; See dhclient.conf(5). /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 16:56:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id 3B7CF37C0CD for ; Wed, 21 Jun 2000 16:56:41 -0700 (PDT) (envelope-from ino-waiting@gmx.net) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtp (Exim 3.14 #3) id 134uMK-000296-00 for net@freebsd.org; Thu, 22 Jun 2000 01:56:40 +0200 Received: from [213.6.3.10] (helo=spotteswoode.de) by mx0.freenet.de with smtp (Exim 3.14 #3) id 134uMI-0002X8-00 for net@freebsd.org; Thu, 22 Jun 2000 01:56:39 +0200 Received: (qmail 5069 invoked by uid 0); 21 Jun 2000 23:57:08 -0000 From: "clemensF" Date: Thu, 22 Jun 2000 01:57:08 +0200 To: Nik Clayton Cc: net@freebsd.org Subject: Re: No route for 127/8 to lo0 Message-ID: <20000622015708.G1130@spotteswoode.de> References: <20000620201733.A665@kilt.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20000620201733.A665@kilt.nothing-going-on.org>; from nik@freebsd.org on Tue, Jun 20, 2000 at 08:17:34PM +0000 Organization: private X-PGP-ID: 0xD4685B88-4894C483/DH X-PGP-FPR: 0FAE 5F53 CEB9 49DE 9300 3035 D468 5B88 4894 C483 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Nik Clayton: > Why don't we automatically include a network route for 127/8 to lo0? > > If you look in src/sys/netinet/in.c:in_ifinit() (around line 700) you'll > see that IFF_LOOPBACK is special cased in the code to only add a host > route, rather than a network route, and it's been like that for about 15 > years or so. i don't understand this. what's the difference between a host route and a network route? should this not be the same for 127.0.0.1? > route add -net 127 -interface lo0 > > at startup. But it's a bit of a kludge. . . why is this a kludge? clemens To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 17:12:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by hub.freebsd.org (Postfix) with ESMTP id AE31937B95E for ; Wed, 21 Jun 2000 17:12:10 -0700 (PDT) (envelope-from ino-waiting@gmx.net) Received: from [62.104.201.2] (helo=mx1.freenet.de) by mout0.freenet.de with esmtp (Exim 3.14 #3) id 134ubI-0001t5-00 for freebsd-net@freebsd.org; Thu, 22 Jun 2000 02:12:08 +0200 Received: from [213.6.3.10] (helo=spotteswoode.de) by mx1.freenet.de with smtp (Exim 3.14 #3) id 134ubG-0000dK-00 for freebsd-net@FreeBSD.ORG; Thu, 22 Jun 2000 02:12:07 +0200 Received: (qmail 5345 invoked by uid 0); 22 Jun 2000 00:12:36 -0000 From: "clemensF" Date: Thu, 22 Jun 2000 02:12:36 +0200 To: freebsd-net@FreeBSD.ORG Subject: Re: cvs commit: src/sys/sys sockio.h src/sys/net if.c src/sbin/ifconfig ifconfig.8 ifconfig.c Message-ID: <20000622021236.H1130@spotteswoode.de> Mail-Followup-To: freebsd-net@FreeBSD.ORG References: <200006162014.NAA12344@freefall.freebsd.org> <20000617011757.C4271@pavilion.net> <010101bfd886$a4e23a50$040aa8c0@local.mindstep.com> <20000619094252.H22172@pavilion.net> <5lzooek6ki.fsf@assaris.sics.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5lzooek6ki.fsf@assaris.sics.se>; from assar@sics.se on Thu, Jun 22, 2000 at 12:33:33AM +0200 Organization: private X-PGP-ID: 0xD4685B88-4894C483/DH X-PGP-FPR: 0FAE 5F53 CEB9 49DE 9300 3035 D468 5B88 4894 C483 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Assar Westerlund: > option dhcp-client-identifier ; > > or > > option host-name ; does this mean these identifiers are defined at kernel build time? how do leases fit into this? clemens To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 18:32:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 5BDC237B563 for ; Wed, 21 Jun 2000 18:32:25 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id SAA02533 for freebsd-net@freebsd.org; Wed, 21 Jun 2000 18:32:24 -0700 (PDT) From: Archie Cobbs Message-Id: <200006220132.SAA02533@bubba.whistle.com> Subject: testers for PPPoE? To: freebsd-net@freebsd.org Date: Wed, 21 Jun 2000 18:32:23 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I've added PPPoE support to mpd, only I don't have a way to test it. If anyone has access to a PPPoE connection and would like to try it out, the new version is 3.0b8 (I just updated the net/mpd-netgraph port).. Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 19:25:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id DE45137B774 for ; Wed, 21 Jun 2000 19:25:47 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id WAA35025; Wed, 21 Jun 2000 22:25:45 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200006220225.WAA35025@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Anders Chr. Skoe" Cc: freebsd-net@FreeBSD.ORG, Julie Schlembach X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Using timestamp option of ip header (IPOPT_TS) References: In-reply-to: Your message of "Wed, 21 Jun 2000 09:46:02 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jun 2000 22:25:45 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I don't think you want any IP options present at all. Depending on the specific implementations in routers, some (most?) will punt IP datagrams with options to a conventional CPU to process. As you only seem to care about timestamps as the packets are leaving the host, and as they arrive at the destination (I think?), there's an alternative approach you might consider. How about having a software shim, perhaps in the form of another network interface which encapsulates the packet to be sent inside another datagram which contains the timestamp the packet was sent (or at least queued for transmission). The remote host could then use the SO_TIMESTAMP socket option to cause a timestamp to be captured when the packet is received. (Though this only currently works for UDP sockets.) louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 20:25:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail1.rdc3.on.home.com (mail1.rdc3.on.home.com [24.2.9.40]) by hub.freebsd.org (Postfix) with ESMTP id F043537BEBF; Wed, 21 Jun 2000 20:24:58 -0700 (PDT) (envelope-from danyc@playground.net) Received: from playground.net ([24.114.192.235]) by mail1.rdc3.on.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <20000622032457.HVHM416.mail1.rdc3.on.home.com@playground.net>; Wed, 21 Jun 2000 20:24:57 -0700 Message-ID: <39518709.83A7BBDB@playground.net> Date: Wed, 21 Jun 2000 23:24:57 -0400 From: Dany Cayouette Reply-To: danyc@playground.net X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: PPPoE with service selection Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greetings, did anyone have the chance to try PPPoE with service selection. I've been testing with 3.4-R (with Netgraph compiled in the kernel). It's been working find for me (once I incresed the carrier detect time in my ppp.conf). The subscriber gateway/PPPoE server has been upgraded and know offers 'multiple' service in the PADO. When that is the case, the PPPoE client never sends a PADR. Is there new code that deals with service selection in netgraph or am I missing something? ppp.conf looks like: default: set device PPPoE:de0 set MRU 1490 set MTU 1490 set authname user@isp1 set authkey password set log Phase Chat LCP IPCP CCP tun command physical set dial set ifaddr 10.0.0.1/0 10.0.0.2/0 add default HISADDR set cd 10 set crtscts off Sample tcpdump looks like: 18:03:19.089309 PPPoE PADI v1, type 1, sess 0 len 12 [Service-Name] [Host-Uniq 4 06778c0] 1109 0000 000c 0101 0000 0103 0004 4067 78c0 18:03:19.102592 PPPoE PADO v1, type 1, sess 0 len 42 [Service-Name] [Service-Nam e isp001] [Service-Name isp002] [AC-Name ssg001] [Host-Uniq 406778c0] 1107 0000 002a 0101 0000 0101 0006 6973 7030 3031 0101 0006 6973 7030 3032 0102 0006 7373 6730 3031 0103 0004 4067 78c0 Thanks for your help! Dany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 20:43:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id EE9EB37B6DF for ; Wed, 21 Jun 2000 20:43:52 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id XAA42436; Wed, 21 Jun 2000 23:43:40 -0400 (EDT) (envelope-from wollman) Date: Wed, 21 Jun 2000 23:43:40 -0400 (EDT) From: Garrett Wollman Message-Id: <200006220343.XAA42436@khavrinen.lcs.mit.edu> To: "Louis A. Mamakos" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Using timestamp option of ip header (IPOPT_TS) In-Reply-To: <200006220225.WAA35025@whizzo.transsys.com> References: <200006220225.WAA35025@whizzo.transsys.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I don't think you want any IP options present at all. Depending on the > specific implementations in routers, some (most?) will punt IP datagrams > with options to a conventional CPU to process. It's even worse than that... some routers will punt any packets which: - are fragmented - have options - don't have the ``right'' protocol field The second is well-known; I've heard of the first and have actually measured the third. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 20:59:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id DE5EA37B7E2 for ; Wed, 21 Jun 2000 20:59:06 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id XAA35435; Wed, 21 Jun 2000 23:59:04 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200006220359.XAA35435@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Using timestamp option of ip header (IPOPT_TS) References: <200006220225.WAA35025@whizzo.transsys.com> <200006220343.XAA42436@khavrinen.lcs.mit.edu> In-reply-to: Your message of "Wed, 21 Jun 2000 23:43:40 EDT." <200006220343.XAA42436@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jun 2000 23:59:04 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > < said: > > > I don't think you want any IP options present at all. Depending on the > > specific implementations in routers, some (most?) will punt IP datagrams > > with options to a conventional CPU to process. > > It's even worse than that... some routers will punt any packets which: > > - are fragmented > - have options > - don't have the ``right'' protocol field > > The second is well-known; I've heard of the first and have actually > measured the third. Yeah, the second became well-known in the early MBONE days where source routed packets were used before IP-in-IP tunnels were used to construct the virtual topology. But the first and the third are just broken. I'm not surprised (little surprises me any more), but mostly disappointed. I'll have to make sure our lab guys add these things to their performance tests. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 21:27:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from tts.tomsk.su (tts.tomsk.su [212.20.50.9]) by hub.freebsd.org (Postfix) with ESMTP id 83A8E37C1B6 for ; Wed, 21 Jun 2000 21:27:44 -0700 (PDT) (envelope-from maksim@tts.tomsk.su) Received: from dragonland (unverified [212.20.50.12]) by tts.tomsk.su (Rockliffe SMTPRA 2.1.6) with SMTP id for ; Thu, 22 Jun 2000 12:27:42 +0800 From: "Maksimov Maksim" To: Subject: How defend from stream2.c attack? Date: Thu, 22 Jun 2000 12:27:50 +0800 Message-ID: <002001bfdc02$39ad3080$0c3214d4@dragonland.tts.tomsk.su> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Importance: Normal Disposition-Notification-To: "Maksimov Maksim" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am insert in my kernel config file this strings: options ICMP_BANDLIM options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN options TCP_RESTRICT_RST #restrict emission of TCP RST and insert in my rc.conf config file this strings: tcp_keepalive="YES" # Enable stale TCP connection timeout (or NO). tcp_drop_synfin="YES" # Set to YES to drop TCP packets with SYN+FIN # NOTE: this violates the TCP specification tcp_restrict_rst="YES" # Set to YES to restrict emission of RST icmp_drop_redirect="YES" # Set to YES to ignore ICMP REDIRECT packets icmp_log_redirect="NO" # Set to YES to log ICMP REDIRECT packets icmp_bmcastecho="NO" # respond to broadcast ping packets and recompile my kernel, and reboot my computer, and set net.inet.icmp.icmplim down to 20, and add rules to my firewall (I use IPFilter 3.4.6): block in quick on ed0 from any to 255.255.255.255 block in quick on ed0 from any to my.local.subnet.255 BUT stream2.c attack freezed my FreeBSD 4.0-20000608-STABLE as before!!! Best regards, Maks Maksimov mailto:maksim@tts.tomsk.su To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 21 21:39: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail1.rdc3.on.home.com (mail1.rdc3.on.home.com [24.2.9.40]) by hub.freebsd.org (Postfix) with ESMTP id 74F7637C167; Wed, 21 Jun 2000 21:39:01 -0700 (PDT) (envelope-from danyc@playground.net) Received: from playground.net ([24.114.192.235]) by mail1.rdc3.on.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <20000622043900.IEBZ416.mail1.rdc3.on.home.com@playground.net>; Wed, 21 Jun 2000 21:39:00 -0700 Message-ID: <39519864.19D8954C@playground.net> Date: Thu, 22 Jun 2000 00:39:00 -0400 From: Dany Cayouette Reply-To: danyc@playground.net X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: PPPoE with service selection References: <39518709.83A7BBDB@playground.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I forgot to add that the system is also complaining about "packet fragmented" when I 'dial' via PPPoE dany Dany Cayouette wrote: > Greetings, > did anyone have the chance to try PPPoE with service selection. I've > been testing with 3.4-R (with Netgraph compiled in the kernel). It's > been working find for me (once I incresed the carrier detect time in my > ppp.conf). The subscriber gateway/PPPoE server has been upgraded and > know offers 'multiple' service in the PADO. When that is the case, the > PPPoE client never sends a PADR. Is there new code that deals with > service selection in netgraph or am I missing something? > > ppp.conf looks like: > default: > set device PPPoE:de0 > set MRU 1490 > set MTU 1490 > set authname user@isp1 > set authkey password > set log Phase Chat LCP IPCP CCP tun command physical > set dial > set ifaddr 10.0.0.1/0 10.0.0.2/0 > add default HISADDR > set cd 10 > set crtscts off > > Sample tcpdump looks like: > 18:03:19.089309 PPPoE PADI v1, type 1, sess 0 len 12 [Service-Name] > [Host-Uniq 4 > 06778c0] > 1109 0000 000c 0101 0000 0103 0004 4067 > 78c0 > 18:03:19.102592 PPPoE PADO v1, type 1, sess 0 len 42 [Service-Name] > [Service-Nam > e isp001] [Service-Name isp002] [AC-Name ssg001] [Host-Uniq 406778c0] > 1107 0000 002a 0101 0000 0101 0006 6973 > 7030 3031 0101 0006 6973 7030 3032 0102 > 0006 7373 6730 3031 0103 0004 4067 78c0 > > Thanks for your help! > Dany > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 22 0:11:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 925DD37B565 for ; Thu, 22 Jun 2000 00:11:06 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id AAA10069; Thu, 22 Jun 2000 00:11:02 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id AAA13950; Thu, 22 Jun 2000 00:11:01 -0700 (PDT) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id AAA07254; Thu, 22 Jun 2000 00:11:01 -0700 (PDT) From: Don Lewis Message-Id: <200006220711.AAA07254@salsa.gv.tsc.tdk.com> Date: Thu, 22 Jun 2000 00:11:01 -0700 In-Reply-To: <002001bfdc02$39ad3080$0c3214d4@dragonland.tts.tomsk.su> References: <002001bfdc02$39ad3080$0c3214d4@dragonland.tts.tomsk.su> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: "Maksimov Maksim" , Subject: Re: How defend from stream2.c attack? Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jun 22, 12:27pm, "Maksimov Maksim" wrote: } Subject: How defend from stream2.c attack? } I am insert in my kernel config file this strings: } } options ICMP_BANDLIM } options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN } options TCP_RESTRICT_RST #restrict emission of TCP RST } } and insert in my rc.conf config file this strings: } } tcp_keepalive="YES" # Enable stale TCP connection timeout (or } NO). } tcp_drop_synfin="YES" # Set to YES to drop TCP packets with } SYN+FIN } # NOTE: this violates the TCP } specification } tcp_restrict_rst="YES" # Set to YES to restrict emission of RST } icmp_drop_redirect="YES" # Set to YES to ignore ICMP REDIRECT packets } icmp_log_redirect="NO" # Set to YES to log ICMP REDIRECT packets } icmp_bmcastecho="NO" # respond to broadcast ping packets } } and recompile my kernel, and reboot my computer, } and set net.inet.icmp.icmplim down to 20, } and add rules to my firewall (I use IPFilter 3.4.6): } block in quick on ed0 from any to 255.255.255.255 } block in quick on ed0 from any to my.local.subnet.255 } } BUT stream2.c attack freezed my FreeBSD 4.0-20000608-STABLE as before!!! I'm grasping at straws here, but maybe you need to configure your kernel with more mbufs. Are your running stream2 on the machine that is freezing or on another machine? If you configure DDB into your kernel, can you break into the debugger and get a stack trace after the machine freezes? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 22 0:53:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from tts.tomsk.su (tts.tomsk.su [212.20.50.9]) by hub.freebsd.org (Postfix) with ESMTP id 40E4037C1D0 for ; Thu, 22 Jun 2000 00:53:09 -0700 (PDT) (envelope-from maksim@tts.tomsk.su) Received: from dragonland (unverified [212.20.50.12]) by tts.tomsk.su (Rockliffe SMTPRA 2.1.6) with SMTP id for ; Thu, 22 Jun 2000 15:40:49 +0800 From: "Maksimov Maksim" To: Subject: RE: How defend from stream2.c attack? Date: Thu, 22 Jun 2000 15:40:57 +0800 Message-ID: <002c01bfdc1d$348b9b30$0c3214d4@dragonland.tts.tomsk.su> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Importance: Normal Disposition-Notification-To: "Maksimov Maksim" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm grasping at straws here, but maybe you need to configure > your kernel > with more mbufs. Output netstat -m before attack: 1/320/4096 mbufs in use (current/peak/max): 1 mbufs allocated to data 0/80/1024 mbuf clusters in use (current/peak/max) 240 Kbytes allocated to network (0% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Output netstat -m during attack: ...... 108/320/4096 mbufs in use (current/peak/max): 67 mbufs allocated to data 41 mbufs allocated to socket names and addresses 25/80/1024 mbuf clusters in use (current/peak/max) 240 Kbytes allocated to network (32% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines ........ 177/320/4096 mbufs in use (current/peak/max): 114 mbufs allocated to data 63 mbufs allocated to socket names and addresses 50/80/1024 mbuf clusters in use (current/peak/max) 240 Kbytes allocated to network (60% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines ........ 156/320/4096 mbufs in use (current/peak/max): 96 mbufs allocated to data 60 mbufs allocated to socket names and addresses 35/80/1024 mbuf clusters in use (current/peak/max) 240 Kbytes allocated to network (45% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines ......... Output netstat -m in 1 second after attack: 1/560/4096 mbufs in use (current/peak/max): 1 mbufs allocated to data 0/130/1024 mbuf clusters in use (current/peak/max) 400 Kbytes allocated to network (0% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines So you see - Nothing terrible! Problem is not in mbufs quantity. Problem in FreeBSD's TCP stack. > > Are your running stream2 on the machine that is freezing or on another > machine? I'm running stream2 on different machine: I'm attacked my FreeBSD boxes from RedHat 5.2 Linux (kernel 2.0.36 -0.7) Computer-attacker - RedHat 5.2 Linux (kernel 2.0.36 -0.7) (Pentium 200Mhz, networ card 10Mb) Computer-victim - FreeBSD 4.0-20000608-STABLE (i486 120Mhz, two network card 10Mb) FreeBSD 4.0-20000608-STABLE (i486 100Mhz, two network card 10Mb) All computers - and victims, and attacker - connected to same LAN (switched Ethernet on 3Com 10/100 Switch Super Stack II) Best regards, Maks Maksimov mailto:maksim@tts.tomsk.su To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 22 2:18:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 68F6437C205 for ; Thu, 22 Jun 2000 02:18:44 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id KAA52299; Thu, 22 Jun 2000 10:18:40 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id JAA01503; Thu, 22 Jun 2000 09:37:35 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006220837.JAA01503@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Archie Cobbs Cc: freebsd-net@FreeBSD.org, brian@hak.lan.Awfulhak.org Subject: Re: testers for PPPoE? In-Reply-To: Message from Archie Cobbs of "Wed, 21 Jun 2000 18:32:23 PDT." <200006220132.SAA02533@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Jun 2000 09:37:35 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hi, > > I've added PPPoE support to mpd, only I don't have a way to test it. > If anyone has access to a PPPoE connection and would like to try it > out, the new version is 3.0b8 (I just updated the net/mpd-netgraph port).. You can test using pppoed(8). > Thanks, > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 22 2:19: 4 2000 Delivered-To: freebsd-net@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id CAF2337C236; Thu, 22 Jun 2000 02:18:48 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id KAA52306; Thu, 22 Jun 2000 10:18:45 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id JAA01536; Thu, 22 Jun 2000 09:39:22 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006220839.JAA01536@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: danyc@playground.net Cc: freebsd-net@FreeBSD.org, freebsd-questions@FreeBSD.org, brian@hak.lan.Awfulhak.org Subject: Re: PPPoE with service selection In-Reply-To: Message from Dany Cayouette of "Wed, 21 Jun 2000 23:24:57 EDT." <39518709.83A7BBDB@playground.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Jun 2000 09:39:22 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Greetings, > did anyone have the chance to try PPPoE with service selection. I've > been testing with 3.4-R (with Netgraph compiled in the kernel). It's > been working find for me (once I incresed the carrier detect time in my > ppp.conf). The subscriber gateway/PPPoE server has been upgraded and > know offers 'multiple' service in the PADO. When that is the case, the > PPPoE client never sends a PADR. Is there new code that deals with > service selection in netgraph or am I missing something? > > ppp.conf looks like: > default: > set device PPPoE:de0 Try ``set device PPPoE:de0:service''. [.....] > Thanks for your help! > Dany -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 22 2:19: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id D18CE37C22D; Thu, 22 Jun 2000 02:18:51 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id KAA52310; Thu, 22 Jun 2000 10:18:47 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id JAA01558; Thu, 22 Jun 2000 09:41:46 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006220841.JAA01558@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: danyc@playground.net Cc: freebsd-net@FreeBSD.org, freebsd-questions@FreeBSD.org, brian@hak.lan.Awfulhak.org Subject: Re: PPPoE with service selection In-Reply-To: Message from Dany Cayouette of "Thu, 22 Jun 2000 00:39:00 EDT." <39519864.19D8954C@playground.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Jun 2000 09:41:46 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What's the actual error message ? > I forgot to add that the system is also complaining about "packet > fragmented" when I 'dial' via PPPoE > > dany > > Dany Cayouette wrote: > > > Greetings, > > did anyone have the chance to try PPPoE with service selection. I've > > been testing with 3.4-R (with Netgraph compiled in the kernel). It's > > been working find for me (once I incresed the carrier detect time in my > > ppp.conf). The subscriber gateway/PPPoE server has been upgraded and > > know offers 'multiple' service in the PADO. When that is the case, the > > PPPoE client never sends a PADR. Is there new code that deals with > > service selection in netgraph or am I missing something? > > > > ppp.conf looks like: > > default: > > set device PPPoE:de0 > > set MRU 1490 > > set MTU 1490 > > set authname user@isp1 > > set authkey password > > set log Phase Chat LCP IPCP CCP tun command physical > > set dial > > set ifaddr 10.0.0.1/0 10.0.0.2/0 > > add default HISADDR > > set cd 10 > > set crtscts off > > > > Sample tcpdump looks like: > > 18:03:19.089309 PPPoE PADI v1, type 1, sess 0 len 12 [Service-Name] > > [Host-Uniq 4 > > 06778c0] > > 1109 0000 000c 0101 0000 0103 0004 4067 > > 78c0 > > 18:03:19.102592 PPPoE PADO v1, type 1, sess 0 len 42 [Service-Name] > > [Service-Nam > > e isp001] [Service-Name isp002] [AC-Name ssg001] [Host-Uniq 406778c0] > > 1107 0000 002a 0101 0000 0101 0006 6973 > > 7030 3031 0101 0006 6973 7030 3032 0102 > > 0006 7373 6730 3031 0103 0004 4067 78c0 > > > > Thanks for your help! > > Dany -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 22 9:51:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 2980137C32E for ; Thu, 22 Jun 2000 09:51:19 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id TAA30059; Thu, 22 Jun 2000 19:50:07 +0300 (EEST) Date: Thu, 22 Jun 2000 19:50:07 +0300 From: Ruslan Ermilov To: Brian Somers Cc: Patrick Bihan-Faou , net@FreeBSD.org Subject: Re: "frag-anyways" knob. Message-ID: <20000622195007.C28777@sunbay.com> Mail-Followup-To: Brian Somers , Patrick Bihan-Faou , net@FreeBSD.org References: <200006211416.PAA33522@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="lEGEL1/lMxI0MVQ2" X-Mailer: Mutt 1.0i In-Reply-To: <200006211416.PAA33522@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on Wed, Jun 21, 2000 at 03:16:56PM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=us-ascii On Wed, Jun 21, 2000 at 03:16:56PM +0100, Brian Somers wrote: > > > I'd tend to agree that a divert(4) daemon would be a far cleaner > > > solution. > > > > > If community wishes I would probably go over it and implement this as > > a divert(4) daemon. > > Cool ! > Here is a standalone daemon which "corrects" the MSS option for outgoing TCP SYN packets based on the supplied MTU value. If run with -v it will stay attached to its controlling terminal and show the changes made: : Script started on Thu Jun 22 19:36:16 2000 : perl# ipfw add 100 divert 1234 tcp from any to any out via rl0 setup : 00100 divert 1234 tcp from any to any out xmit rl0 setup : perl# /usr/local/sbin/tcpmssd -p 1234 -m 1492 -v : MSS: 1460 -> 1452 : ^C : perl# exit : Script done on Thu Jun 22 19:37:03 2000 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 --lEGEL1/lMxI0MVQ2 Content-Type: application/x-tar-gz Content-Disposition: attachment; filename="tcpmssd.tgz" Content-Transfer-Encoding: base64 H4sIAFhDUjkAA+1ZWXPbyBH2K/kr2vTGBmXe1rHRlYJISEJMkQwBWlatt7gQAIoogwALB22v V/nt+XoG4CHJ2icllVpNWcCgp6fv6e6hE3s+i2On/uIJB2039hoNekHU3Ntprr/z0SDaa7a2 t7eb23u7WG40mrsvaOcphcpHGidWRPQiSh/H+7P1/9ORZP6/sD67E893n4IH3Ln7mP9bzXeZ /9+1Wq0dLDd3Ws0X1HgKYe6Ov7j/X9FPurNPufsrC2rWWtRqNBr1xm691aLmzv72zj68EqWk fZ3TT8XiYNg/OypkkVNsn3bVM+PtUfXS8v1ir3+h9o4KV5pRPNF7HX14VKincVT3Q9vy6/G1 FxSLNS+w/dRx6fA6dmrzKLypzT4fF//XpvhLjvz8Z++a/QQ8Hj//zdbe9lr+xwLO/97Ou+fz /98Y9a1qkbaoHc6/Rd7NNCHFLovjT8M09q2AtGjm+eGCkVTfJ4EUU+TGbrRwnRrgvDR0HS9O Iu86TbwwICtwKI1d8gKKwzSyXQHB4beibzQJo1lcoS9eMqUwEu8wTZjKLHS8iWdbTKNCVuTS 3AX7JHEdQppYeA4mydRK8HBBx/fDL15wQ3YYOB5vipkK75u5yT7Pm7U7osUUTnKZ7BA5aIYA gDqJBVmZqnUdLngpswcTwQjCxLPdCjC8mHzQYzIrtkK9TZnA1PYtb+ZGbCNq3RcEDNcskgsC PZ0Uwj2NLCS1zCg5oZ3O3CCxcqfV4Y8Q6xHNrMSNPMuPV4YXDmPC62rkAWCe6wYZ/VPzUh1q hDmKxAe9o3Xo5AqLGqkj87w/JLXXoXa/Zw71k5HZHxr022+qAfw3b3hJRFnvirSPg6FmGIQN +sWgq4MM6A7VnqlrRoX0Xrs76ui9swqBCvX6JnX1C90EmtmvMDsmdH8n9U/pQhu2z/Gpnuhd 3bwSAp3qZo/ZnbKANFCHpt4eddUhDUbDQd8Q1Fitjm60u6p+oXVqBCHAmLQPWs8k41ztdtfV xL8NLU80SKiedAUpwQZaojpqbZPVWc3asBmE61bIGGhtnSfaRw2aqMOrSkbW0P41AhIWmVpH vVDPoJvyJ1aBQ9qjoXbB8sIOxujEMHVzZGp01u93DCYF8oY2/KC3NeOAun1DGGxkaBUwMVXB HlRgLSxjfjIydGE3vWdqw+FoYOr9XpkJnfcvYRgIq2J3R9i43xM6w0b94RXTZXsIF1To8lwD fMgmFVZT2RYGrNc2mdoaJrjCnuaastTTzrr6mdZra7zaZ0KXuqGV4THdYARdcr5Ur4SOI6E+ +wqyyela6FaER0k/JbXzQWfhM2TEgaFnMdM/ZUrGqH2eWT8/BaKXWpbSB5qp3f3tvf13e6tm irbqxeKrZUMUf4vrcyuyZrXp8R1wHNqf3WQTHriJh7+6F4yBksx+tPoD+PxhOBTYXHCj6B4g CO+ImDjefZDvXd+FRchIm7A0QEJxGFaMORfZtAg9Byktilw7GcOYCraldsKmnToRbVUojr3f 3XFCvhuUDza2pbF14yo8xUIxHXtB0twF5sz6CkoHhUKhvoV+96s3S2d0gehdWH7q1tgRQKWF G12HsYut/FmcoS4oDLeiG7tC9hTNwhbmi19+LRe/FwsCMP+c/KIPxhfqx4Hafq+Zvx4UC7mA WIOMFZriyWCpiDenrTkeR6SsQcpAXuGwwy3HicZcRT2xGRCQAVV8S3osWpy9ZxPfuqnQLEkz wJwBmKfjeBpG+MYjW7Kn0LAgdkCIefZuYJWRxFRa6uPHj3Rj21S9hJsClBjLh2KOiNvClynu DKQo9hQ7btwknCeKNBSbqEKl2f58f1Eql+nlEVWb5WKhEKOMAB1bygT7FWwLfcKb2Zt9zAve BMQgP6hZSegpoAdC2H5Iuz9L/EIBwfdVaYK4F8B18PiFOZJOLMHjBSk2st9QU9vnOMCQFLBb fgh9374VWNz54IVTe+mKngFmRri6keXDULEna+I1WhOOkgxVGZ626ee9vyMAEZqMsVeuyTXB RQYZxGclqsQxEE5WLi6T4Fm4syDDWgp/HbnW54OlYebSMJlTpgkKvLJhGrFpvqbXHQILSSAL a9BoPoT1D4HluBMr9ROxQR6jcmaqe/aEOdnRVD0iSOIFzoEALOjtClAU/nwpg+yPP+jlPJ+J rcfUkC5dY3Wf021GRmGryhyoDE7HKDxcI/rt9+OheonKOUBlMvvjjo66YyJijkTACfoIGBEv cnfpEUbXv7tRqLzG6aosXeQFwsh41/A3nljoh79BlkyItSU+rLVYvLCu99ROZzhG6VlDyfwo D6JUDD2go6AfVu4ce6SD+4I8pBYTeEwp4YTM/3wC+dux3FkYKI0K+2CN5pKoRCg94v/l6c+2 ypTETlrJyzpK78k0iFWk9MUkCmesMoBL9TAvQ5qKPB9y/NAkryWzpT3y3CHqEucaDS3JME8Y X6woUEo54zxJoGNGmKbugcwOeE6lhMjL1WNvPp76dHhILaGDTBZ8UZq69mdu2EXp4EhHDggD XzTxhGRxE6K+SVyzPaC5xTEXy+aZo4smkXXDTTe69knsJhKVe/as3lESJkhBDJm6loNeHGLd JNO4VszTDKv6YNCtRx29fl2UlswVmguE7KCwcEsMJUjCaazkiJCsTK+BOu6fnl6oxnth58YK fxOdPcEImY+XWMKeh/fh2XdVIhwfPZwNhVPXe4C7TUCZY4beCirlVdxsUF9FYOwGThIuoy4v yyLgHo21LNTWIk3GkyQooum2iPgpZldpc+PqNbNs+BwXNVyHcS0LKZ07uFrBvYyLSuxGaLlQ jhFWcTrDvaJk2XaJd1j0rlW99sS1D7B0lvryoobrnoWrOF/F0H4EN27MhLNrXU6JFGjBEqCs hb6D1pNp0ZcwcsQVkXHj9DqJLNQxoHGdC9wvEgEnkeOvJCiVhKRxxi+jLuots712M5XEbwH1 4isUEXSRaJ//OTLMMTJG+70xulCgAdon3otjSZ9QLdBUoFgI0AED2EsMPBR1gSECB2bH62Dt W2AdH0OlMtwvvl5T4+sEo7zCA+0lnoRKybE/64fK9O+c8i25Purg9yfhsmLySQQK96bFR7rb xF71tzJORavJbdtUBG0on/NE9oDpWLalAIivvOPd4n5X7lvGDze2eaJL7OpxMuXTvkx0yPR6 1lVtJB/+oSYDZL/XZLkvFo2z8F1+3B88zVz15XFfqlQoRG6SRkHG924+tfgIZT87IIaNq16e TFcsXyqZDtxYxPCPeT4GYnmTOGdmJZQ6T2VueFBGYVLpOWnQMsjD900+46IghVKDxoGcyeYn d0bW+ohk8T3LOluC4hGXgv7AHGv9bnmj+xJR9wBirz8QiJJe3rXJGN2AbymCs5RR8szWDjlj w+rZ57EQWRBdsX9IRtxiDO0sr51rBF9KlK7Wy3EExmYhLcj2V1mLwnImYisrvExSFhAO0DIk k11zzlIgrPUrPCZzXBsTdhhCMKpk0EIJQbNPf0OrfYznp6C0XFljUMnpS/aF1Vlg+8kzcgde zVvtzZ0P5LRsRyU/TJzfMuwtaYoHCN3mF5LbrHaIjLB2ccVxL97VmUoCYfn7Av1SXfxK1blo Jqk64yvHJ9mxuV+9ROGIuH3+T5Xn8Tyex/N4Hs/jeTyP57Ex/gMN2gMGACgAAA== --lEGEL1/lMxI0MVQ2-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 22 11:12:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 0385F37BE9C for ; Thu, 22 Jun 2000 11:12:17 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id VAA32248; Thu, 22 Jun 2000 21:12:08 +0300 (EEST) Date: Thu, 22 Jun 2000 21:12:08 +0300 From: Ruslan Ermilov To: net@FreeBSD.org Subject: [CFV] where to put TCP MSS correction code Message-ID: <20000622211208.A30877@sunbay.com> Reply-To: Ruslan Ermilov Mail-Followup-To: net@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! There exists a well-known problem with broken Path MTU Discovery (see RFC 1191) due to the buggy router software and IP firewall misconfiguration. See http://www.FreeBSD.org/FAQ/ppp.html#AEN3714 and http://www.worldgate.com/~marcs/mtu/index.html for details. Patrick Bihan-Faou found a workaround for this problem where router "corrects" the value of TCP MSS option so that incoming packets are guaranteed to fit in advance without need to perform PMTU discovery cycle. If you are interested in this stuff, please choose from one of the following options, and reply directly to me at . 1. This functionality should be implemented within packet aliasing (NAT) library, libalias(3). This benefits from having this feature in both natd(8) and ppp(8). 2. This functionality is not suitable for NAT software and it should be implemented separately as a stand-alone daemon. (Already available at http://people.FreeBSD.org/~ru/tcpmssd.tgz). 3. Do both. Thank you, -- 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-net" in the body of the message From owner-freebsd-net Thu Jun 22 11:26:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id 52E4837BCA8 for ; Thu, 22 Jun 2000 11:26:47 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id JAA05683; Thu, 22 Jun 2000 09:07:14 +0200 (CEST) (envelope-from assar) To: "clemensF" Cc: freebsd-net@FreeBSD.ORG Subject: Re: cvs commit: src/sys/sys sockio.h src/sys/net if.c src/sbin/ifconfig ifconfig.8 ifconfig.c References: <200006162014.NAA12344@freefall.freebsd.org> <20000617011757.C4271@pavilion.net> <010101bfd886$a4e23a50$040aa8c0@local.mindstep.com> <20000619094252.H22172@pavilion.net> <5lzooek6ki.fsf@assaris.sics.se> <20000622021236.H1130@spotteswoode.de> From: Assar Westerlund Date: 22 Jun 2000 09:07:13 +0200 In-Reply-To: "clemensF"'s message of "Thu, 22 Jun 2000 02:12:36 +0200" Message-ID: <5ld7laqjml.fsf@assaris.sics.se> Lines: 16 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "clemensF" writes: > > Assar Westerlund: > > > option dhcp-client-identifier ; > > > > or > > > > option host-name ; > > does this mean these identifiers are defined at kernel build time? how do > leases fit into this? There are options in /etc/dhclient.conf and have nothing to do with the kernel configuration or build. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 22 13:41:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id DA53737B7B1 for ; Thu, 22 Jun 2000 13:41:08 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id VAA37139; Thu, 22 Jun 2000 21:36:17 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id UAA00485; Thu, 22 Jun 2000 20:25:02 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006221925.UAA00485@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Brian Somers , Patrick Bihan-Faou , net@FreeBSD.org Subject: Re: "frag-anyways" knob. In-Reply-To: Message from Ruslan Ermilov of "Thu, 22 Jun 2000 19:50:07 +0300." <20000622195007.C28777@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Jun 2000 20:25:01 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This looks good. In the PPPoE case, we need to be able to bring the program up and down based on any new MTU values negotiated by ppp(8). This could be done if tcpmssd had a ``create a pidfile'' option, where ppp.linkup could run ``tcpmssd -M IFMTU -P tcpmssd.INTERFACE.pid'' and ppp.linkdown could run ``kill `cat tcpmssd.INTERFACE.pid`''. Ppp would also need to expand IFMTU in command_Expand() in command.c. Does this make sense ? The only alternative I see is to implement this stuff in libalias and have tcpmssd use libalias. Cheers. > On Wed, Jun 21, 2000 at 03:16:56PM +0100, Brian Somers wrote: > > > > I'd tend to agree that a divert(4) daemon would be a far cleaner > > > > solution. > > > > > > > If community wishes I would probably go over it and implement this as > > > a divert(4) daemon. > > > > Cool ! > > > Here is a standalone daemon which "corrects" the MSS option for outgoing > TCP SYN packets based on the supplied MTU value. If run with -v it will > stay attached to its controlling terminal and show the changes made: > > : Script started on Thu Jun 22 19:36:16 2000 > : perl# ipfw add 100 divert 1234 tcp from any to any out via rl0 setup > : 00100 divert 1234 tcp from any to any out xmit rl0 setup > : perl# /usr/local/sbin/tcpmssd -p 1234 -m 1492 -v > : MSS: 1460 -> 1452 > : ^C > : perl# exit > : Script done on Thu Jun 22 19:37:03 2000 > > > 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 -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 22 14: 5:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by hub.freebsd.org (Postfix) with ESMTP id 01E0937BEC1; Thu, 22 Jun 2000 14:05:06 -0700 (PDT) (envelope-from danyc@playground.net) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Thu, 22 Jun 2000 16:01:40 -0500 Received: from zcard00b.ca.nortel.com ([47.128.208.105]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N2WKKAQM; Thu, 22 Jun 2000 17:02:51 -0400 Received: from playground.net (cr197841-a.ca.nortel.com [47.128.214.116]) by zcard00b.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NK23C67W; Thu, 22 Jun 2000 17:02:48 -0400 Message-ID: <39527EBC.A643A958@playground.net> Date: Thu, 22 Jun 2000 17:01:48 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Cayouette, Dany [CAR:5W10:EXCH]" Reply-To: danyc@playground.net X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Somers Cc: freebsd-net@FreeBSD.org, freebsd-questions@FreeBSD.org, brian@hak.lan.Awfulhak.org Subject: Re: PPPoE with service selection References: <200006220839.JAA01536@hak.lan.Awfulhak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org That did it. Thanks Brian! Brian Somers wrote: > > Greetings, > > did anyone have the chance to try PPPoE with service selection. I've > > been testing with 3.4-R (with Netgraph compiled in the kernel). It's > > been working find for me (once I incresed the carrier detect time in my > > ppp.conf). The subscriber gateway/PPPoE server has been upgraded and > > know offers 'multiple' service in the PADO. When that is the case, the > > PPPoE client never sends a PADR. Is there new code that deals with > > service selection in netgraph or am I missing something? > > > > ppp.conf looks like: > > default: > > set device PPPoE:de0 > > Try ``set device PPPoE:de0:service''. > > [.....] > > Thanks for your help! > > Dany > > -- > Brian > > Don't _EVER_ lose your sense of humour ! > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 22 14:18: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 18E6D37B60A; Thu, 22 Jun 2000 14:18:01 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (ip83.salt-lake-city9.ut.pub-ip.psi.net [38.31.167.83]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id PAA11838; Thu, 22 Jun 2000 15:17:43 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <395282AA.1CC568A2@softweyr.com> Date: Thu, 22 Jun 2000 15:18:34 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Martin Gignac Cc: Abdullah Bin Hamad , freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Free WebMail. References: <001901bfd969$5ddb2660$17c14dd4@qatar.net.qa> <004f01bfda65$4d52fe60$d80110ac@martingignac> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Martin Gignac wrote: > > NeoMail at http://neomail.sourceforget.net Which is GPL. Sigh. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 22 14:48:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from modemcable127.61-201-24.mtl.mc.videotron.net (modemcable014.183-200-24.mtl.mc.videotron.net [24.200.183.14]) by hub.freebsd.org (Postfix) with SMTP id 8EE0137BF55 for ; Thu, 22 Jun 2000 14:48:10 -0700 (PDT) (envelope-from patrick@mindstep.com) Received: (qmail 4410 invoked from network); 22 Jun 2000 21:48:06 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 22 Jun 2000 21:48:06 -0000 Message-ID: <016101bfdc93$8b43e8d0$040aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: "Brian Somers" , References: <200006221925.UAA00485@hak.lan.Awfulhak.org> Subject: Re: "frag-anyways" knob. Date: Thu, 22 Jun 2000 17:48:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > In the PPPoE case, we need to be able to bring the program up and > down based on any new MTU values negotiated by ppp(8). If the MSS update hack is in libalias, you just have to call the AliasSetMTU() function to set the new value. I tried to patch ppp for that, but was not succesful. I am not familiar with the code so... Also the updating of the MSS is in a separate function of alias.c. At this time it is static, but I guess it can be made public. I think the best is to discuss that with Ruslan. Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 23 0:25:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 1F08B37C0E6 for ; Fri, 23 Jun 2000 00:25:45 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id KAA46075; Fri, 23 Jun 2000 10:25:33 +0300 (EEST) Date: Fri, 23 Jun 2000 10:25:33 +0300 From: Ruslan Ermilov To: Brian Somers Cc: net@FreeBSD.org Subject: Re: "frag-anyways" knob. Message-ID: <20000623102533.A44764@sunbay.com> Mail-Followup-To: Brian Somers , net@FreeBSD.org References: <200006221925.UAA00485@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200006221925.UAA00485@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on Thu, Jun 22, 2000 at 08:25:01PM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jun 22, 2000 at 08:25:01PM +0100, Brian Somers wrote: > This looks good. > > In the PPPoE case, we need to be able to bring the program up and > down based on any new MTU values negotiated by ppp(8). > > This could be done if tcpmssd had a ``create a pidfile'' option, > where ppp.linkup could run ``tcpmssd -M IFMTU -P tcpmssd.INTERFACE.pid'' > and ppp.linkdown could run ``kill `cat tcpmssd.INTERFACE.pid`''. > > Ppp would also need to expand IFMTU in command_Expand() in command.c. > > Does this make sense ? The only alternative I see is to implement > this stuff in libalias and have tcpmssd use libalias. > Would it be enough if tcpmssd(8) could track interface MTU (kernel is capable of notifying user processes about MTU changes through a routing socket interface as of sys/net/if.c,v 1.83). usage: tcpmssd [-v] -p port [-i iface | -m mtu] So, if run as `tcpmssd -p 1234 -i tun0', it will peek the initial MTU value on startup and then will monitor routing socket for MTU changes. 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-net" in the body of the message From owner-freebsd-net Fri Jun 23 1:12: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from bart.esiee.fr (bart.esiee.fr [147.215.1.20]) by hub.freebsd.org (Postfix) with ESMTP id 7262837B8B6; Fri, 23 Jun 2000 01:12:05 -0700 (PDT) (envelope-from bonnetf@bart.esiee.fr) Received: (from bonnetf@localhost) by bart.esiee.fr (8.10.1/8.10.1) id e5N7RlT22788; Fri, 23 Jun 2000 09:27:47 +0200 (MEST) From: Frank Bonnet Message-Id: <200006230727.e5N7RlT22788@bart.esiee.fr> Subject: Re: Free WebMail. To: wes@softweyr.com Date: Fri, 23 Jun 2000 9:27:47 MEST Cc: mgignac@cinar.com, Arabian@ArabChat.Org, freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <395282AA.1CC568A2@softweyr.com>; from "Wes Peters" at Jun 22, 2000 3:18 pm X-Mailer: Elm [revision: 212.5] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Martin Gignac wrote: > > > > NeoMail at http://neomail.sourceforget.net > > Which is GPL. Sigh. > an alternate solution Postfix + roxen + IMHO + IMAP http://www.postfix.org http://www.roxen.com http://www.lysator.liu.se/~stewa/IMHO/ http://www.imap.org All Free stuff -- Frank Bonnet Groupe ESIEE Paris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 23 3:22:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from dorothy.hentschel.net (d83b0468.dsl.flashcom.net [216.59.4.104]) by hub.freebsd.org (Postfix) with ESMTP id AE42737B90C; Fri, 23 Jun 2000 03:22:06 -0700 (PDT) (envelope-from thomas@hentschel.net) Received: from hentschel.net (thomas@falcon.home.hentschel.net [192.168.1.2]) by dorothy.hentschel.net (8.8.8/8.8.8) with ESMTP id DAA25798; Fri, 23 Jun 2000 03:26:54 -0700 (PDT) (envelope-from thomas@hentschel.net) Message-Id: <200006231026.DAA25798@dorothy.hentschel.net> Date: Fri, 23 Jun 2000 03:27:09 -0700 (PDT) From: thomas@hentschel.net Subject: Re: Free WebMail. To: Frank Bonnet Cc: wes@softweyr.com, mgignac@cinar.com, Arabian@ArabChat.Org, freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <200006230727.e5N7RlT22788@bart.esiee.fr> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 23 Jun, Frank Bonnet wrote: >> >> Martin Gignac wrote: >> > >> > NeoMail at http://neomail.sourceforget.net >> >> Which is GPL. Sigh. >> > > an alternate solution > > Postfix + roxen + IMHO + IMAP > > http://www.postfix.org > http://www.roxen.com > http://www.lysator.liu.se/~stewa/IMHO/ > http://www.imap.org > or Worldpilot (www.worldpilot.org), license is BSD-like.... -Th To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 23 4:34: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from sivka.carrier.kiev.ua (sivka.carrier.kiev.ua [193.193.193.101]) by hub.freebsd.org (Postfix) with ESMTP id 0F53537B590; Fri, 23 Jun 2000 04:33:55 -0700 (PDT) (envelope-from samj@itcj.kiev.ua) Received: from tools.itci.kiev.ua (tools.itci.kiev.ua [62.244.54.249]) by sivka.carrier.kiev.ua (8/Kilkenny_is_better) with ESMTP id ONA12168; Fri, 23 Jun 2000 14:33:52 +0300 (EEST) (envelope-from samj@itcj.kiev.ua) Received: from primsrv ([62.244.54.220]) by tools.itci.kiev.ua (8.9.3/8.9.3) with SMTP id OAA08477; Fri, 23 Jun 2000 14:33:11 +0300 (EEST) (envelope-from samj@itcj.kiev.ua) Message-ID: <004d01bfdd06$e6f40fc0$dc36f43e@primsrv.itci.kiev.ua> From: "Yuriy" To: Cc: Subject: Date: Fri, 23 Jun 2000 14:33:47 +0300 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have problems with mgetty+ppp+scripts+tty sometimes . My script uses 'tty' utility for definition of port. But suddenly on some moment 'tty' determines port as cuaa10 instead of cuaaa. 'wtmp' contains records with even after user on cuaaa was disconnected until host will be reboot. 'w' does not show cuaa10 too. 'ps -ax' shows cuaa10. It breaks all statistics for cuaaa. As it is possible to explain it? Thanks _______ Yuriy Samartsev, Firm ITC Ltd, http://www.itci.net. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 23 5:23:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 3B65A37C457 for ; Fri, 23 Jun 2000 05:23:40 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id NAA60120 for ; Fri, 23 Jun 2000 13:23:36 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id LAA00670; Fri, 23 Jun 2000 11:15:31 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006231015.LAA00670@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Brian Somers , net@FreeBSD.org Subject: Re: "frag-anyways" knob. In-Reply-To: Message from Ruslan Ermilov of "Fri, 23 Jun 2000 10:25:33 +0300." <20000623102533.A44764@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jun 2000 11:15:30 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [sorry if you get this twice - my laptop crashed horribly] > On Thu, Jun 22, 2000 at 08:25:01PM +0100, Brian Somers wrote: > > This looks good. > > > > In the PPPoE case, we need to be able to bring the program up and > > down based on any new MTU values negotiated by ppp(8). > > > > This could be done if tcpmssd had a ``create a pidfile'' option, > > where ppp.linkup could run ``tcpmssd -M IFMTU -P tcpmssd.INTERFACE.pid'' > > and ppp.linkdown could run ``kill `cat tcpmssd.INTERFACE.pid`''. > > > > Ppp would also need to expand IFMTU in command_Expand() in command.c. > > > > Does this make sense ? The only alternative I see is to implement > > this stuff in libalias and have tcpmssd use libalias. > > > Would it be enough if tcpmssd(8) could track interface MTU (kernel > is capable of notifying user processes about MTU changes through a > routing socket interface as of sys/net/if.c,v 1.83). > > usage: tcpmssd [-v] -p port [-i iface | -m mtu] > > So, if run as `tcpmssd -p 1234 -i tun0', it will peek the initial > MTU value on startup and then will monitor routing socket for MTU > changes. That sounds perfect - although I think the pidfile option would be nice too - for consistency. > 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 > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 23 7: 8:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 5161B37B9B5 for ; Fri, 23 Jun 2000 07:08:42 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id RAA64917; Fri, 23 Jun 2000 17:08:27 +0300 (EEST) Date: Fri, 23 Jun 2000 17:08:27 +0300 From: Ruslan Ermilov To: Brian Somers Cc: net@FreeBSD.org Subject: Re: "frag-anyways" knob. Message-ID: <20000623170827.A64269@sunbay.com> Mail-Followup-To: Brian Somers , net@FreeBSD.org References: <200006231015.LAA00670@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200006231015.LAA00670@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on Fri, Jun 23, 2000 at 11:15:30AM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jun 23, 2000 at 11:15:30AM +0100, Brian Somers wrote: > [sorry if you get this twice - my laptop crashed horribly] > > > On Thu, Jun 22, 2000 at 08:25:01PM +0100, Brian Somers wrote: > > > This looks good. > > > > > > In the PPPoE case, we need to be able to bring the program up and > > > down based on any new MTU values negotiated by ppp(8). > > > > > > This could be done if tcpmssd had a ``create a pidfile'' option, > > > where ppp.linkup could run ``tcpmssd -M IFMTU -P tcpmssd.INTERFACE.pid'' > > > and ppp.linkdown could run ``kill `cat tcpmssd.INTERFACE.pid`''. > > > > > > Ppp would also need to expand IFMTU in command_Expand() in command.c. > > > > > > Does this make sense ? The only alternative I see is to implement > > > this stuff in libalias and have tcpmssd use libalias. > > > > > Would it be enough if tcpmssd(8) could track interface MTU (kernel > > is capable of notifying user processes about MTU changes through a > > routing socket interface as of sys/net/if.c,v 1.83). > > > > usage: tcpmssd [-v] -p port [-i iface | -m mtu] > > > > So, if run as `tcpmssd -p 1234 -i tun0', it will peek the initial > > MTU value on startup and then will monitor routing socket for MTU > > changes. > > That sounds perfect - although I think the pidfile option would be > nice too - for consistency. > I have put an updated version here: http://people.FreeBSD.org/~ru/tcpmssd.tgz This version supports `-i iface' option as described above, and it also automatically creates /var/run/tcpmssd..pid file if run with -i. 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-net" in the body of the message From owner-freebsd-net Fri Jun 23 7:53:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 8DD2837C2BB for ; Fri, 23 Jun 2000 07:53:35 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id PAA61183 for ; Fri, 23 Jun 2000 15:53:31 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id PAA85894; Fri, 23 Jun 2000 15:53:24 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006231453.PAA85894@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Brian Somers , net@FreeBSD.org Subject: Re: "frag-anyways" knob. In-Reply-To: Message from Ruslan Ermilov of "Fri, 23 Jun 2000 17:08:27 +0300." <20000623170827.A64269@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jun 2000 15:53:24 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Fri, Jun 23, 2000 at 11:15:30AM +0100, Brian Somers wrote: > > [sorry if you get this twice - my laptop crashed horribly] > > > > > On Thu, Jun 22, 2000 at 08:25:01PM +0100, Brian Somers wrote: > > > > This looks good. > > > > > > > > In the PPPoE case, we need to be able to bring the program up and > > > > down based on any new MTU values negotiated by ppp(8). > > > > > > > > This could be done if tcpmssd had a ``create a pidfile'' option, > > > > where ppp.linkup could run ``tcpmssd -M IFMTU -P tcpmssd.INTERFACE.pid'' > > > > and ppp.linkdown could run ``kill `cat tcpmssd.INTERFACE.pid`''. > > > > > > > > Ppp would also need to expand IFMTU in command_Expand() in command.c. > > > > > > > > Does this make sense ? The only alternative I see is to implement > > > > this stuff in libalias and have tcpmssd use libalias. > > > > > > > Would it be enough if tcpmssd(8) could track interface MTU (kernel > > > is capable of notifying user processes about MTU changes through a > > > routing socket interface as of sys/net/if.c,v 1.83). > > > > > > usage: tcpmssd [-v] -p port [-i iface | -m mtu] > > > > > > So, if run as `tcpmssd -p 1234 -i tun0', it will peek the initial > > > MTU value on startup and then will monitor routing socket for MTU > > > changes. > > > > That sounds perfect - although I think the pidfile option would be > > nice too - for consistency. > > > I have put an updated version here: > > http://people.FreeBSD.org/~ru/tcpmssd.tgz > > This version supports `-i iface' option as described above, and it also > automatically creates /var/run/tcpmssd..pid file if run with -i. Nice one ! > 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 -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 23 14:17: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164]) by hub.freebsd.org (Postfix) with ESMTP id 7AA9C37B777 for ; Fri, 23 Jun 2000 14:17:00 -0700 (PDT) (envelope-from aljtarik@cholla.inrs-telecom.uquebec.ca) Received: from cholla.INRS-Telecom.UQuebec.CA (cholla [192.26.211.110]) by ozias.inrs-telecom.uquebec.ca (8.9.1/8.9.1) with ESMTP id LAA10525; Wed, 21 Jun 2000 11:34:46 -0400 (EDT) Received: from cholla by cholla.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4) id LAA08791; Wed, 21 Jun 2000 11:33:37 -0400 (EDT) Message-Id: <200006211533.LAA08791@cholla.INRS-Telecom.UQuebec.CA> Date: Wed, 21 Jun 2000 11:33:37 -0400 (EDT) From: Tarik Alj Reply-To: Tarik Alj Subject: Re: bridge + VLAN + netgraph To: csg@waterspout.com Cc: net@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6WKYXXoS+da2AzVKVX+Alw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think the VLAN device should really be thought of as a bridge and not as an encapsulator. After all VLAN's purpose is to make the bridging transparent to groups of users on different LANs, and reduce broadcast domains. So VLAN functionnality should really be implemented in bridge. >Date: Tue, 20 Jun 2000 23:33:46 -0500 >From: "C. Stephen Gunn" >To: Julian Elischer >Cc: Tarik Alj , archie@whistle.com, gregoire@cholla.inrs-telecom.uquebec.ca, "Vitaly V. Belekhov" , net@freebsd.org >Subject: Re: bridge + VLAN + netgraph >Mime-Version: 1.0 > >On Tue, Jun 20, 2000 at 10:36:17AM -0700, Julian Elischer wrote: > >> There is VLAN support in FreeBSD but it is independent to >> the Netgraph framework as it was developed independently by >> other people. I have not looked at it closely. > >The VLAN driver was mostly written by Garrett Wollman. > >> It would be nice if we could consolidate these things under >> the single framework. > >our 802.1q VLAN implementation is complicated by several issues: > > - 802.1q is a Layer-2 in Layer-2 encapsulation. Tagged frames > are encapsulated with an ethertype of 0x8100, followed by > a 16-bit field encoding VLAN and Priority. Since we have > our VLAN devices masquerade to the rest of the system as > regular ethernet interfaces (preserving the link header for > things like BPF). > > We can't simply prepend/strip headers from the beginning of > the mbuf like most netgraph modules. > > - Some hardware support tag insertion/extraction. I'm not sure > that hardware tag insertion is a win, since we still have to > store the tag somewhere for I/O to the card. We might as well > just store the tag in the packet. Proably quicker than coding > for the exceptional case of hardware support. > > - Since VLANs shove another 4-byte field in the Ethernet Frame, > we bump the MTU by 4 bytes. Some cards/drivers reject frames > larger than 1500 bytes as giants. This limits the interfaces > recommended for user with VLANs. As someone pointed out > in discussions with me, MTU is a TCP/IP concept, not an > intrinsic property of an interface. > >> The standard 'ethenet' node was recently re-written >> and will be checked in soon. >> >> check: >> ftp://ftp.whistle.com/pub/archie/misc/NGETHER.patch.2 > >I think that ether_input2() is a horrible name. I would advocate >naming ether_demux(). This accurately describes its function. > >It would take a pointer to an ifnet, a pointer to the link-header, >and a the mbuf chain. It should update packet counters, and then >appropriately dispatch the packet to upper protocol layers. > >We could then modify ether_input() to take the full mbuf, including >the headers (like NetBSD). Drivers that want/need to optimize >the selection of packets (NE2000 drivers?) could do their busywork >and pass the packet to ether_demux(). > > - Steve Tarik To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 23 14:17:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164]) by hub.freebsd.org (Postfix) with ESMTP id 7656837B69C for ; Fri, 23 Jun 2000 14:17:06 -0700 (PDT) (envelope-from aljtarik@cholla.inrs-telecom.uquebec.ca) Received: from cholla.INRS-Telecom.UQuebec.CA (cholla [192.26.211.110]) by ozias.inrs-telecom.uquebec.ca (8.9.1/8.9.1) with ESMTP id QAA04031; Tue, 20 Jun 2000 16:56:11 -0400 (EDT) Received: from cholla by cholla.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4) id QAA08381; Tue, 20 Jun 2000 16:55:05 -0400 (EDT) Message-Id: <200006202055.QAA08381@cholla.INRS-Telecom.UQuebec.CA> Date: Tue, 20 Jun 2000 16:55:05 -0400 (EDT) From: Tarik Alj Reply-To: Tarik Alj Subject: Re: bridge + VLAN + netgraph To: luigi@info.iet.unipi.it Cc: archie@whistle.com, gregoire@cholla.inrs-telecom.uquebec.ca, vitaly@riss-telecom.ru, net@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-MD5: h/YRA0MRRGecmYHktrDE6A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am replying to both your mails here, hope you don't mind. from: Luigi Rizzo Subject: Re: bridge + VLAN + netgraph To: Julian Elischer Date: Tue, 20 Jun 2000 21:24:12 +0200 (CEST) CC: Tarik Alj , archie@whistle.com= ,=20 gregoire@cholla.inrs-telecom.uquebec.ca, "Vitaly V. Belekhov"=20 , net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit > Tarik Alj wrote: > >=20 > > Hi, > >=20 > > we are interested in develloping a netgraph=20 > > bridge node following the > > 802.1Q standard; that is a bridge with VLAN support=20 If i can comment: i dod a VLAN bridge (between cards on the same VLAN and supporting TRUNK interfaces) back in 2.2.x times, and was looking at porting this to 3.x/4.x just this morning. The way i did it was within /sys/net/bridge.c and without the VLAN supoprt in RELENG_3 and above. The implementation within bridge.c is relatively straightforward (and tightly related to the idea of clusters of interfaces which is already in the source tree). The only problem is perhaps performance because the VLAN header insertion/deletion is done manually rather than resorting to the hardware support that some cards might have. On the other hand, i am not sure either if if_vlan.c does support it. can I have the source for that? it would be at the very least hintful. I am not sure how easy would it be to make bridging see directly the "vlanX" interface because i think you cannot define a trunk interface, and also there is the problem that vlan_input() calls ether_input again so there is the need for some care in avoiding that the packet is forwarded twice. Yes, the way if_vlan.c works is really *not* the proper way to do it I beli= eve,=20 if you want to handle more than one VLAN it should be done at the bridge le= vel; otherwise you should let the nic handle it, as i think some card are capabl= e of tagging (not sure thought). this is why we would like to see it implemented as a bridge; netgraph seeme= d to=20 be a clean approach as it provides for some sort of API. Plus, i am not really sure how vlan works with Archie's commits to simplify device drivers. =09cheers =09luigi -----------------------------------+------------------------------------- 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 -----------------------------------+------------------------------------- >From: Luigi Rizzo >Subject: Re: bridge + VLAN + netgraph >To: aljtarik@cholla.inrs-telecom.uquebec.ca >Date: Tue, 20 Jun 2000 21:37:59 +0200 (CEST) >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit > >As a followup: > >> > Hi, >> >=20 >> > we are interested in develloping a netgraph=20 >> > bridge node following the >> > 802.1Q standard; that is a bridge with VLAN support=20 > >Forgot one detail: doing the vlan stuff in bridge.c >you can surely make use of the features of ipfw/dummynet. >I understand that you have probably the resources to make this work >by yourself, and that you might be a university, so am asking just >in case-- would you be interested in giving me a small support to >adapt and commit my code in 3.x and above ? (For commits to RELENG_3 >i have to check with Jordan about policy, but if nothing else you >can make use of diffs vs. RELENG_3_5_0_RELEASE). sure. I still have to read about dummynet. We are interested in using dummy= net=20 anyways. And yes, we are a university (http://www.inrs-telecom.uquebec.ca);= the=20 supervisor for the project is Jean-Charles Gr=E9goire=20 (gregoire@inrs-telecom.uquebec.ca). >If not, given that i have some medium-term plans to make this >work anyways before fall, could i suggest that you have a look >at two issues which are missing in the bridging code, namely >spanning tree support (this can be done in userland i believe, >and just implement some {s|g}etsockopt to enable/disable bridging >on some interfaces) and IGMP snooping (forget if this was one >of thie things you had listed in your msg). ok, let me tell you what we would like to have the bridge do : - handle MAC address based VLANs=20 - handle Trunking - have some sort of 802.1p (priority field in 802.1Q header) capabilities (= such=20 as mapping from DSCP to 802.1p for example) - participate in Spanning Tree Protocol - participate in GARP apps (GVRP, possibly GMRP) the aim is to turn the BSD box in a full 802.1Q switch... don't know about IGMP thought. > >For the 3.x branch things are simpler as i know the code very well; >for the 4.x/5.x i need to have a closer look at archie's patches >which are, as far as i can tell, not tested (at least i did not >see a single email confirming that bridging+ipfw still works under >4.x). > >=09cheers >=09luigi > >-----------------------------------+------------------------------------- > 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 >-----------------------------------+------------------------------------- Cheers, Tarik. Tarik Alj INRS-Telecommunications Place Bonaventure 900 De La Gauchetierre Ouest Niveau C, Case Postale 644 Montreal, Qc, H5A 1C6 Canada 514 875-1266 #2036 (email preferred) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 23 15:30: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 18AAC37B649 for ; Fri, 23 Jun 2000 15:29:56 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id PAA03836 for freebsd-net@freebsd.org; Fri, 23 Jun 2000 15:29:51 -0700 (PDT) From: Archie Cobbs Message-Id: <200006232229.PAA03836@bubba.whistle.com> Subject: ng_ether patch To: freebsd-net@freebsd.org Date: Fri, 23 Jun 2000 15:29:51 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Final request for review.. ftp://ftp.whistle.com/pub/archie/misc/NGETHER.patch.5 Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message