The AREDN team has pushed a major upgrade into the nightly builds, available now. This includes the upgrade to Openwrt 19.07.0 recently released with numerous fixes and improvements.
In this AREDN build there are a few models shifted to a new kernel architecture using what is called "device tree" definitions. This basically means that the hardware the linux OS runs on is defined in a data structure. In the past it was written in 'C' and compiled into the kernel. Now, it's essentially a data table that can be independently shared, and possibly provide by the manufacture in the future.
This new architecture is referred to as "ath79" and the old architecture, "ar71xx", will phase out over time as all devices are converted. We call these 'targets', coming from the context of building the target images. The downloads directory now has folders for the respective target images.
Here is what you need to know to start using this nightly and future builds:
1) 32M RAM devices continue to be at the limit of available memory. This means that doing a sysupgrade to load new firmware may take many tries to succeed. Don't use these devices at hard to reach tower sites! The sysupgrade process needs close to 10M of memory to succeed. Tips to get it to work:
In this AREDN build there are a few models shifted to a new kernel architecture using what is called "device tree" definitions. This basically means that the hardware the linux OS runs on is defined in a data structure. In the past it was written in 'C' and compiled into the kernel. Now, it's essentially a data table that can be independently shared, and possibly provide by the manufacture in the future.
This new architecture is referred to as "ath79" and the old architecture, "ar71xx", will phase out over time as all devices are converted. We call these 'targets', coming from the context of building the target images. The downloads directory now has folders for the respective target images.
Here is what you need to know to start using this nightly and future builds:
1) 32M RAM devices continue to be at the limit of available memory. This means that doing a sysupgrade to load new firmware may take many tries to succeed. Don't use these devices at hard to reach tower sites! The sysupgrade process needs close to 10M of memory to succeed. Tips to get it to work:
i) fresh reboot and very quickly do the upgrade (recommended for all devices, particular if at a tower site)
ii) disable mesh RF and any use of wireless, reboot before sysupgrade
iii) disable or uninstall any packages that are running, e.g. meshchat
iv) as an almost last resort, scp the .bin image to /tmp on the node and from the command line type "sysupgrade -n <.bin filename>" (does not save settings)
v) as the last resort, tftp to load the factory image (does not save settings)
ii) disable mesh RF and any use of wireless, reboot before sysupgrade
iii) disable or uninstall any packages that are running, e.g. meshchat
iv) as an almost last resort, scp the .bin image to /tmp on the node and from the command line type "sysupgrade -n <.bin filename>" (does not save settings)
v) as the last resort, tftp to load the factory image (does not save settings)
2) Do not count on being able to sysupgrade to return back to older AREDN images. It might work, it might not based on if model names were cleaned up and changed moving to ath79. The older images may not be recognized on the newer target images.
3) To know what image to use, pay close attention to the table located here (scroll down): https://github.com/aredn/aredn_ar71xx .
4) please report any bugs encountered. At this time, there are no known and new issues.
Have fun!
Joe AE6XE
3) To know what image to use, pay close attention to the table located here (scroll down): https://github.com/aredn/aredn_ar71xx .
4) please report any bugs encountered. At this time, there are no known and new issues.
Have fun!
Joe AE6XE
Also note that the link in Nightly build page points to the AR71XX directories, so you sort of have to figure out how to get to the ath79 directory.
Joe AE6XE
Hope this helps ferret out the problem.
Jim, thanks for the test and confirmation of what is working and not working.
To summarize for everyone of the situation -- this is not necessary a bug that will be fixed or action taken. Let me explain... A change was made to enable tunnels to install on 8M Flash devices. This includes the 64M RAM rockets, 32M RAM airRouters, 32M RAM nanostations, and more. To free up flash, we removed the use of and dependency to a ~935k package being installed with the tunnel, which ended up affecting the protocols in use. Unless a workaround is found, we are faced with the lessor of 2 evils:
1) Not being able to install tunnel capability on 8M Flash devices; or
2) Not being able to connect tunnels between Nightly build 1300+ and 1300- images
The question before us is if #2 is the lessor of the evils? This means that both sides of the tunnel needs to upgrade to nightly 1300+ at the same time.
Joe AE6XE
This may seem like a tough decision for some. But remember, we will encounter a growing number of compromises going forward... particularly with older generational equipment. The choices Joe presents are really one and the same --- if you have an older, 8M Flash device, then the only way to tunnel with it is to do so with a pre nightly-1300 release on both ends.
Do I have this right?
Does this mean that the new AREDN move within the progression of Nightly Builds to the new OpenWrt now takes up more space, such that the older design tunnel will no longer fit in remaining space on any legacy gear when used with it? And, therefore you stripped out some of the unnecesaary encryption to save space so that it could, but now the "new" tunnel code is no longer backward compatible within AREDN v3?
If this is the case, would it be possible to step back a moment and generate a stable 3.20.01 release based on Build #1234 for those of us might feel it imperative to keep our current Control Operator tunnels at multiple locations, etc.
And then, either way, are we now basically at v4 vis-a-vis tunnels?
Thanks for all your efforts on all of this,
- Don - AA7AU
That would make a lot of sense if Option #1 is the route taken going forward. There have been a lot of improvements in the nightly builds since 3.19.3.0 came out. It would not make a lot of sense to lock people into firmware that old.
Joe AE6XE
Cutting off older equipment is a reality in many fields. Eventually support for older stuff goes away.. I run a tunnel on a Rocket M5 so I would be affected by Joe's option #1. However I still think that is the preferred option. For me, that would mean I would likely add a hAP solely as a tunnel device at my office and leave the two Rockets to run RF links. With option #1, people could still use older firmware (up to nightly 1234) if they need to run tunnels on old hardware. And of course this issue is only an issue if you need to run tunnels. The older devices can still be used for RF links.
Option #2 would create a problem for several years as we all know that there are many users out there that are using very old firmware - and will likely continue to do so.
1) these older firmware versions present instabability on the network. For example, vulnerable to OLSR locking up or crashing, because they don't have the fix, and routing through the node is broken. These devices are also vulnerable or at risk. The next embedded wannacry like virus will enter our mesh network given the growth we have had. It's "when", not "if". These nodes have more known vulnerabilities contributing to the risk. The rest of the mesh users who do keep current will not be happy for our networks to be unstable or at unnecessary risk because someone hasn't upgraded. In today's world, staying current is network and computer good-hygine.
2) the combination of old firmware versions AND tunnel will be relatively small. We should be able to pull these metrics out of the SoCal published data.
Joe AE6XE
OK, thanks Joe. Good luck in the investigations. Nonetheless, as I think of it more now, I ask again: would it be possible to step back a moment and generate a stable 3.20.01 release based on Build #1234 please? That might enpurage some of those hold back to get current etc etc etc - even if it doesn't have the last OpenWrt fixes in it. I can think of any number of good reasons to get a stable release out now before the great leap forward. Let's get those who worry about being on the Bleeding Edge up to a more current status.
Please?
TIA,
- Don - AA7AU
Since work is continuing on the "new" tunnel code, would there be any possiblity of making the AREDN-installed vtun package port agile so that we're not locked into the hard-coded 5525 port requirement?
TIA,
- Don - AA7AU
in /etc/config/vtun
locate the "config options" section
add "option port '5568'. // or whatever port that you want to serve
Must be done on server and client sides
Please note all nightly build versions-images still have issues with the hAP ac lite consuming too much RAM and running out -- sluggish, etc. This will be addressed soon. Turn off the 5Ghz radio if experiencing any issues.
Joe AE6XE
Please continue to use the nightly builds! There is only 1 known issue to address -- affects AR750 and hAP ac lite -- using 5GHz radio consumes too much memory and the device can become sluggish or even crash/reboot. A fix for this is known, just a question of getting the right balance of not reducing RAM usage too much that we might sacrifice or degrade performance of 5GHz data thoughput.
Joe AE6XE
Does the memory issue exist when using the 5 ghz radio as a wifi lan AP or only when using it for mesh RF?
Many thanks,
julie
ac0wn
Any use of the 5GHz radio will consume RAM and risk of low memory symptoms. (Since it is 802.11ac, not an option to use for mesh RF.) Using the 2GHz for Mesh RF, or any other purpose, has no impact.
I thought this fix was in AREDN's upgrade to openwrt 19.07.0, but it missed it by a few days. I have working images for 19.07.1 and confirmed we have the fix, however openwrt plans to release 19.07.2 this week, so holding a few days to pull through and push into the AREDN nightly.
Joe AE6XE
OK .. that makes complete sense and my apologies for mistaking the 5 ghz capabilities. I'll wait for 19.07.2 to try the nightly build. :)
Kindest,
julie
ac0wn