From owner-freebsd-hackers Tue Jan 16 23:10:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA21791 for hackers-outgoing; Tue, 16 Jan 1996 23:10:48 -0800 (PST) Received: from argus.flash.net (root@[206.149.24.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA21786 for ; Tue, 16 Jan 1996 23:10:43 -0800 (PST) Received: (from lists@localhost) by argus.flash.net (8.6.12/8.6.12) id BAA00899; Wed, 17 Jan 1996 01:09:15 -0600 From: mailing list account Message-Id: <199601170709.BAA00899@argus.flash.net> Subject: Re: Yet another PPP question To: tomg@fourthgen.com (Tom Greenwalt) Date: Wed, 17 Jan 1996 01:09:14 -0600 (CST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199601170252.UAA03134@fourthgen.com> from "Tom Greenwalt" at Jan 16, 96 08:52:23 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > When users dialin and connect using the Windows 95 PPP client I see the > following messages: > > Jan 16 20:38:22 fourthgen pppd[2916]: pppd 2.1.2 started by tomg, uid 1000 > Jan 16 20:38:22 fourthgen pppd[2916]: Connect: ppp1 <--> /dev/ttyd3 > Jan 16 20:38:25 fourthgen pppd[2916]: input: Unknown protocol (802b) received! > Jan 16 20:38:25 fourthgen pppd[2916]: input: Unknown protocol (803f) received! > Jan 16 20:38:28 fourthgen pppd[2916]: local IP address 204.246.82.8 > Jan 16 20:38:28 fourthgen pppd[2916]: remote IP address 204.246.82.11 > > What's the "Unknown protocol" mean? The connection doesn't seem very stable > and users have a tendency to be kicked off the system unexpectedly. If they > connect using TCPMAN there is no "Unknown protocol" messages and everything > seems to work ok. > Thanks. I think that this may have something to do with RFC 1877 [and something else too?] In a phone conversation with Steve Cobb, the author of RFC 1877, I was informed that this PPP IPCP is in every win95 shipped. Actually, I was meaning to ask if the ppp and pppd authors intended to implement dynamic dns server assignment as per RFC 1877 ??? For us ISP types, this would be a real plus, and FreeBSD could probably scoop most of the terminal server manufacturers on this one. please remember that most people getting on the internet today literally just had their kid show them where the power switch is. the less they have to configure, the better. How many millions of copies of windoze-95 are there now? here are the highlights.. not much to implement... btw: there are also two more options specified in this protocol for primary and secondary netbios name servers. i'm only inserting the relevant dns portions. -------------------------------------------------------------------- 1.1. Primary DNS Server Address Description This Configuration Option defines a method for negotiating with the remote peer the address of the primary DNS server to be used on the local end of the link. If local peer requests an invalid server address (which it will typically do intentionally) the remote peer specifies the address by NAKing this option, and returning the IP address of a valid DNS server. By default, no primary DNS address is provided. A summary of the Primary DNS Address Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Primary-DNS-Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Primary-DNS-Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 129 Length 6 1.3. Secondary DNS Server Address Description This Configuration Option defines a method for negotiating with the remote peer the address of the secondary DNS server to be used on the local end of the link. If local peer requests an invalid server address (which it will typically do intentionally) the remote peer specifies the address by NAKing this option, and returning the IP address of a valid DNS server. By default, no secondary DNS address is provided. A summary of the Secondary DNS Address Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Secondary-DNS-Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Secondary-DNS-Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 131 Length 6 Jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@argus.flash.net - FlashNet Communications - Ft. Worth, Texas