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.
1 Like
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.
3 Likes
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.
@pe1mew
I’m using @kersing packet forwarder, now the LED management is done by a python script running by systemd
check the script monitor*.py there
So it should be easy to add them 
2 Likes
Add them to the resin container you mean… 
Both methods will work. If you decide to go the opkg route you will need to stop the running packet forwarder by hand and start the new one after install. The installer is probably easier.
Correct, it’s what I did, worked like a charm (stop, opkg, start)
1 Like
Hi,
I am having a similar problems with my gateway, trying to install a new LoRagateway using Multitec Conduit, I fallowed all the instructions contained here: https://www.thethingsnetwork.org/docs/gateways/multitech/aep.html, and also upgraded the packet forwarded from the last link provided 2 days ago, after registering my gateway on TTN page I always see it as “not connected”, I have this logs displayed on putty for my packet forwarded intalation
admin@mtcdt:~# tail -f /var/log/lora-pkt-fwd.log
16:02:51 INFO: Flush output after statistic is disabled
16:02:51 INFO: Flush after each line of output is disabled
16:02:51 INFO: Watchdog is disabled
16:02:51 INFO: Contact email configured to "paula10mem@gmail.com"
16:02:51 INFO: Description configured to “”
16:02:51 INFO: [Transports] Initializing protocol for 1 servers
16:02:54 ERROR: [TTN] Connection to server “bridge.eu.thethings.network” failed, retry in 30 seconds
16:03:04 ERROR: [TTN] Connection to server “bridge.eu.thethings.network” failed, retry in 30 seconds
16:03:27 ERROR: [TTN] Connection to server “bridge.eu.thethings.network” failed, retry in 60 seconds
16:03:37 ERROR: [TTN] Connection to server “bridge.eu.thethings.network” failed, retry in 60 seconds
16:04:30 ERROR: [TTN] Connection to server “bridge.eu.thethings.network” failed, retry in 120 seconds
16:04:40 ERROR: [TTN] Connection to server “bridge.eu.thethings.network” failed, retry in 120 seconds
16:06:33 ERROR: [TTN] Connection to server “bridge.eu.thethings.network” failed, retry in 240 seconds
16:06:43 ERROR: [TTN] Connection to server “bridge.eu.thethings.network” failed, retry in 240 seconds
16:10:36 ERROR: [TTN] Connection to server “bridge.eu.thethings.network” failed, retry in 480 seconds
16:10:45 ERROR: [TTN] Connection to server “bridge.eu.thethings.network” failed, retry in 480 seconds
I am very new in this LoRa technology and I am not even pretty sure if there is something wron with my configuration or with my hardware.
Could anybody suggest me a test that allows me to know if the Multitech is not working properly. Or even to realize if I am Or even if I’m configuring the gateway wrong?
Thanks in advance for your help
I would think this message tells it all. The gateway tries to connect to bridge.eu.thethings.network and that connection is unsuccessful. Is port 1883/tcp being blocked by a firewall? Or by your provider?
Thanks, actually I could fix it erasing “rm .installer” file from the gateway, that error was displayed everytime I was trying to download the Packet Forwarder.
That error is generated by the packet forwarder so you had already downloaded and installed it. So I’m not sure how removing the status file of the installer would help.
Anyway, glad you got it working.