I have the mCard in slot 2 if ever and slot 1 is empty.
Both gateways are identical: MTCDT-H5-210L-EU-GB with MTAC-LORA-868 (1.0), using the original power supply.
The mCard is in slot AP1 (I switched it from AP2 - with no difference).
Both are running mLinux 3.3.6 since last week. The GSM functionality is not configured, just Ethernet.
I have a third identical gateway, but that one is still on mLinux 3.2.0 and downgraded to the old packet forwarder (I need it to be up and running). It showed the same problems when I upgraded it to the new forwarder one time.
Please correct me, if i am wrong. But when there is a a “Last seen” status every 30 seconds, i do not receive any valid packets.
I tried the hard way. Completely switching of the gateway, cooling it down, and switching it on after some time. This way it works some times.
When i have the “Last seen” status like more than 30 seconds, there are packets being sent.
Just to note we’re seeing this problem also, with AEP 1.4.1 and the new packet forwarder. We also previously had issues with the old forwarder — on multiple different Conduits — but whereas that would just exit, the process now sticks around but nothing gets forwarded. The last message seen in the log is sometimes:
ERROR: SPI ERROR DURING REGISTER WRITE
What speed is the SPi bus running at? Where can we find the source corresponding to the ipk packages?
SPI is driven by FTDI USB interface, the speed passed to MPSSE is 6MHz.
Github. (lora_gateway for the USB/SPI code, packet_forwarder for the main code and some of the other repos for dependencies)
The 30 seconds are status updates. In between you should see packets, at least that is the case on my units.
Yes, you are right. I do receive packets at these times.
I am not able to correctly reproduce the issue. At some moments, when the status updates occur every 30 seconds, i am not able to receive any packets from my motion sensor.
But this afternoon, i did get packets from the motion sensor even when the status updates were occuring every 30 seconds.
I just saw this occur with 3.0.0-r5 on a remote gateway. Traffic uplink stopped.
Gateway info:
root@mtcdt:~# uname -a
Linux mtcdt 3.12.27 #1 Thu May 5 18:53:23 CDT 2016 armv5tejl GNU/Linux
Status of the packet forwarder was:
516 ? Sl 34:01 /opt/lora/mp_pkt_fwd -c /var/config/lora -l /var/log/
The log file was just not updating –
root@mtcdt:~# ls -lrt /var/log/lora-pkt-fwd.log
-rw-r--r-- 1 root root 384148 Jun 19 12:31 /var/log/lora-pkt-fwd.log
root@mtcdt:~# date
Mon Jun 19 12:53:10 CST 2017
(Note the difference in time.)
I tried to restart:
root@mtcdt:~# /etc/init.d/ttn-pkt-forwarder restart
Stopping ttn-packet-forwarder: OK
Found MTAC-LORA-915 with MTAC-LORA-1.0 hardware
Starting ttn-packet-forwarder: OK
root@mtcdt:~#
But the log showed this:
INFO: [main] Starting the concentrator
lgw_connect:532: INFO: no FPGA detected or version not supported (v103)
Note: success connecting the concentrator
ERROR: SPI ERROR DURING REGISTER BURST READ
INFO: tx_start_delay=1497 (1497.000000) - (1497, bw_delay=0.000000, notch_delay=0.000000)
INFO: End of upstream thread
ERROR: SPI ERROR DURING REGISTER WRITE
And after that nothing was working. I rebooted.
Is there an issue where we’re posting this info?
Feel free to open an issue on github.
I have done so: MultiTech packet forwarder stops sending packets. I added it as an issue on https://github.com/kersing/lora_gateway, which seemed like the most reasonable place, but it wasn’t quite clear to me from context where such bugs should be filed; apologies in advance if it’s on the wrong repo.
Thanks for looking into this!
1 Like
Wondered if there was any update / progress? We’re seeing this on 2x brand new Conduits (MTCDT-LEU1-210A-EU-GB + MTAC-LORA-868), under both AEP firmwares 1.4.3 and 1.4.1.
Have considered installing the previous packet forwarder, but that has a different problem: whereas the new one stays up and shows as connected in the back-end and stops forwarding packets, after some time the process just seems to die where we have the previous software installed on other gateways.
We need to very soon install one of these gateways on top of a 75m tall tower where access is v.difficult, so as you can imagine we’re very keen to do what we can to resolve this. Hopefully without buying a Kerlink…
I have been able to reproduce the issue once, however it did not result in any useful information to solve it.
Lack of time to spend on this because of other community and commercial obligations make progress slow, sorry.
I’ve got the MultiTech AEP model running firmware 1.4.3 and the latest TTN packet forwarder. The packet forwarder service stops at random intervals. I can’t seem to find logs rationalising why it stopped?
Which packet forwarder would that be? The one from TTN github or MP forwarder? If the later, which release?
Sorry, can’t help you with the TTN forwarder. Perhaps it is better to start a new thread explicitly mentioning the TTN forwarder in the subject as most messages in this thread are about the MP forwarder.
Hi every one. I’ve the same problem. Could anyone solve this issue??
Thanks
Does anyone else have a problem with the multi protocol packet forwarder, where it fails to work after a few days of operation? It works fine for typically ~4 days or so, then it disconnects from TTN, stops forwarding packets, and the device appears as offline in the TTN console. The gateway is fine otherwise, I can still connect to it over resin.io, but the problem drives me nuts. I added a cronjob that resets the gateway every night as a sort of temporary fix. Is there any solution to this?
I’m using a Risinghf gateway with this docker build https://github.com/jpmeijers/ttn-resin-gateway-rpi
Hi @ZaneL I have such observations too with the resin implementation of JP. i have a partial solution.
In my case I have 4 gateways from which 2 have LTE connection and 2 ADSL.
All 4 gateways have 2 links to two networs using Setech UDP link.
The gateways using LTE loose their connection between 2 hours and 3 days and need a restart.
This problem is solved when the TTN connection is altered to the protobuf protocol (TCP).
In addition to this problem It was not possible to send (downlink) over the second network. this should be solved by adding the downlink enable variable. however until now I have not been successfull.
I have to invesigate in this further,
2 posts were split to a new topic: Loranet packet forwarder exits when receiving packet with unkown datarate