That’s really good for you! We are pretty locked to the US routes. Almost all ISPs route our traffic through Miami (Only God knows why). For us getting to Australia always implies taking several hops via US or South Americas.
@hackerspacesv 12mSeg is testing with the online TCPtraceroute tool “FROM AUSTRALIA” “TO AUSTRALIA”, is not the time from Argentina to Australia. I wish it was like that 
You could try configuring a gateway for different TTN routers and note the RTT in the packet forwarder logs.
1 Like
Andrew your idea sound a excellent method to make a comparison. I will try it on next days.
Hey @Maj
Any issues currently with your TTN meshed forwarder? Our nodes are hitting our gateway and says its getting to meshed, but no MQTT output from TTN for the nodes since around 130am this morning.
We had the same issue about a week ago at about 240am in the morning, then the nodes started sending MQTT data that afternoon at aroun 330~4pm.
Howdy,
Same issue here. My devices last update was at same time as yours, 1.30 am Jan 9th. I’m in Melbourne.
You mentioned you are using meshed router (your gateways will connect to this) but is your application handler located elsewhere? I.E you are not using meshed handler for your app.
I was using Asia handler (ttn-handler-asia-se) for my app and figured forwarding from meshed router wasn’t working to Asia handler. I have other lora deployments (other applications) using meshed handler, and they were not effected. Hence my reasoning.
I tried a few apps with different handlers (not meshed) and all failed to show device updates. Could only get it working using meshed handler.
I moved my devices to a new application using meshed handler and restored comms and working now. A bit messy as to changing he handler deletes all devices, so must back up device details first.
Regards
Rory
There have been issues with cross region use of gateways and applications for a long time and in V2 of the TTN stack those issues will not be solved. The official statement from TTN is to use an application using the same region (handler) the gateways use to avoid issues.
We are experiencing issues with mqtt from Australia Meshed Handler, i Hope that current catastrophe due to the fires is not the origin and that the Australian people soon manage to control the fires.
The last mqtt hit was 08/01/2020 19:16:10
I´m connecting iotfactory platform thru mqtt with TTN and from 1 day ago, no mqtt connection was possible.
Not sure mate, the fires have been extensive here. I put the outage for 12 hours last week possibly to the fires as the connections eventually resolved themselves last time. I’ll have to check again today was still offline as of last night so maybe 48hrs offline now.
Just makes me nervous as we are looking to potentially deploy a lot of nodes commercially with TTI. We have a few POC nodes on TTN which have been working great for the last 3~4 months. On the day we had a quick chance to show our customer the progress unfortunately the network was down so we didn’t have any real current data we could show them.
Ok, will look into changing them over. Maybe just lucky we haven’t hit this issue before.
from console.thethings.meshed.com.au/ I am not able to make any integrations when I register to either us-west, EU, or meshed_handler. Is there still an outage for AU? Does the meshed server not work at present for integrations?
I have switched to using the SE Asia handler and the AU-915 bands. Then don’t use the meshed console - just use the regular TTN console https://console.thethingsnetwork.org/
There are other ways around but the meshed handler/meshed console just seems to introduce unnecessary complications.
In you’re in Australia you should use:
- meshed-router for gateways
- meshed-handler for applications
- console.thethings.meshed.com.au for the Console when configuring integrations. You can use the regular console at all other times.
The problem with using asia-se is that other people in Australia may have applications registered on meshed-handler trying to use your gateway and the cross-region routing is intermittent and won’t be resolved until V3 is implemented.
See also below for a July 2020 discussion about:
1 Like
I was using the meshed-router for my nodes at university since June , and it was working ok for AU915 frequency plan until this last weekend. I figured out that the OTAA Join Accept is using a different frequency from TTN frequency plan (https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html). Have anybody also detected this behavior ?
There is a problem with OTAA Joins at the moment on the Australian network. Some devices (mostly random) are affected. We are in discussion with the TTN Core Team and hope to have it resolved overnight.
Thanks, the instability has been solved !!!
Hi @Maj, hoping you can shed some light:
-
After about 4 months of operation on around midnight on 8/7/2020 I lost connectivity from a bunch of my Laird RS191 field sensors across a bunch of Dragino LG308 gateways. Turns out that the reason for this is that their Join-Accept’s started specifying the downlink frequency of 923.2 (vs 923.3). FYI I’m on the AU915 band.
-
After much troubleshooting I’ve discovered that due to a bug in the LG308 GUI, they were using the as923.thethings.meshed.com.au router (incorrectly listed as “meshed-router” in the GUI) as the server address on the gateway. So all my gateways in the field are pointing at this rather than the AU915 thethings.meshed.com.au router.
My running theory is that the as923.thethings.meshed.com.au router has been processing AU915 downlinks correctly up to midnight wed 8th July 2020.
All my gateways are in the field and I don’t have remote access, so hoping I can find a way to get 923.3 Join-Accepts from the as923.thethings.meshed.com.au router… BTW, all my gateways are registered on TTN with the AU_915_928 Frequency plan…
Do you know or can you advise how I could find out if there have been any changes in the oz meshed network that could have triggered this??
Thanks and kind regards,
Dave.
Is there an issue with meshed? I was running my devices 2 weeks ago with no issue but now I cannot get my devices to connect. my gateway connect correctly but I cannot get sensors to join. They are just sending join requests. Trying to use AS923 and have tried AS1 and AS2
Is there any status dashboard for meshed? very frustrating…
Just in case it helps, from Slack on Thursday July 9th (Amsterdam time):
Actually, the backend has undergone a significant update on Wed, then a partial rollback yesterday. If your gateways are using MQTT then for now there should be no difference, but the UDP bridges have now been replaced by the v3 GS Offloader.
They still should show the correct frequency plan though.
There’s is more about that on Slack; see also How do I get a Slack invite?
@arjanvanb Thanks Arjan for the feedback - I’ve joined the Slack channel, and reading through the thread it does look like the timing of the changes on the meshed router backend correlates with the impact to my traffic. Interestingly, my backend also reports correctly via “ttnctl gateways list” as AU_915_928, but when doing "ttnctl gateways status " shows EU_863_870.
Reported time: 2020-07-19 13:24:30 +0800 AWST
Frequency Plan: EU_863_870
Bridge: gs.v3.
[Edit][2nd Edit] Actually, if I add in “–router-id meshed-router” to the command above I get the AS_923 frequency plan:
Reported time: 2020-07-20 00:36:09 +0800 AWST
Frequency Plan: AS_923
Bridge: gs.v3.
IP Address: 1.127.104.10
So just need to figure out via @Maj if as923.thethings.meshed.com.au can still honour the AU915 frequency plan that’s assigned in TTN and listed with “ttnctl gateways list” command like it was before rather than what I assume is the default plan for the gateway itself…