https://github.com/ppp-project/ppp/commit/610a7bd76eb1f99f22317541b35001b1e24877ed
https://wiki.archlinux.org/index.php?title=Ppp&diff=696210&oldid=696209
The change was back in 2021 and the compatibility shim was removed in pppd 2.5.0
Thanks for this merge request! I missed it because it was not assigned to me. I have updated my notification settings so that I would catch these in the future. In the meantime, the fix was applied independently.
Jouke Witteveen (354d325e) at 08 Oct 14:35
Do not use SAE (WPA3) when client hardware lacks support
Jouke Witteveen (ad085552) at 08 Oct 14:29
1.29 release updates
https://github.com/ppp-project/ppp/commit/610a7bd76eb1f99f22317541b35001b1e24877ed
https://wiki.archlinux.org/index.php?title=Ppp&diff=696210&oldid=696209
The change was back in 2021 and the compatibility shim was removed in pppd 2.5.0
Thanks for mentioning the type of your AP! After a little search on the web, I have an idea of what you might be seeing. Your AP might be advertising support for WPA3 without Management Frame Protection (MFP), even though MFP is mandatory for the variant of WPA3 that we are targeting here. Combined with the fact that your network card possibly does not support MFP, we end up in a situation where wpa_supplicant
will try to set up a WPA3-secured connection, but is not able to. With the bare wpa_supplicant
configuration, you are only ever using WPA2.
Can you try the following for me?
echo "sae_check_mfp=1" >> "$config_file"
below line 210 in /usr/lib/netctl/wpa
.wpa_supplicant
from git (I used wpa_supplicant-git
from the AUR, but had to remove -Werror
from src/hostap/wpa_supplicant/Makefile
for it to compile).If it works with these changes, I finally have a good reason for another netctl
update :-). Unfortunately, it will rely on the next version of wpa_supplicant
.
As a workaround until this is fixed, there are a few things you could do:
Security=wpa-configsection
WPAConfigSection=(
'ssid="[YOUR_SSID]"'
'key_mgmt=WPA-PSK'
'psk="[YOUR_PASSWORD]"'
)
Added 2020-10-09 11:41:37 UTC - Commented by Jouke Witteveen (jouke)
The "-L" option was in my suggestion merely because it is added by default if no DhcpcdOptions= are provided. So if you provide dhcpcd options manually and want to mimic the default config, you should add it. If you have no use for it, you can leave it out, but for debugging the fallout of your changes, this is not advised.
The problem I see with your suggestion is that it will be very hard to implement for dhclient. As you mention yourself, dhclient would require changes to its configuration file, which netctl will not touch.
Added 2023-08-08 19:11:45 UTC - Commented by Buggy McBugFace (bugbot)
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.
Added 2020-09-11 04:55:51 UTC - Commented by brent saner (sanerb)
Whoops, apologies for the delay... I somehow missed the notification on your comment, Jouke.
This (sort of- see #3) works for dhcpcd, yes, but:
1.) It is a bit more clumsy with dhclient on the configuration end
2.) It would be nice to have this parity with PPPOE and MOBILE_PPP connections' DefaultRoute=false
at the least, and
3.) dhcpcd's -L option is to ignore Link-Local, which is not the same as RFC 3442 routes. (Link-Local/LL is the 169.254.0.0/16 prefix in IPv4, which is used by Bonjour/ZeroConf/etc., not additional static routes pushed by a DHCP lease).
Of course, the IPv6 equivalents would be perhaps to ignore RAs (link-local is ...a little different in IPv6, as the router does not determine/advertise the prefix - it's hardcoded to spec). This is already possible for IPv6 by using static
or no
values for IP6=
.
Added 2019-12-25 12:47:40 UTC - Commented by Jouke Witteveen (jouke)
Thanks for your report. Patches are welcome. What you could do is include the following in your profile: DhcpcdOptions="-L -G"
Would that do what you want?
Added 2019-11-26 20:26:58 UTC - Commented by brent saner (sanerb)
Correction:
"This is different from the 'default route' or 'gateway' option ('routes', option 3)."
should be:
"This is different from the 'default route' or 'gateway' option ('routers', option 3)."
Task Info (Flyspray) | |
---|---|
Opened By | brent saner (sanerb) |
Task ID | 64651 |
Type | Feature Request |
Project | Arch Linux |
Category | Arch Projects |
Version | None |
OS | All |
Opened | 2019-11-26 11:23:40 UTC |
Status | Assigned |
Assignee | Jouke Witteveen (jouke) |
Description: I would like to suggest adding support for a DefaultRoute=(true|false) configuration options for connection types ethernet and wireless, in addition to an IgnoreRoutes=(true|false) option.
dhcpcd has the -G flag for this, at least for ignoring a default route, but unfortunately dhclient does not. It can, however, be supported by a dhclient.conf file and accompanying script (by not requesting the "routers" DHCP option, option 3).
This has the added benefit of providing an in-band resolution to this bug: https://wiki.archlinux.org/index.php/Netctl#RTNETLINK_answers:File_exists(with_multiple_NICs) as one can simply ignore the default route on additional NICs.
IgnoreRoutes would ignore all RFC 3442 routes in the DHCP lease (by not requesting the "rfc3442-classless-static-routes" DHCP option, option 121). This is different from the "default route" or "gateway" option ("routes", option 3).
Added 2022-09-08 07:31:46 UTC - Commented by Jouke Witteveen (jouke)
Re. P.S.: The package is marked as orphan because I (the current maintainer) am not an official Arch Packager. Despite what some people think, I am still interested in maintaining netctl!
Currently, netctl-wait-online indeed does not work with netctl-auto, because netctl-auto does not (and cannot, really) interact with systemd to retain a proper state for the profile services. It might even not be a very good idea to want to combine the two programs, since in a typical netctl-auto use case, you might not come online at all. Effectively, you then rely on netctl-wait-online to time-out, which feels wrong to me.
That being said, I do think there is room for improvement. The systemd service for netctl-auto is a simple forking service. It could be possible to add some smartness there and either notify of state changes (this necessitates the netctl-auto process to be around for longer than it is now), or to add some control of when the netctl-auto process finishes. We could probably add a conditional wait on wpa_supplicant to connect (but this on its own doesn't guarantee a routable connection).
An easier solution would maybe be to add a netctl-auto-wait-online service that just polls wpa_supplicant. The same caveats as above apply, but everything needed for this should be in place already. Patches are welcome, I'm happy to help in their production!
Added 2022-09-08 07:29:15 UTC - Commented by Yuri Kanivetsky (x-yuri)
I'm not an expert at netctl myself, but there doesn't seem to be automatic profiles. It's about the way they are enabled.
Let's say you have a wireless profile. You can enable it with netctl enable PROFILE
. That will enable netctl@.service that will start (connect) the profile on boot.
The other option is to systemctl enable netctl-auto@.service
. That will start (connect) one of your profiles on boot (it will choose/decide). To quote the documentation, "Every time the netctl-auto service is started, all available profiles are enabled by default."
https://man.archlinux.org/man/core/netctl/netctl-auto.1.en
The only thing that makes me think about automatic profiles is that netctl-auto probably doesn't work with wired profiles. I'm not sure.
Also, netctl-auto has the enable command. And generally, from user perspective it makes sense for netctl to at least try once to connect to some network before reaching the network-online.target.
At least that's my understanding.
Added 2022-09-08 07:06:26 UTC - Commented by Toolybird (Toolybird)
Not familiar with netctl myself, but in fairness, the description for netctl-wait-online service says "Wait for the enabled netctl profiles to come online" which means it might only work for enabled profiles and not the automatic ones?
PS - this pkg is currently marked Orphan? Will assign to original author and see what happens.
Task Info (Flyspray) | |
---|---|
Opened By | Yuri Kanivetsky (x-yuri) |
Task ID | 75836 |
Type | Bug Report |
Project | Arch Linux |
Category | Arch Projects |
Version | None |
OS | All |
Opened | 2022-09-07 07:14:13 UTC |
Status | Assigned |
Assignee | Jouke Witteveen (jouke) |
Additional info:
Steps to reproduce:
netctl disable
all profiles.What I see:
Sep 07 08:52:46 yuri2 systemd[1]: Starting Wait for the enabled netctl profiles to come online... Sep 07 08:52:46 yuri2 systemd[1]: Finished Wait for the enabled netctl profiles to come online. Sep 07 08:52:46 yuri2 systemd[1]: Starting Refresh Pacman mirrorlist with Reflector.... Sep 07 08:52:46 yuri2 reflector[422]: error: failed to retrieve mirrorstatus data: URLError: <urlopen error [Errno -3] Temporary failure in name resolution> Sep 07 08:52:46 yuri2 systemd[1]: reflector.service: Main process exited, code=exited, status=1/FAILURE Sep 07 08:52:46 yuri2 systemd[1]: reflector.service: Failed with result 'exit-code'. Sep 07 08:52:46 yuri2 systemd[1]: Failed to start Refresh Pacman mirrorlist with Reflector.. Sep 07 08:52:48 yuri2 systemd[1]: Starting Automatic wireless network connection using netctl profiles... Sep 07 08:52:48 yuri2 netctl-auto[619]: Included profile 'wlo1-yuri' Sep 07 08:52:49 yuri2 systemd[1]: Started Automatic wireless network connection using netctl profiles. Sep 07 08:52:53 yuri2 dhcpcd[1122]: dhcpcd-9.4.1 starting Sep 07 08:52:53 yuri2 dhcpcd[1125]: DUID xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx Sep 07 08:52:53 yuri2 dhcpcd[1125]: wlo1: connected to Access Point: yuri Sep 07 08:52:53 yuri2 dhcpcd[1125]: wlo1: IAID xx:xx:xx:xx Sep 07 08:52:54 yuri2 dhcpcd[1125]: wlo1: rebinding lease of xx.yy.xx.yy Sep 07 08:52:54 yuri2 dhcpcd[1125]: wlo1: probing address xx.yy.xx.yy/24 Sep 07 08:53:00 yuri2 dhcpcd[1125]: wlo1: leased xx.yy.xx.yy for 600 seconds Sep 07 08:53:00 yuri2 dhcpcd[1125]: wlo1: adding route to xx.yy.xx.yy/24 Sep 07 08:53:00 yuri2 dhcpcd[1125]: wlo1: adding default route via xx.yy.xx.yy
Added 2023-08-08 19:11:45 UTC - Commented by Buggy McBugFace (bugbot)
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.
Added 2020-10-09 10:37:30 UTC - Commented by Jouke Witteveen (jouke)
To be honest, I don't know why sys-subsystem-net-devices-lag0.device times out. I agree that there should be no reason for the system (udev?) to delay bringing up the device when an fsck is being run. Unfortunately, I can't think of any solution other than to increase your timeout values (but I am not certain which are involved here). If you ever learn more about this issue and have an idea on how it can be addressed, I would love to hear from you!