Pairing required. Updates under the hood

First — let me wish you all the best in 2020! Hope it will be wonderfull year for all of us! After the holidays I am back with a post about the latest development. It is now almost a standard that it will be mostly “what’s going on under the hood” as the feature-level changes are already frozen.

Pairing required

So the most prominent under the hood feature you will start to see in this week (hopefully) is the requirement for pairing your access points with the dashboard. Until now, there was no key exchange in place (as I wrote the day the beta was introduced) but now as the system gets traction, it is unsustainable and for a production it is even unthinkable :-) The idea how it should work is nothing new, at it was relativelly easy to develop, as the console counted with this feature from day one: So if your device is newly added to the console and was not there before, it just pairs automatically, no action is required from your side. But whenever the device is added and paired for the first time, any change in the keys provided by the connecting device fires up a pairing requirement to prevent tampering your security. You should be aware of any reasonable pairing request and should be very suspective, if there is a pairing request with no apparent reason.

Pairing request from a manually flashed device

So the question is — what is reasonable pairing request? Typically, it is a firmware upgrade done by hand — if you flash your devices manually, it will lost all the configuration, including the pairing keys and those have to be generated from scratch. This is done by the device automatically and (as we do not have the old ones) it breaks the trust between the device and console. To regain the trust, manual intervention from the console user is required — performed by pushing that “Pair” button.

One of the reasons it took so long, if you are interested, was that some older access points (read OM2P) are tight with the flash space and due to this their configuration was not retained across the reboots. I will not discuss the details, if you are interested, google jffs2 overlay partition too small. Until now it did not bother as the configuration was automatically restored from console immdiatelly after start up but now, it kicked back. BTW as always, when one thinks “eh, good enough” :-)

Just for your information, those devices have only 16MB flash (MB, not GB) and considering the fact that they hold the firmware image twice (one running and one backup copy), and further considering the fact that the kernel itself accounts almost 2 megs each, we are playing with the linux userspace accounting for some 6 megs to play with.

The main software component which connects to the console and does all the configuration on the device is written in go, which certainly is not the best language for embedded devices but it allows me to develop quite rapidly, with no memory leaks or buffer overflow headaches which would inevitably arose when using traditional C. It was the tradeoff I deliberately took which allowed me to focus only on what’s important and not playing with pointers. And just another thing — did I told you that I know go much better than C? I am not a professional programmer, I am just the poor IT guy with some programming background… So I have spent most of the pre-Christmas time handling the tight space and give myself some breathing room, result so far — we are not constrained for a while. Which is a great news :-)

Running OpenWrt 19.07 RC2

Another important milestone is that our “edge” firmware already makes use of the OpenWrt 19.07 RC2, which is at the time being the latest development on the operating system Altiwi runs. And if anything bad won’t happen, it will find the way to your devices in this week too.

We strongly believe that it is at utmost importance to keep the devices up-to-date with the latest possible firmwares. And the latest possible firmwares does not mean that the vendor’s firmware was built yesterday but on top of the 4 years old OS. Most devices I touched in the last year had the kernel and the userspace built in 2015 or even older! This clearly illustrates the level of engineering effort they put into their products. And it accounts even for some of the “new” product lines! Simply take the OS and SDK you know well, do not touch anything that might break, do some CSS styling on the web interface and put it on the market! There is nobody who would look inside, isn’t it?

Linux 4.14.162 stands for OpenWrt 19.07, the older 18.06 uses the 4.14.95 kernel

On the other side, we changed the underlying system three times from the start of the development, started with LEDE 17.xx, moved to OpenWrt 18.06 and now we are running the latest 19.07. Nice.

This last change forced me to do another invisible thing — we have now quite robust dockerized build system in place, which allows us to switch the underlying OpenWrt releases quite easily and allows us to build whe whole new system with all the dependencies, including our software, from scratch (sources) within less than an hour. It has still some rough edges but it allows us to keep up with the rest of the world. The world is racing forward and security bugs are arising every day, remeber it.

Features development

In fact the only one I feel we should do is the captive portal. And honestly, even considering dropping it off for a release — as there is not that much people using it. I would be glad if you’d drop me a note on how importan it is for you. At the beginning I considered it quite an important part of the puzzle, and the prototype was among the first features we have developed but it look to me that (relatively) small number of testers even touched it. Did I told you that we watch the logs closely? :-)

Apart of that, we consider the console as feature completed, so it is time to ask which other features are important to you? Here is my list:

• WiFi scheduling — small but for some of you important feature.
• Facebook WiFi alternative — FB discontinued this feature for new vendors in favor some kind of FB app, maybe it might evolve into general social login. Question is — isn’t the demand for this as weak as for the captive portal?
• Internal RADIUS to be able to provide WPA Enterprice without the hassle of maintaining own RADIUS server — this is my personal favorite :-)
• Site survey tool for WiFi planning and deployment
• Application reporting (L7 inspection)
• Presence reporting
• CLI interface— I’d personally love to have something like altiwi reboot network YourNameHere or altiwi upgrade network --all -v 0.0.210 from my console :-)

If there is anything else you are missing, feel free to contact me at rob.h(a)altiwi.com. Thank you for your continuing support!