No output on Conduit packet forwarder to Conduit Network Server setup

[Albert Beukman]

Hi;

I am attempting to construct a proof of concept using one Conduit AEP as a packet forwarder, with a second AEP model as a network server.

Problem statement: I don’t see any MQTT output on network server Conduit’s Node-Red with this setup, while I do see MQTT output when using only the Network Server Conduit. Any guidance will be greatly appreciated.

Components.
– 2x Conduit AEP running v1.2.2
– Custom mote with Microchip RN2903 transceiver

Setup.
The 2 Conduits are on the same network with no switching/routing hardware in between and can reach each other – verified by pings on both ends.

Due to limited space and network infrastructure available I place proverbial earmuffs over the network server Conduit by removing its antenna in an attempt reduce the probability of duplicate messages. This seems adequate as I only perceive CRC errors when looking at the LoRa network server stats via the UI.

Packet forwarder setup copied from US (915 MHz) version @ http://www.multitech.net/developer/software/lora/aep-lora-packet-forwarder/. with changes to gatway config to reflect default Network server setup as below.
`”gateway_conf”: {
“synch_word”: 52,
“forward_crc_disabled”: false,
“forward_crc_error”: false,
“forward_crc_valid”: true,
“gateway_ID” : “<WILL-BE-REPLACED-WITH-LORA-EUI>”,
“keepalive_interval”: 12,
“push_timeout_ms”: 120,
“serv_port_up”: 1780,
“serv_port_down”: 1782,
“server_address”: “10.10.1.200”,
“stat_interval”: 20
}`

Observations.
– With only the Network Server Conduit running, and its antenna in place, the mote joins successfully and up-links commence as expected.
– Packet forwarder Conduit logs show successful upstream receipt and forwarding of packet. Extract below.

##### 2016-07-15 22:00:35 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 1
# CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 1 (23 bytes)
# PUSH_DATA datagrams sent: 1 (246 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 1 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
##### END #####

– Transmission in extract above correlated by creating “Allow” firewall rules on relevant ports (as mentioned in JSON setup) and monitoring the Ethernet logs to see whether corresponding log entries reflects transmissions. It did: Counters on relevant ports increased.
— Network server Conduit extract from USER_INPUT section of Ethernet logs below.
388 32091 ACCEPT udp -- * * 10.10.1.199 0.0.0.0/0 udp dpt:1780
— Packet forwarder Conduit extract from USER_OUTPUT section of Ethernet logs below.
43 11764 ACCEPT udp -- * * 0.0.0.0/0 10.10.1.200 udp dpt:1780
– No downstream traffic from Network Server to Packet Forwarder observed in Ethernet logs on port 1782.

I’m happy to provide more specific info, but this should be a good start

[Jason Reiss]

The network server is not exposed on the external interface to be connected to by default.

Lora network server

[Albert Beukman]

Worked like a treat, thanks Jason.

Enabled the Network Server Conduit’s public interface with the API request found at your link (included below) and verified by checking /var/config/lora/lora-network-server.conf after a Conduit restart.

https://<AEP-IP>/api/loraNetwork?method=PUT&data={"udp":{"allowPublic":true}}

Curious that this setting is not exposed in the UI.

[Jason Reiss]

It is not exposed because the network server downlink routing via multiple gateways is still experimental. Results may not be as expected but should mostly function.

[Author]

Posts