Althea Development Update #81: Phone client Beta 0 and the many fixes of router Beta 11

It's been nearly a month since my last development update, sorry about that, it's been an incredibly busy time.

Without further delay, here is the Althea for Android app. You will need to use it with Beta 11 RC6 or later of the Althea router firmware. You can find a list of supported routers here.

The app is on xDai by default and I'll add a menu to change that at runtime when I get a chance. Or you can add it yourself here. Like everything Althea, the app is Open Source and Apache 2 licensed. It's missing some bells and whistles, but it works in a robust and secure way despite all of the roadblocks Android put in our way.

I believe I could dedicate a whole series of blog posts to why Android is a fun platform when it comes to writing network applications.

• On Motorola phones fe80 IPv6 addresses work to contact routers without the user requesting to 'stay connected' to the WiFi. But IPv4 does not
• On Samsung phones fe80 IPv6 addresses don't work at all, but you can always use the IPv4.
• On Android 8 and 9 the response to the boolean function is_any_local_address() is the opposite for the same IP.
• You're really better of comparing bits yourself to check what subnet an IP is in.
• But haha Java has no unsigned bytes, 192 is -64
• When trying to read the current WiFi SSID name, some phones return null when WiFi is disabled, others return <Unknown SSID>. Even better they will continue to return <Unknown SSID> even when connected if the network does not provide internet.
• The same function call on three different phones can be the key to everything working on phone A, do nothing on phone B, and crash the app on phone C. No - I'm not even talking about the documented API changes where they at least tell you this will happen.

And many other fun things I have blocked out in order to maintain my continued sanity. Compared to all of that, the router side changes were a breeze. The addition of a very small billing module and some minor modifications to the usual neighbor tunnels was all that really needed to happen.

What's new in Beta 11

• Support for Althea android phone clients
• Fixes for a bug where a node may run slowly and fail to validate all payments indefinitely
• Fixes a bug where clients could build up overpayment credit with exits without using it
• Fixes a bug where the clients would fail to bill correctly if the exit failed to respond
• Easy exit adding interfaces now in the dashboard
• Refactor of interfaces support to simplify WiFi port toggling
• Support for Multi-Collateral DAI
• Fixes for non-domain name manual peers
• Dependency update
• Usage history storage is now compressed for a 85% reduction in disk space usage
• Start migration to rust std futures

Overpayment Settling

When a router is paid too much by another router it puts the extra into a field called 'incoming payments' for later processing. This doesn't happen very often but I became interested what exactly was in this field while trying to clean up the debts storage files.

Routers have very limited disk space and I figured if we didn't owe anyone anything we could safely delete the entry. Like anything to do with billing, especially involving deleting data, I decided to inspect this assumption very carefully.

Incoming payments could typically get cleared out when a router is starting to get into a low balance state. Its overpayment credit is then applied by the other router before it's actually considered out of funds. Usually this is just a few cents at most. Probably due to some sort of crash or network disruption.

After more investigation I found that a small contingent of users who had always been very diligent in depositing funds into their router (never letting the balance even get close to low) were owed several dollars by their billing peers due to errors built up over the last year. Beta 11 contains a patch that will ensure these funds are applied right away so that it's no longer possible for them to bill up. These diligent users will see this as a few dollars of free service.

Overloaded Exit Fixes

Routers compute local bills for forwarded traffic, but for client traffic (download) they compute both their own bill and ask their exit server what it thinks the bill should be. This is important as it's possible for the exit to send more data than the client can see due to packet loss.

The Lagos exit in our Abuja deployment had been running rather slowly. Combined with the sudden addition of a dozen users this resulted in a short period where the exit was unable to respond to users requests to the exit. This effectively halted billing until the alarm was attended to and the exit repaired. While fixing this bug I couldn't help but think that the clients should have just gone ahead with their own estimation rather than doing nothing.

In Beta 11 routers will fall back to local billing only in the absence of an exit response to their settle-up request.