[opensuse] Ethernet and onboot/oncable
The configuring Ethernet ports in openSUSE, it is possible to say when the port should be configured. This is the STARTMODE= value in the port configuration file. Has there been a deliberate change in the 'onboot' mode? In previous openSUSE releases, this would cause the port to be configured when the system is booted, independent of whether there is a cable attached. If one want to require that there be a cable, STARTMODE can bet set to 'oncable'. In Leap 42,3, it seems that when one selects On Boot in YAST, STARTMODE is set to 'auto'. If there is no cable attached, the port does not get an address. It acts like 'on cable connect'. I am not running Network Manager. The ports are managed in the traditional way (or whatever fills that role these days). The network and related services are all running before anyone logs in. This is a problem in systems that boot along with other hardware. If, say, the Leap machine starts it's network before some other system, the port on Leap will not get an address. This is bad. While plugging in cable (or the remote system turning on) will cause the port to get an address, services that use that port are not restarted. For example, dhcpd will ignore ports without an address - and it will never try again until you actively restart it. Is there any way to get the previous on boot functionality so that ports with fixed address are assigned them on boot, no matter what may or may not be connected to them? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
The configuring Ethernet ports in openSUSE, it is possible to say when the port should be configured. This is the STARTMODE= value in the port configuration file.
Has there been a deliberate change in the 'onboot' mode? In previous openSUSE releases, this would cause the port to be configured when the system is booted, independent of whether there is a cable attached. If one want to require that there be a cable, STARTMODE can bet set to 'oncable'.
I don't know if/when this was changed, but 'onboot' and 'oncable' were deprecated in favour of "auto" and "hotplug". See e.g. /etc/sysconfig/network/ifcfg.template They should presumably still work, of course.
In Leap 42,3, it seems that when one selects On Boot in YAST, STARTMODE is set to 'auto'. If there is no cable attached, the port does not get an address. It acts like 'on cable connect'.
With a static address assignment? I don't think I've tried that.
I am not running Network Manager. The ports are managed in the traditional way (or whatever fills that role these days).
It's wicked. (noun, not adjective).
This is a problem in systems that boot along with other hardware. If, say, the Leap machine starts it's network before some other system, the port on Leap will not get an address. This is bad.
Before dhcpd is up you mean? ISTR something like that - in earlier days, probably pre-wicked, we could keep broadcasting for an address, so when dhcpd finally woke up, it would still work (for a client). Wicked doesn't do that. I think I may even have opened a bugreport on that change of behaviour.
While plugging in cable (or the remote system turning on) will cause the port to get an address, services that use that port are not restarted. For example, dhcpd will ignore ports without an address - and it will never try again until you actively restart it.
Interesting situation. I think dhcpcd will only listen on 0.0.0.0, on all or specified interfaces. I would have thought it would pick up newly active ports too - I mean, a switch might have a problem etc. -- Per Jessen, Zürich (12.8°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 03/14/2018 11:35 AM, Per Jessen wrote:
I think dhcpcd will only listen on 0.0.0.0, on all or specified interfaces. I would have thought it would pick up newly active ports too - I mean, a switch might have a problem etc.
The address 0.0.0.0 is only used as a source address, never destination. The DHCP client will use it, until it learns it's address from the DHCP server.
Before dhcpd is up you mean? ISTR something like that - in earlier days, probably pre-wicked, we could keep broadcasting for an address, so when dhcpd finally woke up, it would still work (for a client). Wicked doesn't do that.
When dhcpcd woke up??? Also, does a DHCP client keep trying if there's no offer? I couldn't find info on that. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 03/14/2018 11:35 AM, Per Jessen wrote:
I think dhcpcd will only listen on 0.0.0.0, on all or specified interfaces. I would have thought it would pick up newly active ports too - I mean, a switch might have a problem etc.
The address 0.0.0.0 is only used as a source address, never destination. The DHCP client will use it, until it learns it's address from the DHCP server.
I was talking about the dhcp server.
Before dhcpd is up you mean? ISTR something like that - in earlier days, probably pre-wicked, we could keep broadcasting for an address, so when dhcpd finally woke up, it would still work (for a client). Wicked doesn't do that.
When dhcpcd woke up??? Also, does a DHCP client keep trying if there's no offer? I couldn't find info on that.
I believe e.g. dhcpcd does, yes. -- Per Jessen, Zürich (12.7°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 03/14/2018 12:02 PM, Per Jessen wrote:
James Knott wrote:
On 03/14/2018 11:35 AM, Per Jessen wrote:
I think dhcpcd will only listen on 0.0.0.0, on all or specified interfaces. I would have thought it would pick up newly active ports too - I mean, a switch might have a problem etc. The address 0.0.0.0 is only used as a source address, never destination. The DHCP client will use it, until it learns it's address from the DHCP server. I was talking about the dhcp server.
Dhcpcd is the client. The server id dhcpd. Regardless, no server listens on 0.0.0.0, as it's never used as a destination. A server will listen for dhcp discovery on the broadcast address and further transactions on it's own address.
Before dhcpd is up you mean? ISTR something like that - in earlier days, probably pre-wicked, we could keep broadcasting for an address, so when dhcpd finally woke up, it would still work (for a client). Wicked doesn't do that. When dhcpcd woke up??? Also, does a DHCP client keep trying if there's no offer? I couldn't find info on that. I believe e.g. dhcpcd does, yes.
When I get a minute or 2, I'll have to try an experiment to see if it does. The docs seem vague on that point. However, at some point, dhcp, at least on Windows, will fail to a 169.254.0.0 /16 link local address. Network Manager doesn't. I haven't tried with just dhcp and no Network Manager. Network Manager requires a separate configuration for link local. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 03/14/2018 12:02 PM, Per Jessen wrote:
James Knott wrote:
On 03/14/2018 11:35 AM, Per Jessen wrote:
I think dhcpcd will only listen on 0.0.0.0, on all or specified interfaces. I would have thought it would pick up newly active ports too - I mean, a switch might have a problem etc. The address 0.0.0.0 is only used as a source address, never destination. The DHCP client will use it, until it learns it's address from the DHCP server. I was talking about the dhcp server.
Dhcpcd is the client.
Sorry, that 'c' was a typo. Maybe muscle memory.
The server id dhcpd. Regardless, no server listens on 0.0.0.0,
That is nonetheless how you code it to listen on _any_ address (INADDR_ANY). That is also how it is displayed when you look at open sockets with 'netstat' or 'ss'. When I write '0.0.0.0', I usually also imply '::', although that isn't quite correct. Quite remarkably, there is a wikipedia article: https://en.wikipedia.org/wiki/0.0.0.0
Before dhcpd is up you mean? ISTR something like that - in earlier days, probably pre-wicked, we could keep broadcasting for an address, so when dhcpd finally woke up, it would still work (for a client). Wicked doesn't do that. When dhcpcd woke up??? Also, does a DHCP client keep trying if there's no offer? I couldn't find info on that.
I believe e.g. dhcpcd does, yes.
When I get a minute or 2, I'll have to try an experiment to see if it does.
I feel certain I had an issue with that when we switched to wicked. Yep, here it is: https://bugzilla.opensuse.org/show_bug.cgi?id=915025 -- Per Jessen, Zürich (12.5°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 03/14/2018 12:27 PM, Per Jessen wrote:
That is nonetheless how you code it to listen on _any_ address (INADDR_ANY). That is also how it is displayed when you look at open sockets with 'netstat' or 'ss'. When I write '0.0.0.0', I usually also imply '::', although that isn't quite correct.
Does the DHCP server actually listen on any address? Or only it's own and broadcast addresses? The 0.0.0.0 or :: in IPv6 means unknown, while waiting for an address to be assigned. A DHCP client will do the discovery and initial request to the broadcast address and then to the server's address. At what point does it ever use any other? Why would the server listen on any other? 0.0.0.0 is used as the default route within an OS, but then the packet get sent to the appropriate route. But that 0.0.0.0 will never be seen on the wire. On the other hand, a DHCP discovery packet, will show 0.0.0.0 as source and 255.255.255.255 as destination, on the wire. BTW, I tried that experiment. I turned off my DHCP server and plugged in my notebook computer. It sent DHCP discover packets several times over about 3 minutes, but then stopped and sent another 5 minutes later. As I had turned my DHCP server on again, I don't know what would have happened after that. This was with 42.3 & Network Manager. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 03/14/2018 12:27 PM, Per Jessen wrote:
That is nonetheless how you code it to listen on _any_ address (INADDR_ANY). That is also how it is displayed when you look at open sockets with 'netstat' or 'ss'. When I write '0.0.0.0', I usually also imply '::', although that isn't quite correct.
Does the DHCP server actually listen on any address?
According to netstat, it listens on 0.0.0.0: # netstat -lun Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State [snip irrelevant bits] udp 0 0 0.0.0.0:67 0.0.0.0:* udp 0 0 0.0.0.0:69 0.0.0.0:* udp 0 0 :::69 :::*
Or only it's own and broadcast addresses? The 0.0.0.0 or :: in IPv6 means unknown, while waiting for an address to be assigned.
I would have to check/google it, but I have always taken '::' to mean "any ipv6 address".
A DHCP client will do the discovery and initial request to the broadcast address and then to the server's address. At what point does it ever use any other? Why would the server listen on any other?
Maybe there is other ancient stuff "out there" that it supports? -- Per Jessen, Zürich (9.8°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 03/14/2018 01:45 PM, Per Jessen wrote:
Or only it's own and broadcast addresses? The 0.0.0.0 or :: in IPv6
means unknown, while waiting for an address to be assigned. I would have to check/google it, but I have always taken '::' to mean "any ipv6 address".
https://en.wikipedia.org/wiki/IPv6_address#Unspecified_address
A DHCP client will do the discovery and initial request to the broadcast address and then to the server's address. At what point does it ever use any other? Why would the server listen on any other? Maybe there is other ancient stuff "out there" that it supports?
At one time, 0.0.0.0 was a broadcast address. https://supportforums.cisco.com/t5/other-network-infrastructure/ip-broadcast... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Mar 14, 2018 at 5:27 PM, Per Jessen <per@computer.org> wrote:
Quite remarkably, there is a wikipedia article: https://en.wikipedia.org/wiki/0.0.0.0
We don't tell dhcpd to listen on any port. This is because sometimes people connect these systems to their own networks (when home for service or such activity). We don't want to get involved in any dhcp activity on that port (which we don't manage - it is free for their use). To try to be less likely to mess things up when they connect like this, we use the "ignore unknown-clients" directive. But still, we specify the ports on which we expect to be providing addresses.
Before dhcpd is up you mean? ISTR something like that - in earlier days, probably pre-wicked, we could keep broadcasting for an address, so when dhcpd finally woke up, it would still work (for a client). Wicked doesn't do that. When dhcpcd woke up??? Also, does a DHCP client keep trying if there's no offer? I couldn't find info on that.
I believe e.g. dhcpcd does, yes.
If the dhcp server complains as I described, it simply does not listen on that port. There is no 'wake up'. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Mar 14, 2018 at 5:11 PM, James Knott <james.knott@rogers.com> wrote:
On 03/14/2018 12:02 PM, Per Jessen wrote:
James Knott wrote:
On 03/14/2018 11:35 AM, Per Jessen wrote:
I think dhcpcd will only listen on 0.0.0.0, on all or specified interfaces. I would have thought it would pick up newly active ports too - I mean, a switch might have a problem etc. The address 0.0.0.0 is only used as a source address, never destination. The DHCP client will use it, until it learns it's address from the DHCP server. I was talking about the dhcp server.
Dhcpcd is the client. The server id dhcpd. Regardless, no server listens on 0.0.0.0, as it's never used as a destination. A server will listen for dhcp discovery on the broadcast address and further transactions on it's own address.
Before dhcpd is up you mean? ISTR something like that - in earlier days, probably pre-wicked, we could keep broadcasting for an address, so when dhcpd finally woke up, it would still work (for a client). Wicked doesn't do that. When dhcpcd woke up??? Also, does a DHCP client keep trying if there's no offer? I couldn't find info on that. I believe e.g. dhcpcd does, yes.
When I get a minute or 2, I'll have to try an experiment to see if it does. The docs seem vague on that point. However, at some point, dhcp, at least on Windows, will fail to a 169.254.0.0 /16 link local address. Network Manager doesn't. I haven't tried with just dhcp and no Network Manager. Network Manager requires a separate configuration for link local.
When dhcpd (server) starts and a port on which it should listen has not been assigned an IP address, the server complains that there is no subnet available (the same messages as when there is no subnet clause in the configuration). It says it will thus not listen on this port. It will never try again. You must restart it when the port gets an address. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Roger Oberholtzer wrote:
The configuring Ethernet ports in openSUSE, it is possible to say when the port should be configured. This is the STARTMODE= value in the port configuration file.
Has there been a deliberate change in the 'onboot' mode? In previous openSUSE releases, this would cause the port to be configured when the system is booted, independent of whether there is a cable attached. If one want to require that there be a cable, STARTMODE can bet set to 'oncable'.
I don't know if/when this was changed, but 'onboot' and 'oncable' were deprecated in favour of "auto" and "hotplug". See e.g. /etc/sysconfig/network/ifcfg.template
Hmm, 'oncable' seems to be called 'ifplugd', but I am not familiar with that.
In Leap 42,3, it seems that when one selects On Boot in YAST, STARTMODE is set to 'auto'. If there is no cable attached, the port does not get an address. It acts like 'on cable connect'.
With a static address assignment? I don't think I've tried that.
Have just tried it now - I see what you mean. You would like the interface to be assigned the static address, no matter what state the interface is in? -- Per Jessen, Zürich (12.6°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 Wed, Mar 14, 2018 at 5:08 PM, Per Jessen <per@computer.org> wrote:
Per Jessen wrote:
Have just tried it now - I see what you mean. You would like the interface to be assigned the static address, no matter what state the interface is in?
Yes. As in: it is a static address. It ALWAYS has it. I choose the dhcpd server as an example. But it applies to all services. We also use vblade to serve AoE images to diskless systems. It gets confused when this happens. It has also changed our ability to verify that we have configured networks correctly. We now need to connect a switch to each port just to be sure it will get an address and that the various services then start as expected. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Wed, Mar 14, 2018 at 5:08 PM, Per Jessen <per@computer.org> wrote:
Per Jessen wrote:
Have just tried it now - I see what you mean. You would like the interface to be assigned the static address, no matter what state the interface is in?
Yes. As in: it is a static address. It ALWAYS has it.
I choose the dhcpd server as an example. But it applies to all services. We also use vblade to serve AoE images to diskless systems. It gets confused when this happens.
I'm curious - how does it happen? When I tried it yesterday, I physically removed the cable, but I guess the same happens if a switch is down when a machine is booting up?
It has also changed our ability to verify that we have configured networks correctly. We now need to connect a switch to each port just to be sure it will get an address and that the various services then start as expected.
I think this behaviour (and the LINK_REQUIRED option) was introduced with wicked in 13.2. -- Per Jessen, Zürich (4.1°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
14.03.2018 14:03, Roger Oberholtzer пишет:
The configuring Ethernet ports in openSUSE, it is possible to say when the port should be configured. This is the STARTMODE= value in the port configuration file.
Has there been a deliberate change in the 'onboot' mode? In previous openSUSE releases, this would cause the port to be configured when the system is booted, independent of whether there is a cable attached. If one want to require that there be a cable, STARTMODE can bet set to 'oncable'.
In Leap 42,3, it seems that when one selects On Boot in YAST, STARTMODE is set to 'auto'. If there is no cable attached, the port does not get an address. It acts like 'on cable connect'.
I am not running Network Manager. The ports are managed in the traditional way (or whatever fills that role these days). The network and related services are all running before anyone logs in.
This is a problem in systems that boot along with other hardware. If, say, the Leap machine starts it's network before some other system, the port on Leap will not get an address. This is bad. While plugging in cable (or the remote system turning on) will cause the port to get an address, services that use that port are not restarted. For example, dhcpd will ignore ports without an address - and it will never try again until you actively restart it.
Is there any way to get the previous on boot functionality so that ports with fixed address are assigned them on boot, no matter what may or may not be connected to them?
Does setting LINK_REQUIRED=no in ifcfg file help? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
LINK_REQUIRED=no
Perfect, Andrei. How do you manage to keep all those settings memorised ... -- Per Jessen, Zürich (8.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 Wed, Mar 14, 2018 at 6:12 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Does setting LINK_REQUIRED=no in ifcfg file help?
I see this related post: https://serverfault.com/questions/762732/using-link-required-parameter-with-... I have passed this suggestion on to the testers. I will report back with their finding. I have suggested to them that they set it in /etc/sysconfig/network/config as we want this for all ports. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 15, 2018 at 8:44 AM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
I have passed this suggestion on to the testers. I will report back with their finding. I have suggested to them that they set it in /etc/sysconfig/network/config as we want this for all ports.
I suspect we will have to set this in each port's config file. This is the claim for why: "LINK_REQUIRED=no is not possible as default, because it breaks requested + approved features and reverts to obsolete RFCs [that not require duplicate address detection on ipv4], which were written before many of the protocols/mechanisms existing today." -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 15, 2018 at 10:50 AM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Thu, Mar 15, 2018 at 8:44 AM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
I have passed this suggestion on to the testers. I will report back with their finding. I have suggested to them that they set it in /etc/sysconfig/network/config as we want this for all ports.
I suspect we will have to set this in each port's config file. This is the claim for why:
"LINK_REQUIRED=no is not possible as default, because it breaks requested + approved features and reverts to obsolete RFCs [that not require duplicate address detection on ipv4], which were written before many of the protocols/mechanisms existing today."
You confuse default code behavior (when no explicit parameter is set) with using parameter from multiple files. According to code wicked should use LINK_REQUIRED from .../config if it is not explicitly set in interface ifcfg. If it does not happen, it is a bug. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Mar 14, 2018 at 6:12 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
14.03.2018 14:03, Roger Oberholtzer пишет:
The configuring Ethernet ports in openSUSE, it is possible to say when the port should be configured. This is the STARTMODE= value in the port configuration file.
Has there been a deliberate change in the 'onboot' mode? In previous openSUSE releases, this would cause the port to be configured when the system is booted, independent of whether there is a cable attached. If one want to require that there be a cable, STARTMODE can bet set to 'oncable'.
In Leap 42,3, it seems that when one selects On Boot in YAST, STARTMODE is set to 'auto'. If there is no cable attached, the port does not get an address. It acts like 'on cable connect'.
I am not running Network Manager. The ports are managed in the traditional way (or whatever fills that role these days). The network and related services are all running before anyone logs in.
This is a problem in systems that boot along with other hardware. If, say, the Leap machine starts it's network before some other system, the port on Leap will not get an address. This is bad. While plugging in cable (or the remote system turning on) will cause the port to get an address, services that use that port are not restarted. For example, dhcpd will ignore ports without an address - and it will never try again until you actively restart it.
Is there any way to get the previous on boot functionality so that ports with fixed address are assigned them on boot, no matter what may or may not be connected to them?
Does setting LINK_REQUIRED=no in ifcfg file help?
As we want all Ethernet ports to be configured, setting LINK_REQUIRED="no" in /etc/sysconfig/network/config did the trick. Problem solved. Thanks! -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Andrei Borzenkov -
James Knott -
Per Jessen -
Roger Oberholtzer