Will the dd-wrt olsr mesh firmware talk with the areden mesh network?
if so anyone have configuration details for the dd-wrt side?
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
N8EMR,
One of the benefits of AREDN is that a standard configuration of how mesh nodes talk to each other is packaged. The entire network has consistency and we can all be assured when bringing live a mesh node, it will fit in and we can count on the network working.
DD-WRT has no standardized 'network' packaging for a mesh network. In the sense that, yes this is software, anything is possible, a DD-WRT node could be configured to attached to an AREDN network. This would be a fun experiment to do in the lab, but risks bringing instability when trying to co-mingle DD-WRT nodes with an AREDN mesh network. The network can only be counted on to work depending on each individuals ability to make the DD-WRT node work.
If you proceed to experiment with DD-WRT, the AREDN mesh node OSLRD configuration can be directly inspected. It's a matter of applying the same config in DD-WRT and learning how to do so.
Joe AE6XE
and...
making sure that it is in compliance with the FCC regs (ie. callsigns, encryption, etc)
That'd be important if all the components inside AREDN are truly bulletproof. As the recent example of route flapping and looping in the San Diego network shows, this isn't always the case. It'd be unwise to let the concrete harden prematurely. There's still a lot of work to be done first.
KA9Q, about 9 months ago a user was joining a foreign device to the mesh (was tunneled). The configuration was bad and OLSR spam took out some portion of the network. The comments from Darryl and I are intended to address the best practices to avoid shooting a fellow mesh'er in the foot.
We are all getting to know the weaknesses and warts on the network when all the nodes are AREDN. When other devices are added, more unknowns are introduced. From many of your posts, it is clear that you see this experimentation as beneficial and part of the process to evolve and improve (I do too), but wearing my EMCOMM hat, it is problematic for the live mesh connecting City EOCs to be this playground. A staging area or test lab environment is preferred. If we're creative, we can build in network segmentation for both purposes (the lab doesn't have to be indoors).
Joe AE6XE
I fully agree. And when the network actually begins to carry traffic from city EOCs, etc, we can certainly begin to isolate the operational side of the network routine and experimental amateur use.
Any given week on the OC mesh network, we may give a demo to a City Emergency Manager. The last thing we want to do is lose the opportunity because a demo failed. Tomorrow will be a live session included in ICS and EMCOMM training in the Santa Ana Red Cross building. We won't be waiting to ensure our operational network has a known capability. If we did wait, we'd likely never get to the point of actually carrying a City's EOC traffic.
I didn't quite grok that last part. You're willing to demo a network to a "customer" without first ensuring it can do what you tell him it can do?
My experience in the engineering business is that rarely does everything rest on a single demo. It's usually an iterative process. They (and you) learn if you understand their problem correctly and know how to solve it, even if you haven't finished yet. Demos (plural) are only one element.
Experimentation (of which testing is a special case) is exactly how you determine whether a system can do what you want it to do. I know I've said this before, but I'm not sure I'm saying it right. There's much more to making an emergency network than putting something together and placing a high wall around it with a sign that says "emergency use only".
As another example.
Locally here in San Diego we have a "rouge" device that advertises itself as "maggie.ka9q.net".
As i understand it its a Raspberry Pi and its providing some sort of firewall services and bridling between a home network and the mesh. All which could be done without needing to speak native OLSR on the firewall router, but the user chose to make it speak to the mesh routing for some as yet unknown reason.
This device unfortunately doesn't comply with the AREDN protocol naming standards and is operating outside spec because its hostname is outside the local.mesh namespace and its not advertising correctly.
Because of this it caused some code that was (in my opinion) not written as robustly as it could be to behaving in an unexpected manner causing display problems. While I accept its our job to make the code handle as many situations as possible, this node operating out of spec caused issues across the local mesh for displaying network status that never should have occured (it did not affect network routing).
While the AREDN protocol may eventually get to the point where we split up the namespace, but before AREDN would release such a feature it would go through intense testing to ensure it was done in a manner that did not corrupt the rest of the mesh.
This is a perfect example of even the smallest of item it can cause unplanned results, being outside specification it wasn't something that was necessarily routinely tested for because any device running in that position was (per the specs) NOT a proper AREDN node. We can not guarantee what other negative affects this device may be having on the network. Eventually if it does become an issue we may have to order it pulled from the network to protect the stability of the local emergency communications network. We put in a code fix to correct the problem, but ultimately it never should have been able to occur on a production network.
I understand greatly the desire of people to 'hack up' and 'experiment' but one shouldn't do that in production, do it in a network that will never be connected to an active AREDN mesh network so that you do not interfere with those running real EMCOMM networks providing real services.
maggie.ka9q.net is actually a 1U Supermicro Intel Atom running Debian Linux, but close enough; it's my home border router. And yes, it speaks olsrd.
Why? Because it can, and this is ham radio; do I need a better reason?
I do find it much easier to examine and work with internal network state on a general purpose, complete Linux system than in the restricted, special-purpose Linux running in my Ubiquiti node. For example, I found it convenient to have a local copy of /run/hosts_olsr on that system when I wrote a script to turn it into a proper DNS zone file so I wouldn't have to manually choose between mesh connectivity and external Internet connectivity. But that's just a personal preference.
I have many more nodes that can (and have) also run olsrd natively, including several Raspberry Pis, but I don't do that routinely; one currently meets my needs. But now that you mention it, I was puzzled by the fact that hierarchical DNS names of the form "pi.mchs.kg6equ.local.mesh" couldn't be entered into the code running on the Ubiquiti; I'm forced to use names of the form "kg6equ-mchs-pi" like those in the old, pre-DNS ARPA hosts.txt file last used in the late 1980s. Running olsrd on the host would seem to be the most expedient way to work around that bug, as the name is automatically propagated in routing messages without any manual configuration.
maggie.ka9q.net is a valid domain name, unlike ka9q-north.local.mesh, and it is handled correctly by the resolver in the AREDN node code. E.g., I was able to log into that Raspberry Pi at MCHS, set http_proxy=http://maggie.ka9q.net:3128/ and run apt-get. Worked just fine except for the poor performance due to the recurrent routing loops I discovered and mentioned recently.
One usually thanks, not excoriates, those who uncover bugs so they can get fixed before they cause any real trouble. If or when the network is ever called on to carry emergency traffic, I will be happy to defer to it.
By the way, maggie.ka9q.net runs some services that may be of interest to other mesh users. It's a Stratum 2 NTP server, peering locally with a Time Machines GPS/NTP receiver/server; this is open to everyone. I currently see it talking to 10.33.38.109, w6dmr-time.local.mesh.
It runs a Squid web proxy cache on port 3128. I'm currently restricting access to a few remote addresses but I'm happy to open access to others on request.
It runs Bit Torrent, serving a number of Linux and Raspberry Pi images.
And it's a TOR relay node, though this probably isn't of much interest to this group.
None of these services generate any traffic on the mesh unless spoken to.
Chill folks.. MY question was more related to my own personal MESH running ARDEN software and NOT the AREDN as a whole...
N8emr,
No offense taken. just be cautious, that's all.