Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!news.alpha.net!news.mathworks.com!hookup!swrinde!howland.reston.ans.net!swiss.ans.net!jabba.cybernetics.net!usenet From: james@hermes.cybernetics.net (James Robinson) Newsgroups: comp.os.386bsd.questions Subject: Re: Does anyone have ppp working with 2.0? Date: 25 Jan 1995 22:56:05 GMT Organization: http://hermes.cybernetics.net Lines: 66 Message-ID: <3g6ku5$nvb@jabba.cybernetics.net> References: <paigenD2z3Iq.GDF@netcom.com> Reply-To: james@hermes.cybernetics.net NNTP-Posting-Host: hermes.cybernetics.net In article <paigenD2z3Iq.GDF@netcom.com>, paigen@netcom.com (David Paigen) writes: )I've seen a lot of people mention ppp problems with 2.0. ) )Does anyone have it working? Reliably? How about slip? )I need some sort of reliable dialup IP networking. ) )-david I have just gotten PPP up on two 2.0 machines, one as client, and the other as server. The server is sitting on a LAN, and the client dials up through a DEC 700 terminal server sitting on the LAN. My plan is to have one FreeBSD machine act as a PPP server for the modems attached to the DEC machine (if it can do it already -- don't flame me -- this is a bit of an academic exercise anyway). The client machine was a cinch. Install the sourcedist and make the one line change within if_ppp.c, then configure a kernel with a ppp device. The server was a bit tougher. Using the same source tree, I made a kernel that included "options GATEWAY" so that it could forward packets onto the LAN from its PPP children (and vicea versa as well). The server side PPP daemon was being started with "passive proxyarp" options. Now, it seemed to work once without a hitch. From another machine on the LAN, I could ping the PPP client without a problem. I then went around telling people in the office that we could all now work at home :-) So, they came in and I showed them the same setup. Only this time, under the watchful eye of tcpdump. I started to ping from the PPP client to a third party machine. I could see the ping packet make it out onto the network, but then the recipient machine would spit out an ARP request for the sender (the PPP client), and no one (especially the PPP server, who should have responded) replied to the ARP request :-( . So I'm now compiling a new kernel for the PPP server machine with the ARP_PROXYALL option, even having read the warning about burning the huose down et al. I glanced over the code in if_ether.c and it seems to be what I want -- "if I have a route to the IP in question that does not reside on the same interface, then answer the ARP request with my ethernet address that the ARP request came in on." Is this the real case here? I suppose that I will find out once the new kernel finishes cooking (damn 486-25SX). What is the proper config + pppd options for a PPP server on a LAN that should make its PPP children seem to be on that LAN ??? But to answer the orig question -- PPP clienting seems to be fine -- I just need a bit more educating on the PPP serving. Also -- glad to see that 2.0 allows the PPP line discipline over pseudo-terminals. I've disabled the check on the ioctl on my .1.1.5.1+ box (within kern/tty_pty.c), but haven't stressed it, as that we have a 2.0 machine better suited for the server job. #undef BABBLE -- : James Robinson : james@hermes.cybernetics.net ::See the screaming hot black :FreeBSD|XFree86 :The best things in life are Free:: steaming iridescent : Frank Zappa : Music is the best ::naughahyde python screaming : HTTP Server : http://hermes.cybernetics.net/ :: steam roller!