I’m running UDP packet forwarder on my two (remotely deployed) mikrotik gateways without any issues. For those having issues it might help to switch to the UDP packet forwarder (you will need to change the ‘require authenticated connection’ setting in TTN gateway settings.)
BTW: It seems the pessimists were right. The firmware fix did not work. Issue is still wide open. 
I’m running a development version firmware in which the issue is supposedly fixed. The GW is up for more than a week and I’ve not had a crash yet.
The support person to which I’m talking told they they have finally identified a real issue and fixed it.
I see they have pushed a 7.20beta4 that might include theses fixes, I’ve asked support and I’m waiting for the confirmation. If that’s the case, you might want to try this version even if it’s not ‘production ready’.
I have tried the 7.20beta4 on a knot lr8 but lns/cups wont work so the fix may not be in beta yet!
Great to hear you’re seeing improvements; however, I do not. My wAP LR8 is still “stopping” every few hours even with the most recent firmware versions (including test builds).
Apparently there are a number of problems at play here, and at least the one hitting me is still not yet fully understood.
I’m just glad that there does seem to be work occuring on the issue. The old story: Things do happen, but quality depends on how they are handled and hopefully resolved in the end.
I’ve just received information from support that the fix is backported to 7.19.2 which is currently in internal test phase. So we can hope we’ll “officially” get it very soon…
Support told me that the fix is not in this version but in 7.21dev branch (which is a version I received from them)
1 Like
I did also do a support case with mikrotik and got the info that it was now solved and it should work with 7.19.3 that was released today. But it wont work better than before 2-4 packets are sent to thethingsnetwork then it disconnects again.
On my system, v17.19.3 indeed cleared up the errors. There haven’t been any “stops” for a few days now.
But today I saw something new: For about 20 hours (until I noticed the condition) there was no message reception at all. No incoming messages in the log, nothing forwarded to TTN. Also, no errors, and the LoRa interface was still “active”.
After rebooting the router reception came back immidiately.
Has any of you seen something like this?
I’ve also upgraded 1 test gateway and then 2 production GWs to 7.19.3. One one of them I got the old LoRa issue after 24h (LoRa became inactive) but with previous versions I had this issue several times a day. I haven’t had it for the last 48h now so there’s indeed a progress even if there’s still something going on.
I did not encounter the issue you mention so far … you’re scaring me since this one is probably harder to detect using the API than the LoRa disabled interface … I’ll keep an eye.
I got the issue also regarding traffic being stopped. on my Gateway the LoRa device has “disappeared” , I had to reboot in order to get it back and traffic started to flow again.
I’ve pushed a supout.rif file to mikrotik support.
I had the same issue and so far the switch to version 7.20rc1 has fixed the issue for me. 13h uptime while versions prior to it have stopped the gateway after usually an hour or so (using CUPS/LMS). I have not encountered @vger ‘s problem yet with no messages being forwarded on an active gateway. I’ll keep an eye on it over the next week though. I am glad the legacy forwarder was unaffected by this and could be used as a fallback.
I’m happy to say that with the latest testing firmware I’m seeing no issues anymore whatsoever.
I’m just unsure which dev or release firmware includes the necessary changes, since the changelog doesn’t mention this clearly. The timestamps of the different available versions are confusing in this regard as well. I guess I’m not touching the system until the next release version comes out - this should include the fix for sure.
1 Like
For me, the fix came with 7.20rc1. All recent public testing / development versions did not cut it. You are right, the changelog is rather vague in stating “iot - improved LoRa stability and error recovery;”. I’m just glad it happened on a testing system.