From cse.psu.edu!owner-9fans Sun Sep 1 15:56:33 1996 Received: from cse.psu.edu ([130.203.3.50]) by cannon.ecf.toronto.edu with SMTP id <2915>; Sun, 1 Sep 1996 15:56:30 -0400 Received: from localhost (majordom@localhost) by cse.psu.edu (8.7.5/8.7.3) with SMTP id PAA06339; Sun, 1 Sep 1996 15:50:48 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Sun, 1 Sep 1996 15:48:26 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.7.5/8.7.3) id PAA06293 for 9fans-outgoing; Sun, 1 Sep 1996 15:48:18 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.research.att.com (ns.research.att.com [192.20.225.4]) by cse.psu.edu (8.7.5/8.7.3) with SMTP id PAA06289 for <9fans@cse.psu.edu>; Sun, 1 Sep 1996 15:48:09 -0400 (EDT) Received: from research.research.att.com by ns; Sun Sep 1 15:47:06 EDT 1996 Received: from corona.research.att.com by research; Sun Sep 1 15:45:50 EDT 1996 Received: (from rsc@localhost) by corona.research.att.com (8.7.5/8.7) id PAA25228 for 9fans@cse.psu.edu; Sun, 1 Sep 1996 15:47:46 -0400 (EDT) Date: Sun, 1 Sep 1996 15:47:46 -0400 Message-Id: <199609011947.PAA25228@corona.research.att.com> From: Russ Cox To: 9fans@cse.psu.edu Subject: ppp fix for mtu Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk Status: RO I have (attempted to) fix ppp so that it respects the remote's wishes as far as MTU is concerned. There is a boddle on plan9.bell-labs.com in /cm/cs/who/rsc/ppp.rc and stip.rc. Use at your own risk. ppp.rc needs to be applied in /sys/src/cmd/ppp and also contains the changes that were in ppp.bod from forsyth. stip.rc needs to be applied in /sys/src/9/port and changes the setip message. An MTU parameter is added to the end, and if there is a '-' for any parameter, it is treated as if it wasn't there. Thus, setip 135.104.3.9 255.255.255.0 is the same as setip 135.104.3.9 255.255.255.0 - - This is used by ppp, which does: setip 135.104.3.9 255.255.255.0 - mtu and lets ipmuxctl figure out what the third parameter should be. Russ From 9fans@cse.psu.edu Sun Sep 15 22:32:35 EDT 1996 Article: 1806 of comp.os.plan9 Xref: info.ecf comp.os.plan9:1806 Newsgroups: comp.os.plan9 Path: info.ecf!utcsri!newsflash.concordia.ca!news.nstn.ca!ott.istar!istar.net!winternet.com!nntp04.primenet.com!nntp.primenet.com!cpk-news-hub1.bbnplanet.com!newsfeed.internetmci.com!news.mathworks.com!usenet.eel.ufl.edu!warwick!niss!bath.ac.uk!ccsis From: rsc@research.ATt.COM (Russ Cox) Subject: Re: ppp fix Approved: plan9mod@bath.ac.uk Reply-To: 9fans@cse.psu.edu Sender: ccsis@bath.ac.uk (Icarus Sparry) Organization: Plan 9 mailing list Message-ID: <199609020227.WAA00419@corona.research.att.com> Date: Mon, 2 Sep 1996 02:29:35 GMT Lines: 21 Status: RO i didn't play with pppserver.l because i don't serve ppp and couldn't test it. but if you change the ipconfig call to ipconfig(myipaddr, ipmask, 1500, 1); then that will at least put it back to the way it was before (assuming 1500 mtu). i'll have to look at the code a little more in depth to figure out if it even matters just yet. the standard ppp default is for 1500 mtu nuless specified by either side, and we're not specifying it. i suppose the client ppp software could request a lower mtu, but i bet it rarely happens. i'm not sure i see a good way to handle mtu in the server on a per-client basis. i think i'll try to figure that out after i get chap authentication working. russ