Yesterday morning my Mikrotik gateway went off line, I connected with my phone to the WiFi AP and have access to the internet.
I check all the settings and seem fine to me, I rebooted it, but the gateway did not reconnect.
I subsequently have rested to factory default and reconfigured - still not connecting the the TTN server, but I can access the internet via the AP and I can log in from my router side (LAN) into the gateway.
There’s multiple join accepts e.g. TX in response to RX, in that traffic log so I think your assessment is 100% correct, although the existence of the proprietary line there reminds me this list shows CRC-error packets by default e.g. noise that looks like LoRa. </pet peeve>
Why not connect both gateways (only, one at a time) through a router on which you can run tcpdump or tshark, look at the UDP traffic and compare. Particularly look to see if the cycle of push/pull and their corresponding acks is working.
Oh, incidentally, two UDP based gateways behind the same NAT router is apparently a known issue for some NAT implementations… though that tends to affect the downstream side not the upstream, unless the packet forwarded gives up when it doesn’t get any acks.
… which is a very nice description of sitting around waiting for someone else to fix the problem.
Do you have an actual suggestion for getting this user’s gateway back online? You might note I’ve made concrete suggestions for understanding the issue faced by the existing software, and not just jumped to the idea of replacing it - in fact it was Johann, not I, who blamed the incumbent software, my point is as much that the closedness of components makes understanding the problem challenging, not that I’m ready to conclude the factory firmware is actually responsible for the failure…
I’m not saying it doesn’t, but could you be specific about exactly what piece of evidence or test leads you to conclude it is getting responses back from TTN servers?
Unless I’m mistaken, the leftmost “RX” column on the “Join Accept” messages in the earlier log are things it received over the air, not items queued into it by TTN which it transmitted over the air.
If there is UDP traffic going both ways, I’d be really curious to pull it apart. Maybe some condition changed causing one end to format things in a way the other can’t handle, or maybe it is just too spotty with dropped packets.
Does Miktrok speak the ordinary Semtech UDP protocol, or a custom variation?
Also worth wondering if something is going on with your gateway EUI… if it is derived from a network interface MAC could it have changed? Could someone have, er, “stolen” it by accident for theirs? You’ll see the EUI in the raw UDP, too.
These Join-Accept packets were the leading me to believe there are traffic from the TTN to the gateway.
If the left column that’s cropped off now says “TX” I’d entirely agree.
But in your previous post from an earlier run, it clearly said “RX”
(Granted, I can’t rule out the possibility of a web GUI bug mislabeling everything as “RX”)
But then it’s possible to note that those downlinks don’t seem to be time-correlated to any received uplinks recieved by this gateway which could have triggered them, so I’m still learning towards intercepting the transmissions of another gateway.
Kinda odd that traffic isn’t sorted by timestamp, either. But even looking through that I’m not seeing uplink/downlink pairings, except perhaps with something clipped off.