Bug#933930: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works

2019-08-12 Thread Vincent Lefevre 
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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#933930: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works

2019-08-12 Thread Beniamino Galvani 
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.

> > Looking at dhcp-int-failure.pcap, there is an offer from 140.77.1.11:
> > [...]
> > to which the internal client replies with a request. Note the
> > server-id set to 140.77.1.11:
> > [...]
> > The DHCP server at 10.0.1.1 NAKs the request even if it had a
> > different server-id; I don't think this is correct:
> >
> > [...]
> 
> RFC 2131 says: "If a server receives a DHCPREQUEST message with an
> invalid 'requested IP address', the server SHOULD respond to the
> client with a DHCPNAK message and may choose to report the problem
> to the system administrator."
> 
> So this seems correct. Note that it does not say that the server must
> check the server-id, and the fact that it says "a server" instead of
> "the server" tends to make me think that this is how it works.
> 
> BTW, if the server implicitly needs to check the server-id, why
> doesn't the internal client do this too about the DHCPNAK response?

This part of RFC 2131 is quite clear in my opinion:

 3. The client receives one or more DHCPOFFER messages from one or more
 servers.  The client may choose to wait for multiple responses.
 The client chooses one server from which to request configuration
 parameters, based on the configuration parameters offered in the
 DHCPOFFER messages.  The client broadcasts a DHCPREQUEST message
 that MUST include the 'server identifier' option to indicate which
 server it has selected, and that MAY include other options
 specifying desired configuration values. [...]

  4. The servers receive the DHCPREQUEST broadcast from the client.
 Those servers not selected by the DHCPREQUEST message use the
 message as notification that the client has declined that server's
 offer.  The server selected in the DHCPREQUEST message commits the
 binding for the client to persistent storage and responds with a
 DHCPACK message containing the configuration parameters for the
 requesting client. [...]

So the behavior of server 10.0.1.1 seems not compliant to RFC.

> > Also, RFC 2131 says that the "If the client receives a DHCPNAK
> > message, the client restarts the configuration process", that is what
> > the internal client does, until the ACK comes before or until
> > timeout. dhclient apparently ignores the NAK, but I haven't found yet
> > in the code where this is done and based on what.
> 
> 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

 Aug 06 15:48:15 cventin NetworkManager[797]:   [1565099295.6037] dhcp4 
(enp0s25): dhclient started with pid 1052
 Aug 06 15:48:15 cventin dhclient[1052]: DHCPREQUEST for 140.77.13.17 on 
enp0s25 to 255.255.255.255 port 67
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPREQUEST for 140.77.13.17 on 
enp0s25 to 255.255.255.255 port 67
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPNAK from 10.0.1.1
 Aug 06 15:48:21 cventin NetworkManager[797]:   [1565099301.7956] dhcp4 
(enp0s25): state changed unknown -> expire
 Aug 06 15:48:21 cventin NetworkManager[797]:   [1565099301.8037] dhcp4 
(enp0s25): state changed expire -> unknown
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPDISCOVER on enp0s25 to 
255.255.255.255 port 67 interval 4
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPOFFER of 140.77.13.17 from 
140.77.1.12
 Aug

Bug#933930: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works

2019-08-09 Thread Vincent Lefevre 
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.

> Looking at dhcp-int-failure.pcap, there is an offer from 140.77.1.11:
> 
>   12:29:03.690421 94:f1:28:19:08:00 > 98:90:96:bd:7f:f7, ethertype IPv4 
> (0x0800), length 366: (tos 0x0, ttl 63, id 55318, offset 0, flags [DF], proto 
> UDP (17), length 352)
> 140.77.1.11.67 > 140.77.13.17.68: BOOTP/DHCP, Reply, length 324, hops 1, 
> xid 0xff001675, secs 2, Flags [none]
> Your-IP 140.77.13.17
> Server-IP 140.77.14.50
> Gateway-IP 140.77.12.1
> Client-Ethernet-Address 98:90:96:bd:7f:f7
> file "/lpxelinux.0"[|bootp]
> 
> to which the internal client replies with a request. Note the
> server-id set to 140.77.1.11:
> 
>   12:29:03.690539 98:90:96:bd:7f:f7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 
> (0x0800), length 340: (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto 
> UDP (17), length 326)
> 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 
> 98:90:96:bd:7f:f7, length 298, xid 0xff001675, secs 2, Flags [none]
> Client-Ethernet-Address 98:90:96:bd:7f:f7
> Vendor-rfc1048 Extensions
>   Magic Cookie 0x63825363
>   DHCP-Message Option 53, length 1: Request
>   Client-ID Option 61, length 7: ether 98:90:96:bd:7f:f7
>   Parameter-Request Option 55, length 18: 
> Subnet-Mask, Default-Gateway, Hostname, Domain-Name
> Domain-Name-Server, Time-Zone, MTU, BR
> Classless-Static-Route, Static-Route, YD, YS
> NTP, Server-ID, Option 119, Classless-Static-Route-Microsoft
> Option 252, RP
>   MSZ Option 57, length 2: 576
>   Server-ID Option 54, length 4: 140.77.1.11
>   Requested-IP Option 50, length 4: 140.77.13.17
>   Hostname Option 12, length 7: "cventin"
> 
> The DHCP server at 10.0.1.1 NAKs the request even if it had a
> different server-id; I don't think this is correct:
> 
>   12:29:03.691585 5c:96:9d:6d:9d:48 > ff:ff:ff:ff:ff:ff, ethertype IPv4 
> (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto 
> UDP (17), length 328)
> 10.0.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 
> 0xff001675, secs 2, Flags [Broadcast]
> Server-IP 10.0.1.1
> Client-Ethernet-Address 98:90:96:bd:7f:f7
> Vendor-rfc1048 Extensions
>   Magic Cookie 0x63825363
>   DHCP-Message Option 53, length 1: NACK
>   Server-ID Option 54, length 4: 10.0.1.1
>   MSG Option 56, length 31: "requested address not available"

RFC 2131 says: "If a server receives a DHCPREQUEST message with an
invalid 'requested IP address', the server SHOULD respond to the
client with a DHCPNAK message and may choose to report the problem
to the system administrator."

So this seems correct. Note that it does not say that the server must
check the server-id, and the fact that it says "a server" instead of
"the server" tends to make me think that this is how it works.

BTW, if the server implicitly needs to check the server-id, why
doesn't the internal client do this too about the DHCPNAK response?

> Also, RFC 2131 says that the "If the client receives a DHCPNAK
> message, the client restarts the configuration process", that is what
> the internal client does, until the ACK comes before or until
> timeout. dhclient apparently ignores the NAK, but I haven't found yet
> in the code where this is done and based on what.

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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#933930: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works

2019-08-09 Thread Beniamino Galvani 
On Fri, Aug 09, 2019 at 01:10:55PM +0200, Vincent Lefevre wrote:
> On 2019-08-09 09:42:10 +0200, Beniamino Galvani wrote:
> > On Thu, Aug 08, 2019 at 06:07:41PM +0200, Vincent Lefevre wrote:
> ...
> > Could you capture DHCP packets with:
> > 
> >   tcpdump -i enp0s25 -s 0 -w dhcp.pcap udp port 67 or port 68
> > 
> > when using dhclient and the failing internal client, and attach the
> > files?
> 
> dhcp-dhclient.pcap- using dhclient (success, though NAK came first)
> 
> dhcp-int-failure.pcap - using the internal client (failures until
> I stopped the capture; ACK never came first)
> 
> dhcp-int-success.pcap - using the internal client (success after
> several requests, once ACK came first)
> 

Hi,

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?

Looking at dhcp-int-failure.pcap, there is an offer from 140.77.1.11:

  12:29:03.690421 94:f1:28:19:08:00 > 98:90:96:bd:7f:f7, ethertype IPv4 
(0x0800), length 366: (tos 0x0, ttl 63, id 55318, offset 0, flags [DF], proto 
UDP (17), length 352)
140.77.1.11.67 > 140.77.13.17.68: BOOTP/DHCP, Reply, length 324, hops 1, 
xid 0xff001675, secs 2, Flags [none]
  Your-IP 140.77.13.17
  Server-IP 140.77.14.50
  Gateway-IP 140.77.12.1
  Client-Ethernet-Address 98:90:96:bd:7f:f7
  file "/lpxelinux.0"[|bootp]

to which the internal client replies with a request. Note the
server-id set to 140.77.1.11:

  12:29:03.690539 98:90:96:bd:7f:f7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 
(0x0800), length 340: (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto 
UDP (17), length 326)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 
98:90:96:bd:7f:f7, length 298, xid 0xff001675, secs 2, Flags [none]
  Client-Ethernet-Address 98:90:96:bd:7f:f7
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether 98:90:96:bd:7f:f7
Parameter-Request Option 55, length 18: 
  Subnet-Mask, Default-Gateway, Hostname, Domain-Name
  Domain-Name-Server, Time-Zone, MTU, BR
  Classless-Static-Route, Static-Route, YD, YS
  NTP, Server-ID, Option 119, Classless-Static-Route-Microsoft
  Option 252, RP
MSZ Option 57, length 2: 576
Server-ID Option 54, length 4: 140.77.1.11
Requested-IP Option 50, length 4: 140.77.13.17
Hostname Option 12, length 7: "cventin"

The DHCP server at 10.0.1.1 NAKs the request even if it had a
different server-id; I don't think this is correct:

  12:29:03.691585 5c:96:9d:6d:9d:48 > ff:ff:ff:ff:ff:ff, ethertype IPv4 
(0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto 
UDP (17), length 328)
10.0.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 
0xff001675, secs 2, Flags [Broadcast]
  Server-IP 10.0.1.1
  Client-Ethernet-Address 98:90:96:bd:7f:f7
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: NACK
Server-ID Option 54, length 4: 10.0.1.1
MSG Option 56, length 31: "requested address not available"

Also, RFC 2131 says that the "If the client receives a DHCPNAK
message, the client restarts the configuration process", that is what
the internal client does, until the ACK comes before or until
timeout. dhclient apparently ignores the NAK, but I haven't found yet
in the code where this is done and based on what.

Beniamino


signature.asc
Description: PGP signature

Bug#933930: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works

2019-08-09 Thread Vincent Lefevre 
On 2019-08-09 09:42:10 +0200, Beniamino Galvani wrote:
> On Thu, Aug 08, 2019 at 06:07:41PM +0200, Vincent Lefevre wrote:
> > On 2019-08-08 13:37:04 +0200, Michael Biebl wrote:
> > > Bringing Vincent into the loop here.
> > > 
> > > Vincent, can you gather the information Beniamino is asking for?
> > > 
> > > Am 08.08.19 um 09:51 schrieb Beniamino Galvani:
> > > > Would it be possible to capture a dump of DHCP packets for a success
> > > > and for a failure?
> > 
> > Each time after DHCP Request, there are 1 NAK packet (from 10.0.1.1)
> > and 2 NAK packets (from 140.77.1.11 and 140.77.1.12), but not always
  ^^^ ACK

Grrr... I meant "ACK". Sorry. Being a bit tired...

> > in the same order.
> > 
> > With the internal DHCP client, this seems to be a success only if an
> > ACK packet comes first. There is no such issue with the external one.

By an ACK packet, I meant, one of the 2 packets from 140.77.1.*.

> > Do you need more information?
> 
> Could you capture DHCP packets with:
> 
>   tcpdump -i enp0s25 -s 0 -w dhcp.pcap udp port 67 or port 68
> 
> when using dhclient and the failing internal client, and attach the
> files?

dhcp-dhclient.pcap- using dhclient (success, though NAK came first)

dhcp-int-failure.pcap - using the internal client (failures until
I stopped the capture; ACK never came first)

dhcp-int-success.pcap - using the internal client (success after
several requests, once ACK came first)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


dhcp-dhclient.pcap
Description: Binary data


dhcp-int-failure.pcap
Description: Binary data


dhcp-int-success.pcap
Description: Binary data

Bug#933930: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works

2019-08-09 Thread Beniamino Galvani 
On Thu, Aug 08, 2019 at 06:07:41PM +0200, Vincent Lefevre wrote:
> On 2019-08-08 13:37:04 +0200, Michael Biebl wrote:
> > Bringing Vincent into the loop here.
> > 
> > Vincent, can you gather the information Beniamino is asking for?
> > 
> > Am 08.08.19 um 09:51 schrieb Beniamino Galvani:
> > > Would it be possible to capture a dump of DHCP packets for a success
> > > and for a failure?
> 
> Each time after DHCP Request, there are 1 NAK packet (from 10.0.1.1)
> and 2 NAK packets (from 140.77.1.11 and 140.77.1.12), but not always
> in the same order.
> 
> With the internal DHCP client, this seems to be a success only if an
> ACK packet comes first. There is no such issue with the external one.
> 
> Do you need more information?

Could you capture DHCP packets with:

  tcpdump -i enp0s25 -s 0 -w dhcp.pcap udp port 67 or port 68

when using dhclient and the failing internal client, and attach the
files? Or, if you prefer, attach the decoded text output:

  tcpdump -vvenni enp0s25 udp port 67 or port 68

Thanks,
Beniamino


signature.asc
Description: PGP signature

Bug#933930: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works

2019-08-08 Thread Vincent Lefevre 
On 2019-08-08 13:37:04 +0200, Michael Biebl wrote:
> Bringing Vincent into the loop here.
> 
> Vincent, can you gather the information Beniamino is asking for?
> 
> Am 08.08.19 um 09:51 schrieb Beniamino Galvani:
> > Would it be possible to capture a dump of DHCP packets for a success
> > and for a failure?

Each time after DHCP Request, there are 1 NAK packet (from 10.0.1.1)
and 2 NAK packets (from 140.77.1.11 and 140.77.1.12), but not always
in the same order.

With the internal DHCP client, this seems to be a success only if an
ACK packet comes first. There is no such issue with the external one.

Do you need more information?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#933930: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works

2019-08-08 Thread Michael Biebl 
Bringing Vincent into the loop here.

Vincent, can you gather the information Beniamino is asking for?

Am 08.08.19 um 09:51 schrieb Beniamino Galvani:
> On Wed, Aug 07, 2019 at 05:00:01PM +0200, Michael Biebl wrote:
>> Full downstream bug report at
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933930
> 
> Hi,
> 
> comparing a successful run to a failed one, the only difference
> visible from logs is that sometimes the server replies with a NAK
> instead of an ACK.
> 
> Aug 07 14:06:14  [1565179574.0438] libsystemd: DHCP CLIENT 
> (0x1bf948fc): OFFER
> Aug 07 14:06:14  [1565179574.0439] libsystemd: DHCP CLIENT 
> (0x1bf948fc): received message was not an ACK, ignoring
> Aug 07 14:06:14  [1565179574.0439] libsystemd: DHCP CLIENT 
> (0x1bf948fc): REQUEST (requesting)
> Aug 07 14:06:14  [1565179574.0441] libsystemd: DHCP CLIENT 
> (0x1bf948fc): received message was not an ACK, ignoring
> Aug 07 14:06:14  [1565179574.0448] libsystemd: DHCP CLIENT 
> (0x1bf948fc): NAK: requested address not available
> 
> Aug 07 14:04:28  [1565179468.2149] libsystemd: DHCP CLIENT 
> (0x299b0344): OFFER
> Aug 07 14:04:28  [1565179468.2150] libsystemd: DHCP CLIENT 
> (0x299b0344): received message was not an ACK, ignoring
> Aug 07 14:04:28  [1565179468.2151] libsystemd: DHCP CLIENT 
> (0x299b0344): REQUEST (requesting)
> Aug 07 14:04:28  [1565179468.2164] libsystemd: DHCP CLIENT 
> (0x299b0344): ACK
> Aug 07 14:04:28  [1565179468.2417] libsystemd: DHCP CLIENT 
> (0x299b0344): lease expires in 23h 59min 57s
> Aug 07 14:04:28  [1565179468.2418] libsystemd: DHCP CLIENT 
> (0x299b0344): T2 expires in 20h 59min 58s
> Aug 07 14:04:28  [1565179468.2418] libsystemd: DHCP CLIENT 
> (0x299b0344): T1 expires in 11h 59min 59s
> 
> Would it be possible to capture a dump of DHCP packets for a success
> and for a failure? And also with dhclient (but perhaps this is not
> necessary). Do you know which DHCP server it is?
> 
> Beniamino
> 
> 
>>  Weitergeleitete Nachricht 
>> Betreff: Re: [Pkg-utopia-maintainers] Bug#933930: Bug#933930:
>> Bug#933930: network-manager: Ethernet connection no longer works
>> Datum: Wed, 7 Aug 2019 15:58:04 +0200
>> Von: Vincent Lefevre 
>> An: Michael Biebl 
>> Kopie (CC): 933...@bugs.debian.org
>>
>> On 2019-08-07 12:57:37 +0200, Michael Biebl wrote:
>>>  mbiebl_, Unclear what is not working. Could you ask for
>>> level=TRACE logs? See
>>> https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28
>>> , preferably without ratelimiting from journal (see also the comment)
>>
>> I've attached an archive with 3 log files of tests with the
>> internal dhcp client:
>>
>>   * nm-1.19.90-failing (with network-manager 1.19.90-2).
>> I had to wait for more that one minute to get an IP address, and this
>> was not even the correct one (I normally have a fixed IP address).
>> Sometimes, this is worse, e.g. after each of the following reboots
>>   REBOOT in 1s
>>   REBOOT in 2s
>>   REBOOT in 4s
>>   REBOOT in 8s
>>   REBOOT in 16s
>>   REBOOT in 32s
>>   REBOOT in 1min 4s
>> I got "NAK: requested address not available". I did not wait longer.
>>
>>   * nm-1.19.90-working (with network-manager 1.19.90-2).
>> I got the correct IP address (140.77.13.17) after 5 seconds.
>> This is OK.
>>
>>   * nm-1.20.0-failing (with network-manager 1.20.0-1).
>> After each of the following reboots
>>   REBOOT in 1s
>>   REBOOT in 2s
>>   REBOOT in 4s
>>   REBOOT in 8s
>>   REBOOT in 16s
>>   REBOOT in 32s
>>   REBOOT in 1min 4s
>> I got "NAK: requested address not available". I did not wait longer.
>> I tried several times and could not make it work.
>> Still no issues with dhcp=dhclient.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature