Closed fikrisaman closed 3 years ago
Are you using Chirpstack Gateway Bride? If it is, the default port should be 1700
With 127.0.0.1:1700 I still get the "No connection with 127.0.0.1:1700, it may be off" error. The gateway bridge is not on a real existing gateway, but on the same server as the other Chirpstack components
This "error" occurs when the connection between virtual gateway and Chirpstack Gateway Bridge is closed. Are you sure the Chirpstack infrastructure is running? If it is, have you registered virtual gateway's configuration in Chirpstack yet? You can also check Chirpstack Gateway Bridge's configuration if it is correct
Are you sure the Chirpstack infrastructure is running
It is running. I verified it via systemctl status chirpstack-gateway-bridge.
have you registered virtual gateway's configuration in Chirpstack yet?
Wait, do I have to do that? So I need to create a gateway on Chirpstack with the same MAC address? Is it the same case for device too?
check Chirpstack Gateway Bridge's configuration if it is correct
I assumed if it's already running, it means that everything is okay. But here's my gateway bridge conf file.
[general]
# debug=5, info=4, warning=3, error=2, fatal=1, panic=0
log_level=4
# Log to syslog.
#
# When set to true, log messages are being written to syslog.
log_to_syslog=false
# Filters.
#
# These can be used to filter LoRaWAN frames to reduce bandwith usage between
# the gateway and ChirpStack Gateway Bridge. Depending the used backend, filtering
# will be performed by the Packet Forwarder or ChirpStack Gateway Bridge.
[filters]
# NetIDs filters.
#
# The configured NetIDs will be used to filter uplink data frames.
# When left blank, no filtering will be performed on NetIDs.
#
# Example:
# net_ids=[
# "000000",
# "000001",
# ]
net_ids=[
]
# JoinEUI filters.
#
# The configured JoinEUI ranges will be used to filter join-requests.
# When left blank, no filtering will be performed on JoinEUIs.
#
# Example:
# join_euis=[
# ["0000000000000000", "00000000000000ff"],
# ["000000000000ff00", "000000000000ffff"],
# ]
join_euis=[
]
# Gateway backend configuration.
[backend]
# Backend type.
#
# Valid options are:
# * semtech_udp
# * concentratord
# * basic_station
type="basic_station"
# Semtech UDP packet-forwarder backend.
[backend.semtech_udp]
# ip:port to bind the UDP listener to
#
# Example: 0.0.0.0:1700 to listen on port 1700 for all network interfaces.
# This is the listener to which the packet-forwarder forwards its data
# so make sure the 'serv_port_up' and 'serv_port_down' from your
# packet-forwarder matches this port.
udp_bind = "0.0.0.0:1700"
# Skip the CRC status-check of received packets
#
# This is only has effect when the packet-forwarder is configured to forward
# LoRa frames with CRC errors.
skip_crc_check = false
# Fake RX timestamp.
#
# Fake the RX time when the gateway does not have GPS, in which case
# the time would otherwise be unset.
fake_rx_time=false
# ChirpStack Concentratord backend.
[backend.concentratord]
# Check for CRC OK.
crc_check=true
# Event API URL.
event_url="ipc:///tmp/concentratord_event"
# Command API URL.
command_url="ipc:///tmp/concentratord_command"
# Basic Station backend.
[backend.basic_station]
# ip:port to bind the Websocket listener to.
bind=":3001"
# TLS certificate and key files.
#
# When set, the websocket listener will use TLS to secure the connections
# between the gateways and ChirpStack Gateway Bridge (optional).
tls_cert=""
tls_key=""
# TLS CA certificate.
#
# When configured, ChirpStack Gateway Bridge will validate that the client
# certificate of the gateway has been signed by this CA certificate.
ca_cert=""
# Stats interval.
#
# This defines the interval in which the ChirpStack Gateway Bridge forwards
# the uplink / downlink statistics.
stats_interval="30s"
# Ping interval.
ping_interval="1m0s"
# Read timeout.
#
# This interval must be greater than the configured ping interval.
read_timeout="1m5s"
# Write timeout.
write_timeout="1s"
# Region.
#
# Please refer to the LoRaWAN Regional Parameters specification
# for the complete list of common region names.
region="AS923"
# Minimal frequency (Hz).
frequency_min=919000000
# Maximum frequency (Hz).
frequency_max=924000000
# Concentrator configuration.
[[backend.basic_station.concentrators]]
[backend.basic_station.concentrators.multi_sf]
frequencies=[
923200000,
923400000,
]
[backend.basic_station.concentrators.lora_std]
frequency=923200000
bandwidth=125000
spreading_factor=7
[backend.basic_station.concentrators.fsk]
frequency=923200000
# Integration configuration.
[integration]
# Payload marshaler.
#
# This defines how the MQTT payloads are encoded. Valid options are:
# * protobuf: Protobuf encoding
# * json: JSON encoding (easier for debugging, but less compact than 'protobuf')
marshaler="json"
# MQTT integration configuration.
[integration.mqtt]
# Event topic template.
event_topic_template="gateway/{{ .GatewayID }}/event/{{ .EventType }}"
# State topic template.
#
# States are sent by the gateway as retained MQTT messages (by default)
# so that the last message will be stored by the MQTT broker. When set to
# a blank string, this feature will be disabled. This feature is only
# supported when using the generic authentication type.
state_topic_template="gateway/{{ .GatewayID }}/state/{{ .StateType }}"
# Command topic template.
command_topic_template="gateway/{{ .GatewayID }}/command/#"
# State retained.
#
# By default this value is set to true and states are published as retained
# MQTT messages. Setting this to false means that states will not be retained
# by the MQTT broker.
state_retained=true
# Keep alive will set the amount of time (in seconds) that the client should
# wait before sending a PING request to the broker. This will allow the client
# to know that a connection has not been lost with the server.
# Valid units are 'ms', 's', 'm', 'h'. Note that these values can be combined, e.g. '24h30m15s'.
keep_alive="30s"
# Maximum interval that will be waited between reconnection attempts when connection is lost.
# Valid units are 'ms', 's', 'm', 'h'. Note that these values can be combined, e.g. '24h30m15s'.
max_reconnect_interval="1m0s"
# Terminate on connect error.
#
# When set to true, instead of re-trying to connect, the ChirpStack Gateway Bridge
# process will be terminated on a connection error.
terminate_on_connect_error=false
# MQTT authentication.
[integration.mqtt.auth]
# Type defines the MQTT authentication type to use.
#
# Set this to the name of one of the sections below.
type="generic"
# Generic MQTT authentication.
[integration.mqtt.auth.generic]
# MQTT servers.
#
# Configure one or multiple MQTT server to connect to. Each item must be in
# the following format: scheme://host:port where scheme is tcp, ssl or ws.
servers=[
"tcp://127.0.0.1:1883",
]
# Connect with the given username (optional)
username=""
# Connect with the given password (optional)
password=""
# Quality of service level
#
# 0: at most once
# 1: at least once
# 2: exactly once
#
# Note: an increase of this value will decrease the performance.
# For more information: https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels
qos=0
# Clean session
#
# Set the "clean session" flag in the connect message when this client
# connects to an MQTT broker. By setting this flag you are indicating
# that no messages saved by the broker for this client should be delivered.
clean_session=true
# Client ID
#
# Set the client id to be used by this client when connecting to the MQTT
# broker. A client id must be no longer than 23 characters. When left blank,
# a random id will be generated. This requires clean_session=true.
client_id=""
# CA certificate file (optional)
#
# Use this when setting up a secure connection (when server uses ssl://...)
# but the certificate used by the server is not trusted by any CA certificate
# on the server (e.g. when self generated).
ca_cert=""
# mqtt TLS certificate file (optional)
tls_cert=""
# mqtt TLS key file (optional)
tls_key=""
# Google Cloud Platform Cloud IoT Core authentication.
#
# Please note that when using this authentication type, the MQTT topics
# will be automatically set to match the MQTT topics as expected by
# Cloud IoT Core.
[integration.mqtt.auth.gcp_cloud_iot_core]
# MQTT server.
server="ssl://mqtt.googleapis.com:8883"
# Google Cloud IoT Core Device id.
device_id=""
# Google Cloud project id.
project_id=""
# Google Cloud region.
cloud_region=""
# Google Cloud IoT registry id.
registry_id=""
# JWT token expiration time.
jwt_expiration="24h0m0s"
# JWT token key-file.
#
# Example command to generate a key-pair:
# $ ssh-keygen -t rsa -b 4096 -f private-key.pem
# $ openssl rsa -in private-key.pem -pubout -outform PEM -out public-key.pem
#
# Then point the setting below to the private-key.pem and associate the
# public-key.pem with this device / gateway in Google Cloud IoT Core.
jwt_key_file=""
# Azure IoT Hub
#
# This setting will preset uplink and downlink topics that will only
# work with Azure IoT Hub service.
[integration.mqtt.auth.azure_iot_hub]
# Device connection string (symmetric key authentication).
#
# This connection string can be retrieved from the Azure IoT Hub device
# details when using the symmetric key authentication type.
device_connection_string=""
# Token expiration (symmetric key authentication).
#
# ChirpStack Gateway Bridge will generate a SAS token with the given expiration.
# After the token has expired, it will generate a new one and trigger a
# re-connect (only for symmetric key authentication).
sas_token_expiration="24h0m0s"
# Device ID (X.509 authentication).
#
# This will be automatically set when a device connection string is given.
# It must be set for X.509 authentication.
device_id=""
# IoT Hub hostname (X.509 authentication).
#
# This will be automatically set when a device connection string is given.
# It must be set for X.509 authentication.
# Example: iot-hub-name.azure-devices.net
hostname=""
# Client certificates (X.509 authentication).
#
# Configure the tls_cert (certificate file) and tls_key (private-key file)
# when the device is configured with X.509 authentication.
tls_cert=""
tls_key=""
# Metrics configuration.
[metrics]
# Metrics stored in Prometheus.
#
# These metrics expose information about the state of the ChirpStack Gateway Bridge
# instance like number of messages processed, number of function calls, etc.
[metrics.prometheus]
# Expose Prometheus metrics endpoint.
endpoint_enabled=false
# The ip:port to bind the Prometheus metrics server to for serving the
# metrics endpoint.
bind=""
# Gateway meta-data.
#
# The meta-data will be added to every stats message sent by the ChirpStack Gateway
# Bridge.
[meta_data]
# Static.
#
# Static key (string) / value (string) meta-data.
[meta_data.static]
# Example:
# serial_number="A1B21234"
# Dynamic meta-data.
#
# Dynamic meta-data is retrieved by executing external commands.
# This makes it possible to for example execute an external command to
# read the gateway temperature.
[meta_data.dynamic]
# Execution interval of the commands.
execution_interval="1m0s"
# Max. execution duration.
max_execution_duration="1s"
# Split delimiter.
#
# When the output of a command returns multiple lines, ChirpStack Gateway Bridge
# assumes multiple values are returned. In this case it will split by the given delimiter
# to obtain the key / value of each row. The key will be prefixed with the name of the
# configured command.
split_delimiter="="
# Commands to execute.
#
# The value of the stdout will be used as the key value (string).
# In case the command failed, it is ignored. In case the same key is defined
# both as static and dynamic, the dynamic value has priority (as long as the)
# command does not fail.
[meta_data.dynamic.commands]
# Example:
# temperature="/opt/gateway-temperature/gateway-temperature.sh"
# Executable commands.
#
# The configured commands can be triggered by sending a message to the
# ChirpStack Gateway Bridge.
[commands]
# Example:
# [commands.commands.reboot]
# max_execution_duration="1s"
# command="/usr/bin/reboot"
Wait, do I have to do that? So I need to create a gateway on Chirpstack with the same MAC address? Is it the same case for device too?
Yes, You need to register on chirpstack also a gateway with the same MAC address and a device with the same DevEUI
I did as you suggested, registering the gateway & device on chirpstack with the same DevEUI and Mac address. But it still gives out the same error about the No connection with 127.0.0.1:1700, it may be off. Is there anything else that I should specify when I register the gateway/device on Chirpstack?
Can you attach some screenshots of the device and gateway configurations in the LWN simulator and Chirpstack? Thank you.
Can you also attach a screenshot of the console with the error? What is the location of the device? How to install Chirpstack? With docker?
Also a screenshot of the gateway bridge configurations in the LWN simulator, thanks
location of the device
On the simulator I had it all set to 0.
Chirpstack install
I didn't installed Chirpstack with docker. I installed it the general way on a Ubuntu 20.04.3 on a local virtual machine
Where does LWN Simulator run? If it don't run in local virtual machine you have to insert ip address of the virtual machine in Gateway Bridge's address.
I've found the source of the problem. Since my real-life gateway uses Basic station, I've set the Gateway Bridge Server to use Basic Station. After changing it back to its original setting, which was semtech_udp, it started to work 👍
Where do I find my gateway bridge's port and IP? I assume the IP is 127.0.01 since I have it installed on the same virtual machine as my application server and my network server and I'm executing the simulator on the same machine. I tried looking into the ports that my machine are using with:
sudo lsof -i -P -n | grep LISTEN
And it was 3001. But when I try to run the simulator, it gave me this error: 2021/09/14 16:50:23 GW[gw1] [ERROR]: No connection with 127.0.0.1:3001, it may be off