<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 30, 2017 at 3:14 PM, Brian <span dir="ltr"><<a href="mailto:n1uro@n1uro.ampr.org" target="_blank">n1uro@n1uro.ampr.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Corey;<br>
<span class="gmail-"><br>
On Mon, 2017-01-30 at 14:53 -0500, Corey Reichle wrote:<br>
> Why would you use OpenVPN (Or, any other tunneling) over RF links?<br>
> That would be silly.  Routing of IP packets is handled by the AX25<br>
> stack (Or other link layer protocol in use, which could be 802.11).<br>
> No IPEncap required for that.  Just routes.<br>
><br>
</span>You're absolutely correct but there are guys using OpenVPN servers who<br>
are using push to force that issue. Not good.<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>While that may be true, that is neither hither, nor thither regarding the NYS network.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> We're discussing tunneling of IP traffic over an IP network that is<br>
> wired, that's all.<br>
<br>
</span>One needs not to be licensed to be a glorified ISP.<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>I fail to see what that has to do with the price of tea in China.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
><br>
> OLSR is also a dynamic, self-healing routing protocol, that is heads<br>
> and shoulders above RIP protocols, as it is also a self-discovering of<br>
> neighbors and routes.  See Broadband Hamnet's work with that.  It is<br>
> also usable over wired networks.<br>
><br>
> OpenVPN tunnels are used to bridge two networks together.  Hardware<br>
> behind that provides the routing to other networks, and with OSLR,<br>
> having mutliple possible routes is possible, with routing loops<br>
> prevented due to it's design.<br>
<br>
</span>So since the hardware device would *still* require ipencap to speak to<br>
the rest of 44/8 and the global internet, why would you wish to<br>
introduce not one but 2 potential points of failure?<br>
<br></blockquote><div><br></div><div>It doesn't need that.  It's desired, due to the "not invented here" syndrome that plagues many ham activities.  If the manager of the 44/8 network is willing to do so, any number of points in the NYS network could be bridged over a VPN tunnel into there, and appropriate routing decisions made at that point (ie, based on link costing).  Or, two designated points in NYS could be the uplink.  Or, none, and for example, myself, being close to PA might have a route to the PA network via RF, which might have a route to the wider network.</div><div><br></div><div>Of course, this is presuming a modern, link-state routing protocol is used, such as OLSR, or OSPF.  Or, even doable with static routing.  All negating the need for any of this.</div><div><br></div><div>So, it's not introducing 2 points of failure, it's a manner of providing multiple, redundant paths.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Case in point, ALL if Ireland now is forced to use an OpenVPN system.<br>
It is now quite isolated and unreachable. There was a perfectly working<br>
system with an HF gateway using ipencap to ARDC which is now DOA. Once<br>
that additional point of failure was brought in, the "wire" failed just<br>
as it would in an emergency.<br>
<br></blockquote><div><br></div><div>Again, not pertinent to the discussion here, really.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also when you think about it, since vpns use a form of ipencap, and the<br>
method used by ARDC is designed **specifically for amateur usage** and<br>
it does indeed work, why reinvent the wheel?<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br></div></div></blockquote><div><br></div><div>They use a form of it, yet.  However, the method used by ARDC isn't available in COTS hardware, therefore, makes the network more difficult to deploy, and scale.  I fail to see how a custom RIP daemon and a niche clear-channel tunneling protocol is specifically crafted for amateur usage.  The AX25 stack, yes, but that's not what we're discussing here.  We're discussing IPv4 routing over RF links.  There is no "reinventing the wheel" here:  What I'm suggesting is the exact opposite:  Stop reinventing the wheel, and use the systems in place in the wider IPv4 networking world.</div><div><br></div><div>We could, and should, learn some lessons from the wider schools here.  What we're discussing is a mesh network, on a wide scale.  Much like Freifunk network (<a href="https://en.wikipedia.org/wiki/Freifunk">https://en.wikipedia.org/wiki/Freifunk</a>).  They did not write their own custom routing protocol.  They used an off-the-shelf, modern link state routing protocol.  Nodes come and go at will, and the network autodiscovers new routes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">
--<br>
I don't have to worry about body fitness in 2017. All I do is<br>
show my body to itself in the mirror and it throws plenty of<br>
fits.<br>
--------<br>
73 de Brian - N1URO<br>
email: (see above)<br>
Web: <a href="http://www.n1uro.net/" rel="noreferrer" target="_blank">http://www.n1uro.net/</a><br>
Ampr1: <a href="http://n1uro.ampr.org/" rel="noreferrer" target="_blank">http://n1uro.ampr.org/</a><br>
Ampr2: <a href="http://nos.n1uro.ampr.org" rel="noreferrer" target="_blank">http://nos.n1uro.ampr.org</a><br>
Linux Amateur Radio Services<br>
axMail-Fax & URONode<br>
<a href="http://uronode.sourceforge.net" rel="noreferrer" target="_blank">http://uronode.sourceforge.net</a><br>
<a href="http://axmail.sourceforge.net" rel="noreferrer" target="_blank">http://axmail.sourceforge.net</a><br>
AmprNet coordinator for:<br>
Connecticut, Delaware, Maine,<br>
Maryland, Massachusetts,<br>
New Hampshire, New Jersey, Pennsylvania,<br>
Rhode Island, and Vermont.<br>
</div></div><br><br>
<br></blockquote></div><br></div></div>