Synology Reverse Proxy with DSM 6.0

The latest Synology DSM 6.0 version now supports out of the box reverse proxy configuration. So no need to build and edit internal configuration files. Everything can be done now on the DSM web frontend.

To configure the reverse proxy we need to go to the DSM web application, select the Control Panel and then the Application Portal icon:

Application portal Configuration

Application portal Configuration

We can see that I already have some applications configured and with the HTTP internal ports defined. For example the Notes application is accessed internally by the URL http://diskstation:9350. Note that I haven’t defined a HTTPS port because I’ll use the reverse proxy as the HTTPS frontend.

So we take note of the ports for the applications that we want to make available at the reverse proxy, in my case the port 9350 for the Notes application, and create a new reverse proxy configuration by selecting the Reverse Proxy tab and pressing the Create button:

Notes Reverse Proxy Configuration

Notes Reverse Proxy Configuration

Take note of the following:

– I’m using one of the available domains provided by synology
– The Synology domains, at least the supports sub-domain wildcarding.
– So I can have the as my main domain
– And I can have all subdomains below the, like, for example,

So I will make the Notes application available at the and that is the hostname that I need to define under my reverse proxy configuration.

So with the above rule all requests to will be routed to the localhost server running on the port 9350…

And that’s it. Just make another set of rules for the other application under their own sub-domains.

Edit: The following configuration shows the Note Station, File Station and Video Station reverse proxy configuration that allows those “apps” to be accessible from the external IP. Note that this means that port 80 (plain HTTP, if used) and port 443 (HTTPS) must be forwarded on the router configuration to the Synology internal IP:


In my case only HTTPS is used, so I’ve not forwarded the port 80 from the external interface of the router to the Synology.

MQTT Mosquitto broker with SSL/TLS transport security

Just a quick note in setting up transport layer security on the MQTT Mosquitto broker for both supported protocols: MQTT and WebSockets.

There are several posts on the web regarding this, namely:

SSL Client certs to secure mqtt and Mosquitto websocket support

Those posts explain more or less what is needed to be done to have TLS/SSL transport security. These are just my notes:

Generating the server certificates:
This can be quite easily accomplished by using the following script:
This script will generate a self signed certificate to be used by Mosquito for providing TLS for the MQTT and WebSocket protocol. All that is needed to run the script is to have openssl installed on your Linux machine.

If the script is called without parameters, it will generate a self signed certificate for the hostname where the script is running. Otherwise a we can pass a hostname as the first parameter to the script.

After running the script, the following files are generated:

  1. ca.crt – The CA (Certificate Authority, who published the host certificate) public certificate.
  2. hostname.crt – The hostname, that will run the mosquitto broker, public certificate.
  3. hostname.key – The hostname private key.

After having these files, we need to configure the Mosquitto Broker to use them.

Mosquitto configuration:
To configure the Mosquito broker we need first to copy the certificates and key files to a known directory. We will create a certs directory under /etc/mosquitto:

sudo -s
mkdir -p /etc/mosquitto/certs
cp ca.crt /etc/mosquitto/certs
cp hostname.* /etc/mosquitto/certs

After this we can modify the mosquitto configuration file. One important thing to keep in mind is that lines must be following each other without blank lines after the listener directive.


# Plain MQTT protocol
listener 1883

# End of plain MQTT configuration

listener 8883
cafile /etc/mosquitto/ca.crt
certfile /etc/mosquitto/hostname.crt
keyfile /etc/mosquitto/hostname.key

# End of MQTT over TLS/SLL configuration

# Plain WebSockets configuration
listener 9001
protocol websockets

# End of plain Websockets configuration

# WebSockets over TLS/SSL
listener 9883
protocol websockets
cafile /etc/mosquitto/ca.crt
certfile /etc/mosquitto/hostname.crt
keyfile /etc/mosquitto/hostname.key

We will make one more change, but restart mosquitto broker now and do some testing.

Testing MQTT TLS/SSL configuration
We can use Mqtt-Spy to subscribe to our defined test topic: test. We can use plain MQTT or use MQTT over TLS/SSL:

MQTT Spy simple TLS configuration

MQTT Spy simple TLS configuration

We can use then the MQTT spy tool to publish or subscribe MQTT topics.

By command line, the mosquitto_sub and mosquitto_pub only worked if the port number for MQTTS is provided, otherwise it gives a TLS error:

mosquitto_pub --cafile /etc/mosquitto/ca.crt -h localhost -t "test" -m "message" -p 8883

mosquitto_sub -t \$SYS/broker/bytes/\# -v --cafile /etc/mosquitto/ca.crt -p 8883

This should work without any issues.

Testing MQTT websockets over TLS/SSL configuration
The issue with this testing is that we are using a self signed certificate, so only useful for local, restricted, testing.
Before we can use the MQTT websockets with TLS/SSL enabled we need to use the browser and visit the following URL:


Note that we are using HTTPS. When connecting to the above URL, the browser should complain about the insecure connection, due to the self signed certificate, and we need to add an exception and always accept that certificate. After that the error should be something like connection reset or failed to load page. This is normal, since the browser won’t upgrade the connection to a web socket.
We can now use the Hive MQTT Websockets Client to test our connection, and it should work fine (Note the connected green icon and SSL is selected):
Hive MQTT WebSocket client

Forcing TLSv1.2
All this work of enabling TLS/SSL on the Mosquitto Broker is needed, since most IoT clouds that have MQTT interface need that the connection is over TLS/SSL. More specifically AWS IoT cloud needs the connection to be protected by TLS/SSL, but that connection must be only on version 1.2 of the TLS protocol. AWS IoT cloud also requires client authentication through client certificates, but we are not dealing with this part on this post.

So we are now configuring our Mosquitto broker to only accept TLSv1.2 connections. To do that we modify the mosquitto.conf file and add the following line:

listener 8883
cafile /etc/mosquitto/ca.crt
certfile /etc/mosquitto/hostname.crt
keyfile /etc/mosquitto/hostname.key
tls_version tlsv1.2

# WebSockets over TLS/SSL
listener 9883
protocol websockets
cafile /etc/mosquitto/ca.crt
certfile /etc/mosquitto/hostname.crt
keyfile /etc/mosquitto/hostname.key
tls_version tlsv1.2

and restart the broker.

Testing TLS V1.2
We can specify the TLS version on the mosquitto command line utils:

[pcortex@pcortex:~]$ mosquitto_pub --cafile ./ca.crt --tls-version tlsv1.2 -h localhost -t "test" -m "mes" -p 8883 -d
Client mosqpub/26994-pcortex sending CONNECT
Client mosqpub/26994-pcortex received CONNACK
Client mosqpub/26994-pcortex sending PUBLISH (d0, q0, r0, m1, 'test', ... (3 bytes))
Client mosqpub/26994-pcortex sending DISCONNECT
[pcortex@pcortex:~]$ mosquitto_pub --cafile ./ca.crt --tls-version tlsv1.1 -h localhost -t "test" -m "m3224" -p 8883 
Error: A TLS error occurred.

As we can see the lower versions of the TLS protocol are now not accepted.
The Websockets client should work without any issues.

This configuration only solves the transport security, not the authentication security. The later can be accomplished by using the username/password process or using client certificates, which is the process that Amazon AWS IoT cloud uses. But that is topics for another post.

Sigfox BackEnd – Receiving and processing data

The Sigfox network provides a backend service where all Sigfox network devices messages are received and where the client/customer can pick up data from it’s own devices through using a REST API. But using the REST API means that we need to  pool for messages, which is not very efficient.

Another alternative provided by the SigFox backend is a callback mechanism. The callback mechanism can be done through email, where the data is sent by email to the destination, or through an HTTP call to a client/customer owned server. In my case I’ve used a open access IBM Node-Red Server available on the Internet as my own callback server, to process the call backs.

With IBM Node-Red we can easily  bridge the HTTP callback call to a MQTT topic publish. With this HTTP-MQTT bridge it means that every HTTP callback generates an MQTT publishing event, and any subscriber listening to the associated topic receives the Sigfox message. From here we can do whatever we want, and still using Node-Red, we can process the data, or store the data on databases, like InfluxDB where we can then use Grafana to graph the data.

Callbacks to the client/customer private server can be of type Uplink or Bidirectional. In the first case the private server just receives the data. On the second case the backend server, receives the data and responds with something meaningful that is sent to the device, if the device asked for a downlink response.
The response of the private backend server to the Sigfox backend server must be under 10s, otherwise the Sigfox servers will call one more time before raising an error. Also the downlink responses to the devices are, as far as I’m aware, not sure on this, limited to 12 messages per day.

For the callback configuration we have the following screen:

SigFox Callbacks

So an email callback definition for processing incoming data (uplink) from the device by receiving data and sending an email can be as follow:

Sigfox email uplink callback

Or we can call a backend server and return a response to the device if requested. The call can be made through a GET request where the message parameters are sent on the query string, or through the POST or PUT method where the body can be a JSON body with the data:

SigFox HTTP Callback

To let the above callback to define the return data to the device, when a downlink message is requested, we must change the device configuration:

Device Configuration

Otherwise, when direct mode is defined, the access point ID and RSSI is returned.

Also for the HTTP callback, there is the possibility of a HTTP batch callback, where several device messages that arrive in one second at the Sigfox backend, are grouped in a single callback call. This avoids heavy load on the call back private server.

Sigfox Callback to MQTT bridge:
This is rather simple to build with Node-Red:
Node-Red MQTT bridge

[{"id":"2a552b3c.de8d2c","type":"mqtt-broker","broker":"","port":"1883","clientid":"node-red"},{"id":"46ac4f4b.659e48","type":"http in","z":"fdd8cabf.2bfe1","name":"","url":"/cback","method":"post","swaggerDoc":"","x":254.1666717529297,"y":113,"wires":[["f6d8300b.c1777","9c710907.61bd5","7f610b6a.5f6aac"]]},{"id":"f6d8300b.c1777","type":"http response","z":"fdd8cabf.2bfe1","name":"response","x":507.1666717529297,"y":113,"wires":[]},{"id":"9c710907.61bd5","type":"debug","z":"fdd8cabf.2bfe1","name":"","active":true,"console":"false","complete":"true","x":515.1666717529297,"y":205,"wires":[]},{"id":"7f610b6a.5f6aac","type":"mqtt out","z":"fdd8cabf.2bfe1","name":"MQTT Out","topic":"/sigfox/messages","qos":"","retain":"","broker":"2a552b3c.de8d2c","x":517.1666717529297,"y":289,"wires":[]}]

So we now define the callback as a POST call with a JSON object to the /cback path as defined on the HTTP input node as it can be seen on one of the above screenshots. The URL to be defined on the callback definition should be something like: http://node-red-ip:1880/cback

So now every Sigfox message activates a callback to the Node-Red HTTP Post node, and the message is routed to a MQTT out node for the /sigfox/messages topic.

An example of a received message by Node-Red is:

msg.payload : Object{ "device": "12345", "data": "12345566", "time": 1455758443, "rssi": "-124.80", "station": "0111", "snr": "20.68", "avgSnr": "23.34" }

So all is needed now is to process the data field from the JSON object and do something with the data.

For more information regarding callbacks, check out: SigFox Callback Documentation

Some Sigfox tests

So I’m doing some tests with the SigFox enabled Akeru board. This board has an ATMega 328, with bootloader, that makes it compatible with Arduino, and also has a SigFox TD1208 modem connected through serial to pins 4 and 5.
From every aspect that we can think this board, excluding the reserved 4 and 5 pins, works as a standard Arduino Uno R3 board, or clone.

The TD1208 chip, that enables communication with the SigFox network also has some other features available. One of them is the capacity to form some kind of a short range wireless based network with a maximum of 15 devices. This capability allows communications with, probably, other TD1208 chips and family (TD12XX), for a local wireless sensor network where one of the TD1208 devices act as a centralized gateway.. Since I don’t have any other TD1208 chips or boards with that chip or with compatibility for this network, I’m unable to try it. But it is worth a mention.

Also the TD1208 chip has an embedded ARM processor, which means that the TD1208 can be used by itself without the Arduino part. Still the Arduino way to use a serial port to communicate to the TD1208 chip is way easier that develop a native program for the TD1208. Check out this link for further information: TD1208.

Send data to SigFox
With this board there is nothing special to be done to send a message to the SigFox netowrk, and receive it at the backend. Still there are some things worth mention.

The simplest program:

#include <SoftwareSerial.h>
// To communicate with the embedded TD1208 Sigfox module, we use
// serial communications. The pins 5 and 4 are reserved on the
// SnootLab Akeru board.
// Pin 5 is RX
// PIN 4 is TX

const int SigFox_TD1208_RX = 5;
const int SigFox_TD1208_TX = 4;

SoftwareSerial sigfox( SigFox_TD1208_RX , SigFox_TD1208_TX );  

void setup() {
  Serial.println("Starting Sigfox Serial");  
  delay(5000);   // (*1)

  Serial.println("Sending to sigfox");

  // The frames are a maximum of 12 hexadecimal bytes.
  sigfox.write("AT$SF=656667,2,1\n");   // (*2)

  Serial.println("Data sent...");

void loop() {
  // put your main code here, to run repeatedly:
  while(sigfox.available() ) {
    Serial.write( );

The code above looks and is simple enough, but needs some mentions:

We can see that (*1) there is a delay. I’ve found out that without the delay, at powering up the board (Not Reset!) the command to send data to the SigFox network fails. So this means that at power up, the TD1208 isn’t ready right away, and need some time to boot up. This makes sense since it has an ARM processor inside. Resetting the Arduino board, seems not to reset the TD1208, so without the delay, the above code doesn’t work at power up, but works fine after reset.

Sending data is also worth some mentions. Data can only be in Hexadecimal numbers, so bytes are from 0x00 to 0xFF.
So to transmit the word ‘Hello’ we need to send 0x48 0x65 0x6c 0x6c 0x6f:

   sigfox.write("AT$SF=48 65 6c 6c 6f\n");

The data is accumulated until the final new-line character: \n. Spaces are ignored.

This according to the TD1208 data sheet, will send the message twice to the network in probably two different frequencies.

If we want to receive a downlink message, we should pass two parameters to the AT command, first the number of transmissions (2 is the default and maximum value), and one for enable the request for the downlink. I didn’t found any information in how to set the downlink message, so it remains how to do that from the backend point. (Edit: it is callback controlled. See post: Sigfox – Processing Data )

   sigfox.write("AT$SF=48 65 6c 6c 6f, 2 , 1\n");

The results
Since I live in a dense urban area, results are excellent, but I’m not aware of how many gateway/base stations that I have at my area. I’ve only missed messages sent from underground (parking space), and even on of this cases, one of the messages did arrive, very weak, but it did.

What remains to be done?
Three things need to be done: A backend for processing the messages, but that is very easy to do with Node-Red, how to define, if possible, the downlink message, and how to enable and process events from the TD1208.
The TD1208 supports events for monitoring battery voltage, RSSI, temperature, but it seems it is for a TD1208 LAN based topology, not for the Sigfox network.

Low Power and Long Range Communications for IoT devices – SigFox

I was able to attend the SigFox Maker tour in Lisbon: SigFox Makers Tour, where Sigfox explained what it offers, and allowed a hands on approach to long range/low power communications by using a evaluation board from SnootLabs, the Akeru Beta 3.3. As we can see from the previous link, this is an expensive way of entering the long range/low power communications field, so it came (more or less) as a surprise that the board could be kept by the attendees.

SigFox is not alone on this market of M2M (machine to machine communication) where low power and long range is needed. Other contenders are the LoraWan alliance (Lora Alliance) with one open source, crowed sourced network in the making: The Things Network, the more closed Weightless M2M, and many others, like future 5G and LTE-M. Anyway, this is not the main topic of this post, let’s see the what SigFox is all about.

The problem:
Why long range and low power is needed for IoT? IoT is a greater set of a smaller subset of machine to machine communications (M2M from now on). IoT implements the structure, the applications over the devices that communicate and generate data. Think of Google or NetFlix as the IoT part, and TCP/IP, cables, fiber, as the M2M part. IoT can’t exist if devices can’t communicate. But most of the communication forms existing today requires power and vicinity to a communication gateway. Wifi devices need to be near a Wifi access point, Bluetooth, the same, other forms of communication, like Zigbee also need this. They also need large quantities of power, connected to mains, or need to have batteries to be recharged frequently.

So a solution for long range: distance between the device and the gateway can be Kms/Miles, and low power, batteries last years, is needed. Just set a device with what sensors is needed, and it communicates for years using batteries and without any more intervention.

These are the issues where SigFox and all the contenders come to solve. The drawback? Well devices can only transmit small amounts of data at low bit rates and sparsely, but this is for Internet of things, not for Internet of Talking things…

Sigfox Solution:
A great explanation of the SigFox solution is on these slides: SigFox Basics.
In short, SigFox protocol uses the ISM (Instrumental,Scientific,Medical) radio band ( 868MHz in EU, 902Mhz in USA), with a Ultra Narrow band 100Hz signal across a set of 200Khz frequency, where it transmits a 12 byte message (maximum) at a duty cycle of 1% per day. This gives around 140 messages/day. This is enough for transmitting sensor data each 10 minutes.
The signal can be received by any base station on the vicinity, and is delivered to the SigFox backend, where is deduplicated, if necessary.
At the back end the message can be delivered to the final destination either by email (not very useful) or by an HTTP callback.
The HTTP Callback is the process where the SigFox backend servers call your web server, available on the internet, either by http:// ou https:// with a specific set of configured parameters on the http request.

At least with the provided board (the Akeru) the power consumption when transmitting is around 25mA and the it drops when idle to very low values, almost negligible. And this is not the most efficient platform. Also, I’m sure that I’m several Kms away from the gateway. Compare this with the ESP8266, where it uses around 150/300mA when communicating and needs to be around the access point in meters!. The tests that I’ve done so far where always successful in dense urban areas, and inside buildings.

Starting up:
After receiving the board, there is a chip/device id set on top of the Sigfox module. With this id and a PAC (key?) we need to register at the SigFox backend:
At the Makers event, things didn’t went well at first with this registration, but after some fiddling from Sigfox part, it went OK. Still I see a major issue here on the provisioning process of new devices, if this process is needed to be done one by one… There is probably another way of connecting/registering devices on the Sigfox backend.
After the device is registered, with just one command, we can send data to the network.

Hands on
So a quick hands on: The Akeru board is an Arduino Uno compatible board and behaves as one. So we use the Arduino IDE. The only difference is the TD1208 SigFox modem (if we can call it that) on board, and with the serial lines connected to pins 5 and 4.
The TD1208 AT command set is available at this page: Documentation
The following Arduino program, loops over the serial ports, and allows to use the computer to communicate with the TD1208 module across the Arduino board.
I used the command picocom -b 9600 /dev/ttyUSB0 on my computer to communicate to the board:

#include <SoftwareSerial.h>
// To communicate with the embedded TD1208 Sigfox module, we use
// serial communications. The pins 5 and 4 are reserved on the
// SnootLab Akeru board.
// Pin 5 is RX
// PIN 4 is TX

const int SigFox_TD1208_RX = 5;
const int SigFox_TD1208_TX = 4;

SoftwareSerial sigfox( SigFox_TD1208_RX , SigFox_TD1208_TX );  

void setup() {
  // put your setup code here, to run once:
    Serial.begin(9600);   // For Computer communication
    sigfox.begin(9600);   // For talking with the embedded TD1208 module

void loop() {
  char c;
  if (sigfox.available() ) {
  if (Serial.available() ) {

The command ATI shows the board information:

Telecom Design TD1208


The command AT&V shows more information, like the firmware version, and device serial:

Telecom Design TD1208
Hardware Version: 0F
Software Version: SOFT1451
S/N: 0007xxxx
TDID: 0xxxxxxxxx
E1 V1 Q0 X1 S200:0 S300:24 S301:2 S302:14 S303:1 S304:20 S305:25 S350:0 S351:32768 S352:1 S353:10 S400:000000 S401:FFFFFF S402:0 S403:869412500 S404:14 S405:32 S406:1

The ATI command can have some parameters, like 26, the current environment temperature, 27, the current voltage level, and 28, the voltage level when transmitting, when it’s drawing power from the power source. After reboot and without any transmission made, the ATI28 command returns zero.

To transmit a message, 12 bytes maximum!, we use the command AT$SS. The transmission data is Hexadecimal numbers, not ASCII. So AT$SS=Hello is invalid…

So to transmit data we will need to build our data by bit masking and bit concatenation to have data packed as efficiently as possible. For example the temperature for a room can be packed in 4/5 bits. Let’s see the Sigfox TD1208 module in action:

ATI28     <- Voltage when transmiting. Is zero after restart.


AT$SS=10203040  <- Send message 0x10 0x20 0x30 x040 to the network.
3.31      <- Voltage when transmitting the previous frame. No drop due to be power up by USB...


After the transmission, I’ve defined at the backend a email call back with all the possible data to be sent to my address. This is the result:

Device: 7xxxx
Time: 1455432456
Dup: false
SNR: 15.64
Station: 01A4
Data: 10203040
AvgSnr: 21.65
Lat: 49
Lng: -19
RSSI: -134.20
Seq: 22

As we can see the received signal strength (RSSI) at the receiving gateway was at an amazing -134.20 DBm!! This is an extremely low power signal. Wifi stops working around -80DBm, and that is at distances around meters.

The Akeru board works fine and it’s easy to program. Still navigating the backend side is a bit of an hit or miss (topic for other post), but its functional.
Due to the network coverage on all Western Europe, free roaming for the devices, low power and long range, SigFox offer can make a dent on solutions that depend on GPRS or other competing solutions. This means that Sigfox is a readily available solution for some Enterprise/Startup uses/solutions that need low power, long range and free roaming with an established network.
Still the pricing for access the network is opaque (1€ to 20€/year, but per device, number of devices, company,startup?).

Also the maker community that is not able to access these Maker tours, where the hardware is free and can be kept, has a steep entry price. The entry kit is expensive and only offers a one year free fee to access the network. This can hinder the investment on the SigFox solution from individual Makers, and that, in my opinion, is the major issue.

ODroid C2

As an owner of an Odroid C1+ that is a great little device, it came to my knowledge it it might now be obsolete:)

This is because the Odroid C2 has came out: Odroid C2, and if I think that the C1+ is great, what to tell about the C2, that is around the same price point?

The specifications:

64bit S905 ARM quad-core 2GHz processor
2GB of RAM !
HDMI 2.0 with 4K support (not that it matters for me… )
Gigabit Ethernet, as the C1+
eMMC support.
Several other tid bits very similar to C1+.
Missing RTC.

So a major leap forward from the C1+ and from the RPi.

The 40$ price in Europe is no near that value, but probably around 50/55€ mark, my guess ( + P/P). Also the eMMC prices are still very high, almost, or even higher, than the price of the board itself.

Still I’m a bit wary of buying one since HardKernel (the Odroid manufacturer) only provides a 4 week warranty !? I bought mine in Europe, so I suppose it has a 2 year warranty by law.

I had no problems with my C1+, but I wonder, if something goes wrong…