[Pkg-utopia-maintainers] Bug#947613: Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1

[Vincent Bernat]

Hello Michael,

I was able to hit the bug again. It seems I have to go to another wifi
network, then back to my home network to hit the bug. On the
client-side, I get:

janv. 06 18:57:13 zoro NetworkManager[75721]: <info>  [1578333433.9474] dhcp4 (wlp3s0): activation: beginning transaction (timeout in 45 seconds)
janv. 06 18:57:13 zoro NetworkManager[75721]: <debug> [1578333433.9532] dhcp4 (wlp3s0): sent REQUEST to 255.255.255.255
janv. 06 18:57:13 zoro NetworkManager[75721]: <debug> [1578333433.9571] dhcp4 (wlp3s0): received NACK from 0.0.0.0
janv. 06 18:57:13 zoro NetworkManager[75721]: <info>  [1578333433.9572] dhcp4 (wlp3s0): state changed unknown -> fail

On the server-side, I am using dnsmasq. Logs say:

Jan 06 18:51:39 eizo dnsmasq-dhcp[2841]: DHCPREQUEST(lan-trusted) 192.168.117.40 3e:55:59:b2:a3:b9
Jan 06 18:51:39 eizo dnsmasq-dhcp[2841]: DHCPNAK(lan-trusted) 192.168.117.40 3e:55:59:b2:a3:b9 address in use

I am a bit puzzled why dnsmasq says that, but it didn't happen with
older versions of Network Manager. If I capture the request and
response, I get:

18:57:13.952425 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 317)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 3e:55:59:b2:a3:b9, length 289, xid 0xa9a8ed40, Flags [none] (0x0000)
          Client-Ethernet-Address 3e:55:59:b2:a3:b9
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Client-ID Option 61, length 7: ether 3e:55:59:b2:a3:b9
            Parameter-Request Option 55, length 18:
              Subnet-Mask, Time-Zone, Domain-Name-Server, Hostname
              Domain-Name, MTU, BR, Classless-Static-Route
              Default-Gateway, Static-Route, YD, YS
              NTP, Server-ID, Option 119, Classless-Static-Route-Microsoft
              Option 252, RP
            MSZ Option 57, length 2: 576
            Requested-IP Option 50, length 4: 192.168.117.40
            Hostname Option 12, length 4: "zoro"
            END Option 255, length 0
18:57:13.952596 IP (tos 0xc0, ttl 64, id 26751, offset 0, flags [none], proto UDP (17), length 328)
    192.168.117.1.67 > 255.255.255.255.68: [bad udp cksum 0x36ef -> 0x0984!] BOOTP/DHCP, Reply, length 300, xid 0xa9a8ed40, Flags [Broadcast] (0x8000)
          Client-Ethernet-Address 3e:55:59:b2:a3:b9
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: NACK
            Server-ID Option 54, length 4: 192.168.117.1
            MSG Option 56, length 14: "address in use"
            END Option 255, length 0
            PAD Option 0, length 0, occurs 34

But if I look at the lease file from dnsmasq, I see:

1578382414 e8:2a:ea:05:c0:df 192.168.117.40 zoro 01:e8:2a:ea:05:c0:df

So, I suppose this is a because of randomizatio of the MAC address on
wifi networks. I don't see anytrhing special in the NEWS file about
this. Previously, the hardware MAC address was used to do the DHCP
request.

When using dhcp=dhclient, I am getting the same NAK, but then the ISC
DHCP client is using DISCOVER and gets a new IP address.

RFC says "If the client receives a DHCPNAK message, the client
restarts the configuration process." So, I think the bug is more in the
fact that the DHCP client doesn't restart configuration when receiving a
NAK but just gives up.
-- 
Localise input and output in subroutines.
            - The Elements of Programming Style (Kernighan & Plauger)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/attachments/20200106/b659b11c/attachment-0001.sig>