Bug 165907

Created attachment 78324 [details]
NetworkManager Log

Created attachment 78326 [details]
System log

What's the output of

# nm-tool | grep State
# dcop kded networkstatus status NM

?

Just saw the 'not' in your report.  The log says that NM connected to eth1 successfully - is that information incorrect?  Did NM fail to connect, then you set up the connection by hand with i[wf]config?  If this isn't clear, what does ifconfig say?

NetworkManager arrived to connect, after I set up the _hidden_ essid on command line manually. That's why you can find a successful attempt in the logs.

But even then, KDE applications (konqueror, kmail) were not able to go online. I had to reboot in runlevel 3, start the internet manually then run KDE to be able to go online.

Cannot give you more logs now, as I'm on vaccation until easter thuesday, sorry. But I'm sure other users will have similar problems. Unfortunately I could not find my the previous bug report with the same problem, which was fixed fot beta8. There you can find more informations

Michael had the same problem: NetworkManager is offline (from it's own perspective) and KDE only believes that information - even if you quit knetworkmanager. 

I think, this is a NM bug though. It should either signal that it doesn't handle any devices or it should figure, something went online without it.

Timo, NM should be Asleep rather than offline if it failed to set anything up, right?  That's the assumption that Networkstatus works on.

What if NM is disconnected and the user manually sets up with iwconfig - will NM update its state accordingly?  This is a corner case and probably outside of NM's spec thought.

(In reply to comment #7)

> Timo, NM should be Asleep rather than offline if it failed to set anything up,
> right?  That's the assumption that Networkstatus works on.

Actually, NM is in state NM_STATE_ASLEEP if it was sent to sleep via the D-BUS interface.  It is in state NM_STATE_DISCONNECTED if it failed to connect to a network.  Why should it set itself to NM_STATE_ASLEEP? 

If, for example, NM failed to connect to a wireless network because it wasn't found, which lateron appears, NM will connect to it.  This would not be the case if NM would enter NM_STATE_ASLEEP once it could not connect to any network.

> What if NM is disconnected and the user manually sets up with iwconfig - will
> NM update its state accordingly?  This is a corner case and probably outside
> of NM's spec thought.

No, NM will not update its state.  And it shouldn't, really.

We had lengthly discussion whether it is reasonable to allow a mixture of NM and another network-managing instance (ifplugd, manual ifconfig, ...) and we refused to allow such an option.

Um, oh.  I hope you realize that for people who have a DSL connection
on their machine NM will not only be useless, but actively interfering with
work?  So I have to chose between either having the nice wireless features
of NM, or working connectivity.

No, you can set an interface to be user-controlled and NetworkManager will not touch it.  You're free to do anything you want with this interface.

Forgive my ignorance, but where can I do that?  (It might also be because
I had a too old beta, beta7).  In knetworkmanager itself?

#10: will NM still be NM_STATE_DISCONNECTED then? If so, NM _is_ hindering your work, because KDE will think it's offline

(In reply to comment #11)

> Forgive my ignorance, but where can I do that?  (It might also be because
> I had a too old beta, beta7).  In knetworkmanager itself?

It *should* work as before.  Use kinternet to connect/disconnect.

(In reply to comment #12)

> #10: will NM still be NM_STATE_DISCONNECTED then? If so, NM _is_ hindering 
> your work, because KDE will think it's offline

Yes it will.

Fix KDE to not only show the state of NM then.  NM just can not monitor what a user or another daemon might do behind its back.

Why does KDE fully depend on the network informations it gets from NM?
Why doesn't NM check for existing (manual setup) internet connections?

To #10: AFAIK you can only choose if you want to use NM or old-style mode. At least in YaST there is no option to set this per interface. In the fist screen YaST asks you, which you want to use. Later there is no option to change per device.

Ok, I can see how this failed - NM is DISCONNECTED and kinternet defaults to not provide info to kded_networkstatus. So we take NM's info as gospel.  I thought NM went ASLEEP if it was not managing anything, in which case kded doesn't inhibit any network ops.

If I turn on kinternet's kded_networkstatus feed by default and it works for all the ppp flavours and non NM managed ethernets, we should be alright again.

But I would still like NM more if it could differentiate between not managing any networks and managing networks but being disconnected.

Perhaps you can doubt NM if knetworkmanager isn't running? This would fit my expectations as user

This looks like a bad idea to me.

What if a user chooses to use nm-applet or his own cooked NM client?  Other than that, it is also possible to feed known networks to NM not using the applet but YaST.  NM parses the /etc/sysconfig/network/ifcfg-wlan-* for this.

Well, parsing *-wlan-* doesn't seem helpful for the DSL case.  And Will:
kinternet simply wasn't running.  It wasn't even installed on that machine.
I had to use cinternet to manage the DSL interface.  The workaround from
coolo would have helped me indeed.

I'm testing a KNetworkManager that talks to kded on behalf of NM - in KNM I have detailed info on NM's state, so if it doesn't know of any devices I can differentiate between DISCONNECTED and DISCONNECTED_USELESS.  This implements coolo's workaround too, and replaces the direct NM link in kded.  It's not as clean as the direct link but it's too much work to make the dbus code in KNM a library right now.

submitted, please test.

Updated kdepim3* and kinternet are also necessary to test.