From owner-freebsd-net Sun Nov 18 10:15: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id AE18037B418 for ; Sun, 18 Nov 2001 10:15:05 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id KAA99273; Sun, 18 Nov 2001 10:11:43 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fAIIBhn04563; Sun, 18 Nov 2001 10:11:43 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111181811.fAIIBhn04563@arch20m.dellroad.org> Subject: Re: t_dupacks to u_int? In-Reply-To: <20011117192306.A97092@prism.flugsvamp.com> "from Jonathan Lemon at Nov 17, 2001 07:23:06 pm" To: Jonathan Lemon Date: Sun, 18 Nov 2001 10:11:43 -0800 (PST) Cc: Alfred Perlstein , net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jonathan Lemon writes: > On the surface, I don't see a problem with it, but I wonder why you > believe it is needed. Changing the value of rexmttresh is probably > not a good idea, and I would definitely prefer not to expose it as a > user tunable knob. > > On Sat, Nov 17, 2001 at 06:51:02PM -0600, Alfred Perlstein wrote: > > Any problems with this? > > > > -static int tcprexmtthresh = 3; > > +static unsigned int tcprexmtthresh = 3; > > +SYSCTL_UINT(_net_inet_tcp, OID_AUTO, rexmtthresh, CTLFLAG_RW, > > + &tcprexmtthresh, 0, "Max duplicate acks before fast rexmit"); > > + How about a kernel option TCP_TWEAKS or something that would expose these 'dangerous' sysctl's for people to play with. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 18 10:15:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 4A17B37B417; Sun, 18 Nov 2001 10:15:26 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id KAA99264; Sun, 18 Nov 2001 10:09:48 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fAII9lp04548; Sun, 18 Nov 2001 10:09:47 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111181809.fAII9lp04548@arch20m.dellroad.org> Subject: Re: re-entrancy and the IP stack. In-Reply-To: "from Julian Elischer at Nov 16, 2001 05:23:21 pm" To: Julian Elischer Date: Sun, 18 Nov 2001 10:09:46 -0800 (PST) Cc: Luigi Rizzo , Peter Wemm , Julian Elischer , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer writes: > > i actually suggested one i.e. have explicit pointers > > to metadata area(s) in the pkthdr. I think you forget the > > most fundamental feature which is performance. > > This is way more important than flexibility i think. > > Which is the reason that this problem exists.. > no-one ever thinks that people will want to do things different > to what they want to do at the time they write it.. > > Flexibility is I think much more important than you suggest. > Wouldn't it have made it easier for you if there had been a flexible > method to pass such information available? > The m_aux field sounds right to me. IMHO m_aux is fine for this. It already includes built-in support for 'blind' free'ing -- when you free an mbuf any aux data automatically gets free'd with it, whether you put it there or not. I've been using this for work-related stuff and it works great. As for performance, if there's only one or two m_aux structures associated with an mbuf, then the linear search of the m_aux list is not a big deal. If we start getting tons of m_aux's piling up, *then* we can start worrying about optimization (and there are plenty of options there). -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 18 11:59:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from ardbeg.meer.net (ardbeg.meer.net [209.157.152.23]) by hub.freebsd.org (Postfix) with ESMTP id 310B037B41C for ; Sun, 18 Nov 2001 11:59:13 -0800 (PST) Received: from meer.meer.net (mail.meer.net [209.157.152.14]) by ardbeg.meer.net (8.11.3/8.11.3) with ESMTP id fAIJxDc06211; Sun, 18 Nov 2001 11:59:13 -0800 (PST) Received: from neville-neil.com ([209.157.133.226]) by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id LAA570698; Sun, 18 Nov 2001 11:58:09 -0800 (PST) Message-Id: <200111181958.LAA570698@meer.meer.net> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Garrett Wollman Cc: net@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: Message from Garrett Wollman of "Sat, 17 Nov 2001 20:38:48 EST." <200111180138.fAI1cms60316@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Nov 2001 11:58:09 -0800 From: "George V. Neville-Neil" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I won't be at LISA but would be interested in hearing what y'all come up with. BSDCon is in my home town so it's a doddle to make it there for me. Later, George To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 18 12:40:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 9EB4837B405 for ; Sun, 18 Nov 2001 12:40:15 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA24040; Sun, 18 Nov 2001 12:32:33 -0800 (PST) Date: Sun, 18 Nov 2001 12:32:32 -0800 (PST) From: Julian Elischer To: "George V. Neville-Neil" Cc: Garrett Wollman , net@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: <200111181958.LAA570698@meer.meer.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org err, where is BSDcon this year? On Sun, 18 Nov 2001, George V. Neville-Neil wrote: > I won't be at LISA but would be interested in hearing what y'all come up with. > > BSDCon is in my home town so it's a doddle to make it there for me. > > Later, > George > > > > 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 Sun Nov 18 12:47: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from ardbeg.meer.net (ardbeg.meer.net [209.157.152.23]) by hub.freebsd.org (Postfix) with ESMTP id 4FC6937B416 for ; Sun, 18 Nov 2001 12:47:07 -0800 (PST) Received: from meer.meer.net (mail.meer.net [209.157.152.14]) by ardbeg.meer.net (8.11.3/8.11.3) with ESMTP id fAIKl7c15294; Sun, 18 Nov 2001 12:47:07 -0800 (PST) Received: from neville-neil.com ([209.157.133.226]) by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id MAA567144; Sun, 18 Nov 2001 12:46:24 -0800 (PST) Message-Id: <200111182046.MAA567144@meer.meer.net> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Julian Elischer Cc: Garrett Wollman , net@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: Message from Julian Elischer of "Sun, 18 Nov 2001 12:32:32 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Nov 2001 12:46:23 -0800 From: "George V. Neville-Neil" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > err, where is BSDcon this year? Here ya go: Hotel Information Cathedral Hill Hotel 1101 Van Ness Avenue San Francisco, California 94109 Toll Free: 1 800 622 0855 Local Telephone: 1 415 776 8200 Reservation Fax: 1 415 441 2841 Email: reservations@cathedralhillhotel.com Later, George To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 18 15:16:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from usenix.org (voyager.usenix.org [131.106.3.1]) by hub.freebsd.org (Postfix) with ESMTP id B18D837B417 for ; Sun, 18 Nov 2001 15:16:06 -0800 (PST) Received: from melange (melange.errno.com [66.124.149.178]) (authenticated (0 bits)) by usenix.org (Switch-2.1.3/Switch-2.1.0) with ESMTP id fAING5P05822 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Sun, 18 Nov 2001 15:16:12 -0800 (PST) Message-ID: <063a01c17086$fd24a3d0$a665a8c0@errno.com> From: "Sam Leffler (at Usenix)" To: "Julian Elischer" , "George V. Neville-Neil" Cc: "Garrett Wollman" , References: <200111182046.MAA567144@meer.meer.net> Subject: Re: re-entrancy and the IP stack. Date: Sun, 18 Nov 2001 15:15:54 -0800 Organization: Usenix Association 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.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Guiess we missed you with our spam :-) http://www.usenix.org/events/bsdcon02/ ----- Original Message ----- From: "George V. Neville-Neil" To: "Julian Elischer" Cc: "Garrett Wollman" ; Sent: Sunday, November 18, 2001 12:46 PM Subject: Re: re-entrancy and the IP stack. > > err, where is BSDcon this year? > > Here ya go: > > Hotel Information > Cathedral Hill Hotel > 1101 Van Ness Avenue > San Francisco, California 94109 > Toll Free: 1 800 622 0855 > Local Telephone: 1 415 776 8200 > Reservation Fax: 1 415 441 2841 > Email: reservations@cathedralhillhotel.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 19 0:49:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns.moldnet.md (moldnet.md [195.138.124.18]) by hub.freebsd.org (Postfix) with ESMTP id CF46237B416 for ; Mon, 19 Nov 2001 00:49:17 -0800 (PST) Received: from localhost (vg@localhost) by ns.moldnet.md (8.11.3/8.11.3) with ESMTP id fAJ8nBu70318 for ; Mon, 19 Nov 2001 10:49:13 +0200 (EET) (envelope-from vg@ns.moldnet.md) Date: Mon, 19 Nov 2001 10:49:11 +0200 (EET) From: Vladimir Girnetz To: Subject: ipfw + pipes Message-ID: <20011119104807.D70300-100000@ns.moldnet.md> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi How many pipes can be created under FreeBSD 4.4? How the number of pipes will be reflected on usage of CPU and RAM? Thanks, Vladimir Girnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 19 1: 2:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 543DA37B405 for ; Mon, 19 Nov 2001 01:02:21 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fAJ8w6B09815; Mon, 19 Nov 2001 00:58:06 -0800 (PST) (envelope-from rizzo) Date: Mon, 19 Nov 2001 00:58:06 -0800 From: Luigi Rizzo To: Vladimir Girnetz Cc: net@FreeBSD.ORG Subject: Re: ipfw + pipes Message-ID: <20011119005806.A9378@iguana.aciri.org> References: <20011119104807.D70300-100000@ns.moldnet.md> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011119104807.D70300-100000@ns.moldnet.md> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Nov 19, 2001 at 10:49:11AM +0200, Vladimir Girnetz wrote: > Hi > > How many pipes can be created under FreeBSD 4.4? as many as 64k independent pipes, each of which can have a large number (default 1k, but can be soft-configurable) of dynamic pipes. So essentially it is limited by the available RAM. > How the number of pipes will be reflected on usage of CPU and RAM? space is linear in the total number of pipes, per packet processing time is in the worst case logarithmic in the number of active pipes (i.e. those with backlogged traffic). But basically, for most practical applications the performance hit will go unnoticed, and even with the most complex configurations I wouldn't expect a slowdown of more than a factor of 2. [and i hear screams in the background from people who think "oh no, for my application more than 1% overhead is unacceptable" to whom i suggest to run "top" in a window, quickly move the mouse around, and enjoy the "interrupt" stats going up...] cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 19 1:45:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from garfield.bmk.com.au (bmkind.lnk.telstra.net [139.130.51.118]) by hub.freebsd.org (Postfix) with ESMTP id E8E3A37B41A for ; Mon, 19 Nov 2001 01:45:14 -0800 (PST) Received: from localhost (brendan@localhost) by garfield.bmk.com.au (8.9.3/8.9.3) with SMTP id UAA39573 for ; Mon, 19 Nov 2001 20:45:12 +1100 (EST) (envelope-from brendan@bmk.com.au) Date: Mon, 19 Nov 2001 20:45:11 +1100 (EST) From: Brendan Kosowski Reply-To: Brendan Kosowski To: FreeBSD Networking Subject: Services very slow on Firewall/nat boxes. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I am running natd on a FreeBSD box with IPFIREWALL and IPDIVERT added to the kernel. Firewall type is open. I have noticed that when you run a server (eg. sendmail, named, pop3 etc.) on the above, initial connection to the service is very slow (ie. between 5 and 60 seconds ), however once connection has been established data transfer becomes very fast (as per normal). If I disable natd and replace kernel with original, initial connection to services is very fast. This box is on a network with very little traffic. I would greatly appreciate any help on speeding up initial connection to services. Regards, Brendan Kosowski ------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 19 2:20:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 076A737B41A for ; Mon, 19 Nov 2001 02:20:22 -0800 (PST) Received: from dialup-209.245.132.171.dial1.sanjose1.level3.net ([209.245.132.171] helo=blossom.cjclark.org) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 165lXA-00052h-00; Mon, 19 Nov 2001 02:20:20 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fAJAIA984447; Mon, 19 Nov 2001 02:18:10 -0800 (PST) (envelope-from cjc) Date: Mon, 19 Nov 2001 02:18:02 -0800 From: "Crist J. Clark" To: Brendan Kosowski Cc: FreeBSD Networking Subject: Re: Services very slow on Firewall/nat boxes. Message-ID: <20011119021802.N69555@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from brendan@bmk.com.au on Mon, Nov 19, 2001 at 08:45:11PM +1100 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Nov 19, 2001 at 08:45:11PM +1100, Brendan Kosowski wrote: > > I am running natd on a FreeBSD box with IPFIREWALL and IPDIVERT added to > the kernel. Firewall type is open. > > I have noticed that when you run a server (eg. sendmail, named, pop3 etc.) > on the above, initial connection to the service is very slow (ie. between > 5 and 60 seconds ), however once connection has been established data > transfer becomes very fast (as per normal). > > If I disable natd and replace kernel with original, initial connection to > services is very fast. DNS. Your machine is timing out making DNS queries. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 19 3:52:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from garfield.bmk.com.au (bmkind.lnk.telstra.net [139.130.51.118]) by hub.freebsd.org (Postfix) with ESMTP id 69E9F37B41F for ; Mon, 19 Nov 2001 03:51:59 -0800 (PST) Received: from localhost (brendan@localhost) by garfield.bmk.com.au (8.9.3/8.9.3) with SMTP id WAA39840; Mon, 19 Nov 2001 22:51:46 +1100 (EST) (envelope-from brendan@bmk.com.au) Date: Mon, 19 Nov 2001 22:51:46 +1100 (EST) From: Brendan Kosowski Reply-To: Brendan Kosowski To: cjclark@alum.mit.edu Cc: FreeBSD Networking Subject: Re: Services very slow on Firewall/nat boxes. In-Reply-To: <20011119021802.N69555@blossom.cjclark.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have now fixed the problem by getting rid of the UGLY DENY rule that is present in the "open" firewall ruleset, ie "deny all from any to 127.0.0.0/8". All services are now lightning fast on my firewall/nat. Best regards to all. -------------------- On Mon, 19 Nov 2001, Crist J. Clark wrote: > On Mon, Nov 19, 2001 at 08:45:11PM +1100, Brendan Kosowski wrote: > > > > I am running natd on a FreeBSD box with IPFIREWALL and IPDIVERT added to > > the kernel. Firewall type is open. > > > > I have noticed that when you run a server (eg. sendmail, named, pop3 etc.) > > on the above, initial connection to the service is very slow (ie. between > > 5 and 60 seconds ), however once connection has been established data > > transfer becomes very fast (as per normal). > > > > If I disable natd and replace kernel with original, initial connection to > > services is very fast. > > DNS. Your machine is timing out making DNS queries. > -- > Crist J. Clark | cjclark@alum.mit.edu > | cjclark@jhu.edu > http://people.freebsd.org/~cjc/ | cjc@freebsd.org > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 19 4: 2:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id BB87237B416 for ; Mon, 19 Nov 2001 04:02:11 -0800 (PST) Received: from dialup-209.245.132.171.dial1.sanjose1.level3.net ([209.245.132.171] helo=blossom.cjclark.org) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 165n7F-000510-00; Mon, 19 Nov 2001 04:02:01 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fAJBxxE85349; Mon, 19 Nov 2001 03:59:59 -0800 (PST) (envelope-from cjc) Date: Mon, 19 Nov 2001 03:59:54 -0800 From: "Crist J. Clark" To: Brendan Kosowski Cc: FreeBSD Networking Subject: Re: Services very slow on Firewall/nat boxes. Message-ID: <20011119035954.P69555@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20011119021802.N69555@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from brendan@bmk.com.au on Mon, Nov 19, 2001 at 10:51:46PM +1100 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Nov 19, 2001 at 10:51:46PM +1100, Brendan Kosowski wrote: > > I have now fixed the problem by getting rid of the UGLY DENY rule that is > present in the "open" firewall ruleset, ie "deny all from any to > 127.0.0.0/8". You should not have to remove that if the, 100 pass all from any to any via lo0 Rule is present unless something is broken. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 19 11:20:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 2EE9A37B405 for ; Mon, 19 Nov 2001 11:20:21 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA28618; Mon, 19 Nov 2001 11:10:31 -0800 (PST) Date: Mon, 19 Nov 2001 11:10:30 -0800 (PST) From: Julian Elischer To: Brendan Kosowski Cc: FreeBSD Networking Subject: Re: Services very slow on Firewall/nat boxes. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org If you have IPdivert, does this mean that you have natd running? If so, then probably the initiation of a new session is paging in pages of the natd that were paged out. (and allocating new data structures. On Mon, 19 Nov 2001, Brendan Kosowski wrote: > > I am running natd on a FreeBSD box with IPFIREWALL and IPDIVERT added to > the kernel. Firewall type is open. > > I have noticed that when you run a server (eg. sendmail, named, pop3 etc.) > on the above, initial connection to the service is very slow (ie. between > 5 and 60 seconds ), however once connection has been established data > transfer becomes very fast (as per normal). > > If I disable natd and replace kernel with original, initial connection to > services is very fast. > > This box is on a network with very little traffic. > > I would greatly appreciate any help on speeding up initial connection to > services. > > > Regards, Brendan Kosowski > > ------------------------- > > > > 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 Mon Nov 19 16:25:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f166.pav2.hotmail.com [64.4.37.166]) by hub.freebsd.org (Postfix) with ESMTP id 1F28037B419 for ; Mon, 19 Nov 2001 16:25:11 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 19 Nov 2001 16:25:11 -0800 Received: from 204.178.20.14 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 20 Nov 2001 00:25:10 GMT X-Originating-IP: [204.178.20.14] From: "murthy kn" To: net@freebsd.org Subject: ipsend packet generator Date: Tue, 20 Nov 2001 05:55:10 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Nov 2001 00:25:11.0088 (UTC) FILETIME=[D0B8BB00:01C17159] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, When I use the "ipsend" executable/tool available from the distribution and am generating a UDP packet, I am able to see the exact packet at the destination. However, when I try to compile the utility, (downloaded from Net) it is compiling without problem, but when I send a UDP packet, at the destination it is being seen as some arbitrary packet - whatever length I write at the sender, receiver is seeing only a length of 22 bytes of some unknown protocol. My feeling is there may be problem with some flag related to the "IP header" definition while compiling (_IP_VHL or some similar stuff) - has anybody encountered this problem or I am missing something? Thanks for your time, Murthy _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 19 21:26:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from web11602.mail.yahoo.com (web11602.mail.yahoo.com [216.136.172.54]) by hub.freebsd.org (Postfix) with SMTP id 138B237B418 for ; Mon, 19 Nov 2001 21:26:16 -0800 (PST) Message-ID: <20011120052615.36411.qmail@web11602.mail.yahoo.com> Received: from [202.94.0.21] by web11602.mail.yahoo.com via HTTP; Mon, 19 Nov 2001 21:26:15 PST Date: Mon, 19 Nov 2001 21:26:15 -0800 (PST) From: tang hongbin Subject: How can I add new ESP encryption functions into FreeBSD kernel To: net@freebsd.org In-Reply-To: <20011119205058.C89738@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dear Sir/Madam; A problem is troubling me in ages. I want to add my encryption algorithm of ESP, an algorithm like DES, into FreeBSD kernel so as to make kernel recognize it. I added its definitions in /usr/src/sys/net/pfkeyv2.h, added specific functions implementation into /usr/src/sys/netinet6/esp.core.c and added a new subdirectory in sys/crypto. Afterwards I rebuild kernel, but system can't recognize my ESP encryption algorithm when I use PF socket or setkey command to add a new SA into SAD including my new encryption. In a word, please tell me what I should do step by step if I want to add a new ESP encryption algorithm that I have already implemented into kernel so that I can use setkey commmand or sock system call to add SAs into SAD and the kernel can use fucntions I provided to encrypt or decrypt incoming or outgoing IP packages. Any your assistance would be greatly appreciated. Sincerelly yours, Tang hongbin __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 19 23:22:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.143.238.93]) by hub.freebsd.org (Postfix) with SMTP id 58F1737B416 for ; Mon, 19 Nov 2001 23:22:27 -0800 (PST) Received: (qmail 1584 invoked by uid 1001); 20 Nov 2001 17:22:40 +1000 X-Posted-By: GJB-Post 2.22 07-Nov-2001 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Message-Id: Date: Tue, 20 Nov 2001 17:22:40 +1000 From: Greg Black To: net@freebsd.org Subject: ppp(8) crashes 4.2-R when using netgraph(4) module Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I rebuilt my 4.2-RELEASE kernel that has been in use for ages with the following extra lines in the config: options NETGRAPH #netgraph(4) system options NETGRAPH_PPPOE My earlier attempt to run ppp(8) on my new ADSL modem failed because netgraph was not in the kernel. After building a clean new kernel and installing it with the new modules, I tried ppp again and got a panic after a few seconds. I've tried it about six times. Most attempts got a panic (and I have typed up the console screen from one of them below), but some just skipped the panic and rebooted. On some attempts, we got a little bit of logging from the ppp process. Here's one such log: ------------------------------------------------------------------------ Nov 20 15:11:02 Using interface: tun0 Nov 20 15:11:02 deflink: Created in closed state Nov 20 15:11:02 Command: default: set filter alive 0 deny icmp Nov 20 15:11:02 Command: default: set filter alive 1 deny udp src eq 53 Nov 20 15:11:02 Command: default: set filter alive 2 deny udp dst eq 53 Nov 20 15:11:02 Command: default: set filter alive 3 permit 0 0 Nov 20 15:11:02 Command: bne-pi-adsl: set device PPPoE:xl0 Nov 20 15:11:02 Command: bne-pi-adsl: set authname ******** Nov 20 15:11:02 Command: bne-pi-adsl: set authkey ******** Nov 20 15:11:02 Command: bne-pi-adsl: set ifaddr 203.143.238.93 0.0.0.0/0 Nov 20 15:11:02 Command: bne-pi-adsl: add default HISADDR Nov 20 15:11:02 Command: bne-pi-adsl: set timeout 0 Nov 20 15:11:02 Phase: PPP Started (foreground mode). Nov 20 15:11:02 Phase: bundle: Establish Nov 20 15:11:02 Phase: deflink: closed -> opening ------------------------------------------------------------------------ Each line also had the following data after the date: bambi ppp[95014]: tun0: Here's the console screen on one panic: ------------------------------------------------------------------------ module_register: module netgraph already exists! linker_file_sysinit "netgraph.ko" failed to register! 17 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01c9e3f stack pointer = 0x10:0xd24c2c98 frame pointer = 0x10:0xd24c2ca8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 77817 (ppp) interrupt mask = net trap number = 12 panic: page fault syncing disks... 113 7 2 done Uptime: 5m2s Automatic reboot in 15 seconds - press a key [rest elided] ------------------------------------------------------------------------ If anybody can point me in the right direction to solve this, I'll be very grateful. My sole goal is to get ppp to talk to my ADSL modem, so if there's some other magic I should try, I'm happy to do that. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 20 6:24:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts12-srv.bellnexxia.net (tomts12.bellnexxia.net [209.226.175.56]) by hub.freebsd.org (Postfix) with ESMTP id 2E86837B416 for ; Tue, 20 Nov 2001 06:24:49 -0800 (PST) Received: from xena.gsicomp.on.ca ([199.243.144.157]) by tomts12-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20011120142448.KIKX3045.tomts12-srv.bellnexxia.net@xena.gsicomp.on.ca>; Tue, 20 Nov 2001 09:24:48 -0500 Received: from localhost (matt@localhost) by xena.gsicomp.on.ca (8.11.1/8.11.1) with ESMTP id fAKEGZ633449; Tue, 20 Nov 2001 09:16:35 -0500 (EST) (envelope-from matt@xena.gsicomp.on.ca) Date: Tue, 20 Nov 2001 09:16:35 -0500 (EST) From: Matthew Emmerton To: Greg Black Cc: net@FreeBSD.ORG Subject: Re: ppp(8) crashes 4.2-R when using netgraph(4) module In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dynamic loading of negraph modules is still broken, and probably won't be fixed until 5.0 (at least that's what the comments on the zillion PRs about this problem say.) Add 'options NETGRAPH_ETHER' and 'options NEGRAPH_SOCKET' to your kernel config file and rebuild your kernel. -- Matthew Emmerton || matt@gsicomp.on.ca GSI Computer Services || http://www.gsicomp.on.ca On Tue, 20 Nov 2001, Greg Black wrote: > I rebuilt my 4.2-RELEASE kernel that has been in use for ages > with the following extra lines in the config: > > options NETGRAPH #netgraph(4) system > options NETGRAPH_PPPOE > > My earlier attempt to run ppp(8) on my new ADSL modem failed > because netgraph was not in the kernel. > > After building a clean new kernel and installing it with the new > modules, I tried ppp again and got a panic after a few seconds. > I've tried it about six times. Most attempts got a panic (and I > have typed up the console screen from one of them below), but > some just skipped the panic and rebooted. > > On some attempts, we got a little bit of logging from the ppp > process. Here's one such log: > > ------------------------------------------------------------------------ > Nov 20 15:11:02 Using interface: tun0 > Nov 20 15:11:02 deflink: Created in closed state > Nov 20 15:11:02 Command: default: set filter alive 0 deny icmp > Nov 20 15:11:02 Command: default: set filter alive 1 deny udp src eq 53 > Nov 20 15:11:02 Command: default: set filter alive 2 deny udp dst eq 53 > Nov 20 15:11:02 Command: default: set filter alive 3 permit 0 0 > Nov 20 15:11:02 Command: bne-pi-adsl: set device PPPoE:xl0 > Nov 20 15:11:02 Command: bne-pi-adsl: set authname ******** > Nov 20 15:11:02 Command: bne-pi-adsl: set authkey ******** > Nov 20 15:11:02 Command: bne-pi-adsl: set ifaddr 203.143.238.93 0.0.0.0/0 > Nov 20 15:11:02 Command: bne-pi-adsl: add default HISADDR > Nov 20 15:11:02 Command: bne-pi-adsl: set timeout 0 > Nov 20 15:11:02 Phase: PPP Started (foreground mode). > Nov 20 15:11:02 Phase: bundle: Establish > Nov 20 15:11:02 Phase: deflink: closed -> opening > ------------------------------------------------------------------------ > > Each line also had the following data after the date: > bambi ppp[95014]: tun0: > > Here's the console screen on one panic: > > ------------------------------------------------------------------------ > module_register: module netgraph already exists! > linker_file_sysinit "netgraph.ko" failed to register! 17 > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x4 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc01c9e3f > stack pointer = 0x10:0xd24c2c98 > frame pointer = 0x10:0xd24c2ca8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 77817 (ppp) > interrupt mask = net > trap number = 12 > panic: page fault > > syncing disks... 113 7 2 > done > Uptime: 5m2s > Automatic reboot in 15 seconds - press a key [rest elided] > ------------------------------------------------------------------------ > > If anybody can point me in the right direction to solve this, > I'll be very grateful. My sole goal is to get ppp to talk to my > ADSL modem, so if there's some other magic I should try, I'm > happy to do that. > > 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 Tue Nov 20 9:58:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by hub.freebsd.org (Postfix) with ESMTP id 2E72C37B418 for ; Tue, 20 Nov 2001 09:58:52 -0800 (PST) Received: from xena.gsicomp.on.ca ([199.243.144.157]) by tomts13-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20011120175848.BCXR21717.tomts13-srv.bellnexxia.net@xena.gsicomp.on.ca>; Tue, 20 Nov 2001 12:58:48 -0500 Received: from localhost (matt@localhost) by xena.gsicomp.on.ca (8.11.1/8.11.1) with ESMTP id fAKHoQq33935; Tue, 20 Nov 2001 12:50:32 -0500 (EST) (envelope-from matt@xena.gsicomp.on.ca) Date: Tue, 20 Nov 2001 12:50:26 -0500 (EST) From: Matthew Emmerton To: brian@awfulhak.org, freebsd-net@freebsd.org Subject: Strange problem with PPP/Netgraph (PPPoE) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've got a bunch of FreeBSD 4.4 boxes doing PPPoE using netgraph and PPP. They've been doing this quite happily for a few months, but now one of the boxes is sick. [ Disclaimer: I'm 150 miles away from the box, so I don't have exact log messages. What you see below is my simple paraphrasing. ] What is happening is that when ppp starts on bootup (ppp -quiet -ddial pppoe), the last entry is "dial -> carrier" and nothing else. Normally we get a "PPPOE hook suceeded (tun0)" message after that and it goes into the LCP/IPCP phase. I'd like to point the finger at the ISP (since they've had fun dropping connections in the past and they swapped out the modem without telling us -- long story, don't ask), but need to know how to interpret this message. Are we not getting any further because a) ppp can't talk to NETGRAPH, b) NETGRAPH can't talk PPPoE to the DSL modem (bad NIC) or c) DSL modem isn't passing along our data to the ISP (bad ISP.) -- Matthew Emmerton || matt@gsicomp.on.ca GSI Computer Services || http://www.gsicomp.on.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 20 10:22:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f8.law3.hotmail.com [209.185.241.8]) by hub.freebsd.org (Postfix) with ESMTP id 2579537B405; Tue, 20 Nov 2001 10:21:55 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Nov 2001 10:21:55 -0800 Received: from 213.225.121.41 by lw3fd.law3.hotmail.msn.com with HTTP; Tue, 20 Nov 2001 18:21:54 GMT X-Originating-IP: [213.225.121.41] From: "Thor Legvold" To: freebsd-net@freebsd.org Cc: freebsd-questions@freebsd.org Subject: vpn with mpd-netgraph, 4.4-STABLE Date: Tue, 20 Nov 2001 18:21:54 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Nov 2001 18:21:55.0099 (UTC) FILETIME=[3BB67EB0:01C171F0] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm trying to get mpd-netgraph to work so that I can log in to my ISP that uses PPTP VPN software. I'e read the docs, writen a config file, but it doesn't seem to be able to connect (or I think it connects, but doesn't negotiate/authenticate). Stranger still is that when running mpd from the command line and loading a bundle I get error messages like: set pptp mode: unknown command. Try "help". [myisp_bundle] using interface ng0 mpd: option "mppc" unknown [myisp_bundle:myisp_link] set pptp mode active is in the docs, as is option mppc! I imagine my config files are incorrect, but never using pptp/netgraph/mpd before and not understanding the underlying paradigm, I have no idea where I should start looking. I'm not even sure I'm using the right software for what I want to do, although several deja searches and posts both here and to questions resulted in no answers. I'm running 4.4-STABLE, have a dual home host with ipfw and natd running. My home LAN is on 192.168.128.0 and my ISP is on 10.10.2.0, their VPN server on 10.10.1.1. I get an IP via DHCP from them (10.10.2.0 range), conenct to VPN server to get a routable IP from a pool of dynamically adressable addresses, then I should be online. However I haven't gotten it to work. LAN/inside is on dc0, outside is on wi0 (Lucent). Here's a transcript of the connection attempt: [myisp_bundle:myisp_link] open [myisp_bundle] IFACE: Open event [myisp_bundle] IPCP: Open event [myisp_bundle] IPCP: state change Initial --> Starting [myisp_bundle] IPCP: LayerStart [myisp_bundle:myisp_link] [myisp_bundle] bundle: OPEN event in state CLOSED [myisp_bundle] opening link "myisp_link"... [myisp_link] link: OPEN event [myisp_link] LCP: Open event [myisp_link] LCP: state change Initial --> Starting [myisp_link] LCP: LayerStart [myisp_link] device: OPEN event in state DOWN pptp0: connecting to 10.10.1.1:1723 [myisp_link] device is now in state OPENING pptp0: connected to 10.10.1.1:1723 pptp0: attached to connection with 10.10.1.1:1723 pptp0-0: outgoing call connected at 64000 bps [myisp_link] PPTP call successful [myisp_link] device: UP event in state OPENING [myisp_link] device is now in state UP [myisp_link] link: UP event [myisp_link] link: origination is local [myisp_link] LCP: Up event [myisp_link] LCP: state change Starting --> Req-Sent [myisp_link] LCP: phase shift DEAD --> ESTABLISH [myisp_link] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 95c7bf8b AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #2 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 95c7bf8b AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #3 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 95c7bf8b AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #4 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 95c7bf8b AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #5 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 95c7bf8b AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #6 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 95c7bf8b AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #7 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 95c7bf8b AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #8 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 95c7bf8b AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #9 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 95c7bf8b AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #10 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 95c7bf8b AUTHPROTO CHAP MSOFT [myisp_link] LCP: state change Req-Sent --> Stopped [myisp_link] LCP: LayerFinish [myisp_link] LCP: parameter negotiation failed [myisp_link] LCP: LayerFinish [myisp_link] device: CLOSE event in state UP pptp0-0: clearing call [myisp_link] device is now in state CLOSING [myisp_link] device: CLOSE event in state CLOSING [myisp_link] device is now in state CLOSING [myisp_link] device: DOWN event in state CLOSING [myisp_link] device is now in state DOWN [myisp_link] link: DOWN event [myisp_link] LCP: Down event [myisp_link] LCP: state change Stopped --> Starting [myisp_link] LCP: phase shift ESTABLISH --> DEAD [myisp_link] LCP: LayerStart [myisp_link] device: OPEN event in state DOWN [myisp_link] pausing 9 seconds before open [myisp_link] device is now in state DOWN [myisp_link] device: OPEN event in state DOWN [myisp_link] device is now in state DOWN pptp0-0: peer call disconnected res=disconnect request err=none pptp0-0: killing channel pptp0: closing connection with 10.10.1.1:1723 pptp0: ctrl connection closed by peer pptp0: killing connection with 10.10.1.1:1723 [myisp_link] device: OPEN event in state DOWN pptp0: connecting to 10.10.1.1:1723 [myisp_link] device is now in state OPENING pptp0: connected to 10.10.1.1:1723 pptp0: attached to connection with 10.10.1.1:1723 pptp0-0: outgoing call connected at 64000 bps [myisp_link] PPTP call successful [myisp_link] device: UP event in state OPENING [myisp_link] device is now in state UP [myisp_link] link: UP event [myisp_link] link: origination is local [myisp_link] LCP: Up event [myisp_link] LCP: state change Starting --> Req-Sent [myisp_link] LCP: phase shift DEAD --> ESTABLISH [myisp_link] LCP: SendConfigReq #11 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM a6eb13db AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #12 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM a6eb13db AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #13 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM a6eb13db AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #14 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM a6eb13db AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #15 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM a6eb13db AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #16 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM a6eb13db AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #17 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM a6eb13db AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #18 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM a6eb13db AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #19 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM a6eb13db AUTHPROTO CHAP MSOFT [myisp_link] LCP: SendConfigReq #20 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM a6eb13db AUTHPROTO CHAP MSOFT [myisp_link] LCP: state change Req-Sent --> Stopped [myisp_link] LCP: LayerFinish [myisp_link] LCP: parameter negotiation failed [myisp_link] LCP: LayerFinish [myisp_link] device: CLOSE event in state UP pptp0-0: clearing call [myisp_link] device is now in state CLOSING [myisp_link] device: CLOSE event in state CLOSING [myisp_link] device is now in state CLOSING [myisp_link] device: DOWN event in state CLOSING [myisp_link] device is now in state DOWN [myisp_link] link: DOWN event [myisp_link] LCP: Down event [myisp_link] LCP: state change Stopped --> Starting [myisp_link] LCP: phase shift ESTABLISH --> DEAD [myisp_link] LCP: LayerStart [myisp_link] giving up after 1 connection attempts [myisp_link] LCP: Close event [myisp_link] LCP: state change Starting --> Initial [myisp_link] LCP: LayerFinish [myisp_bundle] closing link "myisp_link"... [myisp_bundle] IPCP: Close event [myisp_bundle] IPCP: state change Starting --> Initial [myisp_bundle] IPCP: LayerFinish [myisp_bundle] bundle: CLOSE event in state OPENED [myisp_link] link: CLOSE event [myisp_link] LCP: Close event [myisp_link] device: OPEN event in state DOWN [myisp_link] pausing 9 seconds before open [myisp_link] device is now in state DOWN [myisp_link] device: CLOSE event in state DOWN [myisp_link] device is now in state DOWN pptp0-0: peer call disconnected res=disconnect request err=none pptp0-0: killing channel pptp0: closing connection with 10.10.1.1:1723 pptp0: ctrl connection closed by peer pptp0: killing connection with 10.10.1.1:1723 [myisp_bundle:myisp_link] Here's my mpd.conf (in /usr/local/etc/mpd as /etc/ppp didn't seem to work): # # mpd.conf configuration file # myisp_test: new -i ng0 myisp_bundle myisp_link set iface disable on-demand set bundle disable multilink set bundle authname "mylogin" set link max-redial 1 set link yes pap set link yes chap set link no mppc set link disable no-orig-auth set ipcp ranges 0.0.0.0 213.225.121.0/0 set iface route default And here's my mpd.links file: # # mpd.links configuration file # # myisp via pptp myisp_link: set link type pptp set pptp mode active set pptp peer 10.10.1.1 set pptp enable originate outcall The ISP runs the PPTP VPR server on Linux, prefers that we use CHAP but support both CHAP and PAP. I've tried both in the setup, without luck. I suppose my problem lies elsewhere. Hope someone can point me in the right direction. Regards, Thor _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 20 11:21: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by hub.freebsd.org (Postfix) with ESMTP id 2AA9937B419 for ; Tue, 20 Nov 2001 11:20:59 -0800 (PST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id fAKJKsk28228; Tue, 20 Nov 2001 20:20:55 +0100 (CET) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id 03CF2C25D; Tue, 20 Nov 2001 20:20:57 +0100 (CET) To: Matthew Emmerton Subject: Re: Strange problem with PPP/Netgraph (PPPoE) Message-ID: <1006284056.3bfaad18e931a@citadel.mobility.ccrle.nec.de> Date: Tue, 20 Nov 2001 20:20:56 +0100 (CET) From: Martin.Stiemerling@ccrle.nec.de Cc: brian@awfulhak.org, freebsd-net@FreeBSD.ORG References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.83 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > What is happening is that when ppp starts on bootup (ppp -quiet -ddial > pppoe), the last entry is "dial -> carrier" and nothing else. Normally Looks like that the ethernet connection between your host and the modem is broken. I get the same message when I unplug my ethernet wire. Cheers Martin > we > get a "PPPOE hook suceeded (tun0)" message after that and it goes into > the > LCP/IPCP phase. > > I'd like to point the finger at the ISP (since they've had fun dropping > connections in the past and they swapped out the modem without telling > us > -- long story, don't ask), but need to know how to interpret this > message. > Are we not getting any further because a) ppp can't talk to NETGRAPH, > b) > NETGRAPH can't talk PPPoE to the DSL modem (bad NIC) or c) DSL modem > isn't > passing along our data to the ISP (bad ISP.) > > -- > Matthew Emmerton || matt@gsicomp.on.ca > GSI Computer Services || http://www.gsicomp.on.ca > > > 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 Tue Nov 20 11:24:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 0EB1437B405 for ; Tue, 20 Nov 2001 11:24:27 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [fec0::1:12]) by Awfulhak.org (8.11.6/8.11.6) with ESMTP id fAKJONP01715; Tue, 20 Nov 2001 19:24:23 GMT (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.6/8.11.6) with ESMTP id fAKJOBv53857; Tue, 20 Nov 2001 19:24:11 GMT (envelope-from brian@freebsd-services.com) Message-Id: <200111201924.fAKJOBv53857@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Emmerton Cc: Greg Black , net@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: ppp(8) crashes 4.2-R when using netgraph(4) module In-Reply-To: Message from Matthew Emmerton of "Tue, 20 Nov 2001 09:16:35 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Nov 2001 19:24:11 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Dynamic loading of negraph modules is still broken, and probably won't be > fixed until 5.0 (at least that's what the comments on the zillion PRs > about this problem say.) > > Add 'options NETGRAPH_ETHER' and 'options NEGRAPH_SOCKET' to your kernel > config file and rebuild your kernel. I dynamically load all the modules required for client and server PPPoE on -stable and -current without problems: $ kldstat Id Refs Address Size Name 1 8 0xc0100000 3434b8 kernel 2 1 0xc1408000 c3000 vinum.ko 3 1 0xc14f4000 5000 ip6fw.ko 4 4 0xc161d000 9000 netgraph.ko 5 1 0xc162a000 3000 ng_socket.ko 6 1 0xc162d000 3000 ng_ether.ko 7 1 0xc1632000 5000 ng_pppoe.ko 8 1 0xc164e000 4000 if_tun.ko There is a problem where many of the NIC drivers get confused when netgraph gives them packets before they're IFF_UP'd. ppp now works around the problem by bringing the interface up as required. The originator should try building the latest version of ppp on his 4.2 machine and see if that helps. > -- > Matthew Emmerton || matt@gsicomp.on.ca > GSI Computer Services || http://www.gsicomp.on.ca > > On Tue, 20 Nov 2001, Greg Black wrote: > > > I rebuilt my 4.2-RELEASE kernel that has been in use for ages > > with the following extra lines in the config: > > > > options NETGRAPH #netgraph(4) system > > options NETGRAPH_PPPOE > > > > My earlier attempt to run ppp(8) on my new ADSL modem failed > > because netgraph was not in the kernel. > > > > After building a clean new kernel and installing it with the new > > modules, I tried ppp again and got a panic after a few seconds. > > I've tried it about six times. Most attempts got a panic (and I > > have typed up the console screen from one of them below), but > > some just skipped the panic and rebooted. > > > > On some attempts, we got a little bit of logging from the ppp > > process. Here's one such log: > > > > ------------------------------------------------------------------------ > > Nov 20 15:11:02 Using interface: tun0 > > Nov 20 15:11:02 deflink: Created in closed state > > Nov 20 15:11:02 Command: default: set filter alive 0 deny icmp > > Nov 20 15:11:02 Command: default: set filter alive 1 deny udp src eq 53 > > Nov 20 15:11:02 Command: default: set filter alive 2 deny udp dst eq 53 > > Nov 20 15:11:02 Command: default: set filter alive 3 permit 0 0 > > Nov 20 15:11:02 Command: bne-pi-adsl: set device PPPoE:xl0 > > Nov 20 15:11:02 Command: bne-pi-adsl: set authname ******** > > Nov 20 15:11:02 Command: bne-pi-adsl: set authkey ******** > > Nov 20 15:11:02 Command: bne-pi-adsl: set ifaddr 203.143.238.93 0.0.0.0/0 > > Nov 20 15:11:02 Command: bne-pi-adsl: add default HISADDR > > Nov 20 15:11:02 Command: bne-pi-adsl: set timeout 0 > > Nov 20 15:11:02 Phase: PPP Started (foreground mode). > > Nov 20 15:11:02 Phase: bundle: Establish > > Nov 20 15:11:02 Phase: deflink: closed -> opening > > ------------------------------------------------------------------------ > > > > Each line also had the following data after the date: > > bambi ppp[95014]: tun0: > > > > Here's the console screen on one panic: > > > > ------------------------------------------------------------------------ > > module_register: module netgraph already exists! > > linker_file_sysinit "netgraph.ko" failed to register! 17 > > > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x4 > > fault code = supervisor write, page not present > > instruction pointer = 0x8:0xc01c9e3f > > stack pointer = 0x10:0xd24c2c98 > > frame pointer = 0x10:0xd24c2ca8 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 77817 (ppp) > > interrupt mask = net > > trap number = 12 > > panic: page fault > > > > syncing disks... 113 7 2 > > done > > Uptime: 5m2s > > Automatic reboot in 15 seconds - press a key [rest elided] > > ------------------------------------------------------------------------ > > > > If anybody can point me in the right direction to solve this, > > I'll be very grateful. My sole goal is to get ppp to talk to my > > ADSL modem, so if there's some other magic I should try, I'm > > happy to do that. -- Brian http://www.freebsd-services.com/ 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 Nov 20 11:26:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 7E05C37B419 for ; Tue, 20 Nov 2001 11:26:40 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [fec0::1:12]) by Awfulhak.org (8.11.6/8.11.6) with ESMTP id fAKJQdP01739; Tue, 20 Nov 2001 19:26:39 GMT (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.6/8.11.6) with ESMTP id fAKJQRv53937; Tue, 20 Nov 2001 19:26:27 GMT (envelope-from brian@freebsd-services.com) Message-Id: <200111201926.fAKJQRv53937@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Martin.Stiemerling@ccrle.nec.de Cc: Matthew Emmerton , brian@Awfulhak.org, freebsd-net@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: Strange problem with PPP/Netgraph (PPPoE) In-Reply-To: Message from Martin.Stiemerling@ccrle.nec.de of "Tue, 20 Nov 2001 20:20:56 +0100." <1006284056.3bfaad18e931a@citadel.mobility.ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Nov 2001 19:26:27 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > What is happening is that when ppp starts on bootup (ppp -quiet -ddial > > pppoe), the last entry is "dial -> carrier" and nothing else. Normally > > Looks like that the ethernet connection between your host and the modem is > broken. I get the same message when I unplug my ethernet wire. Sounds plausible. I guess a tcpdump would tell.... > Cheers > Martin -- Brian http://www.freebsd-services.com/ 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 Nov 20 11:40:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 981E137B419 for ; Tue, 20 Nov 2001 11:40:24 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA34119; Tue, 20 Nov 2001 11:22:57 -0800 (PST) Date: Tue, 20 Nov 2001 11:22:55 -0800 (PST) From: Julian Elischer To: Martin.Stiemerling@ccrle.nec.de Cc: Matthew Emmerton , brian@awfulhak.org, freebsd-net@FreeBSD.ORG Subject: Re: Strange problem with PPP/Netgraph (PPPoE) In-Reply-To: <1006284056.3bfaad18e931a@citadel.mobility.ccrle.nec.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org the way to debug this is to run tcpdump on the ethernet card in question tcpdump knows how to interpret pppoe packets and it's good to see what is coming over from the other end.. On Tue, 20 Nov 2001 Martin.Stiemerling@ccrle.nec.de wrote: > > > What is happening is that when ppp starts on bootup (ppp -quiet -ddial > > pppoe), the last entry is "dial -> carrier" and nothing else. Normally > > Looks like that the ethernet connection between your host and the modem is > broken. I get the same message when I unplug my ethernet wire. > > Cheers > Martin > > > > we > > get a "PPPOE hook suceeded (tun0)" message after that and it goes into > > the > > LCP/IPCP phase. > > > > I'd like to point the finger at the ISP (since they've had fun dropping > > connections in the past and they swapped out the modem without telling > > us > > -- long story, don't ask), but need to know how to interpret this > > message. > > Are we not getting any further because a) ppp can't talk to NETGRAPH, > > b) > > NETGRAPH can't talk PPPoE to the DSL modem (bad NIC) or c) DSL modem > > isn't > > passing along our data to the ISP (bad ISP.) > > > > -- > > Matthew Emmerton || matt@gsicomp.on.ca > > GSI Computer Services || http://www.gsicomp.on.ca > > > > > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 20 18: 2:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from rose.niw.com.au (cerberus.apdata.com.au [202.14.95.17]) by hub.freebsd.org (Postfix) with ESMTP id 0D49C37B405 for ; Tue, 20 Nov 2001 18:02:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rose.niw.com.au (Postfix) with ESMTP id BF4A89721C for ; Wed, 21 Nov 2001 12:32:33 +1030 (CST) Received: by rose.niw.com.au (Postfix, from userid 1000) id 6081F97215; Wed, 21 Nov 2001 12:32:32 +1030 (CST) Date: Wed, 21 Nov 2001 12:32:32 +1030 From: Ian West To: freebsd-net@freebsd.org Subject: expiring cached routes on in_pcb entries. Message-ID: <20011121123232.Q80670@rose.niw.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have been looking at the code in ip_ouput in relation to a problem I have had with named using the wrong route for talking to forwarders after route changes occur. There is a check for cached routes, and a check for validity, but not as far as I can see a check for expiry. The situation is when the box starts it has a default route, named starts and uses this to talk to try to talk to it's forwarder. (via UDP, but I don't think it matters). Some time later we get a specific route for the subnet on which the forwarder resides via a dialup (tun) interface. While the route tables all update up correctly, and new connections use the direct route, the named connection continues to send packets out via the wrong interface until it is restarted. I am looking at the ip_output routines, but so far cannot see any check for expiry of cached routes ? Can anyone point me in the right direction (or confirm they don't expire unless the route is physically unavailable ?) Thankyou. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 20 18:37:21 2001 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 7AFD737B405 for ; Tue, 20 Nov 2001 18:37:19 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fAL2bD042142; Tue, 20 Nov 2001 21:37:13 -0500 (EST) (envelope-from wollman) Date: Tue, 20 Nov 2001 21:37:13 -0500 (EST) From: Garrett Wollman Message-Id: <200111210237.fAL2bD042142@khavrinen.lcs.mit.edu> To: Ian West Cc: freebsd-net@FreeBSD.ORG Subject: expiring cached routes on in_pcb entries. In-Reply-To: <20011121123232.Q80670@rose.niw.com.au> References: <20011121123232.Q80670@rose.niw.com.au> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > I am looking at the ip_output routines, but so far cannot see any check > for expiry of cached routes ? Can anyone point me in the right > direction (or confirm they don't expire unless the route is physically > unavailable ?) Routes which are in use do not have timers on them, and therefore do not expire. However, if any route higher in the routing hierarchy changes, the PCB routes should be deleted, and the next output operation on that PCB should notice. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 20 18:45:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id DCBF937B416 for ; Tue, 20 Nov 2001 18:45:32 -0800 (PST) Received: (qmail 97458 invoked by uid 1000); 21 Nov 2001 02:45:31 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Nov 2001 02:45:31 -0000 Date: Tue, 20 Nov 2001 20:45:31 -0600 (CST) From: Mike Silbersack To: Ian West Cc: Subject: Re: expiring cached routes on in_pcb entries. In-Reply-To: <20011121123232.Q80670@rose.niw.com.au> Message-ID: <20011120204428.G95596-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 21 Nov 2001, Ian West wrote: > Hi, I have been looking at the code in ip_ouput in relation to a problem > I have had with named using the wrong route for talking to forwarders > after route changes occur. There is a check for cached routes, and a > check for validity, but not as far as I can see a check for expiry. What revision of the code are you looking at? Some related behavior was changed relatively recently. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 20 20:28:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.143.238.93]) by hub.freebsd.org (Postfix) with SMTP id E6BDD37B41E for ; Tue, 20 Nov 2001 20:27:57 -0800 (PST) Received: (qmail 22476 invoked by uid 1001); 21 Nov 2001 14:27:54 +1000 X-Posted-By: GJB-Post 2.22 07-Nov-2001 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Message-Id: Date: Wed, 21 Nov 2001 14:27:54 +1000 From: Greg Black To: Brian Somers Cc: Matthew Emmerton , net@FreeBSD.ORG Subject: Re: ppp(8) crashes 4.2-R when using netgraph(4) module References: <200111201924.fAKJOBv53857@hak.lan.Awfulhak.org> In-reply-to: <200111201924.fAKJOBv53857@hak.lan.Awfulhak.org> of Tue, 20 Nov 2001 19:24:11 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Brian Somers wrote: | > Dynamic loading of negraph modules is still broken, and probably won't be | > fixed until 5.0 (at least that's what the comments on the zillion PRs | > about this problem say.) | > | > Add 'options NETGRAPH_ETHER' and 'options NEGRAPH_SOCKET' to your kernel | > config file and rebuild your kernel. | | I dynamically load all the modules required for client and server | PPPoE on -stable and -current without problems: Well, I had already compiled all the netgraph stuff into the kernel before I saw this. And it did get rid of the netgraph complaints as part of the next few panics. | There is a problem where many of the NIC drivers get confused when | netgraph gives them packets before they're IFF_UP'd. ppp now works | around the problem by bringing the interface up as required. | | The originator should try building the latest version of ppp on his | 4.2 machine and see if that helps. I took the easy way out here and just ran ifconfig xl0 inet 10.0.0.1 After that, no more panics and the ADSL modem worked first time. Now, the final question: I have to implement something similar on a 4.1-R system several thousand km away. There's no question of upgrading it from 4.1 and I can't afford to have it panic. Is it reasonable to expect that PPPoE will work OK provided I add the netgraph stuff to the kernel and ensure the NIC is UP before running ppp? FYI, I also tried a different box that runs 4.3-R and it did not experience the panic that was seen on the 4.2-R system. Thanks a lot for the help with this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 20 20:50:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts11-srv.bellnexxia.net (tomts11.bellnexxia.net [209.226.175.55]) by hub.freebsd.org (Postfix) with ESMTP id E4D9437B405 for ; Tue, 20 Nov 2001 20:50:32 -0800 (PST) Received: from xena.gsicomp.on.ca ([199.243.144.157]) by tomts11-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20011121045026.UIKK24249.tomts11-srv.bellnexxia.net@xena.gsicomp.on.ca>; Tue, 20 Nov 2001 23:50:26 -0500 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.11.1) with SMTP id fAL4gAW35670; Tue, 20 Nov 2001 23:42:10 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <03f301c17248$074022a0$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Greg Black" Cc: References: <200111201924.fAKJOBv53857@hak.lan.Awfulhak.org> Subject: Re: ppp(8) crashes 4.2-R when using netgraph(4) module Date: Tue, 20 Nov 2001 23:50:21 -0500 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.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Greg Black wrote: > Now, the final question: I have to implement something similar > on a 4.1-R system several thousand km away. There's no question > of upgrading it from 4.1 and I can't afford to have it panic. > Is it reasonable to expect that PPPoE will work OK provided I > add the netgraph stuff to the kernel and ensure the NIC is UP > before running ppp? Yes, that should look after all the gotchas. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 20 20:56:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from rose.niw.com.au (cerberus.apdata.com.au [202.14.95.17]) by hub.freebsd.org (Postfix) with ESMTP id 39F5737B418 for ; Tue, 20 Nov 2001 20:56:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rose.niw.com.au (Postfix) with ESMTP id D753D9724A; Wed, 21 Nov 2001 15:26:51 +1030 (CST) Received: by rose.niw.com.au (Postfix, from userid 1000) id A719197225; Wed, 21 Nov 2001 15:26:48 +1030 (CST) Date: Wed, 21 Nov 2001 15:26:48 +1030 From: Ian West To: Mike Silbersack Cc: freebsd-net@freebsd.org Subject: Re: expiring cached routes on in_pcb entries. Message-ID: <20011121152648.Y80670@rose.niw.com.au> References: <20011121123232.Q80670@rose.niw.com.au> <20011120204428.G95596-100000@achilles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011120204428.G95596-100000@achilles.silby.com>; from silby@silby.com on Tue, Nov 20, 2001 at 08:45:31PM -0600 X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Nov 20, 2001 at 08:45:31PM -0600, Mike Silbersack wrote: > > On Wed, 21 Nov 2001, Ian West wrote: > > > Hi, I have been looking at the code in ip_ouput in relation to a problem > > I have had with named using the wrong route for talking to forwarders > > after route changes occur. There is a check for cached routes, and a > > check for validity, but not as far as I can see a check for expiry. > > What revision of the code are you looking at? Some related behavior was > changed relatively recently. > > Mike "Silby" Silbersack > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message I have seen the problem occur on two different machines, one is running code 4.3-STABLE FreeBSD 4.3-STABLE #0: Thu May 10 15:13:04 CST 2001 the other is 4.3-STABLE FreeBSD 4.3-STABLE #0: Mon May 28 16:10:27 CST 2001 Both machines showed named requests taking the wrong route. Both recovered by restarting named. The code I am actually looking at is the source on a 4.4 stable box. I will see if I can duplicate the problem with 4.4 stable. Are the recent changes a fix for this type of behaviour, or something that may have introduced it ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 20 21:10: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from imo-m04.mx.aol.com (imo-m04.mx.aol.com [64.12.136.7]) by hub.freebsd.org (Postfix) with ESMTP id BE13C37B416 for ; Tue, 20 Nov 2001 21:10:07 -0800 (PST) Received: from YuJamC@netscape.net by imo-m04.mx.aol.com (mail_out_v31_r1.9.) id n.19.2607589 (16213) for ; Wed, 21 Nov 2001 00:09:59 -0500 (EST) Received: from netscape.net (dns1.synology.com [210.58.106.131]) by air-in01.mx.aol.com (v82.22) with ESMTP id MAILININ11-1121000959; Wed, 21 Nov 2001 00:09:59 -0500 Message-ID: <3BFB376F.3030005@netscape.net> Date: Wed, 21 Nov 2001 13:11:11 +0800 From: James Chen User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Problem with if_nge and netatalk Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dear all: I encounter a problem that I cannot receive AppleTalk packets with NS gigabit NIC. I use the netatalk and it does work with Intel's 82544. I find that the driver (if_nge.c) would drop the packets at line 1370. if(!(rxstat & NGE_CMDSTS_PKT_OK)) { ifp->if_ierrors++; nge_newbuf(sc, cur_rx, m); continue; } However, it doesn't happen for TCP/IP packets. Do I have to disable some function on the chip? Thanks, James To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 20 21:19:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 0E23637B416 for ; Tue, 20 Nov 2001 21:19:09 -0800 (PST) Received: (qmail 97952 invoked by uid 1000); 21 Nov 2001 05:19:07 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Nov 2001 05:19:07 -0000 Date: Tue, 20 Nov 2001 23:19:07 -0600 (CST) From: Mike Silbersack To: Ian West Cc: Subject: Re: expiring cached routes on in_pcb entries. In-Reply-To: <20011121152648.Y80670@rose.niw.com.au> Message-ID: <20011120230807.O97823-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 21 Nov 2001, Ian West wrote: > I have seen the problem occur on two different machines, one is running > code 4.3-STABLE FreeBSD 4.3-STABLE #0: Thu May 10 15:13:04 CST 2001 > the other is 4.3-STABLE FreeBSD 4.3-STABLE #0: Mon May 28 16:10:27 CST > 2001 Both machines showed named requests taking the wrong route. Both > recovered by restarting named. > > The code I am actually looking at is the source on a 4.4 stable box. I > will see if I can duplicate the problem with 4.4 stable. Are the recent > changes a fix for this type of behaviour, or something that may have > introduced it ? Hm, good question. I was going to suggest that rev 1.59.2.2 would fix your problem, but apparently it only fixes the problem with routes going away, not routes appearing. You're probably best contacting Ruslan (ru@freebsd.org) directly; he's been the one doing the work in that file, and could probably tell you if his more recent commits address your problem. As for the expiration of cloned routes: They're only timed out by a kernel process which runs minimally once every 10 minutes (more often under heavy route load.) This would explain why they're persisting longer than you expect them to. I wouldn't worry about the longer than expected expiration though; expiration of cloned routes isn't the issue here; the routing code should be invalidating the existing cloned routes when the new route appears. (Apparently this is not happening in your situation.) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 20 23: 0: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 3123737B418 for ; Tue, 20 Nov 2001 23:00:05 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id WAA21531; Tue, 20 Nov 2001 22:49:24 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fAL6nNe17588; Tue, 20 Nov 2001 22:49:23 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111210649.fAL6nNe17588@arch20m.dellroad.org> Subject: Re: expiring cached routes on in_pcb entries. In-Reply-To: <20011120230807.O97823-100000@achilles.silby.com> "from Mike Silbersack at Nov 20, 2001 11:19:07 pm" To: Mike Silbersack Date: Tue, 20 Nov 2001 22:49:23 -0800 (PST) Cc: Ian West , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Silbersack writes: > > I have seen the problem occur on two different machines, one is running > > code 4.3-STABLE FreeBSD 4.3-STABLE #0: Thu May 10 15:13:04 CST 2001 > > the other is 4.3-STABLE FreeBSD 4.3-STABLE #0: Mon May 28 16:10:27 CST > > 2001 Both machines showed named requests taking the wrong route. Both > > recovered by restarting named. > > > > The code I am actually looking at is the source on a 4.4 stable box. I > > will see if I can duplicate the problem with 4.4 stable. Are the recent > > changes a fix for this type of behaviour, or something that may have > > introduced it ? > > Hm, good question. I was going to suggest that rev 1.59.2.2 would fix > your problem, but apparently it only fixes the problem with routes going > away, not routes appearing. > > You're probably best contacting Ruslan (ru@freebsd.org) directly; he's > been the one doing the work in that file, and could probably tell you if > his more recent commits address your problem. This sounds like maybe kern/10778. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 20 23:40:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from mine.kame.net (kame195.kame.net [203.178.141.195]) by hub.freebsd.org (Postfix) with ESMTP id 7314C37B418 for ; Tue, 20 Nov 2001 23:40:49 -0800 (PST) Received: from localhost ([3ffe:501:4819:eeea::6]) by mine.kame.net (8.11.1/3.7W) with ESMTP id fAL7ZKa05413; Wed, 21 Nov 2001 16:35:20 +0900 (JST) To: hongbintang@yahoo.com Cc: net@freebsd.org Subject: Re: How can I add new ESP encryption functions into FreeBSD kernel In-Reply-To: Your message of "Mon, 19 Nov 2001 21:26:15 -0800 (PST)" <20011120052615.36411.qmail@web11602.mail.yahoo.com> References: <20011120052615.36411.qmail@web11602.mail.yahoo.com> X-Mailer: Cue version 0.6 (011026-1440/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20011121164056H.sakane@kame.net> Date: Wed, 21 Nov 2001 16:40:56 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I want to add my encryption algorithm of ESP, an > algorithm like DES, into FreeBSD kernel so as to make > kernel recognize it. I added its definitions in > /usr/src/sys/net/pfkeyv2.h, added specific functions > implementation into /usr/src/sys/netinet6/esp.core.c > and added a new subdirectory in sys/crypto. Afterwards > I rebuild kernel, but system can't recognize my ESP > encryption algorithm when I use PF socket or setkey > command to add a new SA into SAD including my new > encryption. > In a word, please tell me what I should do > step by step if I want to add a new ESP encryption > algorithm that I have already implemented into kernel what is the system ? did "setkey" command recognize your encryption algorithm ? or did the pfkey interface so ? did you get a success to install SA with your algorithm ? check which module did not recognize the algorithm. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 0: 0:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 9387537B417 for ; Wed, 21 Nov 2001 00:00:36 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA36632; Tue, 20 Nov 2001 23:47:48 -0800 (PST) Date: Tue, 20 Nov 2001 23:47:46 -0800 (PST) From: Julian Elischer To: Greg Black Cc: Brian Somers , Matthew Emmerton , net@FreeBSD.ORG Subject: Re: ppp(8) crashes 4.2-R when using netgraph(4) module In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 21 Nov 2001, Greg Black wrote: > > I took the easy way out here and just ran > > ifconfig xl0 inet 10.0.0.1 > Why put an IP address on it? ifconfig xl0 up To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 2:21: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f98.law3.hotmail.com [209.185.241.98]) by hub.freebsd.org (Postfix) with ESMTP id 6DFF837B405; Wed, 21 Nov 2001 02:20:54 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Nov 2001 02:20:54 -0800 Received: from 139.108.175.26 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 21 Nov 2001 10:20:54 GMT X-Originating-IP: [139.108.175.26] From: "Thor Legvold" To: freebsd-net@freebsd.org Cc: freebsd-questions@freebsd.org Subject: Network setup questions Date: Wed, 21 Nov 2001 10:20:54 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Nov 2001 10:20:54.0415 (UTC) FILETIME=[33D159F0:01C17276] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Well, I've asked 3 or 4 times now in the last 3 weeks, and haven't received any answers. Posted to comp.unix.bsd.freebsd.misc and to both questions- and net@freebsd.org. That leads me to conclude that either I'm: asking the wrong question(s), asking in an improper manner or asking the wrong people/wrong group. I *have* searched Deja, I *have* read the docs and attempted to get this to work - I really don't know where else I could be looking or asking for more information. If my question was worded poorly or inappropiate, I would appreciate a pointer as to where/how/who I might contact in order to get my system up and configured properly. Again, I'm trying to log into an ISP via PPTP for internet access, using mpd-netgraph but also trying out pptpclient. I have a small home LAN that I want to NAT/IPFW such that all machines can share the internet connection. I'm running FreeBSD 4.4-Stable. Regards, Thor _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 2:50:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from oldmail.iae.nl (mail.iae.nl [212.61.26.54]) by hub.freebsd.org (Postfix) with ESMTP id 1125037B419 for ; Wed, 21 Nov 2001 02:50:09 -0800 (PST) Received: from uucp.iae.nl (unknown [212.61.26.37]) by oldmail.iae.nl (Postfix) with ESMTP id 9AE4520FC6 for ; Wed, 21 Nov 2001 11:50:06 +0100 (CET) Received: (from uucp@localhost) by uucp.iae.nl (8.9.1/8.9.1) with IAEhv.nl id LAA14130 for freebsd-net@freebsd.org; Wed, 21 Nov 2001 11:50:06 +0100 (MET) Received: from bowtie.nl (hume.intra.bowtie.nl [192.168.4.13]) by bowtie.nl (8.11.1/8.11.1) with ESMTP id fALAjom68107 for ; Wed, 21 Nov 2001 11:45:50 +0100 (CET) (envelope-from joao@bowtie.nl) Message-ID: <3BFB85DD.47B481B9@bowtie.nl> Date: Wed, 21 Nov 2001 11:45:49 +0100 From: Joao Schim Organization: BowTie Technology X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Network setup questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thor Legvold wrote: > > Well, I've asked 3 or 4 times now in the last 3 weeks, and haven't received > any answers. Posted to comp.unix.bsd.freebsd.misc and to both questions- and > net@freebsd.org. > > That leads me to conclude that either I'm: asking the wrong question(s), > asking in an improper manner or asking the wrong people/wrong group. I just subscribed yesterday so i don't know 'bout that. :) > I *have* searched Deja, I *have* read the docs and attempted to get this to > work - I really don't know where else I could be looking or asking for more > information. If my question was worded poorly or inappropiate, I would > appreciate a pointer as to where/how/who I might contact in order to get my > system up and configured properly. > > Again, I'm trying to log into an ISP via PPTP for internet access, using > mpd-netgraph but also trying out pptpclient. I have a small home LAN that I > want to NAT/IPFW such that all machines can share the internet connection. > I'm running FreeBSD 4.4-Stable. Well.. hmm eh.. what's your question ? > Regards, > Thor > Regards, Joao To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 3: 7: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.143.238.93]) by hub.freebsd.org (Postfix) with SMTP id 6EE7837B41E for ; Wed, 21 Nov 2001 03:06:57 -0800 (PST) Received: (qmail 24237 invoked by uid 1001); 21 Nov 2001 21:06:54 +1000 X-Posted-By: GJB-Post 2.22 07-Nov-2001 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Message-Id: Date: Wed, 21 Nov 2001 21:06:54 +1000 From: Greg Black Mail-Followup-To: freebsd-questions@freebsd.org To: "Thor Legvold" Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Network setup questions References: In-reply-to: of Wed, 21 Nov 2001 10:20:54 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Thor Legvold" wrote: | Well, I've asked 3 or 4 times now in the last 3 weeks, and haven't received | any answers. Posted to comp.unix.bsd.freebsd.misc and to both questions- and | net@freebsd.org. | | That leads me to conclude that either I'm: asking the wrong question(s), | asking in an improper manner or asking the wrong people/wrong group. | | I *have* searched Deja, I *have* read the docs and attempted to get this to | work - I really don't know where else I could be looking or asking for more | information. If my question was worded poorly or inappropiate, I would | appreciate a pointer as to where/how/who I might contact in order to get my | system up and configured properly. | | Again, I'm trying to log into an ISP via PPTP for internet access, using | mpd-netgraph but also trying out pptpclient. I have a small home LAN that I | want to NAT/IPFW such that all machines can share the internet connection. | I'm running FreeBSD 4.4-Stable. First, don't cross-post; stick to freebsd-questions for now. Second, what is your question? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 3:23:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.143.238.93]) by hub.freebsd.org (Postfix) with SMTP id 8EA5537B418 for ; Wed, 21 Nov 2001 03:23:44 -0800 (PST) Received: (qmail 25204 invoked by uid 1001); 21 Nov 2001 21:23:41 +1000 X-Posted-By: GJB-Post 2.22 07-Nov-2001 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Message-Id: Date: Wed, 21 Nov 2001 21:23:41 +1000 From: Greg Black To: Julian Elischer Cc: Brian Somers , Matthew Emmerton , net@FreeBSD.ORG Subject: Re: ppp(8) crashes 4.2-R when using netgraph(4) module References: In-reply-to: of Tue, 20 Nov 2001 23:47:46 PST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer wrote: | > I took the easy way out here and just ran | > | > ifconfig xl0 inet 10.0.0.1 | | Why put an IP address on it? | | ifconfig xl0 up I left out a detail. The modem has its own 10.x.x.x address and I was killing two birds with one stone -- this makes it easy to talk to the modem as well as bringing it up. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 4:41:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f6.law3.hotmail.com [209.185.241.6]) by hub.freebsd.org (Postfix) with ESMTP id 611D637B418 for ; Wed, 21 Nov 2001 04:41:19 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Nov 2001 04:41:19 -0800 Received: from 139.108.175.26 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 21 Nov 2001 12:41:19 GMT X-Originating-IP: [139.108.175.26] From: "Thor Legvold" To: joao@bowtie.nl, freebsd-net@freebsd.org Subject: Re: Network setup questions Date: Wed, 21 Nov 2001 12:41:19 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Nov 2001 12:41:19.0351 (UTC) FILETIME=[D1789070:01C17289] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Joao, >Well.. hmm eh.. what's your question ? > I just posted it a few minutes ago to freebsd-questions (again). Else a quick search in the archives will show it (search word VPN PPTP mpd). I was asked not to cross post, but I can also send a copy to you privately if you would like. >Regards, >Joao Regards, Thor _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 5:37: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 5261137B419 for ; Wed, 21 Nov 2001 05:36:58 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 2AB1714C2E; Wed, 21 Nov 2001 14:36:57 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: net@freebsd.org Subject: Garbage tacked onto end of packet From: Dag-Erling Smorgrav Date: 21 Nov 2001 14:36:56 +0100 Message-ID: Lines: 7 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org http://lcamtuf.coredump.cx/mobp/ See Exhibit 5. Is this a known bug? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 6:10: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id E552637B417 for ; Wed, 21 Nov 2001 06:10:05 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fALE5vj32559; Wed, 21 Nov 2001 06:05:57 -0800 (PST) (envelope-from rizzo) Date: Wed, 21 Nov 2001 06:05:57 -0800 From: Luigi Rizzo To: Dag-Erling Smorgrav Cc: net@FreeBSD.ORG Subject: Re: Garbage tacked onto end of packet Message-ID: <20011121060557.A32497@iguana.aciri.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [Bcc to Przemyslaw Frasunek who submitted the example in case he can tell what hardware was involved] On Wed, Nov 21, 2001 at 02:36:56PM +0100, Dag-Erling Smorgrav wrote: > http://lcamtuf.coredump.cx/mobp/ > > See Exhibit 5. Is this a known bug? Looks more like one or more bugs in a specific device driver, tcpdump or bpf. Here we have a short IP packet (44 bytes) which is later shown as having 46 and then 64 bytes. On the wire, ethernet frames are supposed to have at least 64 bytes (including CRC ?) which is exactly 14+46+4 -- so the second example makes perfect sense, it is the only legal format of such a frame coming from an ethernet interface. As for the third one, it might well be that some device driver misinterprets the padding (possibly on the output side) and tries to generate 64-bytes in addition to the headers. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 8:15:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailrelay2.kpn.net (mailrelay2.kpn.net [194.151.226.228]) by hub.freebsd.org (Postfix) with ESMTP id 976A037B417 for ; Wed, 21 Nov 2001 08:14:54 -0800 (PST) Received: from [159.46.248.20] (helo=smtp1.MINJUS.NL) by mailrelay2.kpn.net with smtp (Exim 3.22 #1) id 166a1Q-0006Dk-00 for freebsd-net@FreeBSD.org; Wed, 21 Nov 2001 17:14:48 +0100 X-Server-Uuid: aa978977-e659-47de-8745-df740a63e99a X-Internal-ID: 3BFA26110000D5C3 Message-ID: <8BA878388251D311B08200508B449FD10D0E3F4A@BEHDEVEX1> From: "Rudi Mathijssen" To: "'freebsd-net@FreeBSD.org'" Subject: kernel backtrace for kern/28844 Date: Wed, 21 Nov 2001 17:14:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 17E50E9879868-112-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C172A7.AB0AF914" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C172A7.AB0AF914 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable We had to wait 10 days for the next kernel crash to happily collect our crash dump (people who were using the system at that moment to route thei= r remote maintance job were not so happy...).=20 It appears that the argument m to m_freem() is corrupt, but the value of = m in the context of the caller is 0. This could mean we have corrupted stac= k, or maybe I simply don't understand gdb (I never used it before). As the contents of sc show, the code was handling interface de1 at the moment of the crash. If you need more information, please let me know. Greetings, Rudi Mathijssen # gdb -k=20 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for detail= s. This GDB was configured as "i386-unknown-freebsd". (kgdb) symbol kernel.debug Reading symbols from kernel.debug...done. (kgdb) exec /var/crash/kernel.2 (kgdb) core /var/crash/vmcore.2 IdlePTD 2965504 initial pcb at 263de0 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0x79c02812 fault code =3D supervisor read, page not present instruction pointer =3D 0x8:0xc0164da8 stack pointer =3D 0x10:0xc0244440 frame pointer =3D 0x10:0xc024444c code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D Idle interrupt mask =3D net=20 trap number =3D 12 panic: page fault syncing disks...=20 done Uptime: 10d10h58m20s dumping to dev #da/0x20001, offset 1737856 dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 = 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90= 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 6= 4 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 3= 9 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 1= 4 13 12 11 10 9 8 7 6 5 4 3 2 1=20 --- #0 dumpsys () at ../../kern/kern_shutdown.c:469 469 if (dumping++) { (kgdb) where #0 dumpsys () at ../../kern/kern_shutdown.c:469 #1 0xc014ab7f in boot (howto%6) at ../../kern/kern_shutdown.c:309 #2 0xc014aefc in poweroff_wait (junk=3D0xc023c0cf, howto=3D0) at ../../kern/kern_shutdown.c:556 #3 0xc02060e5 in trap_fatal (frame=3D0xc0244400, eva 42636306) at ../../i386/i386/trap.c:951 #4 0xc0205dbd in trap_pfault (frame=3D0xc0244400, usermode=3D0, eva 4263= 6306) at ../../i386/i386/trap.c:844 #5 0xc02059a3 in trap (frame=3D{tf_fs =3D 16, tf_es =3D 16, tf_ds =3D -2= 147483632,=20 tf_edi =3D 6717472, tf_esi =3D -1064284928, tf_ebp =3D -1071365044,=20 tf_isp =3D -1071365076, tf_ebx =3D 2042636288, tf_edx =3D 0,=20 tf_ecx =3D -1066018816, tf_eax =3D -6717473, tf_trapno =3D 12, tf_err =3D= 0, tf_eip =3D -1072280152, tf_cs =3D 8, tf_eflags =3D 66054,=20 tf_esp =3D -1053560832, tf_ss =3D 2147430528}) at ../../i386/i386/trap.c:443 #6 0xc0164da8 in m_freem (m=3D0xc0904d00) at ../../kern/uipc_mbuf.c:525 #7 0xc01a54b5 in tulip_tx_intr (sc=3D0xc133f000) at ../../pci/if_de.c:37= 15 #8 0xc01a5cf1 in tulip_txput (sc=3D0xc133f000, m=3D0xc08d2100) at ../../pci/if_de.c:4299 #9 0xc01a6421 in tulip_ifstart_one (ifp=3D0xc133f018) at ../../pci/if_de.c:4740 #10 0xc018bc1c in ether_output_frame (ifp=3D0xc133f018, m=3D0xc08d2100) at ../../net/if_ethersubr.c:401 #11 0xc018bb8a in ether_output (ifp=3D0xc133f018, m=3D0xc08d2100, dst=3D0xc02650d4,=20 rt0=3D0xc142b000) at ../../net/if_ethersubr.c:354 #12 0xc019856f in ip_output (m0=3D0xc0765400, opt=3D0x0, ro=3D0xc02650d0,= flags=3D1, imo=3D0x0) at ../../netinet/ip_output.c:787 #13 0xc0197d04 in ip_forward (m=3D0xc0765400, srcrt=3D0) at ../../netinet/ip_input.c:1552 #14 0xc0196f0e in ip_input (m=3D0xc0765400) at ../../netinet/ip_input.c:5= 63 #15 0xc019713f in ipintr () at ../../netinet/ip_input.c:759 #16 0xc01fc675 in swi_net_next () (kgdb) up 6 #6 0xc0164da8 in m_freem (m=3D0xc0904d00) at ../../kern/uipc_mbuf.c:525 525 if (m =3D=3D NULL) (kgdb) print m $1 =3D (struct mbuf *) 0x668020 (kgdb) print *m cannot read proc at 0 (kgdb) up 1 #7 0xc01a54b5 in tulip_tx_intr (sc=3D0xc133f000) at ../../pci/if_de.c:37= 15 3715 m_freem(m); (kgdb) print m $2 =3D (struct mbuf *) 0x0 (kgdb) echo print sc $4 =3D (tulip_softc_t *) 0xc133f000 (kgdb) print *sc $5 =3D {tulip_ifmedia =3D {ifm_mask =3D 0, ifm_media =3D 0, ifm_cur =3D 0= xc071c600,=20 ifm_list =3D {lh_first =3D 0xc071c600},=20 ifm_change =3D 0xc01a46f4 ,=20 ifm_status =3D 0xc01a4774 }, tulip_ac =3D {ac_if =3D { if_softc =3D 0xc133f000, if_name =3D 0xc022a53d "de", if_link =3D { tqe_next =3D 0xc1340018, tqe_prev =3D 0xc071b020}, if_addrhead =3D { tqh_first =3D 0xc132c700, tqh_last =3D 0xc1423f10}, if_pcount =3D 0,=20 if_bpf =3D 0x0, if_index =3D 2, if_unit =3D 1, if_timer =3D 1,=20 if_flags =3D -30653, if_ipending =3D 0, if_linkmib =3D 0x0, if_linkmible= n =3D 0,=20 if_data =3D {ifi_type =3D 6 '\006', ifi_physical =3D 0 '\000',=20 ifi_addrlen =3D 6 '\006', ifi_hdrlen =3D 14 '\016',=20 ifi_recvquota =3D 0 '\000', ifi_xmitquota =3D 0 '\000', ifi_mtu =3D 1500,=20 ifi_metric =3D 0, ifi_baudrate =3D 100000000, ifi_ipackets =3D 13710740,=20 ifi_ierrors =3D 0, ifi_opackets =3D 13455672, ifi_oerrors =3D 1,=20 ifi_collisions =3D 84737, ifi_ibytes =3D 2233673408,=20 ifi_obytes =3D 1905899332, ifi_imcasts =3D 119437, ifi_omcasts =3D 0,=20 ifi_iqdrops =3D 0, ifi_noproto =3D 0, ifi_hwassist =3D 0, ifi_unused =3D 0,=20 ifi_lastchange =3D {tv_sec =3D 0, tv_usec =3D 0}}, if_multiaddrs =3D { lh_first =3D 0xc13485c0}, if_amcount =3D 0,=20 if_output =3D 0xc018b878 ,=20 if_start =3D 0xc01a63d4 , if_done =3D 0,=20 if_ioctl =3D 0xc01a61cc ,=20 if_watchdog =3D 0xc01a6450 , if_poll_recv =3D 0,=20 if_poll_xmit =3D 0, if_poll_intren =3D 0, if_poll_slowinput =3D 0,=20 if_init =3D 0, if_resolvemulti =3D 0xc018bf4c ,=20 if_snd =3D {ifq_head =3D 0x0, ifq_tail =3D 0x0, ifq_len =3D 0, ifq_maxle= n =3D 50,=20 ifq_drops =3D 0}, if_poll_slowq =3D 0x0, if_prefixhead =3D {tqh_first =3D 0x0,=20 tqh_last =3D 0xc133f0e8}}, ac_enaddr =3D "\000=E0)<=E0{", ac_multicnt =3D 0,=20 ac_netgraph =3D 0x0}, tulip_csrs_bst =3D 0, tulip_csrs_bsh =3D 12416,=20 tulip_csrs =3D {csr_busmode =3D 0, csr_txpoll =3D 8, csr_rxpoll =3D 16,=20 csr_rxlist =3D 24, csr_txlist =3D 32, csr_status =3D 40, csr_command =3D= 48, csr_intr =3D 56, csr_missed_frames =3D 64, csr_9 =3D 72, csr_10 =3D 80,=20 csr_11 =3D 88, csr_12 =3D 96, csr_13 =3D 104, csr_14 =3D 112, csr_15 =3D= 120}, tulip_flags =3D 172228608, tulip_features =3D 172303, tulip_intrmask =3D = 106858,=20 tulip_cmdmode =3D 33841186, tulip_last_system_error =3D 0, tulip_txtimer = =3D 0,=20 tulip_system_errors =3D 0, tulip_statusbits =3D 0, tulip_mediums =3D {0x0= ,=20 0xc133f25c, 0xc133f25c, 0x0, 0x0, 0x0, 0x0, 0xc133f25c, 0xc133f25c, 0x0,=20 0x0, 0x0}, tulip_media =3D TULIP_MEDIA_100BASETX, tulip_abilities =3D 8256,=20 tulip_revinfo =3D 34 '"', tulip_phyaddr =3D 3 '\003', tulip_gpinit =3D 31= '\037',=20 tulip_gpdata =3D 0 '\000', tulip_probe =3D {probe_count =3D 0 '\000',=20 probe_timeout =3D 3000, probe_state =3D TULIP_PROBE_INACTIVE,=20 probe_media =3D TULIP_MEDIA_100BASETX, probe_mediamask =3D 0,=20 probe_passes =3D 0, probe_txprobes =3D 0}, tulip_chipid =3D TULIP_21140A= ,=20 tulip_boardsw =3D 0xc022a084, tulip_slaves =3D 0x0, tulip_txq =3D { ifq_head =3D 0xc07f8900, ifq_tail =3D 0xc07cae00, ifq_len =3D 125,=20 ifq_maxlen =3D 128, ifq_drops =3D 0}, tulip_rxq =3D {ifq_head =3D 0xc0863000,=20 ifq_tail =3D 0xc086d400, ifq_len =3D 32, ifq_maxlen =3D 0, ifq_drops =3D= 0}, tulip_dot3stats =3D {dot3StatsSingleCollisionFrames =3D 30355,=20 dot3StatsMultipleCollisionFrames =3D 23777, dot3StatsSQETestErrors =3D 0,=20 dot3StatsDeferredTransmissions =3D 47096, dot3StatsLateCollisions =3D 0, dot3StatsExcessiveCollisions =3D 0, dot3StatsCarrierSenseErrors =3D 0,=20 dot3StatsInternalMacTransmitErrors =3D 1,=20 dot3StatsInternalTransmitUnderflows =3D 1,=20 dot3StatsInternalTransmitBabbles =3D 0, dot3StatsMissedFrames =3D 0,=20 dot3StatsAlignmentErrors =3D 0, dot3StatsFCSErrors =3D 0,=20 dot3StatsFrameTooLongs =3D 0, dot3StatsInternalMacReceiveErrors =3D 0},=20 tulip_rxinfo =3D {ri_first =3D 0xc1327400, ri_last =3D 0xc1327700,=20 ri_nextin =3D 0xc1327540, ri_nextout =3D 0xc1327440, ri_max =3D 48,=20 ri_free =3D 48}, tulip_txinfo =3D {ri_first =3D 0xc1340800,=20 ri_last =3D 0xc1341000, ri_nextin =3D 0xc1340bb0, ri_nextout =3D 0xc1340b90,=20 ri_max =3D 128, ri_free =3D 3}, tulip_mediainfo =3D {{ mi_type =3D TULIP_MEDIAINFO_MII, mi_un =3D {un_sia =3D { sia_connectivity =3D 390, sia_tx_rx =3D 0, sia_general =3D 30720,=20 sia_gp_control =3D 402673664, sia_gp_data =3D 16973824}, un_gpr =3D { gpr_cmdmode =3D 390, gpr_gpcontrol =3D 31488000, gpr_gpdata =3D 402673664,=20 gpr_actmask =3D 0 '\000', gpr_actdata =3D 0 '\000', gpr_default =3D 1},=20 un_mii =3D {mii_mediamask =3D 390, mii_capabilities =3D 30720,=20 mii_advertisement =3D 480, mii_full_duplex =3D 20480,=20 mii_tx_threshold =3D 6144, mii_interrupt =3D 0, mii_phyaddr =3D 3 '\003',=20 mii_gpr_length =3D 1 '\001', mii_gpr_offset =3D 38 '&',=20 mii_reset_length =3D 2 '\002', mii_reset_offset =3D 40 '(',=20 mii_phyid =3D 536894465}}}, {mi_type =3D TULIP_MEDIAINFO_NONE, mi_un =3D { un_sia =3D {sia_connectivity =3D 0, sia_tx_rx =3D 0, sia_general =3D 0,=20 sia_gp_control =3D 0, sia_gp_data =3D 0}, un_gpr =3D {gpr_cmdmode =3D 0,=20 gpr_gpcontrol =3D 0, gpr_gpdata =3D 0, gpr_actmask =3D 0 '\000',=20 gpr_actdata =3D 0 '\000', gpr_default =3D 0}, un_mii =3D { mii_mediamask =3D 0, mii_capabilities =3D 0, mii_advertisement =3D 0,=20 mii_full_duplex =3D 0, mii_tx_threshold =3D 0, mii_interrupt =3D 0,=20 mii_phyaddr =3D 0 '\000', mii_gpr_length =3D 0 '\000',=20 mii_gpr_offset =3D 0 '\000', mii_reset_length =3D 0 '\000',=20 mii_reset_offset =3D 0 '\000', mii_phyid =3D 0}}}, { mi_type =3D TULIP_MEDIAINFO_NONE, mi_un =3D {un_sia =3D {sia_connectivit= y =3D 0,=20 sia_tx_rx =3D 0, sia_general =3D 0, sia_gp_control =3D 0,=20 sia_gp_data =3D 0}, un_gpr =3D {gpr_cmdmode =3D 0, gpr_gpcontrol =3D 0,=20 gpr_gpdata =3D 0, gpr_actmask =3D 0 '\000', gpr_actdata =3D 0 '\000',=20 gpr_default =3D 0}, un_mii =3D {mii_mediamask =3D 0, mii_capabilities =3D= 0, mii_advertisement =3D 0, mii_full_duplex =3D 0, mii_tx_threshold =3D 0,=20 mii_interrupt =3D 0, mii_phyaddr =3D 0 '\000',=20 mii_gpr_length =3D 0 '\000', mii_gpr_offset =3D 0 '\000',=20 mii_reset_length =3D 0 '\000', mii_reset_offset =3D 0 '\000',=20 mii_phyid =3D 0}}}, {mi_type =3D TULIP_MEDIAINFO_NONE, mi_un =3D { un_sia =3D {sia_connectivity =3D 0, sia_tx_rx =3D 0, sia_general =3D 0,=20 sia_gp_control =3D 0, sia_gp_data =3D 0}, un_gpr =3D {gpr_cmdmode =3D 0,= =20 gpr_gpcontrol =3D 0, gpr_gpdata =3D 0, gpr_actmask =3D 0 '\000',=20 gpr_actdata =3D 0 '\000', gpr_default =3D 0}, un_mii =3D { mii_mediamask =3D 0, mii_capabilities =3D 0, mii_advertisement =3D 0,=20 mii_full_duplex =3D 0, mii_tx_threshold =3D 0, mii_interrupt =3D 0,=20 mii_phyaddr =3D 0 '\000', mii_gpr_length =3D 0 '\000',=20 mii_gpr_offset =3D 0 '\000', mii_reset_length =3D 0 '\000',=20 mii_reset_offset =3D 0 '\000', mii_phyid =3D 0}}}, { mi_type =3D TULIP_MEDIAINFO_NONE, mi_un =3D {un_sia =3D {sia_connectivit= y =3D 0,=20 sia_tx_rx =3D 0, sia_general =3D 0, sia_gp_control =3D 0,=20 sia_gp_data =3D 0}, un_gpr =3D {gpr_cmdmode =3D 0, gpr_gpcontrol =3D 0,=20 gpr_gpdata =3D 0, gpr_actmask =3D 0 '\000', gpr_actdata =3D 0 '\000',=20 gpr_default =3D 0}, un_mii =3D {mii_mediamask =3D 0, mii_capabilities =3D= 0, mii_advertisement =3D 0, mii_full_duplex =3D 0, mii_tx_threshold =3D 0,=20 mii_interrupt =3D 0, mii_phyaddr =3D 0 '\000',=20 mii_gpr_length =3D 0 '\000', mii_gpr_offset =3D 0 '\000',=20 mii_reset_length =3D 0 '\000', mii_reset_offset =3D 0 '\000',=20 mii_phyid =3D 0}}}, {mi_type =3D TULIP_MEDIAINFO_NONE, mi_un =3D { un_sia =3D {sia_connectivity =3D 0, sia_tx_rx =3D 0, sia_general =3D 0,=20 sia_gp_control =3D 0, sia_gp_data =3D 0}, un_gpr =3D {gpr_cmdmode =3D 0,= =20 gpr_gpcontrol =3D 0, gpr_gpdata =3D 0, gpr_actmask =3D 0 '\000',=20 gpr_actdata =3D 0 '\000', gpr_default =3D 0}, un_mii =3D { mii_mediamask =3D 0, mii_capabilities =3D 0, mii_advertisement =3D 0,=20 mii_full_duplex =3D 0, mii_tx_threshold =3D 0, mii_interrupt =3D 0,=20 mii_phyaddr =3D 0 '\000', mii_gpr_length =3D 0 '\000',=20 mii_gpr_offset =3D 0 '\000', mii_reset_length =3D 0 '\000',=20 mii_reset_offset =3D 0 '\000', mii_phyid =3D 0}}}, { mi_type =3D TULIP_MEDIAINFO_NONE, mi_un =3D {un_sia =3D {sia_connectivit= y =3D 0,=20 sia_tx_rx =3D 0, sia_general =3D 0, sia_gp_control =3D 0,=20 sia_gp_data =3D 0}, un_gpr =3D {gpr_cmdmode =3D 0, gpr_gpcontrol =3D 0,=20 gpr_gpdata =3D 0, gpr_actmask =3D 0 '\000', gpr_actdata =3D 0 '\000',=20 gpr_default =3D 0}, un_mii =3D {mii_mediamask =3D 0, mii_capabilities =3D= 0, mii_advertisement =3D 0, mii_full_duplex =3D 0, mii_tx_threshold =3D 0,=20 mii_interrupt =3D 0, mii_phyaddr =3D 0 '\000',=20 mii_gpr_length =3D 0 '\000', mii_gpr_offset =3D 0 '\000',=20 mii_reset_length =3D 0 '\000', mii_reset_offset =3D 0 '\000',=20 mii_phyid =3D 0}}}, {mi_type =3D TULIP_MEDIAINFO_NONE, mi_un =3D { un_sia =3D {sia_connectivity =3D 0, sia_tx_rx =3D 0, sia_general =3D 0,=20 sia_gp_control =3D 0, sia_gp_data =3D 0}, un_gpr =3D {gpr_cmdmode =3D 0,= =20 gpr_gpcontrol =3D 0, gpr_gpdata =3D 0, gpr_actmask =3D 0 '\000',=20 gpr_actdata =3D 0 '\000', gpr_default =3D 0}, un_mii =3D { mii_mediamask =3D 0, mii_capabilities =3D 0, mii_advertisement =3D 0,=20 mii_full_duplex =3D 0, mii_tx_threshold =3D 0, mii_interrupt =3D 0,=20 mii_phyaddr =3D 0 '\000', mii_gpr_length =3D 0 '\000',=20 mii_gpr_offset =3D 0 '\000', mii_reset_length =3D 0 '\000',=20 mii_reset_offset =3D 0 '\000', mii_phyid =3D 0}}}, { mi_type =3D TULIP_MEDIAINFO_NONE, mi_un =3D {un_sia =3D {sia_connectivit= y =3D 0,=20 sia_tx_rx =3D 0, sia_general =3D 0, sia_gp_control =3D 0,=20 sia_gp_data =3D 0}, un_gpr =3D {gpr_cmdmode =3D 0, gpr_gpcontrol =3D 0,=20 gpr_gpdata =3D 0, gpr_actmask =3D 0 '\000', gpr_actdata =3D 0 '\000',=20 gpr_default =3D 0}, un_mii =3D {mii_mediamask =3D 0, mii_capabilities =3D= 0, mii_advertisement =3D 0, mii_full_duplex =3D 0, mii_tx_threshold =3D 0,=20 mii_interrupt =3D 0, mii_phyaddr =3D 0 '\000',=20 mii_gpr_length =3D 0 '\000', mii_gpr_offset =3D 0 '\000',=20 mii_reset_length =3D 0 '\000', mii_reset_offset =3D 0 '\000',=20 mii_phyid =3D 0}}}, {mi_type =3D TULIP_MEDIAINFO_NONE, mi_un =3D { un_sia =3D {sia_connectivity =3D 0, sia_tx_rx =3D 0, sia_general =3D 0,=20 sia_gp_control =3D 0, sia_gp_data =3D 0}, un_gpr =3D {gpr_cmdmode =3D 0,= =20 gpr_gpcontrol =3D 0, gpr_gpdata =3D 0, gpr_actmask =3D 0 '\000',=20 gpr_actdata =3D 0 '\000', gpr_default =3D 0}, un_mii =3D { mii_mediamask =3D 0, mii_capabilities =3D 0, mii_advertisement =3D 0,=20 mii_full_duplex =3D 0, mii_tx_threshold =3D 0, mii_interrupt =3D 0,=20 mii_phyaddr =3D 0 '\000', mii_gpr_length =3D 0 '\000',=20 mii_gpr_offset =3D 0 '\000', mii_reset_length =3D 0 '\000',=20 mii_reset_offset =3D 0 '\000', mii_phyid =3D 0}}}}, tulip_setupbuf =3D {= 1, 94, 256, 65535, 65535, 65535, 57344, 15401, 31712, 57344, 15401, 31712,=20 57344, 15401, 31712, 57344, 15401, 31712, 57344, 15401, 31712, 57344,=20 15401, 31712, 57344, 15401, 31712, 57344, 15401, 31712, 57344, 15401,=20 31712, 57344, 15401, 31712, 57344, 15401, 31712, 57344, 15401, 31712,=20 57344, 15401, 31712, 57344, 15401, 31712}, tulip_setupdata =3D {1, 94, 256,=20 65535, 65535, 65535, 57344, 15401, 31712, 57344, 15401, 31712, 57344,=20 15401, 31712, 57344, 15401, 31712, 57344, 15401, 31712, 57344, 15401,=20 31712, 57344, 15401, 31712, 57344, 15401, 31712, 57344, 15401, 31712,=20 57344, 15401, 31712, 57344, 15401, 31712, 57344, 15401, 31712, 57344,=20 15401, 31712, 57344, 15401, 31712},=20 tulip_boardid =3D "SMC 9332BDT \000\000\000",=20 tulip_rombuf =3D "=B8\020\003 ", '\000' , "\234\000\003\001\000=E0)<=E0{\000\036\000\000\000\b\037\001\217\001\000\= 001\000 \002\001\000\000x=E0\001\000P\000\030", '\000' , "\b=C6= ", tulip_pci_busno =3D 2 '\002',=20 tulip_pci_devno =3D 5 '\005', tulip_connidx =3D 16 '\020',=20 tulip_conntype =3D TULIP_SROM_CONNTYPE_AUTOSENSE, tulip_rxdescs =3D 0xc13= 27400,=20 tulip_txdescs =3D 0xc1340800} (kgdb) print m $6 =3D (struct mbuf *) 0x0 (kgdb) quit ------_=_NextPart_001_01C172A7.AB0AF914 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable kernel backtrace for kern/28844

We had to wait 10 days for the next = kernel crash to happily collect our crash dump (people who were using = the system at that moment to route their remote maintance job were not = so happy...).

It appears that the argument m to = m_freem() is corrupt, but the value of m in the context of the caller = is 0. This could mean we have corrupted stack, or maybe I simply don't = understand gdb (I never used it before). As the contents of sc show, = the code was handling interface de1 at the moment of the = crash.

If you need more information, please = let me know.
Greetings,
Rudi Mathijssen

# gdb -k
GNU gdb 4.18
Copyright 1998 Free Software = Foundation, Inc.
GDB is free software, covered by the = GNU General Public License, and you are
welcome to change it and/or = distribute copies of it under certain conditions.
Type "show copying" to see the = conditions.
There is absolutely no warranty for = GDB.  Type "show warranty" for details.
This GDB was configured as = "i386-unknown-freebsd".
(kgdb) symbol kernel.debug
Reading symbols from = kernel.debug...done.
(kgdb) exec = /var/crash/kernel.2
(kgdb) core = /var/crash/vmcore.2
IdlePTD 2965504
initial pcb at 263de0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in = kernel mode
fault virtual address   =3D = 0x79c02812
fault = code      =         =3D supervisor read, page = not present
instruction = pointer     =3D 0x8:0xc0164da8
stack pointer   =         =3D 0x10:0xc0244440
frame pointer   =         =3D 0x10:0xc024444c
code segment    =         =3D base 0x0, limit 0xfffff, = type 0x1b
        =         =         =3D DPL 0, pres 1, def32 1, gran 1
processor = eflags        =3D interrupt enabled, = resume, IOPL =3D 0
current process =         =3D Idle
interrupt mask  =         =3D net
trap number     =         =3D 12
panic: page fault
syncing disks...
done
Uptime: 10d10h58m20s

dumping to dev #da/0x20001, offset = 1737856
dump 128 127 126 125 124 123 122 121 = 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 = 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 = 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 = 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 = 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 = 6 5 4 3 2 1

---
#0  dumpsys () at = ../../kern/kern_shutdown.c:469
469     =         if (dumping++) {
(kgdb) where
#0  dumpsys () at = ../../kern/kern_shutdown.c:469
#1  0xc014ab7f in boot (howto%6) = at ../../kern/kern_shutdown.c:309
#2  0xc014aefc in poweroff_wait = (junk=3D0xc023c0cf, howto=3D0)

      at = ../../kern/kern_shutdown.c:556

#3  0xc02060e5 in trap_fatal = (frame=3D0xc0244400, eva 42636306)

      at ../../i386/i386/trap.c:951

#4  0xc0205dbd in trap_pfault = (frame=3D0xc0244400, usermode=3D0, eva 42636306)

      at ../../i386/i386/trap.c:844

#5  0xc02059a3 in trap = (frame=3D{tf_fs =3D 16, tf_es =3D 16, tf_ds =3D -2147483632,

    tf_edi =3D 6717472, tf_esi =3D = -1064284928, tf_ebp =3D -1071365044,
    tf_isp =3D -1071365076, tf_ebx =3D = 2042636288, tf_edx =3D 0,
    tf_ecx =3D -1066018816, tf_eax =3D = -6717473, tf_trapno =3D 12, tf_err =3D 0,
    tf_eip =3D -1072280152, tf_cs =3D 8, = tf_eflags =3D 66054,
    tf_esp =3D -1053560832, tf_ss =3D = 2147430528}) at ../../i386/i386/trap.c:443

#6  0xc0164da8 in m_freem = (m=3D0xc0904d00) at ../../kern/uipc_mbuf.c:525
#7  0xc01a54b5 in tulip_tx_intr = (sc=3D0xc133f000) at ../../pci/if_de.c:3715
#8  0xc01a5cf1 in tulip_txput = (sc=3D0xc133f000, m=3D0xc08d2100)

    at ../../pci/if_de.c:4299

#9  0xc01a6421 in = tulip_ifstart_one (ifp=3D0xc133f018) at ../../pci/if_de.c:4740
#10 0xc018bc1c in ether_output_frame = (ifp=3D0xc133f018, m=3D0xc08d2100)

      at ../../net/if_ethersubr.c:401

#11 0xc018bb8a in ether_output = (ifp=3D0xc133f018, m=3D0xc08d2100, dst=3D0xc02650d4,

      rt0=3D0xc142b000) at = ../../net/if_ethersubr.c:354

#12 0xc019856f in ip_output = (m0=3D0xc0765400, opt=3D0x0, ro=3D0xc02650d0, flags=3D1,

      imo=3D0x0) at = ../../netinet/ip_output.c:787

#13 0xc0197d04 in ip_forward = (m=3D0xc0765400, srcrt=3D0)

      at = ../../netinet/ip_input.c:1552

#14 0xc0196f0e in ip_input = (m=3D0xc0765400) at ../../netinet/ip_input.c:563
#15 0xc019713f in ipintr () at = ../../netinet/ip_input.c:759
#16 0xc01fc675 in swi_net_next = ()
(kgdb) up 6
#6  0xc0164da8 in m_freem = (m=3D0xc0904d00) at ../../kern/uipc_mbuf.c:525
525     =         if (m =3D=3D NULL)
(kgdb) print m
$1 =3D (struct mbuf *) = 0x668020
(kgdb) print *m
cannot read proc at 0
(kgdb) up 1
#7  0xc01a54b5 in tulip_tx_intr = (sc=3D0xc133f000) at ../../pci/if_de.c:3715
3715    =         =             = m_freem(m);
(kgdb) print m
$2 =3D (struct mbuf *) 0x0
(kgdb) echo print sc
$4 =3D (tulip_softc_t *) = 0xc133f000
(kgdb) print *sc
$5 =3D {tulip_ifmedia =3D {ifm_mask = =3D 0, ifm_media =3D 0, ifm_cur =3D 0xc071c600,

    ifm_list =3D {lh_first =3D = 0xc071c600},
    ifm_change =3D 0xc01a46f4 = <tulip_ifmedia_change>,
    ifm_status =3D 0xc01a4774 = <tulip_ifmedia_status>}, tulip_ac =3D {ac_if =3D {
    if_softc =3D 0xc133f000, if_name =3D = 0xc022a53d "de", if_link =3D {

      tqe_next =3D 0xc1340018, tqe_prev =3D = 0xc071b020}, if_addrhead =3D {
      tqh_first =3D 0xc132c700, tqh_last = =3D 0xc1423f10}, if_pcount =3D 0,

    if_bpf =3D 0x0, if_index =3D 2, = if_unit =3D 1, if_timer =3D 1,
    if_flags =3D -30653, if_ipending =3D = 0, if_linkmib =3D 0x0, if_linkmiblen =3D 0,
    if_data =3D {ifi_type =3D 6 '\006', = ifi_physical =3D 0 '\000',

      ifi_addrlen =3D 6 '\006', ifi_hdrlen = =3D 14 '\016',
      ifi_recvquota =3D 0 '\000', = ifi_xmitquota =3D 0 '\000', ifi_mtu =3D 1500,
      ifi_metric =3D 0, ifi_baudrate =3D = 100000000, ifi_ipackets =3D 13710740,
      ifi_ierrors =3D 0, ifi_opackets =3D = 13455672, ifi_oerrors =3D 1,
      ifi_collisions =3D 84737, ifi_ibytes = =3D 2233673408,
      ifi_obytes =3D 1905899332, = ifi_imcasts =3D 119437, ifi_omcasts =3D 0,
      ifi_iqdrops =3D 0, ifi_noproto =3D 0, = ifi_hwassist =3D 0, ifi_unused =3D 0,
      ifi_lastchange =3D {tv_sec =3D 0, = tv_usec =3D 0}}, if_multiaddrs =3D {
      lh_first =3D 0xc13485c0}, if_amcount = =3D 0,

    if_output =3D 0xc018b878 = <ether_output>,
    if_start =3D 0xc01a63d4 = <tulip_ifstart_one>, if_done =3D 0,
    if_ioctl =3D 0xc01a61cc = <tulip_ifioctl>,
    if_watchdog =3D 0xc01a6450 = <tulip_ifwatchdog>, if_poll_recv =3D 0,
    if_poll_xmit =3D 0, if_poll_intren = =3D 0, if_poll_slowinput =3D 0,
    if_init =3D 0, if_resolvemulti =3D = 0xc018bf4c <ether_resolvemulti>,
    if_snd =3D {ifq_head =3D 0x0, = ifq_tail =3D 0x0, ifq_len =3D 0, ifq_maxlen =3D 50,

      ifq_drops =3D 0}, if_poll_slowq =3D = 0x0, if_prefixhead =3D {tqh_first =3D 0x0,
      tqh_last =3D 0xc133f0e8}}, ac_enaddr = =3D "\000=E0)<=E0{", ac_multicnt =3D 0,

    ac_netgraph =3D 0x0}, tulip_csrs_bst = =3D 0, tulip_csrs_bsh =3D 12416,

tulip_csrs =3D {csr_busmode =3D 0, = csr_txpoll =3D 8, csr_rxpoll =3D 16,

    csr_rxlist =3D 24, csr_txlist =3D 32, = csr_status =3D 40, csr_command =3D 48,
    csr_intr =3D 56, csr_missed_frames = =3D 64, csr_9 =3D 72, csr_10 =3D 80,
    csr_11 =3D 88, csr_12 =3D 96, csr_13 = =3D 104, csr_14 =3D 112, csr_15 =3D 120},

tulip_flags =3D 172228608, = tulip_features =3D 172303, tulip_intrmask =3D 106858,
tulip_cmdmode =3D 33841186, = tulip_last_system_error =3D 0, tulip_txtimer =3D 0,
tulip_system_errors =3D 0, = tulip_statusbits =3D 0, tulip_mediums =3D {0x0,

    0xc133f25c, 0xc133f25c, 0x0, 0x0, 0x0, = 0x0, 0xc133f25c, 0xc133f25c, 0x0,
    0x0, 0x0}, tulip_media =3D = TULIP_MEDIA_100BASETX, tulip_abilities =3D 8256,

tulip_revinfo =3D 34 '"', = tulip_phyaddr =3D 3 '\003', tulip_gpinit =3D 31 '\037',
tulip_gpdata =3D 0 '\000', = tulip_probe =3D {probe_count =3D 0 '\000',

    probe_timeout =3D 3000, probe_state = =3D TULIP_PROBE_INACTIVE,
    probe_media =3D = TULIP_MEDIA_100BASETX, probe_mediamask =3D 0,
    probe_passes =3D 0, probe_txprobes = =3D 0}, tulip_chipid =3D TULIP_21140A,

tulip_boardsw =3D 0xc022a084, = tulip_slaves =3D 0x0, tulip_txq =3D {

    ifq_head =3D 0xc07f8900, ifq_tail =3D = 0xc07cae00, ifq_len =3D 125,
    ifq_maxlen =3D 128, ifq_drops =3D 0}, = tulip_rxq =3D {ifq_head =3D 0xc0863000,
    ifq_tail =3D 0xc086d400, ifq_len =3D = 32, ifq_maxlen =3D 0, ifq_drops =3D 0},

tulip_dot3stats =3D = {dot3StatsSingleCollisionFrames =3D 30355,

    dot3StatsMultipleCollisionFrames =3D = 23777, dot3StatsSQETestErrors =3D 0,
    dot3StatsDeferredTransmissions =3D = 47096, dot3StatsLateCollisions =3D 0,
    dot3StatsExcessiveCollisions =3D 0, = dot3StatsCarrierSenseErrors =3D 0,
    dot3StatsInternalMacTransmitErrors = =3D 1,
    dot3StatsInternalTransmitUnderflows = =3D 1,
    dot3StatsInternalTransmitBabbles =3D = 0, dot3StatsMissedFrames =3D 0,
    dot3StatsAlignmentErrors =3D 0, = dot3StatsFCSErrors =3D 0,
    dot3StatsFrameTooLongs =3D 0, = dot3StatsInternalMacReceiveErrors =3D 0},

tulip_rxinfo =3D {ri_first =3D = 0xc1327400, ri_last =3D 0xc1327700,

    ri_nextin =3D 0xc1327540, ri_nextout = =3D 0xc1327440, ri_max =3D 48,
    ri_free =3D 48}, tulip_txinfo =3D = {ri_first =3D 0xc1340800,
    ri_last =3D 0xc1341000, ri_nextin =3D = 0xc1340bb0, ri_nextout =3D 0xc1340b90,
    ri_max =3D 128, ri_free =3D 3}, = tulip_mediainfo =3D {{
    mi_type =3D TULIP_MEDIAINFO_MII, = mi_un =3D {un_sia =3D {

      sia_connectivity =3D 390, sia_tx_rx = =3D 0, sia_general =3D 30720,
      sia_gp_control =3D 402673664, = sia_gp_data =3D 16973824}, un_gpr =3D {
      gpr_cmdmode =3D 390, gpr_gpcontrol = =3D 31488000, gpr_gpdata =3D 402673664,
      gpr_actmask =3D 0 '\000', gpr_actdata = =3D 0 '\000', gpr_default =3D 1},
      un_mii =3D {mii_mediamask =3D 390, = mii_capabilities =3D 30720,
      mii_advertisement =3D 480, = mii_full_duplex =3D 20480,
      mii_tx_threshold =3D 6144, = mii_interrupt =3D 0, mii_phyaddr =3D 3 '\003',
      mii_gpr_length =3D 1 '\001', = mii_gpr_offset =3D 38 '&',
      mii_reset_length =3D 2 '\002', = mii_reset_offset =3D 40 '(',
      mii_phyid =3D 536894465}}}, {mi_type = =3D TULIP_MEDIAINFO_NONE, mi_un =3D {
      un_sia =3D {sia_connectivity =3D 0, = sia_tx_rx =3D 0, sia_general =3D 0,
      sia_gp_control =3D 0, sia_gp_data =3D = 0}, un_gpr =3D {gpr_cmdmode =3D 0,
      gpr_gpcontrol =3D 0, gpr_gpdata =3D = 0, gpr_actmask =3D 0 '\000',
      gpr_actdata =3D 0 '\000', gpr_default = =3D 0}, un_mii =3D {
      mii_mediamask =3D 0, mii_capabilities = =3D 0, mii_advertisement =3D 0,
      mii_full_duplex =3D 0, = mii_tx_threshold =3D 0, mii_interrupt =3D 0,
      mii_phyaddr =3D 0 '\000', = mii_gpr_length =3D 0 '\000',
      mii_gpr_offset =3D 0 '\000', = mii_reset_length =3D 0 '\000',
      mii_reset_offset =3D 0 '\000', = mii_phyid =3D 0}}}, {

    mi_type =3D TULIP_MEDIAINFO_NONE, = mi_un =3D {un_sia =3D {sia_connectivity =3D 0,
    sia_tx_rx =3D 0, sia_general =3D 0, = sia_gp_control =3D 0,
    sia_gp_data =3D 0}, un_gpr =3D = {gpr_cmdmode =3D 0, gpr_gpcontrol =3D 0,
    gpr_gpdata =3D 0, gpr_actmask =3D 0 = '\000', gpr_actdata =3D 0 '\000',
    gpr_default =3D 0}, un_mii =3D = {mii_mediamask =3D 0, mii_capabilities =3D 0,
    mii_advertisement =3D 0, = mii_full_duplex =3D 0, mii_tx_threshold =3D 0,
    mii_interrupt =3D 0, mii_phyaddr =3D = 0 '\000',
    mii_gpr_length =3D 0 '\000', = mii_gpr_offset =3D 0 '\000',
    mii_reset_length =3D 0 '\000', = mii_reset_offset =3D 0 '\000',
    mii_phyid =3D 0}}}, {mi_type =3D = TULIP_MEDIAINFO_NONE, mi_un =3D {
    un_sia =3D {sia_connectivity =3D 0, = sia_tx_rx =3D 0, sia_general =3D 0,
    sia_gp_control =3D 0, sia_gp_data =3D = 0}, un_gpr =3D {gpr_cmdmode =3D 0,
    gpr_gpcontrol =3D 0, gpr_gpdata =3D = 0, gpr_actmask =3D 0 '\000',
    gpr_actdata =3D 0 '\000', gpr_default = =3D 0}, un_mii =3D {
    mii_mediamask =3D 0, mii_capabilities = =3D 0, mii_advertisement =3D 0,
    mii_full_duplex =3D 0, = mii_tx_threshold =3D 0, mii_interrupt =3D 0,
    mii_phyaddr =3D 0 '\000', = mii_gpr_length =3D 0 '\000',
    mii_gpr_offset =3D 0 '\000', = mii_reset_length =3D 0 '\000',
    mii_reset_offset =3D 0 '\000', = mii_phyid =3D 0}}}, {
    mi_type =3D TULIP_MEDIAINFO_NONE, = mi_un =3D {un_sia =3D {sia_connectivity =3D 0,
    sia_tx_rx =3D 0, sia_general =3D 0, = sia_gp_control =3D 0,
    sia_gp_data =3D 0}, un_gpr =3D = {gpr_cmdmode =3D 0, gpr_gpcontrol =3D 0,
    gpr_gpdata =3D 0, gpr_actmask =3D 0 = '\000', gpr_actdata =3D 0 '\000',
    gpr_default =3D 0}, un_mii =3D = {mii_mediamask =3D 0, mii_capabilities =3D 0,
    mii_advertisement =3D 0, = mii_full_duplex =3D 0, mii_tx_threshold =3D 0,
    mii_interrupt =3D 0, mii_phyaddr =3D = 0 '\000',
    mii_gpr_length =3D 0 '\000', = mii_gpr_offset =3D 0 '\000',
    mii_reset_length =3D 0 '\000', = mii_reset_offset =3D 0 '\000',
    mii_phyid =3D 0}}}, {mi_type =3D = TULIP_MEDIAINFO_NONE, mi_un =3D {
    un_sia =3D {sia_connectivity =3D 0, = sia_tx_rx =3D 0, sia_general =3D 0,
    sia_gp_control =3D 0, sia_gp_data =3D = 0}, un_gpr =3D {gpr_cmdmode =3D 0,
    gpr_gpcontrol =3D 0, gpr_gpdata =3D = 0, gpr_actmask =3D 0 '\000',
    gpr_actdata =3D 0 '\000', gpr_default = =3D 0}, un_mii =3D {
    mii_mediamask =3D 0, mii_capabilities = =3D 0, mii_advertisement =3D 0,
    mii_full_duplex =3D 0, = mii_tx_threshold =3D 0, mii_interrupt =3D 0,
    mii_phyaddr =3D 0 '\000', = mii_gpr_length =3D 0 '\000',
    mii_gpr_offset =3D 0 '\000', = mii_reset_length =3D 0 '\000',
    mii_reset_offset =3D 0 '\000', = mii_phyid =3D 0}}}, {
    mi_type =3D TULIP_MEDIAINFO_NONE, = mi_un =3D {un_sia =3D {sia_connectivity =3D 0,
    sia_tx_rx =3D 0, sia_general =3D 0, = sia_gp_control =3D 0,
    sia_gp_data =3D 0}, un_gpr =3D = {gpr_cmdmode =3D 0, gpr_gpcontrol =3D 0,
    gpr_gpdata =3D 0, gpr_actmask =3D 0 = '\000', gpr_actdata =3D 0 '\000',
    gpr_default =3D 0}, un_mii =3D = {mii_mediamask =3D 0, mii_capabilities =3D 0,
    mii_advertisement =3D 0, = mii_full_duplex =3D 0, mii_tx_threshold =3D 0,
    mii_interrupt =3D 0, mii_phyaddr =3D = 0 '\000',
    mii_gpr_length =3D 0 '\000', = mii_gpr_offset =3D 0 '\000',
    mii_reset_length =3D 0 '\000', = mii_reset_offset =3D 0 '\000',
    mii_phyid =3D 0}}}, {mi_type =3D = TULIP_MEDIAINFO_NONE, mi_un =3D {
    un_sia =3D {sia_connectivity =3D 0, = sia_tx_rx =3D 0, sia_general =3D 0,
    sia_gp_control =3D 0, sia_gp_data =3D = 0}, un_gpr =3D {gpr_cmdmode =3D 0,
    gpr_gpcontrol =3D 0, gpr_gpdata =3D = 0, gpr_actmask =3D 0 '\000',
    gpr_actdata =3D 0 '\000', gpr_default = =3D 0}, un_mii =3D {
    mii_mediamask =3D 0, mii_capabilities = =3D 0, mii_advertisement =3D 0,
    mii_full_duplex =3D 0, = mii_tx_threshold =3D 0, mii_interrupt =3D 0,
    mii_phyaddr =3D 0 '\000', = mii_gpr_length =3D 0 '\000',
    mii_gpr_offset =3D 0 '\000', = mii_reset_length =3D 0 '\000',
    mii_reset_offset =3D 0 '\000', = mii_phyid =3D 0}}}, {
    mi_type =3D TULIP_MEDIAINFO_NONE, = mi_un =3D {un_sia =3D {sia_connectivity =3D 0,
    sia_tx_rx =3D 0, sia_general =3D 0, = sia_gp_control =3D 0,
    sia_gp_data =3D 0}, un_gpr =3D = {gpr_cmdmode =3D 0, gpr_gpcontrol =3D 0,
    gpr_gpdata =3D 0, gpr_actmask =3D 0 = '\000', gpr_actdata =3D 0 '\000',
    gpr_default =3D 0}, un_mii =3D = {mii_mediamask =3D 0, mii_capabilities =3D 0,
    mii_advertisement =3D 0, = mii_full_duplex =3D 0, mii_tx_threshold =3D 0,
    mii_interrupt =3D 0, mii_phyaddr =3D = 0 '\000',
    mii_gpr_length =3D 0 '\000', = mii_gpr_offset =3D 0 '\000',
    mii_reset_length =3D 0 '\000', = mii_reset_offset =3D 0 '\000',
    mii_phyid =3D 0}}}, {mi_type =3D = TULIP_MEDIAINFO_NONE, mi_un =3D {
    un_sia =3D {sia_connectivity =3D 0, = sia_tx_rx =3D 0, sia_general =3D 0,
    sia_gp_control =3D 0, sia_gp_data =3D = 0}, un_gpr =3D {gpr_cmdmode =3D 0,
    gpr_gpcontrol =3D 0, gpr_gpdata =3D = 0, gpr_actmask =3D 0 '\000',
    gpr_actdata =3D 0 '\000', gpr_default = =3D 0}, un_mii =3D {
    mii_mediamask =3D 0, mii_capabilities = =3D 0, mii_advertisement =3D 0,
    mii_full_duplex =3D 0, = mii_tx_threshold =3D 0, mii_interrupt =3D 0,
    mii_phyaddr =3D 0 '\000', = mii_gpr_length =3D 0 '\000',
    mii_gpr_offset =3D 0 '\000', = mii_reset_length =3D 0 '\000',
    mii_reset_offset =3D 0 '\000', = mii_phyid =3D 0}}}}, tulip_setupbuf =3D {1,
    94, 256, 65535, 65535, 65535, 57344, = 15401, 31712, 57344, 15401, 31712,
    57344, 15401, 31712, 57344, 15401, = 31712, 57344, 15401, 31712, 57344,
    15401, 31712, 57344, 15401, 31712, = 57344, 15401, 31712, 57344, 15401,
    31712, 57344, 15401, 31712, 57344, = 15401, 31712, 57344, 15401, 31712,
    57344, 15401, 31712, 57344, 15401, = 31712}, tulip_setupdata =3D {1, 94, 256,
    65535, 65535, 65535, 57344, 15401, = 31712, 57344, 15401, 31712, 57344,
    15401, 31712, 57344, 15401, 31712, = 57344, 15401, 31712, 57344, 15401,
    31712, 57344, 15401, 31712, 57344, = 15401, 31712, 57344, 15401, 31712,
    57344, 15401, 31712, 57344, 15401, = 31712, 57344, 15401, 31712, 57344,
    15401, 31712, 57344, 15401, 31712}, =

tulip_boardid =3D "SMC 9332BDT = \000\000\000",
tulip_rombuf =3D "=B8\020\003 ", = '\000' <repeats 12 times>, = "\234\000\003\001\000=E0)<=E0{\000\036\000\000\000\b\037\001\217\001\= 000\001\000\002\001\000\000x=E0\001\000P\000\030", '\000' <repeats = 76 times>, "\b=C6", tulip_pci_busno =3D 2 '\002',

tulip_pci_devno =3D 5 '\005', = tulip_connidx =3D 16 '\020',
tulip_conntype =3D = TULIP_SROM_CONNTYPE_AUTOSENSE, tulip_rxdescs =3D 0xc1327400,
tulip_txdescs =3D 0xc1340800}
(kgdb) print m
$6 =3D (struct mbuf *) 0x0
(kgdb) quit

------_=_NextPart_001_01C172A7.AB0AF914-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 8:39:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id BC01C37B418 for ; Wed, 21 Nov 2001 08:39:23 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id fALGbQX69784; Wed, 21 Nov 2001 10:37:26 -0600 (CST) (envelope-from jlemon) Date: Wed, 21 Nov 2001 10:37:26 -0600 (CST) From: Jonathan Lemon Message-Id: <200111211637.fALGbQX69784@prism.flugsvamp.com> To: rizzo@aciri.org, net@freebsd.org Subject: Re: Garbage tacked onto end of packet X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article you write: >[Bcc to Przemyslaw Frasunek who submitted the example in case >he can tell what hardware was involved] > >On Wed, Nov 21, 2001 at 02:36:56PM +0100, Dag-Erling Smorgrav wrote: >> http://lcamtuf.coredump.cx/mobp/ >> >> See Exhibit 5. Is this a known bug? > >Looks more like one or more bugs in a specific device driver, tcpdump or bpf. > >Here we have a short IP packet (44 bytes) which is later shown as having >46 and then 64 bytes. > >On the wire, ethernet frames are supposed to have at least 64 bytes (including >CRC ?) which is exactly 14+46+4 -- so the second example makes perfect sense, >it is the only legal format of such a frame coming from an ethernet interface. > >As for the third one, it might well be that some device driver misinterprets >the padding (possibly on the output side) and tries to generate 64-bytes >in addition to the headers. Yup. My guess is the first (short) packet was captured on the originating host, so bpf saw it before it hit the wire. The driver should have padded the packet out to 64 bytes on transmission, and the second hop sees the correct (64 - 14 - 4 = 46 byte) payload. I'm not sure what the third system is doing; it looks like it is returning the total packet length, unadjusted for the ethernet headers, which would be a driver bug. However, this is harmless in this case, since the system is using the length from the IP header, not the mbuf length. It isn't clear if the third system is even a FreeBSD box. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 8:45:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from fe040.worldonline.dk (fe040.worldonline.dk [212.54.64.205]) by hub.freebsd.org (Postfix) with SMTP id DBD5F37B416 for ; Wed, 21 Nov 2001 08:45:17 -0800 (PST) Received: (qmail 18193 invoked by uid 0); 21 Nov 2001 16:45:15 -0000 Received: from 213.237.14.128.adsl.ho.worldonline.dk (HELO denniswork) (213.237.14.128) by fe040.worldonline.dk with SMTP; 21 Nov 2001 16:45:15 -0000 Message-ID: <046101c172ab$ecb280e0$0301a8c0@denniswork> From: "Dennis" To: Subject: Routing problems Date: Wed, 21 Nov 2001 17:45:27 +0100 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi! First off all i have read all the posting from 2001 that might regard my problem but did'nt find anything at all :( I'm having some big problems with routing on my FreeBSD 4.4 box (or atleast i think its the routing..) The setup is like this : The firm has 2 different type of nets (the old HP VGANY lan and plain fast ethernet) and each net has its own /24. On fast ethernet the ip is 192.168.1.0/24 and this net works just fine everutime. But the other net is way more strange, it has the ip area 192.168.10.0/24 and this only works if i flush my firewall rules :( The FreeBSD box has 2 nic's, one for the internal nets and one for thier adsl connection, the internal nic has ip 192.168.1.1. And in the rc.conf i have a route add statement and a nic_alias cmd in order for both nets to access til internet. But what have i missed in the firewall script file because the second net does NOT have access to the internet until i flush my rules :( Any good ideas? Regards Dennnis rc.conf: ifconfig_ep0="inet 192.168.1.1 netmask 255.255.255.0" ifconfig_ep1="inet 192.168.2.10 netmask 255.255.255.0" hostname="jr-data.dk" linux_enable="NO" gateway_enable="YES" defaultrouter="192.168.2.88" router_flags="-q" router="routed" router_enable="YES" firewall_enable="YES" firewall_script="/etc/firewall" sendmail_enable="NO" inetd_enable="NO" route add 192.168.10.0 192.168.1.100 saver="blank" font8x8="cp850-8x8" font8x14="cp850-8x14" font8x16="cp850-8x16" scrnmap="NO" keyrate="fast" keymap="danish.cp865" /etc/firewall /sbin/natd -interface ep1 fwcmd="/sbin/ipfw" inet="192.168.1.0" inet1="192.168.10.0" imask="255.255.255.0" iip="192.168.1.1" #From this computer an on to the net $fwcmd add 100 pass all from ${iip} to ${inet}:${imask} $fwcmd add 110 pass all from ${inet}:${imask} to ${iip} $fwcmd add 120 pass all from ${oip} to ${onet}:${omask} $fwcmd add 130 pass all from ${onet}:${omask} to ${oip} $fwcmd add 140 pass all from ${iip} to ${inet1}:${imask} $fwcmd add 170 pass all from ${inet1}:${imask} to ${iip} #Hvis der er en forbindelse maa denne bruges $fwcmd add 200 skipto 1000 tcp from any to any established #Tillader forbindelse paa de specificerede porte $fwcmd add 300 skipto 1000 tcp from ${inet}:${imask} to any 23 setup $fwcmd add 310 skipto 1000 tcp from ${inet}:${imask} to any 53 setup $fwcmd add 320 skipto 1000 tcp from ${inet}:${imask} to any 80 setup $fwcmd add 330 skipto 1000 tcp from ${inet}:${imask} to any 25 setup $fwcmd add 340 skipto 1000 tcp from ${inet}:${imask} to any 110 setup $fwcmd add 342 skipto 1000 tcp from any 20 to any 30000-63000 setup $fwcmd add 344 skipto 1000 tcp from any 20 to any 1024-4096 setup $fwcmd add 350 skipto 1000 tcp from ${inet}:${imask} to any 20 setup $fwcmd add 360 skipto 1000 tcp from ${inet}:${imask} to any 21 setup $fwcmd add 370 skipto 1000 tcp from ${inet}:${imask} to any 119 setup $fwcmd add 380 skipto 1000 tcp from ${inet}:${imask} to any 443 setup $fwcmd add 392 skipto 1000 tcp from ${inet}:${imask} to any 1433 setup $fwcmd add 390 skipto 1000 tcp from any to any 3389 setup $fwcmd add 301 skipto 1000 tcp from ${inet1}:${imask} to any 23 setup $fwcmd add 311 skipto 1000 tcp from ${inet1}:${imask} to any 53 setup $fwcmd add 321 skipto 1000 tcp from ${inet1}:${imask} to any 80 setup $fwcmd add 331 skipto 1000 tcp from ${inet1}:${imask} to any 25 setup $fwcmd add 341 skipto 1000 tcp from ${inet1}:${imask} to any 110 setup $fwcmd add 351 skipto 1000 tcp from ${inet1}:${imask} to any 20 setup $fwcmd add 361 skipto 1000 tcp from ${inet1}:${imask} to any 21 setup $fwcmd add 371 skipto 1000 tcp from ${inet1}:${imask} to any 119 setup $fwcmd add 381 skipto 1000 tcp from ${inet1}:${imask} to any 443 setup $fwcmd add 394 skipto 1000 tcp from ${inet1}:${imask} to any 1433 setup #UDP trafik $fwcmd add 400 skipto 1000 udp from any 53 to any $fwcmd add 410 skipto 1000 udp from any to any 53 $fwcmd add 485 skipto 1000 udp from any to any 119 $fwcmd add 486 skipto 1000 udp from any 119 to any $fwcmd add 487 skipto 1000 udp from any to any 443 $fwcmd add 488 skipto 1000 udp from any 443 to any $fwcmd add 490 skipto 1000 udp from any 3389 to any $fwcmd add 495 skipto 1000 udp from any to any 3389 $fwcmd add 498 skipto 1000 udp from any 1433 to any $fwcmd add 499 skipto 1000 udp from any to any 1433 #icmp $fwcmd add 500 skipto 1000 icmp from any to any #Terminalserver $fwcmd add 600 allow tcp from any to 192.168.1.5 setup $fwcmd add 601 allow tcp from 192.168.1.5 to any setup #Stop alt som ikke er skippet til regel 1000 $fwcmd add 900 deny all from any to any #NAT det som er tilladt af tidligere regler. $fwcmd add 1000 divert natd all from any to any via ep1 $fwcmd add 1100 pass all from any to any To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 9:37:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f109.law3.hotmail.com [209.185.241.109]) by hub.freebsd.org (Postfix) with ESMTP id DFFF937B418 for ; Wed, 21 Nov 2001 09:37:25 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Nov 2001 09:37:25 -0800 Received: from 193.216.47.156 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 21 Nov 2001 17:37:25 GMT X-Originating-IP: [193.216.47.156] From: "Thor Legvold" To: joao@bowtie.nl Cc: freebsd-net@freebsd.org Subject: Re: Network setup questions Date: Wed, 21 Nov 2001 17:37:25 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Nov 2001 17:37:25.0828 (UTC) FILETIME=[2F1DD040:01C172B3] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Joao, (vôce é português?) >I don't know much about pptp-client programs merely about the ports >needed >to >be open on a firewall in order to pass it trough. But if you say it >won't >work even with the firewall open, i guess there's not much help I >can >give >you.. No, I opened it up and had the same problem. Could nat be making problems for me? It's configured for my "external" interface wi0 (on the 10.10.2.0 net), should I configure it for the ng0 iface, or for something else? I tried pptp-client, the config script (perl) crashes, the script wants config files in /etc/pptp.d/ while the readme says to put them in /etc/ppp/ppp.conf (neither seems to work). It hangs when run, no log, no info, no connection :-( mpd-netgraph changes terms in the documentation (sometimes server, sometimes peer - the same, right?), nor is it clear to me what is my IP address and what is my peers address, if I need a "pptp self" address at all or not (and if so, which of my addresses is it?). My machine has (at least) 2 IP addresses... One for the LAN, one for the WAN. Also there's the loopback, and devices down that don't currently have addresses, like ppp0. And I'm assigned an IP when (if) I connect successfully via PPTP (and I know the genereal range). Plus I'm supposed to supply the VPN "name", I can't see where that is configured. Nor does the documentation say if one needs a pap.secrets or chap.secrets - all I have is a mpd.secrets, dunno if it's enough... Anyway I feel like I'm just digging myself deeper in this quicksand with each repeated time. Now I've found some doc's on Deja that say you need to run pppd in addition to pptp, one runs over the other. ?!?!? No wonder I'm getting confused ;-) >Anyway about the firewall . In my experience with pptp I had to >open the >following ports.. > >control channel: 1723 tcp & udp > >GRE or GRE over UDP: P:47 or 47 udp > >And because of the client being behind the firewall (in my case) I >had to >add >-pptpalias to my natd parameters.. But since you use the > >firewall >as a client I guess you don't need that anyway. I have no idea. I really need to get an overview as to all this stuff fits together and interoperates.... >It's not much , but I hope it helps. > >Regards, >Joao Thanks for trying! Regards, Thor _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 9:59:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 328D837B418 for ; Wed, 21 Nov 2001 09:59:11 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 21 Nov 2001 17:59:10 +0000 (GMT) To: Rudi Mathijssen Cc: "'freebsd-net@FreeBSD.org'" Subject: Re: kernel backtrace for kern/28844 In-Reply-To: Your message of "Wed, 21 Nov 2001 17:14:59 +0100." <8BA878388251D311B08200508B449FD10D0E3F4A@BEHDEVEX1> Date: Wed, 21 Nov 2001 17:59:09 +0000 From: Ian Dowse Message-ID: <200111211759.aa36148@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <8BA878388251D311B08200508B449FD10D0E3F4A@BEHDEVEX1>, Rudi Mathijsse n writes: >--- >Fatal trap 12: page fault while in kernel mode >fault virtual address = 0x79c02812 This is caused by a bug in ip_icmp.c relating to the generation of ICMP redirect messages that was fixed just before 4.3-RELEASE. The problem will go away if you upgrade to a more recent release. I can be almost 100% certain that this particular bug is the cause of your crashes because of the virtual address above. The bug caused the two most significant bytes of the mbuf mh_next pointer to get swapped, so a valid address 0xc0792812 got changed to 0x79c02812. It's a pity that not all bugs have such distinctive signatures :-) Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 10:21: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f4.law3.hotmail.com [209.185.241.4]) by hub.freebsd.org (Postfix) with ESMTP id 7FA7437B417 for ; Wed, 21 Nov 2001 10:20:57 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Nov 2001 10:20:57 -0800 Received: from 193.216.47.156 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 21 Nov 2001 18:20:57 GMT X-Originating-IP: [193.216.47.156] From: "Thor Legvold" To: freebsd-net@freebsd.org Subject: mpd-netgraph log questions Date: Wed, 21 Nov 2001 18:20:57 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Nov 2001 18:20:57.0500 (UTC) FILETIME=[43CB55C0:01C172B9] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Still struggling with PPTP... Trying to decipher the logfile in order to ask more appropriate questions and get this working. I have these iface's configured at startup: dc0 (home LAN 192.168.128.0) lp0 (? never used) lo0 (loopback) ppp0 (? never used) sl0 (? never used) faith0 (ipv4 -> ipv6) wi0 (ISP WAN 10.10.2.0, internet connection via VPN) When I run mpd I get ng0 as well (netgraph, it seems). I think I've narrowed my problem down to my configuration files. I *think* I'm able to connect with the VPN/PPTP server: Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 627, version 3.3 (root@a969.freebase.no 22:47 18-Nov-2001) [:] load access [access] ppp node is "mpd627-access" [access] using interface ng0 mpd: option "mppc" unknown mpd: option "mppc" unknown [access:access] open [access] IFACE: Open event [access] IPCP: Open event [access] IPCP: state change Initial --> Starting [access] IPCP: LayerStart [access:access] [access] bundle: OPEN event in state CLOSED [access] opening link "access"... [access] link: OPEN event [access] LCP: Open event [access] LCP: state change Initial --> Starting [access] LCP: LayerStart [access] device: OPEN event in state DOWN pptp0: connecting to 10.10.1.1:1723 [access] device is now in state OPENING pptp0: connected to 10.10.1.1:1723 pptp0: attached to connection with 10.10.1.1:1723 pptp0-0: outgoing call connected at 64000 bps [access] PPTP call successful [access] device: UP event in state OPENING [access] device is now in state UP [access] link: UP event [access] link: origination is local [access] LCP: Up event [access] LCP: state change Starting --> Req-Sent [access] LCP: phase shift DEAD --> ESTABLISH [access] LCP: SendConfigReq #1 ( I don't know why it says connected at 64000 bps! Its a pptp node, not a ppp node, isn't it?) However, I never get any further, and the program keeps retrying: [access] LCP: SendConfigReq #3 PROTOCOMP MRU 1500 MAGICNUM c685c33c AUTHPROTO CHAP MSOFT [access] LCP: rec'd Configure Reject #3 link 0 (Ack-Sent) AUTHPROTO CHAP MSOFT so here I'm guessing that something is configured wrong and everything stops, because after about 10 retries I get the following: [access] LCP: not converging [access] LCP: parameter negotiation failed [access] LCP: state change Ack-Sent --> Stopped [access] LCP: LayerFinish [access] device: CLOSE event in state UP pptp0-0: clearing call [access] device is now in state CLOSING [access] device: DOWN event in state CLOSING [access] device is now in state DOWN And then everything starts again. I've checked and double checked my login/password, they are correct (besides, I'm sure a program as comprehensive as this one would say "invalid password" if that was the case - right?) Do I need a chap.secrets file in /etc or /etc/ppp? I assumed all I need is a mpd.conf, mpd.links and mpd.secrets. What am I missing (besides an internet connection :-)? Regards, Thor _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 10:43: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f54.law3.hotmail.com [209.185.241.54]) by hub.freebsd.org (Postfix) with ESMTP id A49F537B416 for ; Wed, 21 Nov 2001 10:42:59 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Nov 2001 10:42:59 -0800 Received: from 193.216.47.156 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 21 Nov 2001 18:42:59 GMT X-Originating-IP: [193.216.47.156] From: "Thor Legvold" To: freebsd-net@freebsd.org Subject: mpd-netgraph configuration files Date: Wed, 21 Nov 2001 18:42:59 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Nov 2001 18:42:59.0494 (UTC) FILETIME=[57C39C60:01C172BC] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Still debugging, some questions to verify I have the proper config. FBSD dual homed host/gw for a home LAN dc0 home LAN 192.168.128.0/24 wi0 ISP WAN 10.10.0.0/16 IPFW and NAT are running, ipfw is wide open at present, natd running -m -s -dynamic on wi0. Don't know if I need anything else special on nat for PPTP to work. My ISP has a pool of dynamically assignable (DHCP) routable IP's that they assign via a PPTP server at 10.10.1.1. The routable IP's are in the range 213.225.121.0/24 as far as I understand. My config looks like this: # mpd.conf access: new -i ng0 access access set iface idle 0 set iface route default set iface disable on-demand set bundle disable multilink set bundle authname "myreallogin" set bundle password "myrealpassword" set link yes pap set link yes chap set link no mppc set link disable no-orig-auth set ipcp ranges 0.0.0.0/0 10.10.1.1/0 and links like this: # mpd.links access: set link type pptp set pptp mode active set pptp peer 10.10.1.1 set pptp enable originate outcall mpd.secrets has one line, with the same login/password as in mpd.conf I'm a bit unsure as to what values should be in "set ipcp ranges", but I don't seem to get the error message mentioned in the manual so I think it's ok as is. Does this appear at all correct? My ISP knows a bit about Linux (they use it for the PPTP/VPN server, running PoPToP), and said I needed a "name" variable somewhere, at least when connecting from Linux (but not Windows). Should I use the "set link ident" for this? Regards, Thor _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 21 17:37:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailrelay.netcologne.de (mailrelay.netcologne.de [194.8.194.96]) by hub.freebsd.org (Postfix) with ESMTP id 2BFD037B405; Wed, 21 Nov 2001 17:37:28 -0800 (PST) Received: from design.freestyling.de (design.freestyling.de [195.14.253.182]) by mailrelay.netcologne.de (8.11.6/8.11.6) with ESMTP id fAM1bN728389; Thu, 22 Nov 2001 02:37:23 +0100 (MET) X-Received: from tick.sc.omation.com (64-58-167-31.cbi.cox-oc.net [64.58.167.31] (may be forged)) by design.freestyling.de (8.11.3/8.11.3) with ESMTP id fAM1cR279675 for ; Thu, 22 Nov 2001 02:38:28 +0100 (CET) (envelope-from pherman@omation.com) X-Received: from tick.sc.omation.com (tick.sc.omation.com [192.168.128.2]) by tick.sc.omation.com (8.11.6/8.11.6) with ESMTP id fAM1YTB31405 for ; Wed, 21 Nov 2001 17:34:29 -0800 (PST) (envelope-from pherman@omation.com) Date: Wed, 21 Nov 2001 17:32:27 -0800 (PST) From: Paul Herman X-X-Sender: To: Cc: Subject: arp_rtrequest: bad gateway value Message-ID: <20011121171802.P23581-100000@tick.sc.omation.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ReSent-Date: Wed, 21 Nov 2001 17:34:22 -0800 (PST) X-ReSent-From: Paul Herman X-ReSent-To: X-ReSent-Subject: arp_rtrequest: bad gateway value X-ReSent-Message-ID: <20011121173422.C23581@tick.sc.omation.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I'd like to pick some brains before I file a PR. I've got 4.4-RELEASE running on FreeBSD-alpha with more than one alias on my network interface. I decided to try out routed, and started noticing gobs and gobs of messages: Nov 15 11:38:10 tick /kernel: arp_rtrequest: bad gateway value Nov 15 11:43:10 tick /kernel: arp_rtrequest: bad gateway value Nov 15 11:47:59 tick /kernel: arp_rtrequest: bad gateway value Nov 15 11:58:02 tick last message repeated 2 times Nov 15 12:08:10 tick last message repeated 2 times Nov 15 12:18:10 tick last message repeated 2 times It turns out, this is caused by a bad arp entry: 17:21:33{{ttyq8}pherman@tick}~//> arp -a ns1.sc.omation.com (192.168.128.1) at 0:0:0:0:0:0 permanent [ethernet] rt=200 tick.sc.omation.com (192.168.128.2) at 0:60:97:6e:6e:92 permanent [ethernet] [...etc...] Trying to delete the entry gives me "cannot locate 192.168.128.1", probably because the kernel thinks it doesn't exist becase the MAC addr == NULL... ...perhaps (?) Whatever, it shouldn't be there in the first place. So, I've narrowed this down to when routed it writes RTM_CHANGE of type RTF_HOST in sbin/routed/table.c:725 if (mask == HOST_MASK) { w.w_rtm.rtm_flags |= RTF_HOST; w.w_rtm.rtm_msglen -= sizeof(w.w_mask); } else { w.w_rtm.rtm_addrs |= RTA_NETMASK; w.w_mask.sin_addr.s_addr = htonl(mask); Something is going haywire (64bit issues?) because when I change this to if (mask == HOST_MASK && 0) { it works fine, but I'm sure I'm breaking something. :-) There *is* a sizeof(long) just after it on line 734 which should be a sizeof(u_int32_t), but that doesn't change anything in this case. This obviously works fine on 32-bit architectures, so I'm thinking it's some kind of alignment or sizeof problem, but I don't see it. Can anyone comment on this? -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 0:29:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f35.law3.hotmail.com [209.185.241.35]) by hub.freebsd.org (Postfix) with ESMTP id 371E937B416 for ; Thu, 22 Nov 2001 00:29:58 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 22 Nov 2001 00:29:58 -0800 Received: from 139.108.175.26 by lw3fd.law3.hotmail.msn.com with HTTP; Thu, 22 Nov 2001 08:29:57 GMT X-Originating-IP: [139.108.175.26] From: "Thor Legvold" To: larse@ISI.EDU Cc: freebsd-net@freebsd.org Subject: Re: mpd-netgraph configuration files Date: Thu, 22 Nov 2001 08:29:57 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Nov 2001 08:29:58.0086 (UTC) FILETIME=[DEBFE660:01C1732F] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Thor Legvold wrote: Lars, thanks for the files. I actually got a connection late last night, although I don't know why. Haven't been able to reproduce the "error" :-) Regards, Thor >>Still debugging, some questions to verify I have the proper config. > >FWIW, attached is an mpd configuration that works for me to connect to >ISI's VPN box. > >Lars >-- >Lars Eggert Information Sciences Institute >http://www.isi.edu/larse/ University of Southern California _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 0:38:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f127.law3.hotmail.com [209.185.241.127]) by hub.freebsd.org (Postfix) with ESMTP id 13A2837B416 for ; Thu, 22 Nov 2001 00:38:32 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 22 Nov 2001 00:38:32 -0800 Received: from 139.108.175.27 by lw3fd.law3.hotmail.msn.com with HTTP; Thu, 22 Nov 2001 08:38:31 GMT X-Originating-IP: [139.108.175.27] From: "Thor Legvold" To: freebsd-net@freebsd.org Subject: mpd-netgraph CONNECTED! Date: Thu, 22 Nov 2001 08:38:31 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Nov 2001 08:38:32.0009 (UTC) FILETIME=[11125390:01C17331] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org But I have no idea why. Nor is the link usable. But I'm happy to see I'm making progress :-) As far as I can tell, I did exactly what the docs say not to do (and even generates a warning when loading the bundle) - I set both remote and peer to 0.0.0.0/0, mpd tells me "IPCP: peer address cannot be zero" and the manual explicitly states *not* to set this to zero. However it seemed to allow me to connect, for whatever reason. This would all be easier if I understood the basic paradigm... The strange thing (maybe not strange, I guess it's what I asked for when configuring the peer IP to 0) is that I then get a routable IP from the peer (like I'm supposed to) AND a "self" IP in the 10.100.0.0 range, which I don't understand (I'll call my ISP and ask). I already have (via DHCP) an "internal" WAN IP of 10.10.2.91 which seems to be pretty much constant every time I connect, however setting this in the mpd.conf results in me not being able to connect. Even if I allow a reasonable spread (10.10.0.0/16), it won't work. My routing get's all blown up with a default route that doesn't make sense at all (10.100.n.n as gateway to mt routable IP, but default route still to 10.10.2.1 - the internal WAN). Tried changing this after mpd connected with both "route change ...." and with "set route default" from the mpd prompt. Neither helped, they caused mpd to drop the connection (no route to host). But, at least now I can connect, that's good! Any ideas what's wrong here? (where should I be looking next...?) Regards, Thor _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 0:59:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f108.law3.hotmail.com [209.185.241.108]) by hub.freebsd.org (Postfix) with ESMTP id EC58837B431 for ; Thu, 22 Nov 2001 00:58:55 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 22 Nov 2001 00:58:55 -0800 Received: from 139.108.175.27 by lw3fd.law3.hotmail.msn.com with HTTP; Thu, 22 Nov 2001 08:58:55 GMT X-Originating-IP: [139.108.175.27] From: "Thor Legvold" To: freebsd-net@freebsd.org Subject: More mpd-netgraph questions Date: Thu, 22 Nov 2001 08:58:55 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Nov 2001 08:58:55.0838 (UTC) FILETIME=[EA87CFE0:01C17333] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org A few things I've noticed: The "default" connection speed seems to be 64000 bps according to the log. The manual states you don't need to set anything regarding bandwidth or speed unless you're on an asynchronous dialup (modem, etc). I'm on a 11Mbs wireless WAN, and would like to know if and how I should configure (set link bandwidth foo). The manual says not to set 0.0.0.0 for remote (same as peer?) address in ipcp config, yet this was what allowed me to connect! Is my ISP's PPTP broken (Linux PoPToP), or is the documentation wrong? I'm not really clear on the difference between the "set ipcp ranges" and "set pptp peer" and "set pptp self" commands - could anyone give a hint or two? The problem now is (I think) that I end up with *2* IP's in the 10.0.0.0 class from my ISP, in addition to the routable address that's assigned (I get assigned both a dynamic routable and another dynamic non routable - which I already have via the WAN). Is this normal? Regards, Thor _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 1:34: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from backup.dagupan.com (www.psysc.org.ph [206.101.69.5]) by hub.freebsd.org (Postfix) with ESMTP id 979AD37B436 for ; Thu, 22 Nov 2001 01:34:00 -0800 (PST) Received: by apmail.dagupan.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Nov 2001 17:34:08 +0800 Message-ID: <10F29E27A956D511B0940050DA8D86A9340BE8@apmail.dagupan.com> From: francisv@dagupan.com To: freebsd-net@freebsd.org Subject: Maximum throughput of Intel Pro 100/S NIC? Date: Thu, 22 Nov 2001 17:34:08 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have an Intel Pro 100/S NIC on FreeBSD 4.4-STABLE connected to a Cisco Catalyst 3500XL switch at 100Mbps, full-duplex but I only get 15.6Mbps throughput. I'm transferring ISO images from the FreeBSD machine to an NT FTP server which is also connected on the same switch. What's the tested throughput for the Intel Pro 100 NICs? --- francis a. vidal [bitstop network services] | http://www.dagupan.com streaming media + web hosting | http://www.keystone.ph v(02)330-2871,(02)330-2872; f(02)330-2873 | http://www.kuro.ph To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 1:36:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id D407437B416 for ; Thu, 22 Nov 2001 01:36:22 -0800 (PST) Received: from vova by vbook.express.ru with local (Exim 3.31 #2) id 166qHQ-0000Ym-00; Thu, 22 Nov 2001 12:36:24 +0300 From: "Vladimir B. Grebenschikov" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15356.50968.19296.369023@vbook.express.ru> Date: Thu, 22 Nov 2001 12:36:24 +0300 To: francisv@dagupan.com Cc: freebsd-net@freebsd.org Subject: Maximum throughput of Intel Pro 100/S NIC? In-Reply-To: <10F29E27A956D511B0940050DA8D86A9340BE8@apmail.dagupan.com> References: <10F29E27A956D511B0940050DA8D86A9340BE8@apmail.dagupan.com> X-Mailer: VM 6.96 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org francisv@dagupan.com writes: > Hi, > > I have an Intel Pro 100/S NIC on FreeBSD 4.4-STABLE connected to a Cisco > Catalyst 3500XL switch at 100Mbps, full-duplex but I only get 15.6Mbps > throughput. I'm transferring ISO images from the FreeBSD machine to an NT > FTP server which is also connected on the same switch. > > What's the tested throughput for the Intel Pro 100 NICs? I have got 96% of 100Mbps under real production load. > francis a. vidal [bitstop network services] | http://www.dagupan.com > streaming media + web hosting | http://www.keystone.ph > v(02)330-2871,(02)330-2872; f(02)330-2873 | http://www.kuro.ph -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, vova@express.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 1:37:10 2001 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 3908837B416; Thu, 22 Nov 2001 01:36:43 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fAM9aAA41673; Thu, 22 Nov 2001 11:36:10 +0200 (EET) (envelope-from ru) Date: Thu, 22 Nov 2001 11:36:10 +0200 From: Ruslan Ermilov To: Paul Herman Cc: freebsd-net@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: arp_rtrequest: bad gateway value Message-ID: <20011122113610.C32952@sunbay.com> References: <20011121171802.P23581-100000@tick.sc.omation.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <20011121171802.P23581-100000@tick.sc.omation.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Nov 21, 2001 at 05:32:27PM -0800, Paul Herman wrote: > Hi, > > I'd like to pick some brains before I file a PR. > There's already a PR open on this, kern/29170. > I've got 4.4-RELEASE running on FreeBSD-alpha with more than one > alias on my network interface. I decided to try out routed, and > started noticing gobs and gobs of messages: > > Nov 15 11:38:10 tick /kernel: arp_rtrequest: bad gateway value > Nov 15 11:43:10 tick /kernel: arp_rtrequest: bad gateway value > Nov 15 11:47:59 tick /kernel: arp_rtrequest: bad gateway value > Nov 15 11:58:02 tick last message repeated 2 times > Nov 15 12:08:10 tick last message repeated 2 times > Nov 15 12:18:10 tick last message repeated 2 times > > It turns out, this is caused by a bad arp entry: > > 17:21:33{{ttyq8}pherman@tick}~//> arp -a > ns1.sc.omation.com (192.168.128.1) at 0:0:0:0:0:0 permanent [ethernet] rt=200 > tick.sc.omation.com (192.168.128.2) at 0:60:97:6e:6e:92 permanent [ethernet] > [...etc...] > > Trying to delete the entry gives me "cannot locate 192.168.128.1", > probably because the kernel thinks it doesn't exist becase the > MAC addr == NULL... ...perhaps (?) Whatever, it shouldn't be there > in the first place. > > So, I've narrowed this down to when routed it writes RTM_CHANGE > of type RTF_HOST in sbin/routed/table.c:725 > > if (mask == HOST_MASK) { > w.w_rtm.rtm_flags |= RTF_HOST; > w.w_rtm.rtm_msglen -= sizeof(w.w_mask); > } else { > w.w_rtm.rtm_addrs |= RTA_NETMASK; > w.w_mask.sin_addr.s_addr = htonl(mask); > > Something is going haywire (64bit issues?) because when I change > this to > > if (mask == HOST_MASK && 0) { > > it works fine, but I'm sure I'm breaking something. :-) There > *is* a sizeof(long) just after it on line 734 which should be a > sizeof(u_int32_t), but that doesn't change anything in this case. > This obviously works fine on 32-bit architectures, so I'm thinking > it's some kind of alignment or sizeof problem, but I don't see it. > > Can anyone comment on this? > Please find attached a copy of my recent posting on this topic. Hopefully, it exaplains the problem you observe in details. 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 --0F1p//8PRICkK4MW Content-Type: message/rfc822 Content-Disposition: inline Date: Thu, 18 Oct 2001 17:39:35 +0300 From: Ruslan Ermilov To: Darren Henderson Cc: stable@FreeBSD.ORG, net@FreeBSD.org Subject: Re: /kernel: arp_rtrequest: bad gateway value Message-ID: <20011018173935.A43019@sunbay.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from darren@bmv.state.me.us on Wed, Sep 26, 2001 at 01:08:40PM -0400 On Wed, Sep 26, 2001 at 01:08:40PM -0400, Darren Henderson wrote: > > Posted something similar the other day, but thought I would ask in a more > general way.... > > What causes this error? Looking at the archives and source it appears to be > related to aliases and if_inet.c > > What has changed between 4.3 and 4.4 that would account for this error > appearing under 4.4 but not appear under 4.3 on a system where the network > configuration has not changed? > > Everything appears to be working fine after the upgrade other then the > appearance of this message numerous times during the day with no apparent > pattern. > > Any thoughts appreciated. > There's the problem with routed(8). It issues a command similar to "route change ip ip" for each (but last) IP address of an interface if the route already exists and is different. This results in a changed route with AF_INET gateway, but route's IFA still points to Ethernet device and rt_ifa->ifa_rtrequest == arp_rtrequest. This results in this message as AF_INET != AF_LINK. The message is harmless. This is also reproduceable on a 4.1-RELEASE machine. How to repeat without routed(8): 1. Add IP address to your Ethernet interface: ifconfig rl0 192.168.1.1 alias 2. Create route for this address: ping -c1 192.168.1.1 3. Verify that the route was created with gateway of type AF_LINK: route -vn get 192.168.1.1 4. Change the route like routed(8) does: route change 192.168.1.1 192.168.1.1 5. Watch the dmesg(8) output then repeat "route get" command to see route's gateway changed to AF_INET: route -vn get 192.168.1.1 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 --0F1p//8PRICkK4MW-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 1:39:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 9FE7E37B418 for ; Thu, 22 Nov 2001 01:39:14 -0800 (PST) Received: (qmail 2506 invoked by uid 1001); 22 Nov 2001 09:39:12 +0000 (GMT) To: francisv@dagupan.com Cc: freebsd-net@freebsd.org Subject: Re: Maximum throughput of Intel Pro 100/S NIC? From: sthaug@nethelp.no In-Reply-To: Your message of "Thu, 22 Nov 2001 17:34:08 +0800" References: <10F29E27A956D511B0940050DA8D86A9340BE8@apmail.dagupan.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 22 Nov 2001 10:39:12 +0100 Message-ID: <2504.1006421952@verdi.nethelp.no> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I have an Intel Pro 100/S NIC on FreeBSD 4.4-STABLE connected to a Cisco > Catalyst 3500XL switch at 100Mbps, full-duplex but I only get 15.6Mbps > throughput. I'm transferring ISO images from the FreeBSD machine to an NT > FTP server which is also connected on the same switch. > > What's the tested throughput for the Intel Pro 100 NICs? Wire speed. Measured several years ago. With FreeBSD you can reach wire speed on 100 Mbps Ethernet with something like a P-166. Have you checked that your duplex configuration is correct? Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 1:43:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from backup.dagupan.com (www.psysc.org.ph [206.101.69.5]) by hub.freebsd.org (Postfix) with ESMTP id EE0D037B417 for ; Thu, 22 Nov 2001 01:43:44 -0800 (PST) Received: by apmail.dagupan.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Nov 2001 17:43:54 +0800 Message-ID: <10F29E27A956D511B0940050DA8D86A9340BEA@apmail.dagupan.com> From: francisv@dagupan.com To: vova@express.ru Cc: freebsd-net@freebsd.org Subject: RE: Maximum throughput of Intel Pro 100/S NIC? Date: Thu, 22 Nov 2001 17:43:53 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On a single NIC? Are the clients getting data from your host or are they putting data on the host? -----Original Message----- From: Vladimir B. Grebenschikov [mailto:vova@express.ru] Sent: Thursday, November 22, 2001 5:36 PM To: francisv@dagupan.com Cc: freebsd-net@freebsd.org Subject: Maximum throughput of Intel Pro 100/S NIC? francisv@dagupan.com writes: > Hi, > > I have an Intel Pro 100/S NIC on FreeBSD 4.4-STABLE connected to a Cisco > Catalyst 3500XL switch at 100Mbps, full-duplex but I only get 15.6Mbps > throughput. I'm transferring ISO images from the FreeBSD machine to an NT > FTP server which is also connected on the same switch. > > What's the tested throughput for the Intel Pro 100 NICs? I have got 96% of 100Mbps under real production load. > francis a. vidal [bitstop network services] | http://www.dagupan.com > streaming media + web hosting | http://www.keystone.ph > v(02)330-2871,(02)330-2872; f(02)330-2873 | http://www.kuro.ph -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, vova@express.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 1:45:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from backup.dagupan.com (www.psysc.org.ph [206.101.69.5]) by hub.freebsd.org (Postfix) with ESMTP id 98B2837B416 for ; Thu, 22 Nov 2001 01:45:25 -0800 (PST) Received: by apmail.dagupan.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Nov 2001 17:45:34 +0800 Message-ID: <10F29E27A956D511B0940050DA8D86A9340BEB@apmail.dagupan.com> From: francisv@dagupan.com To: sthaug@nethelp.no Cc: freebsd-net@freebsd.org Subject: RE: Maximum throughput of Intel Pro 100/S NIC? Date: Thu, 22 Nov 2001 17:45:33 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The hosts are Pentium III 900Mhz machines with 1GB of memory. How do you check the duplex configuration? On the switch? On the Windows NT machine? -----Original Message----- From: sthaug@nethelp.no [mailto:sthaug@nethelp.no] Sent: Thursday, November 22, 2001 5:39 PM To: francisv@dagupan.com Cc: freebsd-net@freebsd.org Subject: Re: Maximum throughput of Intel Pro 100/S NIC? > I have an Intel Pro 100/S NIC on FreeBSD 4.4-STABLE connected to a Cisco > Catalyst 3500XL switch at 100Mbps, full-duplex but I only get 15.6Mbps > throughput. I'm transferring ISO images from the FreeBSD machine to an NT > FTP server which is also connected on the same switch. > > What's the tested throughput for the Intel Pro 100 NICs? Wire speed. Measured several years ago. With FreeBSD you can reach wire speed on 100 Mbps Ethernet with something like a P-166. Have you checked that your duplex configuration is correct? Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 1:47:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id E828E37B416 for ; Thu, 22 Nov 2001 01:47:39 -0800 (PST) Received: from vova by vbook.express.ru with local (Exim 3.31 #2) id 166qSM-0000aR-00; Thu, 22 Nov 2001 12:47:42 +0300 From: "Vladimir B. Grebenschikov" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15356.51646.313468.825589@vbook.express.ru> Date: Thu, 22 Nov 2001 12:47:42 +0300 To: francisv@dagupan.com Cc: vova@express.ru, freebsd-net@freebsd.org Subject: RE: Maximum throughput of Intel Pro 100/S NIC? In-Reply-To: <10F29E27A956D511B0940050DA8D86A9340BEA@apmail.dagupan.com> References: <10F29E27A956D511B0940050DA8D86A9340BEA@apmail.dagupan.com> X-Mailer: VM 6.96 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org francisv@dagupan.com writes: > On a single NIC? Are the clients getting data from your host or are they > putting data on the host? None of above. It was one of my core routers so it was transit IP traffic through router. And one of NICs reach almost 100Mbps. > I have got 96% of 100Mbps under real production load. -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, vova@express.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 2:18:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 5FDC237B417 for ; Thu, 22 Nov 2001 02:18:44 -0800 (PST) Received: (qmail 2916 invoked by uid 1001); 22 Nov 2001 10:18:42 +0000 (GMT) To: francisv@dagupan.com Cc: freebsd-net@freebsd.org Subject: RE: Maximum throughput of Intel Pro 100/S NIC? From: sthaug@nethelp.no In-Reply-To: Your message of "Thu, 22 Nov 2001 17:45:33 +0800" References: <10F29E27A956D511B0940050DA8D86A9340BEB@apmail.dagupan.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 22 Nov 2001 11:18:42 +0100 Message-ID: <2914.1006424322@verdi.nethelp.no> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > The hosts are Pentium III 900Mhz machines with 1GB of memory. How do you > check the duplex configuration? On the switch? On the Windows NT machine? On your FreeBSD host, you can check it with the "ifconfig" command. If you have a managed switch, you should be able to get duplex information through the management interface. If you have an unmanaged switch, you *may* still have LEDs which indicate duplex - otherwise you're out of luck. I have no idea how you do it on the NT machine. By the way, this is really stuff for freebsd-questions. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 6:36:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts16-srv.bellnexxia.net (tomts16.bellnexxia.net [209.226.175.4]) by hub.freebsd.org (Postfix) with ESMTP id 8C52037B405 for ; Thu, 22 Nov 2001 06:36:30 -0800 (PST) Received: from xena.gsicomp.on.ca ([199.243.149.34]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20011122132643.QOZN9997.tomts6-srv.bellnexxia.net@xena.gsicomp.on.ca> for ; Thu, 22 Nov 2001 08:26:43 -0500 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.11.1) with SMTP id fAMDIPW40287 for ; Thu, 22 Nov 2001 08:18:25 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <005601c17359$4ffda0f0$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: Subject: Re: Strange problem with PPP/Netgraph (PPPoE) Date: Thu, 22 Nov 2001 08:26:36 -0500 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.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks for all who replied to this thread, indicating that a bad cable was likely the culprit. In this case, changing the cable didn't help, but commenting out the "ifconfig_rl0='up'" line in /etc/rc.conf fixed the problem. Any ideas on why doing an 'ifconfig rl0 up' before starting PPP (using set device PPPoE:rl0) would cause this problem? (These machines are running 4.3-REL-p20) -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 8:36:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f67.pav2.hotmail.com [64.4.37.67]) by hub.freebsd.org (Postfix) with ESMTP id B978837B41C for ; Thu, 22 Nov 2001 08:36:24 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 22 Nov 2001 08:36:24 -0800 Received: from 204.178.20.14 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 22 Nov 2001 16:36:24 GMT X-Originating-IP: [204.178.20.14] From: "murthy kn" To: net@freebsd.org Subject: wrong ifa Date: Thu, 22 Nov 2001 22:06:24 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Nov 2001 16:36:24.0501 (UTC) FILETIME=[D3356650:01C17373] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, what does the message "rtinit:wrong ifa was " exactly mean? I get it when using "ifconfig" on a NIC but I am able to use the NIC without any problems (apparently atleast). Can it cause any problems? Thanks for your time, Murthy _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 11:27:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from obelix.spectraweb.ch (obelix.plusnet.ch [194.158.230.8]) by hub.freebsd.org (Postfix) with ESMTP id 37BF537B405; Thu, 22 Nov 2001 11:27:02 -0800 (PST) Received: from saturn.spectraweb.ch (tch-ls-3-dialup-132.spectraweb.ch [194.230.249.132]) by obelix.spectraweb.ch (8.11.2/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id fAMJQqo04452; Thu, 22 Nov 2001 20:26:53 +0100 Received: (from martin@localhost) by saturn.spectraweb.ch (8.11.6/8.11.6) id fAMKXe002400; Thu, 22 Nov 2001 21:33:40 +0100 (CET) (envelope-from pcservi@spectraweb.ch) Date: Thu, 22 Nov 2001 21:33:38 +0100 From: Martin Schweizer To: Thor Legvold Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Network setup questions Message-ID: <20011122213337.C2253@spectraweb.ch> Reply-To: Martin Schweizer References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tlegvold@hotmail.com on Wed, Nov 21, 2001 at 10:20:54AM +0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello Thor On Wed, Nov 21, 2001 at 10:20:54AM +0000 Thor Legvold wrote: > Well, I've asked 3 or 4 times now in the last 3 weeks, and haven't received > any answers. Posted to comp.unix.bsd.freebsd.misc and to both questions- and > net@freebsd.org. > > That leads me to conclude that either I'm: asking the wrong question(s), > asking in an improper manner or asking the wrong people/wrong group. > > I *have* searched Deja, I *have* read the docs and attempted to get this to > work - I really don't know where else I could be looking or asking for more > information. If my question was worded poorly or inappropiate, I would > appreciate a pointer as to where/how/who I might contact in order to get my > system up and configured properly. > > Again, I'm trying to log into an ISP via PPTP for internet access, using > mpd-netgraph but also trying out pptpclient. I have a small home LAN that I > want to NAT/IPFW such that all machines can share the internet connection. > I'm running FreeBSD 4.4-Stable. I'm using a PPP connection to my ISP. My LAN has a hub, a Win2k workstation, a Win95 workstation and a FreeBSD 4.4 server (and workstation) with IPFW (my rules works fine), gatway function, dial-up (ISDN), DHCP etc. Do you test it without PPTP? If I can I will help you. -- Regards Martin PC-Service M. Schweizer; Gewerbehaus Schwarz; CH-8608 Bubikon Tel. +41 55 243 30 00; Fax: +41 55 243 33 22; http://www.pc-service.ch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 13:25:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from noralf.uib.no (noralf.uib.no [129.177.30.12]) by hub.freebsd.org (Postfix) with ESMTP id 1ECB137B416 for ; Thu, 22 Nov 2001 13:25:10 -0800 (PST) Received: from tunnel-45-12.vpn.uib.no (ii.uib.no) [129.177.45.12] by noralf.uib.no with esmtp (Exim 3.16) id 1671KS-0005Mf-00; Thu, 22 Nov 2001 22:24:16 +0100 Message-ID: <3BFD6E36.1020306@ii.uib.no> Date: Thu, 22 Nov 2001 22:29:26 +0100 From: Trond Davidsen User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010909 X-Accept-Language: en-us MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Mpd 3.2: Error in pptp.c? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *1671KS-0005Mf-00*ifQVIqkFefs* http://tjinfo.uib.no/virus.html Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, in the file pptp.c in function PptpHookUp about line 481: /* Get session info */ memset(&self_addr, 0, sizeof(self_addr)); self_addr.sin_family = AF_INET; self_addr.sin_len = sizeof(self_addr); peer_addr = self_addr; shouldn't peer_addr get it's own structure? When I insert logging after this, self_addr and peer_addr is the same addres, which don't make any sense to me. Trond To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 15:30: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 4E3CC37B416 for ; Thu, 22 Nov 2001 15:30:05 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id PAA37353; Thu, 22 Nov 2001 15:18:30 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fAMNISk89377; Thu, 22 Nov 2001 15:18:28 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111222318.fAMNISk89377@arch20m.dellroad.org> Subject: Re: Mpd 3.2: Error in pptp.c? In-Reply-To: <3BFD6E36.1020306@ii.uib.no> "from Trond Davidsen at Nov 22, 2001 10:29:26 pm" To: Trond Davidsen Date: Thu, 22 Nov 2001 15:18:28 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Trond Davidsen writes: > in the file pptp.c in function PptpHookUp about line 481: > > /* Get session info */ > memset(&self_addr, 0, sizeof(self_addr)); > self_addr.sin_family = AF_INET; > self_addr.sin_len = sizeof(self_addr); > peer_addr = self_addr; > > shouldn't peer_addr get it's own structure? When I insert logging after > this, self_addr and peer_addr is the same addres, which don't make any > sense to me. peer_addr is a separate structure. You're probably seeing the same IP address because you're using inet_ntoa() which returns a static buffer. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 15:41:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 9FCD637B416 for ; Thu, 22 Nov 2001 15:41:13 -0800 (PST) Received: (qmail 74085 invoked from network); 22 Nov 2001 23:41:00 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.21.143]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 22 Nov 2001 23:41:00 -0000 Message-ID: <3BFD8C8D.8C85D8D2@pipeline.ch> Date: Fri, 23 Nov 2001 00:38:53 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Fastforwarding gone? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I can't seem find any reference to ip_fastforward() in ip_input() anymore. Is fastforwarding non-functional at the moment? -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 15:48:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 21AA937B405 for ; Thu, 22 Nov 2001 15:48:55 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fAMNioM49638; Thu, 22 Nov 2001 15:44:50 -0800 (PST) (envelope-from rizzo) Date: Thu, 22 Nov 2001 15:44:50 -0800 From: Luigi Rizzo To: Andre Oppermann Cc: freebsd-net@FreeBSD.ORG Subject: Re: Fastforwarding gone? Message-ID: <20011122154450.A49625@iguana.aciri.org> References: <3BFD8C8D.8C85D8D2@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BFD8C8D.8C85D8D2@pipeline.ch> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Nov 23, 2001 at 12:38:53AM +0100, Andre Oppermann wrote: > I can't seem find any reference to ip_fastforward() in ip_input() > anymore. because it is called earlier, from ether_input(). (mind you, there is some brokenness in ip_fastforward, because you cannot know if a packet is fastforwarded or goes through the standard processing, and the two paths do different things e.g. no firewall in the former.) cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 19: 3:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id E0FAB37B405 for ; Thu, 22 Nov 2001 19:03:31 -0800 (PST) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.11.6/8.11.6) with SMTP id fAN33RR72623; Thu, 22 Nov 2001 22:03:27 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa To: matt@gsicomp.on.ca ("Matthew Emmerton") Cc: freebsd-net@freebsd.org Subject: Re: Strange problem with PPP/Netgraph (PPPoE) Date: Thu, 22 Nov 2001 22:03:27 -0500 Message-ID: <1uervtss6vs7jltu79pos19vmjroiagk17@4ax.com> References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 22 Nov 2001 14:36:37 +0000 (UTC), in sentex.lists.freebsd.net you wrote: >Thanks for all who replied to this thread, indicating that a bad cable = was >likely the culprit. > >In this case, changing the cable didn't help, but commenting out the >"ifconfig_rl0=3D'up'" line in /etc/rc.conf fixed the problem. > >Any ideas on why doing an 'ifconfig rl0 up' before starting PPP (using = set >device PPPoE:rl0) would cause this problem? (These machines are running >4.3-REL-p20) Not sure why. But, I have noticed that many of the realtek cards do not detect their speed / media type properly. On my DSL connection, I need = to do ifconfig rl0 media 10baseT/UTP. Try in your /etc/rc.conf instead of = just ifconfig_rl0=3D'up' try ifconfig_rl0=3D'media 10baseT/UTP up' Without doing this, ifconfig rl0 shows a media type of none and the connection does not function properly. ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 21:45: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 86E2837B405 for ; Thu, 22 Nov 2001 21:45:03 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA39167; Thu, 22 Nov 2001 21:40:45 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fAN5ejr90147; Thu, 22 Nov 2001 21:40:45 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111230540.fAN5ejr90147@arch20m.dellroad.org> Subject: Re: Strange problem with PPP/Netgraph (PPPoE) In-Reply-To: <005601c17359$4ffda0f0$1200a8c0@gsicomp.on.ca> "from Matthew Emmerton at Nov 22, 2001 08:26:36 am" To: Matthew Emmerton Date: Thu, 22 Nov 2001 21:40:45 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Matthew Emmerton writes: > Any ideas on why doing an 'ifconfig rl0 up' before starting PPP (using set > device PPPoE:rl0) would cause this problem? (These machines are running > 4.3-REL-p20) There is a kernel bug in 4.3 where certain interfaces can't deal with an outgoing packet appearing while the interface is still marked down. Brian modified ppp(8) to workaround this by setting the interface to be 'UP' before sending any packets. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 21:45:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 0501037B405 for ; Thu, 22 Nov 2001 21:45:07 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA39158; Thu, 22 Nov 2001 21:37:38 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fAN5bcJ90134; Thu, 22 Nov 2001 21:37:38 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111230537.fAN5bcJ90134@arch20m.dellroad.org> Subject: Re: More mpd-netgraph questions In-Reply-To: "from Thor Legvold at Nov 22, 2001 08:58:55 am" To: Thor Legvold Date: Thu, 22 Nov 2001 21:37:38 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thor Legvold writes: > The "default" connection speed seems to be 64000 bps according to the log. > The manual states you don't need to set anything regarding bandwidth or > speed unless you're on an asynchronous dialup (modem, etc). I'm on a 11Mbs > wireless WAN, and would like to know if and how I should configure (set link > bandwidth foo). Just ignore these settings.. unless you're doing multi-link PPP they don't have any effect on anything. > broken (Linux PoPToP), or is the documentation wrong? I'm not really clear > on the difference between the "set ipcp ranges" and "set pptp peer" and "set > pptp self" commands - could anyone give a hint or two? First, make sure you understand that PPTP is a tunnelling protocol.. that is, it acts just like a modem -- so you can run PPP over it -- but instead of telephone wires it uses IP packets. So each packet has an "outside" IP address (the real one) and an "inside" IP address (the one negotiated by the PPP stuff; often these are non-routable addresses). "set ipcp ranges" configures the "inside" IP address(es) while "set pptp self" and "set pptp peer" configure the outside IP addresses. "ifconfig ng0" (or whatever interface you're using) will show the 'inside' IP addresses. Your "outside" IP address will be on some other interface already configured before PPTP is set up. Make sure the peer's inside and outside addresses are different, otherwise you get an infinite loop. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 21:47:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from backup.dagupan.com (www.psysc.org.ph [206.101.69.5]) by hub.freebsd.org (Postfix) with ESMTP id 733B437B416 for ; Thu, 22 Nov 2001 21:47:46 -0800 (PST) Received: by apmail.dagupan.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Nov 2001 13:47:49 +0800 Message-ID: <10F29E27A956D511B0940050DA8D86A9340C04@apmail.dagupan.com> From: francisv@dagupan.com To: freebsd-net@freebsd.org Subject: OT: Auto-mounting vnode disks Date: Fri, 23 Nov 2001 13:47:48 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, How do you auto-mount vnode disks? I created the file /etc/vntab but it doesn't work: /etc/vntab /dev/vn0c /usr/local/vnodes/file mount=/usr/local/mount_point the `vn' device is already in the kernel and the devices are present in /dev. I've already tried this using: [root@host]# vnconfig /dev/vn0 /usr/local/vnodes/file and then: [root@host]# mount /dev/vn0c /usr/local/mount_point which works but I couldn't make it to work with the `vnconfig -e' option. --- francis a. vidal [bitstop network services] | http://www.dagupan.com streaming media + web hosting | http://www.keystone.ph v(02)330-2871,(02)330-2872; f(02)330-2873 | http://www.kuro.ph To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 22: 0: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 8F82C37B405 for ; Thu, 22 Nov 2001 22:00:02 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA39230; Thu, 22 Nov 2001 21:46:28 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fAN5kSM90172; Thu, 22 Nov 2001 21:46:28 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111230546.fAN5kSM90172@arch20m.dellroad.org> Subject: Re: mpd-netgraph log questions In-Reply-To: "from Thor Legvold at Nov 21, 2001 06:20:57 pm" To: Thor Legvold Date: Thu, 22 Nov 2001 21:46:28 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thor Legvold writes: > [access] LCP: SendConfigReq #3 > PROTOCOMP > MRU 1500 > MAGICNUM c685c33c > AUTHPROTO CHAP MSOFT > [access] LCP: rec'd Configure Reject #3 link 0 (Ack-Sent) > AUTHPROTO CHAP MSOFT You've enabled CHAP in your configuration (via 'set link enable chap', note, not the same thing as 'set link allow chap' which you probably *do* want), and the remote side doesn't want to do that. Add "set link disable chap pap" to your mpd.conf so that you're no longer requiring the remote side to authenticate itself to you. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 22 22: 0:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 9D73537B416 for ; Thu, 22 Nov 2001 22:00:04 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA39243; Thu, 22 Nov 2001 21:50:31 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fAN5oVZ90201; Thu, 22 Nov 2001 21:50:31 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111230550.fAN5oVZ90201@arch20m.dellroad.org> Subject: Re: mpd-netgraph configuration files In-Reply-To: "from Thor Legvold at Nov 21, 2001 06:42:59 pm" To: Thor Legvold Date: Thu, 22 Nov 2001 21:50:31 -0800 (PST) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thor Legvold writes: > Still debugging, some questions to verify I have the proper config. > > FBSD dual homed host/gw for a home LAN > dc0 home LAN 192.168.128.0/24 > wi0 ISP WAN 10.10.0.0/16 > > IPFW and NAT are running, ipfw is wide open at present, natd running -m -s > -dynamic on wi0. Don't know if I need anything else special on nat for PPTP > to work. > > My ISP has a pool of dynamically assignable (DHCP) routable IP's that they > assign via a PPTP server at 10.10.1.1. The routable IP's are in the range > 213.225.121.0/24 as far as I understand. > > My config looks like this: > > # mpd.conf > access: > new -i ng0 access access > set iface idle 0 > set iface route default > set iface disable on-demand > set bundle disable multilink > set bundle authname "myreallogin" > set bundle password "myrealpassword" > set link yes pap > set link yes chap Replace "yes" with "allow" in the above two lines. > set link no mppc Not a valid command.. maybe you mean 'set ccp no mppc' ? > set link disable no-orig-auth > set ipcp ranges 0.0.0.0/0 10.10.1.1/0 > and links like this: > > # mpd.links > access: > set link type pptp > set pptp mode active > set pptp peer 10.10.1.1 > set pptp enable originate outcall > Does this appear at all correct? My ISP knows a bit about Linux (they use it > for the PPTP/VPN server, running PoPToP), and said I needed a "name" > variable somewhere, at least when connecting from Linux (but not Windows). > Should I use the "set link ident" for this? Are you sure they don't want you to do PPPoE instead of PPTP? PPPoE requires a name, but PPTP doesn't. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 23 1: 7:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f122.law3.hotmail.com [209.185.241.122]) by hub.freebsd.org (Postfix) with ESMTP id 69F0937B405 for ; Fri, 23 Nov 2001 01:07:51 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 23 Nov 2001 01:07:51 -0800 Received: from 139.108.175.26 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 23 Nov 2001 09:07:50 GMT X-Originating-IP: [139.108.175.26] From: "Thor Legvold" To: vova@express.ru, francisv@dagupan.com Cc: freebsd-net@freebsd.org Subject: Re: Maximum throughput of Intel Pro 100/S NIC? Date: Fri, 23 Nov 2001 09:07:50 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Nov 2001 09:07:51.0089 (UTC) FILETIME=[53FA6210:01C173FE] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Vladimir B. Grebenschikov" did wax gregarious and thus spake: >francisv@dagupan.com writes: > > Hi, > > > > I have an Intel Pro 100/S NIC on FreeBSD 4.4-STABLE connected to a >Cisco > > Catalyst 3500XL switch at 100Mbps, full-duplex but I only get 15.6Mbps > > throughput. I'm transferring ISO images from the FreeBSD machine to an >NT > > FTP server which is also connected on the same switch. > > > > What's the tested throughput for the Intel Pro 100 NICs? > >I have got 96% of 100Mbps under real production load. Wouldn't the TCP/IP overhead + ethernet design (collisions) reduce this figure to more like 70Mbs max in the real world? >-- >TSB Russian Express, Moscow >Vladimir B. Grebenschikov, vova@express.ru Regards, Thor _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 23 1:50: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 9BACF37B405 for ; Fri, 23 Nov 2001 01:50:04 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id A6D1281D14; Fri, 23 Nov 2001 03:50:04 -0600 (CST) Date: Fri, 23 Nov 2001 03:50:04 -0600 From: Bill Fumerola To: Thor Legvold Cc: freebsd-net@freebsd.org Subject: Re: Maximum throughput of Intel Pro 100/S NIC? Message-ID: <20011123035004.W81711@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tlegvold@hotmail.com on Fri, Nov 23, 2001 at 09:07:50AM +0000 X-Operating-System: FreeBSD 4.4-FEARSOME-20010909 i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Nov 23, 2001 at 09:07:50AM +0000, Thor Legvold wrote: > >I have got 96% of 100Mbps under real production load. > > Wouldn't the TCP/IP overhead + ethernet design (collisions) reduce this > figure to more like 70Mbs max in the real world? 1) when people refer to getting 96% of X Mbps, they're referring to ethernet frames, not cute little netscape download boxes. 2) the real world uses switches and runs full duplex, so collisions aren't really a concern. if you're going to dispute statistics, at least understand the metrics. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org - my anger management counselor can beat up your self-affirmation therapist To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 23 3:14:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f104.law3.hotmail.com [209.185.241.104]) by hub.freebsd.org (Postfix) with ESMTP id A5D5B37B416 for ; Fri, 23 Nov 2001 03:14:37 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 23 Nov 2001 03:14:37 -0800 Received: from 139.108.175.26 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 23 Nov 2001 11:14:37 GMT X-Originating-IP: [139.108.175.26] From: "Thor Legvold" To: billf@mu.org Cc: freebsd-net@freebsd.org Subject: Re: Maximum throughput of Intel Pro 100/S NIC? Date: Fri, 23 Nov 2001 11:14:37 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Nov 2001 11:14:37.0598 (UTC) FILETIME=[09CF8BE0:01C17410] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Bill, > > >I have got 96% of 100Mbps under real production load. > > > > Wouldn't the TCP/IP overhead + ethernet design (collisions) reduce > >figure to more like 70Mbs max in the real world? > >1) when people refer to getting 96% of X Mbps, they're referring to > ethernet frames, not cute little netscape download boxes. Ok. I don't know what cute little Netscape boxes you're referring to, but thanks for the pointer. I don't suppose you were trying to be sarcastic...? >2) the real world uses switches and runs full duplex, so collisions > aren't really a concern. I see. I run full duplex, on a (one :-) switch. I wasn't aware that collisions weren't a concern. >if you're going to dispute statistics, at least understand the metrics. I didn't realize I was disputing, I thought I was asking a question (thinking out loud, whatever). Had a bit too much coffee today? I guess this is the wrong place to learn more about networking & FBSD? >- bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org Regards, Thor _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 23 4:51:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns.sirena2000.ru (ns.sirena2000.ru [194.84.25.34]) by hub.freebsd.org (Postfix) with ESMTP id C297D37B416 for ; Fri, 23 Nov 2001 04:51:13 -0800 (PST) Received: from sirena2000.ru (chek.network.sirena2000.ru [10.1.9.71]) by ns.sirena2000.ru (8.9.3/8.9.3) with ESMTP id PAA03434 for ; Fri, 23 Nov 2001 15:51:05 +0300 (MSK) (envelope-from serg@sirena2000.ru) Message-ID: <3BFE4622.DA72E0D5@sirena2000.ru> Date: Fri, 23 Nov 2001 15:50:42 +0300 From: Chemisov X-Mailer: Mozilla 4.72 [en] (X11; I; SCO_SV 3.2 i386) X-Accept-Language: ru, en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: decreasing TIME_WAIT duration(T/TCP?) Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello! It is important to me to have duration of TIME_WAIT state of TCP connection as short time as possible. It is because Server identifies its Clients by C_IP:C_PORT(which permanent for one Client). In FreeBSD 3.4 I have been edited netinet sources to decrease interval for TIME_WAIT -only(!!!) (TCPTV_MSL(60sec) -> TCPTV_MSL_MY(10sec))- for example(tcp_input.c): switch (tp->t_state) { case TCPS_SYN_RECEIVED: ........................ case TCPS_ESTABLISHED: ..................... case TCPS_FIN_WAIT_1: ................. /* * In FIN_WAIT_2 state enter the TIME_WAIT state, * starting the time-wait timer, turning off the other * standard timers. */ case TCPS_FIN_WAIT_2: tp->t_state = TCPS_TIME_WAIT; tcp_canceltimers(tp); /* Shorten TIME_WAIT [RFC-1644, p.28] */ if (tp->cc_recv != 0 && tp->t_duration < TCPTV_MSL_MY) { /* TCPTV_MSL_MY = 10sec for me!!!*/ tp->t_timer[TCPT_2MSL] = tp->t_rxtcur * TCPTV_TWTRUNC; /* For transaction client, force ACK now. */ tp->t_flags |= TF_ACKNOW; } else tp->t_timer[TCPT_2MSL] = 2 * TCPTV_MSL_MY; /* TCPTV_MSL_MY = 10sec for me!!!*/ soisdisconnected(so); break; /* * In TIME_WAIT state restart the 2 MSL time_wait timer. */ case TCPS_TIME_WAIT: tp->t_timer[TCPT_2MSL] = 2 * TCPTV_MSL_MY; break; } As I know FreeBSD 4.x can calculate MSL depending on data transmission's speed. How to turn on this calculation for 4.x ? It seems that sysctl whith net.inet.tcp.rfc1323 (and .1644) does not work for me. May be I must use T/TCP ? Serg. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 23 7:22:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 01FC037B416 for ; Fri, 23 Nov 2001 07:22:24 -0800 (PST) Received: (qmail 41890 invoked by uid 1001); 23 Nov 2001 15:22:21 +0000 (GMT) To: tlegvold@hotmail.com Cc: freebsd-net@freebsd.org Subject: Re: Maximum throughput of Intel Pro 100/S NIC? From: sthaug@nethelp.no In-Reply-To: Your message of "Fri, 23 Nov 2001 09:07:50 " References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 23 Nov 2001 16:22:21 +0100 Message-ID: <41888.1006528941@verdi.nethelp.no> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > >I have got 96% of 100Mbps under real production load. > > Wouldn't the TCP/IP overhead + ethernet design (collisions) reduce this > figure to more like 70Mbs max in the real world? As has been pointed out, a lot of people run full duplex these days. With FD ethernet, the maximum achievable bandwidth is easy to compute, but depends on which protocol level you're looking at: - 1500 byte Ethernet payload: Maximum is 1500 / (1500 + 18 + 8 + 12) = 97.53% (ie. 97.53 Mbps for 100 Mbps Ethernet). - 1460 byte TCP payload: Maximum is 1460 / (1500 + 18 + 8 + 12) = 94.93% (ie. 94.93 Mbps for 100 Mbps Ethernet). FreeBSD can get extremely close to these limits. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 23 8:11:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from bazooka.trit.org (bazooka.trit.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id F30A937B41A for ; Fri, 23 Nov 2001 08:11:19 -0800 (PST) Received: by bazooka.trit.org (Postfix, from userid 1000) id B9BA13F86; Fri, 23 Nov 2001 16:11:19 +0000 (UTC) Received: from bazooka (localhost [127.0.0.1]) by bazooka.trit.org (Postfix) with ESMTP id B86143C140 for ; Fri, 23 Nov 2001 16:11:19 +0000 (UTC) To: net@freebsd.org Subject: Fix icmp_reflect if no addresses are configured Date: Fri, 23 Nov 2001 16:11:14 +0000 From: Dima Dorfman Message-Id: <20011123161119.B9BA13F86@bazooka.trit.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Please review the following change, from NetBSD: In icmp_reflect(): If the packet was not addressed to us and was received on an interface without an IP address, try to find a non-loopback AF_INET address to use. If that fails, drop it. Previously, we used the address at the top of the in_ifaddrhead list, which didn't make much sense, and would cause a panic if there were no AF_INET addresses configured on the system. This fixes PRs 29337 and 30524. Thanks. Index: ip_icmp.c =================================================================== RCS file: /ref/cvsf/src/sys/netinet/ip_icmp.c,v retrieving revision 1.62 diff -u -r1.62 ip_icmp.c --- ip_icmp.c 2001/10/25 05:56:30 1.62 +++ ip_icmp.c 2001/11/23 15:55:41 @@ -623,10 +623,25 @@ (struct sockaddr *)&icmpdst, m->m_pkthdr.rcvif); /* * The following happens if the packet was not addressed to us, - * and was received on an interface with no IP address. + * and was received on an interface with no IP address: + * We find the first AF_INET address on the first non-loopback + * interface. */ if (ia == NULL) - ia = TAILQ_FIRST(&in_ifaddrhead); + TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { + if (ia->ia_ifp->if_flags & IFF_LOOPBACK) + continue; + break; + } + + /* + * If we still didn't find an address, punt. We could have an + * interface up and (and receiving packets) with no address. + */ + if (ia == NULL) { + m_freem(m); + goto done; + } match: t = IA_SIN(ia)->sin_addr; ip->ip_src = t; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 23 8:19:39 2001 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 42B6A37B419 for ; Fri, 23 Nov 2001 08:19:27 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fANGJ4T70212; Fri, 23 Nov 2001 18:19:04 +0200 (EET) (envelope-from ru) Date: Fri, 23 Nov 2001 18:19:04 +0200 From: Ruslan Ermilov To: Dima Dorfman Cc: net@FreeBSD.ORG Subject: Re: Fix icmp_reflect if no addresses are configured Message-ID: <20011123181904.A69647@sunbay.com> References: <20011123161119.B9BA13F86@bazooka.trit.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011123161119.B9BA13F86@bazooka.trit.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Nov 23, 2001 at 04:11:14PM +0000, Dima Dorfman wrote: > Please review the following change, from NetBSD: > > In icmp_reflect(): If the packet was not addressed to us and was > received on an interface without an IP address, try to find a > non-loopback AF_INET address to use. If that fails, drop it. > Previously, we used the address at the top of the in_ifaddrhead list, > which didn't make much sense, and would cause a panic if there were no > AF_INET addresses configured on the system. > > This fixes PRs 29337 and 30524. > Looks great. 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 Nov 23 8:38:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 2122037B405 for ; Fri, 23 Nov 2001 08:38:42 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id fANGaXI59028; Fri, 23 Nov 2001 10:36:33 -0600 (CST) (envelope-from jlemon) Date: Fri, 23 Nov 2001 10:36:33 -0600 (CST) From: Jonathan Lemon Message-Id: <200111231636.fANGaXI59028@prism.flugsvamp.com> To: serg@sirena2000.ru, net@freebsd.org Subject: Re: decreasing TIME_WAIT duration(T/TCP?) X-Newsgroups: local.mail.freebsd-net In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article you write: >Hello! > >It is important to me to have duration of TIME_WAIT state of TCP >connection as short time as possible. Tweak net.inet.tcp.msl, which specifies the 2MSL timeout. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 23 10:45:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 5182B37B405 for ; Fri, 23 Nov 2001 10:45:42 -0800 (PST) Received: from keg (ras33.isi.edu [128.9.176.133]) by boreas.isi.edu (8.11.6/8.11.2) with SMTP id fANIj5N14948; Fri, 23 Nov 2001 10:45:05 -0800 (PST) Reply-To: From: "Lars Eggert" To: "Jonathan Lemon" , , Subject: RE: decreasing TIME_WAIT duration(T/TCP?) Date: Fri, 23 Nov 2001 10:45:05 -0800 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200111231636.fANGaXI59028@prism.flugsvamp.com> Content-Type: multipart/signed; boundary="----=_NextPart_000_0015_01C1740B.E97EFB40"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C1740B.E97EFB40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > In article > you write: > >Hello! > > > >It is important to me to have duration of TIME_WAIT state of TCP > >connection as short time as possible. > > Tweak net.inet.tcp.msl, which specifies the 2MSL timeout. And know what you are doing, it's there for a reason. If you need to dramatically change this value, I'd wager your system would benefit from a design change. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California ------=_NextPart_000_0015_01C1740B.E97EFB40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5jCCArUw ggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEPMA0GA1UEBBMGRWdnZXJ0 MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFy c2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0AvLBsD78nxcUHeHkaMgl3b4 qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD11uZDy4CNNJUu3gKxKSb+zRV70O+lkwwf tuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcUSF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEA AaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREE ETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQ A8zI7U2K1ZIAl11j0a1DKxnp3GtTvOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2 OhB+jeKEqY7IDAJE4/fI0e+d6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4 fdcOo1S34r4wggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCB kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y 8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtU ihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN AQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONnt UPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2 lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKqMIICpgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFp bCBSU0EgMjAwMC44LjMwAgMFgUcwCQYFKw4DAhoFAKCCAWUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDExMTIzMTg0NTA1WjAjBgkqhkiG9w0BCQQxFgQUyYp2C3eh UYAsZGJuX9rroYmLzMkwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgasGCSsGAQQB gjcQBDGBnTCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZI hvcNAQEBBQAEgYBF4COKdB4pzwhT7VlpT/t/jJNJF54h+/yJimRuFWlU47BnHKllC1QG8CMa+mhp RtesGkHvp4nLGuq96xV5welQzReGl1LaNC6Bz5HL+bUlx0zFfddjSgG2FABC/H8ZDHk3jlnCkCJe ys/KaMDsK9+J+N0wxZfQTbgbZ7Cj0dRJNAAAAAAAAA== ------=_NextPart_000_0015_01C1740B.E97EFB40-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 23 18:10:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailrelay.netcologne.de (mailrelay.netcologne.de [194.8.194.96]) by hub.freebsd.org (Postfix) with ESMTP id 1162337B417; Fri, 23 Nov 2001 18:10:00 -0800 (PST) Received: from design.freestyling.de (design.freestyling.de [195.14.253.182]) by mailrelay.netcologne.de (8.11.6/8.11.6) with ESMTP id fAO29w726703; Sat, 24 Nov 2001 03:09:58 +0100 (MET) X-Received: from tick.sc.omation.com (64-58-167-31.cbi.cox-oc.net [64.58.167.31] (may be forged)) by design.freestyling.de (8.11.3/8.11.3) with ESMTP id fAO2D0284832 for ; Sat, 24 Nov 2001 03:13:00 +0100 (CET) (envelope-from pherman@frenchfries.net) X-Received: from tick.sc.omation.com (tick.sc.omation.com [192.168.128.2]) by tick.sc.omation.com (8.11.6/8.11.6) with ESMTP id fAO28ja01369; Fri, 23 Nov 2001 18:08:45 -0800 (PST) (envelope-from pherman@frenchfries.net) Date: Fri, 23 Nov 2001 18:08:45 -0800 (PST) From: Paul Herman X-X-Sender: To: Ruslan Ermilov Cc: Subject: Re: arp_rtrequest: bad gateway value In-Reply-To: <20011122113610.C32952@sunbay.com> Message-ID: <20011123160634.I49441-100000@tick.sc.omation.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [...off list...] On Thu, 22 Nov 2001, Ruslan Ermilov wrote: > On Wed, Nov 21, 2001 at 05:32:27PM -0800, Paul Herman wrote: > > Hi, > > > > I'd like to pick some brains before I file a PR. > > > There's already a PR open on this, kern/29170. > > [...] > > There's the problem with routed(8). It issues a command > similar to "route change ip ip" for each (but last) IP address > of an interface if the route already exists and is different. > This results in a changed route with AF_INET gateway, but > route's IFA still points to Ethernet device and > rt_ifa->ifa_rtrequest == arp_rtrequest. This results in this > message as AF_INET != AF_LINK. The message is harmless. Well this definately seems to me like bug in the kernel, because route_output()/arp_rtrequest() both allow me to change the gateway from a link addr to an inet addr, but still retain the RTF_LLINFO flag. This is an inconsistent state and should not be allowed. Correct me if I'm wrong, but is there any (historical) case where you would want this state? Possible solutions: 1) Ignore the change of the gateway if the AF_ type and RTF_ flags don't jive. 2) Return an EINVAL if you try to assign an AF_INET gateway to an existing route that has RTF_LLINFO set. 3) If an AF_INET gateway is given to an existing route with RTF_LLINFO set, try to convert the address to its link layer address, and then update the route. IMO, although #1 obeys POLA but might be to permissive, and #3 is probably to complicated for the kernel to do, so I think #2 might be best. Solution #2 would break routed, of course, so it would also have to be changed, as well. FWIW gated works fine and doesn't exhibit the same behaviour that routed does. Dunno about zebra, haven't checked. I'll be happy to see if I can whip up a patch, what does everyone else think? -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 24 13:41:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from www.brasapen.org (www.brasapen.org [193.78.174.81]) by hub.freebsd.org (Postfix) with ESMTP id 3579A37B416 for ; Sat, 24 Nov 2001 13:41:45 -0800 (PST) Received: by www.brasapen.org (Postfix, from userid 1000) id DBD381EC0; Sat, 24 Nov 2001 22:41:38 +0100 (CET) Date: Sat, 24 Nov 2001 22:41:38 +0100 From: eilko.bos@brasapen.org To: Thor Legvold Cc: billf@mu.org, freebsd-net@freebsd.org Subject: Re: Maximum throughput of Intel Pro 100/S NIC? Message-ID: <20011124224138.A21211@www.brasapen.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tlegvold@hotmail.com on Fri, Nov 23, 2001 at 11:14:37AM +0000 X-flatfee-nl: Flatfee internet4everyone in .nl, http://flatfee.nu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org From the keyboard of Thor Legvold, written on Fri, Nov 23, 2001 at 11:14:37AM +0000: > I guess this is the wrong place to learn more about networking & FBSD? Not per se. I purchased such a NIC (3 of them) just this week for use in the office. That is, I ordered Intel 100Mbit, I got 100/S. I will test it this week for performance, but I doubt it will give weird results. I think it must be either your environment or your interpretation of numbers. Another thing, it carries the 'S' in the name. It should be able to communicate via IPSec on the NIC. On the website I only found drivers for M$ OSses. You have to sign up for it, I (in all my honesty) got rejected because I am dutch, and the yankees still seem to have some stupid export restrictions on crypto ;(( So. That being said, I was wondering if somebody has been playing with this IPSec feature on FreeBSD allready. Maybe a bit off-topic. Grtz, -- Eilko Bos. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message