Adventures with Aredn VLANs

I recently put a node up for San Francisco Wireless Emergency Mesh. It’s something I’ve been intending to do for a while but just never made the time. One of the SFWEM members reached out when he saw me on APRS.fi and asked if I were interested in putting up a node. Since it was something I’ve been meaning to do for a while, I got to work.

The hardware I’m using is a Ubiquiti Rocket M5 with an AMO-5G13 omni directional antenna. The hardware runs a custom firmware from Amateur Radio Emergency Data Network. The setup and configuration is well documented and went smoothly. After mounting the Rocket M5 on a roof mount and running an ethernet to a POE, the node was online.


KK6RUH-Oakland-Omni-M5

This node provides good coverage of the general area. It’s currently connected to the rest of the SFWEM mesh network by node KJ6WEG-OAK-Griz-SectorM5 up on Gizzley Peak.

Things got interesting when I started to add a second node. This one is based on a NanoBeam M5 and is intended to create a point-to-point connection to another node on the network, most likely KJ6DZB-USS-HORNET-SOUTH on the USS Hornet.

Putting two devices on a network with the Aredn firmware is supposed to allow them to set up a device-to-device (DtD) connection over the network instead over the RF network.

The Aredn DtD documention was a bit confusing to me. Specifically when I read about the use of VLANs, I assumed that putting the switch ports for both nodes on VLAN 2, they would find and communicate over the network. That’s not what was needed. I know, for whatever reason I suffered a VLAN mental slip.

My network configuration had three VLANs: 1 as the default, 2 for AMPRNET and 3 for Lorawan devices. Since I thought that Aredn wanted to be on VLAN 2, I reconfigured all the switches as: 1 as the default, 2 for Aredn, 3 for Lorawan and 4 for AMPRNET. But this configuration doesn’t work. The SFWEM nodes could get an IP address from the router on VLAN 1 for their WAN interface but they didn’t see each other.

After a few frustrating hours staring at configuration screens, reading and re-reading the Aredn docs, chatting with SFWEM members on slack and wading through my VLAN experience, I realized that I was misunderstanding the use of untagged, VLAN 1 and VLAN 2 by the Aredn firmware. What I realized is that the nodes want to be on their own VLAN and they’ll send WAN data tagged for VLAN 1 while tagging packets for VLAN 2 when doing any DtD communications.

I reconfigured my network switches again but this time as: 1 as the default, 2 for Aredn DtD, 3 for AMPRNET, 4 for Lorawan devices and 5 for SFWEM. The important part here is that the ports for SFWEM nodes are set to tag VLAN 1, tag VLAN 2 and untagged VLAN 5. This gives the Aredn their own default network on VLAN 5, makes VLAN 2 available for DtD communications and allow VLAN 1 traffic to leave the switch for the great beyond.


Both nodes are now online and connected via DtD.

Raspberry PI VLANs

The Raspberry PI is a lovely small computer but sometimes the documentation leaves much to be desired. Expecially when searching for information online. Take networking, if you just need the default configuration everything just works. And that’s one of the joys of working with a Raspberry PI, many tasks just work. But as soon as you want to do anything outside the norms, things become difficult.

Take for instance, adding a VLAN to a PI. Searching online will bring up lots of details on what people have done in the past to add a VLAN and configure it. Sadly, the hows for this have changed over time and most of the information out there is worse that wrong. It forces users to follow steps that just don’t work and then lots of time spent trying to figure out what was done wrong. It’s a rather frustrating aspect of working with a PI.

In an effort to help me remember the steps and for anyone who stumbles into the need to add a VLAN, here are the steps for Stretch, Raspbian Linux 9:

$ sudo apt-get install vlan
$ sudo vconfig add eth0 2
$ sudo bash -c 'echo "interface eth0.2" >> /etc/dhcpcd.conf'
$ sudo ifconfig eth0.2 up
  1. Install the vlan package.
  2. Add vlan 2 to interface to eth0. Change 2 to which ever VLAN you need and eth0 to the physical ethernet interface.
  3. Add a new interface entry to the dhcpcd.conf file so that an IP address can be assigned.
  4. Bring up interface eth0.2.

Update 2021-03-05: There are a couple of steps that I neglected to include. With the steps above, the VLAN will be lost on reboot. Actually those steps won’t work since the VLAN kernel module isn’t loaded. You’ll need to do that before running the vconfig command.

modprobe 8021q
echo 8021q >> /etc/modules

Next, add

vconfig add eth0 5

to /etc/rc.local. If your rc.local has an

exit 0

line at the end, the vconfig command needs to be added before the exit.

With these changes, your VLAN configuration will be re-created when the system is rebooted.

Oakland, fireworks, air pollution and the 4th of July

Oakland is a great city. I’ve enjoyed living here for the past 7 years, and working for another 13 before that. The people, the arts, the culture, the food, it’s all wonderful. Except for the fireworks.

Each year as the 4th of July approaches, the fireworks start. Right around 9pm nightly, someone’s lighting them up, splashing the sky with colors and the air with sounds. Sitting on the roof of my house, I see fireworks 360 degrees. They’re beautiful to watch though after 6 hours, it’s all rather tiring. And the sounds become opressive. They’re constant and punctuated by ridiculously loud explosions.

There’s one aspect that I hadn’t considered before, air quality. I recently installed a PurpleAir module to monitor the air quality. The fires last fall wreched havoc on the air quality and being a geek, I wanted something in place to monitor the next fire season. It’s on the PurpleAir map. I pull the data from it to a local InfluxDB database and recently went exploring through the measurements. What I found was interesting.

PurpleAir PM10 Air Quality

The PM10 air quality reached 305 around 11:52PM on the 4th.


The PM2.5 air quality reached 81 around 12:12AM on the 5th.

The PM10 of 305 and PM2.5 of 81 are way, way higher than recommended maximums. Midnight is when the bulk of fireworks are ignited.

As a city, we need to do better for each other.

[Addendum 2020-07-25 16:44:55]

Another aspect that I want to cover for next year is sound levels. Adding a mechanism by which the decible level for general human and k9 hearing would go a fair way toward a better view into what happens with the fireworks.

I would appreciate any suggestions on sensors that would assist with this endeavour.

Influx Telegraf and inputs.exec

I’m a fan of Influxdb for capturing data over time. Coupling it with Grafana and interesting dashboards come to life.

Part of Influx’s tool set is Telegraf, their data collection tool. It comes with a slew of data input and output plugins that are reasonably easy to configure and use. I use two of them fairly regularly, inputs.snmp and inputs.exec. The inputs.snmp plugin uses the long standing SNMP protocol to pull data from network devices. Configuration is fairly straight forward. Here’s a sample for collecting data from a network switch:

[[inputs.snmp]]
  agents = ["NAME_OR_IP"]
  version = 2
  community = "COMMUNITY"
  timeout = "60s"

  [[inputs.snmp.field]]
    oid = "RFC1213-MIB::sysUpTime.0"
    name = "uptime"

  [[inputs.snmp.field]]
    oid = "RFC1213-MIB::sysName.0"
    name = "source"
    is_tag = true

  [[inputs.snmp.table]]
    oid = "IF-MIB::ifTable"
    name = "interface"
    inherit_tags = ["source"]

    [[inputs.snmp.table.field]]
      oid = "IF-MIB::ifDescr"
      name = "ifDescr"
      is_tag = true

Change NAME_OR_IP to the device name / IP address and the COMMUNITY to the configured SNMP community on the device and Telegraf will pull data from the switch every 60 seconds.

I put one of these configuration files in the

\etc\telegraf\telegraf.d

directory for each device. I use the device name as the file name. So for network switch ns1, the configuration file is

\etc\telegraf\telegraf.d\ns1.conf

At home, the network has 4 switches and there are 4 .conf files in the telegraf.d directory. The inputs.snmp plugin handles all the .conf files and processes the data from all the network devices as expected.

The second Telegraf plugin I often use is inputs.exec. This will launch a program and collect the output to send to the influx database. CSV, JSON, etc. all work to feed the Influx engine.

A typical configuration file looks like:

[[inputs.exec]]
  commands = [
    "/usr/local/bin/purpleair_json.py https://www.purpleair.com/data.json?show=DEVICEID&key=APIKEY"
  ]

  interval = "60s"
  timeout = "10s"
  data_format = "json"
  name_suffix = "_purpleair"
  tag_keys = [
    "ID",
  ]

In this case, the exec will run the /usr/local/bin/purpleair_json.py program and capture the data from a PurpleAir device every 60 seconds.

The problem is that the inputs.exec plugin doesn’t allow for multiple instances as with the inputs.snmp plugin. If there are more than one .conf file with inputs.exec, only the last one read by telegraf will be used. As such, more than one program cannot be used to feed via telegraf into influxdb. Rather annoying.

To get around this, I create another instance of the telegraf service. That includes a new systemd service file, a separate /etc/telegraf_EXECNAME folder and supporting configuration files.
In /lib/systemd/system/telegraf_EXECNAME.service:

[Unit]
Description=The plugin-driven server agent for reporting metrics into InfluxDB
Documentation=https://github.com/influxdata/telegraf
After=network.target

[Service]
EnvironmentFile=-/etc/default/telegraf_EXECNAME
User=telegraf
ExecStart=/usr/bin/telegraf -config /etc/telegraf_EXECNAME/telegraf.conf -config-directory /etc/telegraf_EXECNAME/telegraf.d $TELEGRAF_OPTS
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartForceExitStatus=SIGPIPE
KillMode=control-group

[Install]
WantedBy=multi-user.target

In the /etc/systemd/system/multi-user.target.wants directory, a symbolic link to the new services file:

cd /etc/systemd/system/multi-user.target.wants/
ln -s /lib/systemd/system/telegraf_EXECNAME.service .

In the /etc/telegraf_EXECNAME/telegraf.conf:

[agent]
  interval = "10s"
  round_interval = true
  metric_batch_size = 1000
  metric_buffer_limit = 10000
  collection_jitter = "0s"
  flush_interval = "10s"
  flush_jitter = "0s"
  precision = ""
  debug = true
  logtarget = "file"
  logfile = "/var/log/telegraf/telegraf_EXECNAME.log"
  logfile_rotation_interval = "1d"
  logfile_rotation_max_size = "50MB"
  logfile_rotation_max_archives = 10
  hostname = ""
  omit_hostname = false


[[outputs.influxdb]]

[Add the needed options to the influxdb section for where the influxdb is hosted]

Note that this .conf file has removed all the collection information for the localhost, that remains in the original telegraf instance.

The .conf for the inputs.exec plugin are placed in

\etc\telegraf_EXECNAME\telegraf.d\EXECNAME.conf

To kick off the new service:

systemctl daemon-reload
systemctl enable telegraf_EXECNAME
systemctl start telegraf_EXECNAME

[In all the examples above, replace EXECNAME with a name that describes what’s being run.]

Creating multiple instances of the Telegraf service is annoying but it does allow me to collect the data from multiple places by running programs that reach out, gather the data and format for use with Telegraf and then into an InfluxDB database. See https://github.com/pkropf/telegraf for some examples.

Tags : , ,

Rejection! Burning Man DMV Rejects Most Useless II

Sadly, the Burning Man DMV department has decided that Most Useless II doesn’t meet their minimums. Here’s the rejection letter:

Mutant Vehicle: Most Useless, II
Registration #: M20-0254
Owner: Peter Kropf

Dear Peter Kropf,

The DMV has carefully reviewed your application for your Mutant Vehicle project Most
Useless,II (M20-0254) and we’re very sorry to inform you that your vehicle was not 
accepted for invitation to Burning Man this year.

Please read this letter carefully for more information about the decision regarding 
your vehicle.

The DMV Review Team felt that:

************************************************************

DOES NOT MEET MINIMUM CRITERIA - TOO SIMILAR TO STOCK VEHICLES

Unfortunately, your vehicle as presented in your application does not meet the 
minimum criteria for a mutant vehicle license:

* * * *
"Level of Mutation / Visual Presentation

Mutate your vehicle to the point that it is not recognizable as a street or stock 
vehicle. A radically mutated vehicle will not resemble or represent a car, truck, golf
cart or any other readily identifiable street or stock vehicle. In most cases, little or
none of the base vehicle should be visible. Beyond just changing, covering or hiding
the base vehicle, the mutation should aim to be visually compelling, providing
“wow factor” for the other participants of Black Rock City. When a person sees this
vehicle, their reaction should be “Wow! Look at that!” If a vehicle maintains it’s 
stock form (i.e. – it keeps the shape of a bus, golf cart or street vehicle) it may not
be sufficiently mutated to meet the Mutant Vehicle Criteria."
* * * *

The DMV Review team felt that while your vehicle has custom attributes, and we
appreciate teh "Most Useless" concept, overall the design does not fundamentally
change the vehicle's visuals from the base Taylor-Dunn.

We should be clear that the team overall enjoyed your vehicle, but in the interest
of fairness, we could not invite as the base is too much the same as the stock 
vehicle it is based upon.

************************************************************

Due to the high number of applications and the limited number of vehicles we can
invite, we simply can't invite all applicants, even when they meet the minimum 
requirements.  We don't want anyone to have the sad experience of bringing a
vehicle out to the playa and having it denied a license after all that work!  We
do our best to give invitations to those most likely to get approved on playa.

We very much understand that you have committed significant time and resources
to creating your mutant vehicle (many of us are mutant vehicle creators ourselves,
so we know what it takes) and that this is hard news to receive.  The level of 
execution of mutant vehicles submitted by the Burning Man community for review
increases from year to year, and unfortunately, there is a limit to how many 
moving vehicles we can allow during the event. Your vehicle simply did not exceed
the very high bar that has been set by your fellow Mutant Vehicle creators this year.


Once again, we realize that this is not the news you likely wanted to hear, but we
do want to thank you for the effort you made and look forward to seeing you on the
playa.

If you have questions or wish to discuss this issue further, we can be reached at 
dmv@burningman.org
` 
Sincerely,
- The DMV Hotties and the Burning Man staff and community.