Re: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works
- From: Vincent Lefevre <vincent vinc17 net>
- To: Beniamino Galvani <bgalvani redhat com>
- Cc: Michael Biebl <biebl debian org>, networkmanager-list <networkmanager-list gnome org>, 933930 <933930 bugs debian org>
- Subject: Re: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works
- Date: Mon, 12 Aug 2019 10:59:32 +0200
On 2019-08-12 09:40:43 +0200, Beniamino Galvani wrote:
On Fri, Aug 09, 2019 at 05:03:34PM +0200, Vincent Lefevre wrote:
On 2019-08-09 16:05:11 +0200, Beniamino Galvani wrote:
in the traces I see that there are 3 servers and one of them
advertises a subnet different from other two. This setup makes the
behavior non-deterministic because clients can get an address either
in the 10.0.1.0/24 or in the 140.77.12.0/23 network. Do you know if
the network configured in this way on purpose?
I think so, as there are 2 kinds of machines: those that are supposed
to have a fixed IP address on the main network, and the other machines,
which will be on a secondary network. My machine is in the former
class. I don't know how such machines are supposed to be identified
(probably with a weak identification), but I can see my machine
name in the DHCP Discover and DHCP Request packets.
Ok, then this mechanism is not working since your machine is receiving
offers for both networks and randomly takes one. I don't know how
common this setup is, but the RFC seems to warn against it:
Once the network address and lease have been determined, the server
constructs a DHCPOFFER message with the offered configuration
parameters. It is important for all DHCP servers to return the same
parameters (with the possible exception of a newly allocated network
address) to ensure predictable client behavior regardless of which
server the client selects.
For machines with a static IP address that could be proposed to the
DHCP servers, this should not be an issue. This seems possible to do
with dhclient, but I suspect that users never do that in practice,
even we know our static address (it is given by the admin). So,
indeed, I suspect that there could be an issue with this configuration
in practice.
I'll ask the admins whether this configuration is expected (I can
see an advantage that this allows machines of the former class to
switch to the alternate network when there is an issue with the
main network, but I don't think that this is a good idea anyway,
because this can make machines indefinitely unreachable after a
temporary failure with the main DHCP servers).
BTW, I can see in the logs, that I never got a DHCPNAK before July 22.
So, it seems that something has changed. But I think that no-one
except me noticed, because I'm probably the first one to have upgraded
to the new NetworkManager versions.
It seems that RFC 2131 has some contradictions in case of several
DHCP servers on several networks. IMHO, the client should be
tolerant and ignore DHCPNAK if the server-id is different.
I checked again and the internal client doesn't do any filtering based
on the server-id. In the dhclient log at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933930#42
[...]
the transaction succeeds because the ACK comes before any NAK, which
is the same thing it happens when the transaction succeeds with the
internal client. Perhaps could you capture other logs with dhclient
too see how it handles multiple NAK?
Please look at the capture I had sent at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933930#74
i.e.
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=933930;filename=dhcp-dhclient.pcap;msg=74
The NAK comes first.
--
Vincent Lefèvre <vincent vinc17 net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]