🚀 go-pugleaf

In article <CBBDt1.Ksw@lunatix.uucp> robert@lunatix.uucp (Robert Sexton) writes:
>In article <dhatz.744498408@news.forth.gr> dhatz@pythia.csi.forth.gr (Dhmhtrhs Hatzopoulos) writes:
>According to SCO,  these things have been fixed in the ODT 3.0
>release.  However, those of us running ODT 2.0 (and tcpip 1.2.0)
>are screwed, because SCO has not commited to releasing a fixed
>ppp for older releases.  

This is pretty true.  See below for more details.

>1.  Hardware flow control is not there.  High speed
>modems are thus out.  I recently was able to work around this by
>using ditty, digiboard's port control utility.

I haven't played with this much, so I can't tell you if this got fixed or
not.

>2.  pppd does not seem to notice when the line drops.

You use the idleout function to control this.  I don't think it's really
been fixed, but if the line drops, it will reset when the idleout period has
passwd.  See below for more info on timeouts.

>3.  Timeout parameters do not work as advertized.

This has been fixed.  It now reliably determines when there is inactivity on
the line and drops it according to what you have it set to in /etc/ppphosts.
There is a gotcha though.  Let say you leave a "ping -i 30 -s 8 foobar"
running to keep the line up.  If the line gets dropped for whatever reason,
your ping will make it look to pppd like there is still activity on the
line.  This will prevent pppd from resetting the connection.  The state it
is left in is that you can't get out and no one can get in because it didn't 
reset properly.  This is what I did to prevent this:

	I set the idleout=1 in ppphosts.  I assume that if I'm going to be
	talking to another site, I'm going to run some kind of ping to keep the
	line up until I'm finished.  I then wrote a perl script that pings out
	to a remote site and checks to see if it got a packet back.  If it
	didn't, it assumes that the line has gone down, sleeps for 180 seconds,
	and then restarts a ping.  This has worked pretty effectively so far.

If anyone wants a copy a the perl script, let me know and I'll send it to
you.

>>From what I can tell (reading /usr/adm/syslog entries), ppp (nppp's
>>login shell) receives a sighup once the dialin line disconnects, but
>>doesn't properly detach the tty. The next time nppp logs in, 'w' doesn't
>>report '-ppp' as nppp's shell and 'ps' reports that 'ppp' doesn't have
>>a controlling tty.
>
>I have found that simply killing the stuck pppd often loosens
>things up.   When connections are terminated normally, ie via a
>shutdown, things seem to work a little better.

If I'm in a hurry and don't want to wait for it to timeout, I wrote a script
called "resetppp" that kills pppd, does an "ifconfig ppp0 down", restarts
pppd, and then does a "ifconfig ppp0 up".  This works pretty well.


-- 
      Jesse W. Asher                                          (901)762-6000
                             Varco-Pruden Buildings
                 6000 Poplar Ave., Suite 400, Memphis, TN  38119
    Internet: jessea@vpbuild.vp.com                   UUCP: vpbuild!jessea