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 escreveu: On 06/07/21 22:57, Michael Richardson wrote: Alberto Bursi 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.
Re: Enabling Wi-Fi on First boot
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 escreveu: > > > > On 06/07/21 22:57, Michael Richardson wrote: > > > > Alberto Bursi 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
Re: Enabling Wi-Fi on First boot
On 06/07/21 22:57, Michael Richardson wrote: Alberto Bursi 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
Re: Enabling Wi-Fi on First boot
What about a built-in one-time only password, that only permits one time use and the customer must change ssid/password after first time access the wifi network? That first ssid/password could well be openwrt/openwrt in this case. Shaw ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
Alberto Bursi 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. > 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. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
On 06/07/21 21:06, Enrico Mioso wrote: Hello all!! What I was thinking actually was an option I could enable at build-time (kinda preinit option), at my own risk, when building images. From a technical standpoint, will an uci default work in all cases? Thanks a lot for your ideas guys. Enrico It should. Each device's "default" wifi config is not secure (no password, open wifi) and not optimized for high bandwith streams, VOIP and whatnot, but it should always bring up a wifi you can connect to. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
On 06/07/21 19:01, Henrique de Moraes Holschuh wrote: What would work is to reuse the vendor-provided password that is already in the label and somewhere in FLASH, if you could always know where it is in FLASH (you don't). And some models don't have it. That's a lot of work to get a very low security password. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
On 06/07/21 16:26, Henrique de Moraes Holschuh wrote: However, it is *not* a simple matter to just "enable wireless" at first boot in OpenWrt (due to a "default password" issue), except maybe in a home-and-enthusiast setting. You cannot just do it for a device (or firmware) you're going to deliver to third parties: it is *unsafe*, and extremely strongly discouraged. So, to safely and responsibly enable wireless by default in a device (or firmware) you're delivering to a third-party, you need that "per-unit unique wireless password" per device thing most vendors are doing. Every. Single. Discussion degenerates into a "how could we make it safe" party where wilder and wilder ideas are thrown around until everyone leaves. "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. 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. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
Hello all!! What I was thinking actually was an option I could enable at build-time (kinda preinit option), at my own risk, when building images. From a technical standpoint, will an uci default work in all cases? Thanks a lot for your ideas guys. Enrico On Tue, 6 Jul 2021, Eric Luehrsen wrote: Date: Tue, 6 Jul 2021 19:29:19 From: Eric Luehrsen To: openwrt-devel@lists.openwrt.org Subject: Re: Enabling Wi-Fi on First boot On Tue, Jul 6, 2021, 1:06 PM Henrique de Moraes Holschuh mailto:henri...@nic.br>> wrote: On 06/07/2021 12:05, Nishant Sharma wrote: > On 06/07/21 7:56 pm, Henrique de Moraes Holschuh wrote: >> So, to safely and responsibly enable wireless by default in a device (or >> firmware) you're delivering to a third-party, you need that "per-unit >> unique wireless password" per device thing most vendors are doing. >> >> [2] not really: openwrt sysugrade *does not help* in that there is no >> way to add variable information to an already *finished* image file, to >> be used on first-boot only, and which would *survive a factory reset*. >> > > How about a first-boot script that enables the Wi-Fi if it is disabled > and then sets the password (if not already set) using the first MAC > address it finds on the device? MACs are not a secret. It is absolutely trivial to know them: they're in just about every WiFi (and ethernet) frame. Same goes for anything that is derived *just* from the MAC address. And anyone that is going to automatically scan/exploit for that, will also use MAC-1, MAC+1, and other common variants. What would work is to reuse the vendor-provided password that is already in the label and somewhere in FLASH, if you could always know where it is in FLASH (you don't). And some models don't have it. One also don't know the unit's MAC address beforehand, so any scheme that depends on that doesn't work (because you'd need that MAC address to print the label or generate the PDF). In fact, this precludes the "generate secret at the device at 1st boot" too. You could ask the user, but that isn't safe either: if she gets it wrong (or openwrt isn't correct about what MAC is in the printed label of that exact product version) you now have a device she can't access because the passwords won't match and it would require an ethernet cable to bypass and reset. Some models are more obvious about device unique default password storage than others. So like on my other reply if it is obvious then use it and turn on wifi. For those with wifi-on-first support, make it a check box in the hardware support table. Then small business using openwrt know what options might meet their deployment needs. - Eric ___ 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
Re: Enabling Wi-Fi on First boot
On 06/07/2021 14:29, Eric Luehrsen wrote:
> On Tue, Jul 6, 2021, 1:06 PM Henrique de Moraes Holschuh
> mailto:henri...@nic.br>> wrote:
>
> On 06/07/2021 12:05, Nishant Sharma wrote:
> > On 06/07/21 7:56 pm, Henrique de Moraes Holschuh wrote:
> >> So, to safely and responsibly enable wireless by default in a
> device (or
> >> firmware) you're delivering to a third-party, you need that
> "per-unit
> >> unique wireless password" per device thing most vendors are
doing.
> >>
> >> [2] not really: openwrt sysugrade *does not help* in that there
> is no
> >> way to add variable information to an already *finished* image
> file, to
> >> be used on first-boot only, and which would *survive a factory
> reset*.
> >>
> >
> > How about a first-boot script that enables the Wi-Fi if it is
> disabled
> > and then sets the password (if not already set) using the
first MAC
> > address it finds on the device?
>
> MACs are not a secret. It is absolutely trivial to know them:
they're
> in just about every WiFi (and ethernet) frame. Same goes for
anything
> that is derived *just* from the MAC address. And anyone that is
going
> to automatically scan/exploit for that, will also use MAC-1,
MAC+1, and
> other common variants.
>
> What would work is to reuse the vendor-provided password that is
> already
> in the label and somewhere in FLASH, if you could always know
where it
> is in FLASH (you don't). And some models don't have it.
>
> One also don't know the unit's MAC address beforehand, so any scheme
> that depends on that doesn't work (because you'd need that MAC
address
> to print the label or generate the PDF). In fact, this precludes
the
> "generate secret at the device at 1st boot" too.
>
> You could ask the user, but that isn't safe either: if she gets it
> wrong
> (or openwrt isn't correct about what MAC is in the printed label of
> that
> exact product version) you now have a device she can't access
because
> the passwords won't match and it would require an ethernet cable to
> bypass and reset.
Some models are more obvious about device unique default password
storage than others. So like on my other reply if it is obvious then use
it and turn on wifi. For those with wifi-on-first support, make it a
check box in the hardware support table. Then small business using
openwrt know what options might meet their deployment needs.
We're barely there with the metadata (in openwrt) to actually know what
would be the label's MAC address.
This ("use the vendor password") is going to be highly device-specific
for a LONG time, and unless it is actually something people start paying
attention when adding new models, it won't get better with time either
(unlike the MAC one, which is getting better coverage as new models get
added).
I'd prefer if we could have an option to do it generically in OpenWRT
itself. And not just for passwords, if you're going to do it, do it in
a way that anything UCI can potentially benefit, IMHO...
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
I will address the other points in a separate reply. On 06/07/2021 13:05, Michael Richardson wrote: Henrique de Moraes Holschuh wrote: > [1] The reports are public, and available at https://ceptro.br. Disclaimer: I > work for a different division of the same NGO that produced those reports. Thanks for this pointer... but can you give us the whole URL for those of us who don't speak Portugese (and google translate doesn't seem to have helped). Sorry, the reports go in https://cetic.br, I mistakenly wrote the URL for the special projects engineering center (where I work). There are summaries of the reports in English: https://cetic.br/en/publicacoes/indice/pesquisas/ The one I quoted is this: https://cetic.br/en/publicacao/pesquisa-sobre-o-uso-das-tecnologias-de-informacao-e-comunicacao-nos-domicilios-brasileiros-tic-domicilios-2019/ I am not sure how well that PDF report will survive Google translate... On that report, page 69, the graph shows cellphones in 99% of the surveyed households, but less than 42% of them have computers (of any type: laptop or desktop). I personally expect things changed somewhat due to the pandemic as some households now have a "work laptop", but I don't expect that to change the whole picture drastically. -- Henrique de Moraes Holschuh Analista de Projetos Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537 R.:4023 INOC 22548*625 www.nic.br ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
> > On Tue, Jul 6, 2021, 1:06 PM Henrique de Moraes Holschuh > mailto:henri...@nic.br>> wrote: > > On 06/07/2021 12:05, Nishant Sharma wrote: > > On 06/07/21 7:56 pm, Henrique de Moraes Holschuh wrote: > >> So, to safely and responsibly enable wireless by default in a > device (or > >> firmware) you're delivering to a third-party, you need that > "per-unit > >> unique wireless password" per device thing most vendors are doing. > >> > >> [2] not really: openwrt sysugrade *does not help* in that there > is no > >> way to add variable information to an already *finished* image > file, to > >> be used on first-boot only, and which would *survive a factory > reset*. > >> > > > > How about a first-boot script that enables the Wi-Fi if it is > disabled > > and then sets the password (if not already set) using the first MAC > > address it finds on the device? > > MACs are not a secret. It is absolutely trivial to know them: they're > in just about every WiFi (and ethernet) frame. Same goes for anything > that is derived *just* from the MAC address. And anyone that is going > to automatically scan/exploit for that, will also use MAC-1, MAC+1, and > other common variants. > > What would work is to reuse the vendor-provided password that is > already > in the label and somewhere in FLASH, if you could always know where it > is in FLASH (you don't). And some models don't have it. > > One also don't know the unit's MAC address beforehand, so any scheme > that depends on that doesn't work (because you'd need that MAC address > to print the label or generate the PDF). In fact, this precludes the > "generate secret at the device at 1st boot" too. > > You could ask the user, but that isn't safe either: if she gets it > wrong > (or openwrt isn't correct about what MAC is in the printed label of > that > exact product version) you now have a device she can't access because > the passwords won't match and it would require an ethernet cable to > bypass and reset. Some models are more obvious about device unique default password storage than others. So like on my other reply if it is obvious then use it and turn on wifi. For those with wifi-on-first support, make it a check box in the hardware support table. Then small business using openwrt know what options might meet their deployment needs. - Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
On 06/07/2021 12:05, Nishant Sharma wrote: On 06/07/21 7:56 pm, Henrique de Moraes Holschuh wrote: So, to safely and responsibly enable wireless by default in a device (or firmware) you're delivering to a third-party, you need that "per-unit unique wireless password" per device thing most vendors are doing. [2] not really: openwrt sysugrade *does not help* in that there is no way to add variable information to an already *finished* image file, to be used on first-boot only, and which would *survive a factory reset*. How about a first-boot script that enables the Wi-Fi if it is disabled and then sets the password (if not already set) using the first MAC address it finds on the device? MACs are not a secret. It is absolutely trivial to know them: they're in just about every WiFi (and ethernet) frame. Same goes for anything that is derived *just* from the MAC address. And anyone that is going to automatically scan/exploit for that, will also use MAC-1, MAC+1, and other common variants. What would work is to reuse the vendor-provided password that is already in the label and somewhere in FLASH, if you could always know where it is in FLASH (you don't). And some models don't have it. One also don't know the unit's MAC address beforehand, so any scheme that depends on that doesn't work (because you'd need that MAC address to print the label or generate the PDF). In fact, this precludes the "generate secret at the device at 1st boot" too. You could ask the user, but that isn't safe either: if she gets it wrong (or openwrt isn't correct about what MAC is in the printed label of that exact product version) you now have a device she can't access because the passwords won't match and it would require an ethernet cable to bypass and reset. -- Henrique de Moraes Holschuh Analista de Projetos Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537 R.:4023 INOC 22548*625 www.nic.br ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
(combined reply to several emails) Henrique de Moraes Holschuh wrote: > However, it is *not* a simple matter to just "enable wireless" at first boot > in OpenWrt (due to a "default password" issue), except maybe in a > home-and-enthusiast setting. You cannot just do it for a device (or > firmware) you're going to deliver to third parties: it is *unsafe*, and > extremely strongly discouraged. I agree with you. I think is the OP's case, they are delivering something that is a physical unit, with a specific purpose. > So, to safely and responsibly enable wireless by default in a device (or > firmware) you're delivering to a third-party, you need that "per-unit unique > wireless password" per device thing most vendors are doing. > Now, unique per-device passwords are "easy" [2] to do if you're delivering > whole devices, as you can just print a label with the device's unique > password and attach to it or to its documentation. My training session from 2020: https://www.iotsecurityfoundation.org/consumer-iot/ https://www.youtube.com/watch?v=I-wHZ64T-Ps > It is far less easy when you're delivering just the firmware (openwrt-based), > which the third-party/user will install by herself. At least for generic > devices in the general case. This problem also presents itself for generating HTTPS certificates (which we've discussed at length on this list), and it's particularly acute when attempting to ship Virtual Machine Appliances! (Somehow, cloud-init can help, but I haven't figured out how yet) IoTSF's ManySecured WG, at https://manysecured.net/ is trying to figure this part out, and I think we'll shortly have a more open (less IoTSF member-only) ML for discussion. We'd very much like openwrt people involved. >> This would allow us to relax the security settings for the moment being, >> and discuss and plan them later on. It seems to me there is the general >> desire for having such a feature. > I would very much like to have a config option that allows one to implement > what I described in [2] below -- or something else that could be likewise > used. Basically, a way to append to an already-finished sysupgrade/factory > file some signed configuration data that will resist factory-reset, so that > it is easy/fast to do so at download time without the need to run the image > builder. I also think that this would be a good idea. I think that really, it belongs in the eeprom or in a custom partition that acts in a similiar way. The problem is that one also needs a "really really" factory-reset mode, which *does* erase this data and really goes back to default. > Around here, the ISPs call this kind of variable data that resists a > factory-reset "preseed configuration". Apparently, your typical home user > will factory-reset the device every time anything goes wrong, once they know > how to do it. AFAIK, the preseed configuration usually nukes all their per-customer settings, but retains the TR69 login info, which lets the device retrieve it's customer-specific configuration from the ISP. OpenWRT doesn't have a TR69 implementation merged (yet?!), and TR369 is out, and I know that several people are working on that. > So it is extremely important that the factory-reset settings > match whatever is needed for ISP connectivity and local wireless to work. > Easy to do if you're the router vendor and have a mtd partition set aside for > it, a lot more difficult otherwise. > Then, you could at least easily address the "you're shipping the device with > the label attached" case: you can do that right now using custom code on > specific devices you know of a partition you can reuse like that, etc. But a > "generic device" solution is still missing. I suggest that we should focus initially on the "I ship a device" situation. I think that the generic-device situation will have to sort itself out via help from hardware manufacturers: This is often already here, for instance, Turris has a keypair in the eeprom generated at the "factory" > The solution for "you ship firmware" could then become "build once, but at > download time you append the signed variable data that resists factory-reset, > and contains any unit-specific passwords. You also attach a PDF with the > device passwords for the user to print and glue to his unit". Here is a PDF to print is an interesting solution. > [1] The reports are public, and available at https://ceptro.br. Disclaimer: I > work for a different division of the same NGO that produced those reports. Thanks for this pointer... but can you give us the whole URL for those of us who don't speak Portugese (and google translate doesn't seem to have helped). > [2] not really: openwrt sysugrade *does not help* in that there is no way to > add variable
Re: Enabling Wi-Fi on First boot
On 06/07/21 7:56 pm, Henrique de Moraes Holschuh wrote: > So, to safely and responsibly enable wireless by default in a device (or > firmware) you're delivering to a third-party, you need that "per-unit > unique wireless password" per device thing most vendors are doing. > > [2] not really: openwrt sysugrade *does not help* in that there is no > way to add variable information to an already *finished* image file, to > be used on first-boot only, and which would *survive a factory reset*. > How about a first-boot script that enables the Wi-Fi if it is disabled and then sets the password (if not already set) using the first MAC address it finds on the device? Regards, Nishant ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
On 06/07/2021 03:45, Enrico Mioso wrote: I would like to know your opinion on a topic I know has already been discussed: enabling Wi-Fi on first boot. We had to do it here for some modified firmware we distribute (the device with the modified openwrt firmware is then used to measure internet connection quality in a neutral way, and works as well as a home router when desired). It is a fact[1] that >55% of homes in Brazil only have wireless terminals (read: cellphones, a few might also have tablets): no laptops or desktops. It would be utterly useless to deliver to them something that needs an ethernet cable to enable the wireless. However, it is *not* a simple matter to just "enable wireless" at first boot in OpenWrt (due to a "default password" issue), except maybe in a home-and-enthusiast setting. You cannot just do it for a device (or firmware) you're going to deliver to third parties: it is *unsafe*, and extremely strongly discouraged. So, to safely and responsibly enable wireless by default in a device (or firmware) you're delivering to a third-party, you need that "per-unit unique wireless password" per device thing most vendors are doing. Now, unique per-device passwords are "easy" [2] to do if you're delivering whole devices, as you can just print a label with the device's unique password and attach to it or to its documentation. It is far less easy when you're delivering just the firmware (openwrt-based), which the third-party/user will install by herself. At least for generic devices in the general case. I would very very much like to see this feature present in OpenWRt: because I find myself in a scenario where plugging an Ethernet cable after a fresh sysupgrade without keeping settings (due a a major upgrade or just to "start clean") could be impractical. Indeed. This would allow us to relax the security settings for the moment being, and discuss and plan them later on. It seems to me there is the general desire for having such a feature. I would very much like to have a config option that allows one to implement what I described in [2] below -- or something else that could be likewise used. Basically, a way to append to an already-finished sysupgrade/factory file some signed configuration data that will resist factory-reset, so that it is easy/fast to do so at download time without the need to run the image builder. Around here, the ISPs call this kind of variable data that resists a factory-reset "preseed configuration". Apparently, your typical home user will factory-reset the device every time anything goes wrong, once they know how to do it. So it is extremely important that the factory-reset settings match whatever is needed for ISP connectivity and local wireless to work. Easy to do if you're the router vendor and have a mtd partition set aside for it, a lot more difficult otherwise. Then, you could at least easily address the "you're shipping the device with the label attached" case: you can do that right now using custom code on specific devices you know of a partition you can reuse like that, etc. But a "generic device" solution is still missing. The solution for "you ship firmware" could then become "build once, but at download time you append the signed variable data that resists factory-reset, and contains any unit-specific passwords. You also attach a PDF with the device passwords for the user to print and glue to his unit". [1] The reports are public, and available at https://ceptro.br. Disclaimer: I work for a different division of the same NGO that produced those reports. [2] not really: openwrt sysugrade *does not help* in that there is no way to add variable information to an already *finished* image file, to be used on first-boot only, and which would *survive a factory reset*. -- Henrique de Moraes Holschuh Analista de Projetos Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537 R.:4023 INOC 22548*625 www.nic.br ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
Enrico Mioso wrote: > I wasn't sure about uci-defaults being the correct way to do it - I was > under the impression it could happen that my script gets ran when it's > too early and /etc/config/wireless hasn't been generated yet. > If this isn't the case, then I think it's fine! I haven't tried uci-defaults for the SHG project. Working on Turris MOX, we had two things we needed to tweak: 1) onboard eth0 needs to be WAN port (it has many modes due to different way MOX can be assembled) 2) enable PCIe wifi with an unencrypted ESSID, and with only a very select set of ports open (DNS, 443) so that our app could connect and take control on a TOFU basis. To be sure that we got it all, we booted up, tweaked a bunch of UCI things, and then rebooted to make sure that all the right things happened. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
On 7/6/21 8:36 AM, Alberto Bursi wrote: On 06/07/21 09:12, Enrico Mioso wrote: On Mon, 5 Jul 2021, Paul Spooren wrote: Date: Tue, 6 Jul 2021 09:06:14 From: Paul Spooren To: Enrico Mioso , openwrt-devel@lists.openwrt.org Subject: Re: Enabling Wi-Fi on First boot On 7/5/21 8:45 PM, Enrico Mioso wrote: Hello all!! I would like to know your opinion on a topic I know has already been discussed: enabling Wi-Fi on first boot. I would very very much like to see this feature present in OpenWRt: because I find myself in a scenario where plugging an Ethernet cable after a fresh sysupgrade without keeping settings (due a a major upgrade or just to "start clean") could be impractical. I think you can add uci-default scripts to enable it or do you want a config option during build time? Hello Paul!! Well, I tought about uci-defaults, but I tough it won't be so easy to implement due to the fact Wi-Fi is probed asynchronously, and on some devices i saw it takes a little bit (Netgear R7800). I would have liked to have something already implemented in OpenWRt, so it could be looked at by more people and have much higher chances of working on all devices. Enrico The only thing that must be done by a uci-defaults script is to set the wifi as enabled in the uci config. Afaik all devices ship with a default config for an open wifi network called "OpenWrt" for all their radios, but have option disabled '1' in both the device and wifi-iface text blocks, which disables the wifi. The uci-defaults script should just delete that line recursively along the whole /etc/config/wifi config file and it can be done with sed. Since uci-defaults scripts are run before everything else, the device should just have all wifi enabled on first boot no matter what wifi hardware it actually uses. You can easily turn this in a package (that only installs a uci-defaults script), just look at any other package that sets a uci-default script like this https://github.com/openwrt/packages/blob/master/net/bcp38/Makefile and use it as a template for your own. Since there are strong opinions are about keeping wifi off by default (last time I checked even devices that have no other network interfaces can't have a wifi enabled on first boot, forcing users to do a first config through the debug UART console or integrate a custom wifi config file in a custom image) I do not think many core developers will want to merge this package in core repository, but you can try. I think there should not be much problems if you send your package to community packages repository. https://github.com/openwrt/packages -Alberto Most modern devices have default SSID and password in ROM somewhere that stock OpenWrt doesn't touch. It is written on the radio regulatory compliance sticker. That would seem convenient for the user OEM or OpenWrt. IF OpenWrt knows where to find it, and IF it is found on on first boot, then enable WiFi at first boot. This is especially important on WiFi only devices and as more "slim format" user devices (tablets, phones, ...) are exclusive in homes and have no ethernet. A system reflash or reset with stock OpenWrt is not an option for these users. For example, it should not be trouble to find it on TL 3600/4300/Archer and WRT 1900/3200. - Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
Thanks a lot Alberto!! I wasn't sure about uci-defaults being the correct way to do it - I was under the impression it could happen that my script gets ran when it's too early and /etc/config/wireless hasn't been generated yet. If this isn't the case, then I think it's fine! Thank you all! On Tue, 6 Jul 2021, Alberto Bursi wrote: Date: Tue, 6 Jul 2021 14:36:18 From: Alberto Bursi To: openwrt-devel@lists.openwrt.org Subject: Re: Enabling Wi-Fi on First boot On 06/07/21 09:12, Enrico Mioso wrote: On Mon, 5 Jul 2021, Paul Spooren wrote: Date: Tue, 6 Jul 2021 09:06:14 From: Paul Spooren To: Enrico Mioso , openwrt-devel@lists.openwrt.org Subject: Re: Enabling Wi-Fi on First boot On 7/5/21 8:45 PM, Enrico Mioso wrote: Hello all!! I would like to know your opinion on a topic I know has already been discussed: enabling Wi-Fi on first boot. I would very very much like to see this feature present in OpenWRt: because I find myself in a scenario where plugging an Ethernet cable after a fresh sysupgrade without keeping settings (due a a major upgrade or just to "start clean") could be impractical. I think you can add uci-default scripts to enable it or do you want a config option during build time? Hello Paul!! Well, I tought about uci-defaults, but I tough it won't be so easy to implement due to the fact Wi-Fi is probed asynchronously, and on some devices i saw it takes a little bit (Netgear R7800). I would have liked to have something already implemented in OpenWRt, so it could be looked at by more people and have much higher chances of working on all devices. Enrico The only thing that must be done by a uci-defaults script is to set the wifi as enabled in the uci config. Afaik all devices ship with a default config for an open wifi network called "OpenWrt" for all their radios, but have option disabled '1' in both the device and wifi-iface text blocks, which disables the wifi. The uci-defaults script should just delete that line recursively along the whole /etc/config/wifi config file and it can be done with sed. Since uci-defaults scripts are run before everything else, the device should just have all wifi enabled on first boot no matter what wifi hardware it actually uses. You can easily turn this in a package (that only installs a uci-defaults script), just look at any other package that sets a uci-default script like this https://github.com/openwrt/packages/blob/master/net/bcp38/Makefile and use it as a template for your own. Since there are strong opinions are about keeping wifi off by default (last time I checked even devices that have no other network interfaces can't have a wifi enabled on first boot, forcing users to do a first config through the debug UART console or integrate a custom wifi config file in a custom image) I do not think many core developers will want to merge this package in core repository, but you can try. I think there should not be much problems if you send your package to community packages repository. https://github.com/openwrt/packages -Alberto From an implementation perspective, I don't think this feature needs to be present on images we build with builtbots, nor official images at all. It may be a config option a user can check when self-building his/her images. This would allow us to relax the security settings for the moment being, and discuss and plan them later on. It seems to me there is the general desire for having such a feature. Thanks a lot! Enrico ___ 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
On 06/07/21 09:12, Enrico Mioso wrote: On Mon, 5 Jul 2021, Paul Spooren wrote: Date: Tue, 6 Jul 2021 09:06:14 From: Paul Spooren To: Enrico Mioso , openwrt-devel@lists.openwrt.org Subject: Re: Enabling Wi-Fi on First boot On 7/5/21 8:45 PM, Enrico Mioso wrote: Hello all!! I would like to know your opinion on a topic I know has already been discussed: enabling Wi-Fi on first boot. I would very very much like to see this feature present in OpenWRt: because I find myself in a scenario where plugging an Ethernet cable after a fresh sysupgrade without keeping settings (due a a major upgrade or just to "start clean") could be impractical. I think you can add uci-default scripts to enable it or do you want a config option during build time? Hello Paul!! Well, I tought about uci-defaults, but I tough it won't be so easy to implement due to the fact Wi-Fi is probed asynchronously, and on some devices i saw it takes a little bit (Netgear R7800). I would have liked to have something already implemented in OpenWRt, so it could be looked at by more people and have much higher chances of working on all devices. Enrico The only thing that must be done by a uci-defaults script is to set the wifi as enabled in the uci config. Afaik all devices ship with a default config for an open wifi network called "OpenWrt" for all their radios, but have option disabled '1' in both the device and wifi-iface text blocks, which disables the wifi. The uci-defaults script should just delete that line recursively along the whole /etc/config/wifi config file and it can be done with sed. Since uci-defaults scripts are run before everything else, the device should just have all wifi enabled on first boot no matter what wifi hardware it actually uses. You can easily turn this in a package (that only installs a uci-defaults script), just look at any other package that sets a uci-default script like this https://github.com/openwrt/packages/blob/master/net/bcp38/Makefile and use it as a template for your own. Since there are strong opinions are about keeping wifi off by default (last time I checked even devices that have no other network interfaces can't have a wifi enabled on first boot, forcing users to do a first config through the debug UART console or integrate a custom wifi config file in a custom image) I do not think many core developers will want to merge this package in core repository, but you can try. I think there should not be much problems if you send your package to community packages repository. https://github.com/openwrt/packages -Alberto From an implementation perspective, I don't think this feature needs to be present on images we build with builtbots, nor official images at all. It may be a config option a user can check when self-building his/her images. This would allow us to relax the security settings for the moment being, and discuss and plan them later on. It seems to me there is the general desire for having such a feature. Thanks a lot! Enrico ___ 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
Re: Enabling Wi-Fi on First boot
On Tue, 6 Jul 2021, Tom Psyborg wrote: Date: Tue, 6 Jul 2021 11:37:15 From: Tom Psyborg To: Enrico Mioso Cc: Paul Spooren , OpenWrt Development List Subject: Re: Enabling Wi-Fi on First boot It's been discussed multiple times already. There is no need for additional scripts as you can tweak it in main WiFi script. Search the forums Hello there!! I was hoping for a solution that would get integrated into the upstream project. Various tweaks are possible, but I was hoping for something as generic as possible. Thanks! Enrico On Tue, Jul 6, 2021, 09:14 Enrico Mioso wrote: On Mon, 5 Jul 2021, Paul Spooren wrote: > Date: Tue, 6 Jul 2021 09:06:14 > From: Paul Spooren > To: Enrico Mioso , openwrt-devel@lists.openwrt.org > Subject: Re: Enabling Wi-Fi on First boot > > > On 7/5/21 8:45 PM, Enrico Mioso wrote: >> Hello all!! >> >> I would like to know your opinion on a topic I know has already been >> discussed: enabling Wi-Fi on first boot. >> I would very very much like to see this feature present in OpenWRt: because >> I find myself in a scenario where plugging an Ethernet cable after a fresh >> sysupgrade without keeping settings (due a a major upgrade or just to >> "start clean") could be impractical. > I think you can add uci-default scripts to enable it or do you want a config > option during build time? Hello Paul!! Well, I tought about uci-defaults, but I tough it won't be so easy to implement due to the fact Wi-Fi is probed asynchronously, and on some devices i saw it takes a little bit (Netgear R7800). I would have liked to have something already implemented in OpenWRt, so it could be looked at by more people and have much higher chances of working on all devices. Enrico >> >> From an implementation perspective, I don't think this feature needs to be >> present on images we build with builtbots, nor official images at all. It >> may be a config option a user can check when self-building his/her images. >> This would allow us to relax the security settings for the moment being, >> and discuss and plan them later on. It seems to me there is the general >> desire for having such a feature. >> >> Thanks a lot! >> >> Enrico >> >> ___ >> 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
Re: Enabling Wi-Fi on First boot
On Mon, 5 Jul 2021, Paul Spooren wrote: Date: Tue, 6 Jul 2021 09:06:14 From: Paul Spooren To: Enrico Mioso , openwrt-devel@lists.openwrt.org Subject: Re: Enabling Wi-Fi on First boot On 7/5/21 8:45 PM, Enrico Mioso wrote: Hello all!! I would like to know your opinion on a topic I know has already been discussed: enabling Wi-Fi on first boot. I would very very much like to see this feature present in OpenWRt: because I find myself in a scenario where plugging an Ethernet cable after a fresh sysupgrade without keeping settings (due a a major upgrade or just to "start clean") could be impractical. I think you can add uci-default scripts to enable it or do you want a config option during build time? Hello Paul!! Well, I tought about uci-defaults, but I tough it won't be so easy to implement due to the fact Wi-Fi is probed asynchronously, and on some devices i saw it takes a little bit (Netgear R7800). I would have liked to have something already implemented in OpenWRt, so it could be looked at by more people and have much higher chances of working on all devices. Enrico From an implementation perspective, I don't think this feature needs to be present on images we build with builtbots, nor official images at all. It may be a config option a user can check when self-building his/her images. This would allow us to relax the security settings for the moment being, and discuss and plan them later on. It seems to me there is the general desire for having such a feature. Thanks a lot! Enrico ___ 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
Re: Enabling Wi-Fi on First boot
On 7/5/21 8:45 PM, Enrico Mioso wrote: Hello all!! I would like to know your opinion on a topic I know has already been discussed: enabling Wi-Fi on first boot. I would very very much like to see this feature present in OpenWRt: because I find myself in a scenario where plugging an Ethernet cable after a fresh sysupgrade without keeping settings (due a a major upgrade or just to "start clean") could be impractical. I think you can add uci-default scripts to enable it or do you want a config option during build time? From an implementation perspective, I don't think this feature needs to be present on images we build with builtbots, nor official images at all. It may be a config option a user can check when self-building his/her images. This would allow us to relax the security settings for the moment being, and discuss and plan them later on. It seems to me there is the general desire for having such a feature. Thanks a lot! Enrico ___ 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
Enabling Wi-Fi on First boot
Hello all!! I would like to know your opinion on a topic I know has already been discussed: enabling Wi-Fi on first boot. I would very very much like to see this feature present in OpenWRt: because I find myself in a scenario where plugging an Ethernet cable after a fresh sysupgrade without keeping settings (due a a major upgrade or just to "start clean") could be impractical. From an implementation perspective, I don't think this feature needs to be present on images we build with builtbots, nor official images at all. It may be a config option a user can check when self-building his/her images. This would allow us to relax the security settings for the moment being, and discuss and plan them later on. It seems to me there is the general desire for having such a feature. Thanks a lot! Enrico ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
