Setting up a Remote Station – Part 6 Remote Access

In this post I am going to discuss the need for a local Windows PC and considerations for remote access.

Local Windows PC

I allowed for a local Windows PC in the original spec, but I was hoping to not need it. However, after watching Mike, VA3MW’s YouTube video on his remote station, I changed my mind. Mike’s arguments in favour were:

  1. running Ham-related software locally reduces Internet traffic and latency; and,
  2. having everything local opens up the potential for others to access and use the station with minimal trouble

So, I stumped up for a Mini IT8 from Geekom. This is a micro-PB with an Intel i5, 16GB RAM and 512GB SSD. More than enough for my needs. It runs Windows 11 (unfortunately), but I’m gradually getting used to its foibles.

So far I’ve installed:

The PC is logged into my Microsoft account so the OneDrive replicates to my home QTH.

I’ll access the remote PC over Microsoft’s Remote Desktop client – remembering to play audio on the remote server and not back on the home station.

It’s worth noting that I’m only proposing to use the remote installation of SmartSDR for digital modes. For voice modes and CW I’ll use SmartSDR on my home Mac and use FlexLink to access the Remote Station.

Remote Access

Given that I am designing a Remote Station, access to the Remote Station is a major aspect of the design. The primary requirement is for remote access from my home QTH, but I also want access when I am on the road.

Normally, this would be relatively easy to achieve because the RUT951 would be directly connected to the Internet and I could either open ports or set up a VPN gateway.

In my case though, it is hoped that the Remote Station will be connected to the host’s LAN (as it is at home on the bench), in which case there is an additional router/firewall in the path to the Internet. I cannot assume that I have any potential to control this host-LAN router, so I cannot forward ports or use something like UPnP.

So, what I am doing is to have the RUT951 establish a VPN back to my home network. That way:

  1. I don’t need to worry about the public IP address of the remote station; and,
  2. once the VPN is established, I have full access to the remote station’s LAN

My Home LAN already has a OpenVPN gateway to allow me remote access to the LAN when I am on the road. Hopefully, with this arrangement I can VPN into the Home LAN and also get access to the Remote LAN. We’ll have to see what effect this has on audio latency etc.

Implementation

At the Server end

  • The home QTH OpenVPN server is reachable from the Internet.
  • The Home QTH LAN is 172.29.12.0/24
  • The VPN Server’s Home QTH LAN IP is 172.29.12.11
  • The VPN uses 10.8.0.0/24
  • The VPN server uses the following server.conf (relevant content only)
dev tun 
topology subnet 
server 10.8.0.0 255.255.255.0 
push "dhcp-option DNS 172.29.12.1" 
route 10.29.5.0 255.255.255.0 
push "route 172.29.12.0 255.255.255.0"
push "route 0.0.0.0 0.0.0.0" 
client-to-client
  • The Home QTH’s router has a static route to 10.29.5.0/24 using the gateway 172.29.12.11

At the Remote Station

  • The LAN has the address space 10.29.5.0/24
  • The RUT951 is 10.29.5.1
  • Once connected to the VPN, the RUT is also 10.8.0.5

With this config, the remote LAN is reachable from the Home LAN and vice-versa.

Setting up a Remote Station – Part 5 Setup continued

Rather than continually editing part 4, I’ve decided to move to separate posts.

A lot has happened since I last posted and a lot of progress has been made. I’m nearly at the point where I am ready to start testing the system in the home shack.

From my log:

  • I’ve realised that the Shelly 2.5 Wifi Switch won’t work after all. It needs to be powered by at least 30V DC and the two relays have one side connected to the 0V line. I need them to be independent. I’ll probably implement a couple of switched outputs using the GPIO lines on the Pi.

  • I configured the OpenVPN client on the router to connect to my home’s OpenVPN server.

  • I put a SIM card in the router and set up the failover rules so that the failover order is:

    • My Home LAN (will be changed to the Host LAN at the final location)
    • Any WAN connection that might be plugged in
    • 4G modem
  • This works, though I had to change the process by which the router detects the need to failover, and then "fail-back". The router detects the need to failover by pinging an address periodically. I set a different target for each interface.

  • The VPN connects OK, but I can’t route traffic.

    • I needed to "push" a route to the home LAN to the OpenVPN client, and add static routing statements to the home LAN’s router.
    • I also needed to add additional firewall rules on the OpenVPN server

I now had a major brain fade and managed to screw up the configuration of the Pi, so I needed to start again from scratch. Thank heavens for ansible and the fact that Home Assistant takes regular back-ups.

  • I set up an Home Assistant automation to detect when the UPs went on to battery and use this to kick off the automation that shuts the radio (if it’s on)
  • With this in place, and knowing I’d be away for a few days, I decided to see how long the UPS would power the system and whether it would recover atomically when the power returns. I disconnected the mains and went away
  • When I came back, everything had functioned correctly and the UPS had enough energy to power the system for 5h30m. More than enough.

Still to do

  • Sort out the relay switching for the radio power
  • Finalise the Node-Red dashboard
  • Add temperature/humidity sensors for inside and outside the cabinet
  • Install a Real Time Clock on the Pi

Setting up a Remote Station – Part 4 Build Log

Updated: 20/3

This post will document the process of putting together all the elements of the remote station “on the bench” in the shack. I’ll update this as it goes, and hopefully put up some pictures as well.

Day One

The router, pi and UPS have arrived, so I’ve made a start.

  • Configure the router
    • Connected my laptop to one of the LAN ports and logged in as admin
    • Changed the admin password
    • Set up the LAN Wi-Fi and address range. It needed to be changed because the default 192.168.1.0/24 would clash with one of my internal networks.
    • Enabled https management access from the WAN
    • Connected the WAN to my home Wi-Fi and checked I could log in from the WAN, enabling me to disconnect from the router’s LAN
    • Check that the router can reach the internet and install the NTP server package to be the local time server for those occasions when the WAN is either disconnected or using 4G as I want to minimise unecessary network traffic.
  • Build the Pi
    • Downloaded the aarch64 Debian 11 image and copied it to the SSD
    • Connected keyboard, mouse and monitor to the Pi and booted it for the first time.
    • Connected it to the house WiFi, and used ‘nmcli’ to set a static address.
  • I then configured a firewall rule on the router to allow ‘ssh’ traffic to the Pi.
  • Configured the Pi
    • I use Ansible and Debops to manage the configuration of the various computers at chez M5KVK, so I ran the bootstrap playbook to:
      • update the system software
      • create some users on the Pi,
      • set up their “.ssh/authorized_keys”
      • give them “sudo” privilege
      • install a bunch of packages
    • After this, I could log in remotely to the Pi as ‘pi’
  • Install Docker, ‘os-agent’ and Home Assistant using the Supervised Installer

Day Two

  • Installed the Home Assistant addons and adjusted configuration.yaml to use Mosquito Broker, MariaDb and InfluxDb.
  • Installed the Node-Red addon
  • Installed system_sensors as a service
    • I noted that this had been created on the assumption that the operating system was Raspbian. Debian does not have the hooks to monitor the power supply, so that sensor is dead.
    • I also need to run the service as ‘root’ rather than ‘pi’

Day Three

  • The Tapo plugs have arrived, so I installed the Tapo Controller integration. For this I needed to install HACS.
  • I setup the Tapo plugs using the Tapo iOS app, connected them to the router’s WiFi, made a note of their IP addresses and added the two plugs to the Home Assistant Tapo Controller integration.

Day Four

I added the APC UPS integration to get better feedback and form the basis for the automation that shuts the radio down if the mains power fails. After reading some of the Flex documentation I realised that I needed to sequence the power to the radio. Basically, I need three “switches”

  1. To control the mains to the power supply.
  2. To control the 12V supply from the power supply to the Flex
  3. To remotely control the Flex power itself.

So, I’ve ordered a Shelly 2.5PM WiFi Relay Switch with two relays that can be controlled by Home Assistant. One will control another 12V 30A relay in the 12V feed from the power supply. The other will be connected to the Flex’s remote control port. The sequence will be:

  • Initial state, all switches OFF
  • On user command:
    • Switch on mains power and wait 2s
    • Switch on 12V and wait 2s
    • Switch on Flex
  • On user command or UPS going to battery
    • Switch off Flex and wait 30s for it to shutdown safely
    • Switch off 12v and wait 2s
    • Switch off mains power.

Setting up a Remote Station – Part 2 System Design and Components

Part 1 of this series covered the motivation behind this project and the requirements I set. This part will outline the system design and the components I’ve chosen.

System Design

Design Philosophy

The objective is to create a self-contained and secure environment that delivers the required functionality, looks after itself as much as possible, reports its status back to base and is fully remotely controlled. The desired location for the remote station is somewhere that already has Internet access and has a Wireless LAN that we can connect to. This avoids the need to rely on 4G access, but this will also be provided as a failover option.

I’ve chosen to deliver this using readily available components and base the control system on Home Assistant. Home Assistant is open-source software that can be used to monitor and automate just about all aspects of your home. It has a vast catalogue of supported devices and services and I’ve been using it for some years to add some smarts to my home.

I’m running Home Assistant on a Raspberry Pi 4 housed in the Argon One metal enclosure from Argon 40 with its companion M2 SSD to improve performance and reliability. I can’t speak highly enough for this enclosure. Not only is beautiful to look at, it has significant passive cooling plus a variable-speed fan. Having the SSD significantly improves the usability of the Pi – especially with the M2 SSD.

The Remote Station

  • Router with 4G modem and ability to join a host WiFi (if one is available)
  • UPS
  • Remote controlled mains switches for the Windows PC (if needed), and the Radio Power Supply
  • Raspberry Pi computer running Debian 11 (not Raspbian) and Home Assistant
  • Flex 6400 HF radio
  • Remote On/Off control system for Flex

The Home Station

  • Windows PC running SmartSDR
  • Microphone
  • Key
  • Other ham-related software such as VarAC

Component selection

Router

I’ve chosen to use the Teltonika RUT951 industrial router. I already have one of these installed in my motorhome and it’s excellent. It isn’t cheap, but it is perfect for this job. It delivers:

  • 4G dual MIMO WAN access with support for two SIM cards,
  • Ability to connect to an external Wireless LAN as a WAN
  • Automatic failover between the various WAN connections
  • Internal Wired and Wireless LANs with 3 physical ports
  • VLAN capability (not used in this project)
  • Digital I/O, Modbus support and MQTT
  • VPN server and client
  • Remote management (not used)

UPS

I’m not looking to power the radio for any great time in the absence of mains power, but I do want to be able to shutdown in an orderly fashion. I’ve opted for the APC BackUPS 650. This provides 650VA capacity, six protected outlets, plus two surge-protected only outlets.

The following devices are connected:

  • 5V 3A PSU for the Raspberry Pi Station Control Computer (SCC)
  • 9V 1A PSU for RUT951 Router
  • Tapo P110 remote controlled sockets for the Radio PSU and optional Windows computer
  • Raspberry Pi Station Control Computer running Home Assistant

I have a lot of experience with the Pi and with Home Assistant, so this combination was a natural choice. I’ll cover the Home Assistant configuration in another post.

Radio PSU

To give me the potential to maybe operate off-grid, I’ve chosen the MyDel PS-1335 12V 30AMP PSU with battery backup capability to give a 30A UPS. The MyDEL is an unknown quantity to me. It has a good spec and is supposed to have very low noise. We’ll have to see. Just in case it proves to be unsuitable for any reason, I have another 30A PSU I can use instead.

Flex-6400 Radio

Originally, I intended using my Elecraft K3S in the remote station and using something like RemoteHams to control it. After playing with RemoteHams, I felt that there was something missing. Also, there is the issue of power control on the K3S. You can remotely command the radio to power off, but you can’t power it on remotely. This needs to be done by toggling a control pin – not a problem, but an added complexity.

For a while now, I’ve been looking at the FlexRadio range, and realised that the 6400 is ideal for this application: after all, it’s designed to be operated remotely. I went for the straight 6400 rather than the 6400M. The one I have does not have an ATU. If the proof of concept works, I’ll add the ATU module.

I’ll cover the software and the detail of controlling the power to the 6400 in a separate post.

PiDashCam part four – Beta code released

Part four of the series on my development of a Raspberry Pi based dashcam. See this post for part one, this post for part two and this post for part three.

It’s been a while since I posted, but the holidays got in the way. Anyhow, progress has been made and I am now in the beta testing phase. I have working code, which can be found on github, and the python module can be found in pypi by searching for ‘pidashcam’.

The next stage is to get the breadboard dashcam into my car and see whether it works in the real world: so far it’s been sitting on my bench taking videos of pretty much nothing; and with no movement.

I also need to noodle more on how I am going to package this thing.

PiDashCam part two – Hardware, Software Overview and Pseudo Code

Part 2 of the series on my development of a Raspberry Pi based dashcam. See this post for part 1
Photo of PiDashCam breadboard

Although I’ve only just posted part 1 I’ve actually made quite a lot of progress towards achieving the objectives (as outlined in part 1.) In this post, I’ll look at the hardware I’ve chosen and show the Software Overview and Pseudo Code for pidashcam daemon

Breadboard Hardware

The picture at the top shows the basic hardware sitting on a breadboard for development.

  • Raspberry Pi 3 with the UPS Pico HAT sitting on top (including 450mAh battery)
  • Breadboard with Adafruit Ultimate GPS (including external antenna because I’m indoors) and the two buttons.
    I haven’t got the LEDs on yet.

The one addition is the HDMI Camera Extender I purchased from Tindie. This will allow me to have the camera mounted up near the top of the screen but have the main unit down on the dashboard somewhere: maybe down behind the gear change on my Golf Cabriolet.

PiDashCam Code Overview

The code comprises an installed system daemon with three threads:
1. Main thread
3. Camera thread
4. GPS thread

There are interrupt routines to handle the two buttons and there are several Events to manage signalling between the threads.

Pseudo Code

Subject to change – I’ll come back and revise this as development progresses

Button A interrupt handler (flush video)
  Wait for ExtraTime seconds
  set the flushBuffer event

Button B interrupt handler (stop recording)
  If recording
    Wait for ExtraTime seconds
    set the flushBuffer event
    wait for 
    reset the recording event
  Else
    Set the recording event
  EndIf

Camera thread
   Do until shutDown
      If recording
         Initialise Camera
         While recording
            start recording into buffer
            If flushBuffer
               flush buffer to new file
                  If shutdown is set
                     reset recording event
            Else
               update annotation with current date-time, position and speed
            EndIf
            wait for 0.2 seconds
         EndWhile
      EndIf
      wait for 1 second
   EndDo
   END

GPS Thread
    Initialise connection to gpsd
    Do until shutDown
        update current GPS info
    EndDo
    END

Power failure
  wait for ExtraTime seconds
  set flushBuffer
  set shutdown

Main thread
  Kick off Camera thread
  Kick off GPS thread
  reset the flush video flag
  reset the shutdown flag
  set the record flag
  while not shutdown
      wait for 1 second
  while LAN is connected and there are videos in the sync folder
      wait for 1 second
  Kill threads
  initiate system shutdown
  exit

PiDashCam – Raspberry Pi based dashcam – Part One

This is the first in a series of posts about developing a Raspberry Pi based dashboard camera (dashcam) for my own personal use. I’m also using the project to improve my Python coding skills and re-use a whole load of software engineering patterns I used to deploy when I was a software engineer yonks ago.

Motivation

Like many regular drivers, I see a lot of strange behaviour when I’m out on the roads and I often comment to myself that it would be interesting to have something on video. The lady who zoomed past me on the M25 busily touching up her eye makeup; the van driver who had his morning paper spread out across the steering wheel, the lunatic in the BMW who cut across three lanes on the M1 to avoid missing his exit and precipitated a multi-car shunt: the list goes on.

I have been meaning to buy a dashcam that would allow me to capture these delights on video.
However, rather than just shell out for a commercial dashcam, I decided to make one for myself and to my own specification.

Requirements

These are the requirements I used to drive the system design

  • Single forward facing camera with option for second rearward facing camera
  • Built using Raspberry Pi and programmed in Python
  • Should continue recording even if power has failed (e.g. in an accident)
  • Record HD MPEG format videos continuously but avoid running out of disk space
  • Simple UI to record a notable event and pause/resume recording
  • Video overlaid with Date, Time, Position, Speed and Direction
  • Automatic transfer of recorded video to home Mac when in range of home Wi-Fi
  • to avoid need to physically access pidashcam to extract videos
  • to save space on pidashcam

System Design

After considering the above, I came up with the following system design

Raspberry Pi Model 3 in the Car

  • Connects automatically to Home WI-Fi network
  • PiModules UPS Pico to provide the battery backup, file-safe shutdown and RTC
  • Forward facing Pi Camera
  • Option for USB connected WebCam for rear facing camera
  • Adafruit Ultimate GPS breakout board to source the positional data
  • Two momentary push buttons for external inputs
  • Two LEDs to indicate system status
  • Custom system daemon written in Python to implement the PiDashCam features
  • Resilio Sync1 to synchronise the local video filesystem with my Mac whenever I am connected to home Wi-Fi

iMac in Home

  • Resilio Sync
  • Hazel to:
  • move new videos to another folder (and thus save space on PiDashCam)
  • convert the videos from h264 format to mpeg
  • fire off a Pushover alert to tell me that there are videos to watch

PiDashCam Use Cases

External power is applied to PiDashCam – e.g. ignition switched on

  • Start to record into 5 min circular buffer with positional data overlaid on video stream
  • Switch on LED 1 to indicate that recording is in progress
  • LED 2 remains off

Button A is pressed – flush the current buffer to disk

  • Save content of circular buffer plus another 5 mins of video to disk
  • Flash LED 1 2Hz 50:50 duty cycle whilst this is going on
  • Resume recording into circular buffer

Button B is pressed – flush and pause

  • if PiDashCam is recording
  • simulate Button A being pressed but then pause recording
  • extinguish LED 1
  • otherwise
  • resume recording

UPS signals it has gone on to battery – e.g. ignition switched off

  • Simulate Button B being pressed
  • If PiDashCam is connected to home Wi-Fi
  • Wait for the Videos folder to become empty
  • Flash LED 2 2Hz 50:50 duty cycle whilst this is going on
  • (Note: if UPS PIco battery runs down, it will shutdown PiDashCam safely)
  • shutdown
  • Otherwise
  • shutdown

More to follow


  1. Resilio Sync is a private P2P networking product from the people who brought us BitTorrent. I used the free Sync Home product. 

How To build a Raspberry Pi powered Twitter Display

Use a Raspberry Pi to develop a stand alone Twitter appliance that can be used to display tweets in a public environment.
hashtag #5thLetchworth

Background

Every two years, Letchworth and Baldock District Scouts holds its Arts and Crafts competition. This year, it was decided to hold it in a pop-up shop in Letchworth town centre. The theme was Adventure.

The Scouts in my troop, 5th Letchworth, decided it would be a good idea to have a multi-media display; comprising a physical hashtag and a display of tweets containing that hashtag. The hashtag was, of course, #5thLetchworth.

The Scouts constructed the physical hashtag and decorated it with pictures, poems and other items that conveyed the notion of adventure. It was my task to create the twitter display.

System design

The obvious base for the display was a Raspberry Pi! of which I have several. This would be connected to a large screen TV via the built in HDMI interface, and to the Internet via my own Mi-Fi.

The Pi already has XWindows installed, so that would be used to run the Chromium browser. Chromium would be set to display a feed from www.twitterfall.com.

Setting up

Configuring the Pi

As the basis of the system, I chose to stick to the stock Raspbian distribution as it has almost everything I needed. The only changes I needed to make were to set it to startup in headless mode and allow remote VNC connections (because there wouldn’t be a keyboard or mouse connected when the system was in use). I also had to set it to auto-start Chromium.

Setting the Pi to startup in headless mode

To do this, you need to install the x11vnc package.

  1. Logon as the default user pi
  2. Open a terminal session and download the x11vnc package:

    sudo apt-get update
    sudo apt-get install x11vnc

  3. Set a password for when you attach via your VNC client.
    x11vnc -storepasswd

  4. Create a startup configuration for x11vnc. From your home directory:

    cd .config
    mkdir autostart
    cd autostart

  5. Now use your favourite editor to create the file x11vnc.desktop with the following contents:

    [Desktop Entry]
    Type=Application
    Name=X11VNC
    Exec=x11vnc -forever -shared -usepw -display :0 -ultrafilexfer
    StartupNotify=false
    Terminal=False
    Hidden=False

  6. Now reboot the Pi
  7. After it has rebooted, you should be able to use your favourite VNC client to connect to the IP address of the Pi on port 5900 using the password set it step 3.

Installing and autostarting Chromium

  1. Open another terminal session and install chromium.
    sudo install chromium
    cd .config/autostart
  2. Create the file chromium.desktop with the following contents:
    [Desktop Entry]
    Type=Application
    Name=chromium
    Exec=chromium
    StartupNotify=false
    Terminal=False
    Hidden=False
  3. If you now reboot again, the chromium browser should open automatically

Setting Chromium to open www.twitterfall.com automatically

For this to work, you need to authenticate to a twitter account and decide in advance what you wish to display. In my case I wanted to display the output from a specific Twitter List.

Complete the following in the chromium browser:

  1. Open the URL www.twitterfall.com
  2. Authenticate to the Twitter account.
  3. Set Twitterfall to display the appropriate content
  4. Copy the full URL from the chromium address bar; including the /?oauth suffix
  5. Now open a terminal session and edit the file ~/.config/autostart/chromium.desktop and change the Exec= line to be
    Exec=chromium twitterfall.com/?oauth_token=whatever
  6. Save and close and then reboot to test.

Starting Chromium in kiosk mode

The last step is to set Chromium to start in Full Screen mode

  1. Edit ~/.config/autostart/chromium.desktop again and change the Exec= line again to be:
    Exec=chromium -kiosk twitterfall.com/?oauth_token=whatever
  2. Reboot again and it should all work.

One last thing

You will have noticed that Twitterfall cannot be configured to launch in Presentation Mode. This is why you need the remote VNC connection.

I was going to have my MacBook Air with me when I installed this so I simply connected remotely and clicked on the Presentation Mode button in Twitterfall. If anybody knows how to avoid needing to do this, I’d love to hear from them.

The finished article

Display of tweets from #5thLetchworth

Connecting to the Mi-Fi

The topic of How To connect a Raspberry Pi to a 3G network is covered elsewhere.

How To connect a Raspberry Pi to a 3G network

Connect a Raspberry Pi to a Huawei 3G Modem to allow Internet access

Motivation

As part of the project to create a stand-alone Twitter Appliance, I needed to connect a Raspberry Pi to a 3G network.

System Design

The design is simple: An existing 3G modem is connected to the Raspberry via a USB connection. I already own a Huawei E5756s mobile broadband modem connected to Three UK, and as this also has a USB connection, it was the obvious one to use for this.

Installing the modem

Installing the modem required that the Raspberry Pi recognise the modem as such. Unfortunately, out of the box, the E5756 is detected as a hard disk by Raspbian. This is because the modem has a hidden disk partition that contains the Windows driver.

  1. Plug the modem into one of the USB ports.
  2. In a terminal session, run the command

    # lsusb

With a bit of luck, you’ll see something like:

Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 005: ID 12d1:1506 Huawei Technologies Co., Ltd. E398 LTE/UMTS/GSM Modem/Networkcard

The key line is the last, showing that Raspbian has recognised the modem. Unfortunately, you may well see:

Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 12d1:14fe Huawei Technologies Co., Ltd.  

This indicates that Raspbian sees the Huawei device as a disk drive. To get around this, we need to installthe usb-modeswitch package, but we need to do things in a specific order for this to work (or at least I did anyway).

Open a terminal prompt and, with the modem unplugged:

  1. install the usb-modeswitch package

    # sudo apt-get install usb-modeswitch

  2. After this completes, reboot the Pi and then log in again and open a terminal session.

  3. Plug the modem in, leave it for a second or two for it to be recognised and then do

    # lsusb

  4. Hopefully, the output will now indicate the the modem has been recognised. Display the network interface list:

    # ifconfig -a

Hopefully, you will see:

eth0      Link encap:Ethernet  HWaddr b8:27:eb:04:64:df 
          inet addr:172.29.12.204  Bcast:172.29.12.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1191 errors:0 dropped:0 overruns:0 frame:0
          TX packets:633 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:383489 (374.5 KiB)  TX bytes:100065 (97.7 KiB)

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: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)

wwan0     Link encap:Ethernet  HWaddr 0c:5b:8f:27:9a:64 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5237 (5.1 KiB)  TX bytes:0 (0.0 B)

Good news, we have a new interface. To get this to acquire an IP address, we need to edit the file /etc/network/interfaces and add the lines:

allow-hotplug wwan0  
iface wwan0 inet dhcp

If you now reboot, you should see that the new interface has been initialised and configured:

eth0      Link encap:Ethernet  HWaddr b8:27:eb:04:64:df 
          inet addr:172.29.12.204  Bcast:172.29.12.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1191 errors:0 dropped:0 overruns:0 frame:0
          TX packets:633 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:383489 (374.5 KiB)  TX bytes:100065 (97.7 KiB)

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: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)

wwan0     Link encap:Ethernet  HWaddr 0c:5b:8f:27:9a:64 
              inet addr:192.168.1.101  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5237 (5.1 KiB)  TX bytes:0 (0.0 B)

Hoorah, the modem is connected and working.

After this bit of jiggery-pockery, the modem should continue to be recognised if it is connected at boot time.