Enabling Wi-Fi on First boot
Enrico Mioso
mrkiko.rs at gmail.com
Wed Jul 7 01:28:06 PDT 2021
On Tue, 6 Jul 2021, Paul Spooren wrote:
> Date: Wed, 7 Jul 2021 09:48:59
> From: Paul Spooren <mail at aparcar.org>
> To: Enrico Mioso <mrkiko.rs at gmail.com>,
> OpenWrt Development List <openwrt-devel at lists.openwrt.org>
> Subject: Re: Enabling Wi-Fi on First boot
>
>
>
> On 7/6/21 8:42 PM, Enrico Mioso wrote:
> 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.
>
> Hi Enrico,
>
> I didn't catch up on all the email nor all 109 (?) comments of the previous pull request, but would a config issue in the build system which enabled the WiFi be of help? I could look into implementing something like this since I'd like
> to improve the accessibility of OpenWrt.
>
YES!!!!!!! This would be extremely helpful and nice!
I am extremely grateful for this - accessibility is one of the greates features of OpenWRt for me! :)
> Another option would be to add a package called enable-wifi to packages.git which would automatically enable all WiFis if installed.
>
Yes!!!!! This would be very very helpful.
>
> 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
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
>
More information about the openwrt-devel
mailing list