subject:"Enabling Wi\-Fi on First boot"

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.

On Wed, 7 Jul 2021, Vincent Wiemann wrote:

Date: Wed, 7 Jul 2021 06:25:29
From: Vincent Wiemann 
To: Luiz Angelo Daros de Luca ,
OpenWrt Development List 
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
 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 d

Re: Enabling Wi-Fi on First boot

2021-07-06 Thread Vincent Wiemann

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.

-Al

Re: Enabling Wi-Fi on First boot

2021-07-06 Thread 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
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

2021-07-06 Thread Lao Shaw

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

2021-07-06 Thread Michael Richardson

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

2021-07-06 Thread Eric Luehrsen


>
> 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

2021-07-06 Thread Michael Richardson

(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 information

Re: Enabling Wi-Fi on First boot

2021-07-06 Thread Nishant Sharma

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

2021-07-06 Thread Michael Richardson

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

2021-07-06 Thread Eric Luehrsen


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

2021-07-06 Thread Paul Spooren




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