New MultiTech packet forwarder available

Gateways MultiTech Gateways
1

After months of testing I’ve made the new multi protocol packet forwarder for MultiTech available. The new forwarder is based on poly packet forwarder but additionally supports the TTN gateway connector protocol which provides authentication of the gateway (packets from these gateways will include a ‘trusted’ flag in the metadata) and is TCP based.

This packet forwarder provides support for the new SPI based LoRaWAN mCards from MultiTech as well.

The install script, which also allows upgrading poly packet forwarder based installs, is available at https://raw.githubusercontent.com/kersing/multitech-installer/master/installer.sh

12 Likes
2

Great!! I have installed and will be able to further test tomorrow.

Thanks

3

Well its installed, the log is empty (no errors) but TTN is showing a last seen value which keeps increasing so not sure its wowking properly…

4

Working now … for some reason server_address was empty in the config file.

5

NOTE TO ALL:
During registration of a new gateway in the TTN console the gateway field is NOT set. After registering the gateway, go to the settings and make sure to set the gateway to the correct value for your region.

I have filed a ticket in the hopes this gets resolved.

edit: in the mean time I’ve added a check to the installer to alert the user (and not proceed) if the value is not set.

6

Well I am still having issues but not sure if its related to the new packet forwarder…
Basically the OTAA process is not completing. I see the Activation request arrive in TTN but following that nothing happens. All firewall ports are open and I see inbound and outbound traffic on port 1883 of the MultTech. However I see no traffic in any direction on port 1700.

7

ABP seems to work fine so looks to be an issue with OTAA and maybe the new packet forwarder ?

8

You should not see any traffic on port 1700 that is the ‘old’ protocol, all traffic on TTN is on port 1883 using the new protocol.

Where in TTN do you see the activation request? In the application data or in gateway traffic?

OTAA with the new packet forwarder has been extensively tested. Just be to sure I ran another test right now and it worked without any issues.

9

I see it in the Gateway Traffic

10

Please check the app eui and dev eui to see if they match the information registered in the console for your application. If they match you should see the the activation request in the application data as well.

11

They match but I dont see the activation response in the application data, only the request

12

In the gateway log do you see a message ‘INFO: [down] TTN received downlink with payload’? If so the gateway is getting a response. Next step would be to look at the statistics, you should see something like:

# RF packets sent to concentrator: 2 (0 bytes)
# TX errors: 0
# TX rejected (collision packet): 0.00% (req:2, rej:0)
# TX rejected (collision beacon): 0.00% (req:2, rej:0)
# TX rejected (too late): 0.00% (req:2, rej:0)
# TX rejected (too early): 0.00% (req:2, rej:0)

Where the RF packets should be unequal to zero and the TX errors should be 0 and TX rejected … should be 0.00%.

13

Yes.

I do see a CRC Error in their but for the Upstream so not sure that has any impact.

14

Is there a way to debug whats the packet forwarder is actually doing with the packet ?

Thanks,
Serge

15

I upgraded to this new packet forwarder yesterday. It’s all work good and I get my data on TTN and so on. But I have one “problem” if I type “tail -f /var/log/lora-pkt-fwd.log” it dose not behave that it use to. With the old packet forwarder I get “UP” and “DOWN” in real time and the status message in like 30s intervall. Now it can be quite for up to maybe 2-5min and then I get a lot of text with all my old UP/DOWN message and status message, and the text can be cut in a middle of a word. Doesn’t looks right. Any idea why ?

16

This is because the output is buffered. Only when a buffer of 1KB is filled that buffer is written. The buffer being full can happen anywhere in a line.

17

That means the packet is corrupt and will not be forwarded to TTN.[quote=“ssozonoff, post:14, topic:7117”]
Is there a way to debug whats the packet forwarder is actually doing with the packet ?
[/quote]

The counters for the JIT queue tell what happened. See my previous message with the JIT queue information. The only thing to ignore is the byte count which is not updated correctly at the moment.
Packet to RF means it is sent by the gateway if TX error count is 0.

18

Yeah I dont know. I have gotten OTAA working a few times during my tests today but its completely random (without changing settings).

This was when I was lucky and it worked once.

As mentioned in another thread maybe its some form of timing related issue and thats why its so random.

Thanks,
Serge

19

As you can see in your screenshot the reply is sent about 5 seconds after the packet is received. As the node listens for a reply for milliseconds at the 5 second mark the response is timing critical indeed. Any network delays or timer issues on the node can cause data to be missed.

What are the ping times from your gateway to a site like google?

20

Thanks you. I believe I have it working now, more testing will tell.

A second question is can Node Red and the Packet Forwarder work at the same time ? i.e. do they both receive the lora packets ?

Serge