meshed-handler is currently offline when I’m looking at one of my applications from console.thethingsnetwork.org When looking from console.thethings.meshed.com.au it states ‘App … not registered to a handler’ Moreover, meshed-route is no longer an option to select for a Handler. Is there a status/monitoring site for all the services, handlers, integration providers? Is anyone else experiencing the same issues with meshed-handler?
@Maj Andrew, is there still problems with the server?
Integrations are still not shown on the meshed console.
Yes, I have the same problem
Yes looks like Integrations are still a problem. Restarting the integrations had no effect. I’ll ask the TTN Core team to look into it.
Resolved now
2 Likes
Ohh, I just found this post, while writing a query with the subject “There are no available integrations for handler meshed-handler. Check back later!” Luckily the related post search system sent me here.
I tell you, that until now, I had been using the gateway, in AU915 (from Argentina), with meshed-router, but in the application I used the Brazilian router, and in that way, it saved the “problem” that meshed-router did not offer integration.
Having known that this hidden console for meshed-router existed … should be documented and referenced in the main console …
The scheme of using the application with the router of Brazil, worked well with the integration until August 4, when it stopped working. Since then I am looking for the reason for the failure.
Now I will configure everything from the specific console for meshed-router and I tell you the result.
Regards
Hugo
Hi @hmullerenersa. There are problems with cross-region routing. You should try and use the handler that is in the same region as your gateway. So use either:
- ttn-handler-brazil and ttn-router-brazil
or - meshed-hander and meshed-router
Probably Brazil is a better match for you.
We have seen problems before where routing stops working, usually between meshed-router and asia-se-hander or eu-handler, but probably with any handler. The TTN Core team are aware of the issue, but it’s unlikely to get fixed, since V3 will probably address this.
1 Like
Hi Andrew
What a pleasure to receive a response from you, yesterday I discovered that the meshed-router was located in Australia, physically speaking, and that there was a separate console for this router.
In my experience, I started using the handler in Australia, because here in Argentina we use the AU915 frequency plan.
On the other hand, I used the Brazilian router, ttn-router-brazil because until yesterday, I was the only one that offered me integrations with Cayenne and DataStorage, as I was using the standard TTN console (the only one I knew until yesterday), I didn’t see the integrations when choosing the router meshed-router.
Well, after knowing the existence of the alternative console (https://console.thethings.meshed.com.au/), I set option 2 and it is working!
My configuration, which worked correctly, was meshed-handler + ttn-router-brazil but on Sunday, August 4, it suddenly stopped routing.
Initially I thought I had been penalized by FUP, because as I am in the development phase, I may have exceeded the limits during the tests, but I also read a very interesting post from you that confirmed that there were no penalties currently or bans.
I take advantage of your knowledge to clarify a great doubt:
If my gateway and devices are working on AU915, can I choose any combination of handler + router, preferably from the same node, or should I choose how I did that of the meshed-router due to the assigned frequency plan?
Or put another way, when the gateway connects, does it download directives for the channels it must activate and deactivate, based on the frequency plan of the handler?
It is a great doubt that I have. If the frequency plan is only defined in the gateway or if it must be matched in the handler and router.
Thanks in advance, I hope my doubt has been understood.
regards
No, depending on the software on the gateway it will use the local configuration file (global_conf.json usually) or it will download the channel plan based on the configuration (Frequency plan variable) you specified in the console.for the gateway. The frequencies used do not depend on the handler chosen.
Hi Jac
I currently use two Kerlink Gateways, one iBTS and one iFemtoCell. Both have the global_conf.json file with the AU915 frecuency plan.
I don´t understand that mechanism use, and what kind of gateway do this, to download frequency plan and from where is downloaded eventually. Can you give me some example to understand better this frequency plan update mechanism
So, then I can register my gateway on any handler with their correspondent router, based on the minor network transit time independently of the frequency plan used?
Thanks in advance
Hugo
@hmullerenersa In El Salvador (Central Americas) We are giving the users the instruction to use the router with less network hops to reduce network latency. In our case the closer router is the US router.
In general the gateways only Forward packets to the cloud infraestructure, the frequency depends on two things:
global_config.js defines the frequencies that the Gateway operates both for Uplink and Downlink, the frequencies are globally defined by the LoRaWAN alliance for each region, and you should expect that they are not going to change soon.
The “Frecuency Plan” selected on the Gateway Configuration on The Things Network Console.
The region must match between this two settings and the end-nodes to be able to route packets. It doesn’t matter if the region used uses a different band-plan it is going to answer to the node with the frequencies applicable for the specified Frecuency Plan.
Because the answers for down-links are time-critical you should would want to use the region that is physically closer to your physical location.
We hope that some day we could have a back-end for Central Americas located in Guatemala or Panama because they are the two countries with better global connectivity, meanwhile we are instructing the local gateway owners to use US-WEST even if the region uses a different band-plan.
2 Likes
Kerlinks do not update the configuration so you need to make sure the configuration is right. Examples of gateways downloading the frequency plan are The Things Gateway (original), The Things Indoor Gateway (TTIG) and some Raspberry Pi based gateways. The source of the frequency plan is the account server.
Yes. Please do. Network delays should be as small as possible to prevent them interfering with the LoRaWAN timing.
1 Like
Hi Jac
Thanks you very much, for clarifying the concepts.
With respect to select the network with small delays, I try to ping all servers, with the surprise that all have ICMP blocked.
| ROUTER | ROUTER uri | IP | Ping time |
|---|---|---|---|
| Digitalcatapult-uk-router | ttn.thingsconnected.net | 52.56.216.89 | ping timeout |
| meshed-router | thethings.meshed.com.au | 52.62.83.250 | ping timeout |
| switch-router | ttn.opennetworkinfrastructure.org | 86.119.29.227 | ping timeout |
| ttn-router-asia-se | asia-se.thethings.network | 13.76.41.40 | ping timeout |
| ttn-router-brazil | brazil.thethings.network | 191.235.82.46 | ping timeout |
| ttn-router-eu | eu.thethings.network | 52.169.76.255 | ping timeout |
| ttn-router-jp | asia-se.thethings.network | 13.76.41.40 | ping timeout |
| ttn-router-us-west | us-west.thethings.network | 13.66.229.235 | ping timeout |
So, considering that it is not possible to ping or tracert, what method do you suggest to select the optimal router?
Thanks in advance.
Hugo
The infrastructure is hosted in the azure cloud which does not support ping. Selecting the closest one geographically should work. See the suggestions of @hackerspacesv
As you can see on this map. For the Central Americas region it doesn’t make a lot of sense to connect to any other endpoint rather than the one located in the US.
Yes, I am a network specialist engineer, but that map (https://www.submarinecablemap.com/) corresponding to submarine optical cables, does not indicate anything about the route that the packets are going to take, this is defined at the logical level of routing and may not be the shortest path, nor the closest geographically.
From Argentina exist almost one direct path to europe for example https://www.submarinecablemap.com/#/submarine-cable/atlantis-2 …
Jac
Regarding that Azure does not support Pings, allow me to dissent, it is a matter of definition, any service in the cloud is configurable with respect to whether or not to accept ICMPs, at the virtual machine firewall level.
If by security definition, TTN servers have the response to ICMP blocked, this consists of a definition, not a limitation or imposition of Azure.
I will try to make a traceroute through auxiliary services to see which router is more convenient from Argentina, if I find a solution to the dilemma, I will update it here.
Thanks
TTN uses load balancers in Azure which do not have ICMP enabled. I don’t know if that can be changed (and I don’t manage that infrastructure so I don’t care).
BTW, Azure has firewalls in front of VMs so enabling anything at VM level won’t help if you don’t configure the intermediate firewalls to allow the traffic as well.
An aproximmate tracert may be obtained using TCPTraceroute, https://www.websitepulse.com/tools/tcp-traceroute-test# This traceroute to port 80, without using ICMP, from 3 predefined sources (New York, Germany or Australia). With two traceroutes is posible to have an aproximation, i think…
Example: tracing from Australia to thethings.meshed.com.au 52.62.83.250, return 12mSeg, and it´s logical.
| Host tested: | 52.62.83.250 |
|---|---|
| Test performed from: | Melbourne, Australia |
| Test performed at: | 2019-08-12 20:43:37 (GMT +00:00) |
| Hop Hostname (IP) Round-trip times |
1 111.67.5.252 0.109 ms 0.335 ms 0.337 ms
2 216.14.207.31 2.953 ms 3.183 ms 3.194 ms
3 101.0.127.77 12.881 ms 12.857 ms 13.086 ms
4 45.127.172.131 12.979 ms 12.984 ms 13.219 ms|