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

[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/attachments/20190809/a640d950/attachment-0001.sig>