From owner-freebsd-current Tue Apr 1 16:12:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA16429 for current-outgoing; Tue, 1 Apr 1997 16:12:04 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA16335; Tue, 1 Apr 1997 16:10:38 -0800 (PST) Received: from dialup-usr11.etinc.com (dialup-usr11.etinc.com [204.141.95.132]) by etinc.com (8.8.3/8.6.9) with SMTP id TAA18745; Tue, 1 Apr 1997 19:14:36 -0500 (EST) Message-Id: <3.0.32.19970401190724.00b1d924@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 01 Apr 1997 19:07:32 -0500 To: Brian Somers From: dennis Subject: Re: PPP Desperate for help! Cc: Developer , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 08:49 PM 4/1/97 +0100, Brian Somers wrote: >> At 01:42 PM 4/1/97 +0100, Developer wrote: >> > >> > >> >On Tue, 1 Apr 1997, Andrzej Bialecki wrote: >> > >> >> On Tue, 1 Apr 1997, Developer wrote: >> >> >> >> > >> >> > We are really stuck trying to get the PPP user program (ppp) to >> connect to >> >> > our Perle 833 dial in server. We can connect using Windows NT fine but on >> >> > BSD ppp logs in and then data will travel in both directions (As I can >> see >> >> > the modem lights flash at both ends for both send/recieve) but no data >> >> > seems to actually get through as pings do not work. The packets from the >> >> > server to the user, but seem to be lost on the way back. >> >> >> >> Let me take a guess: maybe it's a known problem with tcp_extensions set to >> >> YES in /etc/sysconfig? Some broken TCP stacks don't like it, so the >> >> solution would be to turn it off. >> >> >> >> Andy >> > >> >We've tried this - no difference. Any more ideas please? >> >> Why not post a trace of the ppp negotiations? Perhaps there is a parameter >> conflict....are you getting to state IPCP_OPENED? If not, you cant pass >> traffic. >> >> Dennis > >I suspect you're way ahead of the problem. Has the original poster >tried "set openmode active" ? Without this, a client ppp will wait >for the server to initiate LCP. > >I think it may be frugal to make this the default for both client >*and* server. A lot of server implementations wait for the client >to start. Any comments ? It shouldnt make a difference, if implemented properly. There is no master-slave relationship in ppp...the ends are peers. Upon starting the interface it should send "n" configs, and then stop if no reply is received. When a config is received it starts again. The state machine allows for this nicely. One problem is when the electrical interface (UP) is not implemented (ie, receipt of DSR) properly. You should not be able to get into both ends being dormant if its done properly. Dennis