Enabling Wi-Fi on First boot

[Luiz Angelo Daros de Luca]

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