Internet connection still working even if dhcpcd and wpa_supplicant is terminated (fossapup 9.5)

[wanthinker]

This is the weirdest thing i seen.

Essentially, I'm used to turn off internet completely (without relying on graphical tool given they can still reconnect sometimes or because i don't want them using ram for nothing) by doing:

Code: Select all

killall -9 wpa_supplicant dhcpcd

This works great, and i can always reconnect by just calling wpa_supplicant the way i have in one of my script...problem isn't reconnecting to it, it's that, IT STILL WORK even with both of those process gone...

I even tried to also terminate netmon* (netmon_wce and netmon_wpoll) but it still works...

Of course, it does disconnect at some point, but the fact that it still somehow still work even for 20 minutes is weird to me.

As usual, any suggestion or thought is appreciated.

EDIT: Forgot to mention but:
- this is on a live install without save file
- this is on default setting (no modification)
- this is while using only wifi, no ethernet
- and yes, i did preemptively checked if any of the process i already mentioned (wpa_supplicant, dhcpcd, netmon_wce, netmon_wpoll, etc) wasn't still running, which they weren't
- I mostly used ping (to 8.8.8.8 and google.com) and palemoon (made sure to reload pages or watch videos which weren't buffered/cached) to see if internet was still working

[wiak]

https://linux.die.net/man/8/wpa_supplicant

The following steps are used when associating with an AP using WPA:

wpa_supplicant requests the kernel driver to scan neighboring BSSes
wpa_supplicant selects a BSS based on its configuration
wpa_supplicant requests the kernel driver to associate with the chosen BSS
If WPA-EAP: integrated IEEE 802.1X Supplicant completes EAP authentication with the authentication server (proxied by the Authenticator in the AP)
If WPA-EAP: master key is received from the IEEE 802.1X Supplicant
If WPA-PSK: wpa_supplicant uses PSK as the master session key
wpa_supplicant completes WPA 4-Way Handshake and Group Key Handshake with the Authenticator (AP)
wpa_supplicant configures encryption keys for unicast and broadcast
normal data packets can be transmitted and received

I hadn't really thought about it before, but I guess from man page quote above that once wpa_supplicant has arranged the above the underlying connect no longer really needs it (except for further control of the connection).

Similarly for udhcpcd - once dyncamic IP arranged and DNS details, not needed anymore.

Whether my above thoughts above about WPA is correct or not, I'm unsure, since never thought much about what wpa_supplicant does overall, however, closing a connection would be easier just by bringing down the interface. For example, see accepted answer in:

https://raspberrypi.stackexchange.com/q ... t-raspbian

That all said, I am also surprised the killall statement you send didn't terminate the connection since I've used similar approach in the past...

[wanthinker]

https://linux.die.net/man/8/wpa_supplicant

The following steps are used when associating with an AP using WPA:

wpa_supplicant requests the kernel driver to scan neighboring BSSes
wpa_supplicant selects a BSS based on its configuration
wpa_supplicant requests the kernel driver to associate with the chosen BSS
If WPA-EAP: integrated IEEE 802.1X Supplicant completes EAP authentication with the authentication server (proxied by the Authenticator in the AP)
If WPA-EAP: master key is received from the IEEE 802.1X Supplicant
If WPA-PSK: wpa_supplicant uses PSK as the master session key
wpa_supplicant completes WPA 4-Way Handshake and Group Key Handshake with the Authenticator (AP)
wpa_supplicant configures encryption keys for unicast and broadcast
normal data packets can be transmitted and received

I hadn't really thought about it before, but I guess from man page quote above that once wpa_supplicant has arranged the above the underlying connect no longer really needs it (except for further control of the connection).

Similarly for udhcpcd - once dyncamic IP arranged and DNS details, not needed anymore.

Whether my above thoughts above about WPA is correct or not, I'm unsure, since never thought much about what wpa_supplicant does overall, however, closing a connection would be easier just by bringing down the interface. For example, see accepted answer in:

https://raspberrypi.stackexchange.com/q ... t-raspbian

That all said, I am also surprised the killall statement you send didn't terminate the connection since I've used similar approach in the past...

Indeed, that's also what i noticed. (I can confirm your above thought is correct given my own experimentation)

Seems like this behavior happen rarely on other distros. Only noticed this on a couple of puppies...
I don't mind it since i guess i could disable the wireless driver using modprobe but that seem a bit "overkill" to me, which is why I posted this (for an easier solution)

The kill statement seems to only work once in a while to disable the connection (as in, disable it instantly, not 20min later haha).

Lastly, closing the connection by bringing down the interface doesn't always work either, as it either reconnect, or take a bit of time before reconnecting (unless i remove the config or move it away, but that seem a bit silly although it work)

Thanks for the suggestion and also confirming i didn't go *crazy* yet

[wiak]

Lastly, closing the connection by bringing down the interface doesn't always work either, as it either reconnect, or take a bit of time before reconnecting (unless i remove the config or move it away, but that seem a bit silly although it work)

Yes, you likely have to also kill udhcpcd (which otherwise restarts wpa_supplicant via its 'hook') and kill wpa_supplicant, and bring down the interface. Otherwise, wpa_supplicant daemon will bring it up again.

EDIT: Mind you, on second thoughts, I don't think wpa_supplicant itself does bring the interface up again, so simply bringing interface down should be enough to break the connection. Just tried on my system and just bringing interface down did break the connection (I'm using WDL_Arch74, but shouldn't be a difference in terms of wpa_supplicant operation, unless there is some other daemon running on your system that is bringing the interface back up again that I don't know about).

[Jafadmin]

Code: Select all

ifconfig wlan0 down

[Jafadmin]

You need to "down" the wireless interface.

Code: Select all

ifconfig wlan0 down

[bigpup]

What network connection wizard are you using to setup the connection?