It is difficult to understand what you are trying to do and why you are doing it.
I cannot think of a normal use case where you would need to restart the NetworkManager daemon to fix a wireless (or other) connectivity problem.

There is an applet on the task bar for KDE that handles the user's view of the NetworkManager as well as a connection editor which you would use to manage your networking connections. You use the applet to manage the NetworkManager connections versus starting/stopping the NetworkManager daemon.

My best guess is that this is introducing some sort of a delay.

Regarding the vindication you express in this post, it would be helpful if you could report whether this change makes a difference.

Today install new updates ...

/etc/rc.d/rc.networkmanager stop

Aparently is stop , but if i open the browser i can use net perfectly .. (non stoped then)

In to kde , ksysguard i use to monitoring net services ..

NetworkManager appears running ..

Why do you think that stopping the daemon that configures and brings connections up should bring the connections down when you stop it? Why would that be a good thing?

I can stop sshd, for example, but any ssh connections that I have at the time will stay up. I just cannot make new ones.

WPA goes through wpa_supplicant
if you stop wpa_supplicant the link to the AP will be useless

edit:
nvm i was at fault
wpa is also a kernel thing
just tested it with SIGKILL and the connection still works
that wpa_supplicant will de-configure when sent a SIGINT still stands


WEP is in the kernel so it doesn't need anything userspace

a network manager can leave wpa_supplicant running but wpa_supplicant does more then just decrypt/encript things

when you stop wpa_supplicant it de-configures the connection to the AP

if you try to configure the interface to something else that wpa_supplicant will probably fight you

so yea, it's not that simple

To extent that this is a problem, then it appears to be an upstream problem versus a Slackware one, doesn't it? AFAIK, Slackware doesn't patch NetworkManager in any way.

pss , incredible , ... then what the porpouse of stop a service ?

stop is STOP

I switch time ago to wicd ...when stop wicd, network is down.

STOP = STOP or not ?

If you need use your network cards for others tasks , need stop the network , for example if you put a wireless card in to monitor , the NetworkManager are all the time trying to manage the card , then have 2 ways , stop the service or edit a config to blacklist card to unmanaged in networkmanager.conf



in the networkmanager.conf can add this

[keyfile]
unmanaged-devices=interface-name:*mon*;

and all cards

monX or wlanXmon

are unmanaged for networkmanager at this point.

_______________________

ever , yes i say EVER , networkmanager service working perfcetly on slack 14.0 and 14.1 , stop is stop ... restart is restart.

but now , that service is broken at some point , im not a pro , im not have idea whats wrong, but im totally sure, something not working as espected.


airmon-ng check kill

kill the networkmanager service ... for example ...and this is a litle example.

Well, Slackware 14.1 used NetworkManager-0.9.8.8. -current uses NetworkManager-1.0.10.

There's been a rather large set of changes between the two and what you are complaining about may be due to Slackware being one of the few remaining non-systemd distros.

https://cgit.freedesktop.org/Network.../NEWS?h=1.0.10

So would a patch to /etc/rc.d/rc.networkmanager to change
to fix the problem of not stopping wpa_supplicant?

it would stop either way
SIGTERM and SIGINT make it de-configure the interface, while SIGKILL-ed it wouldn't
(disconnect, clean up passwords and such and bring it "admin" down)
note i only tested with SIGINT

it occurred to me i don't know why i am talking about WPA
must have mixed up this topic with the other one



USUARIONUEVOs problem seems to be that NM itself continues running
i have no idea why that would be

as for monitors, as in the virtual devices in monitor mode
(created via airmon-ng start or iw; although i remember vaguely that the main device can be changed to a monitor as well)

they should work when the main device is connected, and even if it is not in the "admin up" mode

only problem would be that the monitor device would be stuck on the specific channel if connected

at least on my computer

Hmm. I walked downstairs and ran as root on my laptop that is running Slackware64-current. I'm also running gkrellm on that machine.

My wlan0 device removed itself from the gkrellm display. Running as root made it show up again.

So

1. So, there appears to be a difference between my setup and USUARIONUEVO's
2. I do not know if USUARIONUEVO can articulate what may be unusual about his setup.

USUARIONUEVO, that is not meant as an insult to you. I have studied a couple of languages in my life and I would be absolutely unable to give a technical discussion on computer hardware, software, or operating systems in either of them.

i understand now what USUARIONUEVO was talking about (i'm slow)

NM when told to kill itself would bring down all the interfaces.
problem is that it would take down monitor interfaces as well.

i remember reading a changelog for some new version that it won't do that any more, although i can't find it in the 1.2 version changelog

another thing is that rc.networkmanager stop does not stop ModemManager, so that should be added

Networkmanager is a evil thing. I do not understand why slackware includes this complex shit.

1 members found this post helpful.

That's your (based on what?) opinion. I don't share it
Don't worry. Others do.