[opensuse] Network manager does not restore same connection
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On return from hibernation, Network Manager doesn't restore the same connection that was active. I have two eth network configurations: one automatic, which is the default one, and one fixed, in which I define the address and other things. I'm using "Fixed", but if I hibernate and restore I get "wired connection 1", ie dhcp. I'm going to the undefine "wired connection 1" the setting "connect to this network when available", but then maybe it will not connect to anyone. [...] Confirmed, then I get "no connection". I may try to set both as default, see which one gets it... [...] Well, it was the "Fixed" one. - -- Cheers Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlsrZQIACgkQtTMYHG2NR9XydwCfbKg5kl7z+STQvt2vsh9xcC0I s74AnjIFYBG5ecKSdRkexICA9fu5WrCy =W5z/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/21/2018 01:42 AM, Carlos E. R. wrote:
Hi,
On return from hibernation, Network Manager doesn't restore the same connection that was active.
I have two eth network configurations: one automatic, which is the default one, and one fixed, in which I define the address and other things. I'm using "Fixed", but if I hibernate and restore I get "wired connection 1", ie dhcp.
I'm going to the undefine "wired connection 1" the setting "connect to this network when available", but then maybe it will not connect to anyone. [...] Confirmed, then I get "no connection". I may try to set both as default, see which one gets it... [...] Well, it was the "Fixed" one.
I'm going to suggest that was intentional. People hibernate (and/or suspend)machines mostly to travel, home to work, on the road, etc. Expecting the same connection to be available, and preferred upon resume seems a corner case rather than the normal case. The IP set (manually or via DHCP) should never be trusted upon a resume. You may have moved from one network to another. I think network disconnect is the norm upon suspend/hibernate. And given that, then network initialization and connection would be the norm upon resume. If you have two separate cat5 jacks on the machine, they might come up in random order unless you take measures to prevent that. There is also a built in preference for a wired connection over a wifi. So I think you are expecting the exact prior state, but the system is designed to seek out the best new state. -- After all is said and done, more is said than done.
On 2018-06-21 22:44, John Andersen wrote:
On 06/21/2018 01:42 AM, Carlos E. R. wrote:
Hi,
On return from hibernation, Network Manager doesn't restore the same connection that was active.
I have two eth network configurations: one automatic, which is the default one, and one fixed, in which I define the address and other things. I'm using "Fixed", but if I hibernate and restore I get "wired connection 1", ie dhcp.
I'm going to the undefine "wired connection 1" the setting "connect to this network when available", but then maybe it will not connect to anyone. [...] Confirmed, then I get "no connection". I may try to set both as default, see which one gets it... [...] Well, it was the "Fixed" one.
I'm going to suggest that was intentional. People hibernate (and/or suspend)machines mostly to travel, home to work, on the road, etc. Expecting the same connection to be available, and preferred upon resume seems a corner case rather than the normal case. The IP set (manually or via DHCP) should never be trusted upon a resume. You may have moved from one network to another.
That is debatable. Many people use a laptop at home instead of a desktop machine, and the laptop is sitting permanently on a table in the sitting room, occasionally going somewhere. And it is normal to hibernate machines when not in use, some do so automatically after a period of not being used. It is perfectly valid to verify if the conditions before are still valid after, and if they are, restore the connections, and if not, find new ones. If the connection is wifi, it is of course easy to verify if the same SSID is available. On wire I don't know, but the assumption that if it is connected by wire before and after the wire is the same one is perfectly valid. Otherwise, the correct thing to do is ask the user, if wires can not be identified. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/22/2018 04:44 AM, Carlos E. R. wrote:
I'm going to suggest that was intentional. People hibernate (and/or suspend)machines mostly to travel, home to work, on the road, etc. Expecting the same connection to be available, and preferred upon resume seems a corner case rather than the normal case. The IP set (manually or via DHCP) should never be trusted upon a resume. You may have moved from one network to another. That is debatable. Many people use a laptop at home instead of a desktop machine, and the laptop is sitting permanently on a table in the sitting room, occasionally going somewhere. And it is normal to hibernate machines when not in use, some do so automatically after a period of not being used.
It is perfectly valid to verify if the conditions before are still valid after, and if they are, restore the connections, and if not, find new ones.
I tend to agree with Carlos here. If I put my laptop to sleep at home, I expect that it will come back up with the same connection it went to sleep with. I have multiple adapters configured as well. You don't see windows going to sleep connected to Wi-fi and then awaking connected to a non-plugged in wired connection... While I see the logic in the John's reasoning, I haven't seen any threads that have gotten wide-spread review of dhcpcd spoofing on awakening from sleep. If you are not coming back from sleep connected to the same connection -- that's a problem. There has always been a bit of lack of gracefulness in the way Linux apps handle the recovery from sleep that seem to have been solved long ago on the dark side. I have not done any specific coding regarding return from sleep, but I suspect there is a common framework in windoze that apps can call to determine the connection state on wake-up that doesn't have a Linux companion that app developers have made wide-spread use of. (I have no doubt there is a companion, but given the diversity in the origin of apps for Linux, there isn't any coordinated push for all apps to make use of it) I'll have to do more testing, but the times I have put 42.3 to sleep, it has always come back up with the correct connection. (I generally just leave it idling due to the ssh connections I have open normally -- I have a konsole dcop script that restores all my tabs and automatically makes the connections to the list of hosts specified). I have 15 virtualized, but not on metal, so I haven't tested there. -- David C. Rankin, J.D.,P.E.
On 2018-06-23 07:31, David C. Rankin wrote:
On 06/22/2018 04:44 AM, Carlos E. R. wrote:
I'm going to suggest that was intentional. People hibernate (and/or suspend)machines mostly to travel, home to work, on the road, etc. Expecting the same connection to be available, and preferred upon resume seems a corner case rather than the normal case. The IP set (manually or via DHCP) should never be trusted upon a resume. You may have moved from one network to another. That is debatable. Many people use a laptop at home instead of a desktop machine, and the laptop is sitting permanently on a table in the sitting room, occasionally going somewhere. And it is normal to hibernate machines when not in use, some do so automatically after a period of not being used.
It is perfectly valid to verify if the conditions before are still valid after, and if they are, restore the connections, and if not, find new ones.
I tend to agree with Carlos here. If I put my laptop to sleep at home, I expect that it will come back up with the same connection it went to sleep with. I have multiple adapters configured as well. You don't see windows going to sleep connected to Wi-fi and then awaking connected to a non-plugged in wired connection...
While I see the logic in the John's reasoning, I haven't seen any threads that have gotten wide-spread review of dhcpcd spoofing on awakening from sleep.
It might try on wake up DHCP on a new network that requires a different type of DHCP with password, and if not the network emails the admin with "intruder alert". If the location is different it should ask, IMO.
If you are not coming back from sleep connected to the same connection -- that's a problem.
It kills the existing NFS connection, different IP...
There has always been a bit of lack of gracefulness in the way Linux apps handle the recovery from sleep that seem to have been solved long ago on the dark side. I have not done any specific coding regarding return from sleep, but I suspect there is a common framework in windoze that apps can call to determine the connection state on wake-up that doesn't have a Linux companion that app developers have made wide-spread use of. (I have no doubt there is a companion, but given the diversity in the origin of apps for Linux, there isn't any coordinated push for all apps to make use of it)
I don't think there is a common frame in Linux: When I return from hibernation, some daemons complain: <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18762 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18757 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18762 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18756 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18762 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18756 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18762 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18753 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18759 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18762 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18772 seconds Obviously dovecot was not aware the machine hibernated. I would expect, for instance, a signal named "SIGNTHAW" and applications capturing it and handling the event graciously.
I'll have to do more testing, but the times I have put 42.3 to sleep, it has always come back up with the correct connection. (I generally just leave it idling due to the ssh connections I have open normally -- I have a konsole dcop script that restores all my tabs and automatically makes the connections to the list of hosts specified). I have 15 virtualized, but not on metal, so I haven't tested there.
It is working now here, but I had to define both wired connection (fixed and dhcp) as "use this connection if available", so both compete on restore and who wins? I hope the previous one. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/23/2018 03:16 AM, Carlos E. R. wrote:
It might try on wake up DHCP on a new network that requires a different type of DHCP with password
Since when does DHCP require a password? You're not thinking of a domain controller, which requires something beyond DHCP are you? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 06/23/2018 03:16 AM, Carlos E. R. wrote:
It might try on wake up DHCP on a new network that requires a different type of DHCP with password
Since when does DHCP require a password?
I was wondering about that one too, I don't know of any dhcp implementation that requires a password. I wonder if Carlos meant one of those setups where at first you only get access to a login webpage. After authentication, you then have full access. -- Per Jessen, Zürich (19.3°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-23 20:58, Per Jessen wrote:
James Knott wrote:
On 06/23/2018 03:16 AM, Carlos E. R. wrote:
It might try on wake up DHCP on a new network that requires a different type of DHCP with password
Since when does DHCP require a password?
I was wondering about that one too, I don't know of any dhcp implementation that requires a password.
I wonder if Carlos meant one of those setups where at first you only get access to a login webpage. After authentication, you then have full access.
I have been on networks where only authorized computers get an address. I don't remember any with password, though. The one I remember best the computer had to boot from network to be authorized; if it booted independently there was no auth. I was very lowly to know how exactly it worked. However, if you google "dhcp password" there are many hits, several to say no, but some say yes: https://www.juniper.net/documentation/en_US/junos/topics/reference/configura... -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Le 24/06/2018 à 12:31, Carlos E. R. a écrit :
computer had to boot from network to be authorized; if it booted independently there was no auth. I was very lowly to know how exactly it worked.
but most fixed IP should work, then :-( jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-24 12:33, jdd@dodin.org wrote:
Le 24/06/2018 à 12:31, Carlos E. R. a écrit :
computer had to boot from network to be authorized; if it booted independently there was no auth. I was very lowly to know how exactly it worked.
but most fixed IP should work, then :-(
On that place, only authorized machines got an IP. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/24/2018 06:51 AM, Carlos E. R. wrote:
On that place, only authorized machines got an IP.
That's easy enough to do based on MAC address. With some DHCP servers you can create a list of MACs to allow or deny. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 24/06/2018 à 12:54, James Knott a écrit :
On 06/24/2018 06:51 AM, Carlos E. R. wrote:
On that place, only authorized machines got an IP.
That's easy enough to do based on MAC address. With some DHCP servers you can create a list of MACs to allow or deny.
but you don't need to ask the dhcp to give an address :-) only a firewall or proxy can filter out IP's (I think) jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/24/2018 06:59 AM, jdd@dodin.org wrote:
Le 24/06/2018 à 12:54, James Knott a écrit :
On 06/24/2018 06:51 AM, Carlos E. R. wrote:
On that place, only authorized machines got an IP.
That's easy enough to do based on MAC address. With some DHCP servers you can create a list of MACs to allow or deny.
but you don't need to ask the dhcp to give an address :-)
only a firewall or proxy can filter out IP's (I think)
You can also configure a DHCP server to assign a specific IP to a MAC. If only allowing specific MAC addresses an IP address, you have a fairly effective filter. Also, managed switches can be configured to allow only specific MACs to connect or even limit the number of MACs connected through a port. There are many ways to set up security. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-24 12:54, James Knott wrote:
On 06/24/2018 06:51 AM, Carlos E. R. wrote:
On that place, only authorized machines got an IP.
That's easy enough to do based on MAC address. With some DHCP servers you can create a list of MACs to allow or deny.
I know, but it was way more complex than that. As I said, the machines had to be configured in Bios to boot only from network, never from disk. They loaded some code, and this did the auth and allowed Windows to boot properly. I know because there was some problem, IT was very slow coming, so we attempted recovery, and set computer to boot stand alone. It booted to windows, no network, and no domain. The IT chap finally came and changed the bios to boot from network and booted. He told me the name of the protocol but that was years ago and I have forgotten. At a military place. If it were MAC based, the machine would have gotten an address. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
On 2018-06-24 12:54, James Knott wrote:
On 06/24/2018 06:51 AM, Carlos E. R. wrote:
On that place, only authorized machines got an IP.
That's easy enough to do based on MAC address. With some DHCP servers you can create a list of MACs to allow or deny.
I know, but it was way more complex than that.
As I said, the machines had to be configured in Bios to boot only from network, never from disk. They loaded some code, and this did the auth and allowed Windows to boot properly.
I know because there was some problem, IT was very slow coming, so we attempted recovery, and set computer to boot stand alone. It booted to windows, no network, and no domain. The IT chap finally came and changed the bios to boot from network and booted. He told me the name of the protocol but that was years ago and I have forgotten.
dhcp/bootp + PXE + tftp. All very ancient stuff :-) -- Per Jessen, Zürich (20.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-24 14:11, Per Jessen wrote:
Carlos E. R. wrote:
On 2018-06-24 12:54, James Knott wrote:
On 06/24/2018 06:51 AM, Carlos E. R. wrote:
On that place, only authorized machines got an IP.
That's easy enough to do based on MAC address. With some DHCP servers you can create a list of MACs to allow or deny.
I know, but it was way more complex than that.
As I said, the machines had to be configured in Bios to boot only from network, never from disk. They loaded some code, and this did the auth and allowed Windows to boot properly.
I know because there was some problem, IT was very slow coming, so we attempted recovery, and set computer to boot stand alone. It booted to windows, no network, and no domain. The IT chap finally came and changed the bios to boot from network and booted. He told me the name of the protocol but that was years ago and I have forgotten.
dhcp/bootp + PXE + tftp. All very ancient stuff :-)
Yes, I know about those, but not as a very paranoid security measure. It was a windows only thing. The code that was downloaded from network for booting verified the authenticity of the computer before allowing it to boot and connect to the network. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
On 2018-06-24 14:11, Per Jessen wrote:
Carlos E. R. wrote:
On 2018-06-24 12:54, James Knott wrote:
On 06/24/2018 06:51 AM, Carlos E. R. wrote:
On that place, only authorized machines got an IP.
That's easy enough to do based on MAC address. With some DHCP servers you can create a list of MACs to allow or deny.
I know, but it was way more complex than that.
As I said, the machines had to be configured in Bios to boot only from network, never from disk. They loaded some code, and this did the auth and allowed Windows to boot properly.
I know because there was some problem, IT was very slow coming, so we attempted recovery, and set computer to boot stand alone. It booted to windows, no network, and no domain. The IT chap finally came and changed the bios to boot from network and booted. He told me the name of the protocol but that was years ago and I have forgotten.
dhcp/bootp + PXE + tftp. All very ancient stuff :-)
Yes, I know about those, but not as a very paranoid security measure. It was a windows only thing.
The code that was downloaded from network for booting verified the authenticity of the computer before allowing it to boot and connect to the network.
Still, dhcp/bootp + PXE + tftp. Once you're executing under PXE, what you download can do whatever you want. That is the whole idea. -- Per Jessen, Zürich (19.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/24/2018 08:35 AM, Per Jessen wrote:
The code that was downloaded from network for booting verified the authenticity of the computer before allowing it to boot and connect to the network. Still, dhcp/bootp + PXE + tftp. Once you're executing under PXE, what you download can do whatever you want. That is the whole idea.
Years ago, diskless work stations, that downloaded the OS etc. from a server were common. These days, we have VoIP phones that can download the config by using TFTP on boot up. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-24 14:35, Per Jessen wrote:
Carlos E. R. wrote:
On 2018-06-24 14:11, Per Jessen wrote:
Carlos E. R. wrote:
On 2018-06-24 12:54, James Knott wrote:
On 06/24/2018 06:51 AM, Carlos E. R. wrote:
On that place, only authorized machines got an IP.
That's easy enough to do based on MAC address. With some DHCP servers you can create a list of MACs to allow or deny.
I know, but it was way more complex than that.
As I said, the machines had to be configured in Bios to boot only from network, never from disk. They loaded some code, and this did the auth and allowed Windows to boot properly.
I know because there was some problem, IT was very slow coming, so we attempted recovery, and set computer to boot stand alone. It booted to windows, no network, and no domain. The IT chap finally came and changed the bios to boot from network and booted. He told me the name of the protocol but that was years ago and I have forgotten.
dhcp/bootp + PXE + tftp. All very ancient stuff :-)
Yes, I know about those, but not as a very paranoid security measure. It was a windows only thing.
The code that was downloaded from network for booting verified the authenticity of the computer before allowing it to boot and connect to the network.
Still, dhcp/bootp + PXE + tftp. Once you're executing under PXE, what you download can do whatever you want. That is the whole idea.
I know, but it wasn't exactly that. It had an entry in the bios I had never seen. Maybe I took notes, which are lost, but no photograph, I did not have a digital camera and my phone was to simple. Some kind of custom serialization of the hardware, perhaps. Maybe this: https://militarycac.com/lps.htm -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/24/2018 08:29 AM, Carlos E. R. wrote:
Yes, I know about those, but not as a very paranoid security measure. It was a windows only thing.
I'd be paranoid about using Windows too! ;-)
The code that was downloaded from network for booting verified the authenticity of the computer before allowing it to boot and connect to the network.
As I mentioned earlier, there may be things the military uses you'd never see elsewhere. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-24 14:55, James Knott wrote:
On 06/24/2018 08:29 AM, Carlos E. R. wrote:
Yes, I know about those, but not as a very paranoid security measure. It was a windows only thing.
I'd be paranoid about using Windows too! ;-)
LOL
The code that was downloaded from network for booting verified the authenticity of the computer before allowing it to boot and connect to the network.
As I mentioned earlier, there may be things the military uses you'd never see elsewhere.
Indeed. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/24/2018 07:18 AM, Carlos E. R. wrote:
That's easy enough to do based on MAC address. With some DHCP servers you can create a list of MACs to allow or deny. I know, but it was way more complex than that.
As I said, the machines had to be configured in Bios to boot only from network, never from disk. They loaded some code, and this did the auth and allowed Windows to boot properly.
That's beyond basic DHCP. Booting from the network has been around at least as long as bootp. When you start downloading software on boot, then you can do all sorts of things. You may recall Novell Netware, which booted DOS first and then loaded Netware from disk. IIRC, it could also load from the network, but not sure on that.
He told me the name of the protocol but that was years ago and I have forgotten. At a military place.
I mentioned bootp and now there's PXE. Of course, the military might have something proprietary, that we'd never see in a normal network environment. https://en.wikipedia.org/wiki/Preboot_Execution_Environment. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/24/2018 08:49 AM, James Knott wrote:
Booting from the network has been around at least as long as bootp.
An example. About 40 years ago, I started maintaining Collins 8500C computers. With these computers, you could do an IPL from a disk or tape drive out on the LAN. Even a card reader could be used if needed. There was no internal drive to boot from. It also used core memory, so you could turn the computer off and restart the software after you powered up. Also, this LAN predated both IP and Ethernet. It used Time Division Multiplexing (TDM) over the network, instead of packets or frames as used with IP & Ethernet. Devices were assigned a time slot to transmit in and received on whatever time slot the data came in on. This was coordinated via an "order wire" that had it's own time slot and was received by all devices. The order wire was sort of the broadcast or multicast of the day. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On 2018-06-23 20:58, Per Jessen wrote:
James Knott wrote:
On 06/23/2018 03:16 AM, Carlos E. R. wrote:
It might try on wake up DHCP on a new network that requires a different type of DHCP with password
Since when does DHCP require a password?
I was wondering about that one too, I don't know of any dhcp implementation that requires a password.
I wonder if Carlos meant one of those setups where at first you only get access to a login webpage. After authentication, you then have full access.
I have been on networks where only authorized computers get an address.
Sure, I expect we all have, it's a very common setup. Even your wifi is one of those :-)
However, if you google "dhcp password" there are many hits, several to say no, but some say yes:
Neither is necessarily proof of anything. :-) A config example would be a good start. The typical setup for a private network that accepts authenticated guests is something like this: As a guest, you get a DHCP address from a dedicated "sandboxed" range, where everything is fed through the same router - all that is accepted is port 80, which diverts to a single webpage. Here you present your credentials (e.g. a password) and your machine can now be given an address in the open range. Quite similar to open Wifi networks that still require known users. It doesn't have to be a separate router, it can be done with icmp redirects too, but afaik, Windows had a problem with those at some point. Causes too much hassle for the helpdesk :-( -- Per Jessen, Zürich (19.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 23/06/18 20:58, Per Jessen wrote:
I wonder if Carlos meant one of those setups where at first you only get access to a login webpage. After authentication, you then have full access.
They are called "captive portals". https://en.wikipedia.org/wiki/Captive_portal -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-23 07:31, David C. Rankin wrote:
On 06/22/2018 04:44 AM, Carlos E. R. wrote:
I'm going to suggest that was intentional. People hibernate (and/or suspend)machines mostly to travel, home to work, on the road, etc. Expecting the same connection to be available, and preferred upon resume seems a corner case rather than the normal case. The IP set (manually or via DHCP) should never be trusted upon a resume. You may have moved from one network to another. That is debatable. Many people use a laptop at home instead of a desktop machine, and the laptop is sitting permanently on a table in the sitting room, occasionally going somewhere. And it is normal to hibernate machines when not in use, some do so automatically after a period of not being used.
It is perfectly valid to verify if the conditions before are still valid after, and if they are, restore the connections, and if not, find new ones.
I tend to agree with Carlos here. If I put my laptop to sleep at home, I expect that it will come back up with the same connection it went to sleep with. I have multiple adapters configured as well. You don't see windows going to sleep connected to Wi-fi and then awaking connected to a non-plugged in wired connection...
I suddenly remembered. It is possible to find out if the computer is in the same cable network by interrogating the network device at the other end for its MAC. As they are (in theory) world unique, if it is the same MAC as it was, the laptop has not moved. I believe it is possible to do this before activating tcpip. As for WiFI, if it is the same SSID available, use if. If in doubt, check its MAC... -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/23/2018 12:24 PM, Carlos E. R. wrote:
I suddenly remembered. It is possible to find out if the computer is in the same cable network by interrogating the network device at the other end for its MAC. As they are (in theory) world unique, if it is the same MAC as it was, the laptop has not moved. I believe it is possible to do this before activating tcpip.
You can't count on MAC addresses being unique any more, with MAC spoofing and cheap manufacturers that reuse MAC addresses. However, a MAC address does not have to be globally unique with IP. It only has to be unique on the local link. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-23 20:36, James Knott wrote:
On 06/23/2018 12:24 PM, Carlos E. R. wrote:
I suddenly remembered. It is possible to find out if the computer is in the same cable network by interrogating the network device at the other end for its MAC. As they are (in theory) world unique, if it is the same MAC as it was, the laptop has not moved. I believe it is possible to do this before activating tcpip.
You can't count on MAC addresses being unique any more, with MAC spoofing and cheap manufacturers that reuse MAC addresses.
Shame on them :-P
However, a MAC address does not have to be globally unique with IP. It only has to be unique on the local link.
I know. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Le 24/06/2018 à 12:20, Carlos E. R. a écrit :
On 2018-06-23 20:36, James Knott wrote:
You can't count on MAC addresses being unique any more, with MAC spoofing and cheap manufacturers that reuse MAC addresses.
Shame on them :-P
why anymore? I had more than ten years ago a bunch of eth cards with all Mac zero (easy to change but identical), soi the problem is not new :-( jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-24 12:28, jdd@dodin.org wrote:
Le 24/06/2018 à 12:20, Carlos E. R. a écrit :
On 2018-06-23 20:36, James Knott wrote:
You can't count on MAC addresses being unique any more, with MAC spoofing and cheap manufacturers that reuse MAC addresses.
Shame on them :-P
why anymore? I had more than ten years ago a bunch of eth cards with all Mac zero (easy to change but identical), soi the problem is not new :-(
I know :-( -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/21/2018 04:44 PM, John Andersen wrote:
I'm going to suggest that was intentional. People hibernate (and/or suspend)machines mostly to travel, home to work, on the road, etc. Expecting the same connection to be available, and preferred upon resume seems a corner case rather than the normal case. The IP set (manually or via DHCP) should never be trusted upon a resume. You may have moved from one network to another.
If the computer has only been hibernating and the Ethernet cable has not been disconnected, why would it assume it's elsewhere and needing a different connection? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 23 Jun 2018 14:20:41 -0400
James Knott
On 06/21/2018 04:44 PM, John Andersen wrote:
I'm going to suggest that was intentional. People hibernate (and/or suspend)machines mostly to travel, home to work, on the road, etc. Expecting the same connection to be available, and preferred upon resume seems a corner case rather than the normal case. The IP set (manually or via DHCP) should never be trusted upon a resume. You may have moved from one network to another.
If the computer has only been hibernating and the Ethernet cable has not been disconnected, why would it assume it's elsewhere and needing a different connection?
Indeed, I'd expect any open TCP connections still be open afterwards, as well. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/23/2018 05:06 PM, Dave Howorth wrote:
If the computer has only been hibernating and the Ethernet cable has not been disconnected, why would it assume it's elsewhere and needing a different connection? Indeed, I'd expect any open TCP connections still be open afterwards, as well.
I suspect TCP connections will time out and fail. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-23 23:50, James Knott wrote:
On 06/23/2018 05:06 PM, Dave Howorth wrote:
If the computer has only been hibernating and the Ethernet cable has not been disconnected, why would it assume it's elsewhere and needing a different connection? Indeed, I'd expect any open TCP connections still be open afterwards, as well.
I suspect TCP connections will time out and fail.
I have been these days hibernating a desktop and two laptops with ssh sessions active, and sometimes they survive, if they wake up at nearly the same time. NFS always survives, but it is because it tries again. In fact, entries in /var/lib/nfs/etab can survive years across system upgrades. It is not funny when you hibernate with an nfs mount active, hibernate, then awake on a different place, see the mount and try to umount it. Fails. Then come back to the original place, try to mount or umount: fails. You have to reboot. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/24/2018 08:14 AM, Carlos E. R. wrote:
I suspect TCP connections will time out and fail. I have been these days hibernating a desktop and two laptops with ssh sessions active, and sometimes they survive, if they wake up at nearly the same time.
NFS always survives, but it is because it tries again.
Those are not TCP sessions, they're app sessions. TCP refers only to the part of the IP stack that reliably transfers data over IP. If one end stops, while transferring data, the other end will time out. On the other hand if the transfer has completed, there is no session to stop/fail and you could just pick up after coming out of hibernation. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On return from hibernation, Network Manager doesn't restore the same connection that was active.
I have two eth network configurations: one automatic, which is the default one, and one fixed, in which I define the address and other things. I'm using "Fixed", but if I hibernate and restore I get "wired connection 1", ie dhcp.
How does NetworkManager chose a network connection? is there a default? I.e. is the default to pick a wireless for instance? -- Per Jessen, Zürich (21.9°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-23 18:19, Per Jessen wrote:
Carlos E. R. wrote:
On return from hibernation, Network Manager doesn't restore the same connection that was active.
I have two eth network configurations: one automatic, which is the default one, and one fixed, in which I define the address and other things. I'm using "Fixed", but if I hibernate and restore I get "wired connection 1", ie dhcp.
How does NetworkManager chose a network connection? is there a default? I.e. is the default to pick a wireless for instance?
Not that I know. There is "use this connection if available", and I guess it checks them alphabetically, unless there is some numerical order inside. What happens if two connections, as is my case now, have that bit enabled? So far it is reusing the same connection because it is available. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/23/2018 12:27 PM, Carlos E. R. wrote:
I have two eth network configurations: one automatic, which is the default one, and one fixed, in which I define the address and other things. I'm using "Fixed", but if I hibernate and restore I get "wired connection 1", ie dhcp. How does NetworkManager chose a network connection? is there a default? I.e. is the default to pick a wireless for instance? Not that I know. There is "use this connection if available", and I guess it checks them alphabetically, unless there is some numerical order inside.
What happens if two connections, as is my case now, have that bit enabled? So far it is reusing the same connection because it is available.
With WiFi and Ethernet on the same network, it's the metric that causes Ethernet to be preferred, though the WiFi will still connect. It just won't be used. When you have multiple static configs, I know of know way to determine the default, other than using the automatically connect setting. Beyond that, you'd have to poll, check the arp cache etc., to see where you're connected. BTW, back in the 90s, when I worked at IBM and was running OS/2, I had a static IP for my ThinkPad (9.29.146.147, I've long forgotten my SNA address) for use in my office, but had a utility that enabled me to select other options, including DHCP, when elsewhere. That can now be done easily in the Network Manager. Incidentally, that was back in the day when DHCP was just becoming popular and people working at IBM were assigned static addresses. I had 5 IP & SNA, 1 each for my own use and 4 for testing in my work. Back then I had all 10 addresses memorized, as I had configured them so many times. Now I just have to memorize several IPv6 addresses. ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-23 20:47, James Knott wrote:
On 06/23/2018 12:27 PM, Carlos E. R. wrote:
I have two eth network configurations: one automatic, which is the default one, and one fixed, in which I define the address and other things. I'm using "Fixed", but if I hibernate and restore I get "wired connection 1", ie dhcp. How does NetworkManager chose a network connection? is there a default? I.e. is the default to pick a wireless for instance? Not that I know. There is "use this connection if available", and I guess it checks them alphabetically, unless there is some numerical order inside.
What happens if two connections, as is my case now, have that bit enabled? So far it is reusing the same connection because it is available.
With WiFi and Ethernet on the same network, it's the metric that causes Ethernet to be preferred, though the WiFi will still connect.
You misunderstand. Which cable configuration does network manager prefers to start, when several have the "activate this one if available"? Similarly, when NM has two or more definitions for the same SSID, which one is activated?
BTW, back in the 90s, when I worked at IBM and was running OS/2, I had a static IP for my ThinkPad (9.29.146.147, I've long forgotten my SNA address) for use in my office, but had a utility that enabled me to select other options, including DHCP, when elsewhere. That can now be done easily in the Network Manager. Incidentally, that was back in the day when DHCP was just becoming popular and people working at IBM were assigned static addresses. I had 5 IP & SNA, 1 each for my own use and 4 for testing in my work. Back then I had all 10 addresses memorized, as I had configured them so many times. Now I just have to memorize several IPv6 addresses. ;-)
:-) -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/23/2018 12:19 PM, Per Jessen wrote:
I have two eth network configurations: one automatic, which is the default one, and one fixed, in which I define the address and other things. I'm using "Fixed", but if I hibernate and restore I get "wired connection 1", ie dhcp. How does NetworkManager chose a network connection? is there a default? I.e. is the default to pick a wireless for instance?
With WiFi and Ethernet connections, there is a "cost" metric, where WiFi is considered more expensive than Ethernet, so WiFi would not be used if both connect to the same network. However, this is different from multiple Ethernet connections. There should be only one default, normally DHCP. On my computer, DHCP is the default and I have to manually select any static config I wish to use. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 06/23/2018 12:19 PM, Per Jessen wrote:
I have two eth network configurations: one automatic, which is the default one, and one fixed, in which I define the address and other things. I'm using "Fixed", but if I hibernate and restore I get "wired connection 1", ie dhcp. How does NetworkManager chose a network connection? is there a default? I.e. is the default to pick a wireless for instance?
With WiFi and Ethernet connections, there is a "cost" metric, where WiFi is considered more expensive than Ethernet, so WiFi would not be used if both connect to the same network.
Isn't that a routing thing, rather than something for NetworkManager? -- Per Jessen, Zürich (19.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/23/2018 02:55 PM, Per Jessen wrote:
Isn't that a routing thing
What do you think Linux can do? Here's what "ip route show" displays on my ThinkPad: ip route show default via 172.16.0.1 dev eth0 proto dhcp metric 100 default via 172.16.0.1 dev wlan0 proto dhcp metric 600 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.42 metric 100 172.16.0.0/24 dev wlan0 proto kernel scope link src 172.16.0.40 metric 600 So, Linux is routing over the preferred interface, based on the metric. This results in a nice feature for Linux that doesn't work in Windows. When connected to both WiFi and Ethernet, you need different addresses for each interface. With Linux, with both connected, or WiFi alone, I can use only the WiFi address, when accessing my notebook computer. I don't even have to think of the Ethernet host name or IP address. The traffic to the notebook will travel over the WiFi connection, but the return traffic is via Ethernet. Linux sorts it out. With Windows, if connected via Ethernet and WiFi, I must use the address for the Ethernet connection, as using the WiFi address will fail. I can only use the WiFi address if Ethernet is not connected. This means I have to use 2 different host names or IP addresses, depending on whether the Ethernet cable is connected. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 06/23/2018 02:55 PM, Per Jessen wrote:
Isn't that a routing thing
What do you think Linux can do?
Here's what "ip route show" displays on my ThinkPad:
ip route show default via 172.16.0.1 dev eth0 proto dhcp metric 100 default via 172.16.0.1 dev wlan0 proto dhcp metric 600 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.42 metric 100 172.16.0.0/24 dev wlan0 proto kernel scope link src 172.16.0.40 metric 600
So, Linux is routing over the preferred interface, based on the metric.
That's what I meant. It doesn't solve the OPs issue though. -- Per Jessen, Zürich (17.7°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/23/2018 03:26 PM, Per Jessen wrote:
So, Linux is routing over the preferred interface, based on the metric. That's what I meant. It doesn't solve the OPs issue though.
The only thing that will fix his problem is having only one config auto connect. Otherwise, there is no way for it to know what the default is. However, I would expect the selected config to remain after hibernation, assuming the Ethernet connection hasn't been disconnected. A computer in hibernation is simply in a power saving mode and shouldn't change. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 06/23/2018 03:26 PM, Per Jessen wrote:
So, Linux is routing over the preferred interface, based on the metric. That's what I meant. It doesn't solve the OPs issue though.
The only thing that will fix his problem is having only one config auto connect. Otherwise, there is no way for it to know what the default is.
Right.
However, I would expect the selected config to remain after hibernation, assuming the Ethernet connection hasn't been disconnected. A computer in hibernation is simply in a power saving mode and shouldn't change.
Yeah, I would tend to agree with that. OTOH I can't easily dismiss John Andersen's argument from yesterday. -- Per Jessen, Zürich (15.9°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/24/2018 03:31 AM, Per Jessen wrote: ...
However, I would expect the selected config to remain after hibernation, assuming the Ethernet connection hasn't been disconnected. A computer in hibernation is simply in a power saving mode and shouldn't change. Yeah, I would tend to agree with that. OTOH I can't easily dismiss John Andersen's argument from yesterday.
I often put my laptop into hibernation and never for that reason lose my routing configuration. (Rebooting a different case though.) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
ken wrote:
On 06/24/2018 03:31 AM, Per Jessen wrote: ...
However, I would expect the selected config to remain after hibernation, assuming the Ethernet connection hasn't been disconnected. A computer in hibernation is simply in a power saving mode and shouldn't change. Yeah, I would tend to agree with that. OTOH I can't easily dismiss John Andersen's argument from yesterday.
I often put my laptop into hibernation and never for that reason lose my routing configuration. (Rebooting a different case though.)
Oh sure, me too. A few times a day - but I only use one network interface, ever. -- Per Jessen, Zürich (16.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/25/2018 01:16 AM, Per Jessen wrote:
ken wrote:
On 06/24/2018 03:31 AM, Per Jessen wrote: ...
However, I would expect the selected config to remain after hibernation, assuming the Ethernet connection hasn't been disconnected. A computer in hibernation is simply in a power saving mode and shouldn't change. Yeah, I would tend to agree with that. OTOH I can't easily dismiss John Andersen's argument from yesterday.
I often put my laptop into hibernation and never for that reason lose my routing configuration. (Rebooting a different case though.)
Oh sure, me too. A few times a day - but I only use one network interface, ever.
I tested with leap 42.3 last night. I closed my ssh connections and Tbird,
but left FF, konsole, konqueror and kate running (only local files open in
kate, none via the sftp_kioslave) and then put the laptop to sleep. Both wlan0
and eth0 are configured. The box woke up just fine and back to wlan0 without
issue (eth0 was not connected).
E.g.,
$ ip addr
1: lo:
On 06/25/2018 01:46 PM, David C. Rankin wrote:
and then put the laptop to sleep.
Sleep, or Hibernate? Sleep: Suspend to ram. Wakes up instantly upon resume. Hibernate: Suspend to disk, takes almost as long as a reboot when resuming. Carlos was saying hibernate, but I didn't get an answer when I asked if that is what he really meant. When your battery runs down to nothing, you will lose your session if sleeping. It will take days. With Hibernate you can shut it off for years. There are subtle differences in some machines. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-25 22:46, David C. Rankin wrote:
This is what I recall from the last time it slept. So if 15 is behaving differently, then something has changed (I have wicked and no NM running)
You have not tested my exact question. Define in NM two wired connections. One with dhcp and set to "always use this connection if available", and a second one with a fixed IP that does not have that setting ticked. Then connect using the second one. Then hibernate (to disk) and restore. It goes to the first connection, dhcp, not to the one that was in use. And it has to be NM, not wicked. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" (Minas Tirith))
On 2018-06-23 22:31, James Knott wrote:
On 06/23/2018 03:26 PM, Per Jessen wrote:
So, Linux is routing over the preferred interface, based on the metric. That's what I meant. It doesn't solve the OPs issue though.
The only thing that will fix his problem is having only one config auto connect.
I have two.
Otherwise, there is no way for it to know what the default is. However, I would expect the selected config to remain after hibernation, assuming the Ethernet connection hasn't been disconnected. A computer in hibernation is simply in a power saving mode and shouldn't change.
Well, for reuse the same connection after hibernation, I had to define but configurations as default. If only dhcp is default, it wins over the fixed one that was active before hibernating. Having two as default works. That is fixing the problem for now. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
21.06.2018 11:42, Carlos E. R. пишет:
Hi,
On return from hibernation, Network Manager doesn't restore the same connection that was active.
I have two eth network configurations: one automatic, which is the default one, and one fixed, in which I define the address and other things. I'm using "Fixed", but if I hibernate and restore I get "wired connection 1", ie dhcp.
I'm going to the undefine "wired connection 1" the setting "connect to this network when available", but then maybe it will not connect to anyone. [...] Confirmed, then I get "no connection". I may try to set both as default, see which one gets it... [...] Well, it was the "Fixed" one.
It is rather hard to answer question with zero information (distribution, version, configuration ...), but ... "Wired connection 1" is created by NetworkManager automatically for physical interface if no other applicable connections exist. It is in-memory only and is not saved on disk unless you explicitly modify it in connection editor. NM keeps timestamps for each connection and normally attempts to connect to the one which was used most recently. In my testing with two identical (up to the name of course) wired connections NM always selects the one that was used last. This also includes resume from hibernate (unfortunately interface never gets IP in QEMU with user network but connection that is attempted to be activated is the last one). So if after resume you get "Wired connection 1" again most straightforward answer is that your other connection simply is not (yet) known to NetworkManager, i.e. it is most likely user, not system, connection. P.S. and it is NetworkManager, not "network manager". "Network manager" may refer to any arbitrary program you use to manage your network.
On 2018-06-23 19:23, Andrei Borzenkov wrote:
21.06.2018 11:42, Carlos E. R. пишет:
Hi,
On return from hibernation, Network Manager doesn't restore the same connection that was active.
I have two eth network configurations: one automatic, which is the default one, and one fixed, in which I define the address and other things. I'm using "Fixed", but if I hibernate and restore I get "wired connection 1", ie dhcp.
I'm going to the undefine "wired connection 1" the setting "connect to this network when available", but then maybe it will not connect to anyone. [...] Confirmed, then I get "no connection". I may try to set both as default, see which one gets it... [...] Well, it was the "Fixed" one.
It is rather hard to answer question with zero information (distribution, version, configuration ...), but ...
That machine has 15.0 and XFCE desktop. If you need something else, ask, I didn't think it was relevant, sorry.
"Wired connection 1" is created by NetworkManager automatically for physical interface if no other applicable connections exist. It is in-memory only and is not saved on disk unless you explicitly modify it in connection editor.
NM keeps timestamps for each connection and normally attempts to connect to the one which was used most recently.
Well, it did not. The previous one was named "fixed", and it restored to "Wired connection 1" several times.
In my testing with two identical (up to the name of course) wired connections NM always selects the one that was used last. This also includes resume from hibernate (unfortunately interface never gets IP in QEMU with user network but connection that is attempted to be activated is the last one).
So if after resume you get "Wired connection 1" again most straightforward answer is that your other connection simply is not (yet) known to NetworkManager, i.e. it is most likely user, not system, connection.
Both are filed by now. I renamed "Wired connection 1" to "automatic". I solved the issue by marking both "automatically connect to this network when it is available".
P.S. and it is NetworkManager, not "network manager". "Network manager" may refer to any arbitrary program you use to manage your network.
I was writing on another computer that doesn't have it. Plus, the NM configuration editor doesn't say the name of the program. Several of its windows don't say the name of the thing, so I had to guess. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/21/2018 04:42 AM, Carlos E. R. wrote:
Hi,
On return from hibernation, Network Manager doesn't restore the same connection that was active.
I have two eth network configurations: one automatic, which is the default one, and one fixed, in which I define the address and other things. I'm using "Fixed", but if I hibernate and restore I get "wired connection 1", ie dhcp.
I'm going to the undefine "wired connection 1" the setting "connect to this network when available", but then maybe it will not connect to anyone. [...] Confirmed, then I get "no connection". I may try to set both as default, see which one gets it... [...] Well, it was the "Fixed" one.
I also have multiple configurations available, but only have DHCP and WiFi configured to automatically connect. The only time I use the manual configurations is when I have a specific need for it. If you have multiple automatic connect configurations, how is the desired one supposed to be selected? On my computer, if I need something beyond DHCP, I manually select it. BTW, on my home network, I use DHCP for most devices, but have the DHCP server configured to map a specific IP address to a MAC address. Only my main desktop system and firewall/router have static addresses. Of course, I also run IPv6 at home, so IPv4 addresses are generally irrelevant. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-23 20:19, James Knott wrote:
On 06/21/2018 04:42 AM, Carlos E. R. wrote:
Hi,
On return from hibernation, Network Manager doesn't restore the same connection that was active.
I have two eth network configurations: one automatic, which is the default one, and one fixed, in which I define the address and other things. I'm using "Fixed", but if I hibernate and restore I get "wired connection 1", ie dhcp.
I'm going to the undefine "wired connection 1" the setting "connect to this network when available", but then maybe it will not connect to anyone. [...] Confirmed, then I get "no connection". I may try to set both as default, see which one gets it... [...] Well, it was the "Fixed" one.
I also have multiple configurations available, but only have DHCP and WiFi configured to automatically connect. The only time I use the manual configurations is when I have a specific need for it. If you have multiple automatic connect configurations, how is the desired one supposed to be selected?
By asking. :-) If one was active before hibernation, afterwards try the same one. Why change, if it was manually selected by me, the master of the universe?
On my computer, if I need something beyond DHCP, I manually select it. BTW, on my home network, I use DHCP for most devices, but have the DHCP server configured to map a specific IP address to a MAC address. Only my main desktop system and firewall/router have static addresses.
Of course, I also run IPv6 at home, so IPv4 addresses are generally irrelevant.
-- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
participants (10)
-
Andrei Borzenkov -
Carlos E. R. -
Dave Howorth -
David C. Rankin -
James Knott -
jdd＠dodin.org -
John Andersen -
ken -
Liam Proven -
Per Jessen