| Message ID | 20190207144945.GA19874@Mindship-03 |
|---|---|
| State | New |
| Headers | show |
| Series | [netctl] Move away from using wpa_actiond | expand |
On Thu, 7 Feb 2019 at 14:50, Jouke Witteveen via arch-projects <arch-projects@archlinux.org> wrote: > > The same functionality is provided by wpa_supplicant, so we do not need > an extra and Arch Linux specific dependency. The introduction of wpa_actiond [1] hints there are issues with wpa_cli. Namely: - partial or missing logging capabilities - race conditions Sadly I don't know much more about this. It'll be great if can use wpa_cli, while not introducing new issues. -Emil [1] https://git.archlinux.org/wpa_actiond.git/commit/?id=c5c587771403d31ab4538e1c756e0b88a4641a92
On Fri, Feb 8, 2019 at 3:36 PM Emil Velikov <emil.l.velikov@gmail.com> wrote: > > On Thu, 7 Feb 2019 at 14:50, Jouke Witteveen via arch-projects > <arch-projects@archlinux.org> wrote: > > > > The same functionality is provided by wpa_supplicant, so we do not need > > an extra and Arch Linux specific dependency. > > The introduction of wpa_actiond [1] hints there are issues with wpa_cli. Namely: > - partial or missing logging capabilities > - race conditions > > Sadly I don't know much more about this. It'll be great if can use > wpa_cli, while not introducing new issues. > > -Emil > > [1] https://git.archlinux.org/wpa_actiond.git/commit/?id=c5c587771403d31ab4538e1c756e0b88a4641a92 Thanks! This detective work is highly appreciated! For some reason I had assumed wpa_cli would have gained this functionality only after wpa_actiond came into existence. This couldn't really explain why both use the same parameter names though... I wonder if the issues with wpa_cli have been taken upstream. In my experience, the maintainer of wpa_supplicant is very pleasant to work with. autowifi and, later, wpa_actiond are important parts of the history of netctl, but I tend to give over 10 years of development in wpa_supplicant the benefit of the doubt. This means I would like to try to move away from wpa_actiond anyway. Currently, except from those using wpa_actiond directly, I think netctl is the only user of wpa_actiond. @Thomas: do you have an oppinion in these matters? Thanks, - Jouke
On Sat, 9 Feb 2019 at 09:19, Thomas Bächler <thomas.baechler@gmx.de> wrote: > > Am 8. Februar 2019 20:17:52 MEZ schrieb Jouke Witteveen <j.witteveen@gmail.com>: > >On Fri, Feb 8, 2019 at 3:36 PM Emil Velikov <emil.l.velikov@gmail.com> > >wrote: > >> > >> On Thu, 7 Feb 2019 at 14:50, Jouke Witteveen via arch-projects > >> <arch-projects@archlinux.org> wrote: > >> > > >> > The same functionality is provided by wpa_supplicant, so we do not > >need > >> > an extra and Arch Linux specific dependency. > >> > >> The introduction of wpa_actiond [1] hints there are issues with > >wpa_cli. Namely: > >> - partial or missing logging capabilities > >> - race conditions > >> > >> Sadly I don't know much more about this. It'll be great if can use > >> wpa_cli, while not introducing new issues. > >> > >> -Emil > >> > >> [1] > >https://git.archlinux.org/wpa_actiond.git/commit/?id=c5c587771403d31ab4538e1c756e0b88a4641a92 > > > >Thanks! This detective work is highly appreciated! For some reason I > >had assumed wpa_cli would have gained this functionality only after > >wpa_actiond came into existence. This couldn't really explain why both > >use the same parameter names though... > >I wonder if the issues with wpa_cli have been taken upstream. In my > >experience, the maintainer of wpa_supplicant is very pleasant to work > >with. > > > >autowifi and, later, wpa_actiond are important parts of the history of > >netctl, but I tend to give over 10 years of development in > >wpa_supplicant the benefit of the doubt. This means I would like to > >try to move away from wpa_actiond anyway. Currently, except from those > >using wpa_actiond directly, I think netctl is the only user of > >wpa_actiond. > > > >@Thomas: do you have an oppinion in these matters? > > > >Thanks, > >- Jouke > > I honestly don't remember why wpa_cli was insufficient at the time and why I wrote wpa_actiond. That must have been way over 10 years ago. I just remember that my first attempt used wpa_cli, and something obvious was missing. I'd imagine Jouke has been running the patch for a bit and has not seen serious issues. Guess we could merge this and consider any issues as/if they arise? If it were me I would have kept the cosmetics separate, but it's nothing major so. - s/wpa_config/WPAConfigFile/ - RFKill && -> if RFKill; then Thanks for the work guys. -Emil
Hi team, On Sat, 9 Feb 2019 at 09:19, Thomas Bächler <thomas.baechler@gmx.de> wrote: > > Am 8. Februar 2019 20:17:52 MEZ schrieb Jouke Witteveen <j.witteveen@gmail.com>: > >On Fri, Feb 8, 2019 at 3:36 PM Emil Velikov <emil.l.velikov@gmail.com> > >wrote: > >> > >> On Thu, 7 Feb 2019 at 14:50, Jouke Witteveen via arch-projects > >> <arch-projects@archlinux.org> wrote: > >> > > >> > The same functionality is provided by wpa_supplicant, so we do not > >need > >> > an extra and Arch Linux specific dependency. > >> > >> The introduction of wpa_actiond [1] hints there are issues with > >wpa_cli. Namely: > >> - partial or missing logging capabilities > >> - race conditions > >> > >> Sadly I don't know much more about this. It'll be great if can use > >> wpa_cli, while not introducing new issues. > >> > >> -Emil > >> > >> [1] > >https://git.archlinux.org/wpa_actiond.git/commit/?id=c5c587771403d31ab4538e1c756e0b88a4641a92 > > > >Thanks! This detective work is highly appreciated! For some reason I > >had assumed wpa_cli would have gained this functionality only after > >wpa_actiond came into existence. This couldn't really explain why both > >use the same parameter names though... > >I wonder if the issues with wpa_cli have been taken upstream. In my > >experience, the maintainer of wpa_supplicant is very pleasant to work > >with. > > > >autowifi and, later, wpa_actiond are important parts of the history of > >netctl, but I tend to give over 10 years of development in > >wpa_supplicant the benefit of the doubt. This means I would like to > >try to move away from wpa_actiond anyway. Currently, except from those > >using wpa_actiond directly, I think netctl is the only user of > >wpa_actiond. > > > >@Thomas: do you have an oppinion in these matters? > > > >Thanks, > >- Jouke > > I honestly don't remember why wpa_cli was insufficient at the time and why I wrote wpa_actiond. That must have been way over 10 years ago. I just remember that my first attempt used wpa_cli, and something obvious was missing. After a bit of debugging I've noticed the move to wpa_cli broke my setup. Namely: wpa_cli does not reliably detect when the laptop resumes into another wireless network. Issue happens fairly intermittently - from once a week to multiple times a day - yet I have not seen it even once in the years of using wpa_actiond. Should I file a archlinux bug report, any suggestions how to proceed? Thanks Emil
On Thu, May 16, 2019 at 11:53 AM Emil Velikov <emil.l.velikov@gmail.com> wrote: > After a bit of debugging I've noticed the move to wpa_cli broke my setup. > Namely: wpa_cli does not reliably detect when the laptop resumes into > another wireless network. > Issue happens fairly intermittently - from once a week to multiple > times a day - yet I have not seen it even once in the years of using > wpa_actiond. Is this related to your wpa_actiond patch [1] to wait for three missing PONGs before failing? > Should I file a archlinux bug report, any suggestions how to proceed? It would be nice if you could gather some more details about the issue you are experiencing. Most likely, it indicates a bug in wpa_cli. In my experience, you are likely to get a helpful response over at the hostap mailing list. Regards, - Jouke [1] https://patchwork.archlinux.org/patch/230/
On Thu, 16 May 2019 at 13:19, Jouke Witteveen <j.witteveen@gmail.com> wrote: > > On Thu, May 16, 2019 at 11:53 AM Emil Velikov <emil.l.velikov@gmail.com> wrote: > > After a bit of debugging I've noticed the move to wpa_cli broke my setup. > > Namely: wpa_cli does not reliably detect when the laptop resumes into > > another wireless network. > > Issue happens fairly intermittently - from once a week to multiple > > times a day - yet I have not seen it even once in the years of using > > wpa_actiond. > > Is this related to your wpa_actiond patch [1] to wait for three > missing PONGs before failing? > Haven't confirmed (did not hack on wpa_cli yet) but I suspect they're different. The PONGs are required solely due to resource starvation - high memory/CPU/fd usage. While here we have a wifi network change across suspend/resume. > > Should I file a archlinux bug report, any suggestions how to proceed? > > It would be nice if you could gather some more details about the issue > you are experiencing. Most likely, it indicates a bug in wpa_cli. In > my experience, you are likely to get a helpful response over at the > hostap mailing list. > Dully noted, will do - thanks. -Emil
diff --git a/README b/README index 95df087..f3ca634 100644 --- a/README +++ b/README @@ -9,8 +9,8 @@ Optional: - dhcpcd or dhclient: for DHCP support - wpa_supplicant: for WPA support - dialog: for the interactive assistant -- ifplugd: for automatic connection -- wpa_actiond: for automatic connection +- ifplugd: for automatic wired connections +- ppp: for PPP support For documentation generation: - asciidoc diff --git a/contrib/PKGBUILD.in b/contrib/PKGBUILD.in index b5ce44c..f3359c6 100644 --- a/contrib/PKGBUILD.in +++ b/contrib/PKGBUILD.in @@ -15,7 +15,6 @@ optdepends=('dialog: for the menu based wifi assistant' 'dhcpcd: for DHCP support (or dhclient)' 'wpa_supplicant: for wireless networking support' 'ifplugd: for automatic wired connections through netctl-ifplugd' - 'wpa_actiond: for automatic wireless connections through netctl-auto' 'ppp: for PPP connections' 'openvswitch: for Open vSwitch connections' ) diff --git a/src/lib/auto.action b/src/lib/auto.action index f81d4e3..999f66f 100755 --- a/src/lib/auto.action +++ b/src/lib/auto.action @@ -5,16 +5,17 @@ . "$SUBR_DIR/ip" export INTERFACE="$1" -export SSID="$2" -export ACTION="$4" +export ACTION="$2" +PROFILE_STATE="$STATE_DIR/netctl-auto-$INTERFACE.profile" -load_profile "$3" load_interface_config "$INTERFACE" case $ACTION in - CONNECT) + CONNECTED) + load_profile "$WPA_ID_STR" DhcpcdOptions+=" -K -L" ip_set || exit 1 + echo "$Profile" > "$PROFILE_STATE" # Sandbox the eval if ! ( do_debug eval "$ExecUpPost" ); then # Failing ExecUpPost will take the connection down @@ -22,20 +23,16 @@ case $ACTION in exit 1 fi ;; - DISCONNECT) - # Sandbox the eval - if ! ( do_debug eval "$ExecDownPre" ); then - exit 1 + DISCONNECTED) + if [[ -s "$PROFILE_STATE" ]]; then + load_profile "$(< "$PROFILE_STATE")" + rm -f "$PROFILE_STATE" + # Sandbox the eval + if ! ( do_debug eval "$ExecDownPre" ); then + exit 1 + fi + ip_unset fi - ip_unset - ;; - LOST|REESTABLISHED) - # Not handled. - exit 0 - ;; - *) - # ??? - exit 1 ;; esac diff --git a/src/netctl-auto b/src/netctl-auto index 18d2e10..7e4062e 100755 --- a/src/netctl-auto +++ b/src/netctl-auto @@ -6,7 +6,6 @@ . "$SUBR_DIR/rfkill" . "$SUBR_DIR/wpa" -: ${ACTIOND:=wpa_actiond -p /run/wpa_supplicant} : ${ACTION_SCRIPT:=$SUBR_DIR/auto.action} @@ -193,11 +192,10 @@ list() { done } -## Start and generate config file for the WPA supplicant, start wpa_actiond +## Start and generate config file for the WPA supplicant, monitor for changes # $1: interface start() { local interface="$1" - local pidfile="$STATE_DIR/wpa_actiond-$interface.pid" if interface_is_up "$interface"; then exit_error "The interface '$interface' is already up" @@ -206,12 +204,11 @@ start() { rf_enable "$interface" "$RFKill" || return 1 fi - local wpa_conf - if ! wpa_conf=$(wpa_make_config_file "$interface"); then + if ! WPAConfigFile=$(wpa_make_config_file "$interface"); then exit_error "Could not create the configuration file for interface '$interface'" fi - # Disable p2p to prevent wpa_supplicant from creating another control interface. - echo "p2p_disabled=1" >> "$wpa_conf" + # Disable p2p to prevent wpa_supplicant from creating another control interface + echo "p2p_disabled=1" >> "$WPAConfigFile" local profile list_profiles | while IFS= read -r profile; do @@ -222,16 +219,16 @@ start() { is_yes "${ExcludeAuto:-no}" && exit # Set default and exclude wpa-config as it does not fit this scheme [[ ${Security:=none} != "wpa-config" ]] || exit - printf '%s\n' "network={" "$(wpa_make_config_block)" "id_str=\"$profile\"" "}" >> "$wpa_conf" + printf '%s\n' "network={" "$(wpa_make_config_block)" "id_str=\"$profile\"" "}" >> "$WPAConfigFile" report_notice "Included profile '$profile'" ) done - # Start the WPA supplicant and wpa_actiond + # Start the WPA supplicant and wpa_cli : ${WPADriver:=nl80211,wext} WPAOptions+=" -W" - if wpa_start "$interface" "$WPADriver" "$wpa_conf"; then - if $ACTIOND -i "$interface" -P "$pidfile" -a "$ACTION_SCRIPT"; then + if wpa_start "$interface" "$WPADriver" "$WPAConfigFile"; then + if wpa_call "$interface" -B -a "$ACTION_SCRIPT"; then return 0 fi wpa_stop "$interface" @@ -241,17 +238,16 @@ start() { return 1 } -## Stop the WPA supplicant and wpa_actiond +## Stop the WPA supplicant, which automatically stops wpa_cli # $1: interface stop() { local interface="$1" - local pidfile="$STATE_DIR/wpa_actiond-$interface.pid" - [[ -e "$pidfile" ]] && kill "$(< "$pidfile")" - timeout_wait 1 '! wpa_is_active "$interface"' || wpa_stop "$interface" + wpa_stop "$interface" bring_interface_down "$interface" - [[ $RFKill ]] && rf_disable "$interface" "$RFKill" - return 0 + if [[ $RFKill ]]; then + rf_disable "$interface" "$RFKill" + fi } ## Remove WPA supplicant configuration files