Set unique SSID and random channel for Wifi

[ssokol]

So I spent some time playing with different methods for setting unique SSIDs for each system. It turned out to be easiest to use the MAC address of eth0. I also added a small function to randomize the channel. I built it to run once on first boot, presuming that there is no /etc/hostapd/hostapd.conf file already in place.

To use this, you just need to build an image wherein you:

1) Remove the /etc/hostapd/hostapd.conf file 2) Replace /etc/init.d/hostapd with the attached file

When the system boots it will generate a hostapd.conf file with an SSID of "stratux-{MAC}" (without the ":"s between the octets). It will also select a random value between 1 and 11 for the channel number.

Ultimately it might be nice to have a UI option to manually set the SSID and channel values.

hostapd.zip

[ghost]

Neat.

I'd suggest updating the channel randomization to only use channel 1, 6, or 11.

WiFi in the 2.4 GHz band uses ~20 MHz of bandwidth, but the numbered channels are only 5 MHz apart. E.g., a strong signal on channel 3 will interfere with channels 1, 2, 3, 4, and 5.

Wiki

[duecedriver]

once you are in the air I doubt channel interference will be an issue. if you let the chip decide the channel it usually takes into account its perceived signal to noise ratios and picks the best one.. that could pick a better channel based on EMI noise in your cockpit ....

unless you have several routers on your plane...

[ssokol]

It looks like automatic channel selection has to be enabled when hostapd is compiled:

# Channel number (IEEE 802.11)
# (default: 0, i.e., not set)
# Please note that some drivers do not use this value from hostapd and the
# channel will need to be configured separately with iwconfig.
#
# If CONFIG_ACS build option is enabled, the channel can be selected
# automatically at run time by setting channel=acs_survey or channel=0, both of
# which will enable the ACS survey based algorithm.
channel=1

Not sure it it is on the build included with Stratux.

[bkwny]

I think it is reasonable to anticipate, especially as the future unfolds, multiple hotspots deployed in a single airplane. I even have this today. While I appreciate investigation into autonomous techniques I would like to suggest the most useful and simplest approach would be simply to enhance the web management interface to let the user select the channel number, SSID, encryption level, and password. Write those to /etc/hostapd/hostapd.conf and then restart. The challenge here is in maintaining customization across a Stratux uplevel. Right now the preferred uplevel path is to reimage the micro SD which means anything persistent will be lost. The same problem affects PPM but I think the web management interface already has a way to set that. Thanks for letting me express my view.

[bradanlane]

There is always a lot behind the "simplest approach". The system would need to be able to automatically recover and back out the change if the user somehow "oops'd" their settings. Once the bad info was entered and the system rebooted, there would be no way to reconnect to the WebUI. There are - of course - multiple other failure scenarios.

My question is "how do the commercial products solve this (if at all)?" We don't need to invent new solutions to old problems.

In this case, the solution may be to do nothing (or it may be a lot more complicated than that).

If I had this problem, my initial solution would be to always automate wifi channel selection and always append a unique-ish string to the SSID. No wifi security. No way for the user to make a mistake.

(just my 2¢ which also represents its potential value)

[bkwny]

Hi Brad, I always appreciate hearing all views.

I can tell you I have been developing commercial software for 29 years. In our products, when we try to do something automated like this, we inevitably have customers come to us and say, "Stop trying to be so smart. Instead, give me a way to accomplish the settings I need." So we end up encapsulating the configuration logic in some small place with the config data being an external. This approach further gives another vendor an opportunity to play in our ecosystem, either by providing a config dialog app or by providing his own automation to tweak the customization data according to whatever heuristics he imagines are important.

In the present case, what this might look like is that the Stratux web management screen would reduce to nothing more than a way to get the browser to upload to Stratux an XML-tagged file that specifies all of the customizations Stratux ought to apply. Stratux would read the tagged file, process the XML, and apply the requested customizations. At first there would be no need at all for any configuration application out on the browser side; the user's customization interface would be to use his favorite text editor to create or modify his XML-tagged customization file. A third party developer who wanted to polish up the Stratux user 's customization experience could build a small app that creates or modifies the XML-tagged config file in response to a GUI-based dialog it carries on with the user. The recovery scenario is to keep a backup of your micro SD card. This is the same recovery strategy as is used in larger systems; if you scrog your system you'd better have a backup.

Just my two cents also.

Brian

[bradanlane]

There are definitely lots of options. I was just speaking as a UX Desiner and User Researcher. Our challenge has often been to differentiate between "what a user asks for" vs "what a user wants". Typically they want it to "just work". What they "ask for" comes from frustrTion that it doesn't "just work" and then they take it upon themselves to propose a solution. I spent decades explaining to project engineers, sales, and executives the need to avoid assuming what the user says is actually what they want. :-)

From your example, we might add a REST interface that allows the whole config JSON to be sent to Stratux. It's very similar to config API we already have (which we use to make individual changes).

I agree with you that when the "end user" is a Vendor or 3rd party, what they want is often an interface.

[bkwny]

Hi Brad, thanks.

You're right about users. They sometimes don't know what they want. They just know what pain they're feeling.

About that JSON, yes, that seems to me to be on the right track. You'll probably also want a means for Stratux to build the config JSON and send it out, or perhaps more correctly stated, for some other system to ask Stratux to build the config JSON and send it. In such way some other system -- my laptop, for example -- could retrieve and store the Stratux config before a Stratux upgrade and then send the config back after the upgrade is complete. A Stratux web screen with "export configuration" and "import configuration" buttons would do the trick. IIRC my Linksys router has a similar feature.

The Stratux configuration consists of more than just application-relevant settings for gen_gdl90, such as PPM, or whether 1090 is configured on, or whether AHRS is configured on, or what have you. It consists also of certain important configuration settings for the underlying Linux, such as the SSID, channel number, and encryption settings from /etc/hostapd/hostapd.conf.

Thanks for listening, Brian

[cyoung]

Consolidating to #228.