Gateway statistics not showing

Bocajim · March 20, 2018, 6:24pm

I am not seeing statistics for the gateways, but they are receiving data from devices and forwarding it to my application.

Anything I am missing?

brocaar · March 21, 2018, 2:36pm

The first thing to check would be if your gateway is actually sending stats This is configured through:

github.com

Lora-net/packet_forwarder/blob/master/lora_pkt_fwd/cfg/global_conf.json.PCB_E336.EU868.basic#L220


    },


    "gateway_conf": {
        "gateway_ID": "AA555A0000000000",
        /* change with default server address/ports, or overwrite in local_conf.json */
        "server_address": "localhost",
        "serv_port_up": 1680,
        "serv_port_down": 1680,
        /* adjust the following parameters for your network */
        "keepalive_interval": 10,
        "stat_interval": 30,
        "push_timeout_ms": 100,
        /* forward only valid packets */
        "forward_crc_valid": true,
        "forward_crc_error": false,
        "forward_crc_disabled": false
    }
}

If you have a Tektelic Pico gateway: there was an issue with the stats which is solved in the latest firmware update.

Bocajim · March 21, 2018, 3:30pm

Confirmed, the stat_interval is set to 20 in my config.

lorenzo75 · March 22, 2018, 9:07am

@Bocajim,
you should verify that your packet forwarder has the protocol version 2. The protocol verstion 1 of the packet forwarder doesn’t send the stats.
You can look at the lora-gateway-bridge output: whenerver it receives data from the packet forwarder it dump the protocol version.

brocaar · March 22, 2018, 9:10am

What gateway are you using (vendor / model)?

Bocajim · March 22, 2018, 1:31pm

@lorenzo75 That looks to be the issue.

I have 4 gateways, 2 MultiTech Conduit mLinux units, and both appear to have v1 of the protocol packet forwarder. I also have 2 MultiTech LoRa AP units and they are sending V2 of the protocol (and the gateway statistics are working).

So now I just need to figure out how to upgrade the Conduits.

Thanks,
jim

lorenzo75 · March 22, 2018, 1:36pm

My suggestion is to try to connect to the vendor site and look if there is a newer version already built for your devices.

brocaar · March 22, 2018, 2:07pm

If you follow these steps and install these packages (lora-packet-forwarder or lora-packet-forwarder-usb), you should see stats

elliott · April 5, 2018, 7:02pm

@Bocajim did updating your conduits help you? Mine are running mLinux 3.3.22 and lora-packet-forwarder-usb 1.4.1-r11 (the latest for both) and I’m still not getting gateway stats. Thoughts?

lucdioc · July 18, 2018, 6:12am

Dear Mr. Brocaar,
I have one gateway in a remote site using 3G as backhaul and this gateway stats are not visible on the Lora-App-Server web interface, even if the gateway is perfectly functional.

This gateway on 3G does not have the lora-gateway-bridge installed on the gateway, only Semtech packet forwarder.

It’s not a big deal but it is a bit strange, particularly taking into account that I have 5 other gateways of the same brand and configuration, using Ethernet as backhaul, and those gateways stats are visible.

Any clues of the reason for such “problem” ?
Thanks in advance,
Lucas

brocaar · July 18, 2018, 6:15am

You should check first if the gateway is sending stats at all (e.g. using tcpdump). Test this from your gateway and at the receiving side. If your gateway is not sending any stats. I don’t think this is 3G related.

acaton · September 25, 2018, 11:35am

Hi all,
I am having the same problem with a Multitech Conduit ABP gateway. I’ve tried everything, even updating the packet forwarder, but nothing seems to work. I’ve tested with tcpdump in both sides, the gateway and the LoraServer, and I can confirm that I am receiving a stats packet.
The packet forwarder says this:

##### 2019-02-20 11:30:57 GMT #####
### [UPSTREAM] ### 
# RF packets received by concentrator: 4
# CRC_OK: 50.00%, CRC_FAIL: 50.00%, NO_CRC: 0.00%
# RF packets forwarded: 2 (140 bytes)
# PUSH_DATA datagrams sent: 3 (806 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
# BEACON queued: 0
# BEACON sent so far: 0
# BEACON rejected: 0
### [JIT] ###
# SX1301 time (PPS): 271655707
src/jitqueue.c:448:jit_print_queue(): INFO: [jit] queue is empty
### [GPS] ###
# Valid time reference (age: 3 sec)
# GPS coordinates: latitude 45.00683, longitude 0.16662, altitude 81 m
##### END #####

JSON up: {"stat":{"time":"2019-02-20 11:30:57 GMT","lati":45.00683,"long":0.16662,"alti":81,"rxnb":4,"rxok":2,"rxfw":2,"ackr":0.0,"dwnb":0,"txnb":0}}
lgw_receive:1155: FIFO content: 1 4b 1 7 4b
lgw_receive:1174: [1 17]

And indeed, the gps coordinates and altitude are being correctly received and shown on the LoraServer, but the rx packets graphics are plain.

Any ideas of what can be happening?

acaton · December 13, 2018, 1:57pm

Hi,
I finally found the problem with the statistics not being stored!
I’ll write it here just in case somebody has te same problem. The thing was that one of the multiple gateways on my network didn’t have access to NTP time nor GPS time and therefore, the time and date were wrong. Apparently, loraserver discards the packets with wrong timestamp without complaining on the logs
Anyway, the temporary solution was to set the time manually. Now it works like a charm.
Kind regards,
Adrián.

brocaar · December 18, 2018, 1:04pm

Using the timestamp for aggregating the stats is more likely

Rokscript08 · January 11, 2021, 5:00am

Hello,
I’ve been using the chirpstack server for six months now, no problem, but recently something happen and the gateway stats are not showing up, they’re stuck at Last seen 19 days ago. Even though, I’m still getting the devices data and gateway stats are showing on the journal and mosquito.

Thats the log from the MQTT sub, and the next one is the journal log from the network server:

Thanks for the help.

brocaar · January 22, 2021, 3:05pm

Please see the error on the last line. You ChirpStack Network Server can’t reach the ChirpStack Application Server API.

snspinn · December 17, 2021, 10:55am

@elliott 3 years late is better than never? I think some older hardware cannot support the v2 protocol, regardless of installed packet forwarder version. Older multitech lora cards are one example. Has anyone else seen this behaviour?
I’m trying to confirm, but it appears to me that the latest chirpstack and/or lorawan 1.0.3(+) don’t work well with v1 protocol (semstech udp packet forwarder).