Question

Not sure if the title explains my situation correctly, but in details it looks like this:

I'm writing a simple bash script to set up a wireless network, using wlp2s0 interface.

ip route flush dev wlp2s0
ip addr flush dev wlp2s0
ip link set wlp2s0 down

killall wpa_supplicant

ip link set wlp2s0 up
ip addr add 192.168.1.200/24 dev wlp2s0
ip route add default via 192.168.1.1

wpa_supplicant -B -D wext -i wlp2s0 -c wireless.conf

It kills all previously started wpa_supplicants and then starts a new one. Now, the problem is that the killall call causes ip route add to cry:

RTNETLINK answers: Network is unreachable

no matter if wpa_supplicant was actually started before.

It can be "fixed" by adding a sleep 1 call after killall, but of course I'd like to avoid this. It can also be fixed by removing the killall command and calling it manually before the script.

So the question is - how can I work around this strange behaviour of killall? Maybe someone has any idea why are these strange things happening.

EDIT: ip route add does not give that error if killall isn't called before it.

Was it helpful?

Solution

Why did you think it was strange? Successful return of killall doesn't necessarily mean wpa_supplicant has finished processing the incoming SIGTERM signal. It's only that the signal was delivered to the wpa_supplicant process, at best. Pehaps wpa_supplicant needed some more time (such as sleep 1) to finish execution of its clean-up handler (wpa_supplicant_terminate_proc() in wpa_supplicant.c)

So, I think you really need sleep 1.

Update

I always rely on polling method like this

TIMEO=5
for ((i=0; i<TIMEO; ++i)); do
    if pidof -s wpa_supplicant > /dev/null; then
        sleep 1
    else
        break
    fi
done

if ((TIMEO==i)); then
    echo "timeout"
else
    echo "it's gone"
fi

assuming there will not be multiple instances of wpa_supplicant.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top