Althea Development Update #51: Easier debugging in the field
Here’s our Alpha 5 release
What’s New in Alpha 5
- the exits endpoint, curl or visit 192.168.10.1:4877/exits to see detailed network status for easy debugging
- improvements to the update system to better track what’s going on
- some infrastructure for payments
- other bugfixes and stability improvements
The big feature this sprint was a proper refactor of the exit sign up workflow to actually make sense and properly accommodate rare edgecases.
There are many cases where we want to change x or y property and we need a reliable way for user devices to understand that things have been changed without disconnecting them all from the internet until they perform a manual reset.
Now instead of trying to naively sign up to every available exit at once the device will wait for the users go-ahead and provide a reset button for when things go wrong.
Sadly this didn’t make the cut for Alpha 5 as the ui components are not finished and tested.
What did make the cut for Alpha 5 are several bugfixes and a new endpoint the exits endpoint automatically checks all of the mesh properties we would usually check by hand to debug and provides a very easy way to identify problems. In the future it will be integrated into the interface so that users get a short summary of what may be causing their connection problems.
{
“nickname”: “us_west”,
“exit_settings”: {
“id”: {
“eth_address”: “0x0101010101010101010101010101010101010101”,
“mesh_ip”: “fd96::1337:e2f”,
“wg_public_key”: “1kKSpzdhI4kfqeMqch9I1bXqOUXeKN7EQBecVzW60ys=”
},
“message”: “Althea production US exist”,
“registration_port”: 4875,
“state”: “Registered”
}
“is_selected”: true,
“have_route”: true,
“is_reachable”: true,
“is_tunnel_working”: true,
},
Likewise the groundwork for payments is being set out. We hope to have both the exit signup refactor and the first integration of our payments daemon gauc_rs ready for Alpha 6.
In this iteration guac will complete the payments workflow without actually sending said payments off to a full client to be published on the testnet. It’s been an interesting exercise really working out the payment protocol and making sure everything is solid. No huge inventions here, just chipping away at making a solid implementation.
We’re aiming for early August as our target date for having testnet payments online and functioning.
When it comes to device support I’ve had a very confusing week, I added the Zyxel Armor2 to our supported devices list with high hopes of replacing the Turris Omnia at the 300+ mbps embedded range. Only for it to create a new performance per dollar record in the wrong direction. At $160 for a pitiful 60mbps.
What went wrong? The Omnia runs pretty stock Cortex A9, the Zyxel runs a Krait, also an armv7 core which a higher IPC and more processing bells and whistles.
Digging into the OpenWRT port (my primary suspect) the cpu governor is fine and so is the NEON implementation. WireGuard successfully compiles and runs using vector instructions.
The only place the Omnia wins the spec war is it’s DDR3 vs DDR3L memory in the Zyxel. I don’t really think that’s the key component here though, memory bandwidth should be an order of magnitude higher than networking bandwidth.
My primary suspect at the moment is some processor specific patch that was not unstreamed by Zyxel and somehow not captured in the port.
I’ve decided to stop digging deeper on this device and instead look at the GL-B1300, which also has a pretty good spec sheet on paper and ships with a similar processor.
If it becomes clear that the Zyxel is a part of a larger pattern of substandard performance rather than the exception I’ll start digging into kernel performance profiling and really get to the bottom of the issue.
Our head of outreach Deborah will be in Puerto Rico doing a workshop on Althea at the Meshing With Data hackaton later this week and I will be in Toronto for the State of Our Networks (SOON) conference next month. Hopefully we can get good recordings of both presentations to share with you all.