GNOME Bugzilla – Bug 736242
ifupdown: no longer takes connections from /etc/network/interfaces longer than 15 charakters
Last modified: 2020-11-12 14:33:20 UTC
Created attachment 285620 [details] /etc/network/interfaces Hi. Actually severty should be critical, since this breaks networking. With that version, it seems that network-breaker no longer correctly reads stuff from /e/n/interfaces . I mean that has been buggy ever since, and e.g. WPA-EAP connections never worked with NM, but now normal WPA-PSK connections aren’t working any longer as well. It seems that the ifupdown plugin stopped exporting any connections/ifaces, whose names are longer than 15 characters, which easily happens with WiFi, when using e.g. ifscheme as well. Downgrading to 0.9.8.10 fixes the issue. Cheers, Chris.
Created attachment 285621 [details] NM debug log
Oh I forgot to mention that I've started noting the problem with 0.9.10.0. Not sure about the versions between that and 0.9.8.10 (which still works).
Thanks for reporting the bug, I further recommend to attract attention of someone actually using a distribution with /etc/network/interfaces and willing to provide patches for problems like this one. AFAIK ifupdown support is read only and thus only used by those people who write the configuration file manually.
Well I guess that's clear... But OTOH, NM upstream should probably have much more uhm... "enthusiasm" to properly integrate into the native tools... I mean this here now is really a nasty bug, but it's by far not the only one where NM is buggy or doesn't work at all with the native toolset. Since it's unlikely that NM will every really replace those native network configuration systems (from ifcfg, ifupdown to stuff like vpnc) it should be really upstream's interest to make NM integrate nicely and completely with those things, since otherwise it will always cause troubles and never be really used.
(In reply to comment #4) > But OTOH, NM upstream should probably have much more uhm... "enthusiasm" to > properly integrate into the native tools... NetworkManager upstream is basically anyone interested in improving the software in any way. The best way to affect the future of a project is to join it. > I mean this here now is really a nasty bug, but it's by far not the only one > where NM is buggy or doesn't work at all with the native toolset. We have had those discussions already. The /etc/network/interfaces is a format specific to a particular set of distributions and it's the distribution maintainers who are responsible for best integration with the specifics of their distributions. Only a very small minority (my own guess) of users of those distributions actually want to use /etc/network/interfaces to configure NetworkManager and it's known to not work very well. I personally would remove buggy support for /etc/network/interfaces until there's a maintainer for it but other developers wanted to keep the support even though far from perfect. Individual maintainers have different motivations to contribute to the software and there's an apparent lack of motivated people for the ifupdown plugin. Would be great if someone appeared but nobody seems to care. > (from ifcfg, ifupdown to stuff like vpnc) it should be > really upstream's interest to make NM integrate nicely and completely with > those things, since otherwise it will always cause troubles and never be really > used. Upstream is still waiting for volunteers willing to work on some of those areas. The ifcfg format is pretty much covered thanks to Fedora/RHEL maintainers, but the ifupdown plugin is more or less orphaned.
The bad commit is cda65e18, from bug 693684; we were assuming that we could use the connection name as the interface name, but that's apparently not true (maybe only if you're using "ifscheme"?) The intent of that code is to make sure that if you have multiple devices, that the connection can only be activated on the one with the correct ifname. So, I guess the ifupdown parser needs to recognize that only the first part of the connection name corresponds to the interface name in this case.
@Pavel: Well I guess the Debian NM maintainers's POV is that they also have no interest in maintaining it (afaik)... This of course doesn't mean that this is what Debian as a whole wants,... actually Debian's NM maintainers (or better said people there involved in NM and GNOME) regularly have clashes with the rest of the community... see the infamous tech-ctte ruling on GNOME packages depending on NM... Anyway,... my point remains: NM should integrate with the actual native tools. And IMHO (which is of course not Debian's opinion),... software development is up to upstream and not to distro maintainers... and also... if such software integrates not with a distro, it should perhaps not be part of it... But that this discussion is moot. @Dan. Yeah, I recently went through a diff of the last working version I knew and the first that didn't.... and I also spotted that code... I doubt it's ifscheme specific,... since it works again, if I change the name to something <16 characters. Apart from that: ifscheme is actually as you said: the first part up to excluding the "-" is the iface name,... the remainder is a set of named connection with a set of settings. Well actually ifscheme is just one toolset for using the mapping stanza in /e/n/interfaces, quoting the interfaces(5) manpage: Stanzas beginning with the word "mapping" are used to determine how a logical interface name is chosen for a physical interface that is to be brought up. The first line of a mapping stanza consists of the word "mapping" followed by a pattern in shell glob syntax. Each mapping stanza must contain a script definition. The named script is run with the physical interface name as its argument and with the contents of all following "map" lines (without the leading "map") in the stanza provided to it on its standard input. The script must print a string on its standard output before exiting. See /usr/share/doc/ifupdown/exam‐ ples for examples of what the script must print. Mapping a name consists of searching the remaining mapping patterns and running the script corresponding to the first match; the script outputs the name to which the original is mapped. ifup is normally given a physical interface name as its first non-option argument. ifup also uses this name as the initial logical name for the interface unless it is accompanied by a suffix of the form =LOGICAL, in which case ifup chooses LOGICAL as the initial logi‐ cal name for the interface. It then maps this name, possibly more than once according to successive mapping specifications, until no further mappings are possible. If the resulting name is the name of some defined logical interface then ifup attempts to bring up the physical interface as that logical interface. Otherwise ifup exits with an error. Stanzas defining logical interfaces start with a line consisting of the word "iface" followed by the name of the logical interface. In simple configurations without mapping stanzas this name should simply be the name of the physical interface to which it is to be applied. (The default mapping script is, in effect, the echo command.) The interface name is followed by the name of the address family that the interface uses. This will be "inet" for TCP/IP networking, but there is also some support for IPX networking ("ipx"), and IPv6 networking ("inet6"). Following that is the name of the method used to configure the inter‐ face. Additional options can be given on subsequent lines in the stanza. Which options are available depends on the family and method, as described below. Additional options can be made available by other Debian packages. For example, the wireless-tools package makes avail‐ able a number of options prefixed with "wireless-" which can be used to configure the interface using iwconfig(8). (See wireless(7) for details.) Cheers, Chris.
[offtopic] Christoph: Please fix your broken keyboard to not constantly print three or four full stops when you wanted to write only one. Thank you.
@André: https://en.wikipedia.org/wiki/Ellipsis
(In reply to comment #7) > @Pavel: > Well I guess the Debian NM maintainers's POV is that they also have no interest in maintaining it (afaik)... Well in community developed software a feature that has no interested maintainers/developers is in danger of being unmaintained, damaged or even completely lost. I wish those users that want to actually use this feature to find someone to fix it for them, whether he's from the Debian or NetworkManager community. But I urge anyone to stop saying what open source developers should do in their work and/or free time, especially if that person is not going to actually help them. > This of course doesn't mean that this is what Debian as a whole wants,... If the Debian project wants to achieve something, it's up to the project members to work towards the goal and choose maintainers that will be up to the task. > actually Debian's NM maintainers (or better said people there involved in NM > and GNOME) regularly have clashes with the rest of the community... I don't think NetworkManager bugzilla is the best place to sort out Debian community issues. > Anyway,... my point remains: NM should integrate with the actual native tools. I'm afraid that the activity on the bug reports related to Debian native tools very clearly shows that nobody cares enough to do anything about it. > and also... if such software > integrates not with a distro, it should perhaps not be part of it... Again this is not something that can be solved in the upstream project. > But that this discussion is moot. Yes. Until you dig in the source code or hire your own developers, the only chance is to file bug reports and *hope* someone will be interested in fixing it. You can also take a chance to ask on IRC time by time, but again, the software is released for free, without any warranty, and with only community support.
Well I guess we don't have to continue discussing this bug forever on. IMHO, reporting issues is already a form of contribution, but yes, I do not have any desire to take part in NM development. I mean I've reported far too much issues (also non-ifupdown related, that never got really taken care of, that I could believe NM goes in any future-proof direction where it's worth to spend considerable efforts on) As for the philosophical background,... as I've said before, it's not so easy to say that NM upstream developers work on / ignore whatever they like. Especially since the groups behind NM actively try to integrated it wherever possible. See Debian, years ago, NM was basically just an optional thing, but now it's more or less necessary to install. Sure after the tech-ctte ruling it's possible to avoid it, but basically a lot of things are now simply artificially made such a way that they don't any longer work nicely without NM. And that's just the point why it's not so easy to say "oh we're just opensource and people only work on what they like"... if a group like NM starts to massively push for their product's integration, they can't just break existing setups... either that, or they should just let it be. And it's basically the same in all other places,... be it systemd or the kernel,... surely these respective upstreams also have some fields where they don't like to work upon (just take vt in the kernel), or where they'd like to break existing setups for their own good - but Linus will just curse anyone that breaks user land for no reason. As for NM, the points are basically still the same,... - NM is in no single field (neither Debian or any other distro, nor the respective network systems like dhcp, vpn, wpa, etc.) the real native tool - therefore it's not the duty of those systems (who even existed long before NM did) to fix issues and gain compatibility/integration. - even if NM would be the native tool, it is apparently in many fields far too buggy to be really a replacement for the other... e.g. I have bugs where for example a WPA-EAP connections fails every 10 minutes,... while the same connection, with the same parameters runs just fine forever with ifupdown (even though both use just wpa_supplicant)... or another issue, that I have to kill NM (and the applets) to reconnect to any WiFi once it has lost connection (or I've disconnected). So even if I'd wanted to just switch to NM, and dispose of all the real native tools... I couldn't simply because NM doesn't do the job. - not to talk, about the fact, that NM generally just maps a small subset of features available in the native toolsets, so when I e.g. use vpnc via NM, I loose several options which are very well possible with vpnc itself. And that's where NM is different from things like the kernel or systemd... the later also wants to replace the existing systems, but it provides everything necessary to really do so, and if something is missing or not working... they don't just point to the ones who were there long before, demanding them to fix the stuff which they've broke themselves... they rather fix it themselves. And yes, I'm fully aware how opensource works, and that most of us do this in their spare time... but that doesn't mean that anyone can come along, pushing *his* system to become more or less mandatory, and in the same place not fully supporting it and breaking existing systems. If further wouldn't say, that nobody cares... NM is surely one of the more controversial systems (not only in Debian) and especially in Debian it has been "reprimanded" before by the technical authorities. There actually *is* quite some user group who is not very happy about the basically non-existing integration of NM with native tools (especially Debian's native networking configuration system) and I'd guess it's just a matter of time till the tech-ctte makes another ruling on this.
the bug exists even if no one is currently working on a fix for it
Ah,... I thought the policy was to mark bugs which are not going to be fixed WONTFIX,... if not you might also reopen #681666, #681667 and #681668, which all deal with "integration deficiencies"... There were some further bugs in that area from other reporters, which have been closed as well as WONTFIX, but unfortunately I forgot their numbers.
(In reply to comment #11) > IMHO, reporting issues is already a form of contribution, but yes, I do not > have any desire to take part in NM development. I agree that reporting issues is a very valuable form of contribution and that in an ideal case it would lead to bugs getting analyzed and fixed. But that certainly requires interested developers. > See Debian, years ago, NM was basically just an optional thing, but now it's > more or less necessary to install. This bugzilla is not the right place to discuss policies and decisions of the Debian project. > but that doesn't mean that anyone can come along, pushing > *his* system to become more or less mandatory, I'm not aware of any fellow NetworkManager developers pushing NM to become mandatory nor promising any support for /etc/network/interfaces integration issues. > and I'd guess it's just a matter of > time till the tech-ctte makes another ruling on this. That would be great. I would especially welcome if Debian provided guidance for its users regarding /etc/network/interfaces support in NetworkManager and bugs related to it. (In reply to comment #13) > Ah,... I thought the policy was to mark bugs which are not going to be fixed > WONTFIX,... I proposed (some time ago) to close all remaining bugs related to the ifupdown plugin as well as any newly created bugs (except trivial ones or those with patches attached) and advise the people to file bugs specific to distributions with their respective distributions bug trackers. On the other hand, ifupdown is not strictly specific to Debian and anyone who would like to pick up the bugs is free to use the same bugzilla we use for all other NetworkManager issues.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).