I updated an old laptop to bookworm - but on reboot the hard-wired
ethernet connection wouldn't work. Trying to manually configure the
networking via
nmcli c edit eth0
appeared to work ('print' gave the right values) BUT networking still
didn't work. Old standby /sbin/ifconfig showed the old/wrong values
even after restarting networking. On finally trying
nmcli c show
it showed not 1 but 2 entries for eth0 - though with different UUIDs. Attempting to delete/remove the connection entry with the wrong data
simply caused the defective connection entry to be replicated, only now
with yet another UUID. It is this erroneous connection entry that
appears connected to the eth0 device.

Is there some magic I'm missing for setting the ipv4 parameters?

Thanks for any insights!
-F

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 26 May 2025 12:20:22 -0700
accipiter <pedicularis@mail.com> wrote:

it showed not 1 but 2 entries for eth0 - though with different UUIDs.

If you are using Network Manager, you should not have anything else
setting up interfaces that NM manages for you. What did you use for the
purpose in the past?

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/26/25 6:20 PM, Charles Curley wrote:

On Mon, 26 May 2025 12:20:22 -0700
accipiter <pedicularis@mail.com> wrote:

it showed not 1 but 2 entries for eth0 - though with different UUIDs.

If you are using Network Manager, you should not have anything else
setting up interfaces that NM manages for you. What did you use for the purpose in the past?

In the past it was the old standard /etc/network/interfaces setup. I
had commented-out all the lines associated with 'eth0', but it's
possible there's something that I haven't adequately killed off. Is
there some way to ensure that's thoroughly dead without messing up NetworkManager?

Thanks for the idea!
-F

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 26 May 2025 20:46:37 -0700
accipiter <pedicularis@mail.com> wrote:

If you are using Network Manager, you should not have anything else
setting up interfaces that NM manages for you. What did you use for
the purpose in the past?

In the past it was the old standard /etc/network/interfaces setup. I
had commented-out all the lines associated with 'eth0', but it's
possible there's something that I haven't adequately killed off. Is
there some way to ensure that's thoroughly dead without messing up NetworkManager?

Commenting out the appropriate stanza in /e/n/i should do it. But it
wouldn't hurt to check it now in case the upgrade uncommented it.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/26/25 7:40 PM, Max Nikulin wrote:

On 27/05/2025 02:20, accipiter wrote:

    nmcli c edit eth0

[...]

Attempting to delete/remove the connection entry with the wrong data
simply caused the defective connection entry to be replicated, only
now with yet another UUID.

Is there a chance that NetworkManager is under control of netplan.io in
your case?

Commands from https://wiki.debian.org/NetworkManager#Troubleshooting
might help to figure out what goes wrong in your case.

I know nothing about netplan.io - will explore that.
I haven't tried journalctl in the way that link describes. Will try that..

Thanks for your ideas!
-F

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Mon, May 26, 2025 at 08:46:37PM -0700, accipiter wrote:

In the past it was the old standard /etc/network/interfaces setup. I had commented-out all the lines associated with 'eth0', but it's possible
there's something that I haven't adequately killed off. Is
there some way to ensure that's thoroughly dead without messing up NetworkManager?

Show us the /etc/network/interfaces file and anything you have in /etc/network/interfaces.d/ if that is still included from /e/n/i.

Any time I've seen this sort of thing happen it's been because something
else is bringing up a network interface before NetworkManager takes
control of it.

There was also this (11 year old) bug report where someone has
macchanger installed which was changing the MAC address of their eth0
every time the interface went down, which caused N-M to think the
normal eth0 was a new interface next time.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771077

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, May 26, 2025 at 20:46:37 -0700, accipiter wrote:

On 5/26/25 6:20 PM, Charles Curley wrote:

On Mon, 26 May 2025 12:20:22 -0700
accipiter <pedicularis@mail.com> wrote:

it showed not 1 but 2 entries for eth0 - though with different UUIDs.

If you are using Network Manager, you should not have anything else
setting up interfaces that NM manages for you. What did you use for the purpose in the past?

In the past it was the old standard /etc/network/interfaces setup. I had commented-out all the lines associated with 'eth0', but it's possible
there's something that I haven't adequately killed off. Is
there some way to ensure that's thoroughly dead without messing up NetworkManager?

If you're using DHCP (most people are), there will be a DHCP client
daemon started when the interface is brought up. If you commented
out the lines in the file *before* bringing the interface down, then
the daemon is left running, and ifupdown doesn't know about it,
since the lines that would have told it "hey, there's a daemon you
need to manage" have been commented out.

In that situation, you'll need to find the daemon and kill it.
Rebooting would also take care of that, of course.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/26/25 9:40 PM, Charles Curley wrote:

On Mon, 26 May 2025 20:46:37 -0700
accipiter <pedicularis@mail.com> wrote:

If you are using Network Manager, you should not have anything else
setting up interfaces that NM manages for you. What did you use for
the purpose in the past?

In the past it was the old standard /etc/network/interfaces setup. I
had commented-out all the lines associated with 'eth0', but it's
possible there's something that I haven't adequately killed off. Is
there some way to ensure that's thoroughly dead without messing up
NetworkManager?

Commenting out the appropriate stanza in /e/n/i should do it. But it
wouldn't hurt to check it now in case the upgrade uncommented it.

Yep, still commented-out.
-F

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/26/25 11:10 PM, Andy Smith wrote:

Hi,

On Mon, May 26, 2025 at 08:46:37PM -0700, accipiter wrote:

In the past it was the old standard /etc/network/interfaces setup. I had
commented-out all the lines associated with 'eth0', but it's possible
there's something that I haven't adequately killed off. Is
there some way to ensure that's thoroughly dead without messing up
NetworkManager?

Show us the /etc/network/interfaces file and anything you have in /etc/network/interfaces.d/ if that is still included from /e/n/i.

Any time I've seen this sort of thing happen it's been because something
else is bringing up a network interface before NetworkManager takes
control of it.

There was also this (11 year old) bug report where someone has
macchanger installed which was changing the MAC address of their eth0
every time the interface went down, which caused N-M to think the
normal eth0 was a new interface next time.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771077

Thanks,
Andy

The only non-commented lines in /etc/network/interfaces:
auto lo
iface lo inet loopback

-F

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/26/25 11:10 PM, Andy Smith wrote:

Hi,

On Mon, May 26, 2025 at 08:46:37PM -0700, accipiter wrote:

In the past it was the old standard /etc/network/interfaces setup. I had
commented-out all the lines associated with 'eth0', but it's possible
there's something that I haven't adequately killed off. Is
there some way to ensure that's thoroughly dead without messing up
NetworkManager?

Show us the /etc/network/interfaces file and anything you have in /etc/network/interfaces.d/ if that is still included from /e/n/i.

Any time I've seen this sort of thing happen it's been because something
else is bringing up a network interface before NetworkManager takes
control of it.

There was also this (11 year old) bug report where someone has
macchanger installed which was changing the MAC address of their eth0
every time the interface went down, which caused N-M to think the
normal eth0 was a new interface next time.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771077

Thanks,
Andy

Oh - sorry forgot: there's *nothing* in /etc/network/interfaces.d/

In /etc/NetworkManager/system-connections/ there is a file:
eth0.nmconnection which appears to have the "right stuff" - pointing to
the UUID of the connection that I want.

-F

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/26/25 7:40 PM, Max Nikulin wrote:

On 27/05/2025 02:20, accipiter wrote:

    nmcli c edit eth0

[...]

Attempting to delete/remove the connection entry with the wrong data
simply caused the defective connection entry to be replicated, only
now with yet another UUID.

Is there a chance that NetworkManager is under control of netplan.io in
your case?

Commands from https://wiki.debian.org/NetworkManager#Troubleshooting
might help to figure out what goes wrong in your case.

This is weird.
Looking at the Debian troubleshooting recommendations (thanks for the reference!) - I started looking at the journalctl -b output. To my
surprise, there were some lines from dhcpcd . What??? So I disabled
that with systemctl - then retried the nmcli edit process.

At first it didn't seem to do any good, mis-replicating the eth0
connection when I killed that particular eth0 using its UUID. But then
I tried killing *both* eth0 connections, then trying to re-edit / create
the eth0 connection - and I was left with just a single connection!!
Restarting the networking (/etc/init.d/networking restart) *seemed* to
have an initially correct setup as ifconfig showed the right IP
addressing. But nmcli showed 2 addresses - the manual one that I
wanted, and additionally 169.254.220.204 and wrong gateway/routing. And
I couldn't ping my gateway.

Looking once more using *nmcli c show eth0* showed the right settings
for ipv4 parameters, but also had IP4 parameters with the 169.254...
crap. And at least my initial attempt failed when I tried to delete
these (capitalized) IP4 and GENERAL parameters.

Maybe I'm closer????

Thanks all!!
-F

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------YLtiSkQ3bL0jToZ9NVdxEZjl
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

DQpPbiA1LzI2LzI1IDE0OjIwLCBhY2NpcGl0ZXIgd3JvdGU6DQo+IEF0dGVtcHRpbmcgdG8g ZGVsZXRlL3JlbW92ZSB0aGUgY29ubmVjdGlvbiBlbnRyeSB3aXRoIHRoZSB3cm9uZyBkYXRh DQo+IHNpbXBseSBjYXVzZWQgdGhlIGRlZmVjdGl2ZSBjb25uZWN0aW9uIGVudHJ5IHRvIGJl IHJlcGxpY2F0ZWQsIG9ubHkgDQo+IG5vdyB3aXRoIHlldCBhbm90aGVyIFVVSUQuwqAgSXQg aXMgdGhpcyBlcnJvbmVvdXMgY29ubmVjdGlvbiBlbnRyeSB0aGF0IA0KPiBhcHBlYXJzIGNv bm5lY3RlZCB0byB0aGUgZXRoMCBkZXZpY2UuDQpJIGhhZCBhIHNpbWlsYXIgcHJvYmxlbSBq dXN0IHllc3RlcmRheS4gQ291bGQgbm90IHJlbWVtYmVyIHdoYXQgYWxsIEkgDQpkaWQgdG8g aXQgaW4gdGhlIHBhc3QgeWVhciwgSSBkbyBrbm93IEkgaGFkIG1ham9ybHkgbW9kaWZpZWQg dGhlIA0KbmV0d29ya2luZy4gSSBjb21wbGV0ZWx5IHJlZGlkIHRoZSBuZXR3b3JrIGNvbmZp Z3MgYnV0IHN0aWxsIGhhZCB0aGUgaXAgDQphZGRyZXNzIGdvaW5nIGJhY2sgdG8gdGhlIHBy ZXZpb3VzIHNldHVwLiBHYXZlIHVwIG9uIGl0IGFuZCB3aXBlZCB0aGUgDQpoYXJkIGRyaXZl IGFuZCByZWluc3RhbGxlZCBEZWJpYW4gMTIuIE5vdyBldmVyeXRoaW5nIHdvcmtzIGdyZWF0 Lg0KDQotLSANCg0KVGl0dXMgTmV3c3dhbmdlcg0KQ3VydGlzcyBXSQ0KDQo=

--------------YLtiSkQ3bL0jToZ9NVdxEZjl--

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEJ2LwHADW3dTgtISCFzZcx+xPw+YFAmg2dlkFAwAAAAAACgkQFzZcx+xPw+Zh DA//QmC0fcjIPKrm0P0ba83yQ8DDnkk7PoN0zUZqNPQgkwKgN7wKtVgBY9tEgUiGvXs/hvVgswnw 51oF2qrur1w7TMeOnOvf79zMd08tAd8jrETdDQbFQoc+fMTSPz3+QvCvFErx/16FMmf3lwVDPW96 7bE6wp/VVIYcOuNeQZSgxyN2ZNjJylrL/SI2GwtkIjkagK/3bUUidQ/3hMXgwX/mZ28MT/dV7uHY zbmkqq1gSJcwr7KrweQFb/0jXDVvHupep2yl6hmsYP26J5CZKxR0sxz+lSALiTHzKvxHI9I5eVJ4 vVRLwzcg/gUSTSU2op81E+f9DojZnMQmNiXHCM+//qiaPE6+3N+us+OLuhSJ7jvWarAFwQiwunP0 P1tqmGpb7N2Ey70yHiEabEYjBbc+iuZnQgQKRAu++ZSKZMCPLDaHJKUhMSPIivWjpoPTj7Jp7Q9o tFgfCzLV5gnhRv+3YgF2eJO3hT+Cn9Y8FoKKBPENZTuxev7buBY6hLxMEW8daOTFSWFLtmk8aMfT LaBhEeQZ6nCiEGVmmBWPLaPPipp2LyyTZdUbRgSO24NtiRRn12rclnf2Mx9icxpQkasd5XhZUSli malYChI4uDAaZVSEmixEb80TUlsr7Wkab8tdCUtCsElNg+OlVRc0BdrUkS7M+QlsWl5o9ED1oDxi qSQ=
=Yw0W
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, May 27, 2025 at 19:06:22 -0700, accipiter wrote:

At first it didn't seem to do any good, mis-replicating the eth0 connection when I killed that particular eth0 using its UUID. But then I tried killing *both* eth0 connections, then trying to re-edit / create the eth0 connection - and I was left with just a single connection!!
Restarting the networking (/etc/init.d/networking restart) *seemed* to have an initially correct setup as ifconfig showed the right IP addressing. But nmcli showed 2 addresses - the manual one that I wanted, and additionally 169.254.220.204 and wrong gateway/routing. And
I couldn't ping my gateway.

Aha! See, when you actually post *details*, we can start to make some progress.

An IP address in the 169.254.x.y network is self-assigned by an interface
when it wants to get a DHCP address, but is unable to get a response from
a DHCP server.

So, you have two things going on here:

* The interface is configured to try DHCP.
* The DHCP client is not getting a response.

Other people may be able to offer additional insights. This isn't a
problem I've experienced first-hand. I only know about it from others
on this mailing list.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/27/25 7:40 PM, Titus Newswanger wrote:

On 5/26/25 14:20, accipiter wrote:

Attempting to delete/remove the connection entry with the wrong data
simply caused the defective connection entry to be replicated, only
now with yet another UUID.  It is this erroneous connection entry that
appears connected to the eth0 device.

I had a similar problem just yesterday. Could not remember what all I
did to it in the past year, I do know I had majorly modified the
networking. I completely redid the network configs but still had the ip address going back to the previous setup. Gave up on it and wiped the
hard drive and reinstalled Debian 12. Now everything works great.

It may come to that. Hate to do it, there are some old bits that I've
been using to interact with some specialized hardware - it's the whole
reason why I keep this 14-yo machine. I can *probably* reconstruct but
there's a finite probability that I'll miss something that I didn't
backup. Without a network connection it all gets harder.

It seems likely that there's some detritus from one or more prior
versions of Debian that's screwing things up, but I'm not knowledgeable
enough to figure it out.

This morning's reboot - networking reports via ifconfig and nmcli look
better (right IP#, gateway, /etc/resolv.conf set properly once I use
nmcli to force the device to connect, but can't ping the gateway nor
does pinging this system from other host get any reply.

Thanks to everyone for your suggestions!! I'll make a few more attempts
before the total rebuild but I'm not optimistic.

-F

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 28 May 2025, accipiter wrote:

On 5/27/25 7:40 PM, Titus Newswanger wrote:

On 5/26/25 14:20, accipiter wrote:

Attempting to delete/remove the connection entry with the wrong data
simply caused the defective connection entry to be replicated, only
now with yet another UUID.  It is this erroneous connection entry that
appears connected to the eth0 device.

I had a similar problem just yesterday. Could not remember what all I
did to it in the past year, I do know I had majorly modified the
networking. I completely redid the network configs but still had the ip
address going back to the previous setup. Gave up on it and wiped the
hard drive and reinstalled Debian 12. Now everything works great.

It may come to that. Hate to do it, there are some old bits that I've
been using to interact with some specialized hardware - it's the whole
reason why I keep this 14-yo machine. I can *probably* reconstruct but there's a finite probability that I'll miss something that I didn't
backup. Without a network connection it all gets harder.

It seems likely that there's some detritus from one or more prior
versions of Debian that's screwing things up, but I'm not knowledgeable enough to figure it out.

This morning's reboot - networking reports via ifconfig and nmcli look
better (right IP#, gateway, /etc/resolv.conf set properly once I use
nmcli to force the device to connect, but can't ping the gateway nor
does pinging this system from other host get any reply.

Thanks to everyone for your suggestions!! I'll make a few more attempts before the total rebuild but I'm not optimistic.

-F

i've been watching this thread and i can't figure it out
why is using network manager so important

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/28/25 17:06, accipiter wrote:

On 5/27/25 7:40 PM, Titus Newswanger wrote:

On 5/26/25 14:20, accipiter wrote:

Attempting to delete/remove the connection entry with the wrong data
simply caused the defective connection entry to be replicated, only
now with yet another UUID.  It is this erroneous connection entry
that appears connected to the eth0 device.

I had a similar problem just yesterday. Could not remember what all I
did to it in the past year, I do know I had majorly modified the
networking. I completely redid the network configs but still had the
ip address going back to the previous setup. Gave up on it and wiped
the hard drive and reinstalled Debian 12. Now everything works great.

It may come to that.  Hate to do it, there are some old bits that I've
been using to interact with some specialized hardware - it's the whole
reason why I keep this 14-yo machine.  I can *probably* reconstruct
but there's a finite probability that I'll miss something that I
didn't backup.  Without a network connection it all gets harder.

It seems likely that there's some detritus from one or more prior
versions of Debian that's screwing things up, but I'm not
knowledgeable enough to figure it out.

This morning's reboot - networking reports via ifconfig and nmcli look
better (right IP#, gateway, /etc/resolv.conf set properly once I use
nmcli to force the device to connect, but can't ping the gateway nor
does pinging this system from other host get any reply.

Thanks to everyone for your suggestions!!  I'll make a few more
attempts before the total rebuild but I'm not optimistic.

Classic route error. NM's favorite error.

look at "ip r", anything in the 169.xxx.yyy.zzz needs to go. I put all
my stuff at 192.168,yyy.zzz and remove avahi. & cups-browsed  That block
of 65535 addresses does not get thru the router w/o a NAT entry in the
router, and generally just works. Even my 3d printers running klipper
are able to browse the internet. Keeping them uptodate can be done from
their own keyboard or an ssh link from this main machine.

  -F

.

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)