K1KY Q:
Darryl,
Question on tunnel connections.
I have a remote station that is "normally" connected to our system via RF, but also has a wireless Cellphone modem available for internet connection. I normally have the tunnel client on this station "disabled" and the receiving tunnel server "enabled". The problem with that is if I lose MESH RF connectivity, I can't remotely control the tunnel connection to turn on the client.
What kind of problem does it present if I enable the tunnel on the client end but diable it on the server end, thus enabling me to turn on the tunnel connection from the server side? Does this create any unnecessary "traffic" or "load" on the tunnel client or would this be an acceptable practice for a backup connection in case of RF connectivity failure?? What about the data usage over the Cellular Modem when the tunnel isn't connected, but it is "trying" to make a connection? The reason that I don't want to leave it connected all of the time (tunnel) is that the cellular modem is a pretty slow connection - slower than my RF connection and it defaults to use it when it is turned on since the tunnels have priority. (This is another case where we would like to be able to assign first priority of the RF path and the tunnel as secondary ).
-------------------------------
K5DLQ A:
If the client is enabled it does send a login request periodically (I think every 5-10 seconds) which will be denied if the server is disabled. The packets are very small, but, there is traffic there.
And to "priority", that is a limitation of the underlying OLSR protocol.
-----------------------------
Other input MESH Gurus?
and have the home node which is now server, become a client for this cellular node (you can be a client for this node and server for others at the same time)
and then enable and disable the client node (which now is the server) as needed.
the server on the cellular network will not generate traffic or load trying to connect to the client... it will just sit there standing by until you initiate the connection from the client.
'And to "priority", that is a limitation of the underlying OLSR protocol.' This is false, this is not a limitation of the protocol by any means, it is a limitation of the configuration provided for tunnels currently. I can't recall off hand what the final discussion around setting the priority was (and I won't bother searching my archives without a feature request ticket for it) so I can't say off hand if this would change or not if requested, but if you want it you should run it through a feature request ticket.
That said even with doing that OLSR routing data would still have to transition the cellular data even if the RF had connections. This data adds up, even on a small network it can be several gigabytes a month of data. On a cellular connection that can be the entire months allocation. I can think of other feature requests with just 20 seconds thought that can solve this "Tunnel connection starts if a node looses all neighbors" comes to mind as the first (no guarantee it would be accepted but someone who is willing to champion it might be able to make an argument for it being an EMCOMM feature)
Unfortunately with all that excluded if you don't have access to the node remotely (EG you can't run it as a SERVER or access its web interface over the internet) then it will have to be a client and you will have to accept the traffic loss of a constant connection attempts mentioned in your post. Or as an alternative to above you could have a small computer (Pi or any other SBC) on your network that does some sort of monitoring and executes a curl script to log into the mesh node to enable the tunnel when no neighbors exist.
Interesting to read this chain... once you get past the clutter, I think Aly and Conrad have two essential ideas to answer Tom's excellent question.
1. Putting the server on the cellular or other metered Internet service makes great sense, as it avoids cost.
2. Monitoring of the neighbors and use that to trigger a tunnel client enable function, or even a tunnel server enable function is wise.
A couple of ideas come to mind:
1. Don't assume that it is only a "no neighbors" condition to trigger the tunnels.
2. Routing to isolated segments of the network could also trigger a tunnel and reduce the number of nodes carried by the OLSR.
3. Some method to gather and share nodes and services of a segment of the net needs to be considered.
4. . BGP is one answer, but needs optimization or alternatives for our network.
5. Routing may be needed via a tunnel when a specific segment is isolated, but when do you drop the tunnel? Based on Connectivity? Traffic? What else?
6. It has been noted that with the large number of nodes on various tunnel connections that we have situations where the network reconverges and loses end to end connectivity during data transfer even though all the links are stable. Not sure why, but routing priorities are changing rapidly and that may need to be moderated.
7. Aly and I were discussing this specific topic the other night with a fix of switched tunnels to reduce traffic, but that creates issues as implied above. More discussion is needed and this is a good start.
8. Monitoring and control using an external processor, e.g.an RPI, is good, but if there is some specific peer node or nodes whose loss would trigger a tunnel connection, then maybe that could be driven by a tiny embedded app on an AREDN node?
9. If we are going to use an external management processor, then we might want to consider a redundant set of control processors and possibly even the addition of non-RF nodes running OLSR, BGP, and other routing protocols in addition to tunnels, DHCP, DNS and the like at the network's management and data planes.
Conrad mentioned the need to better understand the priority of RF and Tunnel links. Since this is a popular topic that also extends to getting an understanding of our implementation of OLSR, I think someone on the Development team should post an article or two describing these elements, as it could spark some additional development to help better scale and manage this network. Alternatively, maybe we could get the raw resources online for members of the AREDN community to examine and describe for a broader audience.
Thoughts?
Gordon Beattie, W2TTT
201.314.6964
See the "For Developers" tab it includes content access on these technical items including sourcecode. Beyond that our low level protocols are defined in code and internet RFC standards (everything from the IP standard, Ethernet standard, 802.11 standards, OLSR standards, etc.) Information is available if you are wanting to contribute.
For those who do not have the technical expertise to contribute directly bloodhound accepts feature requests tickets, you don't need to be a technical expert to request these just an average user and the technical team will sort out what doable, what isn't, what meats the project goals, what doesn't etc.
Thanks for your reply.
It's helpful to be reminded of the partial solutions you thoughtfully offer.
One thought about your manner of delivery.
Reading your comments is like reading the President's Tweets... I may agree with the message, but I feel scolded and cringe at the phraseology.
Let's try to be encouraging as we all have many common goals and want to see the platform grow in functionality and applied utility.
Vy 73,
Gordon Beattie, W2TTT
201.314.6964
If your node with the RF connection has an indicator LED that only lights up when your RF connection is active, you could kludge up a circuit that senses the voltage around the LED, or maybe a light sensor that can output a signal you then could use to drive a relay that could say enable or disable the ethernet wire connection to the cellular tunnel. Maybe short the ethernet TX lines together, and short the ethernet RX lines together (or the relay contacts closed would pass all the RX and the TX lines, or open them to kill it), to kill the ethernet wire connection. I've gotten away with such ugly transmission line sins, as long as the length of the cable is reasonably short, so the ethernet reflection/error corrections can deal with it. Yeah, I said it was a kludge...