#694068 netcfg: Wireless connectivity present during an install but absent afterwards

Package:
netcfg
Source:
netcfg
Submitter:
Brian Potkin
Date:
2025-08-17 17:47:49 UTC
Severity:
important
Tags:
#694068#5
Date:
2012-11-23 14:31:20 UTC
From:
To:

I installed in expert mode over a wireless link from

Debian GNU/Linux testing "Wheezy" - Official Snapshot i386 NETINST Binary-1 20121122-21:21

This ISO has netcfg_1.102. Only "Standard system utilities" was selected
as a task. Re-booted as instructed. No network! Checked the contents of
/etc/network/interfaces. The only interface available is lo. I'm still
in a state of shock. :)

From the netcfg changelog:

    * On Linux: Write a network-manager configuration file in perference
      to ifupdown if network-manager is found in the installed system.
      Configure wired networking with ifupdown if not. Do not configure
      wireless networking through ifupdown.

and

     * Reword target_network_config template; do not ask the question.

Not only am I deprived of network connectivity because I did not install
network-manager or use a network cable, but this is done silently.

The machine that Debian was put on is a desktop model and isn't going
anywhere. Now I have try to recollect what to put in /e/n/i to restore
the network connection. Also, the WPA passphrase is a machine generated
63 random characters. With gpm it's a snap to copy and paste. Except....

If I'd installed to a laptop I might have wanted wpagui to deal with any
roaming. Or network-manager for that matter. Having to start from
scratch is tiresome.

Anyone who used a network during an install would, in my opinion, most
likely want it available afterwards. Please consider leaving it set up
as configured by ifupdown when the install takes place as described
above.

Some discussion of the issue is in the thread starting at

http://lists.debian.org/debian-boot/2012/09/msg00252.html

#694068#10
Date:
2012-11-25 15:30:28 UTC
From:
To:
Hello,

For most cases, I think not adding configuration for wireless in
/e/n/i is good, however for the kind a situations you described I
think the best solution would be to have the question asked, at least
with a low priority. If that would be the case, changing the
permissions of /e/n/i to 600 should also be considered.

Sorina

#694068#15
Date:
2012-11-25 19:59:02 UTC
From:
To:
On Sun 25 Nov 2012 at 17:30:28 +0200, Sorina - Gabriela Sandu wrote:

Hello Sorina.

Having the question asked in *all* cases would be far preferable to
having something you may not want forced on you.

I still do not understand "For most cases . . .". Without a handful of
CDs available there is only one way to restore the disallowed connection
to a network - ifupdown. Set it up, pull it down, set it up again isn't
my idea of what Debian should do.

Because the opportunity may not arise again:

I have been following the development of wireless connectivity in D-I
for the past year. The implementation (from the point of view of whether
it works) is very good. I would like to thank you and everybody else for
the work which has been done. The quality of the emerging end result is
a credit to the Debian Project and shows what can be achieved with Free
software and a team of committed developers.

#694068#20
Date:
2012-11-25 20:58:36 UTC
From:
To:
Hello,

Yes, the question should be asked for all installs, but with a low
priority. I can't think of a criterion on which to decide whether to
ask it or not and I also don't believe that having such criterion
would be useful.

What I wanted to say by "For most cases" is that I believe that having
the _default_ to not write wireless config in /e/n/i is good, and this
would work for most installs (but obviously not for the case you
mentioned). I wasn't thinking of asking the questions is "some cases"
and not in others. I hope it's more clear now :)

Thanks,
Sorina

#694068#23
Date:
2012-11-28 20:11:35 UTC
From:
To:
A low priority wouldn't really help, given that it would only be shown in
expert mode. I'm not sure if there's a sane default here and would appreciate
if others could chime in with their opinion. Things like "would we need to
chmod 0600 /e/n/i?", "would all tools cope with /e/n/i being 0600 if so" and
"should we write an entry that might prevent later installations of network
connection management tools to work correctly?".

Kind regards
Philipp Kern

#694068#26
Date:
2012-11-28 20:11:35 UTC
From:
To:
A low priority wouldn't really help, given that it would only be shown in
expert mode. I'm not sure if there's a sane default here and would appreciate
if others could chime in with their opinion. Things like "would we need to
chmod 0600 /e/n/i?", "would all tools cope with /e/n/i being 0600 if so" and
"should we write an entry that might prevent later installations of network
connection management tools to work correctly?".

Kind regards
Philipp Kern

#694068#33
Date:
2016-07-16 15:51:43 UTC
From:
To:
I bumped into this issue when I recently installed Debian on my new laptop.

I only installed the "Standard system utilities", thus no network-manager and
while wpasupplicant was installed the wireless connection config I used during
installation wasn't written to a/the wpa_supplicant.conf file and neither was
there anything configured/written to /e/n/i related to my wireless card.
Due to 'predicable' network naming this becomes even more of a hassle to do
manually.

While the above quote is from 25 Nov 2012 and I haven't checked whether the
changelog would now tell sth different, it looks like wireless networking
through ifupdown is not configured, regardless whether network-manager is
present or not.

Why not configure wireless networking through ifupdown when network-manager
*isn't* installed?

I have to give you kudos for (manually?) copying an .ucode file which I
provided through a workaround [1], but that added to my surprise that wireless
networking still wouldn't work due to the above described problem.

Cheers,
  Diederik

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808792#47

#694068#42
Date:
2018-03-05 10:55:57 UTC
From:
To:
[...]

The number of users affected by this issue over the years is not
insignificant. Not a single one has written in support of the
situation.

https://lists.debian.org/debian-user/2018/03/msg00066.html

has the latest experiences of three users.

Regards,

Brian.

#694068#47
Date:
2018-03-06 00:07:59 UTC
From:
To:
Brian Potkin wrote:

This issue has bitten me at least twice so far.

This issue's history seems to be bogged down on whether interfaces(5) can be mode 0600 (to hide the cleartext passphrase).
This is not necessary; the passphrase can go in a separate file.

Here is a minimal config, assuming WPA2 PSK (not Enterprise) and DHCP (not static) for all SSIDs:

    cat >/etc/network/interfaces <<EOF
    allow-auto lo $iface
    iface lo inet loopback
    iface default inet dhcp
    iface $iface inet manual
      wpa-roam /etc/wpa_supplicant/wpa_supplicant-$iface.conf
    EOF

    wpa_passphrase "$ssid" "$passphrase" >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf"
    chmod 0600 "/etc/wpa_supplicant/wpa_supplicant-$iface.conf"

If you don't want to udebify wpa_passphrase, you can do it by hand:

    cat >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf" <<EOF
    network={
      ssid="$ssid"
      psk="$passphrase"
    }
    EOF

If you really hate ifupdown, you can use systemd instead (not fully tested):

    cat >/etc/systemd/network/$iface.network <<EOF
    [Match]
    iface=$iface
    [Network]
    DHCP=yes
    EOF

    systemctl enable wpa_supplicant@$iface.service

    wpa_passphrase "$ssid" "$passphrase" >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf"
    chmod 0600 "/etc/wpa_supplicant/wpa_supplicant-$iface.conf"

If even these things are too much, can you AT LEAST install wpasupplicant?
Writing config files is much easier than ferrying .debs between computers by USB key.

If this bug is going to be kept ANOTHER Debian release,
can you at least warn people about it in the buster Installation Guide?

#694068#52
Date:
2018-03-06 18:34:27 UTC
From:
To:
bw writes ("Re: (solved) Re: wireless fail after stretch installation"):

If installing a desktop environment, after putting the wireless in
/e/n/i, does not work, then that is a bug in the desktop environment,
surely ?

In practice I would expect the config in /e/n/i to keep working
because nowadays network-manager will ignore things in /e/n/i.  The
difficulty would only come if you
  - used the installer to install a bare system over wifi
  - later install network-manager or wicd
  - then expect the system to give you a gui prompt for new wifi
    networks, rather than expect to have to edit /e/n/i

It would be possible for the n-m and wicd packages to spot when this
is happening and offer to take over the interface.  And I do think
that in the absence of code to do that, it would be more important to
make the barebones system work in the first place, than to improve the
behaviour you later install n-m.

(I'm not sure if what I say about wicd is right.  I use n-m on
machines I have where the user needs to switch between various network
connections, wifi networks, etc.)

The bug tyracker is precisely the right place to discuss how to solve
a particular bug.  So I have CC'd it.

Ian.

#694068#55
Date:
2018-03-06 20:08:52 UTC
From:
To:
Most probably. But desktop environments were not the subject of this
thread. (Sorry for trying to keep on-topic).

That difficulty is  exactly the subject of this thread. The rest of this
post is snipped because it side-steps addressing the issue. What is put
in /e/n/i ceases to work because it is obliterated by the installer for
reasons unknown.

One user calls it a "sick joke". After five years and with no attempt
to rectify the situation, I'm beginning to have sympathy with that view.

(Yes, I know we are all volunteers).

#694068#60
Date:
2018-03-07 18:48:43 UTC
From:
To:
Mode 0600 wasn't intially given as a reason:

https://lists.debian.org/debian-boot/2012/09/msg00282.html

 > I realise a default is only a default and the selection can be changed,
 > but I'm puzzled by the third option. Why treat a wireless install
 > differently from a wired install? It would expected that a user who has
 > chosen not to use a wired connection would still want connectivity after
 > booting into into the new system,

   The main reason for this is that as far as I know writing configs
   related to a wireless network to /e/n/i enforce using only that
   particular network later (of course if you don't modify the file) and
   also that the interface is unmanageable for other tools. The idea was
   to leave the network unconfigured, so that it can be managed later
   (perhaps via something else than NM).

Later in the thread:

https://lists.debian.org/debian-boot/2012/09/msg00313.html

 > On the other hand, we have users who chose not to install a desktop
 > environment but want their machine to migrate between networks when it's
 > moved. These users are going to need to do some form of sysadmin work
 > post-install, whether it's installing a desktop environment and wicd, or
 > editing /etc/network/interfaces on each fresh network, or bringing up
 > wifi connections by hand. So I can't see locking a default into
 > /etc/network/interfaces causing them much bother.

   IIRC we decided on this default before we added the code to change the
   access mode of /e/n/i if it contains a password. The main reason for
   defaulting to no configuration in this case was to avoid having
   passwords in there. If people think it should default to ifupdown in
   this case this can be changed.

The default (loopback only for wireless) was added without considering
mode 0600. At this stage in the history there appears to be a willingness
to use ifupdown and not loopback.

Or dispense with loopback for an installation over wireless (an easy
enough change) and warn about 0600 in the Release Notes.

#694068#69
Date:
2021-12-14 04:37:26 UTC
From:
To:
Having just swatted away this bug while installing bullseye
on a laptop that has 1xUSB3, 2xUSB-C and no ethernet, I thought
I should share the workaround here. This is only necessary,
I'm led to believe, when installing by WiFi without the
installation of a Desktop.

Before tearing down the WiFi interface at the very end of
the installation, the d-i should simply copy the existing
/target/etc/network/interfaces file to /target/root/, perhaps
named as etc-network-interfaces-at-installation, with its
permissions set to 600.

When the machine is rebooted, it is now straightforward for
the sysadmin to login and simply:

  # mv /root/etc-network-interfaces-at-installation /etc/network/interfaces
  # ifup w<TAB><RETURN>

to give themselves WiFi connectivity (using sudo if necessary).

This workaround has the benefit of being fail-safe: the file has
no effect on the system if the sysadmin ignores it and leaves it
in /root, but if they do move it as above, then they've taken
responsibility for its effects on any software they install later.

Naturally, it would require a note in the Installation Guide for
this method to be useful if the sysadmin is not one to make use
of root's home directory.

Cheers,
David.

#694068#74
Date:
2021-12-28 16:19:15 UTC
From:
To:
Bună seara, vă rog să mă sunați acum sau să răspundeți la mailul pe care vi
l-am trimis de ieri.

#694068#79
Date:
2023-01-02 17:27:00 UTC
From:
To:
Just hit this will bookworm too:

https://bugs.debian.org/1027692

Not too bad, given not great options! :)

... or even /etc/network/interfaces.with-wifi and chmod 0600 it for the
previously discussed security reasons.

I would be more likely to notice a file sitting next to
/etc/network/interfaces rather than rummaging around in /root.

live well,
  vagrant