Fighting with computers

Computers are not always friendly.

Saturday, November 19, 2016

Reaching your Pi over your network

There are multiple ways of learning what is the IP address your Raspberry Pi is obtaining from a
router. The most obvious one is to use the router's DHCP client list. Another one is to use a HDMI display as your RPi will report its IP address while booting.

The former requires administrative access to the router, which may not be possible on certain networks and the latter is only possible if you can connect the display to the RPi and you have a display available. What I am going to propose requires no special rights over the network gear not any additional hardware.

One of the things you can do over a network is to broadcast a message (in fact this is the foundation of the DHCP protocol for a computer to find a suitable DHCP sever over the network without previous knowledge of it). Sending a UDP broadcast message allows any other system on the network to hear it. And if that message is received each receiver knows immediately the sender's IP address.

So here is what I do to perform this periodic broadcast from the RPi


from socket import * 
from time import sleep

s=socket(AF_INET, SOCK_DGRAM)
s.setsockopt(SOL_SOCKET, SO_BROADCAST, 1)
while (1) :
    s.sendto("Hello\n", ("255.255.255.255",25555))
    sleep(2)
Any computer on the network can tell the IP address of the sender of this special message so it will effectively learn about it. I tried to use the netcat command but while it works it fails to shown the sender's address so I used tcpdump instead.

sudo tcpdump -i en0 port 25555
That did it for me. Once I learn my RPi address on a network I can go ahead and ssh to it for any maintenance task I want. My main interest here is for nodes that are installed on networks different than my home network.

Tuesday, November 01, 2016

First experience with RPi3

I am working on a project that required some computing power and commanding an Arduino UNO running GRBL. Things have changed quite a bit from
original plan, so because radio reception was awful, the original plan of using dump1090 with a USB dongle had to be ditched. Of course I only learned that once I have it working nicely on the Raspberry Pi 3.

Plan B would be to use the Ethernet network interface. Once that was working we realized it was not possible on our target installation.

Plan C was to use wifi. And while it is really simple to get it working with stock Jesse, I found a way to waste my time when I added spaces in between variables and equal signs in /etc/wpa_supplicant/wpa_supplicant.conf. So now you have been warned.

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

iface eth0 inet manual

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp 
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
#------------ wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
 ssid="mynet"
 psk="mypass"
}


Once wifi connection was working and the rest of the project code was up and running I wanted to have it all to autostart. However, I always like to be able to peek into each program to see how that is going on.

If I had chosen to start each program off /etc/rc.local I had the problem that I won't be able to see what is going on with the terminal output of each program unless I redirect its output to a file, but that usually uses up disk space and eventually needs to be deleted and wears the flash memory.

Instead, I decided to use screen command to launch each program. And, as usual, it did not work at first try. Several things are slightly different there than from bash command line:

  • root user in the one running the show there, if you launch something it will be under that user (unless you do something about it)
  • commands and files locations need to be specified carefully, as there is no $PATH value to rely on.
  • you can always use su - username -c "command" to launch a program under other user credentials
  • any program you launch here needs to end quickly as you are delaying the boot process, if you need to launch a long program it has to be on the background (use &)
Once I understood all these points I was able to launch my commands using lines like this:
  • su - pi -c "/usr/bin/screen -d -m /home/pi/mycommand" 
And while you do not see the & at the end of the line, it is the -d parameter of screen what takes care of running it as a daemon process and not blocking the script flow. 

The good thing is that later, I can log into the RPi3 and use screen -r to connect to the virtual terminal each program is running on, to see if the output is right and everything is working as expected or not. It really works well for me.