wired connection settings are lost after reboot

Routes get lost even without u rebooted :(

I can confirm the same problem, having just upgraded from hardy with static ip in /etc/network/interfaces, eth0 connects via dhcp and ignores the static settings.
Changing the setting through the network manager to a manual address appears to work for a short while, but then reverts to dhcp, even before rebooting.

Bug #261686 might be causing this.

Made the dir and it doesn't solve the problem :(

Also upgraded to newest ppa version (where bug 261686 is fixxed) but didn't solve it neither !

i have the same issues. And i had /etc/NetworkManager/system-connections folder, but when i change my settings, it gets applied when i choose this connection from applet and it works.

but when i restart all settings are lost (and interface has changed to dhcp - i had static settings) and i need to manualy change this again.

when my connection works ( after manualy changing and selecting that changed connection) i see that /etc/resolv.conf and /etc/network/interfaces has been changed acrordingly

Interfaces get added automaticly in NetworkManager. But those u CAN'T edit !

But there is a workaround :)

You have auto connection (Auto eth0 for example), you edit it, Tick off 'System setting', and press OK.
Then u edit it again, and tick it on again.
From now on it will remember the settings :)

Kreso, /etc/network/interfaces are certainly never touched by NetworkManager 0.7.

workaround mentioned above by Dupond jean-Louis works for me to, so for now i have working "nonforgetting" connection with NM 0.7 :)

same problem ...

manual connection is broken ;(

trick:
add AUTO eth0, save, edit, change to manual, save - solve, but i dunno what happen after reboot ;)

On Tue, Oct 07, 2008 at 07:37:07AM -0000, xoco wrote:
> same problem ...
>
> manual connection is broken ;(

Are you using hardy or intrepid? are you using NetworkManager 0.6 or 0.7?

 - Alexander

Alexander Sack : I just tested your latest update of network-manager (0.7~~svn20081008t224042-0ubuntu1) on a clean intrepid installation and this bug persist. This might be a policykit issue since when I try to change the system configuration, I'm not asked for any passphrase. The static IP settings immediately works, but default DHCP come back after one reboot and static IP settings are lost.

Alexander Sack >

latest updated version of interpid.
problem exist.

On Fri, Oct 10, 2008 at 01:11:58AM -0000, Saïvann Carignan wrote:
> Alexander Sack : I just tested your latest update of network-manager
> (0.7~~svn20081008t224042-0ubuntu1) on a clean intrepid installation and
> this bug persist. This might be a policykit issue since when I try to
> change the system configuration, I'm not asked for any passphrase. The
> static IP settings immediately works, but default DHCP come back after
> one reboot and static IP settings are lost.
>

Yes. should be a policykit thing. Not sure where to look first.

 - Alexander

I'd claim this is clearly a showstopper and wonder why priority is still only 'medium'.
Someone must raise it.

I can see lost static configs after reboot, too, with latest intrepid updates
network-manager 0.7~~svn20081015

I have two Ethernet network cards, one DHCP and one static.
I tried hard the workaround above ("Tick off 'System setting', and press OK.
Then u edit it again, and tick it on again, press OK"). Took me a few minutes before it
succeded and NM wrote a config file into

 /etc/NetworkManager/system-connections/

Name of the file corresponds to the connection name I gave it. I can see my static settings inside.

I have found a thread about the problem of configs not being written, tough. Cite from [1]:

"It's likely that the plugins your distro has set up for system settings
aren't capable of saving (ifupdown, ifcfg-fedora, ifcfg-suse). The only
one that can write out information is the keyfile plugin which isn't
enabled by default.
Before 0.7 is release, the system settings service will stack the
plugins and saving will work correctly when both a read-only and a
read-write plugin are in use."

Not sure if this is the problem we are facing in Ubuntu since after some fiddling
it finally asks for PolicyKit confirmation and writes the config.

Regarding the default route problem I found [2] on the NetworkManager mailing list. Looks like this is a known problem.

[1] http://mail.gnome.org/archives/networkmanager-list/2008-October/msg00037.html
[2] http://mail.gnome.org/archives/networkmanager-list/2008-October/msg00052.html

i just remove buggy "Network Manager" at all
and configure it manual ( /etc/networks/interfaces ) ..

all work fine! ;))

the route problem should be fixed in the follow up upload i did today.

Citing Alex
" you cannot save a auto generated connection. so you either have to rename it or to create a new one. then it should work"

This is important to know then.

On Thu, Oct 16, 2008 at 04:29:29PM -0000, Christian Kirbach wrote:
> Citing Alex
> " you cannot save a auto generated connection. so you either have to rename it or to create a new one. then it should work"
>
> This is important to know then.
>

Right. In fact read-only connections should be better marked in
connection editor. We are missing that information however in the
applet and only get an error upon saving. I am thinking about a
solution and will discuss that with upstream. If we cannot find a fix
in time for release, we will surely look into fixing this in form of a
SRU.

 - Alexander

Hi all,
       I dunno much about stuff but I got this while restarting networking (most of the times I think I'm on Auto DHCP but dunno how that works)

sudo /etc/init.d/networking restart
 * Reconfiguring network interfaces... /etc/network/interfaces:5: misplaced option
ifdown: couldn't read interfaces file "/etc/network/interfaces"
/etc/network/interfaces:5: misplaced option
ifup: couldn't read interfaces file "/etc/network/interfaces"
                                                                                                           [fail]

These are the changes I had done on /etc/network/interfaces

 cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth1 inet static
address 192.168.1.2
netmask 255.255.255.0

This is what /etc/resolv.conf shows

 cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.1.1

/etc/NetworkManager/nm-system-settings.conf
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=true

Any ideas what's wrong anywhere?

Ok came to know that now /etc/network/interfaces also needs a dns-nameserver . From what I understand they are the same as in the network-applet right?

The DNS Servers where one puts stuff. This is what I've put there.

auto lo
iface lo inet loopback

auto eth1 inet static
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 61.1.96.69, 61.1.96.71

ifconfig gives this

 sudo ifconfig -a
[sudo] password for shirish:
eth0 Link encap:Ethernet HWaddr some address
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
          Interrupt:18 Base address:0xc800

eth1 Link encap:Ethernet HWaddr some MAC address
          inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
          inet6 addr: some address Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:45406 errors:0 dropped:0 overruns:0 frame:0
          TX packets:37771 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:55521183 (55.5 MB) TX bytes:3939451 (3.9 MB)
          Interrupt:22 Base address:0xcc00

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:882 errors:0 dropped:0 overruns:0 frame:0
          TX packets:882 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:52416 (52.4 KB) TX bytes:52416 (52.4 KB)

ok again I had failure, I was not able to get it working through what I tried above. Had to resort to

sudo dhclient

This is what it used for this time.

DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
DHCPOFFER of 192.168.1.3 from 192.168.1.1
DHCPREQUEST of 192.168.1.3 on eth1 to 255.255.255.255 port 67
DHCPACK of 192.168.1.3 from 192.168.1.1
bound to 192.168.1.3 -- renewal in 1719 seconds.

perhaps that could also help ?

hmm... ok hunted around and got this file

/usr/share/doc/ifupdown/examples/generate-interfaces.pl.gz .

ran it and it gave whole lot of stuff which I have included as an attachment

The main part I put in the /etc/network/interfaces

auto lo
iface lo inet loopback

iface eth1 inet static
    address 192.168.1.3
    netmask 255.255.255.0
    broadcast 192.168.1.255
    gateway 192.168.1.1

Please note that the /etc/NetworkManager/nm-system-settings.conf managed is put to true during this whole time.

On Tue, Oct 21, 2008 at 04:31:41AM -0000, Shirish Agarwal wrote:
> Hi all,
> I dunno much about stuff but I got this while restarting networking (most of the times I think I'm on Auto DHCP but dunno how that works)
>
> sudo /etc/init.d/networking restart
> * Reconfiguring network interfaces... /etc/network/interfaces:5: misplaced option
> ifdown: couldn't read interfaces file "/etc/network/interfaces"
> /etc/network/interfaces:5: misplaced option
> ifup: couldn't read interfaces file "/etc/network/interfaces"
> [fail]
>
> These are the changes I had done on /etc/network/interfaces
>
> cat /etc/network/interfaces
> auto lo
> iface lo inet loopback
>
> auto eth1 inet static

  ^^ thats wrong

auth eth1
iface eth1 inet static

would be the right way.

 - Alexander

On Tue, Oct 21, 2008 at 05:49:15AM -0000, Shirish Agarwal wrote:
> hmm... ok hunted around and got this file
>
> /usr/share/doc/ifupdown/examples/generate-interfaces.pl.gz .
>
> ran it and it gave whole lot of stuff which I have included as an
> attachment
>
> The main part I put in the /etc/network/interfaces
>
> auto lo
> iface lo inet loopback
>
> iface eth1 inet static
> address 192.168.1.3
> netmask 255.255.255.0
> broadcast 192.168.1.255
> gateway 192.168.1.1

this configuration should work in managed=true mode. as there is no
auto eth1 it wont autoconnect though.

 - Alexander

Hi Alex,
so this would be right.

/etc/network/interfaces

auto lo
iface lo inet loopback

auth eth1
iface eth1 inet static
    address 192.168.1.3
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameserver 192.168.1.1

Then tried this :-

 sudo /etc/init.d/networking restart
 * Reconfiguring network interfaces... RTNETLINK answers: No such process
SIOCDELRT: No such process
WARNING: ifup -a is disabled in favour of NetworkManager.
   Set ifupdown:managed=false in /etc/NetworkManager/nm-system-settings.conf.

So this is right at the least saying that my connection is being managed by Network-Manager

Then did this :-

sudo /etc/init.d/NetworkManager restart
 * Stopping NetworkManager... [ OK ]
 * Starting NetworkManager... [ OK ]

Network Manager also did not complain so looks good.

But when I right click on nm-applet and click on edit connection (nm-connections-editor)

for eth1 it still shows me the connection as a dhcp connection and both connect automatically and system settings are checked.

(Stumped here)

Another thing why is the dns-nameserver taken as 192.168.1.1 . From what I understand of dns-nameserver they are usually something at the ISP's end. For e.g. my ISP's dns name-servers are 61.1.96.69 , 61.1.96.71 or sometimes use OpenDNS 208.67.222.222 and 208.67.220.220 . This information should be there, shouldn't it.

Also changing there the dns-nameservers there but it didn't do anything.

I restarted the Network-Manager service and still it shows dhcp connectivity .

Running into some other bugs, it seems dhcp is default for now, is this how its going to be for times to come?

On Wed, Oct 22, 2008 at 05:24:22AM -0000, Shirish Agarwal wrote:
> Hi Alex,
> so this would be right.
>
> /etc/network/interfaces
>
> auto lo
> iface lo inet loopback
>
> auth eth1
> iface eth1 inet static
> address 192.168.1.3
> netmask 255.255.255.0
> gateway 192.168.1.1
> dns-nameserver 192.168.1.1
>
> Then tried this :-
>
> sudo /etc/init.d/networking restart
> * Reconfiguring network interfaces... RTNETLINK answers: No such process
> SIOCDELRT: No such process
> WARNING: ifup -a is disabled in favour of NetworkManager.
> Set ifupdown:managed=false in /etc/NetworkManager/nm-system-settings.conf.
>
> So this is right at the least saying that my connection is being managed
> by Network-Manager
>
> Then did this :-
>
> sudo /etc/init.d/NetworkManager restart
> * Stopping NetworkManager... [ OK ]
> * Starting NetworkManager... [ OK ]

To reload your config you should do: sudo killall nm-system-settings
or restart your system.

Also if that doesnt work I need a full syslog after reproducing.

>
> Network Manager also did not complain so looks good.
>
> But when I right click on nm-applet and click on edit connection (nm-
> connections-editor)
>
> for eth1 it still shows me the connection as a dhcp connection and both
> connect automatically and system settings are checked.
>

How is that connection called? It should be "Ifupdown (...)".

> (Stumped here)
>
> Another thing why is the dns-nameserver taken as 192.168.1.1 . From what
> I understand of dns-nameserver they are usually something at the ISP's
> end. For e.g. my ISP's dns name-servers are 61.1.96.69 , 61.1.96.71 or
> sometimes use OpenDNS 208.67.222.222 and 208.67.220.220 . This
> information should be there, shouldn't it.
>

If you are using a router it should support dhcp and static IPs (nor
dns) shouldnt be necessary.

 - Alexander

Hi Alex,
 What do you know, it worked after couple of restarts, although most because of the dns-nameserver thing the connection didn't work. I will try again.

Using sudo dhclient for the time being.

Yes, the connection is now called ifupdown (eth1)

 Is there a way to name it in the file itself? If yes, how is that naming done, any ideas?

The ADSL router that I have is this one

http://www.sirindia.com/details.asp?ProductID=10142545

Another query but unrelated, what is pan0 ?

scratch that last query, came to know pan0 are for bluetooth devices.

http://fedoraforum.org/forum/showthread.php?t=193187

my comment above was half https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/259214/comments/29

Its a D-Link 502T ADSL router+modem. How I've set it up is computer > D-Link Ethernet Card (the other chipset/one is broken) > ADSL router+modem > Internet.

On Wed, Oct 22, 2008 at 12:34:20PM -0000, Shirish Agarwal wrote:
> Hi Alex,
> What do you know, it worked after couple of restarts, although most because of the dns-nameserver thing the connection didn't work. I will try again.
>
> Using sudo dhclient for the time being.
>
> Yes, the connection is now called ifupdown (eth1)
>
> Is there a way to name it in the file itself? If yes, how is that
> naming done, any ideas?

What is the problem here? Why do you want to rename it? The normal way
is to remove all config from interfaces and let NM do everything. Why
doesnt that work? Are there features you are missing?

 - Alexander

I am also unable to configure nm to keep a static IP address on a wired connection. Each reboot it changes back to dhcp.

OK, according this conversation, I set up eth0 with "system interface" disabled, close the network-manager windows, open it again and set "system interface" to enable. Only after that policy-tool asked me for sudo password, so I think, that the problem is, that network-manager does not update system-wide config file every time it alter the network settings. But I don;t know what to do with non-system settings.

I can confirm this bug. Problem persists even with latest updates.
Please, fix this.

Alexander, maby this bug is fixed in latest Network Manager 0.7.0-rc1 ?

http://ftp.gnome.org/pub/GNOME/sources/NetworkManager/0.7/

Can you, please build it and upload to PPA?

I found that you have to delete all the auto entries, then select new connection,
give it a name and select system tab.
Then go to the IPV4 tab and
manually enter all the IP, gateway, DNS etc and click OK

Once you reboot it's all there and the LAN connects on login.

> From: <email address hidden>
> To: <email address hidden>
> Date: Wed, 12 Nov 2008 15:02:08 +0000
> Subject: [Bug 259214] Re: wired connection settings are lost after reboot
>
> Alexander, maby this bug is fixed in latest Network Manager 0.7.0-rc1 ?
>
> http://ftp.gnome.org/pub/GNOME/sources/NetworkManager/0.7/
>
> Can you, please build it and upload to PPA?
>
> --
> wired connection settings are lost after reboot
> https://bugs.launchpad.net/bugs/259214
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “network-manager” source package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: network-manager
>
> Static IP, dns settings etc get lost after a reboot.
> It gets back to default (AUTO DHCP)
>
> Tested with latest Network Manager version from PPA

_________________________________________________________________
Time for change? Find your ideal job with SEEK.
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Atl%3Ask%3Anine%3A0%3Ahottag%3Achange&_t=757263783&_r=SEEK_tagline&_m=EXT

> I found that you have to delete all the auto entries, then select new connection,
> give it a name and select system tab.
> Then go to the IPV4 tab and
> manually enter all the IP, gateway, DNS etc and click OK
> Once you reboot it's all there and the LAN connects on login.

I've already tried that some days ago, but "Auto eth0" keeps coming back, and Enabled.

Auto eth0 will come back, because it is default config for specific card. Problem is in gaining root privileges to save system-wide config.
In Hardy with NM from ppa everything in this area worked, so I could create new config, assign it to specific card by mac-adress, then turn on "system setting" and autoconnection for it, with promting a root password. Then disable autoconnection for default configs.
Now I just have to click on needed custom config after every startup. So this bug results in two excessive clicks.

Summing up: Name of the bug is incorrct, IMHO, because custom settings are saved, but cannot be applied system-wide.
Also there is lack of feature: prevent deletion or editing of default configs (except autoconnection setting) , so many users can be confused when default configs come back and destroy settings, that were put in them.

Seriously, I can't believe that this annoying bug won't be fixed. 18 days have passed since Ubuntu 8.10 was released, and nothing was done. Ok, you can configure everything in /etc/networks/interfaces, but where is the "user-friendly" on that?

Somebody gave importance "Medium". Medium? This is internet configuration! Configure a PPPoE connection and choice to connect automatically every boot: it won't!
Internet connection is important, you know!!

And nobody is going to fix that... maybe Ubuntu 9.04 also comes with this damn bug.
I can't believe that. If it was little bug with Ekiga, with Gimp, no problem, but with Internet and Network Configuration, THIS is a BIG problem!!!

:(

Agreed, this has affected a large amount of people, just look at the amount of duplicate bug reports!
I've had this issue since August and it's still a problem.
As a hack around I've had to disable auto-eth0 and setup another interface with a static ip, but I have to log in to get it applied, so no networking until the user has logged in.
I also agree, that it should have been dealt with before 8.10 was released, this is a major issue, could someone (maybe Dupond Jean-Louis?) increase this to high importance?

Adjusting Importance to "High" according to the number of duplicates, the fact that it affect a default ubuntu installation and due to the /etc/network/interfaces workaround which is not accessible for a lot of ubuntu users, specifically since nm does not support /etc/network/interfaces anymore.

I can confirm that you can get the settings to save but you have to keep fiddling till your asked for admin privileges, as has been mentioned. It took me many times of clicking on/off of "Connect Automatically -> OK" and "System setting -> OK" before this finally happened. My manually configured settings now survive a reboot.

On Thu, Oct 16, 2008 at 04:29:29PM -0000, Christian Kirbach wrote:
> Citing Alex
> " you cannot save a auto generated connection. so you either have to rename it or to create a new one. then it should work"
>
> This is important to know then.
>

> Right. In fact read-only connections should be better marked in
> connection editor. We are missing that information however in the
> applet and only get an error upon saving. I am thinking about a
> solution and will discuss that with upstream. If we cannot find a fix
> in time for release, we will surely look into fixing this in form of a
> SRU.

> - Alexander

I think it's right.
I add a new connection, and set static address, then set it connect automatically, not system setting, the default 'Auto eth0' change to not connect automatically, save it.
Reboot, it's work.

Can we all rollback to network-manager 0.6 on intrepid ? It used to work soooooo well... Will it work with V0.6 ? Thank you

2 jokker - this is bad idea. Better upadate Network Manager to latest version (0.7.0-rc2)

where is this version ? it is not available on the official repos. Is it on backport or proposed ?

http://ftp.gnome.org/pub/GNOME/sources/NetworkManager/0.7/

> Better upadate Network Manager to latest version (0.7.0-rc2)

I built and installed this version of network-manager on my stock 8.10 system, and it screwed things up so that gnome could not launch applications. So I uninstalled network-manager altogether and configured manually in /etc/network/interfaces. That seems to work.

I tried that but it doesn't work. I have two NICs and with both enabled in interfaces I do not get DNS resolution. If only ONE (either) is enabled it works, go figure...

I agree,

I can actively use only one of my two interface cards, as the other
one does not resolve correctly. I ifdown and ifup the eppropriate
card msnually if want to use a particular card. Very annoying.

On Fri, Nov 21, 2008 at 8:06 PM, jokker <email address hidden> wrote:
> I tried that but it doesn't work. I have two NICs and with both enabled
> in interfaces I do not get DNS resolution. If only ONE (either) is
> enabled it works, go figure...
>
> --
> wired connection settings are lost after reboot
> https://bugs.launchpad.net/bugs/259214
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Stratos Gerakakis
Development Manager
Tel. +30 210 6378958
Mobile +30 697 4289828
e-mail <email address hidden>

Evorad S.A. - Medical Information Systems
42, Kifissias Ave.
151 25 Maroussi, Greece
Tel. +30 210 6378955
Fax +30 210 6378999
http://www.evorad.com

I can't believe this buggy nm thing is still buggy and included with Ubuntu. Is this a joke or what?
I had to fiddle for 30 minutes in order to have it asking me for credentials and finally saving the configuration: how can one be sure the configuration now will last?
What's the need for nm to have its own configuration files instead of relying on the traditional way of configuring networking on linux? Why is that?

Manuel, I agree with you. This bug was first reported in August. It's hard to complain about something that's free, but I wish a network-manager maintainer would at least comment on why it is taking so long to fix this bug and give some estimate of when the bug will be fixed.

Has anyone successfully disabled network manager and set up /etc/network/interfaces manually as a temporary fix?

Except for network-manager, Intrepid has gone very smoothly for me.

I found a workaround... just created a new connection with my static IP. It
takes it about 30 seconds to figure out which connection to use, but then it
connects, and works fine thereafter. Its a minor annoyance to me, but to an
inexperienced user, it would be a severe headache.
- E

On Thu, Nov 27, 2008 at 9:36 AM, sirius56 <email address hidden> wrote:

> Manuel, I agree with you. This bug was first reported in August. It's
> hard to complain about something that's free, but I wish a network-
> manager maintainer would at least comment on why it is taking so long to
> fix this bug and give some estimate of when the bug will be fixed.
>
> Has anyone successfully disabled network manager and set up
> /etc/network/interfaces manually as a temporary fix?
>
> Except for network-manager, Intrepid has gone very smoothly for me.
>
> --
> wired connection settings are lost after reboot
> https://bugs.launchpad.net/bugs/259214
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

"Has anyone successfully disabled network manager and set up /etc/network/interfaces manually as a temporary fix?"

I think we are all using interfaces for quite a long time now ;-)

In the Network Manager GUI, there are two boxes for checkmarks.

--Connect automatically

--System setting

Can someone please explain exactly what each of these options do?

Connect automatically means this connection to be applied as soon as possible after startup, without your assistance.
System settings means this connection is system-wide, not user's, so it is accessible and can be turned on by any user, or even before any user login.

I see people who do not understand this bug. (maybe I do not understand too, so correct me if I'm wrong) IMHO, name should be changed, because NM SAVES settings, but:
- It cannot save them system-wide because of this bug (so connection before login is impossible, automatic connection priority for custom setting is low, because default settings have system-wide status and used first)
- It can not change default connection, except "Connect automatically", because it is a feature. In ideal world without this bug, the only thing you need to do is to create new connection with your settings, make it system and automatic, and uncheck automatic for default connection, so default connection will not be used, but your custom will be. But in our buggy world you just need to click on your custom connection every time manually.

Psy[H[[,
Thank you for clear explanation.

On Mon, Dec 01, 2008 at 12:34:30PM -0000, sirius56 wrote:
>
> Psy[H[[,
> Thank you for clear explanation.
>

The problem here is that you cannot edit Auto connections. So just
create new connectoins. This is a well known bug and I have to fix
that individually in a backport.

 - Alexander

Hi all,

I tryed so many time to work around this bug that I'm not sure how I was able to do that, anyway this is the procedure I used (as far as I remember):
1) edit the /etc/NetworkManager/nm-system-settings.conf file and change the parameter managed=false in managed=true (see below)
[ifupdown]
managed=true

2) in Network Manager interface create a new "dummy" Wired connection using static IP address and name it "local Lan" or something like that
3) switch to the newly created connection "Local Lan" (this should release the "Auto Eth0" connection)
4) delete the "Auto Eth0" connection
5) create a third Connection with static IP (I called it "Static IP Local Lan") and check the "Connect Automatically" and "System Settings" boxes. This should create your new final Static IP connection with "System Settings" option enabled.
6) Check that the new connection configuration file has been created in "/etc/NetworkManager/system-connections" folder
7) If you find a file named "Static IP Local Lan" or whatever you chose for your connection name you have almost done.

maurik@buntu:~$ ls -la /etc/NetworkManager/system-connections
total 12
drwxr-xr-x 2 root root 4096 2008-12-06 15:43 .
drwxr-xr-x 4 root root 4096 2008-12-06 15:03 ..
-rw------- 1 root root 345 2008-12-06 15:43 Static IP Local Lan

8) Switch to the "Static IP Local Lan" and check that everithing is working (IP address, name servers, etc)
9) finally delete all the unused connection and try to reboot

This worked for me but don't ask me why. I think that you have to first release the default system connection creating a temporary connection and then create your own "System Connection" that will replace the default one.
I don't know if the managed=true parameter in /etc/NetworkManager/nm-system-settings.conf is needed, if you like try without changing it and let me know.

Good luck!

I'm assuming it's the same as my problem:

Right click on Network Manager tray icon
Edit Connections
Wired
Auto eth0
Edit
IPv4 Settings
Method: Automatic (DHCP) addresses only
Enter two servers in the DNS servers field (e.g. 1.2.3.4,5.6.7.8)
Enter something in the Search Domains box
OK

Click on the Network Manager tray icon
Click on Auto eth0
/etc/resolv.conf is updated according to manual settings

Reboot

Connection has gone back to Automatic (DHCP) and forgotten my DNS customizations

why do you try to edit or delete default connection?
just create new, it will not be lost.

Because that seemed most logical and it let me do it.

If creating a new connection is a workaround, then I'll do it, but that's still a bug IMO.

Indeed, this IS a bug, because you can create a new connection, but you can't set it to Auto Connect and System Settings.
Maybe the bug name could change the title, but it's still the same idea.

I'm sure this bug is annoying a lot of people... sadly, I'm thinking that Ubuntu 9.04 will have this bug as well... :(

Using network-manager 0.7.0-rc2 WITH network-manager-applet 0.7.0-rc2 from upstream

    http://ftp.gnome.org/pub/GNOME/sources/NetworkManager/0.7/
    http://ftp.gnome.org/pub/GNOME/sources/network-manager-applet/0.7/

seems to solve this issue. I have backported them in my PPA archive:

    https://launchpad.net/~snapy/+archive

You will probably need to backport or at least recompile other network-manager
related packages such as network-manager-kde, network-manager-pptp, openvpn,
etc.

I am not sure that the packages are 100% orthodox in terms of version numbers and
the like (lintian complained about some wrong version name and depreciated features).

All I basically did was copy the debian directory from the original intrepid package, refresh
(and sometimes readapt) the patches with quilt and launch the compilation.

Hoping that helps,

      Miguel

"Static IP, dns settings etc get lost after a reboot.
It gets back to default (AUTO DHCP)",

FYI, I find that the same Network Manager 0.7.0 bug exists for me in Fedora 10, Gnome Desktop.

This bug has been around for a long time. Anyone have any idea of how we can give the Network Manager developers some incentive to get this fixed?

sirius56 escribió:
> "Static IP, dns settings etc get lost after a reboot. It gets back to
> default (AUTO DHCP)",
>
> FYI, I find that the same Network Manager 0.7.0 bug exists for me in
> Fedora 10, Gnome Desktop.
>
>
> This bug has been around for a long time. Anyone have any idea of
> how we can give the Network Manager developers some incentive to get
> this fixed?
>

I would encourage them to backport the 0.7.0-rc2 upstream version from
Gnome. I have done it in the PPA[*] and the problem seems to be solved.

[*] https://launchpad.net/~snapy/+archive

This is just a proof of concept that the upstream version works. Now I
think it is up to the official package maintainers to do the packaging
according to all policy rules.

 Miguel

--
| (O-O)
---oOO-(_)-OOo-----------------------------------------------------
  Miguel TELLERIA DE ESTEBAN Personal Homepage:
  Email: Miguel at mtelleria.com http://www.mtelleria.com

  Miembro de http://www.linuca.org Tel home: +34 942 277429
  Membre de http://www.bxlug.be GSM: +34 650 801098
-------------------------------------------------------------------

On Sat, Dec 06, 2008 at 02:56:41PM -0000, Maurik wrote:
> Hi all,
>
> I tryed so many time to work around this bug that I'm not sure how I was able to do that, anyway this is the procedure I used (as far as I remember):
> 1) edit the /etc/NetworkManager/nm-system-settings.conf file and change the parameter managed=false in managed=true (see below)
> [ifupdown]
> managed=true

this part of your instruction is unrelated. Dont set that if you are
seeing the issue the bug title claims to be about.

Anyway, thanks for posting detailed infos. I guess its useful for some
users.

 - Alexander

On Tue, Dec 09, 2008 at 10:25:57AM -0000, Vitor Lamas Gatti wrote:
> Indeed, this IS a bug, because you can create a new connection, but you can't set it to Auto Connect and System Settings.
> Maybe the bug name could change the title, but it's still the same idea.
>
> I'm sure this bug is annoying a lot of people... sadly, I'm thinking
> that Ubuntu 9.04 will have this bug as well... :(
>

No, i am sure 9.04 will have this fixed.

 - Alexander

Maybe I found workaround to disable automatic connection for default system connections.
run nm-connection-editor from root:
sudo nm-connection-editor
you will gain root access to system connections, so you can disable autoconnect for them.
user's connections are not accessible from root, so there is no way to make them system this way.

still if user's connection has autoconnect, but system connections do not, then user's must connect first, I presume. Will see on next boot...

Strange, but it is still not possible to create system connection from root nm-connection-editor. System checkbox status for custom connection cannot be saved.

after restart of NetworkManager and networking autoconnection checkbox false status for system connections was saved.

I've talked to Dan Williams, the person that maintains this package in GNOME, and he said that the latest version, released 27-Nov-2008, doesn't have this bug.
You can find this version here:
http://ftp.gnome.org/pub/GNOME/sources/NetworkManager/0.7/

I couldn't manage to compile the source code by myself (I don't have too much experience on that). Who can test for us, please do that and let's warn the package maintainer at Ubuntu's repositories to fix this, implementing the newest version.

Wait a minute, if this bug is indeed fixed why is it not available in the official updates ? huh ?! I check updates every single day and no network-manager was updated so far... Can someone else confirm the famous bug fix with this new version of the package PLEASE ?

I just don't want to install another version in vain like I did many times in the past 70 days...

...workaround did not survive reboot :(
waiting for new package.

I figured... Also waiting for new package version in the official updates.

All of the others until now have been various release candidates and source control snapshots. The one from 26 November is the actual release package.

There are *many* changes in the code between our snapshots and now. I can't tell from the ChangeLog if/when this issue got resolved, and haven't checked source control.

Whether or not this is fixed, we ought to get this actual release into Jaunty, and it should be put into a PPA for testing and then backported to Intrepid if it makes sense.

I've found deleting the auto connection, the making a new static one
from scratch works fine. It seems it's just the initial auto one that
has permission problems. Making a new one for me works fine even as a
system setting as it asked for sudo when confirming.

Hope this helps.

--
Sam Jackson / Nandemonai / Junin Toiro

I've just tried this myself and its started working
(previously an auto connection was remade on boot up)

I don't know why the auto connection nuisance has gone away
but I'm most grateful that it has

Here's the steps I took, I deleted ALL connection
made 1 connection that was static with connect automatically
and systems setting selected and rebooted

I'm *sure* that I tried this before and it didn't work
so maybe there is some more subtle underlying problem
going on?

C

On Mon, 2008-12-15 at 14:02 +0000, nandemonai wrote:
> I've found deleting the auto connection, the making a new static one
> from scratch works fine. It seems it's just the initial auto one that
> has permission problems. Making a new one for me works fine even as a
> system setting as it asked for sudo when confirming.
>
> Hope this helps.
>
> --
> Sam Jackson / Nandemonai / Junin Toiro
>
--
Disclaimer:
By sending an email to ANY of my addresses you are agreeing that:

   1. I am by definition, "the intended recipient"

   2. All information in the email is mine to do with as I see fit and
make such financial profit, political mileage, or good joke as it lends
itself to. In particular, I may quote it where I please.

   3. I may take the contents as representing the views of your company.

   4. This overrides any disclaimer or statement of confidentiality that
may be included on your message.

On Fri, Dec 12, 2008 at 08:49:07AM -0000, Miguel Telleria de Esteban wrote:
> sirius56 escribió:
> > "Static IP, dns settings etc get lost after a reboot. It gets back to
> > default (AUTO DHCP)",
> >
> > FYI, I find that the same Network Manager 0.7.0 bug exists for me in
> > Fedora 10, Gnome Desktop.
> >
> >
> > This bug has been around for a long time. Anyone have any idea of
> > how we can give the Network Manager developers some incentive to get
> > this fixed?
> >
>
> I would encourage them to backport the 0.7.0-rc2 upstream version from
> Gnome. I have done it in the PPA[*] and the problem seems to be solved.

take care that we need a SONAME transition for 0.7 final ... so not as
trivial as it seems. If you see crashes after this, its mostlikely
because some apps/libs have not been recompiled/upgraded.

I plan to look into a real backport of 0.7.1 once that is out
... upstream did the required SONAME bump there.

 - Alexander

On Mon, Dec 15, 2008 at 01:57:31PM -0000, Noel J. Bergman wrote:
> All of the others until now have been various release candidates and
> source control snapshots. The one from 26 November is the actual
> release package.
>
> There are *many* changes in the code between our snapshots and now. I
> can't tell from the ChangeLog if/when this issue got resolved, and
> haven't checked source control.
>
> Whether or not this is fixed, we ought to get this actual release into
> Jaunty, and it should be put into a PPA for testing and then backported
> to Intrepid if it makes sense.
>

The issue is fixed upstream, but its none-trivial to backport those
changes, because upstream did last minute changes to the API ... the
easiest solution from here seems to be a full backport, but that also
puts more risks on us and requires a SONAME transition in a SRU (ouch!).

Current plan is: once I have 0.7 with soname bump in jaunty i will
provide backport and then based on feedback consider a SRU for that.

 - Alexander

The workaround of deleting the auto-eth0 connection, creating a new one and putting in it the correct HW address of the interface worked for me (0.7~~svn20081018t105859-0ubuntu1.8.10.1). Really a nasty bug; lost control over my office machine from home after a reboot...

I found a simple work around that simply avoids NetworkManager without removing it. I have not tried the workaround indicated above of deleting the auto eth0 configuration from Networkmanager's connections list and creating a new static configuration. In my case, eth0 is treated as "unmanaged" by NetworkManager. I've not read all of the posts in this thread so this may be a duplicate comment.

I just installed 8.10_amd64 as a clean install on a system previously running 8.04.1, and I also encountered this bug. I used a static configuration during installation from the 8.10 alternate amd64 installation CD. The configuration was written to /etc/network/interfaces in the newly installed system. While the IP address and default route of eth0, as reported by ifconfig and route -a, appear correct, no information for name servers is entered into /etc/resolv.conf. Pinging my gateway using its IP address works. Firefox returns a "Page Load Error" due to "Address Not Found".

Manually entering name server IP addresses into /etc/resolv.conf, or installing the package resolvconf, works around the difficulty. NetworkManager indicates there is no network connection (the "!" symbol is displayed by the applet) but so far all network functions are fine.

On Tue, Dec 16, 2008 at 04:52:36PM -0000, Romano Giannetti wrote:
> The workaround of deleting the auto-eth0 connection, creating a new one
> and putting in it the correct HW address of the interface worked for me
> (0.7~~svn20081018t105859-0ubuntu1.8.10.1). Really a nasty bug; lost
> control over my office machine from home after a reboot...
>

Sorry for the unpleasent incident though ... independent from this its
always a good idea to do a reboot run locally to check that everything
is working properly, before trying a remote reboot :)

 - Alexander

On Wed, Dec 17, 2008 at 02:29:47AM -0000, C David Rigby wrote:

> Manually entering name server IP addresses into /etc/resolv.conf, or
> installing the package resolvconf, works around the difficulty.
> NetworkManager indicates there is no network connection (the "!" symbol
> is displayed by the applet) but so far all network functions are fine.
>

Yes, a mixed setup is best dealt with by using resolvconf ...

 - Alexander

Here's what i did for wireless WPA(you have three options ):

A)
vim /etc/network/interfaces
add
auto wlan0
iface wlan0 inet dhcp
        wpa-driver wext
        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
(the only issue is it leaves you're hard drive in a bad state i.g.
device resource busy when shutting down);

B)

auto wlan0
iface wlan0 inet dhcp
wpa-ssid ?
wpa-bssid ?
wpa-psk ????????????????
wpa-key-mgmt ?
wpa-group ?
wpa-pairwise ?
wpa-proto ?

(this is nicer than "A" due to no device or resource busy
when shutting down);
more options are in /usr/share/doc/wpasupplicant/README.Debian

C)
vim /etc/network/interfaces
(comment and take everything out);

below info was taken from:
http://mail.gnome.org/archives/networkmanager-list/2008-July/msg00239.html
(I give them all the credit);
create a file that has this in it:

[802-11-wireless-security]
 key-mgmt=none
 wep-tx-keyidx=0
 auth-alg=open
 wep-key0=33b7af2400ba80f060f144e195
psk= ????????????????????
 [connection]
 id=Wireless connection 1
 type=802-11-wireless
 autoconnect=true
 timestamp=0

 [802-11-wireless]
 ssid=102;111;111;98;97;114;
 mode=infrastructure
 channel=0
 rate=0
 tx-power=0
 mtu=0
 security=802-11-wireless-security

 [ipv4]
 method=manual
 addresses1=192.168.1.2;24;192.168.1.1;
 routes1=192.168.1.2;24;192.168.1.1;
 ignore-dhcp-dns=false

then put this file in:

/etc/NetworkManager/system-connections/""

chmod 0400 "filenamethatyoucreated"

reboot

you should have internet during boot
with all of you're info reliably.

if you get confused you can always use

nm-system-settings
and
NetworkManager to test you're key file

to make sure it's working.

heres the finished results:

NetworkManager: <info> starting...
NetworkManager: <info> wlan0: driver is 'ath9k'.
NetworkManager: <info> wlan0: driver supports SSID scans (scan_capa 0x01).
NetworkManager: <info> Found new 802.11 WiFi device 'wlan0'.
NetworkManager: <info> (wlan0): exported as /org/freedesktop/Hal/devices/net_00_19_e3_06_2c_16
NetworkManager: <info> Trying to start the supplicant...
NetworkManager: <info> Trying to start the system settings daemon...
nm-system-settings: Loaded plugin keyfile: (c) 2007 - 2008 Red Hat, Inc. To report bugs please use the NetworkManager mailing list.
nm-system-settings: SCPlugin-Ifupdown: init!
nm-system-settings: SCPlugin-Ifupdown: update_system_hostname
nm-system-settings: SCPluginIfupdown: management mode: managed
nm-system-settings: SCPlugin-Ifupdown: devices added (udi: /org/freedesktop/Hal/devices/net_00_19_e3_06_2c_16, iface: wlan0)
nm-system-settings: SCPlugin-Ifupdown: end _init.
nm-system-settings: Loaded plugin ifupdown: (C) 2008 Canonical Ltd. To report bugs please use the NetworkManager mailing list.
nm-system-settings: SCPlugin-Ifupdown: (134630400) ... get_connections.
nm-system-settings: SCPlugin-Ifupdown: (134630400) connections count: 0
NetworkManager: <info> (wlan0): supplicant manager is now in state 1 (from 0).
NetworkManager: <info> (wlan0): device state change: 1 -> 2
NetworkManager: <info> (wlan0): bringing up device.
NetworkManager: <info> (wlan0): preparing device.
NetworkManager: <info> (wlan0): dea...

any reason why this isnt a dupe of the MASTER bug 284298?

seems that vice versa 0_o
This one is earlier.

Psy[H[] wrote:
> *** This bug is a duplicate of bug 284298 ***
> https://bugs.launchpad.net/bugs/284298
>
> seems that vice versa 0_o
> This one is earlier.
>
>
thats ok. thanks for pointing out though.

I had the same problem.

The procedures are:

Edit (as root) /etc/NetworkManager/nm-system-settings.conf:

1) Locate the lines

[ifupdown]
managed=false

2) And change the value for the attribute managed for true

[ifupdown]
managed=true

No problems for me now :)

rmedrado,

Your suggestion,

[ifupdown]
managed=true

is the only one that worked perfectly for me. I have been trying to get a fix for this annoying bug for months. So thank you very much.

Sorry, but not working for me... :-(

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=true

I tried it with network-manager-gnome and it worked much better....a bit more reliable...

I also spent a lot of time to figure out whats going with it...!
No wonder how many times I delete "Auto eth0" or disable its automatic connectivity, it gets recreated at the startup and changes to the static ip address are lost. In /etc/network/interfaces manually settings are also scrambled by Network Manager. This only happens to Ethernet however Wifi works great.
Sirius56, I'm going to try your suggestion out and if it works, I'll sure owe you a beer :D
(Waking up from last 30 hours, lol!)

Unfortunately, this didn't work out like Mustafa said.
I do have a manual solution for that, but you know what, the crappy NetworkManager sets /etc/resolv.conf's permissions back to normal and my start up session script cannot make changes to add the dns resolvers properly. Craptastic, lol!

route del default
route add default gw 192.13.13.3
echo "nameserver 192.13.13.3" >> /etc/resolv.conf

On Sun, Mar 08, 2009 at 12:48:45PM -0000, Bassu Khan wrote:
> *** This bug is a duplicate of bug 284298 ***
> https://bugs.launchpad.net/bugs/284298
>
> Unfortunately, this didn't work out like Mustafa said.
> I do have a manual solution for that, but you know what, the crappy NetworkManager sets /etc/resolv.conf's permissions back to normal and my start up session script cannot make changes to add the dns resolvers properly. Craptastic, lol!
>
> route del default
> route add default gw 192.13.13.3
> echo "nameserver 192.13.13.3" >> /etc/resolv.conf
>

use resolvconf to setup defaults ... or use the connection editor to
set your custom DNS/gw ... its a bit tricky, b ut it works.

 - Alexander

I did pretty much all of the above, and the DNS always switched back upon reboot. Until I found this tutorial right here. Never have that problem anymore, PERIOD. I'm running Ubuntu 8.10 kernel 2.6.27-11

Answer is here: http://www.prash-babu.com/2008/04/how-to-configure-dns-servers-in-linux.html

>use resolvconf to setup defaults ... or use the connection editor to
>set your custom DNS/gw ... its a bit tricky, b ut it works.
> - Alexander

I already achieved the goal without using resolvconf or by editing the custom dns/gw because I don't want to remove NetworkManager

Here is how i did it. I simply put my username into `no pass required for global group` section of sudoers and added that group to /etc/sudoers:

# Members of the admin group may gain root privileges
%abbas ALL= NOPASSWD: /bin/chmod, /sbin/reboot, /sbin/halt, /sbin/poweroff
sudo ALL=NOPASSWD: ALL

(nevermind those reboot, halt and poweroff - it actually saves me some seconds while doing WOL stuff ;))

This then gave me power of modifying the /etc/resolve.config whose permissions are always set to root whenvever buggy NetworkManager pop up or works out (lol for not in a way it should)
So, my machine changes the dns servers to what I define at the startup so easily ;)

Then, the default gateway, which I simply deleted and added by by using "route" (of course /sbin/route has been suid'ed for everyone) instructing through:
route del default gw x.x.x.x.x (removes the one which is seutp by by buggy NetworkManager at startup)
route add default gw x.x.x.x.x (adds what i want)

And boom, my machine goes live on the internet at the startup after getting instructions to wakeonlan.... :D

-Abbas Khan