RAK7249 - Large Data Usage Problem

Hey there,

I am using a RAK7249 outdoor gateway and I am seeing an insane amount of data being used from it. Gigabytes are being used in the matter of a day or 2. I am not sure why this is happening as I am not seeing a lot of packets in the LoRa packet logger - Only 33 in about 2 hours.

If anyone has any idea of what is going on or how to fix it please let me know!

Thanks.

How is it connected and how are you measuring the data use?

It is currently connected via cellular with a Bell SIM card. The current usage for the month so far has been 21169.878MB. I am measuring/seeing this via the online management platform. I can also see in the cellular interface for the gateway that it is using a lot of data in a short amount of time. (See screenshot).

Thanks,

1 Like

I am only using LTE as a fallback in case ETH is not working and for remote SSH login. And I am not seeing any excessive data usage. Maybe 50MB (mostly for remote administration).
I recommend if you’re seeing a bug you should post which firmware version you are using at a minimum.

I am currently using firmware version 1.1.1 - I gave it an update when I started noticing the problem but it seems to still be using a lot of data. This gateway is primarily cellular as it is in a rural area.

I guess I should also be asking what an acceptable amount of data would be from this gateway when it is on primarily cellular… I am not exactly sure what I should be expecting, but I did not think gigabytes within days seemed right…

1 Like

If you’re running primary cellular with the Semtech UDP Packet Forwarder you should be seeing about 30MB/day if you’re receiving approximately 5-10 average sized LoRa packets per minute. Way less than you’re seeing.

I am assuming you have your gateway properly secured, and not the default root:root password exposed to the internet and nobody is using yours as a proxy or botnet file host?

Yes it should be secured from the public. I use OpenVPN to connect to it and have the password and such changed from default. The area it is in is not densely populated so I doubt anyone is using it as a proxy or botnet file host. After about 14 hours today it had used almost 3/4 of a GB… Which is A LOT.

1 Like

If you are using OpenVPN tun routing uses less data than tap. tap can create more traffic because it transfers broadcast traffic. Check if your OpenVPN config uses tap and consider changing to tun.

Another thing would be to use netstat -u -t -p on an SSH terminal which shows current network connections and check if you see something unusual. Otherwise I don’t know.

Any advice from the RAK staff here or RAK support?

One of my customers has just reported teh same problem on some of the RAK7249 units they are using with cellular backhaul. Has anyone seen a fix for this problem or identified the cause?

RAK have answered this query directly: to reduce the data volumes increase the Statistic Interval and Keep Alive interval in the LoRa Network settings. Switching from the UDP packet forwarder to MQTT will also decrease data usage.

Actually I am also seeing now increased data usage over the last month.

I am using LTE as backup only (no UDP packet forwarder traffic and no LoRa Keep Alive traffic over LTE!).
And still I am seeing close to 1 Gigabyte traffic on LTE over the last month!

Interface: wwan0
RX: 317.66 MB(2949587 packets)
TX: 460.41 MB(2844323 packets)
Connected: 11d 16h 45m 22s

And that is with already increased multiWAN interval from 5 to 30.
I will try with 500 next month and see if that helps.

root@RAK7249:~# cat /etc/config/simple_multi_wan

config source 'ethernet'
        option enabled '1'
        option interface 'wan'
        option reliability '2'
        option count '1'
        option timeout '2'
        option interval '5'
        option down '3'
        option up '8'
        option priority '1'
        list track_ip '8.8.8.8'
        list track_ip '208.67.220.220'
        list track_ip '114.114.114.114'

config source 'wifi'
        option interface 'wan0'
        list track_ip '8.8.8.8'
        list track_ip '208.67.220.220'
        list track_ip '114.114.114.114'
        option reliability '1'
        option count '1'
        option timeout '2'
        option interval '5'
        option down '3'
        option up '8'
        option enabled '1'
        option priority '3'

config source 'cellular'
        option enabled '1'
        option interface 'wwan'
        list track_ip '8.8.8.8'
        list track_ip '208.67.220.220'
        list track_ip '114.114.114.114'
        option reliability '1'
        option count '1'
        option timeout '2'
        option up '8'
        option priority '2'
        option interval '30'
        option down '2'

config mwan3_config 'ethernet_wifi_mobile'
        option path '/etc/simple_multi_wan/mwan3_ethernet_wifi_mobile'

config mwan3_config 'ethernet_mobile_wifi'
        option path '/etc/simple_multi_wan/mwan3_ethernet_mobile_wifi'

config mwan3_config 'wifi_ethernet_mobile'
        option path '/etc/simple_multi_wan/mwan3_wifi_ethernet_mobile'

config mwan3_config 'wifi_mobile_ethernet'
        option path '/etc/simple_multi_wan/mwan3_wifi_mobile_ethernet'

config mwan3_config 'mobile_ethernet_wifi'
        option path '/etc/simple_multi_wan/mwan3_mobile_ethernet_wifi'

config mwan3_config 'mobile_wifi_ethernet'
        option path '/etc/simple_multi_wan/mwan3_mobile_wifi_ethernet'

Updating the gateway firmware to WisGateOS V1.2.3 fixed the problem for me.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.