Enabling Wi-Fi on First boot

Tue Jul 6 23:42:51 PDT 2021

Hello all!

First of all, I'm blind and so I don't daily interact with LEDs. My use-case was to be able to set up an openwrt entirely from Wi-Fi with no physical access.
I wasn't looking for a production-ready feature, but as I said, something the user can enable when building his own image at its own risk.
Thanks guys.

On Wed, 7 Jul 2021, Vincent Wiemann wrote:

> Date: Wed, 7 Jul 2021 06:25:29
> From: Vincent Wiemann <vincent.wiemann at ironai.com>
> To: Luiz Angelo Daros de Luca <luizluca at gmail.com>,
>     OpenWrt Development List <openwrt-devel at lists.openwrt.org>
> Subject: Re: Enabling Wi-Fi on First boot
> 
> 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
>>>
>>>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>