Downlink messages not being scheduled to the Gateway

Hi,

I’ve been trying of sending downlinks to my RN2903 nodes but I’ve not been able of doing this. I have checked a lot of threads of the forum which seem to be that scheduling a downlink is easy and straightforward, but I’ve had no luck. Perhaps it can be a bug or a misconfiguration of the network.
I thought it was because I was using the CayenneLPP codec function (see Sending downlinks with CayenneLPP Codec), but the problem is still active, even without the codec function, so I think it is not the root problem.
The strange thing is that I can schedule the downlink messages either via MQTT or using the web interface of the app server. Once the downlinks are scheduled, I can see them on the device_queue table of postgres chirpstack_ns database. The messages are also available in the chirpstack app server log (using journalctl). See figure below:

Unfortunately, the downlink messages never reach the device data or the gateway, I just receive uplinks and no more. See figure below:

The downlink commands are not generating any error and are passed from the app server to the network server correctly.
The command I’m using to schedule downlinks using MQTT is:
mosquitto_pub -h 192.168.1.114 -t 'application/1/device/DEVEUI/tx' -m '{"confirmed": false, "fPort": 3, "data": "MQ=="}' -u mqtt_user -P mqtt_password¨. I’ve done the same using files structured with the bytes64 data field and it’s the same.

As I mentioned in the previous thread, I’ve done the same on TheThingsNetwork and the downlinks reach end devices successfully. My GW is a RisingHF-Raspberry PI Kit which runs the semtech legacy packet forwarder.

Please give me a hand with this, I’ve lost a lot of time trying to achieve this feature on Chirpstack.

Thanks in advance.

1 Like

I have been checking for a while, changing between Chirpstack and TTN, and the root problem seems to be bidirectionality of Chirpstack-Gateway-Bridge.
The gateway bridge, which I’m running on server side, receives all the packets, but doesn’t send any packets down to the gateways. It is also double-checked because it is not returning the join accept in OTAA, then I need to use always ABP.
The semtech packet forwarder is working properly and the connection with TTN is ok, for uplinks and downlinks. Perhaps someone can help me identifying and solving this issue please.

Thank you in advance.

Sounds similar to an issue I was having where the mqtt subscriptions in the gateway bridge were not connected, causing all downlinks to never reach gateways. https://github.com/brocaar/chirpstack-gateway-bridge/issues/183

Are you able to confirm if your gateway bridge is subscribed to specific topics for each gateway? e.g. gateway/0123456789abcdef/command/#

Thank you @John_Roesler for your answer.
My gateway bridge is running on main server (Debian 10 Buster), the gateways use the semtech packet forwarder and connect to gateway bridge on port 1700 on main server. The MQTT topics seem to be properly configured in chirpstack-gateway-bridge.toml:

# MQTT integration configuration.
[integration.mqtt]
# Event topic template.
event_topic_template=“gateway/{{ .GatewayID }}/event/{{ .EventType }}”

# Command topic template.
command_topic_template=“gateway/{{ .GatewayID }}/command/#”

I’m also checking debug level logs and it appears to be working:

Nov 25 17:06:06 lorawan chirpstack-gateway-bridge[7577]: time=“2020-11-25T17:06:06-05:00” level=debug msg=“backend/semtechudp: received udp packet from gateway” addr=“10.32.40.72:42430” protocol_version=2 type=PushData
Nov 25 17:06:06 lorawan chirpstack-gateway-bridge[7577]: time=“2020-11-25T17:06:06-05:00” level=debug msg=“backend/semtechudp: received udp packet from gateway” addr=“10.32.40.72:42430” protocol_version=2 type=PushData
Nov 25 17:06:06 lorawan chirpstack-gateway-bridge[7577]: time=“2020-11-25T17:06:06-05:00” level=debug msg=“backend/semtechudp: sending udp packet to gateway” addr=“10.32.40.72:42430” protocol_version=2 type=PushACK
Nov 25 17:06:06 lorawan chirpstack-gateway-bridge[7577]: time=“2020-11-25T17:06:06-05:00” level=debug msg=“backend/semtechudp: sending udp packet to gateway” addr=“10.32.40.72:42430” protocol_version=2 type=PushACK
Nov 25 17:10:37 lorawan chirpstack-gateway-bridge[7577]: time=“2020-11-25T17:10:37-05:00” level=debug msg=“integration/mqtt: set gateway subscription called” gateway_id=b827ebfffe63f083 subscribe=true

Unfortunately, I’m not receiving the messages from the gateway-bridge to the gateways running the semtech packet forwarder.
I’m also doing the same on my local laptop (Ubuntu 20.04) which has all chirpstack environment and the downlink messages work.
The packet forwarder configuration uses these ports to access gateway-bridge:

“serv_port_up”: 1700,
“serv_port_down”: 1700,

I guess the failure is due to the UDP port in the downlink messages but maybe with the log you can give me more information.

Thank you in advance.

It could certainly be an issue with the UDP port going down. Have you checked any firewalls that may be in place? Iptables rules on the gateway that might be rejecting?

The bug i linked to describes a scenario where the uplinks are flowing because the connection to the broker is active, but the subscriptions are blocked from being obtained due to the bug. Are you able to see in the logs for the mqtt broker what subscriptions are currently active?

Thank you for your quick reply.

I was checking the mqtt broker log, but unfortunately, I didn’t set it to log subscriptions, so I only have log of errors, but nothing related to the LoRaWAN network (because I use it for other networks). I have also done some tests opening the mosquitto_sub in the gateway and downlink topics and the messages are received correctly, either via protobuf or json (both work).
I also checked the iptables of the server and this is what I got:

siata@lorawan:~$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

I’m going to check specific rules for port 1700 on UDP to get further with this.

1 Like

Another option, but I want to have this option as the last one is using the gateway-bridge inside the GW itself. I’m using a Raspberry PI 3 with the RisingHF HAT. The problem is that I’m using the Raspbian 9 OS and I don’t want to change it for ChirpStack Gateway OS. In the documentation it says that is also compatible with Raspberry PI OS but the following commands don’t work on:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1CE2AFD36DBCCA00

sudo echo "deb https://artifacts.chirpstack.io/packages/3.x/deb stable main" | sudo tee /etc/apt/sources.list.d/chirpstack.list
sudo apt update

Thank you in advance for any recommendation you can give me.

Finally, the solution was:
Updating all the Raspberries to latest Raspberry PI OS, install the chirptack-gateway-bridge locally and connect them to the server via MQTT.

It avoids all the problems when connecting via UDP.

Thank you @John_Roesler for helping me realize of the solution.

3 Likes