After recent upgrade to =net-misc/netifrc-0.7.1, which was marked stable on arm64, a wlan interface that was configured in AP mode, such as: config_wlan0="192.168.0.XXX/24" modules_wlan0="!iwconfig !wpa_supplicant" mode_wlan0="master" can no longer be brought up: /etc/init.d/net.wlan0 start net.wlan0 | * Caching service dependencies ... [ ok ] net.wlan0 | * Bringing up interface wlan0 net.wlan0 | * Configuring wireless network for wlan0 net.wlan0 | * Please use hostapd to make this interface an access point net.wlan0 | * Failed to configure wireless for wlan0 net.wlan0 | * ERROR: net.wlan0 failed to start Reverting to the previous stable version of netifrc, netifrc-0.5.1 fixes the problem. The wlan0 device is used with hostapd to serve as an access point for clients. Reproducible: Always Steps to Reproduce: 1. Upgrade your netifrc package to version 0.7.1 2. Try to start the interface with: /etc/init.d/net.wlan0 start With the configuration for AP mode, from the description above. 3. See how it fails to bring up the interface Actual Results: device failed to start Expected Results: device started successfully
Please attach emerge --info.
..and paste the emerge info as described on https://wiki.gentoo.org/wiki/Attach_the_logs_to_the_bug_ticket Please reopen this ticket (Status:UNCONFIRMED) afterwards.
Created attachment 632948 [details] emerge --info output emerge --info output attached.
I found out, that iw is used to configure the device, now, which doesn't understand the option "master" as mode. Workaround, use another module to configure wifi, i.e. ifconfig: modules_wifi0="!wpa_supplicant !iproute2 !iwconfig !iw ifconfig" This bug is confirmed on my system, so reopen, pls.
second that request. I use the following entry in /etc/conf.d/net: ``` modules="iproute2 !iwconfig !wpa_supplicant" config_eth1="null" rc_net_eth1_provide="!net" config_wlan0="null" rc_net_wlan0_provide="!net" rc_net_br0_need="hostapd" bridge_br0="eth1 wlan0" bridge_forward_delay_br0=0 bridge_hello_time_br0=1000 bridge_stp_state_br0=1 config_br0="192.168....." ``` This has worked well for many years, until netifrc-0.7.1 Booting with this version causes the wifi adapter to be started in client mode, as I discovered after connecting a serial console to my headless box. After adding the line `mode_wlan0="master"` as suggested by the install I saw the same message being returned as quoted in the opening post. `Please use hostapd...` Well now that's the whole point. That's what it was supposed to do and what previous versions did. Please revert whatever causes this drastic change in interpreting the `net` config (or rather: ignoring it).
Shamefully there appears to be no action from the people that are supposed to handle this case seriously. I have done some further research and the culprit turns out to be a newly created module named `iw` - don't know how that acts different from the earlier existing `iwconfig` module - that intercepts control over the wifi interface before hostapd gets its turn. It is my conclusion that there are in fact TWO bugs connected to this newly added module: 1) failure of the newly added module to recognize that there is no sense in trying to connect to a remote access point if the interface has been given a `null` assignment. This is of course also true for the already existing modules, requiring them to be disabled in the config file, however that was the status quo and hence does not count, nor should it have been used as an example of what is the right way to handle it. 2) which brings us to the second bug, which is failure (by the development team) to recognize that wifi adapters can and are in fact also used in AP mode and thus not finding it necessary to document a software change that requires user action to allow the AP mode to keep functioning. Which is why we have portage news. Which to this date still does not contain any warning with regard to this pretty nasty bug. I am expecting response from the development team this time. Should again this NEEDINFO follow-up be ignored I will use the info from this post to file it as a new bug to surpass your apparent ignore list.
It's plain to the discerning eye that netfirc is neither well tested nor particularly well maintained. I forked it off recently and fixed a few bugs, such as the apipa.sh module being horribly written and not actually working at all - as revealed by nerdboy - and bug 528314, which is going on six years old now. The code is largely unpleasant to work with although that's partly due to the decision to target POSIX sh (yet failing to conform). In my view, this decision is a historical mistake. Netifrc has no uptake outside of Gentoo and the code would be easier to maintain and more robust if it were to target bash and be re-factored to that end. But I digress. I'm willing to investigate this issue more closely if nobody else will. In order to do so efficiently, I would need to communicate directly with someone affected by the issue. In particular, I would call on cilly to contact me if still affected and interested, for the simple reason that we have spoken before.
I consider this a failure of documentation primarily. There is this note in doc/net.example.Linux.in: # If you're using anything else to configure wireless on your interface AND # you have installed wpa_supplicant, you need to disable wpa_supplicant #modules="!iwconfig !wpa_supplicant" #or #modules="!wireless" 1. This should have been updated to include !iw 2. It should have been clearer up-front that if you used `mode_IFVAR=master`, with EXTERNAL configuration, then modules="!wireless" was probably what you wanted, rather than `modules_wlan0="!iwconfig !wpa_supplicant"` So what combination of the following makes the most sense here? a) Make iw_configure `return 0` if mode==master? b) Try to detect hostapd? c) Fix the documentation to make !wireless a LOT clearer? What I don't understand is that net/iw was added in 0.6.0, and you're only reporting this against 0.7.1. Did nobody else test this in the meantime?
(In reply to Robin Johnson from comment #8) > What I don't understand is that net/iw was added in 0.6.0, and you're only > reporting this against 0.7.1. Did nobody else test this in the meantime? This is probably explained by "amd64" users having upgraded from 0.5.1 to 0.7.1 without experiencing any of the three intervening releases. The prevalence of ~arch users with a propensity for finding and reporting somewhat nuanced bugs may not be as great as expected.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/netifrc.git/commit/?id=51a7c4fae619a05b8f179f5f03b3e8a556df7205 commit 51a7c4fae619a05b8f179f5f03b3e8a556df7205 Author: Robin H. Johnson <robbat2@gentoo.org> AuthorDate: 2020-06-02 21:35:31 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2020-06-02 21:35:31 +0000 doc/net.example.Linux: document !wireless better Users that used layer2 wireless configuration external to netifrc and had previously configured netifrc with: `modules="!iwconfig !wpa_supplicant"` were surprised by the introduction of the iw & iwd modules, because the modules tries to auto-configure the wireless interfaces. Document that `modules="!wireless"` is a better configuration knob for this situation. Bug: https://bugs.gentoo.org/717226 Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> doc/net.example.Linux.in | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)
I've documented that modules="!wireless" is better for this situation, but would ALSO appreciate if somebody could test changing the "return 1" to "return 0" in case master mode was detected, and see if it makes it "just work (TM)".
Returning to this thread, noticing that for some reason my earlier submit to be included in the CC list had failed. @Kerin Millar #7: to my knowledge netifrc has always been gentoo's choice for managing network settings, at least until graphic desktop managers started to aggressively request systemd to be used as the OS init system. As I guess that most systems will be GDM enabled I suppose there is some logic that netifrc could have lost active maintenance, but I am somewhat puzzled by your remark that kind of states that it was always beta software to start with. @Robin Johnson #8: Agreed, documentation appears to be key with this issue. I was in fact never aware of the "wireless" short-hand replacement for specifying the earlier existing modules iwconfig and wpa_supplicant, but it seems logical that this was added some time later than the modules themselves. Interestingly the alternate suggested configuration in the documentation to specify "mode=master" in netifrc has in my case always returned a message that I needed to use hostapd to achieve that. Is there actually anyone who has ever been able to make that work? @Kerin Millar #9: My target system is actually arm, but yes it is configured for "stable" packages only and the 0.6.x versions have never been marked as such. Another consideration here is that netifrc originally did not run with systemd and I'd dare bet that most if not all of the people willing to run beta use GDM enabled systems with systemd. @Robin Johnson #11: There is actually a nasty circular dependency here and this appears to be particularly the case when the wifi adapter running in AP mode is part of a bridge. As stated, specifying mode=master seems to mostly return a message to use hostapd (I have found multiple reports on this), but the hostapd service has a dependency on 'net' and that of course then wants to start the wifi adapter in client mode. Interestingly when I tested this bug on a development machine I was actually able to start AP mode, though there was a huge delay during boot. Turned out that one of my neighbours has an open network "in vision" of that side of my house, allowing netifrc to complete without errors and thus hostapd to start. But why does netifrc return an error on a null configured adapter that is also specified to not provide 'net'? That is the thing that makes no sense whatsoever.
(In reply to Gordon Bos from comment #12) > @Kerin Millar #7: to my knowledge netifrc has always been gentoo's choice > for managing network settings, at least until graphic desktop managers > started to aggressively request systemd to be used as the OS init system. As > I guess that most systems will be GDM enabled I suppose there is some logic > that netifrc could have lost active maintenance, but I am somewhat puzzled > by your remark that kind of states that it was always beta software to start > with. In point of fact, I did not state that it was beta software to start with. Rather, that it is now in a state of heading toward disrepair. I am puzzled that you would be puzzled, having earlier posted that this bug was, shamefully, as you put it, not being given the attention it deserved and threatening to file duplicating bugs in order to initiate a response. If anything, that rather underlines my point. I don't feel any need to defend my position for two reasons. Firstly, the evidence is available to anyone who would scrutinise the recent bug history, the code at large and - importantly - who would thoroughly test it. Not in the "works on my machine for some narrowly defined use case" sense but in the sense of actively testing the full range of features that netifrc offers under all ostensibly supported shells. Secondly, at about the same time that Robin stepped in on this particular bug, he had just been appointed the project lead and was obviously in the process of reviewing the outstanding bug queue at large. This is good news for anyone that uses netifrc. I know Robin to be a conscientious developer and anticipate that it will now be much easier to get bugs addressed. That is all.
