0

I'm working on a raspberry project with a RPi B+, running Debian stretch. I've included a LED which should turn on when the Pi establishes an internet connection, and should turn off when this connection is lost. To do this, I have written a small python script which checks the connection in increasing time-intervals. To test connectivity I'm using this function:

def test_internet(timeout = 5):
    try:
        urlopen('http://www.google.com/',timeout =timeout)
        return True
    except:
        return False

After each check the program sleeps for a fixed time (5 seconds), and then re-checks. Every check is logged to a log-file.

The loop works fine when testing on my computer. I've tested with the RPi by starting the loop, and after a few positive returns, plug-out the ethernet cable. I expected the log to keep recording entries every 5 seconds, although now stating 'False', and turning the LED off.

Unfortunately, whenever I unplug the ehthernet cable, the log shows the test_internet is initiated, but then hangs untill I replug the cable. If I wait really long (like a full minute), it does record a 'False' and turn off the LED. In that case, re-inserting the cable brings the LED back up within a few secs, so no delays there.

It seems like the script is somehow freezing when connectivity drops. Is that possible? How could I circumvent this?

EDIT I've created a simple check bash script which sleeps for five seconds after execution (giving me time to unplug the ethernet cable) and then checks for connectivity. If there's no interwebs, it turns off the LED:

#!/bin/bash
sleep 5
if [ ! -d /sys/class/gpio/gpio27 ]
    then
        echo "27" > /sys/class/gpio/export
        sleep 0.1;
    fi
echo "out" > /sys/class/gpio/gpio27/direction

wget -q --spider http://google.com

if [ $? -eq 0 ]; then
    echo "Online"
    #Turn on connectivity LED
    echo "1" > /sys/class/gpio/gpio27/value

else
    echo "Offline"
    #Turn off connectivity LED
    echo "0" > /sys/class/gpio/gpio27/value

fi

If I run this and unplug the cable, after 5s the LED is turned off. However if I replug it, the LED jumps back on, and the terminal prints 'online'. Seems like it repeats the code when it comes back online. Seems like the plugging/unplugging does something to the Pi, cluttering the view.

  • I'm guessing that the DNS lookup for www.google.com is taking a minute to timeout. That is probably not limited by the urlopen timeout parameter. – Craig Dec 28 '18 at 20:20
  • If I test the same script on my macbook though, test_internet starts returning negatives as soon as I disconnect form wifi. Is it possible DNS lookup takes much longer from RPi than from a laptop? And if so, could I save time by using direct IPs instead of domain names? – Kaz Vermeer Jan 2 at 17:29
  • Also, if I ssh to my RPi using a local network (without internet connectivity) and run test_internet on the RPI, it returns a 'false' immediately, no delays. So it seems the delay does not stem from test_internet. – Kaz Vermeer Jan 3 at 14:15
1

It seems the timeout setting of your urlopen() does not work. So it tries to connect and stuck if a connection isn't possible. Only the long period of the default system timeout is working, so the function returns only after this long time.

To examine the situation I have made a small test program. For me it is unclear what python version you are using. I only use python 3. This is my test program test.py:

import sys, urllib.request

try:
    resp = urllib.request.urlopen(sys.argv[1], timeout=float(sys.argv[2]))
    print("url opened")

except Exception as exc:
    print(exc)

Here are some executions with ethernet cable plugged in:

rpi ~$ python3 test.py "http://google.com" 5
url opened

rpi ~$ python3 test.py "http://google.com" 0.1
url opened

rpi ~$ python3 test.py "http://google.com" 0.05
timed out

rpi ~$ python3 test.py "http://xxx" 5
<urlopen error [Errno -5] No address associated with hostname>

rpi ~$ host -t A google.com
google.com has address 172.217.16.206
rpi ~$ python3 test.py "http://172.217.16.206" 0.1
url opened

Here are some executions with ethernet cable plugged out:

rpi ~$ python3 test.py "http://google.com" 5
<urlopen error [Errno -3] Temporary failure in name resolution>

rpi ~$ python3 test.py "http://google.com" 0.05
<urlopen error [Errno -3] Temporary failure in name resolution>

rpi ~$ python3 test.py "http://172.217.16.206" 5
<urlopen error [Errno 101] Network is unreachable>

As you can see with an unplugged ethernet cable you never get a timeout error. Instead you get an immediate response with a message.

I cannot test your bash script but my interpretation of it is this: the initialisation of gpio27 always turns it off, no matter if the ethernet cable is plugged in or not. After 5s the LED gets always off. If wget has a connection then the LED is immediately turned on again. Maybe you see a flicker? With unplugged cable wget stuck until you plug in the cable. Then LED turns on. I suppose you never reach the false branch. Do you ever see it printing Offline? There is no mystic reexecution ;-)

If not already done you should use python version 3.

  • Thanks for the effort! If you say 'With unplugged cable wget stuck until you plug in the cable' - that's the issue right? Why is it getting stuck instead of returning an error? Anyway, I've changed the script I used to only download the head using the requests.head, which turns out to be a lot quicker. Not sure why, but that seems to solve the issue... – Kaz Vermeer Jan 4 at 8:51
  • @KazVermeer As said I haven't tested the bash script. It was only an assumption that explains the behavior. Because you have found a solution I would say it isn't worth to invest more effort. If my answer helped you to find a solution it would be nice if you could accept the answer by clicking the tick on the left side. This will finish the question and show other users that it has a solution. – Ingo Jan 4 at 9:54

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.