I’m having tunnel issues with 3 of my AirRouters out in the field using various builds from 3.19.3.0 to the most recent 1000. I’m using the MikroTik hAP ac lite. It drops in and out but usually shows connected on the tunnel page but may not show up on the status page. Most often I cannot connect to the nodes even when the LQ/NLQ is at 100%.
I have downloaded my support file from the hAP but I’m attempting the get the support files for the remote AirRouters but it’s like trying to catch the Cuckoo bird exiting the clock! I will download one when I can catch it!
Is this an issue with anyone else?
Thank you in advance,
Denis
Support File Attachment:
The hAP has more memory and should be OK with 3.19+, I am running one with a tunnel now and no problems with 3.19 - but limited experience/loading up to this point.
Thank you all for your comments.
Looking back, the particular problem I had was that - above a certain workload - the response to the GUI would get so slow as to be almost unusable. It seems that the other functions were working but hard to see ... anyway this is the original string of comments on the issue (which may or may not be what you are seeing)
https://www.arednmesh.org/content/airrouter-slow-update-page
Just grabbed my AirRouter and put it on line thru a ~750mile (as the crow meshes) tunnel to check on a remote site and all continues to work well with my AR running the 3.19.3.0 release. I have a number of tunnel clients defined in it, but only run one at a time when I do (occasionally), and then *never* connecting one mesh island to another (so not much traffic passes thru it).
Offered as just another current AR data point. (I love that AR almost as much as my Mikrotik AREDN-Swiss-Army-Knife node.
HTH,
- Don - AA7AU
edited to add: with both MeshChat and Tunnel Server/Client installed and active, this is my current: flash = 436 KB; /tmp = 14112 KB; memory = 3820 KB -- also: connected into Las Vegas area I had: OLSR Entries: Total = 126; Nodes = 40
NB: While this can be a contentious issue, please also note that our [informal, non-chartered] LVmesh group actively discourages any use of "tunnels" except in the case of 1) emergencies; 2) limited appropriate community-support events; and/or 3) proper control operator functions limited to a temporary single end-point connection.
Sounds like a good thing to have (connection verification watchdog) "that can monitor the status of tunnel connections and reset the connection if trouble is detected on the server end". I haven't encountered the issue as I have my tunnels enabled in general for only a short time and/or have not had the type of connection disruption you write about. Guess if we ever had to rely upon a tunnel in an EmComm situation, especially more than short-term, this could be very troublesome indeed.
Diamonds are forever, tunnels not so much? Mr Scott: charge up the dilithium crystals ... we need more RF.
Good luck,
- Don - AA7AU
Thank you all again. It does describe as Tom's issue at times some of the other descriptions as well. I am testing one of the AirRouters now back to 3.19.3.0 and if that's a bust I will move down to 3.18.x.x
I agree about the use of tunnels but we back here in the Northeast are fighting hills valleys and most of all trees lots of trees many as tall as your LV buildings.
Update: We are moving down to 3.18.9.0...
Thank you!!
Joe AE6XE
Thanks Joe,
We backed it down to 3.18.9.0 and it seems to be working very well now. I have to get to 2 others but if you want me to hold off I will wait for your findings.
Here is the Support from the same node that now is running 3.18.9.0 but was downloaded with I believe 960 at the time. Would you like the 3.18.9.0 for comparison?
73,
Moo!!
"19.07 will be the last official build for 4/32 devices. After 19.07, no further images will be built for 4/32 devices, i.e. you have to build your own image with the known space saving measures"
This probably means 4Mb Flash or 32Mb RAM devices may not be built in OpenWRT on their current bleeding edge development. AREDN doesn't fit in 4Mb Flash devices, so we are 8/32 for most of the Ubiquiti AirMax models. Always be sure for any new purchase to get a 16/64 or greater device. 8/64 at minimum, but risk there may not be enough space to install optional packages, like tunnels. In some cases, there may not be any options, e.g. 3GHz devices are only known to be made by UBNT AirMax line -- 8/32 Nano Station/Bridge and 8/64 Rocket.
Joe AE6XE
Joe
If you mean turn off the RF on hAP ac it shows:
" Configuration not saved" then next line:
"Some settings auto updated to avoid conflicts, please review and save one more time"
I never had that message before and not aware where that setting is in Firmware 1010
If you wanted the AirRouter RF off, version 3.18.9.0 doesn't have the RF feature.
Denis
Joe,
I backed the hAP down to 3.19.3.0 and disabled the RF and it still fails to connect to the AirRouter still on 3.18.9.0. It also is showing 100%/100%! One of the AirRouters is at a hospital and is set to be connected to my hAP by a tunnel but I don't have physical access to it because of security issues, hopefully it will not be a problem once connected. I don't remember what version firmware is in it as it has been sitting for over a year or more while we wait for IT to connect it.
Denis
I guess this issue is unresolvable at this time so I will use my spare hAP ac at the hospital to tunnel all our nodes in from Providence into our VoIP server. If anyone finds an answer please let us know.
Again thank you all for your input!
Denis
I have a hAP Microtik and a Nano m5 and have the same error on all of them when loading tunnel server or client ..I am doing something wrong see pictures.
thanks K5GZL aka ki5etd
Doug
DHCP, and Services
Server
Client
Configuration
Thanks W6bi. I knew it was something simple...Thanks for pointing me in the right direction.
I have three 5.8 and one 2.4 online running Asterisk , Mesh chat and some cameras . I just don't have any neighbors in So Texas. So I need a connection.
Doug