You are here

Joining AREDN on Debian

7 posts / 0 new
Last post
KF0ALV
Joining AREDN on Debian

Howdy Folks,

I'm a new HAM with an interest in Mesh networking and a development background. Recently, Ive started working on a new personal project, mesh-front-py . This is intended to be kind of an updated version of the old hsmm-pi project. But it has a few different goals:

  • Targeted to AREDN and OLSR, but eventually I want to add in a batman-adv so I can use it with my personal LibreMesh network.
  • Access to the -1 and -2 channels if a Call-sign is added
  • Python instead of PHP
  • Minimalist with shallow / common dependencies. Less to get out of date.
  • Not as tied to Raspberry Pis or Beaglebone blacks. More with old laptops in mind like the defunct project Byzantium.

Right now its fairly along and basically allows joining AREDN type networks on the non HAM channels. I'm playing around with the optional badman-adv configuration option. Take a look and tell me what you think.

Some stylistic question; how much hand-holding around the HAM type features do people here generally go for? I see AREDN doesn't really require a call-sign for the -1 and -2 channels or higher powers. And I'm conflicted about warning out on a node broadcasting encrypted OLSR services like https if running on a HAM type network(my understanding is this is a violation of some of the fcc rules, but I could be wrong). Do you folks think these types of things should be allowed without warning, allowed with warning, or no allowed? I'm generally of the option that these things should be allowed, but I am also slightly concerned about non HAMs using these features and causing issues or getting in trouble.

AE6XE
AE6XE's picture
KF0ALV,

KF0ALV,

On the AREDN team, we've been wanting and starting to look at LibreMesh in thinking about what's next after OLSRv1, which no longer has active development.    Batman Adv (layer 2) and Batman BMX (layer 3) is something in consideration.     Any ideas you have of how these routing protocols could be used to replace OLSRv1 would be a welcomed discussion.  We have to figure out how to auto-assign addresses, probably means jump to IPv6, to have autonomous mesh nodes that join the network with no pre-planning. 

In regards to creating gateways with AREDN and other mesh networks, and part 97 issues...   This is my personal observation and opinion and may not represent others on the AREDN team.   I don't see my role or the AREDN firmware as a police role and expect a licensed Part 97 operator to be responsible to meet the obligations of their license.  However, A fellow ham will come knocking on a person's door, if they do not have a node name that includes their callsign and transmitting under part 97 operations --  this would mean they are not transmitting their callsign as required by part 97 operations.   We all share the responsibility to work together and as a community operate in the spirit and intent of part 97 licensing.   Not everyone will agree on what this means, for some issues. 

There are a few things to consider to attach to and extend the AREDN network with custom devices.   Some of the issues that have occurred in the past, as an example, include a stable OLSRv1 version.  The default olsr version generally available in linux is an ancient .0.6.x version, and has since had 1000+ fixes.  Also, having consistency in how OLSR is configured, otherwise risks breaking some information everyone sees in mesh status.   Firewall rules and implementing a matrix of policy routing tables is necessary, to avoid breaking expected behavior and gateway default routing.   

There are EMCOMM focused groups that will be concerned if the network they are building is no longer a production environment with experimentation developing a mesh gateways.  Be sure to move forward with open dialog if/when moving from the bench to connect to an existing AREDN network in your area. 

Joe AE6XE



 

KF0ALV
This might be a little off

This might be a little off topic, but as it sounds like the project is looking at LibreMesh / Batman-adv, some notes some of the things I've been fighting with might be useful as Ive been converting over (while leaving in an OLSRd legacy mode).

I did eventually switch my project to default to batman-adv over OLSR. Don't worry, it should still default to OLSRd if meshing with an AREDN / BroadBand Hamnet. The main thing that cause me to do this was it appeared OLSR was starting to be pulled out of some linux repos. I ended up switching my project to just build from scratch every time, but the writing appears to be on the wall for OLSR.

LibreMesh turned out to be a bit more complicated than I originally expected. It seems to use a mixture of Batman-adv and BMX6, and to be honest, it seems a bit beyond me. It might not be a bad path forward for AREDN going forward; it might just be a matter of adding the changes to allow the -1 and -2 channels, the high power modes, and the Call Sign + hostname stuff.

Eventually what I ended up doing is creating basically a base mesh Batman-adv. It fairly easy if there is not internet uplink. Basically, auto generated IPv6 addresses can be used, Avahi/Zeroconfig can be used for (non routable) IPv4 addresses. The main issue here is having IP addresses that change every reboot is causing me issues with other areas in my project (having CJDNS gateways).

Or, if an internet gateway is available, this node can serve up IP addresses with a DHCP server on bat0. The other nodes can be configured to be dhcp clients on bat0. And this will take care of a lot of the work around setting node IP addresses. Of course the big issue here is if you have more than one internet gateway. And to be honest, the only reason I went down this path was because I was having issues with Batman-adv’s gateway client / server settings.

The rabbit hole I am going down now to have more static IP addresses is to have a mode where IPv6 addresses are used, but generated on something like the hostname + interface MAC. Then maybe using Zeroconfig to broadcast out gateways (and other services). After a node is meshed, it would have to choose a gateway. This kind of goes against the “automatically picking the best gateway” design of most modern mesh networks, but it solves my main problem in the short term.

AE6XE
AE6XE's picture
Good input.   Part of the

Good input.   Part of the issue I noticed with libreMesh is the architecture is focused on clients ability to get to internet content, the primary use case.   The AREDN primary use case is for clients to talk to one another.  If there are any NAT ipv4 boundaries in use, it is problematic to get all the services working and ease-of-use for the community to configure.   Using ipv6 addresses everywhere would help solve this issue.  If there were more hours in the day, I might be able to experiment with the options.

Joe AE6XE

KF0ALV
Here is what I'm leaning

Here is what I'm leaning toward for my consistent IPv6 addresses: fe80:::MESH:HOST:MACA

MESH is the SSID of the mesh network, HOST is the hostname, and MACA is the mac address of the device, all put as strings through something like the below python function. This allows a sub-net to limited to the mesh SSID while without gobbling up too much of the IPv6 space (and avoiding IP conflicts with CJDNS as much as possible). This also allows the IPv6 addresses to visually clump inside of the MESH.

The reason the MAC address of the interface is added is because Ive seen examples of people naming their nodes all the same hostname. Also, it would allow multiple interface IPv6 addresses inside of the same host (which sounds like a good idea...).

So for my hostname of 'localhost', and an SSID of 'MyMesh', I would have something like 'fe80:::0862:c38e:eeee'. Here is the example code I used which I converted over from my hostname to IPv4 address function:


def get_bg_by_string(num_size, base, bit_groups_count):
    # Build a long number based on string
    total  = 0
    offset = 1
    for c in base[::-1]:
        total = total + (ord(c) * offset)
        offset = offset * 10

    # Pull off bit_groups_count digits by num_size
    bit_groups = []
    for bg in range(0, bit_groups_count):
        bit_groups.append('{:x}'.format(int(total % num_size)))
        total = int(total / 1000)

    return(bit_groups[::-1])

print get_bg_by_string(16, 'MyMesh', 4)
print get_bg_by_string(16, 'localhost', 4)
AE6XE
AE6XE's picture
Take a look at this idea, to

Take a look at this idea, to encode the call sign into the ipv6 address:
https://destevez.net/ipv6-for-amateur-radio/

The mesh in this Batman usage is contained at layer 2 protocol.   Today, In AREDN, the mesh is at the IP layer 3 at a higher level across all RF links.  The use case of deploying,  means there are many RF mesh islands (2 or more nodes with multiple hops and hidden nodes within range of each other), on the order of 10s to 100s of these RF islands for a large network.       I suspect there may need to be separation between the SSIDs and how  ipv6 addresses are derived, given how the routing works to get IP traffic to all these mesh islands.   We'd not want to have to coordinate an SSID to be in use between all the RF mesh islands that don't have an RF path to connect with each other. Part of the requirements, unlike libremesh, is to require no pre-coordination.  A mesh node should be able to join an existing network, regardless of its topology, without having to pre-coordinate any information.   Probably, the ipv6 addresses need to encode the information unique to a given layer 2 mesh island for routing to work.

Joe

KF0ALV
Its becoming more clear that

Its becoming more clear that IPv6 solves multiple problems.

I didn't even think of just using a call-sign and encoding that directly inside the IPv6. I was kind of going at it like AREDN, where I have a HAM radio mode that changes the hostname of the machine (and ideally high power modes with the -1 and -2 channels). Of course, I loose some characters when encoding the hostname to IPv6, so that might not work alone for the call-sign reporting requirement.

With an IPv6 call-sign you would also be able to predict the IP of the user just by knowing their call-sign (maybe with a optional index on the end). And if there was a linkage between the Mesh islands like with an overlay network gateway; you could maybe even cross from one island to the next just by knowing the Call-sign.

Another call-sign option that might be available on batman based Meshes would be to change the mac address of the wireless card (like with "macchanger"). This might not have met the reporting requirement with OLSR as it was at the IP layer, but as batman is at the Ethernet layer; my understanding is batman-adv acts like a giant Ethernet switch. Ill have to test if two nodes that are not direct neighbors are still aware of each others MACs to see how feasible it.

I’m not sure what regulations are around changing MAC addresses. I know Ive only messed with macchanger in the past when getting a wireless penetration testing cert. So it might be a grey area for all I know.

Ultimately what I ended up doing with my batman-adv mesh was defaulting to auto generated IPv6 addresses, and also running an Overlay/“darknet” (Yggdrasil [ https://yggdrasil-network.github.io/ ]) tunnel interface on each node. As this additional IPv6 layer is also a public encryption key for encrypted communication, this may not be an option for Ham radio based mesh networks.

The main remaining issue is service discovery, which seems to be built into OLSR. Im sure something similar can be grafted on to an IPv6 network with something like Zeroconfigs service discovery.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer