Which NM version and KDE SC do you use?

Are you connecting your slot to Solid::Networking::notifier() or org.kde.networkstatus? They use different backends, so I need to know which one you are using.

Can you monitor NM and see if its signals are being emmited at the right time? You can do it like this:

dbus-monitor --system "type='signal',sender='org.freedesktop.NetworkManager',interface='org.freedesktop.NetworkManager'"

wait for the "connecting" signal (State == 40):

signal sender=:1.0 -> dest=(null destination) serial=135662 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=PropertiesChanged
   array [
      dict entry(
         string "State"
         variant             uint32 40
      )
      dict entry(
         string "ActiveConnections"
         variant             array [
               object path "/org/freedesktop/NetworkManager/ActiveConnection/8"
            ]
      )
   ]
 
and then for the "connected" signal (State == 70):

signal sender=:1.0 -> dest=(null destination) serial=135679 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=StateChanged
   uint32 70
signal sender=:1.0 -> dest=(null destination) serial=135686 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=PropertiesChanged
   array [
      dict entry(
         string "State"
         variant             uint32 70
      )
   ]


It must be a few seconds gap between those two signals (unless your ethernet switch and card are too fast).

Created attachment 63745 [details]
Output upon plugging in the cable.

NetworkManager 0.9.0

I connect to "Solid::Networking::notifier()".

I just tried and I instantly receive
"signal sender=:1.0 -> dest=(null destination) serial=580 path=/org/freedesktop/NetworkManager/Devices/0; interface=org.freedesktop.NetworkManager.Device.Wired; member=PropertiesChanged
   array [
      dict entry(
         string "State"
         variant             uint32 70
      )
   ]
"

So there is no noticeable gap inbetween.


Interestingly after some time (probably when the networkmanager plasmoid shows that it is connected) this gets emitted:

"signal sender=:1.0 -> dest=(null destination) serial=605 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=PropertiesChanged
   array [
      dict entry(
         string "State"
         variant             uint32 70
      )
   ]
"

Though the slot I connected to Solid::Networking::notifier() is not called again.

You are mixing the signals from org.freedesktop.NetworkManager.Device.Wired and  org.freedesktop.NetworkManager interfaces, they are different. 70 means NM_DEVICE_STATE_IP_CONFIG (dhcp client is running) for org.freedesktop.NetworkManager.Device.Wired and NM_STATE_CONNECTED_GLOBAL (fully connected) for org.freedesktop.NetworkManager. Take a look in /usr/include/NetworkManager/NetworkManager.h.

Anyway, the lines below from your log may explain what is happening:

signal sender=:1.0 -> dest=(null destination) serial=598 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=StateChanged
   uint32 70
signal sender=:1.0 -> dest=(null destination) serial=599 path=/org/freedesktop/NetworkManager/Devices/0; interface=org.freedesktop.NetworkManager.Device; member=StateChanged
   uint32 100
   uint32 70
   uint32 0
signal sender=:1.0 -> dest=(null destination) serial=604 path=/org/freedesktop/NetworkManager/Devices/0; interface=org.freedesktop.NetworkManager.Device.Wired; member=PropertiesChanged
   array [
      dict entry(
         string "State"
         variant             uint32 100
      )
      dict entry(
         string "Ip4Config"
         variant             object path "/org/freedesktop/NetworkManager/IP4Config/2"
      )
   ]
signal sender=:1.0 -> dest=(null destination) serial=605 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=PropertiesChanged
   array [
      dict entry(
         string "State"
         variant             uint32 70
      )
   ]

NetworkManager emits the org.freedesktop.NetworkManager's StateChanged signal before the org.freedesktop.NetworkManager.Device.Wired and org.freedesktop.NetworkManager's PropertiesChanged signals. Because of that Solid::Networking::notifier() emits the statusChanged signal before the wired interface emits its signal. Maybe that is the cause of your problem.

OBS: the plasmoid updates the tray icon by getting the status of the network interface that has the default route (so that it can change the icon to wifi, wired, phone, etc), not through statusChanged signal, so it does not suffer from this problem.

One solution is to change Solid::Networking::notifier()'s backend to use org.freedesktop.NetworkManager's PropertiesChanged signal instead of the StateChanged signal. I just do not know if the PropertiesChanged signal is emitted when NetworkManager stops, if not then we will have a problem.

Can you tell me if there is a considerable time gap between the signals:

signal sender=:1.0 -> dest=(null destination) serial=598 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=StateChanged
   uint32 70

and 

signal sender=:1.0 -> dest=(null destination) serial=605 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=PropertiesChanged
   array [
      dict entry(
         string "State"
         variant             uint32 70
      )
   ]

Both are emitted roughly at the same time, i.e. once the plasmoid shows that a connection has been successfully created.

Enable debug messages using kdebugdialog (search for all network related debug outputs), execute:

solid-network query status
qdbus org.kde.kded /modules/networkstatus status
qdbus org.kde.kded /modules/networkstatus \
org.kde.Solid.Networking.Service.networks

before connecting. By the way, you use only NM, right?

Created attachment 63805 [details]
Output when disconnected

As far as I know I only use NM.

(In reply to comment #6)
> Created an attachment (id=63805) [details]
> Output when disconnected
> 
> As far as I know I only use NM.

Sorry, I was not clear in my last post. I need you to send me your ~/.xsession-errors file after executing those commands.

Created attachment 63811 [details]
xsession-errors file

Running these commands did add nothing to the xsesserion-errors file here.

In any case I attached it. What I did was:
1. Starting KDE with the cable plugged in
2. Unplugging cable
3. After some time running the commands you listed in #5
4. Plugging in the cable again.

Unfortunately the xesserion-errors file is also filled with stuff from Soprano etc. even though I deactivated all these in kdebugdialog, probably those are qDebug() etc. messages instead of the k version.

(In reply to comment #8)
> Created an attachment (id=63811) [details]
> xsession-errors file
> 
> Running these commands did add nothing to the xsesserion-errors file here.

They did add this line:

kded(3896)/networkstatus NetworkStatusModule::status:  status:  0
 
> In any case I attached it. What I did was:
> 1. Starting KDE with the cable plugged in
> 2. Unplugging cable
> 3. After some time running the commands you listed in #5
> 4. Plugging in the cable again.

You did more than that. You started your KDE session with NetworkManager stopped and start it after kded was already running. I think that is causing problems to kded's networkstatus module because the module tries to connect a signal to NM (QObject::connet) when it is created. However, that will not succeed because the QDBusInterface passed to QObject::connect will be invalid and kded's networkstatus module will not be able to track NM's status changes.

That explains why networkstatus returned status 0 (unknown), it should have returned status 1 (unconnected).

Probably that is not the cause of your inicial problem, but can you log with NetworkManager already running to see if the problem still happens?
 
> Unfortunately the xesserion-errors file is also filled with stuff from Soprano
> etc. even though I deactivated all these in kdebugdialog, probably those are
> qDebug() etc. messages instead of the k version.

That is not a problem for grep :-)

So that means that I should make a clean restart -- with my cable connected -- and check what is added to the .xsession-errors file to see if networkmanager is started correctly here?

Btw. thanks for all your replies! :)

Almost, NM does not write to ~/.xsession-errors, Plasma NM, Solid's backend and networkstatus do. Since it seem there is nothing really wrong in NM's log I trying to figure out if there is something wrong in the KDE's part of the stack.

The 0 status reported is something wrong, but only that does not explain the Connected signal being emmited too early. I still do not see why it is emmiting that signal so early.

What should I do to give you more information?
And how can I ensure that networkmanager is already running, the daemon should already be started before I reach kdm.

You should enable all debug using kdebugdialog and send me your .xsession-errors.

Created attachment 63992 [details]
log

1. checking everything in kdebugdialog
2. removing ~/.xsession-errors
3. restarting with the cable connected
4. logging in
5. waiting a little then unplugging cable
6. after a while plugging in cable again

I think I know what is happening: you are using ntrack and ntrack is very optmistic to detect when your computer is online.

You can see that in your log, just search backwards (from the end of the log file) for the string "ntrack changed status:  1". That line triggers the statusChanged(Connected) signal. But look more ahead the line '"Wired connection 1" is activating' and the line 'NMWiredNetworkInterface::wiredPropertiesChanged: "State" QVariant(uint, 100)'.  The latter indicates the connection is activated and your computer is effectively online (according to NM).

Some lines before the line "ntrack changed status:  1" there is this line 'NMWiredNetworkInterface::wiredPropertiesChanged: "State" QVariant(uint, 20)', which indicates your wired card was detected by NM. 20 == Unavailable, that is, the card is working but there is no connection available yet. Even though there is no connection available ntrack signals that your computer is online.

Can you recompile kde-runtime without ntrack and see if that fixes your problem? I have never used ntrack, so I cannot help that much on how to disable it.

Have you tested using Solid::Networking::notifier() without ntrack?

Sorry for not answering in a while.
I just tried without ntrack and then it works. :)

What special features are added by ntrack anyway?

I have never used ntrack, by what I have heard ntrack is a generic way to detect network state (disconnected, connecting, connected) independently of the network manager you use (NM, wicd, ifplugd, ifconfig, etc).

Unfortunately we have had some instability problems caused by ntrack before and now this problem. I will check if there is a way to use ntrack to really detect when the computer is connected to the Internet and not only connected to a network manager.

By the way, which ntrack version is installed in your computer?

I am using ntrack 1:13

I am investigating ntrack's source code and it uses modules to do the tracking work. When there is no suitable module available it defaults to a noop module that always signals the computer is online. I think you do not have a suitable ntrack module for NM installed. Try running kded4 in the command line, if the message "no backend found: using built-in noop monitor (always online)." then you should check your ntrack installation.

Since you are using ntrack 0.13 maybe you are facing one of those bugs too:

https://bugs.launchpad.net/ntrack/+bug/750554
https://bugs.launchpad.net/ntrack/+bug/785119

By the way, which distribution do you use?

Anyway, this is an upstream bug so I will close it as such. You can still contact me through this bug entry if you have any more questions.

I am using Arch Linux.

The message I get in xconfig-errors is "ntrack backend selected and created: ntrack-libnl1.so", in the console output I do _not_ have the message you noted.

So the issue is probably something else, but as you noted it has to do with ntrack.