On Tue, 6 Jul 2021, Paul Spooren wrote:
Date: Wed, 7 Jul 2021 09:48:59
From: Paul Spooren <m...@aparcar.org>
To: Enrico Mioso <mrkiko...@gmail.com>,
OpenWrt Development List <openwrt-devel@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.wiem...@ironai.com>
To: Luiz Angelo Daros de Luca <luizl...@gmail.com>,
OpenWrt Development List <openwrt-devel@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
luizl...@gmail.com
Em ter., 6 de jul. de 2021 às 21:43, Alberto Bursi
<bobafetthotm...@gmail.com> escreveu:
On 06/07/21 22:57, Michael Richardson wrote:
Alberto Bursi <bobafetthotm...@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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
