← Back to team overview

debcrafters-packages team mailing list archive

[Bug 2126573] Re: n-dhcp4: Do not set ciaddr in DISCOVER state.

 

Focal is EOSS (but fixed in NM-snap on core20): v1.22.10-31

-- 
You received this bug notification because you are a member of
Debcrafters packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2126573

Title:
  n-dhcp4: Do not set ciaddr in DISCOVER state.

Status in network-manager package in Ubuntu:
  New
Status in network-manager source package in Focal:
  Won't Fix
Status in network-manager source package in Jammy:
  New
Status in network-manager source package in Noble:
  New
Status in network-manager source package in Plucky:
  New
Status in network-manager source package in Questing:
  New

Bug description:
  [ Impact ]

   * The vendored n-dhcp in NetworkManager does not set ciaddr in
  DISCOVER state. This is invalid according to RFC 2131 table 1
  ("Description of fields in a DHCP message") and has previously been
  discussed in https://github.com/nettools/n-dhcp4/issues/45.

   * I came up with a patch to reset ciaddr in INIT state, so we do not
  include the "Client-IP" in any messages, until we receive another
  DHCP-ACK.

  [ Test Plan ]

   * execute as bash -x repro.sh

  ```
  #!/bin/bash

  trap "trap - SIGTERM && kill -- -$$" SIGINT SIGTERM EXIT

  ip netns add ns1
  ip link add veth0 type veth peer name veth1 netns ns1
  ip link set veth0 up
  ip -n ns1 link set veth1 up
  ip -n ns1 address add dev veth1 172.25.1.4/24

  ip netns exec ns1 dnsmasq --bind-interfaces --interface veth1 --dhcp-
  range=172.25.1.100,172.25.1.150,60

  tcpdump -venni veth0 udp port 67 &
  sleep 5

  nmcli connection add type ethernet ifname veth0 con-name veth0+ ipv6.method disabled autoconnect no
  nmcli connection up veth0+

  sleep 5  # wait for DHCP ACK

  ip addr flush dev veth0  # clear IP received from DHCP server
  ip addr add 172.25.1.42/24 dev veth0  # add non-DHCP address
  ip addr show dev veth0
  killall dnsmasq
  ip netns exec ns1 dnsmasq --bind-interfaces --interface veth1 --dhcp-range=172.25.1.151,172.25.1.200,60

  sleep 240

  nmcli connection delete veth0+
  ip link delete veth0
  ip netns delete ns1
  ```

  Without the change, I can see the following DISCOVER message after the
  sleep 240: => Notice the Client-IP 172.25.1.126, which is wrong.

  """
  14:45:13.755789 2a:02:0c:7b:bc:81 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: (tos 0xc0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 336)
      0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 2a:02:0c:7b:bc:81, length 308, xid 0x4acac969, secs 1, Flags [none]
  	  Client-IP 172.25.1.126
  	  Client-Ethernet-Address 2a:02:0c:7b:bc:81
  	  Vendor-rfc1048 Extensions
  	    Magic Cookie 0x63825363
  	    DHCP-Message (53), length 1: Discover
  	    Client-ID (61), length 7: ether 2a:02:0c:7b:bc:81
  	    Parameter-Request (55), length 17: 
  	      Subnet-Mask (1), Time-Zone (2), Domain-Name-Server (6), Hostname (12)
  	      Domain-Name (15), MTU (26), BR (28), Classless-Static-Route (121)
  	      Default-Gateway (3), Static-Route (33), YD (40), YS (41)
  	      NTP (42), Unknown (119), Classless-Static-Route-Microsoft (249), Unknown (252)
  	      RP (17)
  	    MSZ (57), length 2: 576
  	    Hostname (12), length 30: "lp2116214-jammy-n-dhcp4-ciaddr"
  """

  With the change, we should see this instead (after the sleep 240): =>
  No Client-IP header inside the DISCOVER message

  """
  14:53:45.217406 2a:02:0c:7b:bc:81 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: (tos 0xc0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 336)
      0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 2a:02:0c:7b:bc:81, length 308, xid 0x55d8ec3c, secs 1, Flags [none]
  	  Client-Ethernet-Address 2a:02:0c:7b:bc:81
  	  Vendor-rfc1048 Extensions
  	    Magic Cookie 0x63825363
  	    DHCP-Message (53), length 1: Discover
  	    Client-ID (61), length 7: ether 2a:02:0c:7b:bc:81
  	    Parameter-Request (55), length 17: 
  	      Subnet-Mask (1), Time-Zone (2), Domain-Name-Server (6), Hostname (12)
  	      Domain-Name (15), MTU (26), BR (28), Classless-Static-Route (121)
  	      Default-Gateway (3), Static-Route (33), YD (40), YS (41)
  	      NTP (42), Unknown (119), Classless-Static-Route-Microsoft (249), Unknown (252)
  	      RP (17)
  	    MSZ (57), length 2: 576
  	    Hostname (12), length 30: "lp2116214-jammy-n-dhcp4-ciaddr"
  """

  [ Where problems could occur ]

   * This is touching NetworkManager's internal DHCPv4 client, so if
  anything goes wrong, we could see issues with acquiring dynamic IPv4
  addresses.

  [ Other Info ]

   * Ubuntu Core20 bug in LP: #2116214
   * Upstream PR: https://github.com/nettools/n-dhcp4/pull/48

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2126573/+subscriptions



References