From owner-freebsd-net Sun Jul 16 0:56:51 2000 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 558) id 0018037BB4E; Sun, 16 Jul 2000 00:56:49 -0700 (PDT) To: freebsd-net@FreeBSD.ORG Subject: tcp slicing Message-Id: <20000716075649.0018037BB4E@hub.freebsd.org> Date: Sun, 16 Jul 2000 00:56:49 -0700 (PDT) From: hsu@FreeBSD.ORG (Jeffrey Hsu) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Has anyone done any work on TCP splicing under FreeBSD? If not, I'm going to go take a stab at it, so suggestions on api's, implementation strategies, etc. are welcome. Jeffrey References: http://www.cs.arizona.edu/scout/Papers/TR98-01.ps ftp://ftp.monarch.cs.cmu.edu/pub/dmaltz/splice-perf-tr.ps ftp://ftp.monarch.cs.cmu.edu/pub/dmaltz/TR-21147.ps http://www1.bell-labs.com/user/arielcohen/papers/usits99.ps To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 16 16: 0:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id F391637C002; Sun, 16 Jul 2000 16:00:16 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id QAA91769; Sun, 16 Jul 2000 16:00:16 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sun, 16 Jul 2000 16:00:16 -0700 (PDT) From: Kris Kennaway To: stable@freebsd.org, net@freebsd.org Subject: HEADS UP! Please test new KAME Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I meant to send this out yesterday, but forgot. I have merged the KAME code from -current, which brings 4.1 up to the most recent sources from the KAME project (http://www.kame.net). What does this give us? I'm glad you asked :-) * Signficantly improved IPSEC functionality. In particular, IPSEC security associations must no longer be manually keyed: the new code supports racoon, the KAME IKE daemon, which is located in /usr/ports/security/racoon. Racoon has been shown to interoperate well with other vendor IKE systems, meaning that FreeBSD 4.1 can be used in a heterogeneous IPSEC environment. However, racoon *is* still a work in progress, meaning that there may still be bugs, configuration syntax changes, etc. * About 9 months of fixes and improvements to the IPv6 code relative to what was previously in 4.0. * FreeBSD 4.1 can now be installed on an IPv6-only network - this will be the first release of FreeBSD that never needs to operate using IPv4 at all! ftp7.jp.freebsd.org (Japan #7) is an IPv6-reachable mirror site for installation and package-fetching. * Several additional system utilities (whois, fetch, and possibly others) have gained the ability to operate over IPv6. * FreeBSD 4.1 will ship with numerous IPv6-ready packages including web servers and browsers, all manner of network clients (FTP, IRC, SSH, ...) and network tools. See http://www.freebsd.org/ports/ipv6.html for a list of IPv6-capable ports. * One useful feature of KAME which has not yet been merged across is the ALTQ traffic-shaping system - I hope to get this in time for 4.2. The more experimental KAME code has also not been merged. If you need those features, I suggest you make use of the KAME snapshots from www.kame.net which will become available after 4.1-RELEASE. * I am sure I have forgotten some of the features of the new code :-) The merged changes have been tested in -current for several weeks without incident. The only known problem is that NFS mounts over IPSEC do not seem to work reliably (in my testing environment, at least) - I have seen eventual hangs with IPSEC/ESP mounts and possible data corruption with IPSEC/AH. However, there's of course no way for me to have tested everything, so there may still be bugs which affect operation. There are still 9 days until the scheduled release of 4.1-RELEASE in which to find and correct problems, so I respectfully ask all of you who can test the new code to please do as much as you can *now*, while there's still time, and not after the release has been rolled when it's too late. Thanks! On behalf of the FreeBSD community, I would like to thank the KAME developer team for their tireless work and dedication to the BSD community, and in particular the efforts of Hagino-san, Umemoto-san and Sumikawa-san (I hope I'm not forgetting anyone) for bringing the latest code into FreeBSD. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 16 17:48:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from dune.clickarray.com (mail.puretek.com [216.174.91.46]) by hub.freebsd.org (Postfix) with ESMTP id 3F5BA37B72E for ; Sun, 16 Jul 2000 17:48:36 -0700 (PDT) (envelope-from sshah@dune.clickarray.com) Received: (from sshah@localhost) by dune.clickarray.com (8.9.3/8.9.3) id RAA19973 for freebsd-net@freebsd.org; Sun, 16 Jul 2000 17:47:45 -0700 Date: Sun, 16 Jul 2000 17:47:45 -0700 From: Steve Shah To: freebsd-net@freebsd.org Subject: Re: IPsec performance (Re: Merge of KAME code) Message-ID: <20000716174745.A19964@clickarray.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > : > TCP STREAM TEST UDP STREAM TEST > : > NONE: 60Mbps NONE: 94Mbps > : > AH: 23Mbps AH: 30Mbps > : > ESP: 11Mbps ESP: 11Mbps > : > AH+ESP: 8Mbps AH+ESP: 9Mbps What was the speed of the processor that this test was run under? -Steve -- ___________________________________________________________________________ Steve Shah (sshah@clickarray.com) | Developer/Systems Administrator/Author http://www.clickarray.com | Voice: 408.772.8202 (e-mail preferred) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Beating code into submission, one OS at a time... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 17 16:21: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by hub.freebsd.org (Postfix) with ESMTP id EC81437B512 for ; Mon, 17 Jul 2000 16:20:54 -0700 (PDT) (envelope-from gcorcoran@lucent.com) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA17401 for ; Mon, 17 Jul 2000 19:20:54 -0400 (EDT) Received: from mhmail.mh.lucent.com (h135-3-115-8.lucent.com [135.3.115.8]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA17395; Mon, 17 Jul 2000 19:20:53 -0400 (EDT) Received: from lucent.com by mhmail.mh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id TAA14581; Mon, 17 Jul 2000 19:20:51 -0400 (EDT) Message-ID: <397394D5.37D2E2FF@lucent.com> Date: Mon, 17 Jul 2000 19:20:53 -0400 From: "Gary T. Corcoran" Organization: Lucent Microelectronics - Client Access Broadband Systems X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Somers , FreeBSD Network List Subject: Win2000 -> FreeBSD PPPoE daemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brian (and other -net PPP experts), We are trying to test our PPP over Ethernet (over DSL) driver on Windows2000, talking to a FreeBSD (4.0) machine running pppoed. The PPPoE part itself is working fine. Basically, our driver does the PPPoE negotiation, and then we tie into the Microsoft PPP stack. This setup works fine on Win98, but when we tried Win2000, we aren't able to establish a PPP session. We're set to use a fixed IP address, and the IP address negotiation sort of works, but then pppoed keeps trying to get us to use an address of 0.0.0.0, which keeps getting rejected by our side, and eventually it gives up and terminates the PPP session. I got a debug log on our client, and decoded (by hand) the PPP session (after the LCP phase) to see this exchange: (this is viewed from the client end) Transmitted PPP Packet: IPCP: Configure-Request: VJ Compression, IP Address 123.45.99.105, Primary DNS 0.0.0.0, Primary NetBIOS Name Server 0.0.0.0, Secondary DNS 0.0.0.0 ... Received PPP Packet: Protocol 0x80FD (unknown to me), hex contents: 01 01 00 0A 1A 04 78 00 01 02 Received PPP Packet: IPCP: Configure-Request: IP Address 0.0.0.0, VJ Compression, Primary DNS 128.94.100.20, Secondary DNS 128.94.102.150 Received PPP Packet: LCP: Code-Reject: Original hex packet: 0C 02 00 12 56 44 21 F0 4D 53 52 41 53 56 35 2E 30 30 Decode of original packet = Identification: Magic Number 0x564421F0, String "MSRASV5.00" Received PPP Packet: LCP: Code-Reject: Original Hex packet:0C 03 00 19 56 44 21 F0 4D 53 52 41 53 2D 31 2D 47 52 45 45 4E 42 41 59 Decode of original packet = Identification: Magic Number 0x564421F0, String "MSRAS-1-GREENBAY" Received PPP Packet: IPCP: Configure-Reject: Primary DNS 0.0.0.0, Primary NetBIOS Name Server 0.0.0.0, Secondary DNS Address 0.0.0.0, Secondary NetBIOS Name Server 0.0.0.0 Transmitted PPP Packet: LCP: Protocol-Reject: Protocol 80FD, Original hex packet: 01 01 00 0A 1A 04 78 00 01 02 Transmitted PPP Packet: IPCP: Configure-Reject: IP Address 0.0.0.0, Primary DNS 128.94.100.20, Secondary DNS 128.94.102.150 Transmitted PPP Packet: IPCP: Configure-Request: VJ Compression, IP Address 123.45.99.105 Received PPP Packet: IPCP: Configure-Request: IP Address 0.0.0.0, VJ Compression Received PPP Packet: IPCP: Configure-Ack: VJ Compression, IP Address 123.45.99.105 Transmitted PPP Packet: IPCP: Configure-Reject: IP Address 0.0.0.0 Received PPP Packet: IPCP: Configure-Request: IP Address 0.0.0.0, VJ Compression Transmitted PPP Packet: IPCP: Configure-Reject: IP Address 0.0.0.0 Received PPP Packet: IPCP: Configure-Request: IP Address 0.0.0.0, VJ Compression Transmitted PPP Packet: IPCP: Configure-Reject: IP Address 0.0.0.0 Received PPP Packet: IPCP: Configure-Request: IP Address 0.0.0.0, VJ Compression Transmitted PPP Packet: IPCP: Configure-Reject: IP Address 0.0.0.0 Received PPP Packet: IPCP: Configure-Request: IP Address 0.0.0.0, VJ Compression Transmitted PPP Packet: IPCP: Terminate-Request: Hex-Message 56 44 21 F0 00 3C CD 74 00 00 02 DC Received PPP Packet: IPCP: Terminate-Ack Since we can't "fix" Windows 2000 PPP code, is there something that the FreeBSD PPP is getting "confused" about due to the Win2000 implementation that can be fixed? Thanks, Gary -- ========================================================= Gary Corcoran - Distinguished Member of Technical Staff Lucent Microelectronics - Client Access Broadband Systems Communications Protocol & Driver Development Group "We make the drivers that make communications work" Email: gcorcoran@lucent.com ========================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 17 16:46:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id E8AD737B7EC for ; Mon, 17 Jul 2000 16:46:31 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id AAA23391; Tue, 18 Jul 2000 00:42:56 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id AAA84248; Tue, 18 Jul 2000 00:42:15 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200007172342.AAA84248@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Gary T. Corcoran" Cc: Brian Somers , FreeBSD Network List , brian@Awfulhak.org Subject: Re: Win2000 -> FreeBSD PPPoE daemon In-Reply-To: Message from "Gary T. Corcoran" of "Mon, 17 Jul 2000 19:20:53 EDT." <397394D5.37D2E2FF@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jul 2000 00:42:14 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, It sounds like you haven't done a set ifaddr something hisnumber in your config. Without this, if the peer asks for 0.0.0.0, ppp will just say ``yeah, fine, I don't know any better''. Make ``hisnumber'' whatever you want him to use and make ``something'' whatever you want to use locally - probably just your NIC iface IP address (dups are ok as long as only one is a broadcast device). > Brian (and other -net PPP experts), > > We are trying to test our PPP over Ethernet (over DSL) driver > on Windows2000, talking to a FreeBSD (4.0) machine running pppoed. > The PPPoE part itself is working fine. Basically, our driver > does the PPPoE negotiation, and then we tie into the Microsoft > PPP stack. This setup works fine on Win98, but when we tried > Win2000, we aren't able to establish a PPP session. > > We're set to use a fixed IP address, and the IP address negotiation > sort of works, but then pppoed keeps trying to get us to use an > address of 0.0.0.0, which keeps getting rejected by our side, > and eventually it gives up and terminates the PPP session. > > I got a debug log on our client, and decoded (by hand) the > PPP session (after the LCP phase) to see this exchange: > (this is viewed from the client end) > > Transmitted PPP Packet: IPCP: Configure-Request: VJ Compression, > IP Address 123.45.99.105, Primary DNS 0.0.0.0, > Primary NetBIOS Name Server 0.0.0.0, > Secondary DNS 0.0.0.0 ... > Received PPP Packet: Protocol 0x80FD (unknown to me), > hex contents: 01 01 00 0A 1A 04 78 00 01 02 > Received PPP Packet: IPCP: Configure-Request: IP Address 0.0.0.0, > VJ Compression, Primary DNS 128.94.100.20, > Secondary DNS 128.94.102.150 > Received PPP Packet: LCP: Code-Reject: Original hex > packet: 0C 02 00 12 56 44 21 F0 4D 53 52 41 53 56 35 2E 30 30 > Decode of original packet = Identification: Magic Number 0x564421F0, > String "MSRASV5.00" > Received PPP Packet: LCP: Code-Reject: Original Hex > packet:0C 03 00 19 56 44 21 F0 4D 53 52 41 53 2D 31 2D 47 52 45 45 4E 42 41 59 > Decode of original packet = Identification: Magic Number 0x564421F0, > String "MSRAS-1-GREENBAY" > Received PPP Packet: IPCP: Configure-Reject: Primary DNS 0.0.0.0, > Primary NetBIOS Name Server 0.0.0.0, > Secondary DNS Address 0.0.0.0, > Secondary NetBIOS Name Server 0.0.0.0 > Transmitted PPP Packet: LCP: Protocol-Reject: Protocol 80FD, > Original hex packet: 01 01 00 0A 1A 04 78 00 01 02 > Transmitted PPP Packet: IPCP: Configure-Reject: IP Address 0.0.0.0, > Primary DNS 128.94.100.20, > Secondary DNS 128.94.102.150 > Transmitted PPP Packet: IPCP: Configure-Request: VJ Compression, > IP Address 123.45.99.105 > Received PPP Packet: IPCP: Configure-Request: IP Address 0.0.0.0, > VJ Compression > Received PPP Packet: IPCP: Configure-Ack: VJ Compression, > IP Address 123.45.99.105 > Transmitted PPP Packet: IPCP: Configure-Reject: IP Address 0.0.0.0 > Received PPP Packet: IPCP: Configure-Request: IP Address 0.0.0.0, > VJ Compression > Transmitted PPP Packet: IPCP: Configure-Reject: IP Address 0.0.0.0 > Received PPP Packet: IPCP: Configure-Request: IP Address 0.0.0.0, > VJ Compression > Transmitted PPP Packet: IPCP: Configure-Reject: IP Address 0.0.0.0 > Received PPP Packet: IPCP: Configure-Request: IP Address 0.0.0.0, > VJ Compression > Transmitted PPP Packet: IPCP: Configure-Reject: IP Address 0.0.0.0 > Received PPP Packet: IPCP: Configure-Request: IP Address 0.0.0.0, > VJ Compression > Transmitted PPP Packet: IPCP: Terminate-Request: > Hex-Message 56 44 21 F0 00 3C CD 74 00 00 02 DC > Received PPP Packet: IPCP: Terminate-Ack > > Since we can't "fix" Windows 2000 PPP code, is there something > that the FreeBSD PPP is getting "confused" about due to the > Win2000 implementation that can be fixed? > > Thanks, > Gary > -- > ========================================================= > Gary Corcoran - Distinguished Member of Technical Staff > Lucent Microelectronics - Client Access Broadband Systems > Communications Protocol & Driver Development Group > "We make the drivers that make communications work" > Email: gcorcoran@lucent.com > ========================================================= > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 17 17: 3: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by hub.freebsd.org (Postfix) with ESMTP id 8763137B75A for ; Mon, 17 Jul 2000 17:02:57 -0700 (PDT) (envelope-from gcorcoran@lucent.com) Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA16855 for ; Mon, 17 Jul 2000 20:02:55 -0400 (EDT) Received: from mhmail.mh.lucent.com (h135-3-115-8.lucent.com [135.3.115.8]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA16844; Mon, 17 Jul 2000 20:02:54 -0400 (EDT) Received: from lucent.com by mhmail.mh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id UAA17364; Mon, 17 Jul 2000 20:02:53 -0400 (EDT) Message-ID: <39739EB0.229E8CEE@lucent.com> Date: Mon, 17 Jul 2000 20:02:56 -0400 From: "Gary T. Corcoran" Organization: Lucent Microelectronics - Client Access Broadband Systems X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Somers Cc: FreeBSD Network List Subject: Re: Win2000 -> FreeBSD PPPoE daemon References: <200007172342.AAA84248@hak.lan.Awfulhak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Brian, Thanks for the quick response (it's late where you live, isn't it? :-) > It sounds like you haven't done a > > set ifaddr something hisnumber > > in your config. Without this, if the peer asks for 0.0.0.0, ppp will > just say ``yeah, fine, I don't know any better''. Make ``hisnumber'' > whatever you want him to use and make ``something'' whatever you want > to use locally - probably just your NIC iface IP address (dups are ok > as long as only one is a broadcast device). We'll try that tomorrow (the test equipment is 65 miles away and my testing buddy has gone home :). But the curious thing(s) is that this *same* setup, with no changes on the FreeBSD end, works as-is with Win98 (with the same Windows settings). Also, did you see the part in the trace where we asked for the specific IP address and FreeBSD did ack that configuration? If it's just a server setup problem, that's fine, we'll change it. But I'm just curious as to what's going on... BTW, just out of curiousity, why does FreeBSD reject the identification packets? Does it really not understand them? Thanks, Gary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 17 21:42:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 52C4737BA9E; Mon, 17 Jul 2000 21:42:09 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id VAA16262; Mon, 17 Jul 2000 21:42:09 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Mon, 17 Jul 2000 21:42:09 -0700 (PDT) From: Kris Kennaway To: Steve Shah Cc: freebsd-net@freebsd.org Subject: Re: IPsec performance (Re: Merge of KAME code) In-Reply-To: <20000716174745.A19964@clickarray.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 16 Jul 2000, Steve Shah wrote: > What was the speed of the processor that this test was run under? You apparently missed the original message, quoted below: ---- I used to benchmarked IPsec performance on following platform with netperf. - PentiumIII 500MHz - 256MB Memory - Intel Ether Express Pro 100 (100Mbps) - FreeBSD 2.2.8 - KAME 19990809 stable - connect two machines directly - IPv4 - IPsec transport mode - ESP with 3DES-CBC - AH with HMAC-SHA1 And the results are about, TCP STREAM TEST UDP STREAM TEST NONE: 60Mbps NONE: 94Mbps AH: 23Mbps AH: 30Mbps ESP: 11Mbps ESP: 11Mbps AH+ESP: 8Mbps AH+ESP: 9Mbps P.S. The same tests with IPv6 produced almost the same results. // ARIGA Seiji ---- Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 17 22: 7:12 2000 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 SMTP id C174637B9F9 for ; Mon, 17 Jul 2000 22:07:09 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 25792 invoked by uid 1000); 18 Jul 2000 05:07:09 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Jul 2000 05:07:09 -0000 Date: Tue, 18 Jul 2000 00:07:09 -0500 (CDT) From: Mike Silbersack To: itojun@iijlab.net Cc: ARIGA Seiji , freebsd-net@FreeBSD.ORG, lconrad@Go2France.com, kris@FreeBSD.ORG Subject: Re: IPsec Performance (Re: Merge of KAME code) In-Reply-To: <7693.963643060@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 15 Jul 2000 itojun@iijlab.net wrote: > >Question. Is the time spent in the IPSec layer accounted to the user > >processor, or just thrown in with kernel time? > > the current IPsec code does encryption (like actual DES/3DES encryption > of the packet) in the kernel, so it will appear as kernel time. > > itojun Hm, that worries me some, as it seems to be saying that if I allow IPSEC connections from anywhere to any service, I'm leaving the box open to pummeling by anyone with an IPSEC system. On the positive side, it sounds like the openbsd guys decoupled the actual decoding from the packet receive when they implemented their hardware IPSEC engine. So, if that gets ported over here, perhaps the problem can be delt with effectievly. 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 Jul 18 0:42:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from decoy.sfc.keio.ac.jp (decoy.sfc.keio.ac.jp [133.27.84.101]) by hub.freebsd.org (Postfix) with ESMTP id 615D737BBCB for ; Tue, 18 Jul 2000 00:42:50 -0700 (PDT) (envelope-from say@sfc.wide.ad.jp) Received: from localhost (localhost.sfc.keio.ac.jp [127.0.0.1]) by decoy.sfc.keio.ac.jp (8.9.3/8.9.3) with ESMTP id QAA33205 for ; Tue, 18 Jul 2000 16:41:49 +0900 (JST) (envelope-from say@sfc.wide.ad.jp) In-Reply-To: <20000716174745.A19964@clickarray.com> References: <20000716174745.A19964@clickarray.com> X-PGP-Publickey: http://decoy.sfc.keio.ac.jp/~say/key.txt X-PGP-Fingerprint: 8E 70 AB 20 44 E6 8A 8A 1C 49 B3 30 44 1B B3 BA Subject: Re: IPsec performance (Re: Merge of KAME code) From: ARIGA Seiji To: freebsd-net@FreeBSD.ORG X-Mailer: Mew version 1.95b3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000718164148U.say@decoy.sfc.keio.ac.jp> Date: Tue, 18 Jul 2000 16:41:48 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 34 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 16 Jul 2000 17:47:45 -0700, Steve Shah wrote, : > : > TCP STREAM TEST UDP STREAM TEST : > : > NONE: 60Mbps NONE: 94Mbps : > : > AH: 23Mbps AH: 30Mbps : > : > ESP: 11Mbps ESP: 11Mbps : > : > AH+ESP: 8Mbps AH+ESP: 9Mbps : What was the speed of the processor that this test was run under? Hi, as I wrote in <20000713032922M.say@decoy.sfc.keio.ac.jp>, there were three actors. HOST - ROUTER - HOST Router didn't do any IPsec. HOST specification was, - PentiumII 450MHz - 128MB Memory - Intel Ether Express Pro 100 (100Mbps) - FreeBSD 2.2.8 - KAME 19990809 stable ROUTER specification was, - PentiumIII 500MHz - 256MB Memory - Intel Ether Express Pro 100 (100Mbps) - FreeBSD 2.2.8 - KAME 19990809 stable Regards, // ARIGA Seiji To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 2: 4: 1 2000 Delivered-To: freebsd-net@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id F260D37B6DC for ; Tue, 18 Jul 2000 02:03:55 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id KAA32938; Tue, 18 Jul 2000 10:03:52 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id IAA19521; Tue, 18 Jul 2000 08:51:22 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200007180751.IAA19521@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Gary T. Corcoran" Cc: Brian Somers , FreeBSD Network List , brian@Awfulhak.org Subject: Re: Win2000 -> FreeBSD PPPoE daemon In-Reply-To: Message from "Gary T. Corcoran" of "Mon, 17 Jul 2000 20:02:56 EDT." <39739EB0.229E8CEE@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jul 2000 08:51:21 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Hi Brian, > > Thanks for the quick response (it's late where you live, > isn't it? :-) > > > It sounds like you haven't done a > > > > set ifaddr something hisnumber > > > > in your config. Without this, if the peer asks for 0.0.0.0, ppp will > > just say ``yeah, fine, I don't know any better''. Make ``hisnumber'' > > whatever you want him to use and make ``something'' whatever you want > > to use locally - probably just your NIC iface IP address (dups are ok > > as long as only one is a broadcast device). > > We'll try that tomorrow (the test equipment is 65 miles away > and my testing buddy has gone home :). Looking at things a bit more carefully, it looks like the ``something'' bit is what's missing. ppp(8) is sending REQs with 0.0.0.0 (saying ``I'd like to have IP 0.0.0.0 please''). Perhaps you've got ``set ifaddr 0 0'' in your config ? If so, you can probably get away with just removing that line. The default is ``set ifaddr MYADDR 0''. > But the curious thing(s) is that this *same* setup, with no > changes on the FreeBSD end, works as-is with Win98 (with the > same Windows settings). This is strange. Win98 must be assigning ppp(8) an IP number, or maybe it's letting it have 0.0.0.0 and is managing to route through it. ppp(8) doesn't care about it's local interface address (although I would have guessed that things would go wrong if it ended up with 0.0.0.0). > Also, did you see the part in the trace where we asked for > the specific IP address and FreeBSD did ack that configuration? Not until now :-/ It looks like the problem is that ppp(8) is requesting 0.0.0.0 and Win2000 is (correctly) saying ``don't be silly''. > If it's just a server setup problem, that's fine, we'll change > it. But I'm just curious as to what's going on... > > BTW, just out of curiousity, why does FreeBSD reject the > identification packets? Does it really not understand them? Never heard of them... I take it these are Multi-link Procedure options ? I'll stick this on my todo list I guess :-) > Thanks, > Gary Cheers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 2:47:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from keep.scn.ru (SCN-SibInet.sibinet.ru [213.24.217.138]) by hub.freebsd.org (Postfix) with ESMTP id 77A1337BC97 for ; Tue, 18 Jul 2000 02:47:03 -0700 (PDT) (envelope-from smith@scn.ru) Received: from scn.ru (quick.sc.ten [10.0.0.7]) by keep.scn.ru (8.9.3/8.9.3) with ESMTP id RAA38829 for ; Tue, 18 Jul 2000 17:47:11 +0800 (KRAST) Message-ID: <39745F45.D441D899@scn.ru> Date: Tue, 18 Jul 2000 17:44:37 +0400 From: "Vladimir N. Kovalev" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: TAU-PCI-E1 and NETGRAPH Frame Relay Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello ! During a one week ago I'm trying to install syncronous E1 card from Cronyx Engineering (www.cronyx.ru) Tau-PCI-E1 into my FreeBSD 4.0-STABLE server and connect it to IPTL Radwiz System via Frame Relay. . But without success. First of all, I install Tau drivers v 3.33 according the instruction and put into kernell config file some parameters for NETGRAPH and this card. Looks like options NETGRAPH options NETGRAPH_CRONYX # Netgraph mode options NETGRAPH_FRAME_RELAY options NETGRAPH_LMI ..... # Cronyx-Tau-PCI adapter(s). device cp0 After recompile kernel and reboot system I saw, that Unix detect this card /kernel: cp0: mem 0xe4000000-0xe400ffff,0xe4010000-0xe40107ff irq 9 at device 11.0 on pci0 /kernel: cp0: Tau-PCI-E1, clock 16 MHz Fine. Then, I set some parameters for card like syncronization, time slots and CRC. sconfig cp0 syn=rcv crc4=on use16=on ts=1-31 And execute following command for the NETGRAPH # create a frame_relay type node and attach it to the sync port. ngctl mkpeer cp0: frame_relay rawdata downstream # Attach the dlci output of the (de)multiplexor to a new # Link management protocol node. ngctl mkpeer cp0:rawdata lmi dlci0 auto0 # Attach the DLCI(channel) the Telco has assigned you to # a node to hadle whatever protocol encapsulation your peer # is using. In this case rfc1490 encapsulation. ngctl mkpeer cp0:rawdata rfc1490 dlci100 downstream # Attach the ip (inet) protocol output of the protocol mux to the ip (inet) # input of a netgraph "interface" node (ifconfig should show it as "ng0"). #if interface ng0 needs to be created use a mkpeer command.. e.g. ngctl mkpeer cp0:rawdata.dlci100 iface inet inet # Then use ifconfig on interface ng0 as usual ifconfig ng0 10.0.4.2 10.0.4.1 netmask 255.255.255.252 As result of this manipulation all signals on Tau turn on. /var/log > sconfig -i cp0 idle cfg=A 1984000 syn=rcv higain=off use16=on crc4=off loop=off ts=1-31 /var/log > sconfig -m Channel LE DTR DSR RTS CTS CD cp0 On On On On On On Unfortunetly, I have no replay on ping to 10.0.4.1 yet. But in /var/log/messages I find such strings Jul 18 09:35:48 tau /kernel: nglmi: unexpected message type(0x0) Jul 18 09:35:49 tau /kernel: nglmi: error at location 3 Jul 18 09:35:49 tau /kernel: nglmi: packet data: 03 08 00>75 95 01 01 00 03 02 0b 00 Jul 18 09:35:49 tau /kernel: nglmi: no response from exchange Jul 18 09:35:59 tau /kernel: nglmi: unexpected message type(0x0) Jul 18 09:35:59 tau /kernel: nglmi: error at location 3 Jul 18 09:35:59 tau /kernel: nglmi: packet data: 03 08 00>75 95 01 01 00 03 02 0c 00 Anybody know that does this message mean ? Or there I make mistake ? Thanks in advance. Best regards Vladimir N. Kovalev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 7:25:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from sr14.nsw-remote.bigpond.net.au (sr14.nsw-remote.bigpond.net.au [24.192.3.29]) by hub.freebsd.org (Postfix) with ESMTP id DF2CD37B61F for ; Tue, 18 Jul 2000 07:25:36 -0700 (PDT) (envelope-from areilly@nsw.bigpond.net.au) Received: from areilly.bpc-users.org (CPE-144-132-171-71.nsw.bigpond.net.au [144.132.171.71]) by sr14.nsw-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id XAA24523 for ; Tue, 18 Jul 2000 23:10:29 +1000 (EST) Received: (qmail 17864 invoked by uid 1000); 18 Jul 2000 13:10:31 -0000 From: "Andrew Reilly" Date: Tue, 18 Jul 2000 23:10:31 +1000 To: freebsd-net@freebsd.org Cc: Archie Cobbs Subject: mpd-netgraph port vs Windows-2000 PPTP vpn Message-ID: <20000718231031.A16524@gurney.reilly.home> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I've recently built new world and kernel so that I could try the mpd-netgraph port. (My system is now FreeBSD gurney.reilly.home 4.1-RC FreeBSD 4.1-RC #0: Sun Jul 16 10:19:08 EST 2000 root@gurney.reilly.home:/usr/obj/usr/src/sys/GURNEY i386 ) I've gone this way after discovering that the pptpclient port was having trouble connecting to my office's windows-2000 PPTP server (see http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=415346+417548+/usr/local/www/db/text/2000/freebsd-stable/20000709.freebsd-stable) As a reference point, I can successfully connect to this VPN with the dial-up-networking in my Windows-98 laptop, even through my FreeBSD firewall box, thanks to a "-redirect_proto gre" argument to natd... so I know my login name and password. Mpd seems like a wonderful system, and it seems to get much further with the authentication stuff than ppp did, but still not all the way. Any suggestions? It seems possible, given the discussion in the mpd documentation, that my office's Win2000 system might be using the STACK and mppc bits. Is it possible to aquire these at all, or is this something only available internally to Whistle? Exhibit (a) is my mpd.config file, (b) is my mpd.links file, and (c) is the mpd.log trace of my most recent login attempt. Oh: documentation bug report: should the first command in section 4.4 "IPCP layer commands" in the manual read "set ipcp ranges ..." instead of "set iface ranges ..." as it currently does? -- Andrew --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mpd.conf" vpn: new -i ng1 vpn vpn set bundle no multilink set bundle authname andrew # set bundle enable compression # set bundle enable crypt-reqd set iface disable on-demand set iface idle 0 set iface route 192.168.10.0/23 set ipcp ranges 192.168.10.0/23 192.168.10.0/23 set ipcp yes vjcomp set ipcp yes req-pri-dns set ipcp yes req-sec-dns set ipcp yes req-pri-nbns set ipcp yes req-sec-nbns set link enable no-orig-auth set link keep-alive 10 75 set link max-redial 1 set link yes acfcomp protocomp set link no pap set link yes chap # set ccp yes stac # set ccp yes mppc # set ccp yes mpp-compress set ccp yes mpp-e40 set ccp yes mpp-e128 # set ccp yes mpp-stateless # set ecp yes des open --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mpd.links" vpn: set link type pptp set pptp self 144.132.171.71 set pptp peer 210.8.75.9 set pptp enable originate outcall set pptp disable incoming --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mpd.log" Jul 18 22:48:12 gurney mpd: [vpn] device: OPEN event in state DOWN Jul 18 22:48:12 gurney mpd: pptp0: connecting to 210.8.75.9:1723 Jul 18 22:48:12 gurney mpd: [vpn] device is now in state OPENING Jul 18 22:48:12 gurney mpd: pptp0: connected to 210.8.75.9:1723 Jul 18 22:48:12 gurney mpd: pptp0: attached to connection with 210.8.75.9:1723 Jul 18 22:49:16 gurney mpd: pptp0-0: outgoing call connected at -2137614336 bps Jul 18 22:49:16 gurney mpd: [vpn] PPTP call successful Jul 18 22:49:16 gurney mpd: [vpn] device: UP event in state OPENING Jul 18 22:49:16 gurney mpd: [vpn] device is now in state UP Jul 18 22:49:16 gurney mpd: [vpn] link: UP event Jul 18 22:49:16 gurney mpd: [vpn] link: origination is local Jul 18 22:49:16 gurney mpd: [vpn] LCP: Up event Jul 18 22:49:16 gurney mpd: [vpn] LCP: state change Starting --> Req-Sent Jul 18 22:49:16 gurney mpd: [vpn] LCP: phase shift DEAD --> ESTABLISH Jul 18 22:49:16 gurney mpd: [vpn] LCP: SendConfigReq #3 Jul 18 22:49:16 gurney mpd: ACFCOMP Jul 18 22:49:16 gurney mpd: PROTOCOMP Jul 18 22:49:16 gurney mpd: MRU 1500 Jul 18 22:49:16 gurney mpd: MAGICNUM cc944b06 Jul 18 22:49:16 gurney mpd: AUTHPROTO CHAP MSOFT Jul 18 22:49:16 gurney mpd: [vpn] LCP: rec'd Configure Request #0 link 0 (Req-Sent) Jul 18 22:49:16 gurney mpd: AUTHPROTO 0xc227 Jul 18 22:49:16 gurney mpd: MAGICNUM 1f174827 Jul 18 22:49:16 gurney mpd: PROTOCOMP Jul 18 22:49:16 gurney mpd: ACFCOMP Jul 18 22:49:16 gurney mpd: CALLBACK Jul 18 22:49:16 gurney mpd: Not supported Jul 18 22:49:16 gurney mpd: MP MRRU 1614 Jul 18 22:49:16 gurney mpd: ENDPOINTDISC [LOCAL] 35 02 eb 33 73 42 4c 06 8b ff e9 df 07 a9 ef 39 00 00 00 00 Jul 18 22:49:16 gurney mpd: UNKNOWN[23] len=4 Jul 18 22:49:16 gurney mpd: [vpn] LCP: SendConfigRej #0 Jul 18 22:49:16 gurney mpd: CALLBACK Jul 18 22:49:16 gurney mpd: MP MRRU 1614 Jul 18 22:49:16 gurney mpd: UNKNOWN[23] len=4 Jul 18 22:49:16 gurney mpd: [vpn] LCP: rec'd Configure Ack #3 link 0 (Req-Sent) Jul 18 22:49:16 gurney mpd: ACFCOMP Jul 18 22:49:16 gurney mpd: PROTOCOMP Jul 18 22:49:16 gurney mpd: MRU 1500 Jul 18 22:49:16 gurney mpd: MAGICNUM cc944b06 Jul 18 22:49:16 gurney mpd: AUTHPROTO CHAP MSOFT Jul 18 22:49:16 gurney mpd: [vpn] LCP: state change Req-Sent --> Ack-Rcvd Jul 18 22:49:16 gurney mpd: [vpn] LCP: rec'd Configure Request #1 link 0 (Ack-Rcvd) Jul 18 22:49:16 gurney mpd: AUTHPROTO 0xc227 Jul 18 22:49:16 gurney mpd: MAGICNUM 1f174827 Jul 18 22:49:16 gurney mpd: PROTOCOMP Jul 18 22:49:16 gurney mpd: ACFCOMP Jul 18 22:49:16 gurney mpd: ENDPOINTDISC [LOCAL] 35 02 eb 33 73 42 4c 06 8b ff e9 df 07 a9 ef 39 00 00 00 00 Jul 18 22:49:16 gurney mpd: [vpn] LCP: SendConfigNak #1 Jul 18 22:49:16 gurney mpd: AUTHPROTO CHAP MD5 Jul 18 22:49:16 gurney mpd: [vpn] LCP: rec'd Configure Request #2 link 0 (Ack-Rcvd) Jul 18 22:49:16 gurney mpd: AUTHPROTO CHAP MD5 Jul 18 22:49:16 gurney mpd: MAGICNUM 1f174827 Jul 18 22:49:16 gurney mpd: PROTOCOMP Jul 18 22:49:16 gurney mpd: ACFCOMP Jul 18 22:49:16 gurney mpd: ENDPOINTDISC [LOCAL] 35 02 eb 33 73 42 4c 06 8b ff e9 df 07 a9 ef 39 00 00 00 00 Jul 18 22:49:16 gurney mpd: [vpn] LCP: SendConfigAck #2 Jul 18 22:49:16 gurney mpd: AUTHPROTO CHAP MD5 Jul 18 22:49:16 gurney mpd: MAGICNUM 1f174827 Jul 18 22:49:16 gurney mpd: PROTOCOMP Jul 18 22:49:16 gurney mpd: ACFCOMP Jul 18 22:49:16 gurney mpd: ENDPOINTDISC [LOCAL] 35 02 eb 33 73 42 4c 06 8b ff e9 df 07 a9 ef 39 00 00 00 00 Jul 18 22:49:16 gurney mpd: [vpn] LCP: state change Ack-Rcvd --> Opened Jul 18 22:49:16 gurney mpd: [vpn] LCP: phase shift ESTABLISH --> AUTHENTICATE Jul 18 22:49:16 gurney mpd: [vpn] LCP: auth: peer wants CHAP, I want CHAP Jul 18 22:49:16 gurney mpd: [vpn] CHAP: sending CHALLENGE Jul 18 22:49:16 gurney mpd: [vpn] LCP: LayerUp Jul 18 22:49:16 gurney mpd: pptp0: CID 0xa525 in SetLinkInfo not found Jul 18 22:49:16 gurney mpd: [vpn] CHAP: rec'd CHALLENGE #0 Jul 18 22:49:16 gurney mpd: Name: "FIREWALL" Jul 18 22:49:16 gurney mpd: Using authname "andrew" Jul 18 22:49:16 gurney mpd: [vpn] CHAP: sending RESPONSE Jul 18 22:49:16 gurney mpd: [vpn] CHAP: rec'd FAILURE #0 Jul 18 22:49:16 gurney mpd: [vpn] LCP: authorization failed Jul 18 22:49:16 gurney mpd: [vpn] device: CLOSE event in state UP Jul 18 22:49:16 gurney mpd: pptp0-0: clearing call Jul 18 22:49:16 gurney mpd: [vpn] device is now in state CLOSING Jul 18 22:49:16 gurney mpd: [vpn] LCP: rec'd Terminate Request #4 link 0 (Opened) Jul 18 22:49:16 gurney mpd: [vpn] LCP: state change Opened --> Stopping Jul 18 22:49:16 gurney mpd: [vpn] LCP: phase shift AUTHENTICATE --> TERMINATE Jul 18 22:49:16 gurney mpd: [vpn] LCP: SendTerminateAck #4 Jul 18 22:49:16 gurney mpd: [vpn] error writing len 8 frame to bypass: Network is down Jul 18 22:49:16 gurney mpd: [vpn] LCP: LayerDown Jul 18 22:49:16 gurney mpd: [vpn] device: DOWN event in state CLOSING Jul 18 22:49:16 gurney mpd: [vpn] device is now in state DOWN Jul 18 22:49:16 gurney mpd: [vpn] link: DOWN event Jul 18 22:49:16 gurney mpd: [vpn] LCP: Down event Jul 18 22:49:16 gurney mpd: [vpn] LCP: state change Stopping --> Starting Jul 18 22:49:16 gurney mpd: [vpn] LCP: phase shift TERMINATE --> DEAD Jul 18 22:49:16 gurney mpd: [vpn] giving up after 1 connection attempts Jul 18 22:49:16 gurney mpd: [vpn] LCP: Close event Jul 18 22:49:16 gurney mpd: [vpn] LCP: state change Starting --> Initial Jul 18 22:49:16 gurney mpd: [vpn] LCP: LayerFinish Jul 18 22:49:16 gurney mpd: [vpn] closing link "vpn"... Jul 18 22:49:16 gurney mpd: [vpn] IPCP: Close event Jul 18 22:49:16 gurney mpd: [vpn] IPCP: state change Starting --> Initial Jul 18 22:49:16 gurney mpd: [vpn] IPCP: LayerFinish Jul 18 22:49:16 gurney mpd: [vpn] bundle: CLOSE event in state OPENED Jul 18 22:49:16 gurney mpd: [vpn] link: CLOSE event Jul 18 22:49:16 gurney mpd: [vpn] LCP: Close event Jul 18 22:49:16 gurney mpd: [vpn] device: CLOSE event in state DOWN Jul 18 22:49:16 gurney mpd: [vpn] device is now in state DOWN Jul 18 22:49:16 gurney mpd: pptp0: CID 0xa525 in SetLinkInfo not found Jul 18 22:49:16 gurney mpd: pptp0-0: peer call disconnected res=zero? err=none Jul 18 22:49:16 gurney mpd: pptp0-0: killing channel Jul 18 22:49:16 gurney mpd: pptp0: closing connection with 210.8.75.9:1723 Jul 18 22:49:19 gurney mpd: pptp0: no reply to StopCtrlConnRequest after 3 sec Jul 18 22:49:19 gurney mpd: pptp0: killing connection with 210.8.75.9:1723 Jul 18 22:50:03 gurney mpd: [vpn] IFACE: Close event Jul 18 22:50:03 gurney mpd: [vpn] IPCP: Close event Jul 18 22:50:54 gurney mpd: [vpn] IPCP: Down event Jul 18 22:50:54 gurney mpd: [vpn] IFACE: Close event Jul 18 22:50:54 gurney mpd: mpd: process 16313 terminated --dDRMvlgZJXvWKvBx-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 8:10:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by hub.freebsd.org (Postfix) with ESMTP id 18C3A37BE62 for ; Tue, 18 Jul 2000 08:10:35 -0700 (PDT) (envelope-from barney@mx.databus.com) Received: (from barney@localhost) by mx.databus.com (8.9.3/8.9.3) id LAA33088 for freebsd-net@freebsd.org; Tue, 18 Jul 2000 11:10:33 -0400 (EDT) (envelope-from barney) From: Barney Wolff Message-Id: <200007181510.LAA33088@mx.databus.com> Subject: Re: Win2000 -> FreeBSD PPPoE daemon In-Reply-To: <200007180751.IAA19521@hak.lan.Awfulhak.org> from Brian Somers at "Jul 18, 2000 08:51:21 am" To: freebsd-net@freebsd.org Date: Tue, 18 Jul 2000 11:10:33 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a vague memory that Win95 (and therefore probably Win98) allowed a single dial-IN to itself, and contained ppp server functionality for that one connection. Perhaps w2k-pro has removed it. It is normal for a ppp client to send the ipcp conf-req asking for 0.0.0.0, expecting to get a conf-nak with the ip address assigned by the server. The client then sends another conf-req with the server-assigned ip address, which the server acks. Why is the fbsd box acting as a client, rather than a server? Who initiated the "connection"? One side or the other is going to have to assign ip addresses to each side of the connection. Have you tried connecting two w2kpro boxes this way? Does it work? Barney Wolff > > Hi Brian, > > > > Thanks for the quick response (it's late where you live, > > isn't it? :-) > > > > > It sounds like you haven't done a > > > > > > set ifaddr something hisnumber > > > > > > in your config. Without this, if the peer asks for 0.0.0.0, ppp will > > > just say ``yeah, fine, I don't know any better''. Make ``hisnumber'' > > > whatever you want him to use and make ``something'' whatever you want > > > to use locally - probably just your NIC iface IP address (dups are ok > > > as long as only one is a broadcast device). > > > > We'll try that tomorrow (the test equipment is 65 miles away > > and my testing buddy has gone home :). > > Looking at things a bit more carefully, it looks like the > ``something'' bit is what's missing. ppp(8) is sending REQs with > 0.0.0.0 (saying ``I'd like to have IP 0.0.0.0 please''). > > Perhaps you've got ``set ifaddr 0 0'' in your config ? If so, you > can probably get away with just removing that line. The default is > ``set ifaddr MYADDR 0''. > > > But the curious thing(s) is that this *same* setup, with no > > changes on the FreeBSD end, works as-is with Win98 (with the > > same Windows settings). > > This is strange. Win98 must be assigning ppp(8) an IP number, or > maybe it's letting it have 0.0.0.0 and is managing to route through > it. ppp(8) doesn't care about it's local interface address (although > I would have guessed that things would go wrong if it ended up with > 0.0.0.0). > > > Also, did you see the part in the trace where we asked for > > the specific IP address and FreeBSD did ack that configuration? > > Not until now :-/ It looks like the problem is that ppp(8) is > requesting 0.0.0.0 and Win2000 is (correctly) saying ``don't be > silly''. > > > If it's just a server setup problem, that's fine, we'll change > > it. But I'm just curious as to what's going on... > > > > BTW, just out of curiousity, why does FreeBSD reject the > > identification packets? Does it really not understand them? > > Never heard of them... I take it these are Multi-link Procedure > options ? I'll stick this on my todo list I guess :-) > > > Thanks, > > Gary > > Cheers. > > -- > Brian > > Don't _EVER_ lose your sense of humour ! > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 8:19:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from sn1oexchr01.nextvenue.com (sn1oexchr01.nextvenue.com [63.209.169.9]) by hub.freebsd.org (Postfix) with SMTP id 9B2AD37BDDA for ; Tue, 18 Jul 2000 08:19:39 -0700 (PDT) (envelope-from nevans@nextvenue.com) Received: FROM sn1exchmbx.nextvenue.com BY sn1oexchr01.nextvenue.com ; Tue Jul 18 11:15:50 2000 -0400 Received: by sn1exchmbx.nextvenue.com with Internet Mail Service (5.5.2650.21) id <3987S1XJ>; Tue, 18 Jul 2000 11:13:14 -0400 Message-ID: <712384017032D411AD7B0001023D799B07C9F5@sn1exchmbx.nextvenue.com> From: Nick Evans To: "'freebsd-net@freebsd.org'" Subject: Netgraph Date: Tue, 18 Jul 2000 11:13:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF0CA.AD857D50" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk 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_01BFF0CA.AD857D50 Content-Type: text/plain; charset="iso-8859-1" Can someone direct me to some good reading on what netgraph is? I haven't found anything substantial in the man pages and nothing in the handbook ------------------------------------------ nick.evans network.engineering NextVenue, Inc. phone: (212) 909.2988 pager: (888) 642.5541 ------_=_NextPart_001_01BFF0CA.AD857D50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Netgraph

Can someone direct me to some good reading on what = netgraph is? I haven't found anything substantial in the man pages and = nothing in the handbook

------------------------------------------
nick.evans
network.engineering
NextVenue, Inc.
phone: (212) 909.2988
pager: (888) 642.5541

------_=_NextPart_001_01BFF0CA.AD857D50-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 8:28:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164]) by hub.freebsd.org (Postfix) with ESMTP id B49E437BF41 for ; Tue, 18 Jul 2000 08:28:33 -0700 (PDT) (envelope-from aljtarik@cholla.inrs-telecom.uquebec.ca) Received: from cholla.INRS-Telecom.UQuebec.CA (cholla [192.26.211.110]) by ozias.inrs-telecom.uquebec.ca (8.9.1/8.9.1) with ESMTP id LAA15852 for ; Tue, 18 Jul 2000 11:28:30 -0400 (EDT) Received: from cholla by cholla.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4) id LAA18108; Tue, 18 Jul 2000 11:28:30 -0400 (EDT) Message-Id: <200007181528.LAA18108@cholla.INRS-Telecom.UQuebec.CA> Date: Tue, 18 Jul 2000 11:28:30 -0400 (EDT) From: Tarik Alj Reply-To: Tarik Alj Subject: Re: Netgraph To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: UwCwqwpbhegEekTUopjC6Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org march issue of DaemonNews [http://www.daemonnews.org] >Delivered-To: freebsd-net@freebsd.org >From: Nick Evans >To: "'freebsd-net@freebsd.org'" >Subject: Netgraph >Date: Tue, 18 Jul 2000 11:13:07 -0400 >MIME-Version: 1.0 >X-Loop: FreeBSD.org > >Can someone direct me to some good reading on what netgraph is? I haven't >found anything substantial in the man pages and nothing in the handbook > >------------------------------------------ >nick.evans >network.engineering >NextVenue, Inc. >phone: (212) 909.2988 >pager: (888) 642.5541 > Tarik To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 8:41: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hub.freebsd.org (Postfix) with ESMTP id 0F81737BE9E for ; Tue, 18 Jul 2000 08:41:00 -0700 (PDT) (envelope-from rik@cronyx.ru) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id TAA06489; (8.9.3/vak/2.1) Tue, 18 Jul 2000 19:43:05 +0400 (MSD) Message-ID: <39747B18.851AF6A6@cronyx.ru> Date: Tue, 18 Jul 2000 19:43:20 +0400 From: Kurakin Roman Organization: Cronyx X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: ru,en MIME-Version: 1.0 To: Nick Evans Cc: "'freebsd-net@freebsd.org'" Subject: Re: Netgraph References: <712384017032D411AD7B0001023D799B07C9F5@sn1exchmbx.nextvenue.com> Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org There is a goog article about Netgraph: http://www.daemonnews.org/200003/netgraph.html If you want to write driver using Netgraph, it is better to read /sys/netgraph/ng_sample.c and a couple of drivers (in addition to the drivers that in FreeBSD tree, I can offer drivers that I made (http://www.cronyx.ru/pub/cronyx/adapters/cfbsd333.tgz). Best regards, Kurakin Roman > Nick Evans wrote: > > Can someone direct me to some good reading on what netgraph is? I > haven't found anything substantial in the man pages and nothing in the > handbook > > ------------------------------------------ > nick.evans > network.engineering > NextVenue, Inc. > phone: (212) 909.2988 > pager: (888) 642.5541 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 8:48:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from main.piter.net (main.piter.net [195.201.22.10]) by hub.freebsd.org (Postfix) with ESMTP id 922D737BEA4 for ; Tue, 18 Jul 2000 08:48:47 -0700 (PDT) (envelope-from cyril@main.piter.net) Received: from Computer (Singapore.piter.net [195.190.106.223] (may be forged)) by main.piter.net (8.9.3/8.5.2/sply) with SMTP id TAA16550 for ; Tue, 18 Jul 2000 19:47:45 +0400 (MSD) Message-ID: <004d01bff0cf$402498e0$df6abec3@piter.net> From: "Cyril A. Vechera" To: Subject: some kind of policy rounting with large table needed Date: Tue, 18 Jul 2000 19:45:49 +0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0518.4 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello. Is there way to make source address based routing/port forwarding for large tables - about 50K subnets with different sizes. I guess ipfw is not suited enough for large tables :) Sincere Cyril. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 9:22:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 4372437BEEA for ; Tue, 18 Jul 2000 09:22:23 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id MAA08180; Tue, 18 Jul 2000 12:22:14 -0400 (EDT) (envelope-from wollman) Date: Tue, 18 Jul 2000 12:22:14 -0400 (EDT) From: Garrett Wollman Message-Id: <200007181622.MAA08180@khavrinen.lcs.mit.edu> To: "Cyril A. Vechera" Cc: Subject: some kind of policy rounting with large table needed In-Reply-To: <004d01bff0cf$402498e0$df6abec3@piter.net> References: <004d01bff0cf$402498e0$df6abec3@piter.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Is there way to make source address based routing/port > forwarding for large tables - about 50K subnets with different > sizes. Without question you need a Real Data Structure. Probably in order to perform acceptably you will need a kernel cache (similar to how the multicast code, which also examines both addresses, does it) which you can refill as needed from a user process. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 10:46:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 5C4B537B7FC for ; Tue, 18 Jul 2000 10:46:09 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id KAA55411; Tue, 18 Jul 2000 10:45:59 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200007181745.KAA55411@bubba.whistle.com> Subject: Re: mpd-netgraph port vs Windows-2000 PPTP vpn In-Reply-To: <20000718231031.A16524@gurney.reilly.home> from Andrew Reilly at "Jul 18, 2000 11:10:31 pm" To: Andrew Reilly Date: Tue, 18 Jul 2000 10:45:59 -0700 (PDT) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrew Reilly writes: > As a reference point, I can successfully connect to this VPN > with the dial-up-networking in my Windows-98 laptop, even > through my FreeBSD firewall box, thanks to a "-redirect_proto > gre" argument to natd... so I know my login name and password. > > Mpd seems like a wonderful system, and it seems to get much > further with the authentication stuff than ppp did, but still > not all the way. Any suggestions? I think ultimately mpd will need to support MS-CHAPv2... > mpd: [vpn] LCP: auth: peer wants CHAP, I want CHAP > mpd: [vpn] CHAP: sending CHALLENGE > mpd: [vpn] LCP: LayerUp > mpd: pptp0: CID 0xa525 in SetLinkInfo not found > mpd: [vpn] CHAP: rec'd CHALLENGE #0 > mpd: Name: "FIREWALL" > mpd: Using authname "andrew" > mpd: [vpn] CHAP: sending RESPONSE > mpd: [vpn] CHAP: rec'd FAILURE #0 > mpd: [vpn] LCP: authorization failed This is a bit weird.. the remote side claims to support CHAP MD5 but either doesn't really, or your password is wrong. But even if this were fixed, you need MS-CHAP to do MPPE encryption, so that would still be a problem. Just for fun, try the patch below and see if you get any further. > It seems possible, given the discussion in the mpd > documentation, that my office's Win2000 system might be using > the STACK and mppc bits. Is it possible to aquire these at all, > or is this something only available internally to Whistle? You can do the encryption without the compression part. We (Whistle) don't even have the compression code anymore because we chose not to license it (too expensive). I think there is a Linux implementation that somebody wrote, but it would take some work to port it. > Oh: documentation bug report: should the first command in > section 4.4 "IPCP layer commands" in the manual read "set ipcp > ranges ..." instead of "set iface ranges ..." as it currently > does? Thanks! I'll fix that. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Index: lcp.c =================================================================== RCS file: /cvs/mod/whistle/ia/daemon/mpd/lcp.c,v retrieving revision 1.12.2.18 diff -u -r1.12.2.18 lcp.c --- lcp.c 2000/05/08 20:33:34 1.12.2.18 +++ lcp.c 2000/07/18 17:43:22 @@ -736,7 +736,11 @@ case TY_AUTHPROTO: /* authentication protocol */ { static const u_char chapcf[] = +#ifdef MICROSOFT_CHAP + { PROTO_CHAP >> 8, PROTO_CHAP & 0xff, CHAP_ALG_MSOFT }; +#else { PROTO_CHAP >> 8, PROTO_CHAP & 0xff, CHAP_ALG_MD5 }; +#endif static const struct fsmoption chapNak = { TY_AUTHPROTO, 2 + sizeof(chapcf), (u_char *) chapcf }; static const u_char papcf[] = To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 12: 1: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by hub.freebsd.org (Postfix) with ESMTP id 6F68B37B973 for ; Tue, 18 Jul 2000 12:00:52 -0700 (PDT) (envelope-from gcorcoran@lucent.com) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA20288 for ; Tue, 18 Jul 2000 15:00:40 -0400 (EDT) Received: from mhmail.mh.lucent.com (h135-3-115-8.lucent.com [135.3.115.8]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA20278; Tue, 18 Jul 2000 15:00:39 -0400 (EDT) Received: from lucent.com by mhmail.mh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA00188; Tue, 18 Jul 2000 15:00:37 -0400 (EDT) Message-ID: <3974A957.3C709E24@lucent.com> Date: Tue, 18 Jul 2000 15:00:39 -0400 From: "Gary T. Corcoran" Organization: Lucent Microelectronics - Client Access Broadband Systems X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Somers Cc: FreeBSD Network List Subject: Re: Win2000 -> FreeBSD PPPoE daemon References: <200007180751.IAA19521@hak.lan.Awfulhak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brian Somers wrote: > > > BTW, just out of curiousity, why does FreeBSD reject the > > identification packets? Does it really not understand them? > > Never heard of them... I take it these are Multi-link Procedure > options ? I'll stick this on my todo list I guess :-) Nope, nothing to do with Multi-Link. Just "identification" for whatever purpose the remote end might use it. I found it described in RFC1570. It just says you _should_ display the informational message contained in the packet upon receipt... Gary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 12:18:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from main.piter.net (main.piter.net [195.201.22.10]) by hub.freebsd.org (Postfix) with ESMTP id 1D89337B513 for ; Tue, 18 Jul 2000 12:18:22 -0700 (PDT) (envelope-from cyril@main.piter.net) Received: from Computer (Haiti.piter.net [195.190.106.209] (may be forged)) by main.piter.net (8.9.3/8.5.2/sply) with SMTP id XAA18695; Tue, 18 Jul 2000 23:17:28 +0400 (MSD) Message-ID: <000701bff0ec$8a63af00$d16abec3@piter.net> From: "Cyril A. Vechera" To: "Garrett Wollman" Cc: Subject: Re: some kind of policy rounting with large table needed Date: Tue, 18 Jul 2000 23:15:29 +0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0518.4 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org So, no easy way? I guess it sould be made on netgraph with some kind of kernel-type rt_lookup. Maybe someone has more mobile routines for ip subnet lookup that are in kernel? From: Garrett Wollman Date: 18 ÉÀÌÑ 2000 Ç. 20:22 >< said: > >> Is there way to make source address based routing/port >> forwarding for large tables - about 50K subnets with different >> sizes. > >Without question you need a Real Data Structure. Probably in order to >perform acceptably you will need a kernel cache (similar to how the >multicast code, which also examines both addresses, does it) which you >can refill as needed from a user process. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 13:20:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 890EB37BC3C for ; Tue, 18 Jul 2000 13:20:20 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id NAA57301 for freebsd-net@freebsd.org; Tue, 18 Jul 2000 13:20:19 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200007182020.NAA57301@bubba.whistle.com> Subject: "ifconfig" == "ifconfig -a" In-Reply-To: <200007180224.TAA99448@freefall.freebsd.org> from John Polstra at "Jul 17, 2000 07:24:33 pm" To: freebsd-net@freebsd.org Date: Tue, 18 Jul 2000 13:20:19 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Polstra writes: > Modified files: (Branch: RELENG_4) > sbin/ldconfig ldconfig.8 ldconfig.c > Log: > MFC: Make "ldconfig" with no arguments behave the same as "ldconfig -R". This reminds me.. Would anyone complain if we made "ifconfig" with no arguments behave the same as "ifconfig -a" ? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 14:39:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from dune.clickarray.com (mail.puretek.com [216.174.91.46]) by hub.freebsd.org (Postfix) with ESMTP id 968CA37B80B for ; Tue, 18 Jul 2000 14:39:45 -0700 (PDT) (envelope-from sshah@dune.clickarray.com) Received: (from sshah@localhost) by dune.clickarray.com (8.9.3/8.9.3) id OAA25296; Tue, 18 Jul 2000 14:38:43 -0700 Date: Tue, 18 Jul 2000 14:38:43 -0700 From: Steve Shah To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: "ifconfig" == "ifconfig -a" Message-ID: <20000718143843.A25290@clickarray.com> References: <200007180224.TAA99448@freefall.freebsd.org> <200007182020.NAA57301@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <200007182020.NAA57301@bubba.whistle.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org That would be nice... Us ex-linux freaks keep forgetting the -a. ;-) And making route with no parameters print the routing table would be doubly nice. -Steve On Tue, Jul 18, 2000 at 01:20:19PM -0700, Archie Cobbs wrote: > Would anyone complain if we made "ifconfig" with no arguments > behave the same as "ifconfig -a" ? -- ___________________________________________________________________________ Steve Shah (sshah@clickarray.com) | Developer/Systems Administrator/Author http://www.clickarray.com | Voice: 408.772.8202 (e-mail preferred) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Beating code into submission, one OS at a time... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 15:16:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from guppy.evolunet.com (guppy.evolunet.com [195.154.101.161]) by hub.freebsd.org (Postfix) with ESMTP id 5E0C137B85F for ; Tue, 18 Jul 2000 15:16:20 -0700 (PDT) (envelope-from renaud@guppy.evolunet.com) Received: (from renaud@localhost) by guppy.evolunet.com (8.8.7/8.8.7) id AAA14545; Wed, 19 Jul 2000 00:22:16 +0200 (CEST) (envelope-from renaud) From: Renaud Waldura Message-Id: <200007182222.AAA14545@guppy.evolunet.com> Subject: Re: "ifconfig" == "ifconfig -a" In-Reply-To: <20000718143843.A25290@clickarray.com> from Steve Shah at "Jul 18, 0 02:38:43 pm" To: sshah@clickarray.com (Steve Shah) Date: Wed, 19 Jul 100 00:22:16 +0200 (CEST) Cc: archie@whistle.com, freebsd-net@FreeBSD.ORG Reply-To: renaud@waldura.org (Renaud Waldura) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > ifconfig == ifconfig -a > > And making route with no parameters print the routing table would be > doubly nice. I will second that. I see both as nice, practical additions that can only contribute to make FreeBSD easier to use. -- -- Renaud Waldura -- 610 Clipper St. Suite 19 -- San Francisco CA 94114 -- USA -- phone +1 415 642-5364 -- fax +1 415 642-5364 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 16:12:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.102.114]) by hub.freebsd.org (Postfix) with ESMTP id 6DEF737BBDE for ; Tue, 18 Jul 2000 16:12:37 -0700 (PDT) (envelope-from mph@wopr.caltech.edu) Received: (from mph@localhost) by wopr.caltech.edu (8.9.3/8.9.3) id QAA96188; Tue, 18 Jul 2000 16:12:29 -0700 (PDT) (envelope-from mph) Date: Tue, 18 Jul 2000 16:12:29 -0700 From: Matthew Hunt To: Renaud Waldura Cc: Steve Shah , archie@whistle.com, freebsd-net@FreeBSD.ORG Subject: Re: "ifconfig" == "ifconfig -a" Message-ID: <20000718161229.A96043@wopr.caltech.edu> References: <20000718143843.A25290@clickarray.com> <200007182222.AAA14545@guppy.evolunet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007182222.AAA14545@guppy.evolunet.com>; from renaud@guppy.evolunet.com on Wed, Jul 19, 2000 at 12:22:16AM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jul 19, 2000 at 12:22:16AM +0200, Renaud Waldura wrote: > > > > ifconfig == ifconfig -a > > > > And making route with no parameters print the routing table would be > > doubly nice. > > I will second that. I see both as nice, practical additions that can > only contribute to make FreeBSD easier to use. I have no objection to making ifconfig == ifconfig -a, but it is not currently the job of route(8) to display the route table. Making it do so would duplicate functionality that's in netstat(1). -- Matthew Hunt * UNIX is a lever for the http://www.pobox.com/~mph/ * intellect. -J.R. Mashey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 16:21:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by hub.freebsd.org (Postfix) with ESMTP id 5A3AC37B5B3 for ; Tue, 18 Jul 2000 16:21:49 -0700 (PDT) (envelope-from gcorcoran@lucent.com) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA28052 for ; Tue, 18 Jul 2000 19:21:49 -0400 (EDT) Received: from mhmail.mh.lucent.com (h135-3-115-8.lucent.com [135.3.115.8]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA28036; Tue, 18 Jul 2000 19:21:48 -0400 (EDT) Received: from lucent.com by mhmail.mh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id TAA02932; Tue, 18 Jul 2000 19:21:44 -0400 (EDT) Message-ID: <3974E68A.63E79868@lucent.com> Date: Tue, 18 Jul 2000 19:21:46 -0400 From: "Gary T. Corcoran" Organization: Lucent Microelectronics - Client Access Broadband Systems X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Hunt Cc: freebsd-net@FreeBSD.ORG Subject: Re: "ifconfig" == "ifconfig -a" References: <20000718143843.A25290@clickarray.com> <200007182222.AAA14545@guppy.evolunet.com> <20000718161229.A96043@wopr.caltech.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Hunt wrote: > > I have no objection to making ifconfig == ifconfig -a, but it > is not currently the job of route(8) to display the route table. > Making it do so would duplicate functionality that's in netstat(1). Understood, so I won't push for one way or the other. However, I thought it might be useful to note that having spent much time on Windows boxes, where I would type "route print" to see the route table, I sometimes forget and find myself typing "route" or "route print" on my FreeBSD boxes too... ;-) Hmmm.... what about having "route" with no parameters just give a helpful message, something like "To see the current routing table, use the netstat(1) command.". ?? Gary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 16:26:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id 74A7437BA76 for ; Tue, 18 Jul 2000 16:26:10 -0700 (PDT) (envelope-from ras@e-gerbil.net) Received: from localhost (ras@localhost) by overlord.e-gerbil.net (8.9.3/8.9.3) with ESMTP id TAA00583; Tue, 18 Jul 2000 19:26:03 -0400 (EDT) (envelope-from ras@e-gerbil.net) X-Authentication-Warning: overlord.e-gerbil.net: ras owned process doing -bs Date: Tue, 18 Jul 2000 19:26:03 -0400 (EDT) From: "Richard A. Steenbergen" To: "Gary T. Corcoran" Cc: Matthew Hunt , freebsd-net@FreeBSD.ORG Subject: Re: "ifconfig" == "ifconfig -a" In-Reply-To: <3974E68A.63E79868@lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 18 Jul 2000, Gary T. Corcoran wrote: > Matthew Hunt wrote: > > > > I have no objection to making ifconfig == ifconfig -a, but it > > is not currently the job of route(8) to display the route table. > > Making it do so would duplicate functionality that's in netstat(1). > > Understood, so I won't push for one way or the other. > However, I thought it might be useful to note that having > spent much time on Windows boxes, where I would type > "route print" to see the route table, I sometimes forget and > find myself typing "route" or "route print" on my FreeBSD > boxes too... ;-) > > Hmmm.... what about having "route" with no parameters just > give a helpful message, something like "To see the current > routing table, use the netstat(1) command.". ?? If nothing else, it is in no way intuitive that "route" says nothing about how to view the current routing table. This is one of the most common new FreeBSD user questions I hear. At a minimium, something should be hinted at in the man page. -- Richard A Steenbergen http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 16:50:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from guppy.evolunet.com (guppy.evolunet.com [195.154.101.161]) by hub.freebsd.org (Postfix) with ESMTP id D856237B7BE for ; Tue, 18 Jul 2000 16:50:22 -0700 (PDT) (envelope-from renaud@guppy.evolunet.com) Received: (from renaud@localhost) by guppy.evolunet.com (8.8.7/8.8.7) id BAA14966; Wed, 19 Jul 2000 01:56:16 +0200 (CEST) (envelope-from renaud) From: Renaud Waldura Message-Id: <200007182356.BAA14966@guppy.evolunet.com> Subject: Re: "ifconfig" == "ifconfig -a" In-Reply-To: from "Richard A. Steenbergen" at "Jul 18, 0 07:26:03 pm" To: ras@e-gerbil.net (Richard A. Steenbergen) Date: Wed, 19 Jul 100 01:56:16 +0200 (CEST) Cc: gcorcoran@lucent.com, mph@astro.caltech.edu, freebsd-net@FreeBSD.ORG Reply-To: renaud@waldura.org (Renaud Waldura) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Tue, 18 Jul 2000, Gary T. Corcoran wrote: > > > Hmmm.... what about having "route" with no parameters just > > give a helpful message, something like "To see the current > > routing table, use the netstat(1) command.". ?? > > If nothing else, it is in no way intuitive that "route" says nothing about > how to view the current routing table. This is one of the most common new > FreeBSD user questions I hear. At a minimium, something should be hinted > at in the man page. And in an ideal world, the "route" command should do what its name suggests: deal with routes, and that includes printing them IMHO. I hate code/functionnality duplication as much as the next guy, but having to call a command totally unrelated to "route" to display the routing table (ie. netstat) has always struck me as a gratuitous twist. I cast my vote for a "route print". -- -- Renaud Waldura -- 610 Clipper St. Suite 19 -- San Francisco CA 94114 -- USA -- phone +1 415 642-5364 -- fax +1 415 642-5364 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 16:53:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 145C637B843 for ; Tue, 18 Jul 2000 16:53:50 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id QAA61412; Tue, 18 Jul 2000 16:53:38 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200007182353.QAA61412@bubba.whistle.com> Subject: Re: "ifconfig" == "ifconfig -a" In-Reply-To: <200007182356.BAA14966@guppy.evolunet.com> from Renaud Waldura at "Jul 19, 2000 01:56:16 am" To: Renaud Waldura Date: Tue, 18 Jul 2000 16:53:38 -0700 (PDT) Cc: "Richard A. Steenbergen" , gcorcoran@lucent.com, mph@astro.caltech.edu, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Renaud Waldura writes: > I hate code/functionnality duplication as much as the next guy, but having to > call a command totally unrelated to "route" to display the routing table (ie. netstat) > has always struck me as a gratuitous twist. > > I cast my vote for a "route print". Try "route -dvn flush". This prints all the routes, but you can see how ugly it is. It would take a lot of code duplication to make it look as nice as netstat does I think. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 16:54:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from dune.clickarray.com (mail.puretek.com [216.174.91.46]) by hub.freebsd.org (Postfix) with ESMTP id E4E5037B82F for ; Tue, 18 Jul 2000 16:54:17 -0700 (PDT) (envelope-from sshah@dune.clickarray.com) Received: (from sshah@localhost) by dune.clickarray.com (8.9.3/8.9.3) id QAA25806; Tue, 18 Jul 2000 16:53:18 -0700 Date: Tue, 18 Jul 2000 16:53:18 -0700 From: Steve Shah To: Matthew Hunt Cc: freebsd-net@freebsd.org Subject: Re: "ifconfig" == "ifconfig -a" Message-ID: <20000718165318.A25750@clickarray.com> References: <20000718143843.A25290@clickarray.com> <200007182222.AAA14545@guppy.evolunet.com> <20000718161229.A96043@wopr.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <20000718161229.A96043@wopr.caltech.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jul 18, 2000 at 04:12:29PM -0700, Matthew Hunt wrote: > I have no objection to making ifconfig == ifconfig -a, but it > is not currently the job of route(8) to display the route table. > Making it do so would duplicate functionality that's in netstat(1). You're right. OTOH, it's just handy. =) And as I mentioned before, for the many people in the Linux community trying FreeBSD, little things like this make it feel more warm and fuzzy. Just a thought... -Steve (who has finally kicked the habit of typing "route" to see the routing table) -- ___________________________________________________________________________ Steve Shah (sshah@clickarray.com) | Developer/Systems Administrator/Author http://www.clickarray.com | Voice: 408.772.8202 (e-mail preferred) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Beating code into submission, one OS at a time... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 18: 1:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 5CBB537B6E6 for ; Tue, 18 Jul 2000 18:01:19 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.15 #1) id 13Ehan-000E9P-00; Wed, 19 Jul 2000 01:20:05 +0100 Received: (from ben) by strontium.scientia.demon.co.uk (Exim 3.15 #1) id 13Eham-000H2d-00; Wed, 19 Jul 2000 01:20:04 +0100 Date: Wed, 19 Jul 2000 01:20:04 +0100 From: Ben Smithurst To: "Richard A. Steenbergen" Cc: "Gary T. Corcoran" , Matthew Hunt , freebsd-net@FreeBSD.ORG Subject: Re: "ifconfig" == "ifconfig -a" Message-ID: <20000719012004.A4668@strontium.scientia.demon.co.uk> References: <3974E68A.63E79868@lucent.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ocvL5ZWDEAsQ5ck/" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ocvL5ZWDEAsQ5ck/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Richard A. Steenbergen wrote: > At a minimium, something should be hinted at in the man page. I agree. I checked just now, and was quite surprised to see netstat(1) not even referenced in the "SEE ALSO" section. How about this: --- route.8 1999/12/07 17:38:53 1.17 +++ route.8 2000/07/19 00:18:13 @@ -54,6 +54,15 @@ .Xr routed 8 , should tend to this task. .Pp +Note that +.Nm +cannot be used to print out the entire routing table. +For that functionality, please see the +.Fl r +flag to the +.Xr netstat 1 +command. +.Pp The .Nm utility supports a limited number of general options, @@ -351,6 +360,7 @@ to create the new entry. .El .Sh SEE ALSO +.Xr netstat 1 , .Xr netintro 4 , .Xr route 4 , .Xr IPXrouted 8 , Any objections? --=20 Ben Smithurst / ben@FreeBSD.org / PGP: 0x99392F7D FreeBSD Documentation Project / --ocvL5ZWDEAsQ5ck/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: c6yhf1quHIYnvMs+KtQ3su+0l3UKd5Zu iQCVAwUBOXT0NCsPVtiZOS99AQF+EQQAlpm5aHRqhvcDz7FQfX3HpDV5+ryD41vs hdW339Fo359o4fW07E4HtNYghOclMly5QlWjnHQQQp9Pnf0BJpwnbbTWM5Q+9p8i bfEGvIkSXfNzGYn45EUbmpVA67cdNYxjnY6PEKOxgn3IvDgBWuPRka1ihiLv0eB3 dDKTFPpwZ3o= =Mfjv -----END PGP SIGNATURE----- --ocvL5ZWDEAsQ5ck/-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 18: 7:20 2000 Delivered-To: freebsd-net@freebsd.org Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.102.114]) by hub.freebsd.org (Postfix) with ESMTP id 473D737B6E6; Tue, 18 Jul 2000 18:07:16 -0700 (PDT) (envelope-from mph@wopr.caltech.edu) Received: (from mph@localhost) by wopr.caltech.edu (8.9.3/8.9.3) id SAA99471; Tue, 18 Jul 2000 18:06:00 -0700 (PDT) (envelope-from mph) Date: Tue, 18 Jul 2000 18:06:00 -0700 From: Matthew Hunt To: Ben Smithurst Cc: "Richard A. Steenbergen" , "Gary T. Corcoran" , freebsd-net@freebsd.org Subject: Re: "ifconfig" == "ifconfig -a" Message-ID: <20000718180600.A99334@wopr.caltech.edu> References: <3974E68A.63E79868@lucent.com> <20000719012004.A4668@strontium.scientia.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000719012004.A4668@strontium.scientia.demon.co.uk>; from ben@freebsd.org on Wed, Jul 19, 2000 at 01:20:04AM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jul 19, 2000 at 01:20:04AM +0100, Ben Smithurst wrote: > +cannot be used to print out the entire routing table. > +For that functionality, please see the use > +.Fl r > +flag to the > +.Xr netstat 1 > +command. One uses flags, or sees documentation. :-) -- Matthew Hunt * Science rules. http://www.pobox.com/~mph/ * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 18:28:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from sr14.nsw-remote.bigpond.net.au (sr14.nsw-remote.bigpond.net.au [24.192.3.29]) by hub.freebsd.org (Postfix) with ESMTP id 874EE37B82F for ; Tue, 18 Jul 2000 18:28:36 -0700 (PDT) (envelope-from areilly@nsw.bigpond.net.au) Received: from areilly.bpc-users.org (CPE-144-132-171-71.nsw.bigpond.net.au [144.132.171.71]) by sr14.nsw-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id LAA23070 for ; Wed, 19 Jul 2000 11:28:32 +1000 (EST) Received: (qmail 69730 invoked by uid 1000); 19 Jul 2000 01:28:26 -0000 From: "Andrew Reilly" Date: Wed, 19 Jul 2000 11:28:26 +1000 To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: mpd-netgraph port vs Windows-2000 PPTP vpn Message-ID: <20000719112826.A68949@gurney.reilly.home> References: <20000718231031.A16524@gurney.reilly.home> <200007181745.KAA55411@bubba.whistle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007181745.KAA55411@bubba.whistle.com>; from archie@whistle.com on Tue, Jul 18, 2000 at 10:45:59AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi again, Thanks for answering my question so quickly. Your patch to lcp.c seems to have pushed us a little further along, but now we're stalling at the IPCP negotiation phase. I discovered that my previous build had not included DES, even though the relevent bits were on my system. I tweaked the src/Makefile to include "ENCRYPTION_DES= yes" just under the "ENCRYPTION_MPPE= yes" line, and it built (with a few prototype warnings). At least now it recognises the "set ecp accept des" option. Dunno if it's being used. The office uses DHCP to assign IP addresses. Does that interact with the PPTP process? I would imagine that the PPTP server would have to grab an IP address on my behalf for the IPCP negotiation, but is it possible that MS somehow skips that, and requires a separate DHCP session after the link is up? I tried making up an address in the appropriate range, with a /0 qualifier, and it went more-or-less exactly the same way. More things to tweak? Once again, I include mpd.conf, mpd.links, and a session log for your edfication and amusement. Thanks again, -- Andrew --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mpd.conf" vpn: new -i ng1 vpn vpn set bundle no multilink set bundle authname andrew set bundle enable crypt-reqd set iface disable on-demand set iface idle 0 set iface route 192.168.10.0/23 set ipcp ranges 0.0.0.0/0 192.168.10.5/0 set ipcp accept vjcomp set link enable no-orig-auth set link keep-alive 10 75 set link max-redial 1 set link yes acfcomp protocomp set link no pap set link yes chap set ccp yes mpp-compress set ccp accept mpp-e40 set ccp accept mpp-e128 set ccp accept mpp-stateless set ecp accept des open --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mpd.links" vpn: set link type pptp set pptp self 144.132.171.71 set pptp peer 210.8.75.9 set pptp enable originate incoming outcall --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mpd.log.today" Jul 19 11:10:39 gurney mpd: mpd: pid 68477, version 3.0 (andrew@gurney.reilly.home 11:08 19-Jul-2000) Jul 19 11:10:39 gurney mpd: [vpn] ppp node is "mpd68477-vpn" Jul 19 11:10:39 gurney mpd: [vpn] using interface ng1 Jul 19 11:10:39 gurney mpd: mpd: local IP address for PPTP is 144.132.171.71 Jul 19 11:10:39 gurney mpd: mpd: accept req-pri-dns: not applicable Jul 19 11:10:39 gurney mpd: mpd: accept req-sec-dns: not applicable Jul 19 11:10:39 gurney mpd: mpd: accept req-pri-nbns: not applicable Jul 19 11:10:39 gurney mpd: mpd: accept req-sec-nbns: not applicable Jul 19 11:10:39 gurney mpd: [vpn] IFACE: Open event Jul 19 11:10:39 gurney mpd: [vpn] IPCP: Open event Jul 19 11:10:39 gurney mpd: [vpn] IPCP: state change Initial --> Starting Jul 19 11:10:39 gurney mpd: [vpn] IPCP: LayerStart Jul 19 11:10:39 gurney mpd: [vpn] bundle: OPEN event in state CLOSED Jul 19 11:10:39 gurney mpd: [vpn] opening link "vpn"... Jul 19 11:10:39 gurney mpd: [vpn] link: OPEN event Jul 19 11:10:39 gurney mpd: [vpn] LCP: Open event Jul 19 11:10:39 gurney mpd: [vpn] LCP: state change Initial --> Starting Jul 19 11:10:39 gurney mpd: [vpn] LCP: LayerStart Jul 19 11:10:39 gurney mpd: [vpn] device: OPEN event in state DOWN Jul 19 11:10:39 gurney mpd: pptp0: connecting to 210.8.75.9:1723 Jul 19 11:10:39 gurney mpd: [vpn] device is now in state OPENING Jul 19 11:11:09 gurney mpd: pptp0: connected to 210.8.75.9:1723 Jul 19 11:11:09 gurney mpd: pptp0: attached to connection with 210.8.75.9:1723 Jul 19 11:11:09 gurney mpd: pptp0-0: outgoing call connected at -2137614336 bps Jul 19 11:11:09 gurney mpd: [vpn] PPTP call successful Jul 19 11:11:09 gurney mpd: [vpn] device: UP event in state OPENING Jul 19 11:11:09 gurney mpd: [vpn] device is now in state UP Jul 19 11:11:09 gurney mpd: [vpn] link: UP event Jul 19 11:11:09 gurney mpd: [vpn] link: origination is local Jul 19 11:11:09 gurney mpd: [vpn] LCP: Up event Jul 19 11:11:09 gurney mpd: [vpn] LCP: state change Starting --> Req-Sent Jul 19 11:11:09 gurney mpd: [vpn] LCP: phase shift DEAD --> ESTABLISH Jul 19 11:11:09 gurney mpd: [vpn] LCP: SendConfigReq #1 Jul 19 11:11:09 gurney mpd: ACFCOMP Jul 19 11:11:09 gurney mpd: PROTOCOMP Jul 19 11:11:09 gurney mpd: MRU 1500 Jul 19 11:11:09 gurney mpd: MAGICNUM dd661215 Jul 19 11:11:09 gurney mpd: AUTHPROTO CHAP MSOFT Jul 19 11:11:09 gurney mpd: [vpn] LCP: rec'd Configure Request #0 link 0 (Req-Sent) Jul 19 11:11:09 gurney mpd: AUTHPROTO 0xc227 Jul 19 11:11:09 gurney mpd: MAGICNUM 78ca5816 Jul 19 11:11:09 gurney mpd: PROTOCOMP Jul 19 11:11:09 gurney mpd: ACFCOMP Jul 19 11:11:09 gurney mpd: CALLBACK Jul 19 11:11:09 gurney mpd: Not supported Jul 19 11:11:09 gurney mpd: MP MRRU 1614 Jul 19 11:11:09 gurney mpd: ENDPOINTDISC [LOCAL] 35 02 eb 33 73 42 4c 06 8b ff e9 df 07 a9 ef 39 00 00 00 00 Jul 19 11:11:09 gurney mpd: UNKNOWN[23] len=4 Jul 19 11:11:09 gurney mpd: [vpn] LCP: SendConfigRej #0 Jul 19 11:11:09 gurney mpd: CALLBACK Jul 19 11:11:09 gurney mpd: MP MRRU 1614 Jul 19 11:11:09 gurney mpd: UNKNOWN[23] len=4 Jul 19 11:11:09 gurney mpd: [vpn] LCP: rec'd Configure Ack #1 link 0 (Req-Sent) Jul 19 11:11:09 gurney mpd: ACFCOMP Jul 19 11:11:09 gurney mpd: PROTOCOMP Jul 19 11:11:09 gurney mpd: MRU 1500 Jul 19 11:11:09 gurney mpd: MAGICNUM dd661215 Jul 19 11:11:09 gurney mpd: AUTHPROTO CHAP MSOFT Jul 19 11:11:09 gurney mpd: [vpn] LCP: state change Req-Sent --> Ack-Rcvd Jul 19 11:11:09 gurney mpd: [vpn] LCP: rec'd Configure Request #1 link 0 (Ack-Rcvd) Jul 19 11:11:09 gurney mpd: AUTHPROTO 0xc227 Jul 19 11:11:09 gurney mpd: MAGICNUM 78ca5816 Jul 19 11:11:09 gurney mpd: PROTOCOMP Jul 19 11:11:09 gurney mpd: ACFCOMP Jul 19 11:11:09 gurney mpd: ENDPOINTDISC [LOCAL] 35 02 eb 33 73 42 4c 06 8b ff e9 df 07 a9 ef 39 00 00 00 00 Jul 19 11:11:09 gurney mpd: [vpn] LCP: SendConfigNak #1 Jul 19 11:11:09 gurney mpd: AUTHPROTO CHAP MSOFT Jul 19 11:11:10 gurney mpd: [vpn] LCP: rec'd Configure Request #2 link 0 (Ack-Rcvd) Jul 19 11:11:10 gurney mpd: AUTHPROTO CHAP MSOFT Jul 19 11:11:10 gurney mpd: MAGICNUM 78ca5816 Jul 19 11:11:10 gurney mpd: PROTOCOMP Jul 19 11:11:10 gurney mpd: ACFCOMP Jul 19 11:11:10 gurney mpd: ENDPOINTDISC [LOCAL] 35 02 eb 33 73 42 4c 06 8b ff e9 df 07 a9 ef 39 00 00 00 00 Jul 19 11:11:10 gurney mpd: [vpn] LCP: SendConfigAck #2 Jul 19 11:11:10 gurney mpd: AUTHPROTO CHAP MSOFT Jul 19 11:11:10 gurney mpd: MAGICNUM 78ca5816 Jul 19 11:11:10 gurney mpd: PROTOCOMP Jul 19 11:11:10 gurney mpd: ACFCOMP Jul 19 11:11:10 gurney mpd: ENDPOINTDISC [LOCAL] 35 02 eb 33 73 42 4c 06 8b ff e9 df 07 a9 ef 39 00 00 00 00 Jul 19 11:11:10 gurney mpd: [vpn] LCP: state change Ack-Rcvd --> Opened Jul 19 11:11:10 gurney mpd: [vpn] LCP: phase shift ESTABLISH --> AUTHENTICATE Jul 19 11:11:10 gurney mpd: [vpn] LCP: auth: peer wants CHAP, I want CHAP Jul 19 11:11:10 gurney mpd: [vpn] CHAP: sending CHALLENGE Jul 19 11:11:10 gurney mpd: [vpn] LCP: LayerUp Jul 19 11:11:10 gurney mpd: pptp0: CID 0x6fb0 in SetLinkInfo not found Jul 19 11:11:10 gurney mpd: [vpn] CHAP: rec'd CHALLENGE #0 Jul 19 11:11:10 gurney mpd: Name: "FIREWALL" Jul 19 11:11:10 gurney mpd: Using authname "andrew" Jul 19 11:11:10 gurney mpd: [vpn] CHAP: sending RESPONSE Jul 19 11:11:12 gurney mpd: [vpn] CHAP: sending CHALLENGE Jul 19 11:11:12 gurney mpd: [vpn] CHAP: sending RESPONSE Jul 19 11:11:14 gurney mpd: [vpn] CHAP: sending CHALLENGE Jul 19 11:11:14 gurney mpd: [vpn] CHAP: sending RESPONSE Jul 19 11:11:16 gurney mpd: [vpn] CHAP: sending RESPONSE Jul 19 11:11:16 gurney mpd: pptp0: CID 0x6fb0 in SetLinkInfo not found Jul 19 11:11:16 gurney mpd: [vpn] CHAP: rec'd SUCCESS #0 Jul 19 11:11:16 gurney mpd: [vpn] LCP: rec'd Configure Request #4 link 0 (Opened) Jul 19 11:11:17 gurney mpd: AUTHPROTO 0xc227 Jul 19 11:11:17 gurney mpd: MAGICNUM 533a288f Jul 19 11:11:17 gurney mpd: PROTOCOMP Jul 19 11:11:17 gurney mpd: ACFCOMP Jul 19 11:11:17 gurney mpd: CALLBACK Jul 19 11:11:17 gurney mpd: Not supported Jul 19 11:11:17 gurney mpd: MP MRRU 1614 Jul 19 11:11:17 gurney mpd: ENDPOINTDISC [LOCAL] 35 02 eb 33 73 42 4c 06 8b ff e9 df 07 a9 ef 39 00 00 00 00 Jul 19 11:11:17 gurney mpd: UNKNOWN[23] len=4 Jul 19 11:11:17 gurney mpd: [vpn] LCP: LayerDown Jul 19 11:11:17 gurney mpd: [vpn] LCP: SendConfigReq #2 Jul 19 11:11:17 gurney mpd: ACFCOMP Jul 19 11:11:17 gurney mpd: PROTOCOMP Jul 19 11:11:17 gurney mpd: MRU 1500 Jul 19 11:11:17 gurney mpd: MAGICNUM dd661215 Jul 19 11:11:17 gurney mpd: AUTHPROTO CHAP MSOFT Jul 19 11:11:17 gurney mpd: [vpn] LCP: SendConfigRej #4 Jul 19 11:11:17 gurney mpd: CALLBACK Jul 19 11:11:17 gurney mpd: MP MRRU 1614 Jul 19 11:11:17 gurney mpd: UNKNOWN[23] len=4 Jul 19 11:11:17 gurney mpd: [vpn] LCP: state change Opened --> Req-Sent Jul 19 11:11:17 gurney mpd: [vpn] LCP: phase shift AUTHENTICATE --> ESTABLISH Jul 19 11:11:17 gurney mpd: [vpn] LCP: rec'd Configure Reject #2 link 0 (Req-Sent) Jul 19 11:11:17 gurney mpd: AUTHPROTO CHAP MSOFT Jul 19 11:11:17 gurney mpd: [vpn] LCP: SendConfigReq #3 Jul 19 11:11:17 gurney mpd: ACFCOMP Jul 19 11:11:17 gurney mpd: PROTOCOMP Jul 19 11:11:17 gurney mpd: MRU 1500 Jul 19 11:11:17 gurney mpd: MAGICNUM dd661215 Jul 19 11:11:17 gurney mpd: [vpn] LCP: rec'd Configure Request #5 link 0 (Req-Sent) Jul 19 11:11:17 gurney mpd: AUTHPROTO 0xc227 Jul 19 11:11:17 gurney mpd: MAGICNUM 533a288f Jul 19 11:11:17 gurney mpd: PROTOCOMP Jul 19 11:11:17 gurney mpd: ACFCOMP Jul 19 11:11:17 gurney mpd: ENDPOINTDISC [LOCAL] 35 02 eb 33 73 42 4c 06 8b ff e9 df 07 a9 ef 39 00 00 00 00 Jul 19 11:11:17 gurney mpd: [vpn] LCP: SendConfigNak #5 Jul 19 11:11:17 gurney mpd: AUTHPROTO CHAP MSOFT Jul 19 11:11:17 gurney mpd: [vpn] LCP: rec'd Configure Ack #3 link 0 (Req-Sent) Jul 19 11:11:17 gurney mpd: ACFCOMP Jul 19 11:11:17 gurney mpd: PROTOCOMP Jul 19 11:11:17 gurney mpd: MRU 1500 Jul 19 11:11:17 gurney mpd: MAGICNUM dd661215 Jul 19 11:11:17 gurney mpd: [vpn] LCP: state change Req-Sent --> Ack-Rcvd Jul 19 11:11:17 gurney mpd: [vpn] LCP: rec'd Configure Request #6 link 0 (Ack-Rcvd) Jul 19 11:11:17 gurney mpd: AUTHPROTO CHAP MSOFT Jul 19 11:11:17 gurney mpd: MAGICNUM 533a288f Jul 19 11:11:17 gurney mpd: PROTOCOMP Jul 19 11:11:17 gurney mpd: ACFCOMP Jul 19 11:11:17 gurney mpd: ENDPOINTDISC [LOCAL] 35 02 eb 33 73 42 4c 06 8b ff e9 df 07 a9 ef 39 00 00 00 00 Jul 19 11:11:17 gurney mpd: [vpn] LCP: SendConfigAck #6 Jul 19 11:11:17 gurney mpd: AUTHPROTO CHAP MSOFT Jul 19 11:11:17 gurney mpd: MAGICNUM 533a288f Jul 19 11:11:17 gurney mpd: PROTOCOMP Jul 19 11:11:17 gurney mpd: ACFCOMP Jul 19 11:11:17 gurney mpd: ENDPOINTDISC [LOCAL] 35 02 eb 33 73 42 4c 06 8b ff e9 df 07 a9 ef 39 00 00 00 00 Jul 19 11:11:17 gurney mpd: [vpn] LCP: state change Ack-Rcvd --> Opened Jul 19 11:11:17 gurney mpd: [vpn] LCP: phase shift ESTABLISH --> AUTHENTICATE Jul 19 11:11:17 gurney mpd: [vpn] LCP: auth: peer wants CHAP, I want nothing Jul 19 11:11:17 gurney mpd: [vpn] LCP: LayerUp Jul 19 11:11:17 gurney mpd: pptp0: CID 0x6fb0 in SetLinkInfo not found Jul 19 11:11:17 gurney mpd: [vpn] CHAP: rec'd CHALLENGE #0 Jul 19 11:11:17 gurney mpd: Name: "FIREWALL" Jul 19 11:11:17 gurney mpd: Using authname "andrew" Jul 19 11:11:17 gurney mpd: [vpn] CHAP: sending RESPONSE Jul 19 11:11:17 gurney mpd: [vpn] CHAP: rec'd SUCCESS #0 Jul 19 11:11:17 gurney mpd: [vpn] LCP: authorization successful Jul 19 11:11:17 gurney mpd: [vpn] LCP: phase shift AUTHENTICATE --> NETWORK Jul 19 11:11:17 gurney mpd: [vpn] up: 1 link, total bandwidth 64000 bps Jul 19 11:11:17 gurney mpd: [vpn] IPCP: Up event Jul 19 11:11:17 gurney mpd: [vpn] IPCP: state change Starting --> Req-Sent Jul 19 11:11:17 gurney mpd: [vpn] IPCP: SendConfigReq #1 Jul 19 11:11:17 gurney mpd: IPADDR 192.168.11.175 Jul 19 11:11:17 gurney mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jul 19 11:11:19 gurney mpd: [vpn] IPCP: SendConfigReq #2 Jul 19 11:11:19 gurney mpd: IPADDR 192.168.11.175 Jul 19 11:11:19 gurney mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jul 19 11:11:21 gurney mpd: [vpn] IPCP: SendConfigReq #3 Jul 19 11:11:21 gurney mpd: IPADDR 192.168.11.175 Jul 19 11:11:21 gurney mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jul 19 11:11:23 gurney mpd: [vpn] IPCP: SendConfigReq #4 Jul 19 11:11:23 gurney mpd: IPADDR 192.168.11.175 Jul 19 11:11:23 gurney mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jul 19 11:11:25 gurney mpd: [vpn] IPCP: SendConfigReq #5 Jul 19 11:11:25 gurney mpd: IPADDR 192.168.11.175 Jul 19 11:11:25 gurney mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jul 19 11:11:27 gurney mpd: [vpn] IPCP: SendConfigReq #6 Jul 19 11:11:27 gurney mpd: IPADDR 192.168.11.175 Jul 19 11:11:27 gurney mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jul 19 11:11:29 gurney mpd: [vpn] IPCP: SendConfigReq #7 Jul 19 11:11:29 gurney mpd: IPADDR 192.168.11.175 Jul 19 11:11:29 gurney mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jul 19 11:11:31 gurney mpd: [vpn] IPCP: SendConfigReq #8 Jul 19 11:11:31 gurney mpd: IPADDR 192.168.11.175 Jul 19 11:11:31 gurney mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jul 19 11:11:33 gurney mpd: [vpn] IPCP: SendConfigReq #9 Jul 19 11:11:33 gurney mpd: IPADDR 192.168.11.175 Jul 19 11:11:33 gurney mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jul 19 11:11:35 gurney mpd: [vpn] IPCP: SendConfigReq #10 Jul 19 11:11:35 gurney mpd: IPADDR 192.168.11.175 Jul 19 11:11:35 gurney mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jul 19 11:11:37 gurney mpd: [vpn] IPCP: state change Req-Sent --> Stopped Jul 19 11:11:37 gurney mpd: [vpn] IPCP: LayerFinish Jul 19 11:11:37 gurney mpd: [vpn] IPCP: parameter negotiation failed Jul 19 11:11:37 gurney mpd: [vpn] IPCP: LayerFinish Jul 19 11:11:37 gurney mpd: [vpn] bundle: CLOSE event in state OPENED Jul 19 11:11:37 gurney mpd: [vpn] closing link "vpn"... Jul 19 11:11:37 gurney mpd: [vpn] bundle: CLOSE event in state CLOSED Jul 19 11:11:37 gurney mpd: [vpn] closing link "vpn"... Jul 19 11:11:37 gurney mpd: [vpn] link: CLOSE event Jul 19 11:11:37 gurney mpd: [vpn] LCP: Close event Jul 19 11:11:37 gurney mpd: [vpn] LCP: state change Opened --> Closing Jul 19 11:11:37 gurney mpd: [vpn] LCP: phase shift NETWORK --> TERMINATE Jul 19 11:11:37 gurney mpd: [vpn] up: 0 links, total bandwidth 9600 bps Jul 19 11:11:37 gurney mpd: [vpn] IPCP: Down event Jul 19 11:11:37 gurney mpd: [vpn] IPCP: state change Stopped --> Starting Jul 19 11:11:37 gurney mpd: [vpn] IPCP: LayerStart Jul 19 11:11:37 gurney mpd: [vpn] closing link "vpn"... Jul 19 11:11:37 gurney mpd: [vpn] LCP: SendTerminateReq #4 Jul 19 11:11:37 gurney mpd: [vpn] LCP: LayerDown Jul 19 11:11:37 gurney mpd: [vpn] bundle: OPEN event in state CLOSED Jul 19 11:11:37 gurney mpd: [vpn] opening link "vpn"... Jul 19 11:11:37 gurney mpd: [vpn] link: CLOSE event Jul 19 11:11:37 gurney mpd: [vpn] LCP: Close event Jul 19 11:11:37 gurney mpd: [vpn] link: CLOSE event Jul 19 11:11:37 gurney mpd: [vpn] LCP: Close event Jul 19 11:11:37 gurney mpd: [vpn] link: OPEN event Jul 19 11:11:37 gurney mpd: [vpn] LCP: Open event Jul 19 11:11:37 gurney mpd: [vpn] LCP: state change Closing --> Stopping Jul 19 11:11:37 gurney mpd: pptp0: CID 0x6fb0 in SetLinkInfo not found Jul 19 11:11:37 gurney mpd: [vpn] LCP: rec'd Terminate Ack #4 link 0 (Stopping) Jul 19 11:11:37 gurney mpd: [vpn] LCP: state change Stopping --> Stopped Jul 19 11:11:37 gurney mpd: [vpn] LCP: phase shift TERMINATE --> ESTABLISH Jul 19 11:11:37 gurney mpd: [vpn] LCP: LayerFinish Jul 19 11:11:37 gurney mpd: [vpn] device: CLOSE event in state UP Jul 19 11:11:37 gurney mpd: pptp0-0: clearing call Jul 19 11:11:37 gurney mpd: [vpn] device is now in state CLOSING Jul 19 11:11:37 gurney mpd: [vpn] device: DOWN event in state CLOSING Jul 19 11:11:37 gurney mpd: [vpn] device is now in state DOWN Jul 19 11:11:37 gurney mpd: [vpn] link: DOWN event Jul 19 11:11:37 gurney mpd: [vpn] LCP: Down event Jul 19 11:11:37 gurney mpd: [vpn] LCP: state change Stopped --> Starting Jul 19 11:11:37 gurney mpd: [vpn] LCP: phase shift ESTABLISH --> DEAD Jul 19 11:11:37 gurney mpd: [vpn] LCP: LayerStart Jul 19 11:11:37 gurney mpd: [vpn] device: OPEN event in state DOWN Jul 19 11:11:37 gurney mpd: [vpn] pausing 8 seconds before open Jul 19 11:11:37 gurney mpd: [vpn] device is now in state DOWN Jul 19 11:11:37 gurney mpd: [vpn] device: OPEN event in state DOWN Jul 19 11:11:37 gurney mpd: [vpn] device is now in state DOWN Jul 19 11:11:37 gurney mpd: pptp0-0: peer call disconnected res=zero? err=none Jul 19 11:11:37 gurney mpd: pptp0-0: killing channel Jul 19 11:11:37 gurney mpd: pptp0: closing connection with 210.8.75.9:1723 Jul 19 11:11:37 gurney mpd: pptp0: invalid length 16 for type 4 Jul 19 11:11:37 gurney mpd: pptp0: killing connection with 210.8.75.9:1723 Jul 19 11:11:43 gurney mpd: [vpn] IPCP: Down event Jul 19 11:11:43 gurney mpd: [vpn] IFACE: Close event Jul 19 11:11:43 gurney mpd: [vpn] IPCP: Close event Jul 19 11:11:43 gurney mpd: [vpn] IPCP: state change Starting --> Initial Jul 19 11:11:43 gurney mpd: [vpn] IPCP: LayerFinish Jul 19 11:11:43 gurney mpd: mpd: process 68477 terminated --qDbXVdCdHGoSgWSk-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 18:45:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0462D37B94F; Tue, 18 Jul 2000 18:45:26 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6J1jBu11055; Tue, 18 Jul 2000 18:45:11 -0700 (PDT) Date: Tue, 18 Jul 2000 18:45:11 -0700 From: Alfred Perlstein To: Bosko Milekic Cc: David Malone , net@freebsd.org, iedowse@maths.tcd.ie, sheldonh@freebsd.org, jlemon@freebsd.org, wollman@freebsd.org Subject: Re: kern/19866: The mbuf subsystem refcount stuff. Message-ID: <20000718184511.O13979@fw.wintelcom.net> References: <20000718160033.H13979@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from bmilekic@dsuper.net on Tue, Jul 18, 2000 at 09:09:36PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org moved over to -net. * Bosko Milekic [000718 18:08] wrote: > > On Tue, 18 Jul 2000, Alfred Perlstein wrote: > > > That never happens. If you have an mbuf it's _yours_ no one will > > deref it out from under you otherwise it wouldn't work at all. You > > can NOT pass an mbuf you some subsystem and then free it, you must > > pass a _copy_ of it if you want to use it again later (attach > > another mbuf header and increase the ref count), therefor the > > refcount will be 1 higher and even if it's free()'d at intr you'll > > never go to 0. > > Alfred, it's not the MBUF that is being referenced, it's the ext_buf > attached to the m_ext of the mbuf, which CAN be referenced by multiple > mbufs. The idea is to have the referencing handled by the mbuf because a > single mbuf can only map ONE external object. Er, that's what I meant. The refcount is never 0 unless it's completely free. > > The reason is to hopefully avoid locking the entire pool or locking > > 3 objects to make a single cluster copy. I'm not saying that you > > have to make 3 locks, but I can't see it any other way: > > myself, backward, forward -> manip pointers > > By that logic you're going to have to make per CPU pools and add many > more hysterics to the system. This is not even the beginning of your > problems if your plan is to re-invent the wheel. But if you do plan to do > that, count on me to help you if you request it in the future, however, > don't avoid new things from going in because of it. :-) > > > Actually, I would like to see it go in, the macro approach will > > make it easy to move it over the pointer to refcount memory idea, > > I'd just hoped that you would have done it my way. Your work > > will take us halfway there and be very benificial in the meanwhile > > by reducing the amount of callbacks needed when sending clusters > > as well as simplifying a lot of code and special cases. > > If you have an alternate suggestion that is different than the > existing one (i.e. get absolutely rid of that mclrefcnt global array), > that will WORK, and that is better than what I just proposed (which is > actually taken from NetBSD in part), then I'm all ears and ready to > implement! (By know, you know that I have no problem writing code for > the project) Ok here's an idea that I was tossing around: you have a freelist of these guys, one for each mbuf header, you can make less and deal with failure by sleeping or failing as you want, but for the sake of example one is available for each mbuf at any given time. struct mclrefcnt { struct mclrefcnt *mextr_next; /* XXX: use list macros :) */ atomic_t mextr_refcnt; }; and a pointer to one in each mbuf. when you want to make a copy your code looks something like this: /* copying m into n */ if (m->rp == NULL && n->rp == NULL) { m->rp = n->rp = mclrefcnt_alloc(); } else if (m->rp == NULL) { m->rp = n->rp; } else if (n->rp == NULL) { n->rp = m->rp; } else { mclrefcnt_free(n->rp); n->rp = m->rp; } atomic_inc(m->rp.mextr_refcnt); /* freeing m */ /* x must get the value I reduced it to */ x = atomic_dec_and_fetch(m->rp.mextr_refcnt); if (x == 0) { /* do extfree callback */ } else { m->rp = NULL; } /* free mbuf header */ Are there problems you see with that? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 19:19:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 6910A37B54E for ; Tue, 18 Jul 2000 19:19:31 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id DAA45205; Wed, 19 Jul 2000 03:17:34 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id DAA02445; Wed, 19 Jul 2000 03:17:32 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200007190217.DAA02445@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Gary T. Corcoran" Cc: Brian Somers , FreeBSD Network List , brian@Awfulhak.org Subject: Re: Win2000 -> FreeBSD PPPoE daemon In-Reply-To: Message from "Gary T. Corcoran" of "Tue, 18 Jul 2000 15:00:39 EDT." <3974A957.3C709E24@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Jul 2000 03:17:32 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Brian Somers wrote: > > > > > BTW, just out of curiousity, why does FreeBSD reject the > > > identification packets? Does it really not understand them? > > > > Never heard of them... I take it these are Multi-link Procedure > > options ? I'll stick this on my todo list I guess :-) > > Nope, nothing to do with Multi-Link. Just "identification" for > whatever purpose the remote end might use it. I found it described > in RFC1570. It just says you _should_ display the informational > message contained in the packet upon receipt... Ah, ok. I've added support for this. I'd appreciate it if you could confirm if the latest version behaves. It logs the message to the LCP log. > Gary Cheers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 19:34:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 84C1D37B54E for ; Tue, 18 Jul 2000 19:34:34 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id TAA62643; Tue, 18 Jul 2000 19:34:28 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200007190234.TAA62643@bubba.whistle.com> Subject: Re: mpd-netgraph port vs Windows-2000 PPTP vpn In-Reply-To: <20000719112826.A68949@gurney.reilly.home> from Andrew Reilly at "Jul 19, 2000 11:28:26 am" To: Andrew Reilly Date: Tue, 18 Jul 2000 19:34:28 -0700 (PDT) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrew Reilly writes: > Thanks for answering my question so quickly. Your patch to > lcp.c seems to have pushed us a little further along, but now > we're stalling at the IPCP negotiation phase. > > I discovered that my previous build had not included DES, even > though the relevent bits were on my system. I tweaked the src/Makefile > to include "ENCRYPTION_DES= yes" just under the "ENCRYPTION_MPPE= > yes" line, and it built (with a few prototype warnings). At least > now it recognises the "set ecp accept des" option. Dunno if it's > being used. That shouldn't have any effect since ECP is not negotiated. > The office uses DHCP to assign IP addresses. Does that interact > with the PPTP process? I would imagine that the PPTP server would > have to grab an IP address on my behalf for the IPCP negotiation, > but is it possible that MS somehow skips that, and requires a > separate DHCP session after the link is up? Possible.. though I don't know the mysteries of Windows. I don't know why the NT machine is not responding to your request for an IP address.. maybe it's got some configuration problem with respect to that? Also.. 1. Try changing "set link yes chap" to "set link accept chap". 2. To enable MPPE encryption you want something like this... set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless But the IP problem needs to be figured out first.. Can you connect to this machine using the Win95/98 PPTP dialup adapter? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 19:56:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from sr14.nsw-remote.bigpond.net.au (sr14.nsw-remote.bigpond.net.au [24.192.3.29]) by hub.freebsd.org (Postfix) with ESMTP id 1784237BA26 for ; Tue, 18 Jul 2000 19:56:49 -0700 (PDT) (envelope-from a.reilly@lake.com.au) Received: from areilly.bpc-users.org (CPE-144-132-171-71.nsw.bigpond.net.au [144.132.171.71]) by sr14.nsw-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id MAA05254 for ; Wed, 19 Jul 2000 12:56:44 +1000 (EST) Received: (qmail 76700 invoked by uid 1000); 19 Jul 2000 02:56:43 -0000 From: "Andrew Reilly" Date: Wed, 19 Jul 2000 12:56:43 +1000 To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: mpd-netgraph port vs Windows-2000 PPTP vpn Message-ID: <20000719125643.A75967@gurney.reilly.home> References: <20000719112826.A68949@gurney.reilly.home> <200007190234.TAA62643@bubba.whistle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5vNYLRcllDrimb99" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007190234.TAA62643@bubba.whistle.com>; from archie@whistle.com on Tue, Jul 18, 2000 at 07:34:28PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Archie, Yahoo. Something's working now. Well, I can ping hosts, anyway. I tweaked the configuration file the way you described (and as attached below). > Can you connect to this machine using the Win95/98 PPTP dialup adapter? Yes. Browsing the office LAN didn't work, but I'd put that down to stuff that I don't understand about Windows name services. Now that we have a route, I'll do some more playing... Thanks, -- Andrew --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mpd.conf" vpn: new -i ng1 vpn vpn set bundle no multilink set bundle authname andrew set bundle enable compression set bundle enable crypt-reqd set iface disable on-demand set iface idle 0 set iface route 192.168.10.0/23 set ipcp ranges 0.0.0.0/0 192.168.10.5/0 set ipcp accept vjcomp set link enable no-orig-auth set link keep-alive 10 75 set link max-redial 1 set link yes acfcomp protocomp set link no pap set link accept chap set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless open --5vNYLRcllDrimb99-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 18 23:16:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by hub.freebsd.org (Postfix) with ESMTP id 6AF6737BCDB for ; Tue, 18 Jul 2000 23:16:34 -0700 (PDT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.0) with SMTP id QAA24727; Wed, 19 Jul 2000 16:15:35 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 19 Jul 2000 16:15:35 +1000 (EST) From: Ian Smith To: Matthew Hunt Cc: Renaud Waldura , Steve Shah , archie@whistle.com, freebsd-net@FreeBSD.ORG Subject: Re: "ifconfig" == "ifconfig -a" In-Reply-To: <20000718161229.A96043@wopr.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 18 Jul 2000, Matthew Hunt wrote: > On Wed, Jul 19, 2000 at 12:22:16AM +0200, Renaud Waldura wrote: > > > > > > ifconfig == ifconfig -a Why not. There's always 'man ifconfig' if you want to see syntax. > > > And making route with no parameters print the routing table would be > > > doubly nice. > > > > I will second that. I see both as nice, practical additions that can > > only contribute to make FreeBSD easier to use. > > I have no objection to making ifconfig == ifconfig -a, but it > is not currently the job of route(8) to display the route table. > Making it do so would duplicate functionality that's in netstat(1). Agreed. And we sure don't want 'netstat' == 'netstat -a' :-) Cheers, Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 3:39:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from terminal.sil.at (terminal.sil.at [194.152.178.15]) by hub.freebsd.org (Postfix) with ESMTP id 5039437BE94 for ; Wed, 19 Jul 2000 03:39:37 -0700 (PDT) (envelope-from cjm@terminal.sil.at) Received: from terminal.sil.at (localhost [127.0.0.1]) by terminal.sil.at (8.9.2/8.9.2) with ESMTP id MAA19208; Wed, 19 Jul 2000 12:39:23 +0200 (CEST) Message-Id: <200007191039.MAA19208@terminal.sil.at> X-Mailer: exmh version 2.1.1 01/07/2000 To: renaud@waldura.org (Renaud Waldura) Cc: ras@e-gerbil.net (Richard A. Steenbergen), gcorcoran@lucent.com, mph@astro.caltech.edu, freebsd-net@FreeBSD.ORG Subject: Re: "ifconfig" == "ifconfig -a" In-reply-to: renaud's message of Wed, 19 Jul 0100 01:56:16 +0200. <200007182356.BAA14966@guppy.evolunet.com> X-Face: "0|_!}6Ay;=lSa@qs\q$u2RZUTyW(m(?80f[OF3eR:4uk6rd&+9lUw"6ACgq]hyak/Io Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > On Tue, 18 Jul 2000, Gary T. Corcoran wrote: > > > > > Hmmm.... what about having "route" with no parameters just > > > give a helpful message, something like "To see the current > > > routing table, use the netstat(1) command.". ?? > > > > If nothing else, it is in no way intuitive that "route" says nothing about > > how to view the current routing table. This is one of the most common new > > FreeBSD user questions I hear. At a minimium, something should be hinted > > at in the man page. > > And in an ideal world, the "route" command should do what its name suggests: deal > with routes, and that includes printing them IMHO. > > I hate code/functionnality duplication as much as the next guy, but having to > call a command totally unrelated to "route" to display the routing table (ie. netstat) > has always struck me as a gratuitous twist. > > I cast my vote for a "route print". [x] against NT-ish "route print" later, cjm -- SILVER SERVER \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\\\\ \\ \ cjm@sil.at, cjm@enemy.org, neo@bsdger.org www.sil.at --PGP-Key-ID: 0xA941452D | If I could PING you, and you could PING me, -------------------------| then we were both on the Internet - RFC1287 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 3:58:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by hub.freebsd.org (Postfix) with ESMTP id 6207637B9AC for ; Wed, 19 Jul 2000 03:58:06 -0700 (PDT) (envelope-from DRHAGER@de.ibm.com) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id MAA290174; Wed, 19 Jul 2000 12:58:01 +0200 From: DRHAGER@de.ibm.com Received: from d12mta01.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m3/NCO v2.07) with SMTP id MAA255214; Wed, 19 Jul 2000 12:58:02 +0200 Received: by d12mta01.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256921.003C3901 ; Wed, 19 Jul 2000 12:57:47 +0200 X-Lotus-FromDomain: IBMDE To: "Chris J. Mutter" Cc: ras@e-gerbil.net (Richard A. Steenbergen), gcorcoran@lucent.com, mph@astro.caltech.edu, freebsd-net@FreeBSD.ORG Message-ID: Date: Wed, 19 Jul 2000 12:57:40 +0200 Subject: Re: "ifconfig" == "ifconfig -a" Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> >> I cast my vote for a "route print". > >[x] against NT-ish "route print" There is another issue involved, I believe: netstat is for everyone to have a look - you cant change anything. route is for root to change things vital to the system. To me it makes sense to distinguish. Nontheless I would prefer consistency: mount => all mounts ifconfig => all interfaces route => all routes who => all users logged on etc. --orm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 6:12:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 6FCF737BE1E for ; Wed, 19 Jul 2000 06:12:05 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.15 #1) id 13EtUA-000FNO-00; Wed, 19 Jul 2000 14:02:02 +0100 Received: (from ben) by strontium.scientia.demon.co.uk (Exim 3.15 #1) id 13EtUA-000F1d-00; Wed, 19 Jul 2000 14:02:02 +0100 Date: Wed, 19 Jul 2000 14:02:02 +0100 From: Ben Smithurst To: Matthew Hunt Cc: freebsd-net@freebsd.org Subject: Re: "ifconfig" == "ifconfig -a" Message-ID: <20000719140202.H4668@strontium.scientia.demon.co.uk> References: <3974E68A.63E79868@lucent.com> <20000719012004.A4668@strontium.scientia.demon.co.uk> <20000718180600.A99334@wopr.caltech.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="H/WPIfG0zNp9n2ch" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000718180600.A99334@wopr.caltech.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --H/WPIfG0zNp9n2ch Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Matthew Hunt wrote: > On Wed, Jul 19, 2000 at 01:20:04AM +0100, Ben Smithurst wrote: >=20 >> +cannot be used to print out the entire routing table. >> +For that functionality, please see the > use >> +.Fl r >> +flag to the >> +.Xr netstat 1 >> +command. >=20 > One uses flags, or sees documentation. :-) Actually, I don't think I'll mention the -r flag at all. The route(8) manpage isn't the right place to document netstat(1)'s flags, IMO. I think I'll just say "... please use the netstat(1) command". On second thoughts, I think "For that functionality, the netstat(1) command should be used" would be better. --=20 Ben Smithurst / ben@FreeBSD.org / PGP: 0x99392F7D FreeBSD Documentation Project / --H/WPIfG0zNp9n2ch Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: W99/BMOt2Fjk4pVB0e73S/Zmxysbcxgt iQCVAwUBOXWmyisPVtiZOS99AQHTNQP8DkTITp9iACftjWbfYWzK+VElQjyRp3YQ C1nX7M1Zh8rX3dBDHBNGI63BJ0lyJ2xzodCUbUNCons/O7q4QNpV34M7gZAczIbe StrzT4c4M+OPVmZGcr3liQvNOiLijHeQml3iRd5eO/wStqokDBeaaeSvgtvEktNI biKndG9eCis= =LskB -----END PGP SIGNATURE----- --H/WPIfG0zNp9n2ch-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 7: 3:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id B00D237B755 for ; Wed, 19 Jul 2000 07:03:12 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from modemcable009.62-201-24.mtl.mc.videotron.net ([24.201.62.9]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FXY001WK6QR00@field.videotron.net> for net@FreeBSD.ORG; Wed, 19 Jul 2000 09:56:51 -0400 (EDT) Date: Wed, 19 Jul 2000 09:59:22 -0400 (EDT) From: Bosko Milekic Subject: Re: kern/19866: The mbuf subsystem refcount stuff. In-reply-to: <20000718184511.O13979@fw.wintelcom.net> X-Sender: bmilekic@jehovah.technokratis.com To: Alfred Perlstein Cc: net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 18 Jul 2000, Alfred Perlstein wrote: > moved over to -net. [...] > Ok here's an idea that I was tossing around: > > you have a freelist of these guys, one for each mbuf header, > you can make less and deal with failure by sleeping or failing > as you want, but for the sake of example one is available for > each mbuf at any given time. > > struct mclrefcnt { > struct mclrefcnt *mextr_next; /* XXX: use list macros :) */ > atomic_t mextr_refcnt; > }; Okay, following our discussion yesterday, I can understand why your suggestion is valid, especially given the brief SMP outline and future changes that are to come. There is something that I recently thought of, following a brief beginning in modifying and implementing this, though: the mclrefcnt/mextrefcnt/whatever we want to call it is on a singly linked list to which additions and removes will be made via the head. Therefore, one will have to splimp(), or lock multiple CPUs in the SMP case, when tampering with this list, and this would be during certain reference increments. It's not as bad as the linked list case, which will have to do this during every single additional reference, because it will only need to do it during the first reference call, which will probably come from the allocation macro, which will be under splimp() (or SMP equivalent multiple CPU lock) anyway. Correct? Also, I'm curious at this point as to how some of this stuff is done in BSD/OS, but I don't have access/can't see the source. Any pointers/explanations/brief outlines? I'm mainly curious as to the SMP stuff vs. mbuf pools, whether they are per CPU, etc. Alfred, now that I think about it, I would eventually like to try the per-CPU list idea, to see how well it will scale on an SMP machine with relatively heavy network load, and I'll probably want to do this before I finalize the resource freeing of mbuf-used pages outline. > and a pointer to one in each mbuf. > > when you want to make a copy your code looks something like this: > > /* copying m into n */ > > if (m->rp == NULL && n->rp == NULL) { > m->rp = n->rp = mclrefcnt_alloc(); > } else if (m->rp == NULL) { > m->rp = n->rp; > } else if (n->rp == NULL) { > n->rp = m->rp; > } else { > mclrefcnt_free(n->rp); > n->rp = m->rp; > } > atomic_inc(m->rp.mextr_refcnt); > > > /* freeing m */ > > /* x must get the value I reduced it to */ > x = atomic_dec_and_fetch(m->rp.mextr_refcnt); > if (x == 0) { > /* do extfree callback */ > } else { > m->rp = NULL; > } > /* free mbuf header */ > > Are there problems you see with that? Not by just glancing at it, although the copying of the mbuf code above can be more concise, as you know you're copying say m->m_ext into n->m_ext and incrementing the ref count, so it's not really that tough, as far as I can see right now. To "copy m into n" you just do something like: n->m_ext = m->m_ext; n->m_ext->mextrefcnt++; ...and you're on your way. As we discussed this, you don't have to worry about something else freeing a reference and consequently freeing the mextrefcnt node and ext_buf, because you know that here you have control of both m and n, both of which refer to the same ext_buf, so the refcnt cannot drop below 1, while you're going to atomically increment. You mentionned a race condition in the free code above, yesterday, but I don't exactly recall what. If the refcnt reaches zero above though, you'll have to free the mextrefcnt/mclrefcnt/whatever structure too, at least back to its respective free list. Note that if in the SMP case we decide to split up the free lists, this is one list that will have to remain global, as we may have to deal with mbufs from different CPU free lists referring the same ext_buf's as some allocated from different CPU mbuf free lists. > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." Cheers, Bosko. -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 bmilekic@technokratis.com * http://www.technokratis.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 7:35:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id F0D9137BEE5; Wed, 19 Jul 2000 07:35:35 -0700 (PDT) (envelope-from pherman@frenchfries.net) Received: from bagabeedaboo.security.at12.de (dial-195-14-226-174.netcologne.de [195.14.226.174]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id QAA05352; Wed, 19 Jul 2000 16:35:31 +0200 (MET DST) Received: from localhost (localhost.security.at12.de [127.0.0.1]) by bagabeedaboo.security.at12.de (8.10.2/8.10.2) with ESMTP id e6JEZI600355; Wed, 19 Jul 2000 16:35:18 +0200 (CEST) Date: Wed, 19 Jul 2000 16:35:18 +0200 (CEST) From: Paul Herman To: Ben Smithurst Cc: Matthew Hunt , freebsd-net@FreeBSD.ORG Subject: Re: "ifconfig" == "ifconfig -a" In-Reply-To: <20000719140202.H4668@strontium.scientia.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 19 Jul 2000, Ben Smithurst wrote: > > One uses flags, or sees documentation. :-) > > Actually, I don't think I'll mention the -r flag at all. The route(8) > manpage isn't the right place to document netstat(1)'s flags, IMO. I > think I'll just say "... please use the netstat(1) command". On second > thoughts, I think "For that functionality, the netstat(1) command should > be used" would be better. Hmmm... what led to this idea was: people who use "route print" to print the routing table in "other" OSes need to be informed how to print the routing table under FreeBSD. If that's really true, some how I have a feeling they would already know about "netstat -r" (which AFAIK is pretty much ubiquitous among Unicies.) Is it just me, who thinks this? -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 9: 0: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id C8C7937BF26 for ; Wed, 19 Jul 2000 08:59:58 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id IAA65589; Wed, 19 Jul 2000 08:59:47 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200007191559.IAA65589@bubba.whistle.com> Subject: Re: mpd-netgraph port vs Windows-2000 PPTP vpn In-Reply-To: <20000719125643.A75967@gurney.reilly.home> from Andrew Reilly at "Jul 19, 2000 12:56:43 pm" To: Andrew Reilly Date: Wed, 19 Jul 2000 08:59:47 -0700 (PDT) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrew Reilly writes: > Yahoo. Something's working now. > > Well, I can ping hosts, anyway. Cool.. > > Can you connect to this machine using the Win95/98 PPTP dialup adapter? > > Yes. Browsing the office LAN didn't work, but I'd put that down > to stuff that I don't understand about Windows name services. Browsing is its own little nightmare. Acutally the problem is that the NT server needs to forward broadcasts to you since it's proxy-ARP'ing for your IP address. Also make sure your workgroup is the same. You should be able to connect to a machine via IP address, e.g., from the run menu: "\\123.45.6.7\folder". -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 9:21:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from nets5.rz.rwth-aachen.de (nets5.rz.RWTH-Aachen.DE [137.226.144.13]) by hub.freebsd.org (Postfix) with ESMTP id BFDC737BF5E for ; Wed, 19 Jul 2000 09:21:11 -0700 (PDT) (envelope-from Gerald.Heinig@post.rwth-aachen.de) Received: from post.rwth-aachen.de (s4m219.dialup.RWTH-Aachen.DE [137.226.8.219]) by nets5.rz.rwth-aachen.de (8.10.1/8.10.1/5) with ESMTP id e6JGL4311313; Wed, 19 Jul 2000 18:21:04 +0200 (MET DST) Message-ID: <3975D526.BF27BC1D@post.rwth-aachen.de> Date: Wed, 19 Jul 2000 18:19:50 +0200 From: Gerald Heinig X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: archie@whistle.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: "ifconfig" == "ifconfig -a" References: <200007182222.AAA14545@guppy.evolunet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Renaud Waldura wrote: > > > ifconfig == ifconfig -a > > > > And making route with no parameters print the routing table would be > > doubly nice. Cool idea. I'm all for it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 9:21:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 2034737B53C for ; Wed, 19 Jul 2000 09:21:22 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6JGLFC01576; Wed, 19 Jul 2000 09:21:15 -0700 (PDT) Date: Wed, 19 Jul 2000 09:21:15 -0700 From: Alfred Perlstein To: Bosko Milekic Cc: net@FreeBSD.ORG Subject: Re: kern/19866: The mbuf subsystem refcount stuff. Message-ID: <20000719092114.S13979@fw.wintelcom.net> References: <20000718184511.O13979@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from bmilekic@dsuper.net on Wed, Jul 19, 2000 at 09:59:22AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Bosko Milekic [000719 07:00] wrote: > > On Tue, 18 Jul 2000, Alfred Perlstein wrote: > > > moved over to -net. > > [...] > > > Ok here's an idea that I was tossing around: > > > > you have a freelist of these guys, one for each mbuf header, > > you can make less and deal with failure by sleeping or failing > > as you want, but for the sake of example one is available for > > each mbuf at any given time. > > > > struct mclrefcnt { > > struct mclrefcnt *mextr_next; /* XXX: use list macros :) */ > > atomic_t mextr_refcnt; > > }; > > Okay, following our discussion yesterday, I can understand why your > suggestion is valid, especially given the brief SMP outline and > future changes that are to come. > There is something that I recently thought of, following a brief > beginning in modifying and implementing this, though: the > mclrefcnt/mextrefcnt/whatever we want to call it is on a singly linked > list to which additions and removes will be made via the head. Therefore, > one will have to splimp(), or lock multiple CPUs in the SMP case, when > tampering with this list, and this would be during certain reference > increments. It's not as bad as the linked list case, which will have to > do this during every single additional reference, because it will only > need to do it during the first reference call, which will probably come > from the allocation macro, which will be under splimp() (or SMP > equivalent multiple CPU lock) anyway. Correct? Yes the freelist of refcount structures must be protected, at a later point we may be able to move them to per-processor buckets and lock against ourselves (interrupt) for the most part. Although I could have sworn I'd seen a way to manage a singly linked queue without locks in one of the texts I own. > Also, I'm curious at this point as to how some of this stuff is > done in BSD/OS, but I don't have access/can't see the source. Any > pointers/explanations/brief outlines? I'm mainly curious as to the SMP > stuff vs. mbuf pools, whether they are per CPU, etc. Alfred, now that I > think about it, I would eventually like to try the per-CPU list idea, to > see how well it will scale on an SMP machine with relatively heavy network > load, and I'll probably want to do this before I finalize the resource > freeing of mbuf-used pages outline. From what I can see they do it our way for the most part, the only difference is that they only have a single function pointer for ref/deref, when you're increasing ref you get 2 pointers to mbufs, when decreasing you get 1 and the other is NULL. It's called on _every_ ref, just like what we have now. > > and a pointer to one in each mbuf. > > > > when you want to make a copy your code looks something like this: > > > > /* copying m into n */ > > > > if (m->rp == NULL && n->rp == NULL) { > > m->rp = n->rp = mclrefcnt_alloc(); \--------------------------------/ This is a race condition. --/ There's a chance that two cpu threads may issue a m_copym on a mbuf chain on seperate CPUs, if the mbuf chain's refcounts aren't yet allocated and NULL, there's a race where _both_ CPUs will call this code. The effect will be an incorrect refcount and the leaking of a refcount structure. Pretty fatal. the code will have to change to something like this: mclrefcnt_free(n->rp); n->rp = m->rp; atomic_inc(m->rp.mextr_refcnt); which is actually simpler. :) The solution I see is to never have it NULL.. See the comments on the free function. > > } else if (m->rp == NULL) { > > m->rp = n->rp; > > } else if (n->rp == NULL) { > > n->rp = m->rp; > > } else { > > mclrefcnt_free(n->rp); > > n->rp = m->rp; > > } > > atomic_inc(m->rp.mextr_refcnt); > > > > > > /* freeing m */ > > > > /* x must get the value I reduced it to */ > > x = atomic_dec_and_fetch(m->rp.mextr_refcnt); > > if (x == 0) { > > /* do extfree callback */ > > } else { > > m->rp = NULL; This is incorrect, the code should be: m->rp = mclrefcnt_alloc(); that will ensure that we don't have mbufs where the m->rp isn't initialized to a structure, it also allows us to simplify the copy code above. the mbufs startup code will have to pre-assign them all refcount structures. > > } > > /* free mbuf header */ > > > > Are there problems you see with that? > > Not by just glancing at it, although the copying of the mbuf code > above can be more concise, as you know you're copying say m->m_ext into > n->m_ext and incrementing the ref count, so it's not really that tough, > as far as I can see right now. To "copy m into n" you just do something > like: > n->m_ext = m->m_ext; > n->m_ext->mextrefcnt++; > > ...and you're on your way. As we discussed this, you don't have to worry > about something else freeing a reference and consequently freeing the > mextrefcnt node and ext_buf, because you know that here you have control > of both m and n, both of which refer to the same ext_buf, so the refcnt > cannot drop below 1, while you're going to atomically increment. > > You mentionned a race condition in the free code above, yesterday, > but I don't exactly recall what. If the refcnt reaches zero above though, > you'll have to free the mextrefcnt/mclrefcnt/whatever structure too, at > least back to its respective free list. Note that if in the SMP case we > decide to split up the free lists, this is one list that will have to > remain global, as we may have to deal with mbufs from different CPU free > lists referring the same ext_buf's as some allocated from different > CPU mbuf free lists. The race condition is outlined above and I think the solution ought to work. The refcount list certainly does not need to remain global, there's nothing wrong with per-cpu pools of them and when your own pool is exhausted you can try to lock against another CPU's pool and steal structures. The CPUs will have to lock thier own queues against themselves for protection against interrupts, doing so is cheap, when we have a shortage we can take the performance hit to lock against another CPU in order to steal refcount structures. And if that code to do queue/dequeue wasn't just a figment of my imagination we may not need to lock at all. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 11: 4:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from duchess.wagill.com (duchess.wagill.com [198.182.208.147]) by hub.freebsd.org (Postfix) with ESMTP id 522DC37BFA1 for ; Wed, 19 Jul 2000 11:04:48 -0700 (PDT) (envelope-from bill@wagill.com) Received: from localhost (bill@localhost) by duchess.wagill.com (8.8.7/8.8.7) with SMTP id LAA16654; Wed, 19 Jul 2000 11:04:03 -0700 (PDT) (envelope-from bill@wagill.com) Date: Wed, 19 Jul 2000 11:04:02 -0700 (PDT) From: Bill Reply-To: Bill To: "Chris J. Mutter" Cc: Renaud Waldura , "Richard A. Steenbergen" , gcorcoran@lucent.com, mph@astro.caltech.edu, freebsd-net@FreeBSD.ORG Subject: Re: "ifconfig" == "ifconfig -a" In-Reply-To: <200007191039.MAA19208@terminal.sil.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [x] against NT-ish "route print" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 13:32:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from jason.argos.org (a1-3a062.neo.rr.com [24.93.180.62]) by hub.freebsd.org (Postfix) with ESMTP id 9A42237B54A; Wed, 19 Jul 2000 13:32:24 -0700 (PDT) (envelope-from mike@argos.org) Received: from localhost (mike@localhost) by jason.argos.org (8.10.1/8.10.1) with ESMTP id e6JKVuN14888; Wed, 19 Jul 2000 16:31:56 -0400 Date: Wed, 19 Jul 2000 16:31:56 -0400 (EDT) From: Mike Nowlin To: Paul Herman Cc: Ben Smithurst , Matthew Hunt , freebsd-net@FreeBSD.ORG Subject: Re: "ifconfig" == "ifconfig -a" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hmmm... what led to this idea was: people who use "route print" to > print the routing table in "other" OSes need to be informed how to > print the routing table under FreeBSD. If that's really true, some > how I have a feeling they would already know about "netstat -r" (which > AFAIK is pretty much ubiquitous among Unicies.) > > Is it just me, who thinks this? Nope - not just you. Just because Linux does something in a particular way doesn't mean that FBSD should. Linux is the exception, not the rule, as far as LOTS of the system config commands are concerned -- if "making it act like other systems" is to be an issue, we should make it act like the big boys, not like the one rogue system that's just different (yet popular) enough to cause some confusion.... (DEC UNIX) ig88:~$ route usage: route [-n] [-C] cmd [[-net|-host] [/bitmask] [-netmask ] ] (AIX) wookie:~$ route usage: route [ -nqCvf ] cmd [[ - ] args ] (FBSD) bobafett:~$ route usage: route [-dnqtv] command [[modifiers] args] ...not to mention "netstat -f inet", /etc/exports, and several others. --mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 13:55:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from amazhan.bitstream.net (amazhan.bitstream.net [216.243.128.132]) by hub.freebsd.org (Postfix) with SMTP id 8F0AD37C065 for ; Wed, 19 Jul 2000 13:55:23 -0700 (PDT) (envelope-from airboss@bitstream.net) Received: (qmail 72319 invoked by uid 79); 19 Jul 2000 20:55:20 -0000 Received: from dmitri.bitstream.net (206.144.236.191) by mail.bitstream.net with SMTP; 19 Jul 2000 20:55:20 -0000 Date: Wed, 19 Jul 2000 16:03:00 -0500 (CDT) From: Dan Debertin To: Mike Nowlin Cc: Paul Herman , Ben Smithurst , Matthew Hunt , freebsd-net@FreeBSD.ORG Subject: Re: "ifconfig" == "ifconfig -a" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm with you there, Mike. Linux (not to disparage it) is the divergent one. Increasing the level of incompatibility will only have a concomitant effect on people's level of confusion. This particular change won't break anything huge, but I disagree with the overall Linux-emulation philosophy. See below for more unices ... Solaris 7 (and 6) xenon [3:43pm] # route usage: route [ -fnqv ] cmd [[ - ] args ] SunOS 5.5.1: senator [3:50pm] # route senator [3:50pm] # (i.e. nothing) IRIX: copper# route usage: route [ -nqvfF ] cmd [[ - ] args ] > > Nope - not just you. Just because Linux does something in a particular > way doesn't mean that FBSD should. Linux is the exception, not the rule, > as far as LOTS of the system config commands are concerned -- if "making > it act like other systems" is to be an issue, we should make it act like > the big boys, not like the one rogue system that's just > different (yet popular) enough to cause some confusion.... > > (DEC UNIX) > ig88:~$ route > usage: route [-n] [-C] cmd [[-net|-host] [/bitmask] [-netmask > ] ] > > (AIX) > wookie:~$ route > usage: route [ -nqCvf ] cmd [[ - ] args ] > > (FBSD) > bobafett:~$ route > usage: route [-dnqtv] command [[modifiers] args] > > ...not to mention "netstat -f inet", /etc/exports, and several others. > > > --mike > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > ~Dan D. -- __________________________________________________________________ -- I feel the earth move. -- I feel the tumbling down, the tumbling down. ++ Dan Debertin ++ Senior Systems Administrator ++ Bitstream Underground, LLC ++ airboss@bitstream.net ++ (612)321-9290 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 14: 8:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from gluttony.henshaw.net (gluttony.henshaw.net [63.70.222.4]) by hub.freebsd.org (Postfix) with SMTP id AB46337B873 for ; Wed, 19 Jul 2000 14:08:10 -0700 (PDT) (envelope-from ben@henshaw.net) Received: (qmail 43927 invoked from network); 19 Jul 2000 21:08:06 -0000 Received: from dhcp-63-70-222-246.henshaw.net (HELO ben.henshaw.net) (63.70.222.246) by gluttony.henshaw.net with SMTP; 19 Jul 2000 21:08:06 -0000 Message-Id: <4.3.2.7.2.20000719150237.00c41100@mail.henshaw.net> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jul 2000 15:08:06 -0600 To: freebsd-net@FreeBSD.ORG From: Ben Schumacher Subject: Re: "ifconfig" == "ifconfig -a" In-Reply-To: References: <20000719140202.H4668@strontium.scientia.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 04:35 PM 7/19/00 +0200, Paul Herman wrote: >Hmmm... what led to this idea was: people who use "route print" to >print the routing table in "other" OSes need to be informed how to >print the routing table under FreeBSD. If that's really true, some >how I have a feeling they would already know about "netstat -r" (which >AFAIK is pretty much ubiquitous among Unicies.) > >Is it just me, who thinks this? I personally, cast my (mostly meaningless) vote against "route print" or just "route" showing routing tables. To be honest, even on those other OSes, I always type netstat -r to get routing tables (which works on Win9x/NT, as well). Normally when I type just "route" it is to remind my simple mind of the syntax I need to use on the rare occasions that I need to change routing tables. Just my two cents. - Ben Schumacher To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 14:57:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id AE9B437B711 for ; Wed, 19 Jul 2000 14:57:20 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.15 #1) id 13F1pf-000GtP-00; Wed, 19 Jul 2000 22:56:47 +0100 Received: (from ben) by strontium.scientia.demon.co.uk (Exim 3.15 #1) id 13F1pf-000Ibz-00; Wed, 19 Jul 2000 22:56:47 +0100 Date: Wed, 19 Jul 2000 22:56:47 +0100 From: Ben Smithurst To: Mike Nowlin Cc: Paul Herman , Matthew Hunt , freebsd-net@FreeBSD.ORG Subject: Re: "ifconfig" == "ifconfig -a" Message-ID: <20000719225647.E75784@strontium.scientia.demon.co.uk> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7CZp05NP8/gJM8Cl" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --7CZp05NP8/gJM8Cl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mike Nowlin wrote: > Just because Linux does something in a particular way doesn't mean > that FBSD should. I'm not suggesting we should! I'm just suggesting adding a note to the manual page telling people where to look if that's the functionality they want. "route" may be the logical command for some people to print out the entire routing table, and the manpage at the moment doesn't even hint on how to do that as far as I can see. --=20 Ben Smithurst / ben@FreeBSD.org / PGP: 0x99392F7D FreeBSD Documentation Project / --7CZp05NP8/gJM8Cl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: UVV73qijs29e5lKwuGn4SDUxIi1pOfO9 iQCVAwUBOXYkHisPVtiZOS99AQEVOQP+JFTDGhbfUgRtK/xfOVqQlv89UwBKNWLC o/RdG4Yil+wI/+GGL+FAgEgY+yLuhA2EQKbYetFJ4UJO+DV499sqS811VefOC0pP n1sAYcigPEZMHztZams0eE5O/dWtDCWZdWF0uMPjGeFPylw44sV6Oying6iaa799 SObu9Sweaq8= =Gw5f -----END PGP SIGNATURE----- --7CZp05NP8/gJM8Cl-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 15:26:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from web.mercuryfilmworks.com (web.mercuryfilmworks.com [209.17.176.194]) by hub.freebsd.org (Postfix) with ESMTP id CFCE337B875 for ; Wed, 19 Jul 2000 15:26:53 -0700 (PDT) (envelope-from derrick@mercuryfilmworks.com) Received: from odin.mercuryfilmworks.com ([209.17.174.153] helo=mercuryfilmworks.com) by web.mercuryfilmworks.com with esmtp (Exim 3.15 #1) id 13F2Kc-0008Qe-00 for freebsd-net@freebsd.org; Wed, 19 Jul 2000 15:28:46 -0700 Message-ID: <39762B54.BE0CDACB@mercuryfilmworks.com> Date: Wed, 19 Jul 2000 15:27:33 -0700 From: Derrick MacPherson X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: AltQ/dummynet & IP accounting.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 2 different questions, maybe they can even be done by the same box without a problem? What seems to be the better of the two - AltQ or dummynet? Is one better for certain jobs? Can I monitor (for stats gathering, see who is using our bandwidth, what protocols/ports, what direction) 3 or more partial Class C's and is there a 'sexy' way to do this, or do I end up with a number like 6 gazzilion, and I need to get a calculator, divide by the sum of the square root of a parsec, inverse that number and I get a megabyte total for 1 machine. (I have a machine that I will be putting between our router and the net I am just looking for a way to NOT pay Bill Gates) -- Derrick MacPherson Mercury Filmworks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 16: 7:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 316BD37B538 for ; Wed, 19 Jul 2000 16:07:11 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from modemcable009.62-201-24.mtl.mc.videotron.net ([24.201.62.9]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FXY003L7VVJK1@falla.videotron.net> for net@FreeBSD.ORG; Wed, 19 Jul 2000 18:59:43 -0400 (EDT) Date: Wed, 19 Jul 2000 19:02:16 -0400 (EDT) From: Bosko Milekic Subject: Re: kern/19866: The mbuf subsystem refcount stuff. In-reply-to: <20000719092114.S13979@fw.wintelcom.net> X-Sender: bmilekic@jehovah.technokratis.com To: Alfred Perlstein Cc: net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 19 Jul 2000, Alfred Perlstein wrote: > > > when you want to make a copy your code looks something like this: > > > > > > /* copying m into n */ > > > > > > if (m->rp == NULL && n->rp == NULL) { > > > m->rp = n->rp = mclrefcnt_alloc(); > \--------------------------------/ > This is a race condition. --/ > > There's a chance that two cpu threads may issue a m_copym on a mbuf > chain on seperate CPUs, if the mbuf chain's refcounts aren't yet > allocated and NULL, there's a race where _both_ CPUs will call this > code. > > The effect will be an incorrect refcount and the leaking of a > refcount structure. Pretty fatal. > > the code will have to change to something like this: > > mclrefcnt_free(n->rp); > n->rp = m->rp; > atomic_inc(m->rp.mextr_refcnt); > > which is actually simpler. :) This seems unnecessary, as far as I can see. If you are "copying m into n" the idea is that "m" is already allocated and, if it is an M_EXT mbuf, it already has a mextrfcnt structure allocated for it, and is pointing to it. How this works is that when you allocate an mbuf and assign it external storage, the first mbuf to be assigned this ext_buf will be the one that will have to perform the locking and get the mextrefcnt allocated and detatched from the list of mextrefcnt's. Let's say this "first" mbuf is called `m,' then later on you can copy `m' into `n' by giving `n' the same m_ext struct as `m,' and then having n->m_ext->mextr_refcnt be incremented (++), which doesn't need any locking. You should clearly be able to have mbufs that are not at all associated to mextrfcnts for the simple reason that it would be useless if they don't have external storage associated to them. If, when you are copying m into n, n already has a reference pointer, then you're in big trouble and what you're doing is incorrect. > The solution I see is to never have it NULL.. See the comments on > the free function. It's safe to have it null when you're not using m_ext (when the mbuf doesn't refer to an ext_buf). I don't see why you would check BOTH m and n's refcnt pointers when you should take for granted that if you are copying something into n, then n surely isn't referencing anything else because if it is, you shouldn't be copying anything into it unless you free what was previously there first. > > > > } else if (m->rp == NULL) { > > > m->rp = n->rp; > > > } else if (n->rp == NULL) { > > > n->rp = m->rp; > > > } else { > > > mclrefcnt_free(n->rp); > > > n->rp = m->rp; > > > } > > > atomic_inc(m->rp.mextr_refcnt); > > > > > > > > > /* freeing m */ > > > > > > /* x must get the value I reduced it to */ > > > x = atomic_dec_and_fetch(m->rp.mextr_refcnt); > > > if (x == 0) { > > > /* do extfree callback */ > > > } else { > > > m->rp = NULL; > > This is incorrect, the code should be: > m->rp = mclrefcnt_alloc(); > > that will ensure that we don't have mbufs where the m->rp isn't > initialized to a structure, it also allows us to simplify the copy > code above. > > the mbufs startup code will have to pre-assign them all refcount > structures. Not all mbufs should have an assigned mextrefcnt, because not all mbufs refer to external storage, so it would be a waste of memory. When you free an mbuf, you'll also have to be under splimp() most likely (unless we find those atomic queue manip. constructs). The reason is that you'll be placing the mbuf back on the list, which requires blocking against interrupts, and also against other CPUs in the SMP case (unless we decide to split the list in the future). So what you do in this case should be more like this: struct mextrefcnt *our_ref = mbuf_to_be_freed->m_ext->mext_refcnt; int s = splimp(); our_ref->counter--; if (our_ref->counter == 0) { /* call (mbuf_to_be_freed->m_ext->ext_free)(blah, blah) */ /* free mextrefcnt structure (our_ref) to the mextrefcnt freelist */ } mbuf_to_be_freed->m_ext->m_ext_refcnt = NULL; /* actually, all of the mbuf's m_ext should be zero'd, but the next allocation should take care of that anyway, so we can skip it here and do it during the allocating of the mbuf. */ free_the_mbuf(mbuf_to_be_freed); Clearly, when you are freeing the mbuf, you have to splimp(), but this is normal for now. The idea is though that you _don't_ have to splimp() when you just increment the ref count, unless it's the first incrementation. This is the reason, as I understand it, that your idea makes sense (as opposed to my linked list idea which always needed to be splimp()ed). Naturally, MEXTADD() will also have to be modified to not only setup the mbuf for the ext_buf type (e.g. setup ext_free, and other m_ext fields) but to also splimp() and allocate the mextrefcnt structure and increment it by one. This is expected. > The race condition is outlined above and I think the solution ought > to work. > > The refcount list certainly does not need to remain global, there's > nothing wrong with per-cpu pools of them and when your own pool is > exhausted you can try to lock against another CPU's pool and steal > structures. Well, now that I've thought about it more extensively, this does make sense, but only if you consider that just because an mbuf was originally allocated from CPU#1's freelist, doesn't mean that it necessarily has to be freed to CPU#1's freelist, such that it may end up on any of the CPU's freelists eventually; same goes for the mextrefcnt list elements. > The CPUs will have to lock thier own queues against themselves for > protection against interrupts, doing so is cheap, when we have a > shortage we can take the performance hit to lock against another > CPU in order to steal refcount structures. Agreed. But if we do go with this, we'll REALLY be in trouble when it comes to freeing physical memory, especially if you consider that each CPU's freelists can now contain mbufs from pretty much anywhere. In other words, I can now have 16 mbufs making up a page spread out across 4 different CPU's free lists, and I would have to giant lock in order to free them, or even track all of them at that (say I want to move them to a less used list, etc.). Poul-Henning, do you see what I mean, given discussions we had regarding this? > And if that code to do queue/dequeue wasn't just a figment of my > imagination we may not need to lock at all. I think Mike blurted out that there are some atomic queue manipulation constructs, although I am personally not familiar with them (yet). If we do find them and they do apply, we will see a dramatic advantage not only in the SMP area, but overall. It almost seems to good to be applicable. :-) > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." Cheers, Bosko. -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 bmilekic@technokratis.com * http://www.technokratis.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 16: 8: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from prioris.im.pw.edu.pl (pf39.warszawa.sdi.tpnet.pl [213.25.209.39]) by hub.freebsd.org (Postfix) with ESMTP id 69B5437B824 for ; Wed, 19 Jul 2000 16:08:00 -0700 (PDT) (envelope-from zaks@prioris.im.pw.edu.pl) Received: by prioris.im.pw.edu.pl (Postfix, from userid 1000) id 46E1A6394E; Thu, 20 Jul 2000 01:07:44 +0200 (CEST) Content-MD5: 1e4beeb86459ecb5f370ceaf4ca248d2 From: Slawek Zak To: freebsd-net@freebsd.org Subject: tcpdump on tun0 strangeness Organization: Ministerstwo smierci na wojnie Date: 20 Jul 2000 01:07:43 +0200 Message-ID: <878zux7m80.fsf@localhost.localnet> Lines: 24 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've found a strange bahaviour of tcpdump in 4.1-RC (and 4.0) when listening on tun0 interface. When I specify the protocol to filter, tcpdump shows only packets going out. Without the filter I see all the packets. # tcpdump -i tun0 Shows all packets when pinging any remote host # tcpdump -i tun0 icmp Shows only packets going out. # tcpdump -i fxp0 icmp (Ethernet link) Works just fine too. Any ideas?? -- `When any government, or any church for that matter, undertakes to say to its subjects, "This you may not read, this you must not see, this you are forbidden to know," the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, "If this goes on --" Suavek Zak / PGP: finger://zaks@prioris.mini.pw.edu.pl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 16:15:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id D372B37B56B for ; Wed, 19 Jul 2000 16:15:41 -0700 (PDT) (envelope-from julian@elischer.org) Received: from casablanca-45.budapest.interware.hu ([195.70.53.45] helo=jules.elischer.org) by mail.interware.hu with smtp (Exim 3.12 #1 (Debian)) id 13F32w-0006L4-00; Thu, 20 Jul 2000 01:14:35 +0200 Message-ID: <39763643.167EB0E7@elischer.org> Date: Wed, 19 Jul 2000 16:14:11 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Archie Cobbs Cc: "Vladimir N. Kovalev" , freebsd-net@FreeBSD.ORG Subject: Re: FWD: TAU-PCI-E1 and NETGRAPH Frame Relay References: <200007192303.QAA68792@bubba.whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs wrote: > > FYI- > -Archie > > > Hello ! > During a one week ago I'm trying to install syncronous E1 card from Cronyx > Engineering (www.cronyx.ru) Tau-PCI-E1 into my FreeBSD 4.0-STABLE server and > connect it to IPTL Radwiz System via Frame Relay. . But without success. > > First of all, I install Tau drivers v 3.33 according the instruction and put > into kernell config file some parameters for NETGRAPH and this card. Looks like > options NETGRAPH > options NETGRAPH_CRONYX # Netgraph mode > options NETGRAPH_FRAME_RELAY > options NETGRAPH_LMI > ..... > # Cronyx-Tau-PCI adapter(s). > device cp0 > > After recompile kernel and reboot system I saw, that Unix detect this card > /kernel: cp0: mem > 0xe4000000-0xe400ffff,0xe4010000-0xe40107ff irq 9 at device 11.0 on pci0 > /kernel: cp0: Tau-PCI-E1, clock 16 MHz > Fine. > > Then, I set some parameters for card like syncronization, time slots and CRC. > sconfig cp0 syn=rcv crc4=on use16=on ts=1-31 > And execute following command for the NETGRAPH > # create a frame_relay type node and attach it to the sync port. > ngctl mkpeer cp0: frame_relay rawdata downstream > # Attach the dlci output of the (de)multiplexor to a new > # Link management protocol node. > ngctl mkpeer cp0:rawdata lmi dlci0 auto0 Missing step: ngctl connect cp0:rawdata cp0:rawdata.dlci0 dlci1023 auto1023 OR ngctl name cp0:rawdata mux0 ngctl name mux0:dlci0 lmp0 ngctl connect mux0: lmp0: dlci1023 auto1023 > # Attach the DLCI(channel) the Telco has assigned you to > # a node to hadle whatever protocol encapsulation your peer > # is using. In this case rfc1490 encapsulation. > ngctl mkpeer cp0:rawdata rfc1490 dlci100 downstream > # Attach the ip (inet) protocol output of the protocol mux to the ip (inet) > # input of a netgraph "interface" node (ifconfig should show it as "ng0"). > #if interface ng0 needs to be created use a mkpeer command.. e.g. > ngctl mkpeer cp0:rawdata.dlci100 iface inet inet > # Then use ifconfig on interface ng0 as usual > ifconfig ng0 10.0.4.2 10.0.4.1 netmask 255.255.255.252 > > As result of this manipulation all signals on Tau turn on. > /var/log > sconfig -i > cp0 idle cfg=A 1984000 syn=rcv higain=off use16=on crc4=off loop=off ts=1-31 > /var/log > sconfig -m > Channel LE DTR DSR RTS CTS CD > cp0 On On On On On On > > Unfortunetly, I have no replay on ping to 10.0.4.1 yet. > But in /var/log/messages I find such strings > Jul 18 09:35:48 tau /kernel: nglmi: unexpected message type(0x0) > Jul 18 09:35:49 tau /kernel: nglmi: error at location 3 > Jul 18 09:35:49 tau /kernel: nglmi: packet data: 03 08 00>75 95 01 01 00 03 02 > 0b 00 > Jul 18 09:35:49 tau /kernel: nglmi: no response from exchange > Jul 18 09:35:59 tau /kernel: nglmi: unexpected message type(0x0) > Jul 18 09:35:59 tau /kernel: nglmi: error at location 3 > Jul 18 09:35:59 tau /kernel: nglmi: packet data: 03 08 00>75 95 01 01 00 03 02 > 0c 00 > > Anybody know that does this message mean ? > Or there I make mistake ? > > Thanks in advance. > > Best regards > Vladimir N. Kovalev > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > ----- End of forwarded message from Vladimir N. Kovalev ----- > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ;_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 16:21:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.visgen.com (uu-t1-6.visgen.com [216.94.71.6]) by hub.freebsd.org (Postfix) with ESMTP id 877CC37B6B9 for ; Wed, 19 Jul 2000 16:21:11 -0700 (PDT) (envelope-from scott@visgen.com) Received: from vindicator2.visgen.com (evans-auto-229 [192.168.3.229]) by mail.visgen.com (8.9.3/8.9.3) with ESMTP id TAA01583 for ; Wed, 19 Jul 2000 19:21:09 -0400 (EDT) Message-Id: <4.3.2.20000719190642.00c86e20@pophost> X-Sender: scott@pophost X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 19 Jul 2000 19:19:46 -0400 To: freebsd-net@freebsd.org From: Scott Augustus Subject: named errors Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey! I'm relatively new to FreeBSD but have a lot of experience with OpenBSD. I've got a couple of servers that I'm having difficulty getting named running properly on and can't seem to find much documentation on the topic. I'd say I've got named about 99% done but I'm having problems doing an interactive nslookup from other machines to these freebsd boxes (ie: nslookup - freebsdbox) I get the following errors: *** Can't find server name for address xxx.xxx.xxx.xxx: Non-existent host/domain *** Default servers are not available However, you can do local interactive nslookups no problem. I'm thinking it might have something to do with hosed PTR records or something. Just wondering if anyone has any tips as to what would cause this to happen or maybe point me at a good named doc/faq, or sample named.conf files for FreeBSD, which I've yet to find! Best Regards, Scott Augustus Systems/Network Administrator Visible Genetics Inc. 291 Evans Ave. Toronto, ON M8Z 5T1 Phone: 416-991-3228 Email: scott@visgen.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 16:34:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 1456B37B73C for ; Wed, 19 Jul 2000 16:34:53 -0700 (PDT) (envelope-from julian@elischer.org) Received: from casablanca-45.budapest.interware.hu ([195.70.53.45] helo=jules.elischer.org) by mail.interware.hu with smtp (Exim 3.12 #1 (Debian)) id 13F3Lu-0007Gq-00; Thu, 20 Jul 2000 01:34:10 +0200 Message-ID: <39763ADB.2781E494@elischer.org> Date: Wed, 19 Jul 2000 16:33:47 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Archie Cobbs Cc: "Vladimir N. Kovalev" , freebsd-net@FreeBSD.ORG Subject: Re: FWD: TAU-PCI-E1 and NETGRAPH Frame Relay References: <200007192303.QAA68792@bubba.whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Jul 18 09:35:48 tau /kernel: nglmi: unexpected message type(0x0) > Jul 18 09:35:49 tau /kernel: nglmi: error at location 3 > Jul 18 09:35:49 tau /kernel: nglmi: packet data: 03 08 00>75 95 01 01 00 03 02 > 0b 00 > Jul 18 09:35:49 tau /kernel: nglmi: no response from exchange > Jul 18 09:35:59 tau /kernel: nglmi: unexpected message type(0x0) > Jul 18 09:35:59 tau /kernel: nglmi: error at location 3 > Jul 18 09:35:59 tau /kernel: nglmi: packet data: 03 08 00>75 95 01 01 00 03 02 > 0c 00 > > Anybody know that does this message mean ? > Or there I make mistake ? This is a status INQUIRY packet (type 75). We are expemcting an status RESPONSE (type 7D) WE should be sending inquiry packets, not the other end This looks like something was in loopback mode. (OR the other end is also running in 'DTE' mode.) As I mentionned in the other mail, the sequence of commands you are running is incomplete so it should not be actively sending packets yet, so these shouldn't be our own packets echoed, so the othe rend must be sending htem, in which case it's in the wrong mode. (or it isn't a frame relay line, but you have frame relay equipment on it) 03 UI Header 08 Protocol discriminator "Frame realy" 00 Call reference # >75 Status Inquiry 95 Annex D escape 01 Annex D report type (normal) 01 Size 1 00 Full report reqested. 03 Annex D verifivation IE 02 2 bytes info follow: 0c local sequence number 00 remote sequence number > > Thanks in advance. > > Best regards > Vladimir N. Kovalev > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > ----- End of forwarded message from Vladimir N. Kovalev ----- > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ;_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 16:38: 4 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 6E8A837B75D for ; Wed, 19 Jul 2000 16:38:01 -0700 (PDT) (envelope-from nick@rapidnet.com) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id RAA01381; Wed, 19 Jul 2000 17:37:58 -0600 (MDT) Date: Wed, 19 Jul 2000 17:37:58 -0600 (MDT) From: Nick Rogness To: Scott Augustus Cc: freebsd-net@freebsd.org Subject: Re: named errors In-Reply-To: <4.3.2.20000719190642.00c86e20@pophost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 19 Jul 2000, Scott Augustus wrote: > I'd say I've got named about 99% done but I'm having problems doing an > interactive nslookup from other machines to these freebsd boxes (ie: > nslookup - freebsdbox) I get the following errors: > > *** Can't find server name for address xxx.xxx.xxx.xxx: Non-existent > host/domain > *** Default servers are not available Your xxx.xxx.xxx.xxx doesn't have a PTR record. If you own that IP (or range), you will need to add in-addr-arpa records for those IPs. If they are not delegated to you then whomever owns them doesn't have PTR records intact. If they are non-routeables, you should add an in-addr-arpa zone for them. > > However, you can do local interactive nslookups no problem. > > I'm thinking it might have something to do with hosed PTR records or > something. Just wondering if anyone has any tips as to what would cause > this to happen or maybe point me at a good named doc/faq, or sample > named.conf files for FreeBSD, which I've yet to find! This could be a any number of problems. Check to make sure that you can do a reverse lookup (PTR) on your default nameserver's IP address. The name server configuration for FreeBSD should be no different than that on an OpenBSD, linux, etc, Unix box. What works on one should work on another (default)...that is if you are running ISC's BIND. I would recommend buying OReilly's DNS/Bind rev 3 book. It is a great reference and should answer most of your DNS questions. Nick Rogness - Speak softly and carry a Gigabit switch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 16:52: 1 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1EC9C37BDAC for ; Wed, 19 Jul 2000 16:51:52 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6JNpoK16493; Wed, 19 Jul 2000 16:51:50 -0700 (PDT) Date: Wed, 19 Jul 2000 16:51:50 -0700 From: Alfred Perlstein To: Bosko Milekic Cc: net@FreeBSD.ORG Subject: Re: kern/19866: The mbuf subsystem refcount stuff. Message-ID: <20000719165150.A13979@fw.wintelcom.net> References: <20000719092114.S13979@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from bmilekic@dsuper.net on Wed, Jul 19, 2000 at 07:02:16PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Bosko Milekic [000719 16:03] wrote: > > On Wed, 19 Jul 2000, Alfred Perlstein wrote: > > > > > when you want to make a copy your code looks something like this: > > > > > > > > /* copying m into n */ > > > > > > > > if (m->rp == NULL && n->rp == NULL) { > > > > m->rp = n->rp = mclrefcnt_alloc(); > > \--------------------------------/ > > This is a race condition. --/ > > > > There's a chance that two cpu threads may issue a m_copym on a mbuf > > chain on seperate CPUs, if the mbuf chain's refcounts aren't yet > > allocated and NULL, there's a race where _both_ CPUs will call this > > code. > > > > The effect will be an incorrect refcount and the leaking of a > > refcount structure. Pretty fatal. > > > > the code will have to change to something like this: > > > > mclrefcnt_free(n->rp); > > n->rp = m->rp; > > atomic_inc(m->rp.mextr_refcnt); > > > > which is actually simpler. :) > > This seems unnecessary, as far as I can see. If you are "copying m > into n" the idea is that "m" is already allocated and, if it is an M_EXT > mbuf, it already has a mextrfcnt structure allocated for it, and is > pointing to it. How this works is that when you allocate an mbuf and > assign it external storage, the first mbuf to be assigned this ext_buf > will be the one that will have to perform the locking and get the > mextrefcnt allocated and detatched from the list of mextrefcnt's. Let's > say this "first" mbuf is called `m,' then later on you can copy `m' into > `n' by giving `n' the same m_ext struct as `m,' and then having > n->m_ext->mextr_refcnt be incremented (++), which doesn't need any > locking. You should clearly be able to have mbufs that are not at all > associated to mextrfcnts for the simple reason that it would be useless > if they don't have external storage associated to them. > If, when you are copying m into n, n already has a reference pointer, > then you're in big trouble and what you're doing is incorrect. Yes, you can look at it like that, I agree that the refcnt structs should be allocate at MEXTADD time as you state below. > > > The solution I see is to never have it NULL.. See the comments on > > the free function. > > It's safe to have it null when you're not using m_ext (when the mbuf > doesn't refer to an ext_buf). I don't see why you would check BOTH m and > n's refcnt pointers when you should take for granted that if you are > copying something into n, then n surely isn't referencing anything else > because if it is, you shouldn't be copying anything into it unless you > free what was previously there first. perhaps a good place to KASSERT? :) > > > > > > > } else if (m->rp == NULL) { > > > > m->rp = n->rp; > > > > } else if (n->rp == NULL) { > > > > n->rp = m->rp; > > > > } else { > > > > mclrefcnt_free(n->rp); > > > > n->rp = m->rp; > > > > } > > > > atomic_inc(m->rp.mextr_refcnt); > > > > > > > > > > > > /* freeing m */ > > > > > > > > /* x must get the value I reduced it to */ > > > > x = atomic_dec_and_fetch(m->rp.mextr_refcnt); > > > > if (x == 0) { > > > > /* do extfree callback */ > > > > } else { > > > > m->rp = NULL; > > > > This is incorrect, the code should be: > > m->rp = mclrefcnt_alloc(); > > > > that will ensure that we don't have mbufs where the m->rp isn't > > initialized to a structure, it also allows us to simplify the copy > > code above. > > > > the mbufs startup code will have to pre-assign them all refcount > > structures. > > Not all mbufs should have an assigned mextrefcnt, because not all > mbufs refer to external storage, so it would be a waste of memory. > When you free an mbuf, you'll also have to be under splimp() most > likely (unless we find those atomic queue manip. constructs). The reason > is that you'll be placing the mbuf back on the list, which requires > blocking against interrupts, and also against other CPUs in the SMP case > (unless we decide to split the list in the future). So what you do in > this case should be more like this: > > struct mextrefcnt *our_ref = mbuf_to_be_freed->m_ext->mext_refcnt; > > int s = splimp(); > our_ref->counter--; > if (our_ref->counter == 0) { > /* call (mbuf_to_be_freed->m_ext->ext_free)(blah, blah) */ > /* free mextrefcnt structure (our_ref) to the mextrefcnt freelist */ > } > mbuf_to_be_freed->m_ext->m_ext_refcnt = NULL; > /* actually, all of the mbuf's m_ext should be zero'd, but the next > allocation should take care of that anyway, so we can skip it here and do > it during the allocating of the mbuf. */ > free_the_mbuf(mbuf_to_be_freed); > > Clearly, when you are freeing the mbuf, you have to splimp(), but this is > normal for now. The idea is though that you _don't_ have to splimp() when > you just increment the ref count, unless it's the first incrementation. > This is the reason, as I understand it, that your idea makes sense (as > opposed to my linked list idea which always needed to be splimp()ed). > > Naturally, MEXTADD() will also have to be modified to not only setup the > mbuf for the ext_buf type (e.g. setup ext_free, and other m_ext fields) > but to also splimp() and allocate the mextrefcnt structure and increment > it by one. This is expected. Yes, the problem in the first proposal was that the refcnt allocation could be delayed until m_copym time, that's no good. As long as you make it so that when a m_ext mbuf is created it always has a refcount struct associated with it, then you don't need to always have a refcnt struct with each mbuf as the creator has exclusive access and you'll always "be" ok, in face it ought to speed up the code a bit not to have to worry about freeing/allocating whenever doing shallow copies. > > The race condition is outlined above and I think the solution ought > > to work. > > > > The refcount list certainly does not need to remain global, there's > > nothing wrong with per-cpu pools of them and when your own pool is > > exhausted you can try to lock against another CPU's pool and steal > > structures. > > Well, now that I've thought about it more extensively, this does make > sense, but only if you consider that just because an mbuf was originally > allocated from CPU#1's freelist, doesn't mean that it necessarily has to > be freed to CPU#1's freelist, such that it may end up on any of the CPU's > freelists eventually; same goes for the mextrefcnt list elements. Actually, remeber, we are locking against ourselves for interrupts, there's no reason why a cpu couldn't free a mbuf back into another mbuf's pool, if we implement decent processor binding (affinity (sp?)) of processes then you're most likely to allocate from your own pool and free to it keeping your locking to yourself, but you can still lock against other CPUs to free into thier pools. :) The per cpu pool is a Dynix thing, the freeing back into another CPU's pool is something pioneered by the people doing Horde. We'd possibly help our cache by doing this, but it would have to be profiled heavily to figure it all out. > > The CPUs will have to lock thier own queues against themselves for > > protection against interrupts, doing so is cheap, when we have a > > shortage we can take the performance hit to lock against another > > CPU in order to steal refcount structures. > > Agreed. But if we do go with this, we'll REALLY be in trouble when it > comes to freeing physical memory, especially if you consider that each > CPU's freelists can now contain mbufs from pretty much anywhere. In other > words, I can now have 16 mbufs making up a page spread out across 4 > different CPU's free lists, and I would have to giant lock in order to > free them, or even track all of them at that (say I want to move them to > a less used list, etc.). Poul-Henning, do you see what I mean, given > discussions we had regarding this? If you want to do this you can free back into other CPU's pools, the locking is already established to protect from interrupts, it can also function to lock against other CPUs. > > And if that code to do queue/dequeue wasn't just a figment of my > > imagination we may not need to lock at all. > > I think Mike blurted out that there are some atomic queue > manipulation constructs, although I am personally not familiar with them > (yet). If we do find them and they do apply, we will see a dramatic > advantage not only in the SMP area, but overall. It almost seems to good > to be applicable. :-) I swear i've seen it on paper somewhere, I'll probably be in my lab tonight tearing things up looking for the stuff. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 16:52: 4 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.wanlogistics.net (mail.wanlogistics.net [63.209.114.3]) by hub.freebsd.org (Postfix) with ESMTP id 245CD37BDAC for ; Wed, 19 Jul 2000 16:52:01 -0700 (PDT) (envelope-from chuck@mail.wanlogistics.net) Received: (from chuck@localhost) by mail.wanlogistics.net (8.9.3/8.9.3) id TAA96891 for freebsd-net@freebsd.org; Wed, 19 Jul 2000 19:51:45 -0400 (EDT) (envelope-from chuck) Message-Id: <200007192351.TAA96891@mail.wanlogistics.net> Subject: Re: "ifconfig" == "ifconfig -a" In-Reply-To: from Paul Herman at "Jul 19, 2000 04:35:18 pm" To: freebsd-net@freebsd.org Date: Wed, 19 Jul 2000 19:51:45 -0400 (EDT) From: bv@wjv.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Reply to: bv@wjv.com X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > On Wed, 19 Jul 2000, Ben Smithurst wrote: > > > > One uses flags, or sees documentation. :-) > > Actually, I don't think I'll mention the -r flag at all. The route(8) > > manpage isn't the right place to document netstat(1)'s flags, IMO. I > > think I'll just say "... please use the netstat(1) command". On second > > thoughts, I think "For that functionality, the netstat(1) command should > > be used" would be better. > Hmmm... what led to this idea was: people who use "route print" to > print the routing table in "other" OSes need to be informed how to > print the routing table under FreeBSD. If that's really true, some > how I have a feeling they would already know about "netstat -r" (which > AFAIK is pretty much ubiquitous among Unicies.) > Is it just me, who thinks this? I think retaining the classic Unix behaviour with no arguments giving useage options is the way it should be. That keeps the consitancy. Changing the standard design to match other OSes implementation is a step in the wrong direction. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 16:56:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id 58DD337B84B for ; Wed, 19 Jul 2000 16:56:20 -0700 (PDT) (envelope-from ras@e-gerbil.net) Received: from localhost (ras@localhost) by overlord.e-gerbil.net (8.9.3/8.9.3) with ESMTP id TAA65942; Wed, 19 Jul 2000 19:56:05 -0400 (EDT) (envelope-from ras@e-gerbil.net) X-Authentication-Warning: overlord.e-gerbil.net: ras owned process doing -bs Date: Wed, 19 Jul 2000 19:56:05 -0400 (EDT) From: "Richard A. Steenbergen" To: bv@wjv.com Cc: freebsd-net@freebsd.org Subject: Re: "ifconfig" == "ifconfig -a" In-Reply-To: <200007192351.TAA96891@mail.wanlogistics.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 19 Jul 2000 bv@wjv.com wrote: > > Is it just me, who thinks this? > > I think retaining the classic Unix behaviour with no arguments giving useage > options is the way it should be. That keeps the consitancy. > > Changing the standard design to match other OSes implementation is a > step in the wrong direction. I don't think the arguement is to make it "like linux", I think the arguement is that "classic unix" behavior is wrong and inconsistant with a well thought out design. :P -- Richard A Steenbergen http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 17:12:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id BD6DE37B72E for ; Wed, 19 Jul 2000 17:12:37 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id CAA52115; Thu, 20 Jul 2000 02:13:47 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200007200013.CAA52115@info.iet.unipi.it> Subject: Re: AltQ/dummynet & IP accounting.. In-Reply-To: <39762B54.BE0CDACB@mercuryfilmworks.com> from Derrick MacPherson at "Jul 19, 2000 03:27:33 pm" To: Derrick MacPherson Date: Thu, 20 Jul 2000 02:13:47 +0200 (CEST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > What seems to be the better of the two - AltQ or dummynet? Is one better > for certain jobs? the answer is likely yes, but rather than coming up wit a million different tasks why dont you decide/tell us what you want to do and then figure out which one (if not both) do the job. > Can I monitor (for stats gathering, see who is using our bandwidth, what > protocols/ports, what direction) 3 or more partial Class C's and is > there a 'sexy' way to do this, or do I end up with a number like 6 i would rather use ntop or trafshow or things like that. In ports/net, i think. cheers luigi > gazzilion, and I need to get a calculator, divide by the sum of the > square root of a parsec, inverse that number and I get a megabyte total > for 1 machine. > > (I have a machine that I will be putting between our router and the net > I am just looking for a way to NOT pay Bill Gates) > > -- > Derrick MacPherson > Mercury Filmworks > > > > > > 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 Wed Jul 19 18:22:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from snafu.adept.org (adsl-63-201-63-44.dsl.snfc21.pacbell.net [63.201.63.44]) by hub.freebsd.org (Postfix) with ESMTP id 8EFEE37B8FC; Wed, 19 Jul 2000 18:22:54 -0700 (PDT) (envelope-from mike@adept.org) Received: by snafu.adept.org (Postfix, from userid 1000) id EF5B39EE01; Wed, 19 Jul 2000 18:22:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by snafu.adept.org (Postfix) with ESMTP id E75B99B001; Wed, 19 Jul 2000 18:22:45 -0700 (PDT) Date: Wed, 19 Jul 2000 18:22:45 -0700 (PDT) From: Mike Hoskins To: Paul Herman Cc: Ben Smithurst , Matthew Hunt , freebsd-net@FreeBSD.ORG Subject: Re: "ifconfig" == "ifconfig -a" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 19 Jul 2000, Paul Herman wrote: > Hmmm... what led to this idea was: people who use "route print" to > print the routing table in "other" OSes need to be informed how to > print the routing table under FreeBSD. If that's really true, some > how I have a feeling they would already know about "netstat -r" (which > AFAIK is pretty much ubiquitous among Unicies.) > > Is it just me, who thinks this? That is true... netstat behaves the same way on NT/2k as well. -mrh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 18:44: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from web.mercuryfilmworks.com (web.mercuryfilmworks.com [209.17.176.194]) by hub.freebsd.org (Postfix) with ESMTP id DC31837B61E for ; Wed, 19 Jul 2000 18:44:00 -0700 (PDT) (envelope-from derrick@mercuryfilmworks.com) Received: from localhost (derrick@localhost) by web.mercuryfilmworks.com (8.9.3/8.9.3) with ESMTP id SAA20828; Wed, 19 Jul 2000 18:45:48 -0700 X-Authentication-Warning: web.mercuryfilmworks.com: derrick owned process doing -bs Date: Wed, 19 Jul 2000 18:45:47 -0700 (PDT) From: Derrick MacPherson To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: AltQ/dummynet & IP accounting.. In-Reply-To: <200007200013.CAA52115@info.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > What seems to be the better of the two - AltQ or dummynet? Is one better > > for certain jobs? > > the answer is likely yes, but rather than coming up wit a million > different tasks why dont you decide/tell us what you want to do > and then figure out which one (if not both) do the job. There are 2 things: 1) I look after the Unix (Irix) boxes at a education facility that has about 400 machines running on 5 class C's, and a 10 meg connection to the net. There traffic has jumped from about 200 gigs a month to about 900 gigs a month, and I told them they should get a traffic shaping tool. The Cisco product to this costs about 15 000$, or so I am told, that has yet to be confirmed, so it seems like running all the traffic through a box is the way to go. My unix background is mainly Irix, a little bit of Linux, some Sun, HP and I actually did an install of FreeBSD4 about a month ago. I would like to set them up with a way to say this group of machines (called A), and this protocols, either get 1st priority or X megs (not sure if I? get an option on that), these machines (B) and these protocols get 2nd or 70% of X megs, and anything outside that (which I hope is all the streaming audio and napster traffic) gets very little. 2) Where I work: we have a wireless 4.5 meg connection to the net, the boss wants to know how much surfing/streaming audio/napster traffic we are doing, and from which machines. He may want to traffic shape, that is why I mentioned both on the same box. There is 80 users, on 3 class c's, and we are also providing network access for a couple other small (less than 5 machines) clients in the building, and need to monitor their traffic ona monthly basis, to bill back at X per gig. (We will control their bandwidth via the router) > i would rather use ntop or trafshow or things like that. In ports/net, i > think. I will look into trafshow, I have not seen that before. ntop I have and like. Thank you Luigi Derrick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 18:48:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from snafu.adept.org (adsl-63-201-63-44.dsl.snfc21.pacbell.net [63.201.63.44]) by hub.freebsd.org (Postfix) with ESMTP id D937C37B61E for ; Wed, 19 Jul 2000 18:48:43 -0700 (PDT) (envelope-from mike@adept.org) Received: by snafu.adept.org (Postfix, from userid 1000) id 6F4A19EE01; Wed, 19 Jul 2000 18:48:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by snafu.adept.org (Postfix) with ESMTP id 6B4289B001; Wed, 19 Jul 2000 18:48:38 -0700 (PDT) Date: Wed, 19 Jul 2000 18:48:38 -0700 (PDT) From: Mike Hoskins To: Nick Rogness Cc: Scott Augustus , freebsd-net@freebsd.org Subject: Re: named errors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 19 Jul 2000, Nick Rogness wrote: > I would recommend buying OReilly's DNS/Bind rev 3 book. It is a > great reference and should answer most of your DNS questions. Agreed, a great read, but I'd also suggest the online documentation... That'd be the 'More About BIND' section at the bottom of http://www.isc.org/products/BIND. 'Other BIND and DNS Resources' is especially useful... I was a little disappointed to not see the BOG right up front. I think I'll start mirroring it again. -mrh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 19: 2:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from keep.scn.ru (SCN-SibInet.sibinet.ru [213.24.217.138]) by hub.freebsd.org (Postfix) with ESMTP id CDA0B37B5B9 for ; Wed, 19 Jul 2000 19:02:31 -0700 (PDT) (envelope-from smith@scn.ru) Received: from scn.ru (quick.sc.ten [10.0.0.7]) by keep.scn.ru (8.9.3/8.9.3) with ESMTP id KAA45354; Thu, 20 Jul 2000 10:02:04 +0800 (KRAST) Message-ID: <39769534.A86F547@scn.ru> Date: Thu, 20 Jul 2000 09:59:16 +0400 From: "Vladimir N. Kovalev" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Julian Elischer Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG Subject: Re: FWD: TAU-PCI-E1 and NETGRAPH Frame Relay References: <200007192303.QAA68792@bubba.whistle.com> <39763ADB.2781E494@elischer.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer wrote: > > Jul 18 09:35:48 tau /kernel: nglmi: unexpected message type(0x0) > > Jul 18 09:35:49 tau /kernel: nglmi: error at location 3 > > Jul 18 09:35:49 tau /kernel: nglmi: packet data: 03 08 00>75 95 01 01 00 03 02 > > 0b 00 > > Jul 18 09:35:49 tau /kernel: nglmi: no response from exchange > > Jul 18 09:35:59 tau /kernel: nglmi: unexpected message type(0x0) > > Jul 18 09:35:59 tau /kernel: nglmi: error at location 3 > > Jul 18 09:35:59 tau /kernel: nglmi: packet data: 03 08 00>75 95 01 01 00 03 02 > > 0c 00 > > > > Anybody know that does this message mean ? > > Or there I make mistake ? > > This is a status INQUIRY packet (type 75). > We are expemcting an status RESPONSE (type 7D) > WE should be sending inquiry packets, not the other end > This looks like something was in loopback mode. > (OR the other end is also running in 'DTE' mode.) Unfortunetly, it's true. The other end of link is running on DTE mode. And this equipment does't support DCE mode. Can I turn the UNIX end into DCE mode ? Or may be Frame Relay will work without LMI at all ? Best regards Vladimir N. Kovalev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 20:56:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from keep.scn.ru (SCN-SibInet.sibinet.ru [213.24.217.138]) by hub.freebsd.org (Postfix) with ESMTP id A9C5D37B989 for ; Wed, 19 Jul 2000 20:56:29 -0700 (PDT) (envelope-from smith@scn.ru) Received: from scn.ru (quick.sc.ten [10.0.0.7]) by keep.scn.ru (8.9.3/8.9.3) with ESMTP id LAA50481; Thu, 20 Jul 2000 11:55:52 +0800 (KRAST) Message-ID: <3976AFE0.E28A7583@scn.ru> Date: Thu, 20 Jul 2000 11:53:04 +0400 From: "Vladimir N. Kovalev" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Julian Elischer Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG Subject: Re: FWD: TAU-PCI-E1 and NETGRAPH Frame Relay - DONE ! References: <200007192303.QAA68792@bubba.whistle.com> <39763ADB.2781E494@elischer.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello ! Julian Elischer wrote: > > Jul 18 09:35:48 tau /kernel: nglmi: unexpected message type(0x0) > > Jul 18 09:35:49 tau /kernel: nglmi: error at location 3 > > Jul 18 09:35:49 tau /kernel: nglmi: packet data: 03 08 00>75 95 01 01 00 03 02 > > 0b 00 > > Jul 18 09:35:49 tau /kernel: nglmi: no response from exchange > > Jul 18 09:35:59 tau /kernel: nglmi: unexpected message type(0x0) > > Jul 18 09:35:59 tau /kernel: nglmi: error at location 3 > > Jul 18 09:35:59 tau /kernel: nglmi: packet data: 03 08 00>75 95 01 01 00 03 02 > > 0c 00 > > > > Anybody know that does this message mean ? > > Or there I make mistake ? > > This is a status INQUIRY packet (type 75). > We are expemcting an status RESPONSE (type 7D) > WE should be sending inquiry packets, not the other end > This looks like something was in loopback mode. > (OR the other end is also running in 'DTE' mode.) The Frame Relay link was established without LMI. Many thanks ! Best regards Vladimir N. Kovalev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 23:20:25 2000 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 C887637B7E9 for ; Wed, 19 Jul 2000 23:20:20 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA67100; Wed, 19 Jul 2000 23:19:37 -0700 (PDT) Date: Wed, 19 Jul 2000 23:19:36 -0700 (PDT) From: Julian Elischer To: "Vladimir N. Kovalev" Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG Subject: Re: FWD: TAU-PCI-E1 and NETGRAPH Frame Relay In-Reply-To: <39769534.A86F547@scn.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > This is a status INQUIRY packet (type 75). > > We are expemcting an status RESPONSE (type 7D) > > WE should be sending inquiry packets, not the other end > > This looks like something was in loopback mode. > > (OR the other end is also running in 'DTE' mode.) > > Unfortunetly, it's true. The other end of link is running on DTE mode. > And this equipment does't support DCE mode. > Can I turn the UNIX end into DCE mode ? > Or may be Frame Relay will work without LMI at all ? > You can turn frame relay off on both ends and simply use 1/ Cisco-HDLC or 2/ Raw IP direct ovver the link, or 3/ PPP over the link. I have not written code to act as a local exchange... Though it would not be impossible to do so. what is at the other end? Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 19 23:48:20 2000 Delivered-To: freebsd-net@freebsd.org Received: from keep.scn.ru (SCN-SibInet.sibinet.ru [213.24.217.138]) by hub.freebsd.org (Postfix) with ESMTP id 536EC37BC6A for ; Wed, 19 Jul 2000 23:48:07 -0700 (PDT) (envelope-from smith@scn.ru) Received: from scn.ru (quick.sc.ten [10.0.0.7]) by keep.scn.ru (8.9.3/8.9.3) with ESMTP id OAA58632; Thu, 20 Jul 2000 14:47:32 +0800 (KRAST) Message-ID: <3976D81D.18725882@scn.ru> Date: Thu, 20 Jul 2000 14:44:45 +0400 From: "Vladimir N. Kovalev" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Julian Elischer Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG Subject: Re: FWD: TAU-PCI-E1 and NETGRAPH Frame Relay References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer wrote: > > > > > > This is a status INQUIRY packet (type 75). > > > We are expemcting an status RESPONSE (type 7D) > > > WE should be sending inquiry packets, not the other end > > > This looks like something was in loopback mode. > > > (OR the other end is also running in 'DTE' mode.) > > > > Unfortunetly, it's true. The other end of link is running on DTE mode. > > And this equipment does't support DCE mode. > > Can I turn the UNIX end into DCE mode ? > > Or may be Frame Relay will work without LMI at all ? > > > You can turn frame relay off on both ends and simply use > 1/ Cisco-HDLC > or > 2/ Raw IP direct ovver the link, > or > 3/ PPP over the link. > > I have not written code to act as a local exchange... > Though it would not be impossible to do so. > > what is at the other end? There is XSI-6 card in VDAS-300 shelf of IPTL System from RADWIZ Ltd at the other end. It has only Frame Relay. But link established without LMI. And I'm happy ! ;-) Best wishes Vladimir N. Kovalev > > > > Julian > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 20 2:16: 1 2000 Delivered-To: freebsd-net@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id E505437BE0E for ; Thu, 20 Jul 2000 02:15:57 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id KAA78167; Thu, 20 Jul 2000 10:15:53 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id JAA31039; Thu, 20 Jul 2000 09:18:51 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200007200818.JAA31039@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Slawek Zak Cc: freebsd-net@FreeBSD.org, brian@Awfulhak.org Subject: Re: tcpdump on tun0 strangeness In-Reply-To: Message from Slawek Zak of "20 Jul 2000 01:07:43 +0200." <878zux7m80.fsf@localhost.localnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Jul 2000 09:18:50 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org There's an outstanding PR on this (19377). I haven't gotten around to looking at it though :-( > I've found a strange bahaviour of tcpdump in 4.1-RC (and 4.0) when > listening on tun0 interface. When I specify the protocol to filter, > tcpdump shows only packets going out. Without the filter I see all the > packets. > > # tcpdump -i tun0 > > Shows all packets when pinging any remote host > > # tcpdump -i tun0 icmp > > Shows only packets going out. > > # tcpdump -i fxp0 icmp (Ethernet link) > > Works just fine too. > > Any ideas?? > -- > `When any government, or any church for that matter, undertakes to say to > its subjects, "This you may not read, this you must not see, this you are > forbidden to know," the end result is tyranny and oppression no matter how > holy the motives' -- Robert A Heinlein, "If this goes on --" > Suavek Zak / PGP: finger://zaks@prioris.mini.pw.edu.pl -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 20 7:10:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 58A4237B946 for ; Thu, 20 Jul 2000 07:10:22 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id QAA56271; Thu, 20 Jul 2000 16:11:25 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200007201411.QAA56271@info.iet.unipi.it> Subject: Re: AltQ/dummynet & IP accounting.. In-Reply-To: from Derrick MacPherson at "Jul 19, 2000 06:45:47 pm" To: Derrick MacPherson Date: Thu, 20 Jul 2000 16:11:25 +0200 (CEST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 1) I look after the Unix (Irix) boxes at a education > facility that has about 400 machines running on 5 class C's, and a 10 meg > connection to the net. There traffic has jumped from about 200 gigs a > month to about 900 gigs a month, and I told them they should get a traffic > shaping tool. The Cisco product to this costs about 15 000$, or so I am > told, that has yet to be confirmed, so it seems like running all the > traffic through a box is the way to go. My unix background is mainly Irix, for that, probably a picobsd-based bridge does the job fairly well. there is a floppy image at http://www.iet.unipi.it/~luigi/ip_dummynet/ which also has Weighted Fair Queueing enabled. > 2) Where I work: > we have a wireless 4.5 meg connection to the net, the boss wants to know > how much surfing/streaming audio/napster traffic we are doing, and from > which machines. He may want to traffic shape, that is why I mentioned both > on the same box. There is 80 users, on 3 class c's, and we are also > providing network access for a couple other small (less than 5 machines) > clients in the building, and need to monitor their traffic ona monthly > basis, to bill back at X per gig. (We will control their bandwidth via the > router) same as above plus ntop for monitoring (for this you will need a full install as ntop does not fit on a floppy image). cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 20 7:12:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from sugar.pharlap.com (sugar.pharlap.com [192.107.36.1]) by hub.freebsd.org (Postfix) with ESMTP id E6D1B37B946 for ; Thu, 20 Jul 2000 07:12:40 -0700 (PDT) (envelope-from clark@pharlap.com) Received: from clark ([192.107.36.171]) by sugar.pharlap.com (Post.Office MTA v3.5.2 release 221 ID# 0-56365U200L2S100V35) with SMTP id com for ; Thu, 20 Jul 2000 10:13:54 -0400 From: clark@pharlap.com (Clark Jarvis) Date: Thu, 20 Jul 2000 10:21:14 -0400 To: freebsd-net@FreeBSD.ORG In-Reply-To: <20000719225647.E75784@strontium.scientia.demon.co.uk> Subject: Re: "ifconfig" == "ifconfig -a" X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19zg/19zg Message-ID: <20000720141354258.AAA215@sugar.pharlap.com@clark> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In <20000719225647.E75784@strontium.scientia.demon.co.uk>, on 07/19/00 at 10:56 PM, Ben Smithurst said: >Mike Nowlin wrote: >> Just because Linux does something in a particular way doesn't mean >> that FBSD should. >I'm not suggesting we should! I'm just suggesting adding a note to the >manual page telling people where to look if that's the functionality they >want. "route" may be the logical command for some people to print out the >entire routing table, and the manpage at the moment doesn't even hint on >how to do that as far as I can see. Consider "arp -a". Seems to be a reasonable parallel. -- Clark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 20 8: 3:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from web.mercuryfilmworks.com (web.mercuryfilmworks.com [209.17.176.194]) by hub.freebsd.org (Postfix) with ESMTP id 0D13E37B821 for ; Thu, 20 Jul 2000 08:03:05 -0700 (PDT) (envelope-from derrick@mercuryfilmworks.com) Received: from localhost (derrick@localhost) by web.mercuryfilmworks.com (8.9.3/8.9.3) with ESMTP id IAA01116; Thu, 20 Jul 2000 08:04:23 -0700 X-Authentication-Warning: web.mercuryfilmworks.com: derrick owned process doing -bs Date: Thu, 20 Jul 2000 08:04:23 -0700 (PDT) From: Derrick MacPherson To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: AltQ/dummynet & IP accounting.. In-Reply-To: <200007201411.QAA56271@info.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > for that, probably a picobsd-based bridge does the job fairly well. > there is a floppy image at http://www.iet.unipi.it/~luigi/ip_dummynet/ > which also has Weighted Fair Queueing enabled. How would this handle a 10 meg connection and +400 machines? Is it going to bog down significantly? wWhat about if I add full firewalling capabalities? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 20 8:21:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 4DF0B37BCEF for ; Thu, 20 Jul 2000 08:21:27 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id RAA56588; Thu, 20 Jul 2000 17:22:33 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200007201522.RAA56588@info.iet.unipi.it> Subject: Re: AltQ/dummynet & IP accounting.. In-Reply-To: from Derrick MacPherson at "Jul 20, 2000 08:04:23 am" To: Derrick MacPherson Date: Thu, 20 Jul 2000 17:22:33 +0200 (CEST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > for that, probably a picobsd-based bridge does the job fairly well. > > there is a floppy image at http://www.iet.unipi.it/~luigi/ip_dummynet/ > > which also has Weighted Fair Queueing enabled. > > How would this handle a 10 meg connection and +400 machines? Is it going > to bog down significantly? wWhat about if I add full firewalling > capabalities? it all depends on the CPU and cards you have. We have one such bridge with a 350 or 400 MHz CPU, Intel ("fxp") cards on a 100Mbit net and it does not seem to harm too much. At 10Mbit/s i am pretty sure you will only notice little more than the store&forward latency introduced by the bridge. Of course the more rules you have (for firewalling) the slower the system is, but typically if you use dynamic rules, after the initial match you have O(1) cost per packet, and the WF2Q+ algorithm has O(log N) cost where N is the number of flows. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 20 14:31:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from herbelot.dyndns.org (r148m178.cybercable.tm.fr [195.132.148.178]) by hub.freebsd.org (Postfix) with ESMTP id 3634E37B65D; Thu, 20 Jul 2000 14:31:37 -0700 (PDT) (envelope-from herbelot@cybercable.fr) Received: from cybercable.fr (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id XAA50337; Thu, 20 Jul 2000 23:41:54 +0200 (CEST) (envelope-from herbelot@cybercable.fr) Message-ID: <39776E37.BE623003@cybercable.fr> Date: Thu, 20 Jul 2000 23:25:11 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian Somers , net@freebsd.org Cc: stable@freebsd.org Subject: What is wrong in my PPP over UDP config ? (long) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Brian, I'm trying to build on my work LAN a PPP over UDP tunnel (to link two NAT-hidden networks over a public-IP LAN). The problem I see is that the route to the remote network added via the ppp "add" command seems to use the wrong network interface : ed in the following example, instead of the "tun" interface. Thus, I can't ping a machine on the remote "NAT-ed" network without patching the routing table. I must be doing something wrong, but after RTFMing a bit, I can't see what. (both machines use mostly recent FreeBSD versions : 3.5-Stable from the end of June and a 4.0-Stable from the beginning of July - the machines I use at work are built with sourcesfrom the beginning of this month) TIA TfH My configuration follows : I've been following the example in the man page : * on both machines, I've changed the /etc/services file * on the "server", I've changed inetd.conf to add two lines : ------------------------------------ ppp-in stream tcp nowait root /usr/sbin/ppp ppp -direct ppp-in ppp-in dgram udp wait root /usr/sbin/ppp ppp -direct ppp-in ------------------------------------ * on the "server", I've also changed the stock ppp.conf : ------------------------------------ # set timeout 120 ... # add default HISADDR ... ppp-in: set timeout 0 set ifaddr 10.0.4.1 10.0.4.2 add 10.0.1.0/24 10.0.4.2 ------------------------------------ * then I've restarted inetd tfh# killall -INT inetd tfh# uname -a FreeBSD tfh.herbelot.nom 3.5-STABLE FreeBSD 3.5-STABLE #1: Wed Jun 21 08:12:49 CEST 2000 thierry.herbelot@tfh.herbelot.nom:/usr/src/sys/compile/TFH_34 i386 tfh# netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.3 UGSc 4 155 ed2 127.0.0.1 127.0.0.1 UH 0 152 lo0 192.168.1 link#2 UC 0 0 ed2 192.168.1.1 0:40:5:65:66:13 UHLW 4 2300730 lo0 192.168.1.2 0:4f:49:8:17:72 UHLW 7 3156731 ed2 461 192.168.1.3 52:54:4c:1b:90:1b UHLW 4 192099 ed2 1056 tfh# * on the client, I've modified the stock ppp.conf : ------------------------------------ # set timeout 120 ... # add default HISADDR ... tfh: set escape 0xff set device tfh:ppp-in/tcp # I've also tested with udp transport set dial set log Phase Chat Connect hdlc LCP IPCP CCP tun set ifaddr 10.0.4.2 10.0.4.1 add 10.0.2.0/24 10.0.4.1 ------------------------------------ * on the client, I lauch the ppp connection : multi# netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.3 UGSc 13 0 ed0 127.0.0.1 127.0.0.1 UH 0 62 lo0 192.168.1 link#1 UC 0 0 ed0 => 192.168.1.1 0:40:5:65:66:13 UHLW 3 356324 ed0 852 192.168.1.3 52:54:4c:1b:90:1b UHLW 14 27906 ed0 257 192.168.1.255 ff:ff:ff:ff:ff:ff UHLWb 0 5 ed0 multi# ppp -background tfh Working in background mode Using interface: tun0 PPP enabled multi# netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.3 UGSc 13 0 ed0 10.0.2/24 10.0.4.1 UGSc 0 0 ed0 ^^^^ 10.0.4.1 10.0.4.2 UH 0 0 tun0 127.0.0.1 127.0.0.1 UH 0 62 lo0 192.168.1 link#1 UC 0 0 ed0 => 192.168.1.1 0:40:5:65:66:13 UHLW 4 356362 ed0 764 192.168.1.3 52:54:4c:1b:90:1b UHLW 14 27906 ed0 169 192.168.1.255 ff:ff:ff:ff:ff:ff UHLWb 0 5 ed0 multi# --- at this moment I can't ping machines on the 10.0.2 network --- (I can ping 10.0.4.1, though) --- if I re-create manually the remote route, all is well : multi# route delete -net 10.0.2 delete net 10.0.2 multi# route add -net 10.0.2 10.0.4.1 add net 10.0.2: gateway 10.0.4.1 multi# netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.3 UGSc 12 0 ed0 10.0.2/24 10.0.4.1 UGSc 0 0 tun0 ^^^^ 10.0.4.1 10.0.4.2 UH 1 0 tun0 127.0.0.1 127.0.0.1 UH 0 62 lo0 192.168.1 link#1 UC 0 0 ed0 => 192.168.1.1 0:40:5:65:66:13 UHLW 5 356415 ed0 259 192.168.1.3 52:54:4c:1b:90:1b UHLW 14 27907 ed0 864 192.168.1.255 ff:ff:ff:ff:ff:ff UHLWb 0 5 ed0 multi# multi# tcpdump -i tun0 tcpdump: listening on tun0 23:07:46.527098 10.0.4.2 > 10.0.2.1: icmp: echo request 23:07:47.528903 10.0.4.2 > 10.0.2.1: icmp: echo request 23:07:48.529749 10.0.4.2 > 10.0.2.1: icmp: echo request 23:07:49.530623 10.0.4.2 > 10.0.2.1: icmp: echo request 23:07:50.531443 10.0.4.2 > 10.0.2.1: icmp: echo request 23:07:51.532280 10.0.4.2 > 10.0.2.1: icmp: echo request (in another xterm) multi% ping 10.0.2.1 PING 10.0.2.1 (10.0.2.1): 56 data bytes ^C --- 10.0.2.1 ping statistics --- 6 packets multi% uname -a FreeBSD multi.herbelot.nom 4.0-STABLE FreeBSD 4.0-STABLE #3: Sun Jul 2 23:03:56 CEST 2000 thierry.herbelot@multi.herbelot.nom: /files3/src/sys/compile/multi i386 multi% transmitted, 0 packets received, 100% packet loss multi% -- Thierry Herbelot ASCII RIBBON CAMPAIGN /"\ AGAINST HTML MAIL & NEWS \ / PAS DE HTML DANS X LES COURRIELS / \ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 21 10:28: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from prioris.mini.pw.edu.pl (prioris.mini.pw.edu.pl [148.81.80.7]) by hub.freebsd.org (Postfix) with ESMTP id 10AC737B9C6 for ; Fri, 21 Jul 2000 10:28:02 -0700 (PDT) (envelope-from zaks@prioris.mini.pw.edu.pl) Received: by prioris.mini.pw.edu.pl (Postfix, from userid 501) id C9B6E7CF08; Fri, 21 Jul 2000 19:27:14 +0200 (CEST) Date: Fri, 21 Jul 2000 19:27:14 +0200 From: Slawek Zak To: freebsd-net@freebsd.org Subject: "nd6_lookup: failed" after upgrade to 4.1-RC Message-ID: <20000721192714.A75927@prioris.mini.pw.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a tunnel v6 over v4. When I try to connect any host using ipv6 I a flooded with messages saying: pf39 nd6_lookup: failed to add route for a \ neighbor(3ffe:8010:0007:0002::0001), errno=17 When I manualy delete the route to 3ffe:8010:0007:0002::0001 I get: pf39 nd6_lookup: failed to lookup \ 3ffe:8010:0007:0002::0001 (if = gif0) In both cases I can communicate just fine, only the syslog hurts. # netstat -rn Internet6: Destination Gateway Flags [....] 3ffe:8010:7:2::1 3ffe:8010:7:2::2 UHL gif0 3ffe:8010:7:2::2 ::1 UH lo0 Relevant part of rc.conf: ## IPv6 ifconfig_gif0="inet6 3ffe:8010:7:2::2 3ffe:8010:7:2::1 prefixlen 126" ipv6_enable=YES ipv6_network_interfaces="auto" ipv6_static_routes="gif0" ipv6_route_gif0="default 3ffe:8010:7:2::1" ipv6_gateway_enable=NO ipv6_router_enable=YES gif_interfaces="gif0" gifconfig_gif0="213.25.209.39 193.219.28.246" It all worked with 4.0-STABLE. Thanks for any help. /S To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 21 13:47:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from postal.linkfast.net (postal.linkfast.net [208.160.105.2]) by hub.freebsd.org (Postfix) with ESMTP id 3799E37BF1A for ; Fri, 21 Jul 2000 13:47:44 -0700 (PDT) (envelope-from grasshacker@linkfast.net) Received: from leviathan (gh.ws.linkfast.net [208.160.105.41]) by postal.linkfast.net (Postfix) with SMTP id EB3D19B43; Fri, 21 Jul 2000 15:47:38 -0500 (CDT) Message-ID: <008b01bff354$ea620cc0$2969a0d0@leviathan> From: "gh" To: "Steve Shah" Cc: References: <20000718143843.A25290@clickarray.com> <200007182222.AAA14545@guppy.evolunet.com> <20000718161229.A96043@wopr.caltech.edu> <20000718165318.A25750@clickarray.com> Subject: Re: "ifconfig" == "ifconfig -a" Date: Fri, 21 Jul 2000 15:47:42 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > You're right. OTOH, it's just handy. =) And as I mentioned before, > for the many people in the Linux community trying FreeBSD, little > things like this make it feel more warm and fuzzy. Heh, this caused me to ponder the many things Linux distributors have done to make linux distributions feel ``warm and fuzzy''. I immediately screamed. Although convenience is nice, we must be careful to avoid stupidity. I am neither for, nor against this movement. Long live FreeBSD! gh > > Just a thought... > > -Steve > (who has finally kicked the habit of typing "route" to see the > routing table) > > -- > ___________________________________________________________________________ > Steve Shah (sshah@clickarray.com) | Developer/Systems Administrator/Author > http://www.clickarray.com | Voice: 408.772.8202 (e-mail preferred) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Beating code into submission, one OS at a time... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 21 13:49:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from postal.linkfast.net (postal.linkfast.net [208.160.105.2]) by hub.freebsd.org (Postfix) with ESMTP id B254B37C0E3 for ; Fri, 21 Jul 2000 13:49:12 -0700 (PDT) (envelope-from grasshacker@linkfast.net) Received: from leviathan (gh.ws.linkfast.net [208.160.105.41]) by postal.linkfast.net (Postfix) with SMTP id A005D9B0C; Fri, 21 Jul 2000 15:49:08 -0500 (CDT) Message-ID: <009a01bff355$200d1040$2969a0d0@leviathan> From: "gh" To: "Archie Cobbs" Cc: References: <200007182353.QAA61412@bubba.whistle.com> Subject: Re: "ifconfig" == "ifconfig -a" Date: Fri, 21 Jul 2000 15:49:12 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Could one not just alias `route print` to the correct mutation of `netstat`? gh > Renaud Waldura writes: > > I hate code/functionnality duplication as much as the next guy, but having to > > call a command totally unrelated to "route" to display the routing table (ie. netstat) > > has always struck me as a gratuitous twist. > > > > I cast my vote for a "route print". > > Try "route -dvn flush". > > This prints all the routes, but you can see how ugly it is. > It would take a lot of code duplication to make it look as > nice as netstat does I think. > > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 22 7: 4:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.bezeqint.net (mail-a.bezeqint.net [192.115.106.23]) by hub.freebsd.org (Postfix) with ESMTP id 0B88637B97B for ; Sat, 22 Jul 2000 07:04:14 -0700 (PDT) (envelope-from nimrodm@bezeqint.net) Received: from bsd.net.il ([212.179.182.125]) by mail.bezeqint.net (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with ESMTP id <0FY300FOXR0Q3Q@mail.bezeqint.net> for freebsd-net@FreeBSD.org; Sat, 22 Jul 2000 17:02:55 +0300 (IDT) Received: (from nimrodm@localhost) by bsd.net.il (8.9.3/8.9.3) id QAA01168 for freebsd-net@FreeBSD.org; Sat, 22 Jul 2000 16:59:29 +0300 (IDT envelope-from nimrodm) Date: Sat, 22 Jul 2000 16:59:29 +0300 From: Nimrod Mesika Subject: rfc1323 timestamps To: freebsd-net@FreeBSD.org Reply-To: nimrodm@email.com Message-id: <20000722165929.A1060@localhost.bsd.net.il> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline Mail-Followup-To: freebsd-net@FreeBSD.org User-Agent: Mutt/1.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following behavior has been observed while talking to a Linux machine (timestamps enabled, tcpdump output modified for easier reading): 21.66 bsd > linux: ack 1 win 17376 ^ ts1 sent by bsd 22.05 linux > bsd: 1:1449(1448) ack 1 win 32120 ^ts1 echoed by linux 22.14 bsd > linux: ack 1449 win 17376 ^ ts2 sent by bsd 22.23 linux > bsd: 1449:2897(1448) ack 1 win 32120 ^ ts1 echoed by linux AGAIN ... For each ack+timestamp sent by FreeBSD, Linux sends two data packets (i.e., slow start) - both echoing back the same timestamp. 1. Is this standard behavior? 2. Will FreeBSD behave in the same way? (couldn't test as most BSD machines have rfc1323 timestamps turned off). -- Nimrod. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 22 7:49:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from mout2.silyn-tek.de (mout2.silyn-tek.de [194.25.165.70]) by hub.freebsd.org (Postfix) with ESMTP id 9573A37B52C for ; Sat, 22 Jul 2000 07:49:14 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from [192.168.32.33] (helo=mx1.silyn-tek.de) by mout2.silyn-tek.de with esmtp (Exim 3.13 #1) id 13G0aS-0007SP-00; Sat, 22 Jul 2000 16:49:08 +0200 Received: from p3e9c1151.dip0.t-ipconnect.de ([62.156.17.81] helo=neutron.cichlids.com) by mx1.silyn-tek.de with esmtp (Exim 3.13 #1) id 13G0aN-0003cG-00; Sat, 22 Jul 2000 16:49:03 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 10119AB91; Sat, 22 Jul 2000 16:50:53 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id AD0A514BAE; Sat, 22 Jul 2000 16:49:12 +0200 (CEST) Date: Sat, 22 Jul 2000 16:49:12 +0200 To: nimrodm@email.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: rfc1323 timestamps Message-ID: <20000722164912.A15678@cichlids.cichlids.com> References: <20000722165929.A1060@localhost.bsd.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000722165929.A1060@localhost.bsd.net.il>; from nimrodm@bezeqint.net on Sat, Jul 22, 2000 at 04:59:29PM +0300 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. From: alex@big.endian.de (Alexander Langer) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thus spake Nimrod Mesika (nimrodm@bezeqint.net): > For each ack+timestamp sent by FreeBSD, Linux sends two data packets > (i.e., slow start) - both echoing back the same timestamp. That's probably a bug in Linux. BIG SURPRISE! Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message