🚀 go-pugleaf

John Phillips (john@linux.demon.co.uk) wrote:
: I have observed that my pppd shuts down at a random interval from 
: about 3 minutes to about 20 minutes after traffic ceases.  This 
: is with Linux kernel 1.1.47 and pppd from ppp-2.1.2a.


: I have not seen anything in the pppd manpage to say why this can 
: happen, so can anyone comment on what I might be doing wrong?

: The /var/adm/messages log shows:

: Sep 24 09:06:21 linux pppd[1698]: remote IP address 158.152.251.194
: Sep 24 09:17:17 linux pppd[1698]: Hangup (SIGHUP)
: Sep 24 09:17:17 linux pppd[1698]: ipcp: down
: Sep 24 09:17:17 linux pppd[1698]: Exit.

: When there is plenty of traffic, this does not happen.  I have run 
: over two hours of continuous traffic successfully in testing.

: If I set "lcp-echo-interval 180", even though the peer does not seem 
: to return the echos, this problem goes away, but I don't understand 
: why.

I had a similar problem on my system.  What seems to happen is that first of
all your service provider has some timer running on his end and after a
certain period during which no packets travel over the link it simply shuts
the connection down.  In my case it happens after 180sec from the initial
connection.

As far as lcp-echo stuff is concerned it will not work unless whoever you
dial up to has the echo request enabled on their end so that their server
responds to your requests.  Again for me it doesnt work either.

: Also if I then set "lcp-echo-failure 3", as expected, pppd shuts down 
: communications after the specified number of failed echos, but the 
: pppd process does not exit and the modem remains connected.  Moreover 
: pppd will not then exit on any signal but SIGKILL, so my normal ppp 
: shutdown script is ineffective.

Thats weird.  I had stuff like that happen when pppd received HUP and then
went down.  The modem should disconnect within some (unspecified) time
interval.  Sometimes for me it was quick sometimes it was slow.  The way
I worked around it is simply to runn your ppp-off script which should kill 
the deamon and all the rest of the stuff associated with it.

: The random hangup occurs when I start up pppd with:

: # Start the main PPP connection (machine name from /etc/hosts).
: /usr/lib/ppp/pppd connect /usr/local/sbin/demon.ppp \
:     debug \
:     crtscts modem defaultroute lock asyncmap 0x00000000 mru 576 mtu 576 \
:     /dev/$port 38400

Here you might want to look at your demon.ppp file.  I had problems setting my
chat script up initially.  Sometimes too many returns in the file cased the
modem to dial and then once the connection was up everything went to hell.

Also make sure you need asyncmap.  I though I did too in the begining but it turned out I didnt and it was only screwing things up.


As far as keeping the connection up try using some command that periodically
sends something over a link.  vmstat or ping will do.  They dont add too much
traffic to the link and make the connection stay up.

The longest I had the connection up with a ping was about 2 days after which
the noise on my phone like couse the whole think to collapse.

We now really need dial-on-demand.  Check out dp-2.3 sources at Perdue for
their deamon.  It is supposedly much better then pppd.  The only problem is
that there is no linux port.

-Kapi
-- 
Kapi, 542 Baldy Hall, 645-2448

kapis-p@cs.Buffalo.EDU (Piotr Kapiszewski) writes:
>John Phillips (john@linux.demon.co.uk) wrote:
.
.
>: The random hangup occurs when I start up pppd with:
>: # Start the main PPP connection (machine name from /etc/hosts).
>: /usr/lib/ppp/pppd connect /usr/local/sbin/demon.ppp \
>:     debug \
>:     crtscts modem defaultroute lock asyncmap 0x00000000 mru 576 mtu 576 \
>:     /dev/$port 38400

>Here you might want to look at your demon.ppp file.  I had problems setting my
>chat script up initially.  Sometimes too many returns in the file cased the
>modem to dial and then once the connection was up everything went to hell.

>Also make sure you need asyncmap.  I though I did too in the begining but it turned out I didnt and it was only screwing things up.

Actually, asyncmap 0x00000000 says _nothing_ should be escaped. If you 
leave the asyncmap command out, ppp escapes _everything_ from ascii 0 to 127.
which is why leaving it out works, but the above command probably wont. Also,
if you are dialing in to a terminal server or something like that, see if 
you can turn off the various escape characters that the server recognizes. 
You want as transparent a connection as possible.



>We now really need dial-on-demand.  Check out dp-2.3 sources at Perdue for
>their deamon.  It is supposedly much better then pppd.  The only problem is
>that there is no linux port.

??? Perdue?? Could you describe this in a little more detail?

--Chris Davis

kapis-p@cs.Buffalo.EDU (Piotr Kapiszewski) writes:

>We now really need dial-on-demand.  Check out dp-2.3 sources at Perdue for
>their deamon.  It is supposedly much better then pppd.  The only problem is
>that there is no linux port.

Nor is there likely to be one in the future.

We did look at dp. (The current version is 3.0, by the way.)

We also looked at 'portable ppp' and another package called simply 'ppp'.

The problem with dp is that there is no support for any system which does
not use streams. The dp program is a streams driver. The documentation
says that at the start, there was a bsd section. However, it was not
maintained and was subsequently removed some time ago.

A great many changes have taken place with dp since then. I doubt that it
would be worth trying to make it work under Linux.

Demand dial is getting closer in pppd. It looked like it was going to make
it in pppd-2.3.0, but it probably won't by now.

The major addition in pppd-2.3 is the support for BSD compression
protocol.

The major change in pppd for Linux is to get rid of the kludges which Linux
has in the pppd process and go to a simpler format of using select() rather
than SIGIO and SIGALRM.

-- 
Al Longyear           longyear@netcom.com