Jekyll2022-08-10T11:22:10+02:00https://fieldtracks.org/FieldtracksFieldtracks - Tracking personal in field training exercisesJellingStone rewrite - a new wire procotol2022-05-25T17:27:18+02:002022-05-25T17:27:18+02:00https://fieldtracks.org/misc/2022/05/25/wire-protocol<p>JellingStone is the software for ESP32-devices. It utilizes Bluetooth for scanning (i.e. detecting) and emitting beacons.
Results are transmitted over MQTT and WLAN. It is based on <a href="https://docs.espressif.com/projects/esp-idf/en/latest/esp32/get-started/index.html">ESP-IDF</a>.</p>
<p>Recently, a rewrite was needed, and we moved to a byte-oriented wire-protocol for reports.
It is already implemented in JellingStone but changes to the StoneAggregator are yet to be done.</p>
<!--break-->
<h3 id="changes-in-esp-idf">Changes in ESP-IDF</h3>
<p>Over the past years, ESP-IDF has undergone significant changes. Components such as MQTT are integrated and
do no longer require 3rd-party dependencies. The build-system moved from Makefiles to CMake and the toolchain addresses
more modern Python versions. In result, only a build-server based on Debian oldstable is able to
build the software correctly, still. This motivated revisiting and rewriting large parts of the application.</p>
<h3 id="application-redesign">Application redesign</h3>
<p>When starting JellingStone back in 2017 / 2018, it was designed as a research prototype. Not knowing exactly what was needed,
we instead focused on exploring what was possible. Our motto was simplicity over optimization. For scan-reports we went
for a simple protocol. Interesting data such as MAC-addresses, UUIDs, min/max/avg signal strength was encoded in JSON.
Almost 100 byte of data were needed per detected beacon. Of course, this can be reduced by compression. Still,
such a report includes a lot of data that is neither processed nor analyzed.
Growing and compressing a JSON string consumes memory, whereas only 160 KiB of RAM are dynamically available.
In addition, encrypting, fragmenting and transmitting larger MQTT-payloads puts significant stress on ESP32 devices.</p>
<h3 id="avoiding-network-fragmentation">Avoiding Network Fragmentation</h3>
<p>When trying to avoid fragmentation on lower network layers, it is important that one complete MQTT message can
be put into one Ethernet frame. Realistically, Ethernet can transmit at least 1280 byte per frame (<a href="https://datatracker.ietf.org/doc/html/rfc2460#section-5">RFC2460</a>).
Typical TCP- and IP headers reduce the available capacity by 60 byte (IPv6-Header: 40 byte, TCP-Header 20 byte).
Using TLS encryption further reduces the capacity by ~ <a href="https://netsekure.org/2010/03/tls-overhead/">40-60 byte</a> due to padding
and message authentication codes. Of course, this depends on the ciphers in use.
In total, this leaves about 1280 - 60 - 60 = 1160 byte for MQTT payloads. The MQTT-header is relatively large,
because the topic name is included in every message. For instance, 37 byte are needed to encode a name
of a JellingStone scan-report topic. Hence, roughly about <strong>1100 byte</strong> are appropriate to be used for actual data.</p>
<h3 id="wire-protocol-design">Wire-protocol Design</h3>
<p>Having about 1 KiB available for data motivates a relatively compact encoding scheme. However, various BLE standard
use relatively large identifiers to avoid collisions between beacons of different networks and standards.</p>
<ul>
<li>AltBeacon: <a href="https://github.com/AltBeacon/spec">20 byte Beacon ID</a></li>
<li>Eddystone UID: <a href="https://github.com/google/eddystone/tree/master/eddystone-uid">16 byte Beacon ID</a> (10 byte namespace, 6 byte instance)</li>
<li>Eddystone EID: <a href="https://github.com/google/eddystone/tree/master/eddystone-eid">8 byte Ephemeral ID</a></li>
</ul>
<p>In essence, one needs to carry up to 8-20 byte of ID data per Beacon. However, most parts are rather redundant.
For Eddystone UID, the 10 byte namespace is not of interest, because it refers to the beacon-network (e.g. dev.fieldtracks.org).
In addition, an instance ID of 6 byte is relatively large for fieldtracks. It is unrealistic to track more
than 65536 people during a field exercise training. Hence, the instance ID potentially needs just 1 or 2 byte
depending on number of participants and the numbering scheme. Of course, one needs an additional byte to encode the
beacon-type and the detected RSSI each.</p>
<ul>
<li>Using EID for privacy requires 10 byte per beacon: <em>~100 scan-results per message</em></li>
<li>Using UID and requires just 4 byte per beacon: <em>~256 scan-results per message</em></li>
</ul>
<h3 id="protocol-specification">Protocol specification</h3>
<h4 id="header">Header</h4>
<table>
<thead>
<tr>
<th>Byte</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td><code class="highlighter-rouge">0x01</code> (Version), reserved: <code class="highlighter-rouge">0x7B</code> for JSON Payloads</td>
</tr>
<tr>
<td>1-4</td>
<td>Report-ID / 32-Bit timestamp (seconds since Unix-epoch), Big-Endian / Network Byte Order</td>
</tr>
<tr>
<td>5</td>
<td>Message sequence number (signed), unique per report, starts at <code class="highlighter-rouge">0x01</code> in each report, incremented per message, a negative number marks final one, e.g. <code class="highlighter-rouge">0xFF</code> (-1), if there’s just one message</td>
</tr>
<tr>
<td>6</td>
<td>unsigned, number of beacon data segments in this message (report has more, if and only if there are more messages)</td>
</tr>
<tr>
<td>7 - 1100</td>
<td>0…255 (up to 255) segments of beacon data</td>
</tr>
</tbody>
</table>
<h4 id="beacon-data-segment">Beacon Data segment</h4>
<table>
<thead>
<tr>
<th>Byte</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Type and length of Beacon ID in byte. <br /> <code class="highlighter-rouge">0x14</code> AltBeacon <br /> <code class="highlighter-rouge">0x08</code> Eddystone EID <br /> <code class="highlighter-rouge">0x10</code> Eddystone UID <br /> <code class="highlighter-rouge">0x06</code> Eddystone UID, namespace matches configured one <br /> <code class="highlighter-rouge">0x01</code> Eddystone UID, namespace matches configured one, instance <= 255 (i.e. 1 byte) <br /> <code class="highlighter-rouge">0x02</code> Eddystone UID, namespace matches configured one, instance <= 65536 (i.e. 2 bytes)</td>
</tr>
<tr>
<td>1</td>
<td>signed, detected RSSI in dBm + 100 (i.e. -228 dBm to 27 dBm) encoded as -128 to 127</td>
</tr>
<tr>
<td>2 - 21</td>
<td>Beacon ID, variable length</td>
</tr>
</tbody>
</table>
<h4 id="remarks">Remarks</h4>
<ul>
<li>Beacon data is encoded on a type-value basis, whereas the byte value of the type corresponds to the length of the ID-value</li>
<li>The reporting stone (i.e. sender address) is included in the topic-name. It is part of the MQTT-header, hence.</li>
<li>Using a 32-bit timestamp is motivated by <code class="highlighter-rouge">time_t</code> having 32 bit in ESP-IDF. Due to a year 2036-problem that may change in later versions of the protocol.</li>
</ul>
<h3 id="conclusion-and-ideas">Conclusion and ideas</h3>
<p>Re-designing the wire protocol allows to transmit beacons more efficiently. Depending on the privacy-requirements,
up to 255 scan results can be transmitted in a MQTT frame. That’s a huge improvement over the existing JSON based protocol.</p>
<p>Intuitively, receiving up to 255 beacons or more during a scan period of 8 seconds doesn’t seem to be completely absurd in the first place.
However, guessing somewhat realistic numbers is out-of-scope for this article.</p>
<p>Nevertheless, one could think about using this wire-protocol with LoRaWAN instead of MQTT. This won’t work. A typical LoRa
frame has only 37 byte (51 byte - 13 byte for LoRaWAN-header) - up to 3 beacons could be transmitted at once. Duty cycle limitations suggest a scan-interval of 2 minutes at least.
Hence, the potential is quite limited. Furthermore, it is open which data is actually useful when using LoRaWAN, i.e. long-distance
links. Do we need a timestamp, still? Do we need RSSI-data? How many LoRa-speakers are realistic?</p>
<p>Happy Hacking ;-).</p>JellingStone is the software for ESP32-devices. It utilizes Bluetooth for scanning (i.e. detecting) and emitting beacons. Results are transmitted over MQTT and WLAN. It is based on ESP-IDF.Almost stalled, but not dead.2021-08-03T17:27:18+02:002021-08-03T17:27:18+02:00https://fieldtracks.org/misc/2021/08/03/Not-Much-Progress<p>In the last monts, there was very little progress in this project. Probably, it’ll be like this for a while.</p>
<p>The annual field execerise in Pforzheim is canceled for the second time in a row this year. Still, the risk of
Covid-19 infections remains a major blocker for larger trainings, especially including actors.</p>
<p>Nevertheless, there is some progress. We had an online hackathon in March and we will continue to develop and refactor our codebase.
But not seeing a field deployment in the near future, there is no fixed release date or specific plan to implement a certain featureset.</p>
<p>Stay safe!
yanosz</p>In the last monts, there was very little progress in this project. Probably, it’ll be like this for a while.R2R: Fieldtracks.org Hackathon2021-03-25T16:27:18+01:002021-03-25T16:27:18+01:00https://fieldtracks.org/misc/2021/03/25/R2R-Hackathon<p>Machen wir einen Hackathon // Let’s have a hackathon:</p>
<ul>
<li>📅 2021-04-03 / -04</li>
<li>🕑 12.00 (CEST) - …</li>
<li>💬 Matrix: #ft-public:matrix.org</li>
<li>🏠
<a href="https://play.c4map.fieldtracks.org/">https://play.c4map.fieldtracks.org/_/global/maps.c4map.fieldtracks.org/c4map/countc4.json#start</a></li>
</ul>
<p><del><a href="https://bbb.daten.reisen/b/yan-uzg-1hh-qhh">https://bbb.daten.reisen/b/yan-uzg-1hh-qhh</a></del></p>
<!--break-->
<p><strong><em>English text at the bottom</em></strong></p>
<h2 id="ein-hackathon">Ein Hackathon…</h2>
<p>Das Fieldtracks.org-Projekt ruht seit etwa einem Jahr. Mit der SARS-CoV-2 Pandemie sind praktisch alle
Einsatzübungen abgesagt. Dennoch, bald könnte es wieder losgehen.</p>
<p>Nutzen wir das aktuelle Oster-DiVOC 2021 um weiter zu kommen. Es gibt viel zu tun:</p>
<ul>
<li>Das Frontend (fieldmon) braucht neue Features und eine bessere UX
(<a href="https://github.com/FieldTracks/fieldmon/wiki">https://github.com/FieldTracks/fieldmon/wiki</a>)</li>
<li>Die Python-Middleware könnte zusammengeführt und für Docker neu paketiert werden</li>
<li>Das Power-Distribution board steht in den Startlöchern</li>
</ul>
<p>Packen wir’s an!</p>
<p>Den Hackathon koordinieren wir per BigBlueButton (<a href="https://bbb.daten.reisen/b/yan-uzg-1hh-qhh">https://bbb.daten.reisen/b/yan-uzg-1hh-qhh</a>).
Los geht’s am Samstag und am Sonntag um ca. 12 Uhr (CEST). Das Ende ist offen.</p>
<p><em>Da wir ein recht kleines Team sind, ist der Raum möglicherweise nicht fortlaufend besetzt.</em></p>
<p>Bei Fragen kannst Du Dich auch gerne vorab an <a href="mailto:info@fieldtracks.org">info@fieldtracks.org</a> wenden.</p>
<p>Viel Spaß am Gerät!</p>
<h2 id="a-hackathon">A Hackathon</h2>
<p>Fieldtracks.org ist in silence mode for a year or so. Due to the SARS-CoV-2 pandemic, virtually all
field exercises and drills are canceled. However, thinks could go one this year.</p>
<p>Let’s use this year’s Easter-DiVOC to progress. There’s a lot of stuff to do.</p>
<ul>
<li>The frontend (fieldmon) needs new features and better UX
(<a href="https://github.com/FieldTracks/fieldmon/wiki">https://github.com/FieldTracks/fieldmon/wiki</a>)</li>
<li>Different Python-Middleware services can get merged repacked for Docker.</li>
<li>The power-distribution board is about to be finished.</li>
</ul>
<p>Let’s go for it!</p>
<p>We’re going to organize via BigBlueButton (<a href="https://bbb.daten.reisen/b/yan-uzg-1hh-qhh">https://bbb.daten.reisen/b/yan-uzg-1hh-qhh</a>).
Thinks are about to start round 12 o’clock on both Saturday and Sunday. There’s no end-time yet.</p>
<p><em>Due to being a relatively small team, the room might not be open all time</em></p>
<p>Please contact <a href="mailto:info@fieldtracks.org">info@fieldtracks.org</a> in case of further questions.</p>
<p>Happy hacking!</p>Machen wir einen Hackathon // Let’s have a hackathon: 📅 2021-04-03 / -04 🕑 12.00 (CEST) - … 💬 Matrix: #ft-public:matrix.org 🏠 https://play.c4map.fieldtracks.org/_/global/maps.c4map.fieldtracks.org/c4map/countc4.json#startDockerizing the Environment2020-08-23T17:27:18+02:002020-08-23T17:27:18+02:00https://fieldtracks.org/misc/2020/08/23/docker<p>Deployment and development can be done using Docker. Respective sources are available at
<a href="https://github.com/FieldTracks/docker-env">https://github.com/FieldTracks/docker-env</a>.</p>
<!--break-->
<h2 id="motivation-and-the-situation-before-docker">Motivation and the Situation before Docker</h2>
<p>For some time now, both development and deployment was solely happening in Linux Container (LXC) containers.
These containers are run on dedicated development machine and provisioned using Ansible. However, this
approach has certain shortcomings. Onboarding new developers results in grating access and configuring additional
test environments as needed. Furthermore, all Ansible templates are tailored to Debian/Buster. All components
(fieldmon, StoneAggregator, StoneFlashtool) are required to be packaged using, for instance Debian or pip packages.
Also, the Ansible templates rely on inbound Internet connectivity, making it hard for local Development environments.</p>
<p>This motivates to start experimenting with docker. In essence, the setup is supposed to:</p>
<ul>
<li>Enable local containers for development</li>
<li>Reduce the complexity for deployment</li>
</ul>
<p>Nevertheless, the fieldtracks stack is more challenging compared to web-application typically addressed by Docker.</p>
<h2 id="challenges-for-providing-docker-images">Challenges for providing Docker images</h2>
<p>By design, the fieldtracks technology stack contains various components and technologies. For instance, this includes HTTP
and MQTT servers as well as software developed as a part of the fieldtracks project. Tight dependencies exist between
all components. For instance, Mosquitto relies on Apache for authenticating MQTT users based on JWT/HTTP.</p>
<p>Additional complexity is introduced by Transport Layer Security (TLS). A local certificate authority (CA) is used
to secure MQTT-traffic between JellingStone and the MQTT broker. This requires generating certificates for the broker
and distributing key material using StoneFlash Tool. An Internet based CA such as Let’s encrypt cannot be used due to
requiring inbound Internet connectivity. However, this can hardly be fulfilled in local development and offline
site deployments.</p>
<p>Both, using various components and operating a custom CA are rather uncommon for typical web-applications.
In total, docker packaging is required for the following components:</p>
<ol>
<li>fieldmon (HTTP)</li>
<li>WebDAV (HTTP)</li>
<li>MQTT service (i.e. Mosquitto)</li>
<li>JWT services for both HTTP and MQTT.</li>
<li>StoneAggregator</li>
<li>StoneFlashtool</li>
<li>StoneSimulator (when used in development)</li>
<li>Local CA (i.e. easy-rsa)</li>
<li>Let’s encrypt client (when used in field deployments)</li>
</ol>
<p>In result, the large number of different services and application makes it unpractical to provide distinct images
the various components. This reasons to differ from conventional docker designs,
which aggregate different, single-process images. Creating a docker-compose YAML file for nine different applications would have
resulted in an elaborate configuration with complex service-interactions.</p>
<h2 id="the-docker-env-repository">The docker-env repository</h2>
<p>Fieldtracks uses a single Docker images for packaging all components except for Let’s encrypt client and StoneFlashtool. It is available at
<a href="https://github.com/FieldTracks/docker-env">https://github.com/FieldTracks/docker-env</a>. Images for Amd64 and Arm64 are provided on <a href="https://hub.docker.com/u/fieldtracks">Docker Hub</a>.</p>
<p>The Amd64 image is called fieldtracks, whereas fieldtracks-rpi is built for Arm64 devices such as Raspberry Pis.</p>
<p>When used for development, the Image can be started as follows</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>mkdir data # Mind to create data directory for certificates and easy-rsa data.
docker run \
--name fieldtracks \
--hostname local-dev.fieldtracks.org \
--rm \
-it \
-p 8485:80 \
-p 8443:443 \
-p 2225:22 \
-p 2883:1883 \
-p 8883:8883 \
--mount type=bind,source="$(pwd)"/data,target=/data \
fieldtracks:latest
</code></pre></div></div>
<p>Certificate data is placed at <code class="highlighter-rouge">data/tls</code> and can easily be added to the local browser. A detailed discussion on files
present in data is given in
<a href="https://github.com/FieldTracks/docker-env/blob/master/Readme.md">https://github.com/FieldTracks/docker-env/blob/master/Readme.md</a>.</p>
<p>For deployments, the situation is more complex. Generating valid TLS certificates requires a Let’s encrypt
client in addition. An example for a corresponding Docker compose file is available at
<a href="https://github.com/FieldTracks/docker-env/blob/master/docker-compose.yml">https://github.com/FieldTracks/docker-env/blob/master/docker-compose.yml</a>.</p>
<h3 id="the-todo-list">The Todo-List</h3>
<p>Still experimenting with docker yet, the Image is not complete. Most notable, the stone simulator is not started by default
and there is the StoneFlashtool is not configured, yet. The latter also concerns configuring USB-port shares in Docker.</p>
<p>Happy Hacking 😉.</p>Deployment and development can be done using Docker. Respective sources are available at https://github.com/FieldTracks/docker-env.Meet us at FOSDEM 20202020-01-11T14:14:18+01:002020-01-11T14:14:18+01:00https://fieldtracks.org/misc/2020/01/11/fosdem<p>We’re going to give a short presentiation at FOSDEM 2020.
The session will take place in the <a href="https://fosdem.org/2020/schedule/track/internet_of_things/">Internet of Things devroom</a> devroom (<a href="https://fosdem.org/2020/schedule/room/ud2218a/">UD2.218</a>) on Sunday from 14:30 til 15:00. It will cover a short demo and some background information.</p>
<p>Details can be found at <a href="https://fosdem.org/2020/schedule/event/iotfieldtracks/">https://fosdem.org/2020/schedule/event/iotfieldtracks/</a>.</p>
<p>Greetz, yanosz</p>We’re going to give a short presentiation at FOSDEM 2020. The session will take place in the Internet of Things devroom devroom (UD2.218) on Sunday from 14:30 til 15:00. It will cover a short demo and some background information.Testing DSL and overlay networks2019-11-13T19:14:18+01:002019-11-13T19:14:18+01:00https://fieldtracks.org/network/2019/11/13/dsl<p>Altough our first field test went well, the network infrastructure has still room for improvements. This article explains some ideas for integrating a Digital Subscriber Line (DSL) based network into field tracks and their evaluation.</p>
<!--break-->
<h2 id="learning-from-the-initial-field-test">Learning from the initial field test</h2>
<p>The first test happened on a parking lot. Three mobile treatment center were
raised by different units. Participants were tracked during triage and therapy.</p>
<p>To provide wlan at the site, four <a href="https://store.ui.com/products/unifi-ac-mesh-ap">UniFi AC Mesh AP</a> units were installed. A local controller was used for provisioning and monitoring. Using different channels, the wlan provided more than enough capacity for all JellingStone devices. All units were hooked up to the grid using power-over-ethernet (POE). Cat5 cables were used to create a wired, switched backbone. The deployment went smooth and took about 30 minutes. Still, some shortcomings occurred:</p>
<ol>
<li>Not having power cables or batteries in the beginning, the build-up started two hours later than planned initially. By intuition, it appears reasonable to have batteries - but using battery power imposes power constraints on the devices in use: Overprovisioning using powerful devices becomes less attractive.</li>
<li>Using mesh-links instead of Cat5-cables was not attractive. For power distribution, all AP were hooked up by cables nevertheless and Cat5 is easier to handle than H07RNF-3G2.5. In this non-reflecting environment, mesh-links would have required line-of-sight in addition.</li>
</ol>
<p>Learning from this event, we decided to extent the network regarding to the devices in use:</p>
<ul>
<li>Create a power system using local batteries to exploit mesh links.</li>
<li>Introduce smaller boxes, requiring less power.</li>
<li>Potentially use field wire (still common among relief organizations in Germany) for non-line-of-sight situations. This could improve handling and allow larger communication range compared with Cat5.</li>
</ul>
<h2 id="what-do-we-actually-need">What do we actually need?</h2>
<p>On the one hand, each JellingStone sensor roughly transmits up 10 KByte every 5 seconds - i.e. to 2 KByte/s. Thus 200 devices need 400 Kbyte/s, requiring 3.6 MBit/s approximately. That’s about the uplink capacity of an ADSL2+ Annex M link. Using compression and avoiding fragmentation, we hope reduce the traffic to 10% in the future.</p>
<p>On the other hand, lines of field wire are usually deployed and used with <a href="https://en.wikipedia.org/wiki/Field_telephone">telephones</a>, opening the case for Voice-over-IP (VoIP).</p>
<p>In general, field exercises may take up to few days - batteries should should last for 8-12 hours at least. Replacing batteries 2-3 times per day is fine.</p>
<h2 id="hardware-in-use">Hardware in use</h2>
<p>To validate our idea, we decided to do some benchmarking based on old ADSL hardware and got an old <a href="https://www.zyxel.ch/de/provider-products/msans-dslams/ies-1248-5x_ies-1248-5xa-series">Zyxel IES‑1248‑51A</a> for testing (~ 120 €). It is able to connect up to 48 ADSL2+ boxes.</p>
<p>Being somewhat stingy, we looked for cheap ADSL2+ boxes. Two boxes draw our attention:</p>
<ul>
<li><a href="https://avm.de/service/fritzbox/fritzbox-7312">AVM Fritzbox 7312</a></li>
<li><a href="https://openwrt.org/toh/astoria/arv752dpw22">Arcadyan ARV752DPW22 / Vodafone Easy Box 803a</a></li>
</ul>
<p>Both boxes are available for ~1 € (used; 5 € including shipping) and supported by OpenWRT in principle. But it is a tough choice:</p>
<ul>
<li>The ARV752DPW22 consumes three times the power of the 7312. While the 7312 uses 5V/1.6A and could be powered using an USB powerbank, the ARV752DPW22 needs 15V / 1.6A, practically resulting in a lead-battery having a step-up converter.</li>
<li>On the 7312, the telephone connectors can only be used with AVM’s stock firmware. But when using stock firmware, the wireless cannot do anything interesting (802.11s, P2P, IBSS, etc.).</li>
</ul>
<p>To keep things simple in the beginning, we went on testing the 7312 using stock firmware and OpenWRT at our hackathon in November.</p>
<h2 id="network-architecture-roaming-and-the-case-for-an-overlay-network">Network-architecture, roaming and the case for an overlay network</h2>
<p>In general, wireless stations should be able to roam within the network while maintaining IP-connectivity. In a very simple form, this can be realized by creating a Layer-2 / ethernet segment bridging all wireless access points.</p>
<p>In principle, this could be realized by running Ethernet-over-ATM (EoA) and bridge the corresponding interface to wireless interfaces running in AP mode. But haven run a similar configuration with Thomson TG605s back-to-back before, we noticed that some DSL devices are not used to update mac address tables when stations roam through the network - the entries turned out to be quite persistent. This is completely fine for PPPoE setups with no mobility at all and I guess, that many boxes were never tested to update any address due to a roaming device.</p>
<p>Another point is, that AVM does not expose the EoA interface to the kernel. Thus it is impossible to bridge it with the wireless lan interface using the linux command line.</p>
<p>Both points can be addressed by bridging an overlay network (VPN without encryption) instead of the EoA interface. Being limited to technologies that are part of Freetz / Fritz OS 6, the two most interesting candidates are:</p>
<ul>
<li><a href="https://en.wikipedia.org/wiki/L2TPv3">L2TPv3</a></li>
<li><a href="https://www.tinc-vpn.org/">Tinc</a></li>
</ul>
<p>Stateless L2TPv3 pseudowires are simple point-to-point links. L2TPv3 is implemented in the kernel and can be configured using <code class="highlighter-rouge">ip l2tp</code> for each link individually. Tinc on the other hand is a decentralized and simple VPN program, that can be used like a distributed switch.</p>
<p>Compared with L2TPv3, tinc is running in userland and potentially slow. But it supports fragmentation, path-mtu & peer discovery and passing traffic between peers directly. L2TPv3’s mtu is bound by the underlying link - IPv4 fragmentation is possible, though. In other words: Tinc might be slow, while L2TPv3’s achilles heel is costlier configuration. This raises two questions:</p>
<ul>
<li>What is Tinc’s TCP-Goodput compared to L2TP? Is an AVM 7312 running tinc able to switch at 3.5 MBit/s at least?</li>
<li>Is it possible to create a L2TPv3 pseudowire on AVM 7312 devices? What is the actual effort for configuring and maintaining all L2TPv3 links?</li>
</ul>
<p>For testing, we decided to give both protocols a try using <a href="https://freetz.github.io/">Freetz</a> - we also tested installing and using OpenWRT.</p>
<h2 id="testing-freetz">Testing freetz</h2>
<p>Working on top of AVM Fritz OS, Freetz enables SSH-access and command line administration, needed to configure l2tp-links. As of today, both Fritz OS 6.33 and Fritz OS 6.55 can be used in combination with freetz’es master branch. In general, build-instructions for freetz are availble at <a href="https://freetz.github.io/wiki/help/howtos/common/install.html">freetz.github.io</a> - keep in mind, that the project is hosted on <a href="https://github.com/freetz">github</a> nowadays.</p>
<p>Not having <code class="highlighter-rouge">/sbin/l2tp</code> in 6.55 initially, 6.30 is used - tinkering with 6.55 is not on the agenda, yet. Tinc on the other hand is included in our freetz build-<a href="https://github.com/FieldTracks/benchmark/blob/master/freetz_7312/.config">.config</a> - tun devices drives are included in 6.33 - no futher kernel modules are needed in addition. As of today, running Freetz / FritzOS 6.33 results in linux 2.6.32 and tinc 1.0.35.</p>
<h3 id="installation">Installation</h3>
<p>After cloning the master branch and entering the menu (<code class="highlighter-rouge">make menuconfig</code>), the tinc package is included in addition. Executing <code class="highlighter-rouge">make</code> creates the image - (for example: 7312_06.30-freetz-HEAD-20191017-828c7d609-dirty.de_20191107-121917.image) Extract and flash:</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">tar </span>xvf images/7312_06.30-freetz-HEAD-20191017-828c7d609-dirty.de_20191107-121917.image
<span class="nb">cd </span>var/tmp <span class="c"># change folder</span>
ftp 192.168.178.1 <span class="c"># 3-5 seonds after power on; during boot</span>
</code></pre></div></div>
<p>The Zyxel IES-1248-51A requires the Fritzbox to operate using Annex A. This is done by setting <code class="highlighter-rouge">kernel_args</code> accordingly.</p>
<p>Transcript of the FTP session. Prompt is <code class="highlighter-rouge">ftp></code> - username / password: adam2</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Connected to 192.168.178.1.
220 ADAM2 FTP Server ready
Name (192.168.178.1:jan): adam2
331 Password required for adam2
Password:
230 User adam2 successfully logged in
Remote system type is AVM.
ftp> quote SETENV kernel_args annex=A
200 SETENV command successful
ftp> binary
200 Type set to BINARY
ftp> passive
Passive mode on.
ftp> quote MEDIA FLSH
200 Media set to MEDIA_FLASH
ftp> put kernel.image mtd1
local: kernel.image remote: mtd1
227 Entering Passive Mode (192,168,178,1,12,8)
150 Opening BINARY data connection
226 Transfer complete
13660936 bytes sent in 29.32 secs (454.9759 kB/s)
ftp> quote REBOOT
221 Thank you for using the FTP service on ADAM2
ftp> quit
221 Goodbye.
</code></pre></div></div>
<h3 id="benchmarking-tinc--l2tpv3">Benchmarking Tinc & L2TPv3</h3>
<p>For testing, we connected a Lenovo T580 laptop to the AVM 7312 using a 100 MBit/s wired ethernet connection. To avoid limits imposed by the DSL line, the ethernet port (“LAN”) is configured for WAN access - the overlay network is working on top of the wired connection. Bridging the overlay network to the infrastructure wlan on the 7312, the corresponding interface on the laptop becomes effectively part of the LAN of the 7312. At last, another laptop (Lenovo T490) providing an iperf3 service is connected to the infrastructure wlan hosted on the 7312. The network is illustrated in Figure 1:</p>
<figure>
<a href="/assets/dsl-benchmark.png">
<img src="/assets/dsl-benchmark.png" alt="Benchmark network" />
</a>
<figcaption>Figure 1: Overlay network setup for benchmarking</figcaption>
</figure>
<h4 id="tinc">Tinc</h4>
<p>Including tinc in the Freetz build before, it is possible to setup tinc using the Freetz GUI at Port 81/tcp. But due to a missing inode in the <code class="highlighter-rouge">/dev</code>-filesystem, tinc is unable start. This can be fixed by SSH’ing to the box and creating the inode manually. Doing only preliminary benchmarking, we have not tried creating a reboot-save configuration, yet.</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">mknod</span> /dev/tun c 10 200
</code></pre></div></div>
<p>All configuration files are available at <a href="https://github.com/FieldTracks/benchmark/tree/master/tinc">https://github.com/FieldTracks/benchmark/tree/master/tinc</a>. The laptop is configured
using linux command tools in the distribution (Manjaro Linux 18.1.2, Kernel 4.19.81, Tinc 1.0.35).</p>
<pre><code class="language-bash=">$ iperf3 -c 192.168.188.21
Connecting to host 192.168.188.21, port 5201
[ 5] local 192.168.188.200 port 56890 connected to 192.168.188.21 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 864 KBytes 7.08 Mbits/sec 0 73.0 KBytes
[ 5] 1.00-2.00 sec 776 KBytes 6.36 Mbits/sec 0 107 KBytes
[ 5] 2.00-3.00 sec 545 KBytes 4.47 Mbits/sec 3 89.3 KBytes
[ 5] 3.00-4.00 sec 763 KBytes 6.25 Mbits/sec 0 104 KBytes
[ 5] 4.00-5.00 sec 592 KBytes 4.85 Mbits/sec 3 78.4 KBytes
[ 5] 5.00-6.00 sec 763 KBytes 6.25 Mbits/sec 0 89.3 KBytes
[ 5] 6.00-7.00 sec 699 KBytes 5.73 Mbits/sec 3 83.9 KBytes
[ 5] 7.00-8.00 sec 699 KBytes 5.73 Mbits/sec 0 78.4 KBytes
[ 5] 8.00-9.00 sec 763 KBytes 6.25 Mbits/sec 0 89.3 KBytes
[ 5] 9.00-10.00 sec 636 KBytes 5.21 Mbits/sec 0 92.0 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 6.93 MBytes 5.82 Mbits/sec 9 sender
[ 5] 0.00-10.15 sec 6.77 MBytes 5.60 Mbits/sec receiver
iperf Done.
</code></pre>
<p>Looking at the results, the bitrate rate looks volatile, but clearly above 3.5 MBit/s all the time. Assuming, that using DSL instead of ethernet poses no additional CPU load on the 7312, it appears reasonable to assume, that tinc is able to fill the ADSL2+ Annex M uplink completely. For the downlink the situation is different: Being able to serve 27 MBit/s, tinc poses a relevant restriction.</p>
<p>As a result, tinc can potentially be used to transport sensor data generated by JellingStone - but additional IP-traffic (web browsing, etc.) can only be handled to a very limit extend. Tinc’s performance is good enough but has room for improvements.</p>
<h4 id="l2tpv3">L2TPv3</h4>
<p>Unlike tinc, L2TPv3 cannot be configured using the Freetz WebUI. Setting up L2TPv3 requires:</p>
<ol>
<li>Creating a virtual interface having the same IPv4 address as used on the WAN-Interface. This is needed because the kernel appears to be unaware of the network configuration done in the driver-blobs.</li>
<li>Creating a L2TPv3-tunnel according to the IPv4 addresses used in the WAN network.</li>
<li>Creating a L2TPv3 session on top of the tunnel.</li>
<li>Adding the corresponding l2tpeth pseudo-device to the existing LAN-bridge</li>
</ol>
<p>For automation, we created a small <a href="https://github.com/FieldTracks/benchmark/blob/master/scripts/freetz/rc.custom">script</a>, that can be executed during boot, utilizing the <a href="https://freetz.github.io/wiki/packages/mod.html">rc.custom hook</a>. Running iperf3 in this configuration yields:</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nv">$ </span>iperf3 <span class="nt">-c</span> 192.168.188.21
Connecting to host 192.168.188.21, port 5201
<span class="o">[</span> 5] <span class="nb">local </span>192.168.188.200 port 50020 connected to 192.168.188.21 port 5201
<span class="o">[</span> ID] Interval Transfer Bitrate Retr Cwnd
<span class="o">[</span> 5] 0.00-1.00 sec 9.22 MBytes 77.3 Mbits/sec 22 451 KBytes
<span class="o">[</span> 5] 1.00-2.00 sec 9.28 MBytes 77.8 Mbits/sec 0 552 KBytes
<span class="o">[</span> 5] 2.00-3.00 sec 8.29 MBytes 69.6 Mbits/sec 0 609 KBytes
<span class="o">[</span> 5] 3.00-4.00 sec 8.17 MBytes 68.5 Mbits/sec 4 453 KBytes
<span class="o">[</span> 5] 4.00-5.00 sec 8.48 MBytes 71.1 Mbits/sec 0 493 KBytes
<span class="o">[</span> 5] 5.00-6.00 sec 8.42 MBytes 70.6 Mbits/sec 0 519 KBytes
<span class="o">[</span> 5] 6.00-7.00 sec 8.29 MBytes 69.6 Mbits/sec 0 533 KBytes
<span class="o">[</span> 5] 7.00-8.00 sec 8.97 MBytes 75.2 Mbits/sec 0 540 KBytes
<span class="o">[</span> 5] 8.00-9.00 sec 8.85 MBytes 74.2 Mbits/sec 0 541 KBytes
<span class="o">[</span> 5] 9.00-10.00 sec 9.03 MBytes 75.8 Mbits/sec 0 541 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
<span class="o">[</span> ID] Interval Transfer Bitrate Retr
<span class="o">[</span> 5] 0.00-10.00 sec 87.0 MBytes 73.0 Mbits/sec 26 sender
<span class="o">[</span> 5] 0.00-10.10 sec 85.4 MBytes 70.9 Mbits/sec receiver
iperf Done.
</code></pre></div></div>
<p>Again, the bitrate looks volatile and is around 70 MBit/s, potentially hitting the capacity of the 2.4 GHz network - we have a rather noisy environment in our local hackerspace.</p>
<p>As a result, the higher bitrate (~70 MBit/s) makes L2TPv3 by far more attractive than tinc (~ 5 MBit/s) .</p>
<h2 id="testing-openwrt">Testing OpenWRT</h2>
<p>The AVM 7312 is supported by OpenWRT since version 19.07, which is not released yet. 19.07-rc1 is used for testing.</p>
<p>Unfortunately, the needed DSL driver is not configured in OpenWRT stock builds. By default, it includes ITU 992.1/.3/.5 Annex B (ISDN blanking period, Germany), only. However, the IES-1248-51A needs Annex A (POTS blanking period, rest of the world).</p>
<p>In principle, OpenWRT provides an Annex A firmware, that was made available directly by lantiq a few years ago. Newer versions can only be downloaded using vendor firmware bundles. Thus they cannot be provided by OpenWRT due to legal reasons.</p>
<p>Providing version 4.4.4.0.0.1, OpenWRT’s firmware is rather old and causes stability issues on the 7312. Thus we went on by copying <code class="highlighter-rouge">ar9-A-dsl.bin</code> from a freetz box into the OpenWRT file system and updating the <code class="highlighter-rouge">/lib/firmware/adsl.bin</code>-symlink accordingly.</p>
<p>Flashing can be done using <a href="https://fritz-tools.readthedocs.io/">fritz-tools</a> - transcript:</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>wget https://raw.githubusercontent.com/freifunk-darmstadt/fritz-tools/master/fritzflash.py
<span class="c"># Downloading log ommited</span>
python3 fritzflash.py <span class="nt">--image</span> path/to/openwrt-lantiq-xway-avm_fritz7312-squashfs-sysupgrade.bin
</code></pre></div></div>
<p>Executing fritzflash.py yields an interactive terminal program guiding through the flash process. Log:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>This program will help you installing Gluon, a widely used Firmware for Freifunk networks, onto your AVM device.
You can always find the most current version of this script at https://www.github.com/freifunk-darmstadt/fritz-tools
It is strongly recommended to only connect your computer to the device you want to flash.
Disable all other connections (Ethernet, WiFi/WLAN)!
Before we start, make sure you have assigned your PC a static IP Address in the Subnet of the device you want to flash.
The following example would be a completely fine option:
IP-Address: 192.168.178.2
Subnet: 255.255.255.0
Gateway: 192.168.178.1
DNS Servers: Leave blank
Once you're done, press enter, disconnect power from your AVM device and reconnect the power-supply.
Trying to autodiscover! Abort via Ctrl-c.
FritzBox found at 192.168.178.1
Autodiscovery succesful!
-> Device detected at 192.168.178.1.
-> Establishing connection to device!
--> Try 1 of 10
-> Flash image
Writing Gluon image to your AVM device...
This process may take a lot of time.
First, the device will erase its current Operating System.
Next, the device will write the Gluon image to its memory.
The red Info LED will illuminate in this step. Don't worry, this is expected behavior.
Do *not* turn of the device!
We will tell you when your device has finished installing Gluon (this may take a while).
-> Image write successful
-> Performing reboot
== Congratulations! ==
Your device is now running Gluon.
It will restart and in 2-5 minutes you will be able to visit its config-mode.
Remember to reconfigure your interface to automatically obtain an IP-address!
You can reach config-mode by typing in http://192.168.1.1/ in your preferred Webbrowser.
Press any key to exit.
</code></pre></div></div>
<p>After a while, the box is reachable using ssh at <code class="highlighter-rouge">192.168.1.1</code>. To establish a DSL connection we changed the network configuration according to our DSL setup using SSH</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>uci <span class="nb">set </span>network.dsl.annex<span class="o">=</span><span class="s1">'a'</span>
uci <span class="nb">set </span>network.atm.vpi<span class="o">=</span><span class="s1">'0'</span>
uci <span class="nb">set </span>network.atm.vci<span class="o">=</span><span class="s1">'33'</span>
uci <span class="nb">set </span>network.wan.proto<span class="o">=</span><span class="s1">'dhcp'</span>
uci del network.wan.username
uci del network.wan.password
uci commit network
reboot
</code></pre></div></div>
<p>After rebooting and giving the DSL-sync some time, <code class="highlighter-rouge">/etc/init.d/dsl_control status</code> shows the configuration in use.</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>/etc/init.d/dsl_control status
ATU-C Vendor ID:
ATU-C System Vendor ID:
Chipset: Ifx-AR9
Firmware Version: 4.6.1.7.0.1
API Version: 3.24.4.4
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0
Annex: A
Line Mode: G.992.5 <span class="o">(</span>ADSL2+<span class="o">)</span>
Profile:
Line State: UP <span class="o">[</span>0x801: showtime_tc_sync]
Forward Error Correction Seconds <span class="o">(</span>FECS<span class="o">)</span>: Near: 0 / Far: 0
Errored seconds <span class="o">(</span>ES<span class="o">)</span>: Near: 4 / Far: 1
Severely Errored Seconds <span class="o">(</span>SES<span class="o">)</span>: Near: 1 / Far: 1
Loss of Signal Seconds <span class="o">(</span>LOSS<span class="o">)</span>: Near: 0 / Far: 1
Unavailable Seconds <span class="o">(</span>UAS<span class="o">)</span>: Near: 29 / Far: 29
Header Error Code Errors <span class="o">(</span>HEC<span class="o">)</span>: Near: 1102 / Far: 16
Non Pre-emtive CRC errors <span class="o">(</span>CRC_P<span class="o">)</span>: Near: / Far:
Pre-emtive CRC errors <span class="o">(</span>CRCP_P<span class="o">)</span>: Near: / Far:
Power Management Mode: L0 - Synchronized
Latency <span class="o">[</span>Interleave Delay]: 0.25 ms <span class="o">[</span>Fast] 0.50 ms <span class="o">[</span>Fast]
Data Rate: Down: 27.446 Mb/s / Up: 1.291 Mb/s
Line Attenuation <span class="o">(</span>LATN<span class="o">)</span>: Down: 0.0 dB / Up: 6.2 dB
Signal Attenuation <span class="o">(</span>SATN<span class="o">)</span>: Down: 0.0 dB / Up: 0.0 dB
Noise Margin <span class="o">(</span>SNR<span class="o">)</span>: Down: 6.0 dB / Up: 6.2 dB
Aggregate Transmit Power <span class="o">(</span>ACTATP<span class="o">)</span>: Down: 8.1 dB / Up: 6.1 dB
Max. Attainable Data Rate <span class="o">(</span>ATTNDR<span class="o">)</span>: Down: 27.352 Mb/s / Up: 1.335 Mb/s
Line Uptime Seconds: 11
Line Uptime: 11s
</code></pre></div></div>
<p>As a result, OpenWRT is able to create a stable DSL-connection, while the wireless interface (ath9k) is supporting almost all IEEE 802.11 MAC schemes (IBSS, mesh, etc.).</p>
<h2 id="conclusion">Conclusion</h2>
<p>All tests show promising results. The initial idea of creating a DSL-network using cheap AVM boxes running on USB powerbanks looks surprisingly realistic. OpenWRT can be used as well as stock firmware. Both L2TPv3 and Tinc are able to spawn usable overlay networks, but only L2TPv3 is able to provide the full downlink capacity of an ADSL2+ annex M link.</p>
<p>As suspected before our tests, the choice between OpenWRT and stock firmware boils down to using IBSS / 802.11s versus FXS / DECT. Both configurations appear to be realistic at this point in time. A more powerful but hungry Arcadyan ARV752DPW22 is a - yet untested - alternative.</p>
<p>Future work is probably going to focus on user-experience and field testing:</p>
<ul>
<li>Are signal corps of volunteer-driven relief organizations able to set up the network without help from IT-professionals?</li>
<li>Given, that one can operate either mesh or POTS on a AVM 7312: What is the tactical choice? Is it reasonable to introduce additional complexity by having boxes with different configurations? Are cheap Android SIP Phones a tactical alternative to POTS-ones?</li>
<li>What are the DSL signal characteristics of field wire (400m, 800m, 1-pair, 2 pairs)? What is the resulting TCP goodput?</li>
</ul>
<p>That’s it. Happy hacking ;-).</p>Altough our first field test went well, the network infrastructure has still room for improvements. This article explains some ideas for integrating a Digital Subscriber Line (DSL) based network into field tracks and their evaluation.JellingStone v1.0.0 released2019-07-27T19:47:18+02:002019-07-27T19:47:18+02:00https://fieldtracks.org/releases/2019/07/27/JellingStone-release<p>We have just released JellingStone v1.0.0. Downloads are available at
<a href="https://releases.fieldtracks.org/JellingStone">https://releases.fieldtracks.org/JellingStone/</a>.
The binaries are used by Flashtool and fieldmon for provisioning.</p>
<p>Version 1.0.0 supports beaconing, scanning, and transmitting results over mqtt \o/.</p>
<p>Have fun 😉.</p>We have just released JellingStone v1.0.0. Downloads are available at https://releases.fieldtracks.org/JellingStone/. The binaries are used by Flashtool and fieldmon for provisioning.Outlining components, network architecture and design2019-07-07T19:47:18+02:002019-07-07T19:47:18+02:00https://fieldtracks.org/technical/2019/07/07/network<p>Implementing an indoor localization system such as Fieldtracks includes designing a network
infrastructure for transporting and processing sensor data. This blog post outlines its design and challenges.</p>
<!--break-->
<h3 id="components">Components</h3>
<p>From a bird’s-eye view, the Fieldtracks system consists of several components,
illustrated in figure 1:</p>
<figure>
<a href="/assets/birds_eye.svg">
<img src="/assets/birds_eye.svg" alt="Components in Fieldtracks" />
</a>
<figcaption>Fig. 1: Components in Fieldtracks</figcaption>
</figure>
<p>Typically, users access the system using smartphones and laptop computers:</p>
<ul>
<li>When using a smartphone, users broadcast their position using Bluetooth Low Energy (BLE) beacons. These beacons are received by JellingStone when scanning.</li>
<li>The graphical user interface (Fieldmon) is accessible using https. Optionally, Fieldmon
can be installed as a Progressive Web Application (PWA).</li>
</ul>
<p>BLE scanning and additional beaconing is implemented by JellingStone using ESP32 µControllers.</p>
<p>Message Queuing Telemetry Transport (MQTT) is used as a distributed middleware system. It provides
publish and subscribe interfaces to JellingStone and Fieldmon and takes care of data propagation
and retaining scanning results.</p>
<p>Besides MQTT, a nginx service is used to provide basic storage functionality. This includes
serving Fieldmon’s artifacts and assets. It is not used for scanning data or results.</p>
<p>Flashtool and StoneAggregator are the two backend processes used in Fieldtracks.</p>
<ul>
<li>The Flashtool is installed on portable computers (e.g. Raspberry Pi) to provision
ESP32 devices plugged in locally. It is controlled using Fieldmon.</li>
<li>The StoneAggregator provides data transformation. Data received from MQTT
is aggregated and distributed using retained messages.</li>
</ul>
<h3 id="network-architecture">Network architecture</h3>
<p>In essence, the network has to be designed to provide MQTT-connectivity in a robust and scaleable manner. A few requirements exist for the network, that have to be reflected in its architecture:</p>
<ol>
<li>The network must provide IP-connectivity for ESP32 devices using wireless lan (IEEE 802.11). Focusing on indoor deployments, the network is also utilized by users accessing Fieldmon.</li>
<li>The network has to scale according to the people taking part in a field exercise.
It has to handle up to ~1000 devices.</li>
<li>Smartphone users roam between regions with and without cellular connectivity (3G / 4G / 5G).
Fieldmon and MQTT have to be accessible using the public internet as well as a local on-site network.</li>
<li>Labyrinthine environments (e.g. old mines) are rather unfriendly radio environments shadowing
stations. Thus, the network has to deal with highly unstructured mesh connections resulting in
potentially large layer-2 segments.</li>
</ol>
<p>Figure 2 illustrates the networking architecture. It contains cloud- and on-site services, an on-site network and a vpn.</p>
<figure>
<a href="/assets/img1.svg">
<img src="/assets/img1.svg" alt="Networking architecture" />
</a>
<figcaption>Fig. 2: Networking Architecture</figcaption>
</figure>
<p>The <em>on-site network</em> is a heterogeneous mesh network. It connects mobile terminals (e.g. smartphones)
and JellingStone sensors (not shown). Different technologies can be used for implementing the on-site networks. Due to providing IP-connectivity, it can be built using ethernet cabling (e.g. Cat5) and more eccentric technologies such as 802.11s, vlans, MPLS or DSL.
IPv4, DHCP and NTP services are provided within the network.</p>
<p>If a site has internet connectivity (e.g. LTE / DSL), an <em>on-site vpn uplink</em> is
used, to connect the on-site network to additional servers in the cloud. If multiple, distinct uplinks are available, the vpn is used to support roaming
within the on-site network.</p>
<p>MQTT and WebDAV can be hosted on site (<em>on-site-services</em> - e.g. using a raspberry by) or cloud-based
(<em>cloud services</em>) using virtual machines or both in parallel. This creates an unified,
omni-channel view. <em>Mobile Terminals</em> can seamlessly access Fieldmon using any network.</p>
<h3 id="network-design-and-implementation">Network design and implementation</h3>
<p>Implementing the actual network has both simple and challenging tasks.
On the one hand, using just MQTT and WebDAV, there is no need for a sophisticated middleware
including many services. On the other hand, integrating cloud- and on-site services while
providing a consistent and unified view is challenging.</p>
<p>In its simplest form, a Fieldtracks network consist of a commercial, of-the-shelf LTE hotspot connecting a dozen of ESP32 devices to a MQTT-Broker running on a cloud based virtual machine.</p>
<p><a href="https://github.com/freifunk-gluon">Gluon</a> appears to be a promising framework for implementing the on-site network. Using batman-adv, 802.11s and VPN-services Fieldtrack’s requirements are
reflected in many Freifunk networks. It also focus on non-expert users. However, its single channel mesh approach introduces limits on client density.</p>
<h3 id="summary">Summary</h3>
<p>Using just MQTT and WebDAV, Fieldtracks poses rather simple requirements
to the network infrastructure. Deploying a scalable network for a field exercise is a
challenging task, still. MQTT’s distributed capabilities make it interesting for hybrid cloud- and
on-site deployments.</p>Implementing an indoor localization system such as Fieldtracks includes designing a network infrastructure for transporting and processing sensor data. This blog post outlines its design and challenges.Meetup (monthly)2019-06-10T19:47:18+02:002019-06-10T19:47:18+02:00https://fieldtracks.org/events/2019/06/10/meetups<p>We’ve established a monthly meetup:</p>
<ul>
<li>Date: 4th Wednesday each month</li>
<li>Place: <a href="https://koeln.ccc.de/c4/faq/index.xml#anreise">C4 (CCC Cologne)</a></li>
<li>Time: 19h</li>
</ul>
<p>Please contact <a href="mailto:dev@fieldtracks.org">dev@fieldtracks.org</a> if you are interested.</p>We’ve established a monthly meetup:Hackathon2019-04-07T19:47:18+02:002019-04-07T19:47:18+02:00https://fieldtracks.org/events/2019/04/07/hackathon<p>We are going to have a small hackathon next weekend. We’re going to start
at 2019-04-13 11:00 CEST. Location: <a href="https://koeln.ccc.de">https://koeln.ccc.de</a></p>
<p>Please contact <a href="mailto:dev@fieldtracks.org">dev@fieldtracks.org</a> if you wanna join us.</p>
<p>Happy Hacking 😉</p>We are going to have a small hackathon next weekend. We’re going to start at 2019-04-13 11:00 CEST. Location: https://koeln.ccc.de