If the interface isn't known or controlled by NetworkManager, then NM won't know that your computer has a connection.  There's nothing NM can do if it's not aware of the existence of an interface that's configured.  It's likely you've made NM ignore that interface in your configuration files.  For your case for now, I'd suggest turning NetworkManager off completely.

Dan, you cannot just close this bug cause it don't like to hear that you have a major design fault in your pet project. Just removing default routes or removing entires from /etc/resolv.conf - as network manager currently does - is plainly wrong. Reporting dependent programs the network would be down, just because network manager didn't create an interface also is plainly wrong. 

NetworkManager could for instance inspect the routing table for default routes on network devices it doesn't know and check the link-state of those devices. If they report they to the kernel they are intact, than also NetworkManager should do this to its clients otherwise you cause endless pain for your users.

Look, I'm not just closing the bug for the fun of it.  Ubuntu decided to make NM ignore devices you've set up via the Ubuntu tools by default.  That's not an NM decision, that's an Ubuntu decision.  I have no control over it.  They did that knowing full well that NM would stomp on the routing table if devices were unknown to NM.  If you have a problem with that, please take it up with Ubuntu people

NM is not going to inspect the routing table and try to "fake" a network device that it is not supposed to control.  That's not the right solution.  The right solution is to expand the use-cases of NetworkManager to cover the reason why you're not letting NM manage this particular network device for you.  And we're going to deal with that in the next major version coming around the corner.  But not in the way you suggest.

If NetworkManager isn't working for you in a particular use-case, then the best thing for you to do is to disable NetworkManager and use the distro tools to configure your networking.

Dan, best way to reach world domination - as you seem to do - is consense, not confrontation. You currently follow the path of confrontation. My network setup worked before someone decided to throw network manager at me. Now it doesn't do anymore. If I am out for paternalism I can easily choose Windows.

Dan, I am not here to say the idea behind NetworkManager is nonsense. But currently there are quite some people, who really are pissed by getting NetworkManager getting forced on them - so those issues rather should be resolved than be ignored. 

Giving people short term solutions, like playing nice with manually configured network interfaces is a good way to get people used to network manager. I am pretty sure some of them will send you patches integrating their custom setups into network manager, once they have used nm for some time, but you are not going to convince them of network manager if you slap them right in the face, as you are doing right now. 

I am fetching the source code of nm right now to look where to fix its behavior. Those are the moments when I really hate open source: Really do not like having to choose between hating you, network manager and the world, or creating a patch.

Hmm. Calmed down a bit. Checking if it's really Ubuntu doing something wrong. 

Nevertheless the unconditional "/sbin/ip route del default" in nm_generic_delete_default_route[1] seems to be plain wrong to me: You cannot delete routes pointing to devices not managed by network manager.


[1] http://svn.gnome.org/viewcvs/NetworkManager/trunk/src/backends/NetworkManagerGeneric.c?revision=2339&view=markup

Dan, I want to applogize for the tonage of my words. Sometimes I take things too seriously. Thought I'd have learned to control this, but appearently feisty not working out of the box (plus some other stuff) caused me to relapse.

I am having the same problem running Gutsy: NM works fine with "normal" setups wor LAN and WLAN. However, I recently got my hands on a UMTS modem which I have to beat with a self written chatscript and pppd to get a connection up and running. Of course, NW could not know of the interface so it tells epiphany end everyone the network were down.

What would be the correct way to implement a solution? Shouldn't pppd do that automatically for pon/poff events? Or is there a more general problem with interfaces popping up from out of nowhere, which NM then is unable to handle?

Maybe, I just could not google a working solution. So, I would appreciate any hints.

Hiya Guys, I think I have a similar problem in Fedora 8. when I boot up I am unable to get online. My /etc/resolv.conf is as follows;


# generated by NetworkManager, do not edit!

search domain_not_set.invalid


nameserver 192.168.1.1
nameserver 68.237.161.12


I have to remove the first listing of the nameserver which is my router. once that is done I am able to get online. Now here is the problem, when I restart Fedora 8, ny /etc/resolv.conf reverts back and have to remove that line again and will have to after each time I boot fedora 8 up.

so how to I prevent network manager from changing /etc/resolv.conf again?

Like I said looking at this bugzilla report it looks to be similar to my problem
any suggestions?

Regards
Richard

Richard, this means your DHCP server is returning the value "domain_not_set.invalid" to your machine.  Can you confirm if that's really the case?  Does this still happen for you in Rawhide?

@others: NM now handles mobile broadband cards in trunk.

Again, if NM is not controlling the network interface, then it will not know anything about that interface's configuration.  You could try telling NetworkManager to got to sleep when you activate your UMTS connection, and when the connection terminates, tell NM to wake up.

(In reply to comment #10)
> @others: NM now handles mobile broadband cards in trunk.

That's cool.

> Again, if NM is not controlling the network interface, then it will not know
> anything about that interface's configuration.  You could try telling
> NetworkManager to got to sleep when you activate your UMTS connection, and when
> the connection terminates, tell NM to wake up.

Guess you loose LAN/WLAN connectivity when doing that, won't you? So even if the situation of having the default route on a device not managed by NM became less certain now, it still be useful to have an easy method for telling NM about such links...

Yes, NM 0.6.x doesn't support having multiple connections active at the same time.  0.7 will support multiple active connections managed by NetworkManager, but again will not be aware of other network connections.

I think Mathias Hasselmann has a point here:

See Network Manager reports offline tough an interface it does not control is indeed fully operational and online. The application - like Iceweasel [1] - relies on that report.

IMHO this is just plain wrong. If Network Manager refers to the whole network its answer is wrong. If Network Manager only refers to the interfaces it controls, IMHO the application is wrong to rely on it for network detection.

I still think Network Manager should at least report "unknown" as network online status in case it does not control all interfaces. Thats at least an honest answer to the query an application makes.

Forcing an all or nothing scenario on users who wish to use Network Manager doesn't seem to be a solution that makes sense to me. At least for me that answer then probably would just be to use WPA supplicant again and be done with Network Manager. Or hope for Debian's netconf developments: http://netconf.alioth.debian.org/

I might be convinced when Network Manager can handle static configuration that can be triggered on finding a certain IP and MAC address combination like guessnet is able to do. But even then there may always be cases to which Network Manager might not have catched up to like UMTS, special PPP setups and such. On insisting on the all-or-nothing scenario, this would mean that users with those scenarious cannot use Network Manager even for the cases where it works for them.

I do not like to offend anyone, but honestly spoken this all smells to me like the typical GNOME approach of not letting users configure their systems *as they wish*, but insisting to know it better than those users.

I hope a good solution can be found.

See also:

- Debian bug report(s) regarding this issue: http://bugs.debian.org/491826, http://bugs.debian.org/491822 and others referenced in the first debian bug report.

- Firefox 3.0 bug report regarding this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=424626

(In reply to comment #13)
> I think Mathias Hasselmann has a point here:
> 
> See Network Manager reports offline tough an interface it does not control is
> indeed fully operational and online. The application - like Iceweasel [1] -
> relies on that report.

Most of the people complaining about this are using NetworkManager 0.6.6, which was more limited.  NetworkManager 0.7 supports *many* more configurations (static IP, GSM/CDMA, PPPoE, etc) and thus is able to control the default connection for most people.

> IMHO this is just plain wrong. If Network Manager refers to the whole network
> its answer is wrong. If Network Manager only refers to the interfaces it
> controls, IMHO the application is wrong to rely on it for network detection.

NetworkManager is a mechanism for easily configuring your network.  If you have really special networking needs, then don't use NetworkManager, and Iceweasel won't report that it is offline.

> I still think Network Manager should at least report "unknown" as network
> online status in case it does not control all interfaces. Thats at least an
> honest answer to the query an application makes.

This has been covered in multiple mails and bugs already.  If a device is not controlled by NetworkManager, then NetworkManager cannot, by *definition* know any details about the device.  If the application then tries to figure out what device is actually online and what IP address it has, it could not, because even if NM reported "online" for that device, NM doesn't have any of the device details.

> Forcing an all or nothing scenario on users who wish to use Network Manager
> doesn't seem to be a solution that makes sense to me. At least for me that
> answer then probably would just be to use WPA supplicant again and be done with
> Network Manager. Or hope for Debian's netconf developments:
> http://netconf.alioth.debian.org/

NetworkManager 0.7 is able to control many more devices than 0.6.6.  Please check out NM 0.7 and see if that works for you.

> I might be convinced when Network Manager can handle static configuration that
> can be triggered on finding a certain IP and MAC address combination like
> guessnet is able to do. But even then there may always be cases to which
> Network Manager might not have catched up to like UMTS, special PPP setups and
> such. On insisting on the all-or-nothing scenario, this would mean that users
> with those scenarious cannot use Network Manager even for the cases where it
> works for them.

NetworkManager can control GSM and CDMA mobile broadband devices.  Again, if NetworkManager does not fit you needs, there's nothing that says you have to use it.

(In reply to comment #14)
> > I still think Network Manager should at least report "unknown" as network
> > online status in case it does not control all interfaces. Thats at least an
> > honest answer to the query an application makes.
> 
> This has been covered in multiple mails and bugs already.  If a device is not
> controlled by NetworkManager, then NetworkManager cannot, by *definition* know
> any details about the device.  If the application then tries to figure out
> what device is actually online and what IP address it has, it could not,
> because even if NM reported "online" for that device, NM doesn't have any of
> the device details.

All we need is for NM to detect whether there are interfaces up that it's not managing, and in that case, refuse to broadcast StateChange messages. We do not need NM to determine whether those interfaces represent a working connection to a network. Since, on Linux at least, it seems ifconfig can enumerate active interfaces of all kinds, it seems to me that it should be possible for NM to do this and thus to figure out if there are any non-loopback interfaces that it's not managing.

Currently, we (Firefox) can't depend on NM's StateChange messages to be reliable indicators of whether the user is online or not, and so we have to keep NM integration disabled by default or users who run NM but have some active interfaces not managed by NM will complain that Firefox is broken.
https://bugzilla.mozilla.org/show_bug.cgi?id=424626
We can argue till we're blue in the face that those users shouldn't be using NM, or should be managing all their interfaces with NM, but it won't help. Making StateChange reliable is the only way I can see to fix this in practice.

Dan: it makes me sad that Firefox doesn't rely on NetworkManager events :-( Is there any possibility of NetworkManager changing along like lines roc suggests in comment #15? 

Semantically, it does make sense for NM to refuse to broadcast messages about the network state when it doesn't have full knowledge of that state. And surely it must be possible to get, from the OS, a list of all network interfaces, and compare that list with the list of ones NM is managing?

Gerv