Proxying GWP Packets

GWP is the first protocol widely used by LoraWAN. It started out as a proposal from Semtech to prove the concept. Essentially GWP is just JSON wrapped in UDP.

It has become apparent that there is a need for a GWP proxy, not only to provide access for multiple gateways. but also to provide debugging. Using this GWP proxy it was possible to discover a design flaw in interoperability between the RAK2287 software and The Things Network. In the protocol specification it makes use of a ‘temp’ variable in the ‘stat’ data structure. Which RAK Wireless implemented.

The Things Network silently discarded the entire packet and reset the last seen counter. The result from this was the gateways current GPS position was also discarded, and incoming packets from devices would not be stamped with the GPS co-ordinates.

The GWP proxy can be found on GitHub.

Because this was a quick implementation, it lacks some features. It will provide bi-directional communications. and all output is visible on STDOUT.

The RAK2287 Gateway can be found:

Packet Forwarder Protocol

Github Issue

Remote Desktop Gateway Certificates

When installing RD Gateway Certificates using the server manager snapin. If the error ‘The WSMan provider host process did not return a proper response’ occurs. This error can be triggered by importing a PFX key bundle with no password.

The easiest way around it is to import the bundle into the local user store, then re-export with the password field set.

‘Certify the Web’ saves PFX files with no password. So if you are using a similar LetsEncrypt application to secure RD. This maybe your problem.

Translogix Importing

Translogix maybe built around Fox Pro 9. But importing and exporting data can at times be a tedious task.

Thankfully there are classes and interfaces that can be taken advantage of to get data in and out. To get data out you can either write a custom export, which will dump data to a syntactically correct xml or csv file. It can also render data to paper style reports.

Exporting data can also be accomplished through the Visual Fox Pro ADO drivers. These drivers are limited to x86 though, due to the age of Visual Fox Pro.

Importing data in must be completed through custom imports, Using ADO is not appropriate.

It is possible to import job data into Translogix. There are some caveats that have been encountered. You can import a job, with a complete dataset. However assigning a manifest number will add the job to the manifest. It will not populate the driver, rego, and trailer fields. If there is a requirement to add the job to a manifest. Passing the manifest specific driver, rego and trailer fields will be required.

This is because a ‘job’ also stores data about who and what is transporting it. Each time you change a manifest number the data is re-looked up. If a modification is done to a manifest on these fields. To update the data on the job it will need to be removed and added again to the manifest.

When importing a manifest, the same interface as the job import is used. However the man_type field must be set to ‘M’ ‘0x4d’ and the job_type field must also be set to ‘M ‘ that is ‘0x4d 0x20’.

Time Stamping

If you are after validation when a piece of data was generated and verified. It is possible to sign arbitrary data with a timestamp in the same way as Authenticode.

Why would you want to do this? In my scenario I have a scanned image database, This database contains all the Proof of Delivery documents for a large transport company. Suppose I want to sign all the inward images at the time they were first imported into the database.

This level of protection costs about 2kb per image, and will provide assurance that the image has not changed since the timestamp was signed. It would not provide protection if the file is resigned. You could employ some sort of anti-replay protection.

To get started, for the proof of concept, suppose we want to sign “testfile.txt” with the text abcdxyz inside

# openssl ts -query -data "testtimestamp.txt" -cert -sha256 -no_nonce -out request.tsq

This will result in the request file “request.tsq” being generated. Which is essentially the SHA256 hash of test file.txt.

000 30390201 01303130  0d060960 86480165  |09...010...`.H.e|
010 03040201 05000420  073f5622 473e0b6b  |....... .?V"G>.k|
020 3f485afe fcadff10  b281b8df be81e308  |?HZ.............|
030 882cf331 e667f068  0101ff             |.,.1.g.h...|

This file is now served to the time stamping service of our choice.

# cat request.tsq | curl -s -S -H 'Content-Type: application/timestamp-query' --data-binary @- -o response.tsr

You will then get a P7 response that contains the timestamp and signature of when the file signature was signed. This is the most important file to save for verification. You can also verify against the hashed request file, it will save you time when it comes to verifying large files.

The easiest way to display the signature time is through openssl again,

# openssl ts -reply -in response.tsr  -text

Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified

TST info:
Version: 1
Policy OID:
Hash Algorithm: sha256
Message data:
    0000 - 07 3f 56 22 47 3e 0b 6b-3f 48 5a fe fc ad ff 10   .?V"G>.k?HZ.....
    0010 - b2 81 b8 df be 81 e3 08-88 2c f3 31 e6 67 f0 68   .........,.1.g.h
Serial number: 0x1DAAB7B41F40C33E4F29A4CC09BF0582A684BFCD
Time stamp: Sep  1 01:10:50 2020 GMT
Accuracy: unspecified
Ordering: no
Nonce: unspecified
TSA: DirName:/C=SG/O=GMO GlobalSign Pte Ltd/CN=GlobalSign TSA for Standard - G2

If you have the root certificate file you can also verify the signature chain through this method.

Saved Signature Verification
# openssl ts -verify -CAfile ./bundle.cer -in response.tsr -queryfile request.tsq 
Using configuration from /usr/lib/ssl/openssl.cnf
Verification: OK

Verifying directly against source file
# openssl ts -verify -CAfile ./bundle.cer -data testfile.txt -in response.tsr 
Using configuration from /usr/lib/ssl/openssl.cnf
Verification: OK

Testing whether the timestamp becomes invalid
# echo abcxyy > testfile.txt && openssl ts -verify -CAfile ./bundle.cer -data testfile.txt -in response.tsr 
Using configuration from /usr/lib/ssl/openssl.cnf
Verification: FAILED
139911881494976:error:2F064067:time stamp routines:ts_check_imprints:message imprint mismatch

Please be aware that to verify your certificate bundle, you already need a working trust store. Whether you built that trust store manually by concatenating multiple root and intermediate certificates you wish to trust or using the system trust model.

As expected if your source file changes but your verifying the TSQ against the TSR then it will still return it is valid.

Zoneminder White Screen

I recently had a huge issue connecting to zone minder, only one computer was able to connect to the web service. I also have a couple of video wall 4k displays where the video footage is being live displayed.

Because of the video wall displays I knew the issue was not with Zoneminder, PHP, Mysql, or any other component responsible for rendering the mjpeg displays. What I eventually found via the terminal was a obscure entry in the syslog.

Running while refreshing the ZM server :-
tail -f /var/log/syslog

I was able to see a error in the syslog, No skin found for ”. This in turn led me to set the theme in the http webrequest by instead of going to You will need to append ?skin=classic

The root cause of this issue is this. Zoneminder can’t find the default skin ”. This is because in your options, there is no default skin set. Why it continues to work on some browsers is because the skin name is also saved to a cookie. zmSkin.

So when you goto the URI with ?skin=classic. this tells zone minder what skin you want to use. Open options and set the SKIN_DEFAULT parameter to classic. and you should not see this issue again.

Excel VBA Signing

Today I experienced a strange issue signing Excel VBA code.


From the VBA editor, when you choose your certificate through Tools\Digital Signature. Ecel would complain about not having any valid signing certificates. However there was one issued by our corporate PKI.


The cause of this problem, was due to the fact that Windows had two entries in the personal certificate store (certmgr.msc). One of the entries was the Public Key only. The other was the Public + Private key bundle.

Excel must during its certificate enumeration process read the Public Key only certificate. Determine it has no private key, then move onto the key bundle and determine that the public component is the same as what was already evaluated as invalid for signing.

This issue can occur by importing all the certificates provided in the .zip from your nominated registrar. You should only ever need to import the single certificate that contains the Public and Private keys. You should not need to install the Root certificate that comes with your certificate bundle. If you paid for a trusted certificate then it should already be trusted by Windows.


Delete any certificates entries that do not contain a private key and share the same public key information as your code signing certificate.

Netvox and The Things Network

In order to connect a Netvox sensor to The Things Network. First, you have to connect the device somewhere, then you can send it a downlink message over the air. that will reconfigure its parameters. Fortunately, most gateways can be put into a local operation mode to facilitate over the air programming. The documentation that is distributed with the Netvox R311W wireless Water detector on this topic is very vague. To connect it into your LoraWAN infrastructure. Use the AppKey, AppEui from the box.

For the RAK7258 in built LoRa Network Server.
Create a new application and enter the AppKey and AppEui provided on the box. For the simplicity of configuration turn on Auto Add LoRa Device.
Startup the R311W and all going well the device should auto register to the gateway.

The next step is to create a device in The Things Network console. Once the device is created, edit its settings. Make sure it is set to OTAA. and overwrite the DevEui and AppKey with the parameters found on the devices box. The AppEui will not be able to be modified. and this is why we needed to connect it earlier to our gateway.

Back in the RAK7258 open up the application you created. In the downlink area, this is where we create the packet and queue it to transmit. In the specifications for these particular commands, they require high bandwidth. So you need to be fairly close relatively speaking.
To prepare the AppEui change.

Turn on confirmed
FPort 8
HEX Bytes 03 00 01 02 03 04 05 06 07 00 00 00 00 00 00 00 00 SEND
HEX Bytes 83 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SEND
This will change the AppEui to 0001020304050607. So substitute this for the AppEui from The Things Network.
To complete the command either wait for the next transmit window, or press a button on the side.
After the device connects and the downlink packets are delivered. Connecting to The Things Network can be completed by power cycling the device by removing the batteries. If there is no Things Network gateway available the device will not activate.

Once you have the device connected to The Things Network. It is possible to downlink messages there to configure other aspects of the device. This process is also device agnostic and should work for all Netvox devices.