Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 01 Apr 1997 19:07:32 -0500
From:      dennis <dennis@etinc.com>
To:        Brian Somers <brian@awfulhak.org>
Cc:        Developer <dev@fgate.flevel.co.uk>, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org
Subject:   Re: PPP Desperate for help! 
Message-ID:  <3.0.32.19970401190724.00b1d924@etinc.com>

next in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.32.19970401190724.00b1d924>