Connecting Cisco IR1101 with P-LWRA-900 to ChirpStack Application Server

Hi everyone,

I’ve recently downloaded and installed ChirpStack on an Ubuntu machine, but I’m encountering issues connecting it to a Cisco IR1101. I believe I’ve followed the setup and configuration steps correctly, but ChirpStack doesn’t seem to recognize the LoRaWAN gateway. I’ve verified that both devices can ping each other successfully.

Here’s the configuration on the Cisco device:

interface LORAWAN0/1/0
no ip address
common-packet-forwarder profile
region-channel-plan AU915
gateway-id 0018B20000000201
lns-ip 192.168.1.252
lns-port 1700
cpf enable
arp timeout 0

The gateway ID matches the one entered in the ChirpStack Application Server’s gateway tab.

Has anyone encountered a similar issue, or can offer any guidance on what might be going wrong? Any advice would be greatly appreciated!

Thanks in advance!

A bit more information is needed to help you here.

What architecture are you using? i.e are you using Chirpstack Gateway Bridge / MQTT forwarder on your gateway or on your server? Are you using UDP packet forwarder?

Have you enabled AU915 in your chirpstack.toml?

Have you set your GW bridge MQTT topic prefix to au915_0 or something similar?

Does your gateway simply say “offline” in the UI?

Are you getting any errors in the Chirpstack Logs?

Hi Liam,

Thanks for your response.

I’ve been following this guide for the gateway bridge: Cisco - ChirpStack open-source LoRaWAN<sup>®</sup> Network Server, and I’ve adjusted everything to the AU915 frequency plan. Below is my current configuration:

# Gateway backend configuration.
[backend]

# Backend type.
type="basic_station"

  # Basic Station backend.
  [backend.basic_station]

  # IP:Port to bind the WebSocket listener.
  bind=":3001"

  # Region.
  region="AU915"

  # Minimal frequency (Hz).
  frequency_min=915000000

  # Maximum frequency (Hz).
  frequency_max=928000000

  # Concentrator configuration.
  # Note: this is defined twice as the Cisco gateway has two SX1301 chips.
  [[backend.basic_station.concentrators]]
    # Multi-SF channel configuration.
    [backend.basic_station.concentrators.multi_sf]

    # Frequencies (Hz).
    frequencies=[
      916800000,
      917000000,
      917200000,
      917400000,
      917600000,
      917800000,
      918000000,
      918200000,
    ]

    # LoRa STD channel.
    [backend.basic_station.concentrators.lora_std]

    # Frequency (Hz).
    frequency=917500000

    # Bandwidth (Hz).
    bandwidth=500000

    # Spreading factor.
    spreading_factor=8

    # FSK channel.
    [backend.basic_station.concentrators.fsk]

    # Frequency (Hz).
    frequency=917300000

  [[backend.basic_station.concentrators]]
    # Multi-SF channel configuration.
    [backend.basic_station.concentrators.multi_sf]

    # Frequencies (Hz).
    frequencies=[
      916800000,
      917000000,
      917200000,
      917400000,
      917600000,
      917800000,
      918000000,
      918200000,
    ]

    # LoRa STD channel.
    [backend.basic_station.concentrators.lora_std]

    # Frequency (Hz).
    frequency=917500000

    # Bandwidth (Hz).
    bandwidth=500000

    # Spreading factor.
    spreading_factor=8

    # FSK channel.
    [backend.basic_station.concentrators.fsk]

    # Frequency (Hz).
    frequency=917300000

# Integration configuration.
[integration]

# Payload marshaler.
marshaler="protobuf"

  # MQTT authentication.
  [integration.mqtt.auth]
  type="generic"

    # Generic MQTT authentication.
    [integration.mqtt.auth.generic]
    # MQTT servers.
    servers=[
      "tcp://127.0.0.1:1883",
    ]

I’ve also set the chirpstack-network-server.toml and chirpstack-application-server.toml files to use AU915, but I haven’t made any changes to the base chirpstack.toml file. Within the ChirpStack Application Server GUI, the gateway’s last seen status is marked as “never,” not “offline.”

The ChirpStack logs, including those from the gateway bridge (which is hosted on the same machine as the other ChirpStack components), seem fine. I’m not sure if I’m missing something in the device configuration, as I’ve double-checked all the steps and everything appears correct.

If needed, I can provide other configuration files to help troubleshoot the issue. Based on the logs, it seems the MQTT forwarder is functioning correctly.

Thanks,

Joshua

Hey Joshua,

I would highly recommend restarting using Chirpstack V4 instead of V3.

V3 is no longer being maintained and V4 has many improvement, especially to initial configuration.

Hi Liam,

I wasn’t aware I was using the outdated version is there a guide for instructions to setup using Ubuntu the new V4 version?

Thanks,
Joshua

https://www.chirpstack.io/docs/

Hi Liam,

Thanks for the link the link I was using I am guessing was for V3. I’ve setup a new Ubuntu installation and ran through all those steps. Nothing seems to mention the installation of the application server? is this not required for V4? Anyways still doesn’t seem to connect as it comes up as never seen still when I’ve added the gateway to the network server gui. I’ll provide all my configuration files below incase something is slightly wrong. chirpstack-gateway-bridge

This configuration provides a Semtech UDP packet-forwarder backend and
integrates with a MQTT broker. Many options and defaults have been omitted
for simplicity.

#
# See https://www.chirpstack.io/gateway-bridge/install/config/ for a full
# configuration example and documentation.


# Gateway backend configuration.
[backend]
# Backend type.
type="semtech_udp"

  # 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"


# 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="protobuf"

  # MQTT integration configuration.
  [integration.mqtt]
  # Event topic template.
  event_topic_template="au915/gateway/{{ .GatewayID }}/event/{{ .EventType }}"
  command_topic_template="au915/gateway/{{ .GatewayID }}/command/#"

  # 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 server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
    server="tcp://127.0.0.1:1883"

    # Connect with the given username (optional)
    username=""

    # Connect with the given password (optional)
    password=""

Chirpstack.Toml

[logging]

  # Log level.
  #
  # Options are: trace, debug, info, warn error.
  level = "info"


# PostgreSQL configuration.
[postgresql]

  # PostgreSQL DSN.
  #
  # Format example: postgres://<USERNAME>:<PASSWORD>@<HOSTNAME>/<DATABASE>?sslmode=<SSLMODE>.
  #
  # SSL mode options:
  #  * disable - no SSL
  #  * require - Always SSL (skip verification)
  #  * verify-ca - Always SSL (verify that the certificate presented by the server was signed by a trusted CA)
  #  * verify-full - Always SSL (verify that the certification presented by the server was signed by a trusted CA and the server host name matches the one in the certificate)
  dsn = "postgres://chirpstack:chirpstack@localhost/chirpstack?sslmode=disable"

  # Max open connections.
  #
  # This sets the max. number of open connections that are allowed in the
  # PostgreSQL connection pool.
  max_open_connections = 10

  # Min idle connections.
  #
  # This sets the min. number of idle connections in the PostgreSQL connection
  # pool (0 = equal to max_open_connections).
  min_idle_connections = 0


# Redis configuration.
[redis]

  # Server address or addresses.
  #
  # Set multiple addresses when connecting to a cluster.
  servers = ["redis://localhost/"]

  # Redis Cluster.
  #
  # Set this to true when the provided URLs are pointing to a Redis Cluster
  # instance.
  cluster = false


# Network related configuration.
[network]

  # Network identifier (NetID, 3 bytes) encoded as HEX (e.g. 010203).
  net_id = "000000"

  # Enabled regions.
  #
  # Multiple regions can be enabled simultaneously. Each region must match
  # the 'name' parameter of the region configuration in '[[regions]]'.
  enabled_regions = [
    "as923",
    "as923_2",
    "as923_3",
    "as923_4",
    "au915_0",
    "cn470_10",
    "cn779",
    "eu433",
    "eu868",
    "in865",
    "ism2400",
    "kr920",
    "ru864",
    "us915_0",
    "us915_1",
  ]


# API interface configuration.
[api]

  # interface:port to bind the API interface to.
  bind = "0.0.0.0:8080"

  # Secret.
  #
  # This secret is used for generating login and API tokens, make sure this
  # is never exposed. Changing this secret will invalidate all login and API
  # tokens. The following command can be used to generate a random secret:
  #   openssl rand -base64 32
  secret = "shipwreck33"


[integration]
  enabled = ["mqtt"]

  [integration.mqtt]
    server = "tcp://localhost:1883/"
    json = true

Cisco Configuration for IR1101


Building configuration...

Current configuration : 6419 bytes
!
! Last configuration change at 12:08:55 AEST Fri Aug 30 2024 by cisco
!
version 17.14
service timestamps debug datetime msec
service timestamps log datetime msec
platform qfp utilization monitor load 80
platform hardware throughput level 250M
!
hostname LoRaWan1
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
clock timezone AEST 10 0
!
ip domain name optech.net
!
!
!
!
!
!
!
!
!         
login block-for 60 attempts 3 within 30
login delay 3
login on-success log
!
!
!
!
!
!
!
subscriber templating
!
! 
! 
! 
! 
!
!
!
!
!
!
!
!
!
crypto pki trustpoint TP-self-signed-3691864828
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-3691864828
 revocation-check none
 rsakeypair TP-self-signed-3691864828
 hash sha256
!
crypto pki trustpoint SLA-TrustPoint
 enrollment pkcs12
 revocation-check crl
 hash sha256
!
!
crypto pki certificate chain TP-self-signed-3691864828
 certificate self-signed 01
  30820330 30820218 A0030201 02020101 300D0609 2A864886 F70D0101 0B050030 
  31312F30 2D060355 04030C26 494F532D 53656C66 2D536967 6E65642D 43657274 
  69666963 6174652D 33363931 38363438 3238301E 170D3234 30383039 30313438 
  30375A17 0D333430 38303930 31343830 375A3031 312F302D 06035504 030C2649 
  4F532D53 656C662D 5369676E 65642D43 65727469 66696361 74652D33 36393138 
  36343832 38308201 22300D06 092A8648 86F70D01 01010500 0382010F 00308201 
  0A028201 0100C991 475C3B5A 370F7AC6 4958914C 504D823C 1750ECB3 286AE51A 
  A5E1A648 56880C0E BA7A86BB C7D2F18F 503180F6 F2556A3E BA23D2BE 6F3647A3 
  48F33C2F 3B8C352B 9D83FE6B 86995BBF 11F7D6ED 9AFFEA30 472BEF07 EE00F471 
  29745E6E 0B8FE7AC A0362A67 F9335975 EA0EACA8 91CB643C 6C805A99 0B263DC5 
  2C2D5A6D B713ECEB B768B6F5 1AE5D7D2 A3F678D0 F7573E2C AB5A0AB6 7C4CE1E7 
  C247ADC3 4D21DBED DB9F9C8D F60C1A3D 913FCB39 ABC9A1D7 1F0DA7F7 3072B298 
  D0C78DE8 CD49F0C5 0E916FBE 13D7E707 DAAE7FC4 B5C9E7D5 B4F53757 9BFC59AC 
  25F42820 932722C3 F7776083 51E1CB1D 39503746 2ADD8219 517ADFC3 54F7CCBB 
  6BC949B0 B0570203 010001A3 53305130 1D060355 1D0E0416 041453DA C18D29FD 
  6A0569B4 646EE317 B5D02A41 D7A6301F 0603551D 23041830 16801453 DAC18D29 
  FD6A0569 B4646EE3 17B5D02A 41D7A630 0F060355 1D130101 FF040530 030101FF 
  300D0609 2A864886 F70D0101 0B050003 82010100 0F085580 888E2E94 C0E7AE25 
  82AC8C9D F3F92D22 4D15857A 394F8E0B F577B330 6AB35D65 2CC85326 DEA15E6D 
  7C4B795D 9550BCC9 C82DF607 E078C79A 1BF37A8E C9EC9ABC F30EBB0B B0D29CCE 
  F9F0E659 EFCCADFB 0ED711FF 595D04A3 7D657F64 0E9F929C A082EA42 246E3FE2 
  382A7161 D18B446F B335430A C564360F 96C0999E 1AA889B8 163D0F8B C940E6DA 
  7597E7BF BEC9738B D66C5C76 FFBC42BD 73CE98D4 E795F3C6 FDD4F4AF 717EB1D9 
  BABD440F BB7641F4 722D90E8 0F71A411 ED95D1DF AA711EC9 DEC8DCC7 2D908486 
  055B94A4 030FD234 2C6E51DC B37C8589 F79D10A9 3A6802EE B66F50A4 AD5FD655 
  0BDD783F CD8D4BB6 35554340 521A7EBB FDDFDCA5
  	quit
crypto pki certificate chain SLA-TrustPoint
 certificate ca 01
  30820321 30820209 A0030201 02020101 300D0609 2A864886 F70D0101 0B050030 
  32310E30 0C060355 040A1305 43697363 6F312030 1E060355 04031317 43697363 
  6F204C69 63656E73 696E6720 526F6F74 20434130 1E170D31 33303533 30313934 
  3834375A 170D3338 30353330 31393438 34375A30 32310E30 0C060355 040A1305 
  43697363 6F312030 1E060355 04031317 43697363 6F204C69 63656E73 696E6720 
  526F6F74 20434130 82012230 0D06092A 864886F7 0D010101 05000382 010F0030 
  82010A02 82010100 A6BCBD96 131E05F7 145EA72C 2CD686E6 17222EA1 F1EFF64D 
  CBB4C798 212AA147 C655D8D7 9471380D 8711441E 1AAF071A 9CAE6388 8A38E520 
  1C394D78 462EF239 C659F715 B98C0A59 5BBB5CBD 0CFEBEA3 700A8BF7 D8F256EE 
  4AA4E80D DB6FD1C9 60B1FD18 FFC69C96 6FA68957 A2617DE7 104FDC5F EA2956AC 
  7390A3EB 2B5436AD C847A2C5 DAB553EB 69A9A535 58E9F3E3 C0BD23CF 58BD7188 
  68E69491 20F320E7 948E71D7 AE3BCC84 F10684C7 4BC8E00F 539BA42B 42C68BB7 
  C7479096 B4CB2D62 EA2F505D C7B062A4 6811D95B E8250FC4 5D5D5FB8 8F27D191 
  C55F0D76 61F9A4CD 3D992327 A8BB03BD 4E6D7069 7CBADF8B DF5F4368 95135E44 
  DFC7C6CF 04DD7FD1 02030100 01A34230 40300E06 03551D0F 0101FF04 04030201 
  06300F06 03551D13 0101FF04 05300301 01FF301D 0603551D 0E041604 1449DC85 
  4B3D31E5 1B3E6A17 606AF333 3D3B4C73 E8300D06 092A8648 86F70D01 010B0500 
  03820101 00507F24 D3932A66 86025D9F E838AE5C 6D4DF6B0 49631C78 240DA905 
  604EDCDE FF4FED2B 77FC460E CD636FDB DD44681E 3A5673AB 9093D3B1 6C9E3D8B 
  D98987BF E40CBD9E 1AECA0C2 2189BB5C 8FA85686 CD98B646 5575B146 8DFC66A8 
  467A3DF4 4D565700 6ADF0F0D CF835015 3C04FF7C 21E878AC 11BA9CD2 55A9232C 
  7CA7B7E6 C1AF74F6 152E99B7 B1FCF9BB E973DE7F 5BDDEB86 C71E3B49 1765308B 
  5FB0DA06 B92AFE7F 494E8A9E 07B85737 F3A58BE1 1A48A229 C37C1E69 39F08678 
  80DDCD16 D6BACECA EEBC7CF9 8428787B 35202CDC 60E4616A B623CDBD 230E3AFB 
  418616A9 4093E049 4D10AB75 27E86F73 932E35B5 8862FDAE 0275156F 719BB2F0 
  D697DF7F 28
  	quit
!
!
!
!
!
!
!
!
!
diagnostic bootup level minimal
!
no license feature hseck9
license udi pid IR1101-K9 sn FCW2818Y1BK
memory free low-watermark processor 43622
!
spanning-tree extend system-id
!
enable secret 9 $9$qfnOg7IvBIA26.$yBJXq.EAkV8GIO7GJHPh94LKHoFVwYfbSLjlHOtTaaY
enable password admin
!         
username admin privilege 15 password 0 admin
username cisco privilege 15 password 0 cisco
!
redundancy
!
!
!
!
!
!
vlan internal allocation policy ascending
!
!
! 
!
!
!
!
!
!
!
!
!
!
!
!
!
! 
!         
!
!
interface GigabitEthernet0/0/0
 ip dhcp client client-id ascii cisco-ec19.2e79.9100-Gi0/0/0
 ip address dhcp
!
interface FastEthernet0/0/1
!
interface FastEthernet0/0/2
!
interface FastEthernet0/0/3
!
interface FastEthernet0/0/4
!
interface Vlan1
 ip address 192.168.2.240 255.255.255.0
!
interface Async0/2/0
 no ip address
 encapsulation scada
!
interface LORAWAN0/1/0
 no ip address
 common-packet-forwarder profile
  region-channel-plan AU915
  gateway-id 0018B20000000321
  lns-ip 192.168.1.227
  lns-port 1700
  cpf enable
 arp timeout 0
!
iox
ip default-gateway 192.168.1.1
ip forward-protocol nd
ip http server
ip http auth-retry 3 time-window 1
ip http authentication local
ip http secure-server
ip http client source-interface GigabitEthernet0/0/0
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1
ip ssh bulk-mode 131072
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
line con 0
 stopbits 1
line 0/0/0
line 0/2/0
line vty 0 4
 password admin
 login local
 transport input ssh
line vty 5 14
 password admin
 login local
 transport input ssh
line vty 15
 login local
 transport input ssh
!
!
!
!
!
!
!
!
!
!
!
!
!
!
end 

Your MQTT topic prefix should be “au915_0” or “au915_1”, not just the region but the subband as well (only au915_0 is enabled in your chirpstack.toml though). After that I believe it should connect. And no in V4 the network and application server are merged into one for simplicity sake.

I’ve tried changing it from just Au915 to au915_0 but it still doesn’t appear to have fixed the problem. Only thing I can think of is that the chirpstack server I have setup is inside of an Esxi installation and it somehow is blocking the UDP traffic between the gateway and the chirpstack application I might try and either just redo it using a pc not running on Esxi or just try and figure out how to unblock the UDP traffic if it is being blocked.

Setup a new ubuntu installation with a different pc setup locally connected to one of the gateways lan ports. Using the same configuration files it doesn’t appear to connect still even after changing the ip address of the lns-server in the cisco gateway to the updated one. The new gateway can ping the computers ip address fine but under gateways in the chirpstack gui it still appears as never seen.

I did some digging and I think the issue might be that cisco doesn’t support the Semtech UDP packet forwarder protocol and only supports basic station packet forwarder protocol.

Then set up a basic-station gateway-bridge and see if that solves the issue.

A couple things that might help in troubleshooting if that doesn’t work:

  • Any errors in the Chirpstack logs?
  • If you subscribe to your MQTT broker topic can you see any messages in the broker? - mosquitto_sub -h localhost -t "#" -v -d
  • Maybe double check the gateway ID?

Hey Liam,

I setup a basic station packet forwarder instead this is what my configuration looks like

# Gateway backend configuration.
[backend]

# Backend type.
type="basic_station"

  # Basic Station backend.
  [backend.basic_station]

  # ip:port to bind the WebSocket listener to.
  bind=":3001"

  # Region.
  region="AU915"

  # Minimal frequency (Hz).
  frequency_min=915200000

  # Maximum frequency (Hz).
  frequency_max=927800000

  # Concentrator configuration.
  # Note: this is defined twice if the gateway has two SX1301 or SX1302 chips.
  [[backend.basic_station.concentrators]]
    # Multi-SF channel configuration.
    [backend.basic_station.concentrators.multi_sf]
 
    # Frequencies (Hz) for AU915_0.
    frequencies=[
      915200000,  # Channel 0
      915400000,  # Channel 1
      915600000,  # Channel 2
      915800000,  # Channel 3
      916000000,  # Channel 4
      916200000,  # Channel 5
      916400000,  # Channel 6
      916600000,  # Channel 7
    ]
  
    # LoRa STD channel.
    [backend.basic_station.concentrators.lora_std]
  
    # Frequency (Hz).
    frequency=916800000
  
    # Bandwidth (Hz).
    bandwidth=500000
  
    # Spreading factor.
    spreading_factor=7
  
    # FSK channel.
    [backend.basic_station.concentrators.fsk]
  
    # Frequency (Hz).
    frequency=916900000

  # If your gateway has a second concentrator, duplicate the section above with new frequency values
  [[backend.basic_station.concentrators]]
    # Multi-SF channel configuration.
    [backend.basic_station.concentrators.multi_sf]
 
    # Frequencies (Hz) for AU915_0.
    frequencies=[
      915200000,  # Channel 0
      915400000,  # Channel 1
      915600000,  # Channel 2
      915800000,  # Channel 3
      916000000,  # Channel 4
      916200000,  # Channel 5
      916400000,  # Channel 6
      916600000,  # Channel 7
    ]
  
    # LoRa STD channel.
    [backend.basic_station.concentrators.lora_std]
  
    # Frequency (Hz).
    frequency=916800000
  
    # Bandwidth (Hz).
    bandwidth=500000
  
    # Spreading factor.
    spreading_factor=7
  
    # FSK channel.
    [backend.basic_station.concentrators.fsk]
  
    # Frequency (Hz).
    frequency=916900000


# Integration configuration.
[integration]

# Payload marshaler.
marshaler="protobuf"

  # MQTT integration configuration.
  [integration.mqtt]
  # Event topic template.
  event_topic_template="au915_0/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="au915_0/gateway/{{ .GatewayID }}/state/{{ .StateType }}"

  # Command topic template.
  command_topic_template="au915_0/gateway/{{ .GatewayID }}/command/#"


  # MQTT authentication.
  [integration.mqtt.auth]
  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",
    ]

I’ve checked the gateway ID it looks consistent between chirpstack and the gateway. As for the chirpstack logs is there a directory or something that they are stored in by default as I can’t seem to find where they are stored as nothing seems to be stored under /var/log. I’ve subscribed to the broker the only thing that seems to be getting displayed is Client null sending/recieved PINGRESP.

This should work to get the logs:
sudo journalctl -f -n 100 -u chirpstack

Hey Liam,

This is the output of the logs.

Sep 04 15:43:33 lorawan-server chirpstack[1889]: 2024-09-04T05:43:33.716702Z INFO gRPC{uri=/api.GatewayService/List}: chirpstack::api: Finished processing request status=“200” latency=36.817896ms
Sep 04 15:43:33 lorawan-server chirpstack[1889]: 2024-09-04T05:43:33.718327Z INFO gRPC{uri=/api.TenantService/Get}: chirpstack::api: Finished processing request status=“200” latency=1.7683ms
Sep 04 15:43:33 lorawan-server chirpstack[1889]: 2024-09-04T05:43:33.721375Z INFO gRPC{uri=/api.InternalService/GetDevicesSummary}: chirpstack::api: Finished processing request status=“200” latency=40.83927ms
Sep 04 15:43:42 lorawan-server chirpstack[1889]: 2024-09-04T05:43:42.357636Z INFO gRPC{uri=/api.TenantService/Get}: chirpstack::api: Finished processing request status=“200” latency=2.222529ms
Sep 04 15:43:42 lorawan-server chirpstack[1889]: 2024-09-04T05:43:42.357967Z INFO gRPC{uri=/api.InternalService/GetVersion}: chirpstack::api: Finished processing request status=“200” latency=1.068446ms
Sep 04 15:43:42 lorawan-server chirpstack[1889]: 2024-09-04T05:43:42.358986Z INFO gRPC{uri=/api.TenantService/Get}: chirpstack::api: Finished processing request status=“200” latency=1.636763ms
Sep 04 15:43:42 lorawan-server chirpstack[1889]: 2024-09-04T05:43:42.374971Z INFO gRPC{uri=/api.TenantService/Get}: chirpstack::api: Finished processing request status=“200” latency=2.09657ms
Sep 04 15:43:42 lorawan-server chirpstack[1889]: 2024-09-04T05:43:42.432885Z INFO gRPC{uri=/api.InternalService/GetGatewaysSummary}: chirpstack::api: Finished processing request status=“200” latency=1.778719ms
Sep 04 15:43:42 lorawan-server chirpstack[1889]: 2024-09-04T05:43:42.434347Z INFO gRPC{uri=/api.GatewayService/List}: chirpstack::api: Finished processing request status=“200” latency=2.172519ms
Sep 04 15:43:42 lorawan-server chirpstack[1889]: 2024-09-04T05:43:42.435878Z INFO gRPC{uri=/api.InternalService/GetDevicesSummary}: chirpstack::api: Finished processing request status=“200” latency=3.876303ms
Sep 04 15:43:43 lorawan-server chirpstack[1889]: 2024-09-04T05:43:43.064304Z INFO gRPC{uri=/api.TenantService/Get}: chirpstack::api: Finished processing request status=“200” latency=1.490737ms
Sep 04 15:43:43 lorawan-server chirpstack[1889]: 2024-09-04T05:43:43.064316Z INFO gRPC{uri=/api.InternalService/GetVersion}: chirpstack::api: Finished processing request status=“200” latency=702.108µs
Sep 04 15:43:43 lorawan-server chirpstack[1889]: 2024-09-04T05:43:43.080133Z INFO gRPC{uri=/api.TenantService/ListUsers}: chirpstack::api: Finished processing request status=“200” latency=1.738074ms
Sep 04 15:43:43 lorawan-server chirpstack[1889]: 2024-09-04T05:43:43.100752Z INFO gRPC{uri=/api.TenantService/Get}: chirpstack::api: Finished processing request status=“200” latency=1.708814ms
Sep 04 15:43:43 lorawan-server chirpstack[1889]: 2024-09-04T05:43:43.935159Z INFO gRPC{uri=/api.TenantService/Get}: chirpstack::api: Finished processing request status=“200” latency=1.105194ms
Sep 04 15:43:43 lorawan-server chirpstack[1889]: 2024-09-04T05:43:43.935374Z INFO gRPC{uri=/api.InternalService/GetVersion}: chirpstack::api: Finished processing request status=“200” latency=575.079µs
Sep 04 15:43:43 lorawan-server chirpstack[1889]: 2024-09-04T05:43:43.943029Z INFO gRPC{uri=/api.DeviceProfileService/List}: chirpstack::api: Finished processing request status=“200” latency=3.739283ms
Sep 04 15:43:43 lorawan-server chirpstack[1889]: 2024-09-04T05:43:43.961788Z INFO gRPC{uri=/api.TenantService/Get}: chirpstack::api: Finished processing request status=“200” latency=1.117101ms
Sep 04 15:43:44 lorawan-server chirpstack[1889]: 2024-09-04T05:43:44.504175Z INFO gRPC{uri=/api.InternalService/GetVersion}: chirpstack::api: Finished processing request status=“200” latency=522.655µs
Sep 04 15:43:44 lorawan-server chirpstack[1889]: 2024-09-04T05:43:44.504382Z INFO gRPC{uri=/api.TenantService/Get}: chirpstack::api: Finished processing request status=“200” latency=1.232506ms
Sep 04 15:43:44 lorawan-server chirpstack[1889]: 2024-09-04T05:43:44.518657Z INFO gRPC{uri=/api.GatewayService/List}: chirpstack::api: Finished processing request status=“200” latency=3.084019ms
Sep 04 15:43:44 lorawan-server chirpstack[1889]: 2024-09-04T05:43:44.519857Z INFO gRPC{uri=/api.ApplicationService/List}: chirpstack::api: Finished processing request status=“200” latency=3.630504ms
Sep 04 15:43:44 lorawan-server chirpstack[1889]: 2024-09-04T05:43:44.542188Z INFO gRPC{uri=/api.TenantService/Get}: chirpstack::api: Finished processing request status=“200” latency=2.183795ms
Sep 04 15:43:52 lorawan-server chirpstack[1889]: 2024-09-04T05:43:52.917518Z INFO gRPC{uri=/api.GatewayService/List}: chirpstack::api: Finished processing request status=“200” latency=1.851138ms
Sep 04 15:43:56 lorawan-server chirpstack[1889]: 2024-09-04T05:43:56.636065Z INFO gRPC{uri=/api.TenantService/Get}: chirpstack::api: Finished processing request status=“200” latency=943.84µs
Sep 04 15:43:56 lorawan-server chirpstack[1889]: 2024-09-04T05:43:56.637613Z INFO gRPC{uri=/api.InternalService/GetVersion}: chirpstack::api: Finished processing request status=“200” latency=1.348733ms
Sep 04 15:43:56 lorawan-server chirpstack[1889]: 2024-09-04T05:43:56.639419Z INFO gRPC{uri=/api.GatewayService/Get}: chirpstack::api: Finished processing request status=“200” latency=2.575191ms
Sep 04 15:43:56 lorawan-server chirpstack[1889]: 2024-09-04T05:43:56.663020Z INFO gRPC{uri=/api.GatewayService/GetMetrics}: chirpstack::api: Finished processing request status=“200” latency=2.880643ms
Sep 04 15:43:56 lorawan-server chirpstack[1889]: 2024-09-04T05:43:56.664057Z INFO gRPC{uri=/api.GatewayService/GetDutyCycleMetrics}: chirpstack::api: Finished processing request status=“200” latency=2.458308ms
Sep 04 15:44:01 lorawan-server chirpstack[1889]: 2024-09-04T05:44:01.816412Z INFO gRPC{uri=/api.InternalService/GetVersion}: chirpstack::api: Finished processing request status=“200” latency=636.851µs
Sep 04 15:44:01 lorawan-server chirpstack[1889]: 2024-09-04T05:44:01.816588Z INFO gRPC{uri=/api.TenantService/Get}: chirpstack::api: Finished processing request status=“200” latency=1.460866ms
Sep 04 15:44:01 lorawan-server chirpstack[1889]: 2024-09-04T05:44:01.819611Z INFO gRPC{uri=/api.GatewayService/Get}: chirpstack::api: Finished processing request status=“200” latency=1.598827ms
Sep 04 15:44:05 lorawan-server chirpstack[1889]: 2024-09-04T05:44:05.987211Z INFO gRPC{uri=/api.TenantService/Get}: chirpstack::api: Finished processing request status=“200” latency=1.19983ms
Sep 04 15:44:05 lorawan-server chirpstack[1889]: 2024-09-04T05:44:05.987779Z INFO gRPC{uri=/api.InternalService/GetVersion}: chirpstack::api: Finished processing request status=“200” latency=775.577µs
Sep 04 15:44:05 lorawan-server chirpstack[1889]: 2024-09-04T05:44:05.989112Z INFO gRPC{uri=/api.GatewayService/Get}: chirpstack::api: Finished processing request status=“200” latency=1.545004ms
Sep 04 15:44:09 lorawan-server chirpstack[1889]: 2024-09-04T05:44:09.152399Z INFO gRPC{uri=/api.TenantService/Get}: chirpstack::api: Finished processing request status=“200” latency=1.302535ms
Sep 04 15:44:09 lorawan-server chirpstack[1889]: 2024-09-04T05:44:09.152905Z INFO gRPC{uri=/api.InternalService/GetVersion}: chirpstack::api: Finished processing request status=“200” latency=544.748µs
Sep 04 15:44:09 lorawan-server chirpstack[1889]: 2024-09-04T05:44:09.164065Z INFO gRPC{uri=/api.InternalService/StreamGatewayFrames}: chirpstack::api: Finished processing request status=“200” latency=1.891979ms
Sep 04 15:44:09 lorawan-server chirpstack[1889]: 2024-09-04T05:44:09.165196Z INFO gRPC{uri=/api.GatewayService/Get}: chirpstack::api: Finished processing request status=“200” latency=1.909595ms

Those logs are just full of API calls (presumably from you clicking around the UI).

Try checking the logs when Chirpstack first starts to see if there are any errors. So restart Chirpstack and use sudo journalctl -f -u chirpstack.

Does your Gateway have any logging? Might be worth checking that if so.

I am not sure what could be causing your issues at this point, it seems as though you’ve set up everything on the Chirpstack side correctly so the problem likely lies with the rest of your setup. Possibly its a networking issue (if your using basic station now make sure your computer firewall is open to websocket / tcp traffic on 3001). Possibly its a gateway issue, I am not familiar with that gateway but maybe if you shared a photo of your config screen it might help.

Hi Liam,

Sep 06 13:18:48 lorawan-server systemd[1]: Stopping chirpstack.service - ChirpStack open-source LoRaWAN Network Server...
Sep 06 13:18:48 lorawan-server systemd[1]: chirpstack.service: Deactivated successfully.
Sep 06 13:18:48 lorawan-server systemd[1]: Stopped chirpstack.service - ChirpStack open-source LoRaWAN Network Server.
Sep 06 13:18:48 lorawan-server systemd[1]: Started chirpstack.service - ChirpStack open-source LoRaWAN Network Server.
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.314798Z  INFO chirpstack::cmd::root: Starting ChirpStack LoRaWAN Network Server version="4.9.0" docs="https://www.chirpstack.io/"
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.314834Z  INFO chirpstack::storage: Setting up PostgreSQL connection pool
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.315269Z  INFO chirpstack::storage: Applying schema migrations
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.344159Z  INFO chirpstack::storage: Setting up Redis client
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.344979Z  INFO chirpstack::region: Setting up regions
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.345039Z  INFO setup{common_name=AU915 region_id=au915_0}: chirpstack::region: Configuring region
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.345166Z  INFO chirpstack::backend::joinserver: Setting up Join Server clients
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.345190Z  INFO chirpstack::backend::roaming: Setting up roaming clients
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.345197Z  INFO chirpstack::adr: Setting up adr algorithms
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.345218Z  INFO chirpstack::integration: Setting up global integrations
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.345224Z  INFO chirpstack::integration::redis: Initializing Redis integration
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.345230Z  INFO chirpstack::integration::mqtt: Initializing MQTT integration
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.357418Z  INFO chirpstack::integration::mqtt: Connecting to MQTT broker server_uri=tcp://localhost:1883/ client_id=304085bdc29064a8 clean_session=false
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.357494Z  INFO chirpstack::gateway::backend: Setting up gateway backends for the different regions
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.357516Z  INFO chirpstack::gateway::backend: Setting up gateway backend for region region_id=au915_0 region_common_name=AU915
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.357566Z  INFO chirpstack::integration::mqtt: Starting MQTT event loop
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.358873Z  INFO chirpstack::integration::mqtt: Subscribing to command topic command_topic=application/+/device/+/command/+
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.367347Z  INFO chirpstack::gateway::backend::mqtt: Connecting to MQTT broker region_id=au915_0 server_uri=tcp://localhost:1883 clean_session=false client_id=3382d6907c88e90f
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.367425Z  INFO chirpstack::downlink: Setting up Class-B/C scheduler loop
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.367435Z  INFO chirpstack::downlink: Setting up multicast scheduler loop
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.367468Z  INFO chirpstack::api: Setting up API interface bind=0.0.0.0:8080
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.367496Z  INFO chirpstack::gateway::backend::mqtt: Starting MQTT event loop
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.368357Z  INFO chirpstack::gateway::backend::mqtt: Subscribing to gateway event topic region_id=au915_0 event_topic=$share/chirpstack/au915_0/gateway/+/event/+
Sep 06 13:18:48 lorawan-server chirpstack[5550]: 2024-09-06T03:18:48.386360Z  INFO chirpstack::api::backend: Backend interfaces API interface is disabled

These are the logs I am seeing from chirpstack.

If everything is setup correctly on chirpstack than it must be an issue between the communication from the gateway and the chirpstack server. The logs from the cisco gateway seem very limited. I’ll see if I can see some sort of logs from the cisco. The firewall on the linux machine is fully disabled as well. Definitely looks like it is listen to traffic over 3001. lorawan@lorawan-server:~$ sudo netstat -ltnp | grep -w ':3001' tcp6 0 0 :::3001 :::* LISTEN 1872/chirpstack-gat

I would look into your gateways packet forwarder some more. I dug into the documentation some myself, try the command: #show common-packet-forwarder log list and see what is happening on the gateway side.

I am also curious how you enabled basic-station on the gateway, as by default it uses the “common packet forwarder” which is ironic because that is not the same as the actually common UDP packet forwarder which may cause compatibility issues with the Chirpstack gateway bridge. If the basic-station packet forwarder is similarly different from the classic it may not be compatible with a chirpstack gateway bridge.

I also noticed a line “GPS is mandatory for the Common Packet Forwarder (CPF) application to work.” seems absurd that would be a requirement but do you have GPS enabled?

Yes, I have GPS enabled on the Cisco Gateway.

Thanks for this information what do you think my best bet is moving forward as I thought Cisco was compatiable with the ChirpStack but I might be mistaken.

I’ll run that command on the device and get back to you regarding the output from the logs.

I think the gateway logs could share some important insight that would determine compatibility, besides that I think it really depends on how technically literate you are and how willing you are to get down in the weeds.

One “next step” I can think of would be to capture a packet coming out of your gateway and compare its structure to a UDP packet forwarder packet, if these are the same / similar enough it could be an issue elsewhere in the networking. If not then it is incompatible, but you might be able to do some post-processing on it to make it work.

When you say you enabled basic-station on the gateway, do you mean you just enabled web-socket security for the CPF (the only web-socket / basicstation-esque setting I could see)? If so then that is definitely not compatible with CS, and I would go back to trying to work the UDP version.