I did think about merging, but wasn't sure about the priority. Don't you think this deserves "important"?
Control: severity 1095302 important
Control: merge 1095302 -1
Control: reassign -1 netcfg 1.194
[Please send replies to the bug mail address, not only mine]
On 24/04/2025 at 12:59, Marcin Owsiany wrote:
I did think about merging, but wasn't sure about the priority. Don't you think this deserves "important"?
I am not sure either but let's raise the original bug priority anyway, merge and reassign the two bugs to netcfg. If anyone objects, the priority can be lowered.
To d-i people: adding nl80211 and wifi 7 support to netcfg looks like
a big task and I guess it is way too late to do it before Trixie
release.
However wouldn't it be desirable to mark wifi 7 controllers as
unsupported in netcfg and in the installation guide in order to limit
user frustration ?
The difference between normal and important is a matter of opinion, and
that doesn't really factor in what we're going to do about these bug
reports anyway. Important looks good to me.
(Also, when a submitter considers their bug to be covered by another bug report, an option would be to close their bug, mentioning that's a
duplicate of another one, or that the other one is more complete,
precise, etc.)
To d-i people: adding nl80211 and wifi 7 support to netcfg looks like
a big task and I guess it is way too late to do it before Trixie
release.
ISTR someone asking for help to implement/test that, but I couldn't deal
with that at the time (or now), but I had some vague hopes to look into
it (either assisting or hacking myself) “in the near future”. I'm not sure how prevalent Wi-Fi 7 is at the moment, but it seems to me this is definitely something we should tackle, and that might be worth
considering as a backport to Trixie (via point releases) (1) if and when support has landed and has been tested, and (2) if backporting doesn't
seem crazy (code/packaging change wise, and risk wise).
However wouldn't it be desirable to mark wifi 7 controllers as
unsupported in netcfg and in the installation guide in order to limit
user frustration ?
If we can easily spot unsupported cards and not offer them at all
(ignore entirely, with explicit log lines in syslog?) and also document
that in the installation guide, that'd be nice to have. Best if that can
land in 13.0; OK if that lands in 13.n, n>0. (Until support comes along
and is considered for a possible backport as detailed above.)
I get the impression most laptops shipping now are wifi 7. Most
machines I have seen in the last year had had it at least.
I can certainly test it. I asked a few months ago about how a desired implementation should be done, but got no response from anyone to the question.
Given the new interface is netlink based, and there already is libnl
in the installer, I don't think it would be a big change package wise,
but it would need netcfg to add support for making netlink calls to
control wifi 7 devices (and optionally wifi 6 devices I suppose).
Certainly the current installer behaviour is confusing since the
driver loads, then it treats it like a wired port which doesn't work
because wifi 7 drivers require using the new interface which netcfg
doesn't support. So you see the network device present but it doesn't
ask about wifi settings it just tries to do dhcp and fails.
Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-24):
However wouldn't it be desirable to mark wifi 7 controllers as
unsupported in netcfg and in the installation guide in order to limit
user frustration ?
If we can easily spot unsupported cards and not offer them at all
(ignore entirely, with explicit log lines in syslog?) and also document
that in the installation guide, that'd be nice to have. Best if that can
land in 13.0; OK if that lands in 13.n, n>0. (Until support comes along
and is considered for a possible backport as detailed above.)
On the user interface side, what would be best ?
- Silently ignore unsupported interfaces ? (but the user may wonder why the
interface is not showing)
- Or warn the user that the wireless interface is not supported yet ? (with
a new debconf template, implies translation effort).
if /sys/class/net/$[interface}/wireless exists
or /sys/class/net/$[interface}/uevent contains "DEVTYPE=wlan"
or /sys/class/net/$[interface}/type = "801" (802.11)
Lennart or Marcin, can you check if any of these conditions match your
Wi-Fi 7 interface ?
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">if /sys/class/net/$[interface}/wireless exists<br>or /sys/class/net/$[interface}/uevent contains "DEVTYPE=wlan"<br>
1<br><div><br></div><div>Marcin </div></div></div>
On the user interface side, what would be best ?
I think I answered that in my previous answer?
- Silently ignore unsupported interfaces ? (but the user may wonder why the >> interface is not showing)
Log + documentation, yes.
- Or warn the user that the wireless interface is not supported yet ? (with >> a new debconf template, implies translation effort).
At this stage? That really doesn't look like either reasonable or feasible.
These commands yield the same output on both P1 Gen7 (WiFi 7 I assume) and
P1 Gen3 (I assume not WiFi 7, because wifi worked in netcfg back when I installed Debian on it)
Am 29. April 2025 00:21:37 MESZ schrieb Cyril Brulebois <kibi@debian.org>: >At this stage? That really doesn't look like either reasonable or feasible.
I could think of adding a new template, but not mark it as translatable.
So it's always in English, and does not break translation status.
After Trixie is released, it could then be changed in translatable and translators get it (for Forky and probably trixie point release).
These commands yield the same output on both P1 Gen7 (WiFi 7 I assume) and >> P1 Gen3 (I assume not WiFi 7, because wifi worked in netcfg back when I
installed Debian on it)
Eyeballing these device directories from both laptops side by side did not reveal anything that could be used to distinguish wifi7 from earlier versions, but maybe I missed something.
Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-29):
- Silently ignore unsupported interfaces ? (but the user may wonder why the >> interface is not showing)
Log + documentation, yes.
Am 29. April 2025 00:21:37 MESZ schrieb Cyril Brulebois <kibi@debian.org>:
Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-29):
- Or warn the user that the wireless interface is not supported yet ? (with >>> a new debconf template, implies translation effort).
At this stage? That really doesn't look like either reasonable or feasible.
I could think of adding a new template, but not mark it as translatable.
So it's always in English, and does not break translation status.
To be honest, at this stage, I'm a little worried about getting the
logic right. If someone managed to have a piece of code that works in
the installed system, I could look into doing whatever is needed to get
it to work inside d-i (dealing with Makefiles, build systems, linking
against libnl or whatever).
If someone had reference(s) of external adapters I could easily shop for
and get delivered to France, that would make the feedback loop shorter
(I'd be able to hack and build and test, instead of hacking and
building, then asking others to test).
Am 29. April 2025 00:21:37 MESZ schrieb Cyril Brulebois <kibi@debian.org>: >>> Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-29):PoC: <https://salsa.debian.org/pham/netcfg/-/tree/pham/wifi7-2>
Not sure if I made the new two templates non translatable properly, please check.
Am 29. April 2025 00:21:37 MESZ schrieb Cyril Brulebois <kibi@debian.org>: >>> Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-29):
I could think of adding a new template, but not mark it as translatable.
- Or warn the user that the wireless interface is not supported yet ? (with
a new debconf template, implies translation effort).
At this stage? That really doesn't look like either reasonable or feasible. >>
So it's always in English, and does not break translation status.
PoC: <https://salsa.debian.org/pham/netcfg/-/tree/pham/wifi7-2>
Not sure if I made the new two templates non translatable properly, please check.
Temporary ISO image: <https://salsa.debian.org/pham/netcfg/-/jobs/7517082/artifacts/file/debian/output/debian-202501XX+salsaci+20250501+53-amd64-gtkmini.iso>
I may be missing something so correct me if I am wrong but IMO you do not need Wi-Fi 7 hardware to test: you can disable the current check which uses wext in is_wireless_iface() and use any wireless adapter whose driver uses nl80211. AFAICS since Linux 6.8 all in-kernel wireless drivers depend on cfg80211/mac80211.
Am 1. Mai 2025 15:17:54 MESZ schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:
PoC: <https://salsa.debian.org/pham/netcfg/-/tree/pham/wifi7-2>
- Or warn the user that the wireless interface is not supported yet ? >>>
I gave it a go, it seems to work as intended, see attached screenshots.
A couple of notes that I would have found useful on this screen or related docs:
- the installed system (network manager etc) might in fact support WiFi7
just fine
- an USB-attached ethernet interface might be a good enough workaround for installation time
On 02/05/2025 at 09:19, Marcin Owsiany wrote:
Am 1. Mai 2025 15:17:54 MESZ schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:
PoC: <https://salsa.debian.org/pham/netcfg/-/tree/pham/wifi7-2>
- Or warn the user that the wireless interface is not supported yet ? >>>
I gave it a go, it seems to work as intended, see attached screenshots.
A couple of notes that I would have found useful on this screen or related docs:
- the installed system (network manager etc) might in fact support WiFi7 just fine
- an USB-attached ethernet interface might be a good enough workaround for installation time
New tweaked version with this and "Go back" working as expected when
both supported and unsupported interfaces are found:
<https://salsa.debian.org/pham/netcfg/-/jobs/7521336/artifacts/file/debian/output/debian-202501XX+salsaci+20250502+57-amd64-gtkmini.iso>
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote (Fri, 2 May 2025 11:52:02 +0200):
New tweaked version with this and "Go back" working as expected when
both supported and unsupported interfaces are found:
You are talking about a "new (...) version" here, but I cannot find any
such commit.
On 04/05/2025 at 20:10, Holger Wansing wrote:
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote (Fri, 2 May 2025 11:52:02 +0200):
New tweaked version with this and "Go back" working as expected when
both supported and unsupported interfaces are found:
You are talking about a "new (...) version" here, but I cannot find any such commit.
Because I amended the last two commits and force-pushed.
On 02/05/2025 at 09:19, Marcin Owsiany wrote:
Am 1. Mai 2025 15:17:54 MESZ schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:
PoC: <https://salsa.debian.org/pham/netcfg/-/tree/pham/wifi7-2>
- Or warn the user that the wireless interface is not supported yet ? >>>
I gave it a go, it seems to work as intended, see attached screenshots.
A couple of notes that I would have found useful on this screen or related docs:
- the installed system (network manager etc) might in fact support WiFi7 just fine
- an USB-attached ethernet interface might be a good enough workaround for installation time
New tweaked version with this and "Go back" working as expected when
both supported and unsupported interfaces are found:
Maybe one more proposal:
do not focus on the "USB-attached ethernet interface" in the template.
Maybe the user already has a wired ethernet interface built into the
laptop, but the user did not take that into account, since using WiFi is
just the preferred option, because it's easier (no need to plug in a cable).
On 04/05/2025 at 21:17, Holger Wansing wrote:
Maybe one more proposal:
do not focus on the "USB-attached ethernet interface" in the template. Maybe the user already has a wired ethernet interface built into the laptop, but the user did not take that into account, since using WiFi is just the preferred option, because it's easier (no need to plug in a cable).
The user will see that template only if no supported interface was
detected. There is no user's choice, unless they chose to disable the built-in ethernet controller in BIOS settings.
So I think we are ready for a MR?
Any objections, to get this into trixie, as a workaround for WiFi 7 ?
So I think we are ready for a MR?
Any objections, to get this into trixie, as a workaround for WiFi 7 ?
Draft MR opened: ><https://salsa.debian.org/installer-team/netcfg/-/merge_requests/16>
But this was originally intended as a quick and dirty PoC, not sure it is ready for production.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 482 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 69:05:26 |
| Calls: | 9,571 |
| Calls today: | 2 |
| Files: | 13,663 |
| Messages: | 6,142,164 |