Hi all,
In response to all the requests for tunnel connections, the AREDN team has created an cloud-based tunnel server to create a large/global mesh network. We have been testing this server with a limited number of clients over the last few weeks with good success.
It is now time to take the testing to the next level.
(I'm only posting here in the forums for now to limit the number of requests initially.)
We are looking for additional testers who would like to connect.
There are a few requirements/notes that you should be aware of.
By connecting to this service, you agree to these basic Terms of Service:
- Tunnel clients must be running the latest released version of AREDN (or a higher nighly build)
- No non-AREDN nodes should be directly connected to the tunnel server (RPi's, PI-HSMM, BBHN, etc., although they can be "behind" the client) (ie. no custom builds, no HSMM-Pi, no BBHN clients)
- While we will do our best to keep the tunnel service up and running, there is no service-level agreement (SLA).
- In the event of an actual emergency, AREDN Inc. reserves the right to limit connections to the tunnel server in order to prioritize EMCOMM traffic in affected areas.
This effort, and all of the AREDN Inc. project, is largely funded by a few people.
Bandwidth and resources are not free, so, please consider supporting AREDN Inc. with a recurring monthly donation of $5, $10, or $20.
If you would like to help test this service, please email me at k5dlq@arednmesh.org with the following information:
- Your AREDN Node name that you want to use to connect to the server
- The primary reason why you want to connect to the tunnel server
- Your device type (ie. Ubiquiti Rocket M5, Mikrotik hAP AC Lite, etc.)
- The version of AREDN that you have loaded on the above device
- How many nodes are currently showing in your mesh status page
While we cannot promise EVERYONE a connection at this time, we will do our best to accommodate each request. I will do my best to respond within 24 hours.
If accepted into this phase of testing, we will email you back with your network IP address, your password, and the server address where you will connect.
Thank you,
Darryl - K5DLQ
This is amazing news! I know this is early but I was curious on a few things?:
*1) Will the cloud nodes elevate the 10 connections to a node that standard nodes are restricted to?
*2) will this be made public for those of us that have server access ourselves? By creating a constellation of cloud nodes we can minimize a single point of failure. Of course the cost would be absorbed by the individual point in the constellation and would have to be strictly coordinated by the AREDN team.
Again I realize these questions may be months or more out I am just excited by the possibilities of this! I can see this as a huge evolution of the project.
There is no hard limit on the number of connections the cloud server. It is running in a custom built Linux-based Docker container.
we have not yet discussed distributing it yet. Want to get more miles on it before we start discussing that.
Thanks to all who have responded. We have enough testers at this time. Stay tuned for expanded testing.
K5DLQ - Darryl
Hi Darryl,
here at my side all seems to work fine. I think this feature can help managing the growth oh arednmesh network.
Maybe this feature usable in future to manage local (e.g. italians) networks?
73 de Leo IZ5FSA
Anything that can be done to offload Tunnels to a server will be a great addition to AREDN. Porting to the PC environment locally or perhaps eve a Raspberry Pi could be very useful and likely add some functionality not currently available.
Thanks gentlemen for the effort.
Jim
W8ERW
Great job! I think it might be useful for us as we are opening partnership to use commercial wireless ip network to create redundancy of our network for certain sites that are out of amateur radio reach.
So a tunnel server behind those existing networks to links multiple nodes that will be connected to the mesh at exit points to establish new routes and eliminate the risks associated with a single center site will be more than welcome. I can guess that many will also look to this kind of deployment as it greatly cut the cost for sites and hardware!
Good job guys!
I've got a problem agai on Mikrotik hAC ap lite IZ5FSA-HOME the OLSR system seems to be in troubles.
I can se as neighbor-node a USA node
and this is not true.
To avoid the problem a scheduled daily reboot in crontab seems not to be a solution. In fact, only checking aredn.olsr.restart in advanced configuration and then reboot node can solve the problem.
The latest nightly build can solve the issue? Or... Is there a command to reset OLSR from crontab?
The Advanced Configuration option to restart OLSR simply runs
You should be able to put that command into your crontab to restart OLSR on a scheduled basis.
If this restart OLSR daemon don't solve the problem. Reboot makes the job. I need to clean olsrd "memory" and reboot seems not doing that job.
How much bandwidth will your server use?
Hi All
Are there any updates on the current cloud-based tunnel testing? How many clients are currently directly connected. What are the Bandwidth requirements, etc? Do you have room for more testers? What applications have been tested through the cloud-based tunnel server? Does iperf work through the cloud-based tunnel server?
I know these things take time to implement and monitor. I just wanted to show support and interest for joining this node/server when there there is another announcement.
@n3wtt send me an email: k5dlq@arednmesh.org
Email sent.
Just curious how many nodes are normal for this tunnel? I know this will be a very dynamic number and would be hard to estimate, however I am seeing a wide fluctuation on my end. At times I see 70(ish) Nodes visible with 250+ Total OSLR entries, other times this number is 5 times this amount or more.
clients can come and go as they wish, so, there's not a "stable" number.
After my install of the 3.1 release, my wan display shows a node count of only 74 now (in Virginia), down from around 600. Now as I have a tunnel client up and running from the hotel (in Seattle this week) my node count is 588. This Seattle node is tunneling through Virginia. The numbers are skewed. Anything to be concerned with? My screenshots are over size allowed...grumble. Thanks. John KB4YFK
clients can come and go as they wish, so, there's not a "stable" number. There are currently 29 clients defined on the server.
Thank you. I know it's a the server is in testing was just looking if a bug needed reporting is all.quite impressive what this dev team is capable of.
How many concurrent clients do you think the server will support?
we have an arbitrary limit at the moment of 40, but, haven't seen anything so far that would indicate that we could not increase significantly.
Wow! Thank awesome I would like to partcipate.
FYI for all AREDN Global Tunnel Server DIRECTLY connected clients... please update your client node to 3.20.3.1 ASAP to remain on the tunnel server.
There was a change in 3.20.3.1 to the OLSR config that is important for tunnels.
Your node may be disabled if it is not running 3.20.3.1 (or higher nightly build).
Thanks for your cooperation.
Hello, can someone help me out?
I want to connect to an AREDN Tunnel server for testing.
Best regards,
A
K9AJE
PS: Please email me ar escalantea @ gmail dot com
Hi Darryl,
You have mentioned the capacity of the AREDN Tunnel Server above. What estimate do you have of what a user node must be able to support, in terms of OLSR entries which drives the routing table size?
Currently, I'm seeing ~ 2200 OSLR entries coming in from that tunnel server. If I'm not mistaken, this also corresponds to a routing table size of ~2200 entries.
Is there anything a user can do to decrease this number and still have connectivity?
73, Mark, N2MH
The reason the routing table is so big is that some user(s) are connected to the Southern California network as well as the AREDN Tunnel Server. This is causing instabilities in our network and needs to be disconnected. There is no reason for these two segements to be connected. If a user wishes to be on both segments, that's fine, but they should not cross connect them--one computer on one, one computer on another, do not DtD the nodes.
If another user cross-connects into another metro area you can see how quickly this will fall apart.
We have been dealing with routing loops and mesh "storms" all week in So Cal which renders the entire network useless (including those on the global Tunnel segement).
This sounds like a wonderful adjunct to connectivity. I am currently enjoying the steep learning curve that comes with setting up one's first node! Currently I am breaking new ground in the city of York in northern England, and my solitary and completely isolated node is beginning to take shape. I will soon be trying to get others involved so we can develop a functional mesh to cover the city. An easily set up internet access function (which I am currently struggling to get to grips with) will make the whole idea more appealing to others. Good luck in developing things and when you need more testers hopefully I'll be able to get involved.