Enabling Wi-Fi on First boot

[Vincent Wiemann]

Hi,

this thread seams to be a follow-up of:
https://github.com/openwrt/openwrt/pull/2408

The end result was that we could let the status LED signal a randomly
generated PSK in morse code. There are several apps like
"Morse code reader" for Android which can use a mobile phone's
camera to decode morse code.

I was working on using the HTML5 camera API with JavaScript image
feature detection to create a platform independent solution.
Unfortunately the standard feature detection models are not very good
at it. So it needs some work.

Best,

Vincent Wiemann

On 7/7/21 3:26 AM, Luiz Angelo Daros de Luca wrote:
> Hello,
> 
> I would enable wifi during the first boot. Maybe we could disable it
> after a couple of minutes if nothing happens.
> I would not use an unprotected network, like OpenWrt, as someone could
> sniff the new password (we also have no https://).
> But an OpenWrt/OpenWrt could work.
> 
> If you have a working OpenWrt and want to do a clean setup through
> wifi, one solution would be to apply a simple "enable wifi"
> configuration
> together with the new image. Luci does not allow but CLI sysupgrade
> does have the option "-f conf.tgz". OpenWrt could provide a standard
> enable-wifi.tgz and a way to flash a firmware with configuration from LuCI.
> 
> Some devices block the user from using the router to access the
> internet until some basic things are set, like admin and wifi
> password.
> They normally redirect all http traffic to the router. It would be
> nice to have something similar to force the user to set a password.
> However, it will never get merged if that setup applies to everything
> as it would break many provisioning. It might be overkill but maybe it
> looks like a new image flavor...
> 
> My 2 cents,
> 
> ---
>       Luiz Angelo Daros de Luca
>              luizluca at gmail.com
> 
> Em ter., 6 de jul. de 2021 às 21:43, Alberto Bursi
> <bobafetthotmail at gmail.com> escreveu:
>>
>>
>>
>> On 06/07/21 22:57, Michael Richardson wrote:
>>>
>>> Alberto Bursi <bobafetthotmail at gmail.com> wrote:
>>>       > "unique" per-device passwords like most vendors are doing are low security
>>>       > and relatively easy to brute force once someone has disassembled the firmware
>>>       > and learned the algorithm used to generate them. They rely on obscurity for
>>>       > most of their security, which is not really a thing for an open source
>>>       > project.
>>>
>>> If they devices are shipped with such derivable passwords, then they violate
>>> the California (now US) regulations, and also the come UK ones.
>>> We can do better, and we are doing better.
>>
>> Yeah, like most devices are also paying lip service to the other US laws
>> about not allowing "custom firmware" on the device because that could
>> make it go against radio power/emission regulations.
>> One thing is the law, one thing is actually enforcing it besides asking
>> nicely to the OEMs and trusting their "boy scout's word" that it's all
>> secure.
>>
>>>
>>>       > They are also completely useless for DYI users that are just flashing a
>>>       > couple devices.
>>>       > With much less effort you can just ship a pre-made wifi config file with your
>>>       > own settings and passwords, and that's what many are already doing.
>>>
>>> Many devices have USB ports, and I'd suggest having a standard names .json
>>> file that can be fed into uci in some way.  I think that this solves a lot
>>> problems.  Have to make sure that vfat support is included in the base image
>>> because... users.
>>
>> And the idea mill keeps going. Not specifically just you but I've seen
>> these discussions run in circles so many times at this point that I'm a
>> bit jaded.
>> Imho this proposal does open more problems than it solves, and it is
>> non-trivial to implement, and it adds bloat in firmware images so people
>> will be unhappy.
>> And it is not universal, a lot of devices don't have USB ports.
>>
>>
>>
>> The best idea I've seen so far is to just add the feature to add a
>> custom wifi config (possibly more than just wifi) in the image builder
>> website frontend framework thing made by Spooren (aparcar on github)
>> https://github.com/aparcar/asu
>> So that the user can generate an image with custom config from a point
>> and click interface, and when the device does the first boot it will
>> come up with an already configured wifi and network and whatnot.
>>
>> This avoids bloating images, does not add any new attack vectors in the
>> device firmware, keeps the wifi security freaks happy as no wifi is
>> enabled by default, while still being friendly to the end user.
>>
>> The only thing that could go wrong is that the user screws up the config
>> and locks himself out, device reset will not change the configs he
>> integrated, but I think Fallback mode can to be modified to always use
>> "openwrt default configs (i.e. 192.168.1.1 IP and device default ports
>> for LAN/WAN, no wifi enabled)" instead of whatever the user has shipped.
>> So that if the user does something wrong they can still get into
>> fallback mode and then reflash a new firmware with the right configs.
>>
>> Not saying this is easier to develop or faster or whatever.
>> Just that imho this would be the optimal "solution" that satisfies the
>> most types of userbase.
>>
>> -Alberto
>>
>>