Bash script to see if PPP link is up...
Gabriel Michael
I'm looking for a way to have a bash shell script check to see if a
particular ppp link is up (ppp0), and if so, output "1", if not,
output "0"... my (messy) idea was:
ping -c 1 host.i.want.to.ping | grep -c "0% loss"
This outputs a "1" if the host is up... then I'd assign that value to
a variable, and test the variable, and output 1 or 0 based on that.
I'm sure there's a better way to do this, but my mind is blanking...
Thanks in advance,
Gabe
Bit Twister
Well if that is the default gateway, it tests routing, DNS, and connectivity
through your isp gateway in one shot.
I would add -w 2 or something to prevent longer time outs.
Maybe increasing the -c and test for 3 good in 5 pings just incase
there is an odd ping failure or two.
What do you feel is wrong with it?
Floyd Davidson
Read the man page for ping.
#!/bin/sh
if ping -qnw1 -c1 ip_address 2>&1 >/dev/null
then
echo "Link is up"
else
echo "Link is down"
fi
--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl...@barrow.com
Alan Connor
Here's the script I use to post news with, using a ppp link:
#!/bin/bash
pon
while true ; do sleep 1 ; if tail -1 /var/log/syslog \
| grep IP 1> /dev/null ; then sleep 2 ; slrnpull --post-only ; poff ; exit 0 ; else continue ; fi ; done
There are a lot of other ways, of course.
Alan C
David Efflandt
Unless you have a flaky ISP with routing problems, it would be better to
just determine if pppd is connected or not instead of constantly pinging
an outside host (which may not like that). You cannot use ifconfig
output to tell status of demand pppd (since ppp0 is up whether connected
or waiting to be triggered).
When I used demand dialup pppd, I wrote write my local IP to a file
(/etc/ppp/stat) from /etc/ppp/ip-ip (or ip-up.local) and similarly wrote a
zero to that file from ip-down (or ip-down.local). In SuSE ip-down.local
was a symlink to ip-up.local and it used a case to determine if it was
coming up or down. Then I simply checked if the contents of the
/etc/ppp/stat file was greater than zero to tell if I was connected.
For example /etc/ppp/ip-up.local (and ip-down.local symlink):
#!/bin/sh
BASENAME=${0##*/}
INTERFACE=$1
DEVICE=$2
SPEED=$3
LOCALIP=$4
REMOTEIP=$5
# demand pppd status
case "$BASENAME" in
ip-up*)
echo $LOCALIP > /etc/ppp/stat
# update dynamic DNS (older no-ip.com binary then)
/usr/local/bin/noip
;;
ip-down*)
echo 0 > /etc/ppp/stat
;;
*)
;;
esac
Sample shell script to tell if I was online:
#!/bin/sh
FILE="/etc/ppp/stat"
if [ ! -r "$FILE" ]; then
echo "$FILE not found or unreadable"
exit 1
fi
STATUS=`cat "$FILE"`
if [ "$STATUS" = "0" ]; then
echo "pppd is not connected"
else
echo "pppd ip: $STATUS"
fi
--
David Efflandt - All spam ignored http://www.de-srv.com/
http://www.autox.chicago.il.us/ http://www.berniesfloral.net/
http://cgi-help.virtualave.net/ http://hammer.prohosting.com/~cgi-wiz/
JRH
> On 19 Aug 2003 18:51:35 -0700, Gabriel Michael <gmic...@fastmail.fm>
> wrote:
[..]
>> I'm looking for a way to have a bash shell script check to see if a
>> particular ppp link is up (ppp0)
[..]
>> Gabe
[..]
> There are a lot of other ways, of course.
> Alan C
This is what I use, based on script in ?Firewall or ?Masquerading HOWTO. I
don't pretend to understand the details! It is said to work in all
locales.
EXTIF="ppp0" # external interface, may be empty
IFCONFIG=/sbin/ifconfig
AWK=/bin/awk
# get the external IP address - it returns empty string if it is not up
if [ -n "$EXTIF" ]; then
EXTIP="`$IFCONFIG $EXTIF 2>/dev/null | $AWK \
/$EXTIF/'{next}//{split($0,a,":");split(a[2],a," ");print a[1];exit}'`"
fi
echo " External IP: $EXTIP"
...John
--
---------------------------------------------------
(Remove digits from my email address before use ;-)
Alan Connor
Yeh. Read from ifconfig instead of /var/log/syslog. Good idea.
But that script is grossly over-complex for his purposes . All you need to do
is run:
/sbin/ifconfig ppp*
and look at the exit code to see if it is up:
echo $?
0 for yes and 1 for no.
The awk part of the script is just stripping the IP address from the
output of ifconfig. Easier with sed.
Alan C
Floyd Davidson
>
>But that script is grossly over-complex for his purposes . All you need to do
>is run:
>
>
>/sbin/ifconfig ppp*
>
>and look at the exit code to see if it is up:
>
>echo $?
>
>0 for yes and 1 for no.
Wrong.
It returns 1 if the interface has never been up. It returns 0
for an interface that is up, or that has been configured and is
currently down.
Alan Connor
>
>
> Alan Connor <xxx...@xxxx.xxx> wrote:
>>
>>But that script is grossly over-complex for his purposes . All you need to do
>>is run:
>>
>>
>>/sbin/ifconfig ppp*
>>
>>and look at the exit code to see if it is up:
>>
>>echo $?
>>
>>0 for yes and 1 for no.
>
> Wrong.
>
> It returns 1 if the interface has never been up. It returns 0
> for an interface that is up, or that has been configured and is
> currently down.
>
Wrong. I tested it before I posted.
You should try it sometime.
Alan C
Floyd Davidson
>>>
>>>/sbin/ifconfig ppp*
>>>
>>>and look at the exit code to see if it is up:
>>>
>>>echo $?
>>>
>>>0 for yes and 1 for no.
>>
>> Wrong.
>>
>> It returns 1 if the interface has never been up. It returns 0
>> for an interface that is up, or that has been configured and is
>> currently down.
>>
>
>Wrong. I tested it before I posted.
Clearly not.
>You should try it sometime.
Here's one test you clearly didn't try:
>ifconfig dummy0
dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.3.1 Bcast:192.168.3.255 Mask:255.255.255.0
...
>echo $?
0
>ifconfig dummy0 down
>ifconfig dummy0
dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.3.1 Bcast:192.168.3.255 Mask:255.255.255.0
BROADCAST NOARP MTU:1500 Metric:1
...
>echo $?
0
David Efflandt
ifconfig may be able to tell if it is up, but can it tell if it is
connected or not? For example when you use demand pppd, the ppp0
interface appears in ifconfig, but it is not connected until there is
traffic routed to it. Likewise if an idle time is set for a demand
connection and it disconnects, ifconfig would still show it up. That is
why I use ip-up & ip-down scripts (which are reliable even for demand and
idle).
Alan Connor
>
>
> Alan Connor <xxx...@xxxx.xxx> wrote:
>>>>
>>>>/sbin/ifconfig ppp*
>>>>
>>>>and look at the exit code to see if it is up:
>>>>
>>>>echo $?
>>>>
>>>>0 for yes and 1 for no.
>>>
>>> Wrong.
>>>
>>> It returns 1 if the interface has never been up. It returns 0
>>> for an interface that is up, or that has been configured and is
>>> currently down.
>>>
>>
>>Wrong. I tested it before I posted.
>
> Clearly not.
Fuck you. Killfiled again. And this time it is permanent.
Alan C
Alan Connor
>
>
> On Thu, 21 Aug 2003 21:28:57 GMT, Alan Connor <xxx...@xxxx.xxx> wrote:
>> On Thu, 21 Aug 2003 21:54:51 +0100, JRH <john...@yoredale2003.uklinux.net> wrote:
>
> ifconfig may be able to tell if it is up, but can it tell if it is
> connected or not? For example when you use demand pppd, the ppp0
> interface appears in ifconfig, but it is not connected until there is
> traffic routed to it. Likewise if an idle time is set for a demand
> connection and it disconnects, ifconfig would still show it up. That is
> why I use ip-up & ip-down scripts (which are reliable even for demand and
> idle).
>
To repeat:
If my ppp connection is not up, /sbin/ifconfig ppp0 exits with an error
message and the exit code reads 1
If the connection is up, then I get the full info and the exit code is 0.
This info includes the local and remote IP addresses, which cannot be there
until the connection is actually established, being as they are both dynamic.
It seems that some folks have the mistaken notion that all programs and
utilities with the same name behave just the same, even on differently
configured OSs.
This is not the case, and that asshole Floyd Davidson, whom I have just
killfiled for the second time (everyone deserves a second chance, no?)
knows this perfectly well.
I recommend being very careful about his advice. His ego is bigger than
his desire to accurately inform others.
Alan C
Lew Pitcher
[some disparaging words about another poster, which I have snipped]
FWIW, I concur with Mr. Efflandt.
I run a "demand connect" ppp on my home server, and your ifconfig returncode
hack wouldn't (and doesn't) work[1] on it. In fact, the usual grep on
ifconfig's report doesn't work[1] either. In both cases, the technique given
falsly reports that I have a connection to the internet [2] when I do not.
By far the best way to detect whether you have an IP connection is to
a) place code in /etc/ppp/ip-up and /etc/ppp/ip/down that manages an
external sentinal for the IP (and/or IPX) connections, and
b) use external tools to test the sentinal
This is a reliable technique that does not give false positives when using
demand-dial ppp.
[1] "work" as in "reliably indicate the state IP over PPP".
[2] Notice that I said "have a connection to the internet" rather than "PPP
is UP". PPP can be "UP" without having established /any/ connection at
all ("Gee, I hear a dialtone on my telephone. How can ppp be 'up'?").
Even when ppp is using the phone line, it can be "UP" without having
established an IP link. In both cases, the suggested ifconfig techniques
would truely report that ppp is UP, but falsly imply that IP
connectivity had been established.
--
Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group
(Opinions expressed here are my own, not my employer's)
Clifford Kite
> I recommend being very careful about his advice. His ego is bigger than
> his desire to accurately inform others.
You are arrogant far beyond your means. I've finally put you in *my*
kill file. Replying is futile.
--
Clifford Kite
/dev/rob0
Alan Connor wrote:
> If my ppp connection is not up, /sbin/ifconfig ppp0 exits with an error
> message and the exit code reads 1
>
> If the connection is up, then I get the full info and the exit code is 0.
Please demonstrate that at the command line and paste it here. Perhaps
try it both with and without using an intermediate "rmmod ppp_generic"
command. (Understand also that those with static, non-modular kernels,
cannot remove the driver.)
> It seems that some folks have the mistaken notion that all programs and
> utilities with the same name behave just the same, even on differently
> configured OSs.
I appreciate the fact that you qualified that with "it seems". I myself
have the belief that /sbin/ifconfig on GNU/Linux of any flavour is
likely to have been based on the same source code, and that its
behaviour differences where seen are likely to have logical and definite
causes.
[Floyd Davidson]
> knows this perfectly well.
Mr. Davidson is not always cheerful ... possibly because he's fleeing
hungry polar bears and losing sleep due to midnight sun[1] ... but he's
always an excellent resource on Unix matters.
> I recommend being very careful about his advice. His ego is bigger than
> his desire to accurately inform others.
Not having had the chance to get to know him personally, and lacking
such extraordinary confidence in my telepathic abilities, I could not
venture such an observation. But TBH I will say that I have no greater
confidence in your ability to draw such a conclusion.
You seem to be a poster who allows his anger to interfere in what
otherwise could / should be a factual discussion. That, I would venture,
could well be an issue of egotism ... or of something else. I'm not much
into psychoanalysis ever since I discovered computers. :)
My recommendation to Usenet readers WRT Mr. Davidson is the opposite of
yours. Those who ignore him will miss out on a lot of valuable
information and experience.
[1] This is, of course, a joke. It never hurts to make that clear on
Usenet.
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply
Alan Connor
For the third time, for those who of you who apparently cannot read simple
English or are foolish enough to believe that you know everything about linux,
which is impossible.
If my ppp connection is not up, ie I am not connected to my isp, then this is
what happens:
alanc@localhost:~$ /sbin/ifconfig ppp0
ppp0: error fetching interface information: Device not found
alanc@localhost:~$ echo $?
1
If the connection IS up:
alanc@localhost:~$ /sbin/ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:65.157.134.245 P-t-P:64.167.222.8 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1524 Metric:1
RX packets:5 errors:1 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:710 (710.0 b) TX bytes:195 (195.0 b)
alanc@localhost:~$ echo $?
0
I have altered the IP addresses.
Apparently what is going on is that the ppp0 interface is being configured on
demand, then un-configured when I am through with it.
This makes it reliable for the sort of tests the OP was interested in on MY
box.
Eth0 and lo on the other hand, are permanently configured and always show
up with ifconfig -a.
Now. If anyone calls me a liar or an idiot one more time, their ass
is killfiled, and good riddance to fools. I will be saved from bad advice in
the future.
Alan C
Lew Pitcher
[snip]
> If my ppp connection is not up, ie I am not connected to my isp, then this is
> what happens:
>
> alanc@localhost:~$ /sbin/ifconfig ppp0
> ppp0: error fetching interface information: Device not found
With my dial-on-demand ppp setup, /sbin/ifconfig ppp0 will show the ppp0
details even when /not/ connected to my ISP. In fact, ifconfig shows my
/disconnected/ ppp0 as having an IP address.
> alanc@localhost:~$ echo $?
> 1
>
> If the connection IS up:
>
>
> alanc@localhost:~$ /sbin/ifconfig ppp0
> ppp0 Link encap:Point-to-Point Protocol
> inet addr:65.157.134.245 P-t-P:64.167.222.8 Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1524 Metric:1
> RX packets:5 errors:1 dropped:0 overruns:0 frame:0
> TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:710 (710.0 b) TX bytes:195 (195.0 b)
>
>
> alanc@localhost:~$ echo $?
> 0
>
> I have altered the IP addresses.
I will post the same from /my/ system tomorrow (when I can get to it).
You'll see a difference between what works on /my/ system (Slackware Linux
9.0 with all current upgrades) and what works (or not) on yours.
FWIW, I've been running ppp dial-on-demand since Slackware 7.0 and it has
never behaved like you describe.
> Apparently what is going on is that the ppp0 interface is being configured on
> demand, then un-configured when I am through with it.
Apparently, that behaviour is on your box. My box does different.
> This makes it reliable for the sort of tests the OP was interested in on MY
> box.
But not on /my/ box.
And not in the /general case/.
> Eth0 and lo on the other hand, are permanently configured and always show
> up with ifconfig -a.
Yes.
> Now. If anyone calls me a liar or an idiot one more time, their ass
> is killfiled, and good riddance to fools. I will be saved from bad advice in
> the future.
Killfile me or not, I don't care about your opinion.
I /do/ care that questions get answered properly, and system or
configuration dependancies get identified. Obviously, you've got a system or
configuration depencancy that behaves in a consistant testable manner for
/you/. However, the behaviour you describe does not work for everyone. If
you take someone saying that your procedure won't work in general (or even,
won't work for them in particular) as being called a liar, then you are
reading too much into the words entered here.
>
> Alan C
Alan Connor
>
>
> Alan Connor wrote:
> [snip]
>> If my ppp connection is not up, ie I am not connected to my isp, then this is
>> what happens:
>>
>> alanc@localhost:~$ /sbin/ifconfig ppp0
>> ppp0: error fetching interface information: Device not found
>
> With my dial-on-demand ppp setup, /sbin/ifconfig ppp0 will show the ppp0
> details even when /not/ connected to my ISP. In fact, ifconfig shows my
> /disconnected/ ppp0 as having an IP address.
welcome to my killfile, fool.
Alan C
Gabriel Michael
> Read the man page for ping.
>
> #!/bin/sh
> if ping -qnw1 -c1 ip_address 2>&1 >/dev/null
> then
> echo "Link is up"
> else
> echo "Link is down"
> fi
Thanks, this is exactly what I needed. The ppp link is for a VPN, so
it's not bad etiquette for me to incessantly pinging the other end ;-)
Alan Connor
Every since this thread began, I have been using the following script, and
it has not failed ONCE. Neither has its mirror, the one to upload news.
I have run both of them FAR more often than I would normally, precisely
for the purpose of testing them.
#!/bin/sh
# getnews, aliased to gn
pon
while true ; do
/sbin/ifconfig
k=`echo $?`
if [ "$k" = "0" ] ; then slrnpull --no-post && exit 0
else continue
fi
done
poff
So I am supposed to believe the rantings of egomaniacal fools who think they
know everything about linux? Or the evidence of my own eyes?
Fortunately, that decision is mine and mine alone.
Alan C
Alan Connor
>
>
>
> Every since this thread began, I have been using the following script, and
> it has not failed ONCE. Neither has its mirror, the one to upload news.
>
> I have run both of them FAR more often than I would normally, precisely
> for the purpose of testing them.
>
>
> #!/bin/sh
>
> # getnews, aliased to gn
>
> pon
>
> while true ; do
>
> /sbin/ifconfig
>
> k=`echo $?`
>
>
> if [ "$k" = "0" ] ; then slrnpull --no-post && exit 0
> else continue
>
> fi
>
> done
>
> poff
>
>
Oops! I should have pasted the script rather than relying on memory
> if [ "$k" = "0" ] ; then slrnpull --no-post && poff && exit 0
and, obviously, remove the useless "poff" from the bottom.
And yes, for clarities' sake, I left out the parts that sends the stderr
and stdout messages to /dev/null
>
>
> So I am supposed to believe the rantings of egomaniacal fools who think they
> know everything about linux? Or the evidence of my own eyes?
>
> Fortunately, that decision is mine and mine alone.
>
>
> Alan C
>
>
>
Alan C
Alan Connor
>
Christ! I just got an email pointing out that I had made yet ANOTHER mistake
in the script I posted.
hehe. I am VERY busy at present and quite distracted. My apologies.
Here's the script, cut and pasted, just like I use it.
Works every time, and never gotten an error message from slrnpull.
#!/bin/sh
pon
while true ; do
sleep 1
/sbin/ifconfig ppp0 &> /dev/null
k=`echo $?`
if [ "$k" = "0" ] ; then slrnpull --no-post && poff && exit 0
else continue
fi
done
Out of this wonderful medium for at LEAST a couple of hours.
Alan C
/dev/rob0
Alan Connor wrote:
> For the third time, for those who of you who apparently cannot read simple
I appreciate your patience and tolerance, and I apologise if I happened
to miss something earlier in the thread.
> If my ppp connection is not up, ie I am not connected to my isp, then this is
> what happens:
>
> alanc@localhost:~$ /sbin/ifconfig ppp0
> ppp0: error fetching interface information: Device not found
>
> alanc@localhost:~$ echo $?
> 1
Indeed. I can explain this now. Shell clippings inside "#v" marks, with
comments and explanations immediately following each block.
#v+
rob0@obrien:~$ /sbin/ifconfig lo ; echo $?
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:27566 errors:0 dropped:0 overruns:0 frame:0
TX packets:27566 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3511905 (3.3 Mb) TX bytes:3511905 (3.3 Mb)
0
#v-
For reference, an active interface, exit code 0.
#v+
rob0@obrien:~$ /sbin/ifconfig dummy0 ; echo $?
dummy0: error fetching interface information: Device not found
1
rob0@obrien:~$ sudo /sbin/modprobe dummy
rob0@obrien:~$ /sbin/ifconfig dummy0 ; echo $?
dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
0
#v-
dummy0 was inactive before, and the driver (a module in this kernel) was
not loaded. Without the driver, exit code 1, just as you got with ppp0.
*With* the driver but *no* IP assigned, exit code 0.
#v+
rob0@obrien:~$ sudo /sbin/ifconfig dummy0 192.168.192.168
rob0@obrien:~$ /sbin/ifconfig dummy0 ; echo $?
dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.192.168 Bcast:192.168.192.255 Mask:255.255.255.0
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:2455 (2.3 Kb)
0
rob0@obrien:~$ sudo /sbin/ifconfig dummy0 down
rob0@obrien:~$ /sbin/ifconfig dummy0 ; echo $?
dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.192.168 Bcast:192.168.192.255 Mask:255.255.255.0
BROADCAST NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:2710 (2.6 Kb)
0
#v-
Assigned an IP to the interface, note now the "UP" flag, Still exit code
0. Took the interface down, no "UP" flag, and still 0.
#v+
rob0@obrien:~$ sudo /sbin/modprobe -rv dummy
# delete dummy
rob0@obrien:~$ /sbin/ifconfig dummy0 ; echo $?
dummy0: error fetching interface information: Device not found
1
#v-
ifconfig exits with 0 if the interface exists, 1 if not. The interface
exists whilst the driver is loaded.
> If the connection IS up:
>
>
> alanc@localhost:~$ /sbin/ifconfig ppp0
> ppp0 Link encap:Point-to-Point Protocol
> inet addr:65.157.134.245 P-t-P:64.167.222.8 Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1524 Metric:1
> RX packets:5 errors:1 dropped:0 overruns:0 frame:0
> TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:710 (710.0 b) TX bytes:195 (195.0 b)
>
>
> alanc@localhost:~$ echo $?
> 0
Yes, this is expected, because the interface can only be up if its
driver is loaded.
> I have altered the IP addresses.
Save the trouble next time: the real one is in your NNTP-Posting-Host:
header. :) (And if the IP is dynamic, who cares?)
> Apparently what is going on is that the ppp0 interface is being configured on
> demand, then un-configured when I am through with it.
Your script or something being run by your distro is unloading the
ppp_generic module when you disconnect. Mine has a cron.hourly job to
remove unused modules, but I always disable that on my systems. Yours
might be running that job (it's "/sbin/rmmod -as" BTW) more frequently,
or perhaps the ip-down script explicitly removes ppp_generic.
If you're interested in testing this, try "/sbin/lsmod" before you make
the connection, after it comes up, and after it's terminated. Check the
crontab for root and the /etc/cron.hourly directory.
Also, try an explicit load of ppp_generic, and then check lsmod. Note
the absence of the "(autoclean)" flag. From now on your script will
probably fail (unless as noted, ip-down removes the module.) rmmod or
modprobe will not automatically remove non-autoclean modules.
> This makes it reliable for the sort of tests the OP was interested in on MY
Indeed, but it might well NOT be reliable on other machines, nor on
differently-managed distros, as you mentioned before.
> Eth0 and lo on the other hand, are permanently configured and always show
> up with ifconfig -a.
If either one is a module, you could do the same with it as I just
showed you with my dummy0 interface.
> Now. If anyone calls me a liar or an idiot one more time,
I don't recall having called you anything of the sort. I do, however,
believe that you misunderstood the reason why your script was working. I
hope this helps to clear the confusion.
Floyd Davidson
Still, you probably don't need to do it in a continious loop without
sleeping for several seconds between pings.
Floyd Davidson
>Works every time, and never gotten an error message from slrnpull.
For anyone who might need this functionality (other than "Alan
Connor"), this script should be *avoided*.
It will provide false positives on the test under several
different circumstances that have caused the PPP link to fail.
"Alan Connor", who is a well known net kook that has posted
under a number of different names, may have never experienced
any of the conditions in which it fails, but others who have
worked on a reliable means of testing whether a link is up or
not have.
His script only works when the PPP link is properly taken down
in the manner expected. If the modems drop the link due to line
noise, for example, the results will not be so kind.
The only way I've found to effectively test a link is to ping
the distant end. A script that runs when the link is
established can store the appropriate IP address to ping, and
then scripts like this can fetch that address from a known
location and use something like the test previously posted:
IPADDR=$(cat /etc/ppp/remoteaddress)
if ! ping -q -w 2 -c 1 ${IPADDR}
then
echo "PPP link is not available"
exit 1
fi
... # rest of script goes here
And further, I would caution that skipping the script to save the remote
IP address for the PPP link, and instead just choosing some obvious IP
address such as the ISP's mail server, router, or whatever, is a *bad*
idea! They *will* eventually change the IP address or take it down for
maintenance or something. And trouble shooting your system because they
did, won't be a pleasant experience.
>#!/bin/sh
>
>
>pon
>
>while true ; do
>
>sleep 1
>
>/sbin/ifconfig ppp0 &> /dev/null
>
>k=`echo $?`
>
>if [ "$k" = "0" ] ; then slrnpull --no-post && poff && exit 0
>
>
>else continue
>
>fi
>
>done
>
>
>
>Out of this wonderful medium for at LEAST a couple of hours.
>
>
>
>Alan C
>
>
>
>
--
Alan Connor
You certainly didn't call me anything and thanks much for the insight, Rob0,
I'll tuck this in my /doc/ppp dir because it deserves at least another reading.
I am dead sure that you are right about the module being loaded and unloaded
on demand, but will check it out anyway.
Alan C
Lew Pitcher
> On Fri, 22 Aug 2003 03:53:41 +0000 (UTC), David Efflandt <effl...@xnet.com> wrote:
>
>>
>>On Thu, 21 Aug 2003 21:28:57 GMT, Alan Connor <xxx...@xxxx.xxx> wrote:
>>
>>>On Thu, 21 Aug 2003 21:54:51 +0100, JRH <john...@yoredale2003.uklinux.net> wrote:
>>
>>ifconfig may be able to tell if it is up, but can it tell if it is
>>connected or not? For example when you use demand pppd, the ppp0
>>interface appears in ifconfig, but it is not connected until there is
>>traffic routed to it. Likewise if an idle time is set for a demand
>>connection and it disconnects, ifconfig would still show it up. That is
>>why I use ip-up & ip-down scripts (which are reliable even for demand and
>>idle).
>>
>
>
> To repeat:
>
> If my ppp connection is not up, /sbin/ifconfig ppp0 exits with an error
> message and the exit code reads 1
>
> If the connection is up, then I get the full info and the exit code is 0.
The keys to this are the words "my" and "I", as in "my ppp connection" and "I get".
Your experience is not the be-all and end-all of Linux, and ifconfig is not a reliable
way to determine if pppd has established an internet connection.
[snip]
> It seems that some folks have the mistaken notion that all programs and
> utilities with the same name behave just the same, even on differently
> configured OSs.
Including you. You seem to think that ifconfig is a reliable indicator, and /we/
have experience that it is not.
[snip]
So, instead of debating who's right and who's wrong, lets /see/ what happens.
On /my/ system, I'll try /your/ suggestion and JRH's script, and we'll see if
either of you have a solution that will work for me.
I run Slackware Linux 9.0 (I've run Slackware Linux since it's 3.0 release),
with current levels of all relevant packages and the 2.4.21 kernel. I have
pppd running in "dial-on-demand" mode so that any off-lan activity from my
lan gets routed through the ppp interface to the internet.
/I/ say that your ifconfig trick doesn't reliably indicate when this config
is "on the internet" and when it is "off". /I/ say that JRH's script suffers
from the same unreliability, although his script gives a little better info
than technique does. /I/ say that the only reliable way /I've/ found to
determine the state of my internet connection is to use the features of
the /etc/ppp/ip-up and /etc/ppp/ip-down scripts.
So, here's my demonstration...
Linux Kernel 2.4.21 compiled for Pentium processor
root@merlin:~# uname -a
Linux merlin 2.4.21 #17 Sat Jun 21 21:34:23 EDT 2003 i586 unknown
Slackware Linux 9.0 installation (all packages updated)
root@merlin:~# cat /etc/slackware-version
Slackware 9.0.0
The ppp-2.4.1-i386-2 package from slackware.com
root@merlin:~# ls /var/adm/packages/ppp*
/var/adm/packages/ppp-2.4.1-i386-2
Verify that...
root@merlin:~# head -16 /var/adm/packages/ppp-2.4.1-i386-2
PACKAGE NAME: ppp-2.4.1-i386-2
COMPRESSED PACKAGE SIZE: 186 K
UNCOMPRESSED PACKAGE SIZE: 480 K
PACKAGE LOCATION: slackware/n/ppp-2.4.1-i386-2.tgz
PACKAGE DESCRIPTION:
ppp: ppp (Point-to-Point Protocol)
ppp:
ppp: The Point-to-Point Protocol (PPP) provides a method for transmitting
ppp: data over serial links. It's commonly used for connecting to the
ppp: Internet using a modem. This package includes the PPP daemon (pppd),
ppp: which negotiates with the peer to establish the link and sets up the
ppp: ppp network interface, and pppsetup, an easy-to-use utility for
ppp: setting up your PPP daemon.
ppp:
ppp:
ppp:
Even pppd agrees.
root@merlin:~# pppd -h
pppd version 2.4.1
Usage: pppd [ options ], where options are:
<device> Communicate over the named device
<speed> Set the baud rate to <speed>
<loc>:<rem> Set the local and/or remote interface IP
addresses. Either one may be omitted.
asyncmap <n> Set the desired async map to hex <n>
auth Require authentication from peer
connect <p> Invoke shell command <p> to set up the serial line
crtscts Use hardware RTS/CTS flow control
defaultroute Add default route through interface
file <f> Take options from file <f>
modem Use modem control lines
mru <n> Set MRU value to <n> for negotiation
See pppd(8) for more options.
Right now, ppp dial-on-demand is down, so no ppp0 shows up in ifconfig
root@merlin:~# /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:C0:F0:37:C2:80
inet addr:192.168.11.1 Bcast:192.168.11.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7306 errors:38 dropped:0 overruns:0 frame:38
TX packets:57475 errors:0 dropped:0 overruns:0 carrier:0
collisions:847 txqueuelen:100
RX bytes:758130 (740.3 Kb) TX bytes:6155617 (5.8 Mb)
Interrupt:10 Base address:0x6000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6329 errors:0 dropped:0 overruns:0 frame:0
TX packets:6329 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3116710 (2.9 Mb) TX bytes:3116710 (2.9 Mb)
We try your trick of checking the returncode from ifconfig,
and find that ifconfig returns 1 when no PPP daemon is running
root@merlin:~# /sbin/ifconfig ppp0
ppp0: error fetching interface information: Device not found
root@merlin:~# echo $?
1
Now, I start up the ppp0 dial-on-demand daemon (by hand, although
I usually use the equivalent ppp-go script).
root@merlin:~# rm -f /var/LCK* /var/run/ppp*.pid
root@merlin:~# /usr/sbin/pppd file "/etc/ppp/options.demand" &
[1] 3333
Now, ifconfig shows that ppp0 is up, connecting local IP address 10.64.64.64
to remote IP address 10.10.10.10, and ifconfig returns a zero returncode.
root@merlin:~# /sbin/ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:10.64.64.64 P-t-P:10.10.10.10 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
root@merlin:~# echo $?
0
However,
1) My wife is using our one and only phone line at the moment, so
ppp0 *is not* connected to the internet. For that matter, chat
hasn't even picked up the phone, let alone tried to dial out.
2) Since ppp0 is not connected to the internet, neither the remote IP
address nor the local IP address reported are valid (they are both
placeholder addresses which will be discarded once I /do/ connect
to the internet.
So, let's see how JRH's script works (posted in message <3f45...@212.67.96.135> )
I cut'n'paste his script directly from his post into the terminal window and
execute it. I get...
root@merlin:~# EXTIF="ppp0" # external interface, may be empty
root@merlin:~# IFCONFIG=/sbin/ifconfig
root@merlin:~# AWK=/bin/awk
root@merlin:~#
root@merlin:~# # get the external IP address - it returns empty string if it is not up
root@merlin:~# if [ -n "$EXTIF" ]; then
> EXTIP="`$IFCONFIG $EXTIF 2>/dev/null | $AWK \
> /$EXTIF/'{next}//{split($0,a,":");split(a[2],a," ");print a[1];exit}'`"
> fi
root@merlin:~# echo " External IP: $EXTIP"
External IP: 10.64.64.64
Again, this is wrong. I'm *not* connected to the internet, and, while the IP
address reported is the placeholder address assigned by pppd, it is *not* the
IP address used by my dial-on-demand pppd.
So, neither your technique nor JRH's technique properly reports the state of
my system's internet connection.
Now, the technique that /I/ use is to have the /etc/ppp/ip-up script create
a sentinal file when pppd establishes it's IP connection to the internet, and
have the /etc/ppp/ip-down script delete the sentinal file. This way, external
processes can check for the existance of the sentinal and determine indirectly
the state of the internet connection.
Take a look at the manpage for pppd...
root@merlin:~# man pppd
PPPD(8) PPPD(8)
NAME
pppd - Point to Point Protocol daemon
SYNOPSIS
pppd [ tty_name ] [ speed ] [ options ]
DESCRIPTION
The Point-to-Point Protocol (PPP) provides a method for transmit-
ting datagrams over serial point-to-point links. PPP is composed
of three parts: a method for encapsulating datagrams over serial
links, an extensible Link Control Protocol (LCP), and a family of
Network Control Protocols (NCP) for establishing and configuring
different network-layer protocols.
[snip]
SCRIPTS
Pppd invokes scripts at various stages in its processing which
can be used to perform site-specific ancillary processing. These
scripts are usually shell scripts, but could be executable code
files instead. Pppd does not wait for the scripts to finish.
The scripts are executed as root (with the real and effective
user-id set to 0), so that they can do things such as update
routing tables or run privileged daemons. Be careful that the
contents of these scripts do not compromise your system's secu-
rity. Pppd runs the scripts with standard input, output and
error redirected to /dev/null, and with an environment that is
empty except for some environment variables that give information
about the link. The environment variables that pppd sets are:
[snip]
Pppd invokes the following scripts, if they exist. It is not an
error if they don't exist.
[snip]
/etc/ppp/ip-up
A program or script which is executed when the link is
available for sending and receiving IP packets (that is,
IPCP has come up). It is executed with the parameters
interface-name tty-device speed local-IP-address remote-
IP-address ipparam
/etc/ppp/ip-down
A program or script which is executed when the link is no
longer available for sending and receiving IP packets.
This script can be used for undoing the effects of the
/etc/ppp/ip-up script. It is invoked in the same manner
and with the same parameters as the ip-up script.
My /etc/ppp/ip-up script creates (or replaces) the /var/run/ppp0.ip file
when ppp0 comes up. The file contains the local IP address assigned by
my ISP, in textual form. This way, I can test for the existance of the
file to determine whether or not my internet connection is up, and /if/
it is up, I can determine the IP address without resorting to the
ifconfig/grep/awk awkwardness.
root@merlin:~# cat /etc/ppp/ip-up
#!/bin/sh
#
# ip-up interface-name tty-device speed local-IP remote-IP ipparm
# $1 $2 $3 $4 $5 $6
#
# (NB: ipparm is string from ipparm parameter in pppd options)
#
# This file /etc/ppp/ip-up is run by pppd when there's a
# successful ppp connection.
#
# The environment is cleared before executing this script
# so the path must be reset.
#
PATH=/usr/bin:/usr/sbin:/usr/local/bin:/sbin:/bin
export PATH
#
SCRIPT=`/usr/bin/basename $0`
#
echo $4 >/var/run/$1.ip
My /etc/ppp/ip-down script deletes the /var/run/ppp0.ip file, so that when I loose
my internet connection, the sentinal file disappears. Again, if an external process
looks for the file, and /does not/ find it, it can assume that /etc/ppp/ip-down
deleted it, and infer that the internet connection has been dropped.
root@merlin:~# cat /etc/ppp/ip-down
#!/bin/sh
#
# This script is run by pppd after the PPP connection is ended.
#
# ip-down interface-name tty-device speed local-IP remote-IP ipparm
# $1 $2 $3 $4 $5 $6
#
# (NB: ipparm is string from ipparm parameter in pppd options)
#
PATH=/usr/sbin:/sbin:/usr/bin:/usr/local/bin:/bin
export PATH
#
SCRIPT=`/usr/bin/basename $0`
#
rm /var/run/$1.ip
Finally, here's an example of a script that determines if my internet
connection is live or not.
root@merlin:~# cat is_ppp_up
#!/bin/bash
if [ -f /var/run/ppp0.ip ]
then
echo "Yes, PPP0 is UP with IP address " `cat /var/run/ppp0.ip`
exit 0
else
echo "No, PPP0 is DOWN"
exit 1
fi
When I run it while I'm "offline", I get
root@merlin:~# ./is_ppp_up
No, PPP0 is DOWN
However, if I do something that requires an internet connection
(like try to browse http://slashdot.net/ under Mozilla), I get
root@merlin:~# ./is_ppp_up
Yes, PPP0 is UP with IP address 64.228.63.114
If I try the ifconfig returncode trick, I get the same results as when my internet
connection is down.
root@merlin:~# /sbin/ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:64.228.63.114 P-t-P:64.228.63.241 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:100 errors:1 dropped:0 overruns:0 frame:0
TX packets:105 errors:0 dropped:10 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:49724 (48.5 Kb) TX bytes:9794 (9.5 Kb)
root@merlin:~# echo $?
0
If I try JRH's script, I get marginally different results from when my internet
connection was down. At least this time JRH's script properly reports my IP address.
root@merlin:~# EXTIF="ppp0" # external interface, may be empty
root@merlin:~# IFCONFIG=/sbin/ifconfig
root@merlin:~# AWK=/bin/awk
root@merlin:~#
root@merlin:~# # get the external IP address - it returns empty string if it is not up
root@merlin:~# if [ -n "$EXTIF" ]; then
> EXTIP="`$IFCONFIG $EXTIF 2>/dev/null | $AWK \
> /$EXTIF/'{next}//{split($0,a,":");split(a[2],a," ");print a[1];exit}'`"
> fi
root@merlin:~# echo " External IP: $EXTIP"
External IP: 64.228.63.114
And if I try it again after my internet connection comes down ("idle time out"),
I get /the same/ results. It appears that JRH's script thinks that my internet
connection is still up.
root@merlin:~# ./is_ppp_up
No, PPP0 is DOWN
root@merlin:~# EXTIF="ppp0" # external interface, may be empty
root@merlin:~# IFCONFIG=/sbin/ifconfig
root@merlin:~# AWK=/bin/awk
root@merlin:~#
root@merlin:~# # get the external IP address - it returns empty string if it is not up
root@merlin:~# if [ -n "$EXTIF" ]; then
> EXTIP="`$IFCONFIG $EXTIF 2>/dev/null | $AWK \
> /$EXTIF/'{next}//{split($0,a,":");split(a[2],a," ");print a[1];exit}'`"
> fi
root@merlin:~# echo " External IP: $EXTIP"
External IP: 64.228.63.114
root@merlin:~#
In all, ifconfig is not reliable in determining whether pppd has an internet
connection or not. The only reliable way so far seems to be to get the info
directly from pppd through one of it's exits (like /etc/ppp/ip-up).
--
Lew Pitcher
Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
Alan Connor
Lew, I did not read your post, and will not.
I killfiled you, and the fact that you have altered your headers to
beat my killfile PROVES that you are an asshole and a troll.
Only an arrogant creep would even consider trying to force someone to
listen to them if this was against their wishes.
I am never reading another one of your posts.
That's a fact.
Now kiss my ass and take a REAL long hike.
And so it is done.
Alan C
JRH
I hope this works for you, and continues to work. Until recently I used a
similar technique in my ip-up.local script to check the accessibility of
certain other sites, but about a week ago it stopped working. It appears my
ISP (onetel) now blocks ALL outgoing pings. At about the same time it
appears demon started ignoring incoming pings.
If this is prevalent it is going to make testing network setups that bit
harder!
SPAM_FREE
Gabriel Michael wrote:Floyd Davidson <fl...@barrow.com> wrote in message news:<87n0e5y...@barrow.com>...Read the man page for ping. #!/bin/sh if ping -qnw1 -c1 ip_address 2>&1 >/dev/null then echo "Link is up" else echo "Link is down" fiThanks, this is exactly what I needed. The ppp link is for a VPN, so it's not bad etiquette for me to incessantly pinging the other end ;-)I hope this works for you, and continues to work. Until recently I used a similar technique in my ip-up.local script to check the accessibility of certain other sites, but about a week ago it stopped working. It appears my ISP (onetel) now blocks ALL outgoing pings. At about the same time it appears demon started ignoring incoming pings. If this is prevalent it is going to make testing network setups that bit harder! ...John
because of th latest winblows virus.
SPAM_FREE
because of the latest winblows virus.How about this .... telnet a web page and test for success
echo | telnet google.com 80 2> /dev/null > /dev/null
if [ $? = 1 ]
then
echo sucess
fi
Lew Pitcher
In fact, I posted the article last night from my home system.
Since I don't use ppp at work (don't have a modem, and don't even have
pppd installed), it would have been impossible to perform the real-world
test that I needed. Instead of attempting to fudge the results and post
through my employers account (lew.p...@td.com), I did the proper
testing on my home lan (my firewall/NAT/dial-on-demand server,
actually), and posted the results through my personal account
(lpit...@sympatico.ca).
In any case, the results show that the ifconfig returncode is not a
reliable indicator of whether or not the ppp connection has been
established with the ISP, let alone a reliable indication that the PPP
connection is "live" to the internet.
[snip]
Lew Pitcher
>
> welcome to my killfile, fool.
There are none so deaf as those who would not hear.
Too bad you've decided to stop learning.
Time to move on.
Lew Pitcher
detection. I await his refutation or explanation of the results I posted
previously wrt the effectiveness of ifconfig vs /etc/ppp/ip-up in
determining ppp link state.
We shall see if a rational discussion can be conducted, or if it degrades
into namecalling and other verbal abuse.
Alan Connor
I never said that it worked on all machines, I said it worked on MINE.
THAT was the discussion you jumped into: People were telling me that the
script didn't work on my machine when I knew it did.
The fact that you could prove it didn't work on other machines was IRRELEVANT
to that part of the discussion. This had already been clearly established
and left behind.
I THOUGHT you were another one of the people that were telling me that
script didn't work on my machine.
THAT was my mistake.
So I apologize for mistaking you for one of those people and giving you
what I gave them.
They deserved it and you didn't.
I'm sorry.
Alan C
--
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
David Efflandt
> detection. I await his refutation or explanation of the results I posted
> previously wrt the effectiveness of ifconfig vs /etc/ppp/ip-up in
> determining ppp link state.
>
> We shall see if a rational discussion can be conducted, or if it degrades
> into namecalling and other verbal abuse.
Maybe some definitions are in order. "up" from the standpoint of ifconfig
only means that an interface is ready to accept traffic.
For a manual (non-demand) pppd connection, it would only be up when
connection was established and would go down when connection was lost.
For a demand pppd connection, ifconfig would show it up when ready to
accept traffic, but has no indication of the state of the ppp link
(whether connected due to demand, or disconnected due to idle timeout).
The only reason testing this with ifconfig would work (per earlier posted
script example) is because it would trigger the connection if it was not
already established.
If the intent is to only do something while a demand pppd link is active,
and NOT trigger it when disconnected, I do not see how ifconfig could be
used for that, because it has no option or visual indication of demand
pppd link status (up does not necessarily mean connected, just ready to
accept traffic).
--
David Efflandt - All spam ignored http://www.de-srv.com/
http://www.autox.chicago.il.us/ http://www.berniesfloral.net/
http://cgi-help.virtualave.net/ http://hammer.prohosting.com/~cgi-wiz/
Alan Connor
>
>
> On Fri, 12 Sep 2003 15:25:25 -0400, Lew Pitcher <Lew.P...@td.com> wrote:
>> I have invited Alan Connor to resume the discussion on PPP link state
>> detection. I await his refutation or explanation of the results I posted
>> previously wrt the effectiveness of ifconfig vs /etc/ppp/ip-up in
>> determining ppp link state.
>>
>> We shall see if a rational discussion can be conducted, or if it degrades
>> into namecalling and other verbal abuse.
>
> Maybe some definitions are in order. "up" from the standpoint of ifconfig
> only means that an interface is ready to accept traffic.
>
> For a manual (non-demand) pppd connection, it would only be up when
> connection was established and would go down when connection was lost.
>
> For a demand pppd connection, ifconfig would show it up when ready to
> accept traffic, but has no indication of the state of the ppp link
> (whether connected due to demand, or disconnected due to idle timeout).
> The only reason testing this with ifconfig would work (per earlier posted
> script example) is because it would trigger the connection if it was not
> already established.
>
> If the intent is to only do something while a demand pppd link is active,
> and NOT trigger it when disconnected, I do not see how ifconfig could be
> used for that, because it has no option or visual indication of demand
> pppd link status (up does not necessarily mean connected, just ready to
> accept traffic).
>
Fortunately, neither my machine nor I care what you or anyone else can "see".
The script works flawlessly. Never an error message from SLRN, which is
not shy with them.
It connects to the internet, fetches news (or sends news, depending on which
script it is) and disconnects from the internet.
Perfectly. Silently. Over and over and over.
> --
> David Efflandt - All spam ignored http://www.de-srv.com/
> http://www.autox.chicago.il.us/ http://www.berniesfloral.net/
> http://cgi-help.virtualave.net/ http://hammer.prohosting.com/~cgi-wiz/
A sensible person trusts their experience over the mere words of ANYONE.
Lew Pitcher
[snip]
> I never said that it worked on all machines, I said it worked on MINE.
Understood. And I apologize if any of my posts appeared to contradict you in
this regard.
[snip]
So, let's forget the conflict, and move on.
Answer me this...
Given that ifconfig clearly /does/ answer the question "is pppd up?" but
doesn't answer the question "what is the state of my ppp connection to my
ISP", how would you suggest we clarify the state of a (generic) ppp
connection. I think that there is a problem here, and that some solution is
necessary. Specifically, newbies and general users don't care for the
technical explanations; they want an answer to their question of whether ppp
is up or not.
However, their question itself is ambigious, and no amount of explanation will
help them. They don't care if pppd is running or not or that the ppp0
interface is or is not defined, or even whether or not IPCP has or has not
assigned them an IP address; they only care if they have IP connectivity to
their ISP or not. So answers that involve checking for pppd's PID, or ppp0's
existance, or even the execution of /etc/ppp/ip-up are not answers for them.
Such techniques only serve to confuse the issue because two techniques can
give radically different or incorrect answers.
The /etc/ppp/ip-up technique fails when the files it creates are deleted by
outside sources. The ifconfig technique fails when pppd is run in demand-dial
mode, or IPCP negotiation fails. I've been thinking about a combination of
both the ifconfig returncode technique and the /etc/ppp/ip-up technique, but I
can't quite make it work yet.
Do you have any suggestions? You've seen my scripts; can they be made to give
a complete answer, or should we start fresh? I believe that the example
is_ppp_up script, combined with ifconfig can give a 90% solution, but I'm not
in a position to test it outside of a demand-dial configuration.
Lew Pitcher
> On Fri, 12 Sep 2003 15:25:25 -0400, Lew Pitcher <Lew.P...@td.com> wrote:
>
>>I have invited Alan Connor to resume the discussion on PPP link state
>>detection. I await his refutation or explanation of the results I posted
>>previously wrt the effectiveness of ifconfig vs /etc/ppp/ip-up in
>>determining ppp link state.
>>
>>We shall see if a rational discussion can be conducted, or if it degrades
>>into namecalling and other verbal abuse.
>
>
> Maybe some definitions are in order. "up" from the standpoint of ifconfig
> only means that an interface is ready to accept traffic.
>
> For a manual (non-demand) pppd connection, it would only be up when
> connection was established and would go down when connection was lost.
Even if ifconfig shows the existance of ppp0, if IPCP negotiation fails, the
interface is demonstrably /not/ ready to accept or serve IP traffic. Even in a
non-demand situation, ifconfig alone cannot give an unambigious answer to the
question.
> For a demand pppd connection, ifconfig would show it up when ready to
> accept traffic, but has no indication of the state of the ppp link
> (whether connected due to demand, or disconnected due to idle timeout).
> The only reason testing this with ifconfig would work (per earlier posted
> script example) is because it would trigger the connection if it was not
> already established.
>
> If the intent is to only do something while a demand pppd link is active,
> and NOT trigger it when disconnected, I do not see how ifconfig could be
> used for that, because it has no option or visual indication of demand
> pppd link status (up does not necessarily mean connected, just ready to
> accept traffic).
As I said in another post, most who ask the question "how can I tell when ppp
is up?" don't see the fine distinction of "the interface is up, but can't
accept traffic", and want an answer of "No, you can't get on the internet" or
"Yes, you can get on the internet".
Given that /etc/ppp/ip-up can only really write sentinal files, and those
files can be deleted or corrupted outside of the ppp process, you can't trust
the external results of the ip-up script (even though you can trust the ip-up
script itself).
Given that ifconfig does not make a distinction between "up but not connected"
and "up and connected" in a demand-dial environment (or even a manual
invocation, when IPCP negotiation fails), you can't trust the results of
ifconfig to answer the question either.
Is there a third option? What about a combination of the two techniques?
Inquiring minds want to know ;-)
BTW...
Welcome back Alan. It's good to have you back at the table.
Lew Pitcher
[snip]
> So I apologize for mistaking you for one of those people and giving you
> what I gave them.
Apology accepted.
Incedent forgotten.
Let's move on. <grin>
Alan Connor
Many thanks, Lew.
Would hate to lose your guidance through the labyrinth of *[Nn]*[Xx].