OSR 5.0.4 & MSTPPP 2.1.3a
Shenandoah Mutual Fire Insurance Co.
installed
for on-demand, dynamic outgoing to our local ISP.
My problem is that what ever process that causes the
link to be brought up (except ping to an ip address) times out.
The link is up but the initial request is not fulfilled.
/usr/lib/mstppp Devices
Best_Data_288 tty2A 38400
/usr/lib/mstppp Systems
127.0.0.3 Any;5 ACU 38400 5551212 "" "" in:--in: \dlogname word:
\qpassword
(all one line in actual file)
/usr/lib/mstppp Autostart
/usr/lib/mstppp/dialout 127.0.0.2~:127.0.0.3~ auto exec
/usr/lib/mstppp/exec.dialout netmask 255.255.255.0 debug 5
echolqm nolqm
(all one line in actual file)
If any more information is needed or anyone has had/fixed this
problem please let me know.
Thanks
Mark Getz
********************************************
* Shenandoah Mutual Fire Insurance Company *
* P.O. Box 405 Woodstock Va 22664 *
* Phone:(540) 459-3421 Fax:(540) 459-2093 *
* EMail she...@shentel.net *
********************************************
Olive
I was also having a similar problem. The process which kicks off the PPP
connection on my System is /usr/lib/mstppp/Autostart, while testing the
connection I would run the Autostart script but nothing happened. In the
Autostart script if you add the command "up" just after auto, the ppp
connection should be brought up straight away.
i.e. if your Autostart script should look like :
/usr/lib/mstppp/dialout 127.0.0.2~:127.0.0.3~ auto up exec
/usr/lib/mstppp/exec.dialout netmask 255.255.255.0 debug 5
echolqm nolqm
I hope that I have understood your problem correctly and that this helps.
Olive
Shenandoah Mutual Fire Insurance Co. wrote in message
<1999112420...@sherman.shentel.net>...
swe...@scruznet.com
> I have SCO Openserver 5.0.4 (504c, oss601a) and MSTPPP 2.1.3a
> installed
> for on-demand, dynamic outgoing to our local ISP.
> My problem is that what ever process that causes the
> link to be brought up (except ping to an ip address) times out.
> The link is up but the initial request is not fulfilled.
Someone once posted that the first packet went into /dev/null due
to a bug. The proposed workaround was to list the primary nameserver
twice in /etc/resolv.conf.
Maybe this helps?
-sw
Evan Hunt
Don't blame me, I voted for swe...@scruznet.com.
>Someone once posted that the first packet went into /dev/null due
>to a bug. The proposed workaround was to list the primary nameserver
>twice in /etc/resolv.conf.
It's not a bug, so much as an unavoidable consequence of dynamically-addressed
PPP. The first packet (which is usually a DNS lookup) hits the PPP link,
PPP dials the phone and brings up the connection, and the packet goes out--
but in the meantime the IP address has been changed by the server you
dialed into, and so the source address in the packet is wrong, and so
the answer gets lost on the way back.
The workaround you mentioned works fine.
--
Evan Hunt - evanh at sco dot com
"The wages of sin are death. But after taxes are taken out,
it's just a sort of tired feeling." - Paula Poundstone