I see that the GW has received 5+2 messages (in this log snippet). They did not appear in the logging of console?
It seems as if connection status is not printed in your log:
21.02.18 11:56:31 (+0100) ### [ CONNECTIONS ] ### 21.02.18 11:56:31 (+0100) # bridge.eu.thethings.network: Connected 21.02.18 11:56:31 (+0100) # Semtech status report send. 21.02.18 11:56:31 (+0100) ##### END #####
i presume you are using the updated version from Jac?
Maybe I did’nt wait for a long enough time but no I did not see any connection status logs, and rebooted since.
I use the version shown on the following URL:
https://www.thethingsnetwork.org/docs/gateways/multitech/aep.html
Is that the one you’re refering to?
I downloaded it from https://github.com/kersing/multitech-installer/raw/master/installer.sh
(it uses TCP on port 1883, not UDP)
I had never connectivity problems with the Multitech-Gateway over months. Something at the backend must have changed too. Now i have daily issues. At least it is Linux i can run a simple script who watches over the connection. Ok there are many new gateways since christmas, but the scaling should be calculable.
The good news for RPi users, pull the current sources for all components, rebuild and your reconnect issues should disappear.
Once the new version is running the status should include the lines:
### [ CONNECTIONS ] ###
# bridge.eu.thethings.network: Connected(Of course the bridge.eu.thethings.network part varies depending on the TTN server you connect to)
For the MultiTech owners, if you want to, grab an updated package from
http://office.the-box.com/mp-packet-forwarder_3.0.20-r1_arm926ejste.ipk , transfer to your MultiTech Conduit and use ‘opkg install mp-packet-forwarder_3.0.20-r1_arm926ejste.ipk’ to update to the new version. The installer will be updated as well, however that will take some time as testing the updated installer is time consuming.
(Logging should include the same lines after update)
great news… tnx Jack !
Thanks, will try. Would you mind to publish the Checksums of the packet? md5sum sha256sum is supported by busybox on multitech.
md5sum: 8f3364c09910df3077fd0f6930b4bea1 mp-packet-forwarder_3.0.20-r1_arm926ejste.ipk
Great thanks! I installed it successfully on one of my gateways.
Thanks, put it on one of my testing gateways as well.
@kersing can you recommend ways to test it before it goes out into the field gateways? (or it should be OK?)
Also, does it replace the global_conf.json file completely with a new one? (just wondering because on one of my gateways we put in the “autoquit” line, and wondering if I have to remove that or will it just get overwritten anyway. I saw that it was updated in the install of the ipk
cheers
Paul
edit: never mind answered my own question, it gets overwritten
I had the same issue on another GW (4G Internet came after forwarder start and forwarder was never started because of on internet) and I kept things simple, every 5 minutes if forwarder is down restart it.
created a file /etc/cron.d/forwarder_restart with the following content (adjust for your os and forwarder)
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
*/5 * * * * root /etc/init.d/lora-packet-forwarder start
Of course check the init script to be sure forwarder does nothing if it already started
Since that no more issues, I know not clean, but took me 5 minutes and solved my issue.
Th difficulty with your solution @Charles is that it is less simple to implement while using resin.
I’ve done extensive testing (aided by community members) and I am confident the software is at the same level of reliability poly forwarder is at. However, it is still software and I haven’t mathematically proven it to be correct 
As you found it will be overwritten. It is overwritten on every restart of the sotware on MultiTech conduits. Keep in mind “autoquit” only works for the semtech protocol, the ttn protocol has no option to quit the software when the connection is lost. (Yes, I have been tempted to take that route in order to work around the reconnect issues but in the end didn’t have to resort to it)
After 4 weeks of testing on multiple instances of the multi packet forwarder I can confirm that the current version of @kersing the multi packet forwarder is no longer suffering from link failures. It reconnects despite the bad 4G link quality.
Great, what’s the best update option?
opkg the ipk provided by @kersing above or can we update the version already installed by reinstall like that?
wget https://github.com/kersing/multitech-installer/raw/master/installer.sh --no-check-certificate
then
sh installer.sh
@Charles For my trials I used production gateways that use the resin.io implementation of @jpmeijers. That implementation is retrieving the last repository from @kersing during installation.
It is not the answer to your question but a quick explanation of what I have done.
@pe1mew you can use resin.io on multitech?
I would love using resin.io but I always need specific features and I don’t know how to add them on resin (like service for blinking led, display information, install private lorawan server, install WiFi AP on GW, …)
So these things take me less than 15 min to configure on RPI Zero with concentrator so I don’t have time to spend days to achieve the same on resin.io, but as I said I would love 
Sorry for the confusion. I am running RapsberryPI and IMST IC880a gateways not Multitech.
This was the first topic in my memory where the multi packet forwarder linking issue was mentioned that seems to affect all deployments of multi packet forwarder.
As I had good results I wanted to share them with the community and I choose this thread to share them as that seems the best to me.
I do know your led additions to the packet forwarder and they are nice and helpful but it is a derivation of the code of @kersing and it is not simple to maintain both.
I think it is relatively easy to fork the resin.io repo of @jpmeijers and replace the multi packet forwarder with your own fork.
It would be great to merge your features to the main trunk of multi packet forwarder. I my opinion that can be relative simple.
