| Summary: | net-misc/netifrc does not support iwd | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Johannes Willem (Hans) Fernhout <hfern> |
| Component: | netifrc | Assignee: | netifrc Team <netifrc> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | athila.m.mattos, cedk, flyser42, gabriel, gabriele.svelto, halcon, henning, hfern, krinpaus, kripton, ne3dle, nishanth.gerrard, sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Basic /lib/netifrc/net/iwd.sh script | ||
|
Description
Johannes Willem (Hans) Fernhout
2019-07-27 08:49:00 UTC
Created attachment 586390 [details]
Basic /lib/netifrc/net/iwd.sh script
The attached iwd.sh seems to work reasonably well for both static IP addresses and DHCP. It works when it is simply installed in /lib/netifrc/net.
It requires in /etc/conf.d/net something like this (for interface wlp4s0 on phy0):
modules_wlp4s0="iwd"
config_wlp4s0="dhcp"
#config_wlp4s0="192.168.178.222/24"
iwd_wlp4s0="phy0"
Only issue observed so far is that on stopping the interface it complains with the following texts,probably because iwd already brings the interface down:
net.wlp4s0 |RTNETLINK answers: No such file or directory
net.wlp4s0 |Error talking to the kernel
Has there been any update regarding using iwd in Gentoo? The wiki (https://wiki.gentoo.org/wiki/Iwd) refers to this bug, but does not acknowledge the iwd.sh script as a potential solution. Hypoon, maybe you can try the script? Please confirm the results back here. Thanks. (In reply to Hans Fernhout from comment #1) > Created attachment 586390 [details] > Basic /lib/netifrc/net/iwd.sh script > > The attached iwd.sh seems to work reasonably well for both static IP > addresses and DHCP. It works when it is simply installed in /lib/netifrc/net. > > It requires in /etc/conf.d/net something like this (for interface wlp4s0 on > phy0): > modules_wlp4s0="iwd" > config_wlp4s0="dhcp" > #config_wlp4s0="192.168.178.222/24" > iwd_wlp4s0="phy0" > > Only issue observed so far is that on stopping the interface it complains > with the following texts,probably because iwd already brings the interface > down: > net.wlp4s0 |RTNETLINK answers: No such file or directory > net.wlp4s0 |Error talking to the kernel I don't have a setup for reproducing this. Can you capture it the interface going down with --verbose, so we can see exactly which command(s) trigger the message. There is prior work for cases where the interface vanished underneath netifrc. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/netifrc.git/commit/?id=c0f36e9995b6e07b6691fa0c2d5c3a13223f9815 commit c0f36e9995b6e07b6691fa0c2d5c3a13223f9815 Author: Hans Fernhout <hfern@fernhout.info> AuthorDate: 2020-05-31 05:27:16 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2020-05-31 05:29:36 +0000 net/iwd: add iwd helper Bug: https://bugs.gentoo.org/690808 Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> net/iwd.sh | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) (In reply to Robin Johnson from comment #4) > I don't have a setup for reproducing this. Can you capture it the interface > going down with --verbose, so we can see exactly which command(s) trigger > the message. > > There is prior work for cases where the interface vanished underneath > netifrc. Not sure where you did your commit and if it is available for me, but I tried it out with my original iwd helper script, and it works fine now. No error message on stop any more. Maybe the error on stop had something to do with https://bugs.gentoo.org/642774 ? Same error message. That bug is listed as in progress, but has a commit, so maybe it is solved? Once this is available for Gentoo users I will document the steps also in https://wiki.gentoo.org/wiki/Iwd#netifrc. This script works for me mostly. I downloaded the "iwd.sh" script from the netifrc.git repo: https://gitweb.gentoo.org/proj/netifrc.git/tree/net/iwd.sh?id=c0f36e9995b6e07b6691fa0c2d5c3a13223f9815 and dropped it in "/lib/netifrc/net/". In my "/etc/conf.d/net" I just put: > modules_wlp2s0="iwd" Finally in order for "/etc/init.d/net.lo" to load iwd I had to create this symlink: > ln -s /usr/libexec/iwd /usr/local/bin I get this warning/error on start: > start-stop-daemon: fopen '/run/iwd-wlp2s0.pid': No such file or directory But everything seems to working correctly as far as I can tell. Thanks for the feedback and reporting your test results. Not sure why you would need the symlink: the script provides the complete path to the iwd executable: local iwds=/usr/libexec/iwd . It works beautifully for me now with: 1) symlinking net.wlan0 to net.lo in /etc/init.d 2) adding the following to /etc/conf.d/net: modules_phy0="iwd debug" iwd_wlan0="phy0 debug" config_wlan0="dhcp" Adding the debug parameter may give additional information at startup and/or in syslog. Note that in my setup I have prevented interface renaming because iwd tends to delete the interface and create it fresh: # touch /etc/udev/rules.d/80-net-name-slot.rules If with these changes the error still exists, can you then attach the syslog output with the debug setting please? Thanks. I have set up everything as you specified:
1) net.wlan0 symlink
2) conf.d/net settings
3) udev rules
I found I also needed to have this in 'conf.d/net':
> modules_wlan0="iwd debug"
And I had to keep my symlink for '/usr/libexec/iwd' in '/usr/local/bin'. It's something to do with how '/etc/init.d/net.lo' calls '_program_available()'. I think something here is failing which prevents the module from loading and 'iwd_pre_start()' being called.
The error still exists, where should I look for the debug messages?
Not sure why you refer to /etc/init.d/net.lo calling something. The service should be started with: #rc-service net.wlan0 start Please attach the relevant portion of your syslog, from the moment where you start the service. The location of your syslog file might depend on which logger you have installed and how you have configured it. Syslog-ng puts it in /var/log/messages. Sorry, it's my first rodeo so bear with me. I'm running the service with: >rc-service net.wlan0 start I'm just refering to the script it symlinks to. I noticed while doing some debugging by echoing the loaded modules that at some point in the script 'iwd' gets dropped from the list and I think it has something to do with '_program_available()'. Perhaps that's a seperate issue. This is what I got from /var/log/messages, I'm using sysklogd, it doesn't appear to show any errors or debug messages: >Jun 6 13:30:05 thiyl syslogd[2099]: syslogd v2.1.2: restart. >Jun 6 13:30:05 thiyl crond[2127]: (CRON) STARTUP (1.5.4) >Jun 6 13:30:05 thiyl crond[2127]: (CRON) INFO (Syslog will be used instead of sendmail.) >Jun 6 13:30:05 thiyl crond[2127]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 75% if used.) >Jun 6 13:30:05 thiyl crond[2127]: (CRON) INFO (running with inotify support) >Jun 6 13:30:05 thiyl dhcpcd[2184]: dev: loaded udev >Jun 6 13:30:05 thiyl dhcpcd[2184]: no interfaces have a carrier >Jun 6 13:30:05 thiyl dhcpcd[2184]: forked to background, child pid 2207 >Jun 6 13:30:05 thiyl dhcpcd[2207]: eth0: waiting for carrier >Jun 6 13:30:05 thiyl dhcpcd[2207]: wlan0: waiting for carrier >Jun 6 13:30:05 thiyl dhcpcd[2207]: wlan0: carrier acquired >Jun 6 13:30:05 thiyl dhcpcd[2207]: DUID 00:06:13:4d:16:4c:29:c9:13:b3:a9:9c:89:3f:e5:db:ee:38 >Jun 6 13:30:05 thiyl dhcpcd[2207]: wlan0: IAID ea:ac:a3:14 >Jun 6 13:30:05 thiyl dhcpcd[2207]: wlan0: adding address fe80::865:e2ca:c4ed:5141 >Jun 6 13:30:05 thiyl dhcpcd[2207]: wlan0: carrier lost >Jun 6 13:30:05 thiyl dhcpcd[2207]: wlan0: deleting address fe80::865:e2ca:c4ed:5141 >Jun 6 13:30:06 thiyl dhcpcd[2448]: sending commands to master dhcpcd process >Jun 6 13:30:06 thiyl dhcpcd[2207]: control command: dhcpcd -m 3 wlan0 >Jun 6 13:30:06 thiyl dhcpcd[2207]: wlan0: carrier acquired >Jun 6 13:30:06 thiyl dhcpcd[2207]: wlan0: connected to Access Point `thiylwifi' >Jun 6 13:30:06 thiyl dhcpcd[2207]: wlan0: IAID ea:ac:a3:14 >Jun 6 13:30:06 thiyl dhcpcd[2207]: wlan0: adding address fe80::260e:2565:a959:9495 >Jun 6 13:30:07 thiyl dhcpcd[2207]: wlan0: soliciting an IPv6 router >Jun 6 13:30:07 thiyl dhcpcd[2207]: wlan0: rebinding lease of 192.168.178.168 >Jun 6 13:30:07 thiyl dhcpcd[2207]: wlan0: probing address 192.168.178.168/24 >Jun 6 13:30:12 thiyl dhcpcd[2207]: wlan0: leased 192.168.178.168 for 864000 seconds >Jun 6 13:30:12 thiyl dhcpcd[2207]: wlan0: adding route to 192.168.178.0/24 >Jun 6 13:30:12 thiyl dhcpcd[2207]: wlan0: adding default route via 192.168.178.1 >Jun 6 13:30:20 thiyl dhcpcd[2207]: wlan0: no IPv6 Routers available >Jun 6 13:30:20 thiyl dbus-daemon[2157]: [system] Activating service name='org.freedesktop.login1' requested by ':1.1' (uid=0 pid=2575 comm="/bin/login -- ") (using servicehelper) >Jun 6 13:30:20 thiyl dbus-daemon[2157]: [system] Successfully activated service 'org.freedesktop.login1' (In reply to Cid Kramer from comment #11) > Sorry, it's my first rodeo so bear with me. > > I'm running the service with: > >rc-service net.wlan0 start > > I'm just refering to the script it symlinks to. I noticed while doing some > debugging by echoing the loaded modules that at some point in the script > 'iwd' gets dropped from the list and I think it has something to do with > '_program_available()'. Perhaps that's a seperate issue. To trace the script, you may insert the following line into /etc/init.d/net.lo, anywhere after the first line containing the openrc-run shebang: exec 2> >(ts >> /tmp/net-runscript.log); set -x This particular approach requires that /bin/sh point to bash, which is the default state of affairs in Gentoo. You should also emerge moreutils to obtain the ts utility. Come to think of it, the trace will be easier to follow in the case that PS4 is customised. Hence: PS4='+$BASH_SOURCE:$LINENO: ' exec 2> >(ts >> /tmp/net-runscript.log); set -x Thank you, Kerin, for looking into this. The tracer doesn't seem to be working correctly. I inserted the two lines you suggested into /etc/init.d/net.lo but I got this while trying to restart the service. atrodrig-t470s ~ # rc-service net.wlan0 restart * Caching service dependencies ... /etc/init.d/net.br0: line 8: syntax error near unexpected token `>' /etc/init.d/net.br0: line 8: `exec 2> >(ts >> /tmp/net-runscript.log); set -x' /etc/init.d/net.lo: line 8: syntax error near unexpected token `>' /etc/init.d/net.lo: line 8: `exec 2> >(ts >> /tmp/net-runscript.log); set -x' /etc/init.d/net.wlan0: line 8: syntax error near unexpected token `>' /etc/init.d/net.wlan0: line 8: `exec 2> >(ts >> /tmp/net-runscript.log); set -x' [ ok ] /etc/init.d/net.wlan0: line 8: syntax error near unexpected token `>' /etc/init.d/net.wlan0: line 8: `exec 2> >(ts >> /tmp/net-runscript.log); set -x' * ERROR: net.wlan0 failed to stop So I rewrote it like this: PS4='+$BASH_SOURCE:$LINENO: ' exec 2> ts >> /tmp/net-runscript.log; set -x And here's the output of /tmp/net-runscript.log: atrodrig-t470s ~ # cat /tmp/net-runscript.log * Bringing down interface wlan0 * Stopping dhcpcd on wlan0 ... [ ok ] * Stopping iwd on wlan0 ... [ ok ] * Bringing up interface wlan0 * Assigned PHY to be phy0 * Starting iwd on phy0 and wlan0 ... * Detaching to start `/usr/libexec/iwd' ... * dhcp ... * Running dhcpcd ... [ ok ] * received address 192.168.1.21/24 [ ok ] is this helpful? (In reply to Athila Mattos from comment #14) > Thank you, Kerin, for looking into this. > The tracer doesn't seem to be working correctly. > I inserted the two lines you suggested into /etc/init.d/net.lo but I got > this while trying to restart the service. > > atrodrig-t470s ~ # rc-service net.wlan0 restart > * Caching service dependencies ... > /etc/init.d/net.br0: line 8: syntax error near unexpected token `>' > /etc/init.d/net.br0: line 8: `exec 2> >(ts >> /tmp/net-runscript.log); set I can't account for this. The format of the error message implies that /bin/sh is linked to bash and the given syntax is certainly valid for bash, at least in isolation. One possibility is the script was mis-edited and that there is some surrounding context (not yet shown) that confuses the parser. > So I rewrote it like this: > > PS4='+$BASH_SOURCE:$LINENO: ' > exec 2> ts >> /tmp/net-runscript.log; set -x This would have directed STDERR to a file named "ts", rather than "/tmp/net-runscript.log", as was intended. If we are to forgo the use of the ts utility, it can be written as follows. PS4='+$BASH_SOURCE:$LINENO: ' exec 2>> /tmp/net-runscript.log; set -x The only material difference is that there will be no timestamps in the resulting log file. > > And here's the output of /tmp/net-runscript.log: > > atrodrig-t470s ~ # cat /tmp/net-runscript.log > * Bringing down interface wlan0 > * Stopping dhcpcd on wlan0 ... [ ok ] > * Stopping iwd on wlan0 ... [ ok ] > * Bringing up interface wlan0 > * Assigned PHY to be phy0 > * Starting iwd on phy0 and wlan0 ... > * Detaching to start `/usr/libexec/iwd' ... * dhcp ... * Running > dhcpcd ... [ ok ] > * received address 192.168.1.21/24 > [ ok ] > > is this helpful? No, because STDERR wasn't directed to this particular file (see above). Hi, Kerin, Thank you for the explanation. I followed your advice and I removed the usage of 'ts' from the parser, and I have uploaded the file here: https://0bin.net/paste/fVq2Y9hg#O0ALntfKFZ6d2QZPv4rYNpSlnuzubrd9NHGfoA2FOy0 ^ this is set to expire in 1 month. I can send you or attach it here, not sure what is the best way to collaborate here. Nevertheless, thank you for the guidance here. (In reply to Athila Mattos from comment #16) > Hi, Kerin, > > Thank you for the explanation. > > I followed your advice and I removed the usage of 'ts' from the parser, and > I have uploaded the file here: > > https://0bin.net/paste/fVq2Y9hg#O0ALntfKFZ6d2QZPv4rYNpSlnuzubrd9NHGfoA2FOy0 > > ^ this is set to expire in 1 month. I can send you or attach it here, not > sure what is the best way to collaborate here. > > Nevertheless, thank you for the guidance here. Sorry, Athila - this flew under the radar somehow. Indeed, if you could attach it, that would be helpful. Otherwise, externally hosted content inevitably expires, as has happened in this case. (In reply to Kerin Millar from comment #17) > (In reply to Athila Mattos from comment #16) > > Hi, Kerin, > > > > Thank you for the explanation. > > > > I followed your advice and I removed the usage of 'ts' from the parser, and > > I have uploaded the file here: > > > > https://0bin.net/paste/fVq2Y9hg#O0ALntfKFZ6d2QZPv4rYNpSlnuzubrd9NHGfoA2FOy0 > > > > ^ this is set to expire in 1 month. I can send you or attach it here, not > > sure what is the best way to collaborate here. > > > > Nevertheless, thank you for the guidance here. > > Sorry, Athila - this flew under the radar somehow. Indeed, if you could > attach it, that would be helpful. Otherwise, externally hosted content > inevitably expires, as has happened in this case. (CCed Athila.) A workaround for me was adding "!wpa_supplicant" to "modules_wlan0=". Adding it to plain "modules=" didn't work. i.e.: 'modules_wlan0="iwd debug !wpa_supplicant"' |
