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
