Release Candidate - Major changes and tests
 

The Release Candidate Process

 

The Release Candidate process starts with the release of nightly build 20261012-e3528941.

Subsequent nightly builds will be released when issues are fixed during this testing process and these will replace the current release candidate. The current release candidate is 20261012-e3528941. The process will continue until a build is considered stable. That will become the 4.26.X.0 release.

Please report all bugs using the usual process on GitHub. Functional bugs are the most important, cosmetic bugs are the least. You should not expect any major changes in functionality during this process. Please make sure you are running the latest release candidate before reporting an issue and please note the exact build number in your report.

If you are reporting a bug which appears to have been caused during the upgrade process, please make sure to include the version running before the upgrade was performed.

Before upgrading to an RC build, please backup your configuration. Apart from being a good idea, we might need this to aid debugging.
 

IPQ40xx Reboot Freeze 

In the 4.26.7.0 a Linux kernel bug prevents a small subset of Mikrotik IPQ40xx hardware from ever rebooting. A power-cycle is necessary for recovery. This only affects a few hardware instances. For example, the majority of Mikrotik hAP ac3s work correctly, a few do not.

• This RC fixes the bug. However, if you have this problem, after installing the RC you will still need to power cycle your device one last time as the bug is in the running code. After this the problem should be resolved.
• If you have hardware with this issue, please validate this fix.

Radios

 

If you are running a node as a Mesh Station connected to a Mesh PtMP, please make sure the Mesh PtMP end is running 4.26.7.0 or more preferably, migrated to the RC before upgrading yours.

Support for multiple radios that can each be enabled as Mesh. Mesh Station, Mesh PtP, Mesh PtMP or LAN hotspot.

• No support for multiple WAN Clients

Mesh Stations now allow multiple channels to be configured at once.

•   Try setting up two or three channels and make sure the radio connects to the appropriate PtMP node.
•   The main display will show “Searching” under the channel until one is selected.

• Some radios were having trouble scanning the large number of channels we allocate so we needed to reduce it by 4 to fit into a specific scan buffer size. We couldn't find anyone using these 4 on the worldmap.

40, 80 and 160 MHz bandwidths available again

• A change in OpenWRT limited bandwidth to 20 MHz max. Verify this cap has been removed.
• For wider channels, the loss of the 4 channels above may affect other selections (e.g. channel 60 on 40MHz can no longer be used as it includes channel 64).

Rework which channel/bandwidth combination can be selected on a radio

• Remove any regulatory restrictions on what channels can be selected, instead supporting whatever the hardware says it can support. Leaves regulatory enforcement to the operator rather than the software.
• Validate that a radio does support what it claims it can support.

AX Radio performance

• Intermittently poor performance on AX radios due to an immature driver. Your mileage may vary.

3GHz radio channel list should no longer include the wrong channels.

• Can someone with a 3GHz radio verify this?

The daemon which handles LAN Hotspot, WAN Client, Mesh Station, Mesh PtP and Mesh PtMP modes has been updated to a smaller build which excludes configurations we don’t use.

• Verify it still works as you’d expect for your setup.

 

Tunnels

Removal of the 172.X tunnel addresses. Tunnel addresses are IPV6 addresses autogenerated internally by the nodes and do not have to be shared with the tunnel configuration. These addresses were already “link-local” and not shared on the network.

• Tunnel endpoint addresses are therefore different. Babel doesn’t care about this so your tunnels will continue to operate after the upgrade. Babel may take a short while to resync after this change.
• Tunnels may appear white in the UI on non-upgraded nodes when connected to upgraded nodes. Tunnels will still be operating correctly and can be verified using traceroute. This is a UI inconsistency and not an operational one.
• Duplicate tunnel entries, one white one green, may be shown in the UI on non-upgraded nodes. This is a UI inconsistency and not an operational one.
• The tunnel server names and ports used remain the same.

Old tunnels should migrate to the new format.

• Verify tunnels migrate and work as expected.
• Verity tunnels still work and the MTU (Maximum Transmission Unit) is 1420. If you were previously running early nightly builds this may not happen automatically.If you have existing tunnels which require a lower MTU please change the value at both ends of the tunnel - they must match - and verify the tunnel works.

New tunnels now have an MTU of 1280 (the minimum)

• MTU field should be empty and use the default from the Advanced Options where it should be set to 1280.
• When new tunnels are created the node’s network is not restarted making adding tunnels faster.
• This feature was in 4.26.7.0 but sometimes it was still necessary to restart the network by hand.
• Make sure that’s not necessary.New tunnels with new MTU should work as expected.
• You can try changing the MTU but make sure to change it at both ends.

You cannot create new tunnels between RC and older nodes as the tunnel information is different.

 

XLinks

 

Removal of the IP address and mask associated with Xlink. Xlinks just require a VLAN now.

• Old xlink should migrate and remain operational
• XLink endpoint addresses are autogenerated. The old addresses were never distributed on the network.
• Check anything which might depend on the old IP addresses for xlink (e.g. devices which monitor the old endpoint address and power cycle nodes)
• Babel doesn’t care what the xlink endpoint addresses are but it may take a moment to resync after this change.

 

Networks

A node’s LAN IP network can be changed from the default.

• Verify new IPs work. The IP will be masked based on the LAN Type so expect the value to change slightly.

Disabling the LAN DHCP stops the LAN routes being advertised to other nodes

• We couldn't find anyone who used a LAN network on a node but not the DHCP server. This reduces the routes in the system which helps to keep things more efficient.

A node’s WAN network, if available, is now shared with other nodes connected by the local DtD network (DtD to WAN).

• This option is on by default. Is that good?
• Traceroute from another (also RC’ed) node to make sure routing works correctly.

A node’s firewall and NAT can be disabled.

• Tricky to test without setting up a router correctly to forward traffic to the non-firewall node.

Babel can now run on the LAN network, which can be useful if you want to run Babel across a link using non-AREDN radios which are connected to your LAN.

• Is this feature useful or just confusing?

• Tricky to test unless your node is an obvious path to the Internet for traffic which isn’t from your other local nodes.
• This shouldn’t affect traffic from your local nodes if they are using the DtD to WAN feature.
• Internet traffic which previously went through this node should be rerouted around it.

WAN MTU can be changed

• Verify WAN MTU can be reduced. Necessary for some ISPs. Randomly changing your MTU when your ISP doesn’t require it can cause problems - test with care.

A new WAN Monitor service checks if your WAN network is up and usable. If not it withdraws any WAN access you advertise to the Mesh.

• Unplugging the WAN network to a node should be noticed after a few minutes. Check that it’s no longer being used by other nodes for WAN access.

Changes to how Ethernet Port configuration is stored

• The network should operate as before after the migration; especially for non-default network configurations.
• Old configuration should migrate to the new format successfully.
• Changing the Ports configuration should work correctly.

Babel route readiness changes

• Route changes, especially when other nodes reboot, should be more responsive. Difficult to quantify and test.

 

UI

Main UI - menus will now close when you click away from them.Make sure menus don’t close incorrectly making them unusable.

Mesh UI - When logged in, the mesh page will show ping, trace and iperf tools (on hover) for each mesh node listed.

• Clicking these items should open the appropriate tool with source and destination fields prefilled.

Tools

Tracerouting via RC-running nodes should show the correct node name rather than a largely useless IP address.

Wifi Signal and Scan tools works across all radios

• Check they work in all the various configurations, especially hardware with multiple radios at both the station and AP ends.

Wifi Signal tools should be available in PtP and PtMP modes

• Will just show the connected stations

AREDNLink

Old protocol version has been deprecated

• V0.0.1 of the protocol hasn’t been used in a long time. Disabling its support shouldn’t affect things. Good to make sure the number of hosts is still the same.

 

Memory

• Available RAM is a better gauge of how much ram is available for use in the system because it includes RAM in caches which can be quickly reused when needed.

• Note that we previously showed Free RAM so comparison is difficult

• Both the above changes should see less chance of OOM (Out Of Memory) errors in logs, especially on older devices.