Trigger action when wireless network event

Yann · 2020-12-07 19:18:54

Hi everyone,

I would like to run a script any time there is a wifi event/change. I mostly would like to update the status bar. How should I do that ? Systemd, udev, acpid, other ?

I have seen that the wpa_supplicant@XXX.service service gets aware of some events. How can I get a script run when there is a wifi change ?

Thanks for your time.

Yann · 2020-12-20 13:30:01

After further researches, udev and acpid don't seem to permit that. The wpa service seems to be the best option.
But how can I get a script to be run at wireless event ?

Slithery · 2020-12-20 16:17:36

What are you using to manage your networking?

Yann · 2020-12-20 16:30:14

wpa_supplicant. I don't use NetworkManager.

mozurin · 2020-12-20 17:22:44

wpa_cli action script might be the one...?

Yann · 2020-12-20 17:44:42

Well. This looks very interesting indeed. Thanks.

So I should put in my login .bash_profiles script the following line ?

wpa_cli -i wlp59s0 -a wpa_events.sh &

I can not specify it directly in the wpa_supplicant conf ? As it is an enabled daemon.

Last edited by Yann (2020-12-20 17:45:08)

Trilby · 2020-12-20 18:41:15

No that should not be in your bash profile if you want it to just run under X. Perhaps xinitrc could work. Alternatively a service file to run this could work (but again, if it's just for in X, a service file would not be a very good idea unless you already run your X session through a systemd user service).

Yann · 2020-12-20 18:56:58

Indeed, I am interested to trigger actions on the X server. If I put it in .xinitrc, the wpa_cli process will remain alive even if X stops, right ? I don't see the difference of behavior between .xinitrc and .bash_profile.

seth · 2020-12-20 19:50:29

You'll not start it in cli sessions and you'll have the proper $DISPLAY for the server exported.
Also if you don't exec the session binary, you can easily store the PID of wpa_supplicant and kill it after the session binary terminates.

Yann · 2020-12-20 20:40:31

Indeed, did not think about the $DISPLAY variable. So I have to run that command after X is started, such as the .xinitrc file. What is the "session binary", I am not sure to understand.

seth · 2020-12-20 21:23:39

How do you start X11? What does your xinitrc look like?

Yann · 2020-12-20 21:34:04

Start X11

[[ $(tty) == '/dev/tty1' ]] && startx

.xinitrc

#!/bin/bash

# X keyboard fr
#setxkbmap fr

XMODMAP_PATH=$MHOME/.Xmodmap
if [ -f "$XMODMAP_PATH" ]; then
  xmodmap "$XMODMAP_PATH"
fi

XRESOURCES_PATH=$MHOME/.Xresources
if [ -f "$XRESOURCES_PATH" ]; then
  source "$XRESOURCES_PATH"
fi

# Unlock numluck key
numlockx &

# Xhost display
xhost +

# Dpms (Display Power Management Signaling)
xset dpms $X_STANDBYTIME $X_SUSPENDTIME $X_OFFTIME

# Set the dns servers to the /etc/resolv.conf file
# Use resolvconf to copy the content of resolv.conf.head to resolv.conf
sudo resolvconf -u

# Notification daemon
dunst &

# Execute picom
picom &

# Update graphic confs
displayup

# update wallpaper
source $MHOME/dev/bash/wallpaper_up.sh

export XDG_SESSION_TYPE=x11

exec i3

seth · 2020-12-20 21:39:04

exec i3

i3 is the session binary (because the session will close with it, or rather would if you'd also "exec startx")

Unrelated sidenote, try to get rid of the "xhost +" call - whatever it's supposed to fix, that's not a good fix for anything.

Yann · 2020-12-20 22:03:45

I removed the "xhost +", not sure to remember what it was supposed to fix.

So, when you say session, it's the graphical session, right ? In my case, if i3 gets closed, it will close X11 too ?

seth · 2020-12-21 07:23:33

if i3 gets closed, it will close X11 too

X11 will be "closed" once "xinit" end and it ends when the xinitrc ends or when "exec i3" replaces the "xinit" process, when i3 ends.

Trilby · 2020-12-21 13:54:17

When the startx/i3 process(es) end, all child processes (e.g., all those started in xinitrc) are sent a SIGTERM or SIGHUP - I forget which off the top of my head, I think it's SIGHUP.

If the wpa_cli process responds to this signal it may then terminate. But if it doesn't, it will still be running and the script it runs will simply fail. Even if this is the case, it makes more sense to start launch the wpa_cli process from xinitrc as doing it in your bash profile will mean it will definitely still run after X exists, and it will run before X starts, and most importantly, it will not inherit the DISPLAY variable which if not inherited by the action script will cause the script to fail even while X is running.

The ideal approach depends a bit on how likely you are to exit X11 without shutting down your system and also how likely you are to restart X11. If you are likely to restart X11, you'd just want to make sure there aren't two wpa_cli daemons running, perhaps with something like the following in your xinitrc:

pgrep wpa_cli || wpa_cli -a /path/to/script

Of course there may be other gotchas as I'm not sure if the environment will automatically be inherited by the action script or not (to get the DISPLAY variable). So I'm not suggesting that just putting the wpa_cli command in your xinitrc and forgetting about any further adjustment will be sufficient. I'm only suggesting that it will be a much better first step than putting it in your bash profile which will definitely require a lot more further adjustment.

GSMiller · 2020-12-21 19:44:47

Yann, if you want wpa_cli to persist after i3 exits, you should start it as root, maybe as systemd service.

Yann · 2020-12-22 11:27:55

Thanks for the answers. I took time to study it. Everything you explained is pretty clear, thanks .

However, I am still confused on how to implement it, indeed, it's not an easy riddle. I am going to try to summarize what disturbs me.

On wifi events, I would like to perform actions, mostly on the graphical session, indeed. So, I should start the wpa_cli process while X11 is running (maybe from the xinitrc). Noticed that I restart i3 several times per day, but I only close the X11 session at shutdown, I think i3 restarting doesn't restart X11, i3 it's just one client among others.
However, I often get wifi wpa disconnections and have to restart the wpa service pretty often. And when I do that, I break the wpa_cli -a process as it is attached to the current wpa service.
So, I would like this wpa_cli process to be running when both X11 and the wpa service are running. But, if the restart of the wpa service stops wpa_cli, I need the wpa service starting to start the wpa_cli process too. But this doesn't work all the time as sometime the X11 process is not running while starting wpa, at boot for example.

Maybe I should create a wpa_cli service with systemd that is started by the wpa service when starting, only if X11 is running. And another way to start it from xinitrc only if not already running. Could it work ?

I guess if it is started from the wpa service, DISPLAY won't be in the variables. Is it okay to set DISPLAY=:0 by myself. Or it won't work or is not good practice ?

After further tests, wpa_cli -a script only tells when there a wifi connection or disconnection. I would have wanted to trigger events also when there is an internet connection or disconnection, or when wifi signal strength changes. But I guess I am not going to be able to be notified by system events for these specific events, I will have to use a loop that checks these informations, right ?

Thanks for your time.

Trilby · 2020-12-22 14:36:03

Yann wrote:

I restart i3 several times per day, but I only close the X11 session at shutdown, I think i3 restarting doesn't restart X11, i3 it's just one client among others.

How do you restart it? With $MOD+shift+r? That's not really restarting, but replacing the current instance with a new one. That will not result in Xorg shutting down, but any other method will.

Yann wrote:

I would have wanted to trigger events also when there is an internet connection or disconnection, or when wifi signal strength changes. But I guess I am not going to be able to be notified by system events for these specific events, I will have to use a loop that checks these informations, right?

Yup, and in that case, forget everything else in this thread as wpa_cli is of no use anymore. You may want to watch /proc/net/wireless.

Yann · 2020-12-22 15:24:30

Ok. I would like an hybride solution, wpa_cli to get inform ASAP of dis·connection and another process checking every 5 seconds the strength of the signal.

What do you think about that solution for the wpa_cli part:

Yann wrote:

On wifi events, I would like to perform actions, mostly on the graphical session, indeed. So, I should start the wpa_cli process while X11 is running (maybe from the xinitrc). Noticed that I restart i3 several times per day, but I only close the X11 session at shutdown, I think i3 restarting doesn't restart X11, i3 it's just one client among others.
However, I often get wifi wpa disconnections and have to restart the wpa service pretty often. And when I do that, I break the wpa_cli -a process as it is attached to the current wpa service.
So, I would like this wpa_cli process to be running when both X11 and the wpa service are running. But, if the restart of the wpa service stops wpa_cli, I need the wpa service starting to start the wpa_cli process too. But this doesn't work all the time as sometime the X11 process is not running while starting wpa, at boot for example.
Maybe I should create a wpa_cli service with systemd that is started by the wpa service when starting, only if X11 is running. And another way to start it from xinitrc only if not already running. Could it work ?
I guess if it is started from the wpa service, DISPLAY won't be in the variables. Is it okay to set DISPLAY=:0 by myself. Or it won't work or is not good practice ?

GSMiller · 2020-12-23 18:48:10

Yann, how do you start i3?

Yann wrote:

another process checking every 5 seconds the strength of the signal.

You can put any process in a shell script, like this:

while sleep 5; do
    check signal strength
done

You can write a small demon this way.

Yann · 2020-12-23 18:56:36

With "exec i3" in the .xinitrc file.

Yes, this is the idea. But my question now is more about the wpa_cli process that must be started by the wpa daemon and when X11 is running, see my last answer.

seth · 2020-12-23 20:40:29

I mostly would like to update the status bar

How do you get the data into the (which) statusbar itfp?
Because if the bar doesn't (only) provide some socket to write into but updates fields by allowing a scheduled command execution, this is all moot.
You want some nice script to print the signal quality that your bar then calls every couple of seconds.

Yann · 2020-12-23 21:00:51

Right now, I have a pretty huge script that monitors everything with a variable sleep loop. Every time there is a change regarding the last known value, it writes a "echo command" in a file under /var/wm/xxxx and send a signal to the i3bar process to update one of its 30 blocks that will execute the var file. I think it's not the worst implementation. However, I would like to add system event support in order to be notified directly.

For this reason, in the case of wireless events, the wpa_cli option seems interesting to be notified right away at any dis·connection. What do you think about the suggestion I made on post 18 ?

Thanks for your time.

seth · 2020-12-23 21:55:03

I'd probably rather check the state to see whether you've to check the quality (and update i3bar) because you're most likely connected most of the time anyway and reacting to the wpa event (that you're not interested in by itself) runs the risk to miss it (and spoil the data inspection from there on)
This way you also won't have to worry whether or not which wpa_supplicant process is running and which X11 server to use and when to restart what (because the presence of a carrier is agnostoc to what actually provides it)

Arch Linux

#1 2020-12-07 19:18:54

Trigger action when wireless network event

#2 2020-12-20 13:30:01

Re: Trigger action when wireless network event

#3 2020-12-20 16:17:36

Re: Trigger action when wireless network event

#4 2020-12-20 16:30:14

Re: Trigger action when wireless network event

#5 2020-12-20 17:22:44

Re: Trigger action when wireless network event

#6 2020-12-20 17:44:42

Re: Trigger action when wireless network event

#7 2020-12-20 18:41:15

Re: Trigger action when wireless network event

#8 2020-12-20 18:56:58

Re: Trigger action when wireless network event

#9 2020-12-20 19:50:29

Re: Trigger action when wireless network event

#10 2020-12-20 20:40:31

Re: Trigger action when wireless network event

#11 2020-12-20 21:23:39

Re: Trigger action when wireless network event

#12 2020-12-20 21:34:04

Re: Trigger action when wireless network event

#13 2020-12-20 21:39:04

Re: Trigger action when wireless network event

#14 2020-12-20 22:03:45

Re: Trigger action when wireless network event

#15 2020-12-21 07:23:33

Re: Trigger action when wireless network event

#16 2020-12-21 13:54:17

Re: Trigger action when wireless network event

#17 2020-12-21 19:44:47

Re: Trigger action when wireless network event

#18 2020-12-22 11:27:55

Re: Trigger action when wireless network event

#19 2020-12-22 14:36:03

Re: Trigger action when wireless network event

#20 2020-12-22 15:24:30

Re: Trigger action when wireless network event

#21 2020-12-23 18:48:10

Re: Trigger action when wireless network event

#22 2020-12-23 18:56:36

Re: Trigger action when wireless network event

#23 2020-12-23 20:40:29

Re: Trigger action when wireless network event

#24 2020-12-23 21:00:51

Re: Trigger action when wireless network event

#25 2020-12-23 21:55:03

Re: Trigger action when wireless network event

Board footer