Date: Mon, 2 Nov 1998 18:18:13 +0000 (GMT)
From: John and Lucy Hayward-Warburton <hay-warb@billabong.demon.co.uk>
To: "Charles P. Wright" <cpwright@villagenet.com>
Subject: Re: IP Masq Dialler

Hello, Charles.

Now, here are the raw changes I first made to mserver to make it work. As
it stands, it just looks at the syslog file... it could be made much
better because I don't check whether or not the connection is failing; at
present it can get stuck in a no-man's-land of "connection pending" if the
far end fails after dialling, but before PPP fires up on the line. I know
it's an ISP problem, and not at my end, but they're not so reliable.

Furthermore, ipppd still doesn't generate a LCK..ttyI0 file! So I do it
myself, with the line

echo ${$} > /var/lock/LCK..ttyI0

in my /usr/local/bin/internetstart script.

>> The following information inserted by Charles P. Wright is from Gustav
>> Eimar <eimar@hempseed.com>
If you script exits and doesn't stick around you should use the following line
to get the pid of IPPPD in /var/lock/LCK..ttyI0:
echo `pidof ipppd` > /var/lock/LCK..ttyI0"
>> End Quote

Here is my mserver.conf file:

port = 222
debugport = 2222
demon = true
inetd = false
slimit = 10
license = /usr/local/share/mserver/LICENSE
history = /usr/local/share/mserver/HISTORY
# I use stattype because the network devices in /proc don't easily
# reflect what's really going on with the status of the PPP link
stattype = pppdlock
netdev = ippp0
devfile = "/proc/net/dev"
lockfile = "/var/lock/LCK..ttyI0"
logfile = "/var/log/messages"
confile = "/tmp/mserver_status"
admin_ipallow = "127.0.0.1"
cspeed = 64000
defkill = "internal"
killsig = "-KILL"
logtimeout = 120
parselog = true
cname = "ISDN"
ISDN_script = "/usr/local/bin/internetstart"
ISDN_ipallow = "192.168.7.*:127.0.0.1"
ISDN_info = "Billabong using Demon Internet"
ISDN_kill = "/usr/local/bin/internetstop"

Here is a good log, followed by an explanation of what can go wrong.

Nov  1 23:02:05 billabong ipppd[1039]: Local number: , Remote number: 13208453535667, Type: outgoing
Nov  1 23:02:05 billabong ipppd[1039]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 7
Nov  1 23:02:05 billabong ipppd[1039]: Remote message: billabong: IP Address: 194.222.216.167  Running PPP on 10719LINX maintenance in progress.Finger status@gate.demon.co.uk for more info. Last change: 21:00 Nov 01  HELLO^M
Nov  1 23:02:05 billabong ipppd[1039]: bundle, he: 0 we: 0
Nov  1 23:02:05 billabong ipppd[1039]: CCP enabled! Trying CCP.
Nov  1 23:02:05 billabong ipppd[1039]: CCP: got ccp-unit 0 for link 0 (protocol: 0x80fd)
Nov  1 23:02:05 billabong ipppd[1039]: ccp_resetci!
Nov  1 23:02:05 billabong ipppd[1039]: local  IP address 194.222.216.167
Nov  1 23:02:05 billabong ipppd[1039]: remote IP address 158.152.1.222

"PHASE_WAIT -> PHASE ESTABLISHED"... mark the machine's acknowledgement of
an active ISDN connection;
"local IP address / remote IP address"... always come together, and
indicate the interface (ippp0 in this case) going 'up'.

I think the best way of determining whether a link is active or not is to
examine the system log. /proc/net/dev shows ippp0 whenever ipppd is active
(it doesn't matter if the link is up or down) and the LCK..ttyI0 file is
generated by my scripts because either ipppd doesn't generate the file
when asked, or because I don't drive it properly.

What sometimes goes wrong is either the call fails due to a line error, or
the PPP at the distant end fails to kick in. (Sometimes, routing at the
far end fails, and when I return, I'd like to try writing a simple
auto-ping routine that tries pinging a well-known router at my ISP, and
drops/redials the link if the ping doesn't work for, say, ten seconds.)

Errors on dialling look like this:

Oct 31 12:09:03 billabong kernel: isdn: HiSax,ch0 cause: E0229
Oct 31 12:09:03 billabong kernel: ippp0: remote hangup
Oct 31 12:09:03 billabong kernel: ippp0: Chargesum is 0
Oct 31 12:09:03 billabong kernel: isdn: HiSax,ch0 cause: E0229

The "E0229" is an error code. The possible responses are given in the
isdn_cause manpage which is attached to the end of this email.

Note that ipppd doesn't respond at all to an error: everything is handled
by the kernel. In this case, on my system, the ideal response is to close
the connection manually (isdnctrl hangup ippp0; ifconfig ippp0 down), and
then restart manually. My terminate script /usr/local/bin/internetstop
does that for me.

At the end of a call, the log shows:

Nov  1 21:53:22 billabong ipppd[102]: Modem hangup
Nov  1 21:53:22 billabong ipppd[102]: Connection terminated.
Nov  1 21:53:22 billabong ipppd[102]: taking down PHASE_DEAD link 0, linkunit: 0
Nov  1 21:53:22 billabong ipppd[102]: closing fd 7 from unit 0
Nov  1 21:53:22 billabong ipppd[102]: link 0 closed , linkunit: 0
Nov  1 21:53:22 billabong ipppd[102]: reinit_unit: 0
Nov  1 21:53:22 billabong ipppd[102]: Connect[0]: /dev/ippp0, fd: 7

I think this explains itself. "Connect[0]..." seems to mean
"disconnected". Sometimes, if the distant end times out, other messages
precede those seen:

Nov  1 23:19:43 billabong ipppd[1039]: IPCP terminated by peer
Nov  1 23:19:44 billabong ipppd[1039]: LCP terminated by peer
Nov  1 23:19:46 billabong kernel: isdn: HiSax,ch0 cause: E0229
Nov  1 23:19:46 billabong kernel: ippp0: remote hangup
Nov  1 23:19:46 billabong kernel: ippp0: Chargesum is 0
Nov  1 23:19:46 billabong ipppd[1039]: Modem hangup
Nov  1 23:19:46 billabong ipppd[1039]: Connection terminated.
Nov  1 23:19:46 billabong ipppd[1039]: taking down PHASE_DEAD link 0, linkunit: 0
Nov  1 23:19:46 billabong ipppd[1039]: closing fd 7 from unit 0
Nov  1 23:19:46 billabong ipppd[1039]: link 0 closed , linkunit: 0
Nov  1 23:19:46 billabong ipppd[1039]: reinit_unit: 0
Nov  1 23:19:46 billabong ipppd[1039]: Connect[0]: /dev/ippp0, fd: 7
Nov  1 23:19:46 billabong kernel: isdn: HiSax,ch0 cause: E0229

Often, the link fails. In this case, if ipppd doesn't autodial (sometimes
it does, sometimes it doesn't!), and you'll get a set of messages that
include "hangup".

This is how my logic for connecting to the internet via ISDN works:

If you try to connect, but get a /var/adm/messages line with both "ippp0"
and "hangup" in it, your ISDN connection on the ippp0 interface has
failed.

If you do connect, but don't get the "local  IP address..." / "remote IP
address..." pair within an acceptable time limit (10 seconds here) your
connection has failed. (Nasty business: there's an extra space between
"local" and "IP" in the log message to make it line-up on the screen)

Otherwise, all is well.

Here, now, are the very small changes I had to make to version 0.0.7 to
make it go. This is all I had to do, apart from generate my own LCK.. file
and get mserver.conf right. I'm afraid that after changing these few
lines, other things started to get in the way, but we should be back to
normal and back from Oz by Christmas. No ISDN out there! Just a hotel
phone and a pair of crocodile clips.

Best wishes,

John Hayward-Warburton
hay-warb@billabong.demon.co.uk

Diffs, then one attachment.


--- dial.c	Sun Oct 11 01:06:06 1998
+++ ../mserver-mod/dial.c	Tue Oct 13 10:42:32 1998
@@ -145,19 +145,19 @@
 		}
 		else
 		{
-			if (strstr(temp, "pppd[") != NULL)
+			if (strstr(temp, "ipppd[") != NULL)
 			{
 				if (strstr(temp, "started") != NULL)
 				{
-					fprintf(outsock, "PPPD Process Started\n");
+					fprintf(outsock, "IPPPD Process Started\n");
 					fflush(outsock);
 				}
-				else if (strstr(temp, "Serial connection established") != NULL)
+				else if (strstr(temp, "PHASE_WAIT -> PHASE_ESTABLISHED") != NULL)
 				{
 					fprintf (outsock, "Modem Connected\n");
 					fflush(outsock);
 				}
-				else if (strstr(temp, "Connect: ppp") != NULL)
+				else if (strstr(temp, "local  IP address") != NULL)
 				{
 					fprintf (outsock, "PPP Link Established\n");
 					continue_log = false;
--- getstat.c	Sat Oct 10 14:21:07 1998
+++ ../mserver-mod/getstat.c	Tue Oct 13 11:11:10 1998
@@ -124,7 +124,7 @@
 	{
 		return false;
 	}
-
+#if 0
 	fgets(temp, 1024, lock);
 	fclose (lock);
 
@@ -148,6 +148,6 @@
 	{
 		return false;
 	}
-
+#endif
 	return true;
 }
