Add ability for DtDlink capability riding over 3rd party RF links

[ae6xe]

Submitted recently by Orv W6BI, and numerous discussions by AREDN team and other groups in the past. Some of the scenarios for this feature:

1. usage of TDMA AirOS P2P link (is expected to have higher thoughput than CSMA AREDN links unless channel is too noisy, if stuck in part15 space).
2. existing part15 wireless links.

In such scenarios, the 3rd party wireless networks would be configured to look to an AREDN node like a cat5 cable. However, these RF links would have higher data loss and thus require different settings to behave as expected. Existing DtDlinks over a cat5 settings, if used over an RF link, would drop out unexpectedly. OLSR requires different settings.

The design discussed to date:

1. create a new vlan 3 for connecting AREDN nodes over a 3rd party RF link
2. usage of 172.x.x.x similar to tunnel link address space to conserve 10.x.x.x address for mesh devices. (transparent to mesh users.)

Deliverables would ideally include:

1. updating switch config examples to include vlan 3
2. firmware updates
3. Doc on usage and 3rd party device requirements, e.g. the 3rd party network, could be used to connect many AREDN nodes (many to many)

[wd6eby]

I like the idea of of moving the wired network to the 172 block as long as it is tagged as vlan 3. Are you proposing leaving the 172 addressing up to the end user or automatically assign it via the MAC address as in the past? If setup via MAC addressing please also have incorporate the vlan3 tag. If left un-tagged the 172 address block would cause conflicts with my existing 172 network.

[n2mh]

One might also extend the idea of OLSR shaping to Tunnels. K1KY has experienced that some of his Internet connections are not CAT5 quality. This tends to drive OLSR bonkers. In addition, it can be expected that at some future time, someone will try to bring up a tunnel in the field using some arbitrary WiFi connection that can be found. This type of connection can not be expected to be CAT5 quality either.

[blm2008]

This would still be a very useful feature. Several of our area's node locations are connected by existing or planned point-to-point microwave--some Part 15, some licensed. AREDN isn't the right approach for those links as they need to carry non-amateur traffic, but we'd like to be able to use a VLAN for AREDN node inter-communication. It's been a few months since this issue was opened and we've been anxiously awaiting it making it into the nightlies. -- de N4CV

[ae6xe]

There are groups doing this today, suggesting contacting W6BI to consider options in the interim.

[Orv]

aredn/aredn_ar71xx#462 is NOT a duplicate of this issue; it's a recommendation for an easy alternate solution. Please consider it. Thanks.

[Orv]

In Ventura County we're able to locate radios on several elevated sites on private property in exchange for providing Internet access to the families living on these remote properties. So those links have to be Part 15 radio links because they're carrying traffic that might violate Part 97 regulations. We do partition VLAN 2 off on these trunks for management purposes.

However DtD links default to a wired ('ether') status, and as such Joe has explained to me that the code is designed to drop out at an LQ lower than about 90 percent. Frequently a Part 15 link can have enough interference enough to cause the LQ to drop below 90. Additionally, a link carrying heavy but normal traffic can have its LQ drop when there's nothing wrong. This premature disabling of a link causes unwanted dropouts, or even route flapping if there's an alternate route to the destination.

What we do to work around this is to remove the assumption in the AREDN config that every DtD link is a wired connection. We do that by commenting out the line

option Mode 'ether'

in /etc/config/olsrd

It's a hack, but it works. The problem is, it's not persistent. That is, every time you upgrade the software in a node, it reverts to default and has to be commented out again.

We in this area have concluded that the 'ether' option should just be removed completely. If a DtD link (regardless if it's wired or wireless) is having a problem and drops below 90 it should be allowed to keep passing traffic. After all, we don't drop out RF links because they drop below 90.