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.
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
Joe AE6XE
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)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