Discussion:
[Dnsmasq-discuss] Option82 subnet selection and DHCPREQUEST bug
Jérôme Fleury
2017-12-22 22:25:17 UTC
Permalink
Hi all,

Here is my config:

log-dhcp
dhcp-authoritative
interface=bond0
listen-address=10.36.20.19

dhcp-range=set:int32,10.36.60.5,10.36.60.253,255.255.255.0,60 # LAN DHCP
scope
dhcp-option=tag:int32,option:router

dhcp-option=tag:int32,121,10.36.0.0/16,10.36.60.1
dhcp-option=tag:int32,option:ntp-server,10.36.25.26



I am seeing this unexpected behavior with these packets:

This is a relayed DHCP Discover from a Cisco Nexus switch:

103.21.247.66.67 > 10.36.20.19.67: [udp sum ok] BOOTP/DHCP, Request
from a8:1e:84:c3:16:8c, length 336, hops 1, xid 0x2085a416, secs 1, Flags
[none] (0x0000)
Gateway-IP 103.21.247.66
Client-Ethernet-Address a8:1e:84:c3:16:8c
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 19: hardware-type 255,
46:58:db:60:00:02:00:00:ab:11:3b:1a:a9:7f:6a:55:35:27
Parameter-Request Option 55, length 9:
Subnet-Mask, Default-Gateway, Hostname, Domain-Name
Domain-Name-Server, Static-Route, Classless-Static-Route, NTP
TZ-Name
MSZ Option 57, length 2: 576
Requested-IP Option 50, length 4: 10.36.60.49
Agent-Information Option 82, length 48:
Circuit-ID SubOption 1, length 14: ^A^H^@^F^@^@'^Z^@^@^@^@^@^@
Remote-ID SubOption 2, length 6: ^@:}M-^V+^M
Unknown SubOption 151, length 10:
0x0000: 0069 6e74 6572 6e61 6c73
Unknown SubOption 11, length 4:
0x0000: 0a24 3c01
Unknown SubOption 5, length 4:
0x0000: 0a24 3c00

It contains SubOption 11 for RFC5107 and SubOption 5 for RFC 3527

Request is being treated properly by dnsmasq and the offer being sent is:

20:50:36.793610 IP (tos 0xc0, ttl 64, id 45936, offset 0, flags [none],
proto UDP (17), length 379)
162.158.65.83.67 > 103.21.247.66.67: [bad udp cksum 0x43c2 -> 0xaf47!]
BOOTP/DHCP, Reply, length 351, hops 1, xid 0x2085a416, secs 1, Flags [none]
(0x0000)
Your-IP 10.36.60.49
Server-IP 10.36.20.19
Gateway-IP 103.21.247.66
Client-Ethernet-Address a8:1e:84:c3:16:8c
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.36.60.1
Lease-Time Option 51, length 4: 120
SUBNET Option 118, length 4: 10.36.60.0
RN Option 58, length 4: 60
RB Option 59, length 4: 105
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 10.36.60.255
NTP Option 42, length 4: 10.36.25.26
Classless-Static-Route Option 121, length 7: (10.36.0.0/16:10.36.60.1)
Agent-Information Option 82, length 48:
Circuit-ID SubOption 1, length 14: ^A^H^@^F^@^@'^Z^@^@^@^@^@^@
Remote-ID SubOption 2, length 6: ^@:}M-^V+^M
Unknown SubOption 151, length 10:
0x0000: 0069 6e74 6572 6e61 6c73
Unknown SubOption 11, length 4:
0x0000: 0a24 3c01
Unknown SubOption 5, length 4:
0x0000: 0a24 3c00


According to RFC5107, Server-ID is correctly forced to the relay
10.36.60.1. It's all looking good.

Problem is on the renewal of the lease:

Request received is:

22:07:00.710302 IP (tos 0xc0, ttl 251, id 48805, offset 0, flags [none],
proto UDP (17), length 370)
103.21.247.66.67 > 10.36.20.19.67: [udp sum ok] BOOTP/DHCP, Request
from a8:1e:84:c3:16:8c, length 342, hops 1, xid 0xa046c86b, secs 1738,
Flags [none] (0x0000)
Gateway-IP 103.21.247.66
Client-Ethernet-Address a8:1e:84:c3:16:8c
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 19: hardware-type 255,
46:58:db:60:00:02:00:00:ab:11:3b:1a:a9:7f:6a:55:35:27
Parameter-Request Option 55, length 9:
Subnet-Mask, Default-Gateway, Hostname, Domain-Name
Domain-Name-Server, Static-Route, Classless-Static-Route, NTP
TZ-Name
MSZ Option 57, length 2: 576
Server-ID Option 54, length 4: 10.36.20.19
Requested-IP Option 50, length 4: 10.36.60.49
Agent-Information Option 82, length 48:
Circuit-ID SubOption 1, length 14: ^A^H^@^F^@^@'^Z^@^@^@^@^@^@
Remote-ID SubOption 2, length 6: ^@:}M-^V+^M
Unknown SubOption 151, length 10:
0x0000: 0069 6e74 6572 6e61 6c73
Unknown SubOption 11, length 4:
0x0000: 0a24 3c01
Unknown SubOption 5, length 4:
0x0000: 0a24 3c00

This request never gets acknowledged by dnsmasq.

I have identified the line that silently drops the request:

https://github.com/imp/dnsmasq/blob/master/src/rfc2131.c#L1093

If I bypass this check, the request is correctly acknowledged and replied
to.

I don't see anything wrong with the Request, and I'm not sure what the
check is supposed to mean.

Can anyone confirm this is indeed a bug ?
Simon Kelley
2018-01-20 23:47:16 UTC
Permalink
That's old code, and pre-dates detailed git logs, but it's fairly clear
that the test is implementing this part of RFC 5107


When servicing a DHCPREQUEST message, the DHCP server would normally
look at the Server Identifier option for verification that the
address specified there is one of the addresses associated with the
DHCP server, silently ignoring the DHCPREQUEST if it does not match a
configured DHCP server interface address. If the DHCPREQUEST message
contains a Server Identifier Override suboption, however, comparison
should be made between the address in this suboption and the Server
Identifier option. If both the Server Identifier Override suboption
and the Server Identifier option specify the same address, then the
server should accept the DHCPREQUEST message for processing,
regardless of whether or not the Server Identifier option matches a
DHCP server interface.


So the problem is that the client, on renewal, is sending the server-ID
as 10.36.20.19, which is tripping the test specified above.

Cheers,

Simon.
Post by Jérôme Fleury
Hi all,
log-dhcp
dhcp-authoritative
interface=bond0
listen-address=10.36.20.19
dhcp-range=set:int32,10.36.60.5,10.36.60.253,255.255.255.0,60 # LAN DHCP
scope
dhcp-option=tag:int32,option:router
dhcp-option=tag:int32,121,10.36.0.0/16,10.36.60.1
<http://10.36.0.0/16,10.36.60.1>
dhcp-option=tag:int32,option:ntp-server,10.36.25.26
    103.21.247.66.67 > 10.36.20.19.67: [udp sum ok] BOOTP/DHCP, Request
from a8:1e:84:c3:16:8c, length 336, hops 1, xid 0x2085a416, secs 1,
Flags [none] (0x0000)
  Gateway-IP 103.21.247.66
  Client-Ethernet-Address a8:1e:84:c3:16:8c
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Discover
    Client-ID Option 61, length 19: hardware-type 255,
46:58:db:60:00:02:00:00:ab:11:3b:1a:a9:7f:6a:55:35:27
      Subnet-Mask, Default-Gateway, Hostname, Domain-Name
      Domain-Name-Server, Static-Route, Classless-Static-Route, NTP
      TZ-Name
    MSZ Option 57, length 2: 576
    Requested-IP Option 50, length 4: 10.36.60.49
0x0000:  0069 6e74 6572 6e61 6c73
0x0000:  0a24 3c01
0x0000:  0a24 3c00
It contains SubOption 11 for RFC5107 and SubOption 5 for RFC 3527
20:50:36.793610 IP (tos 0xc0, ttl 64, id 45936, offset 0, flags [none],
proto UDP (17), length 379)
    162.158.65.83.67 > 103.21.247.66.67: [bad udp cksum 0x43c2 ->
0xaf47!] BOOTP/DHCP, Reply, length 351, hops 1, xid 0x2085a416, secs 1,
Flags [none] (0x0000)
  Your-IP 10.36.60.49
  Server-IP 10.36.20.19
  Gateway-IP 103.21.247.66
  Client-Ethernet-Address a8:1e:84:c3:16:8c
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Offer
    Server-ID Option 54, length 4: 10.36.60.1
    Lease-Time Option 51, length 4: 120
    SUBNET Option 118, length 4: 10.36.60.0
    RN Option 58, length 4: 60
    RB Option 59, length 4: 105
    Subnet-Mask Option 1, length 4: 255.255.255.0
    BR Option 28, length 4: 10.36.60.255
    NTP Option 42, length 4: 10.36.25.26
(10.36.0.0/16:10.36.60.1 <http://10.36.0.0/16:10.36.60.1>)
0x0000:  0069 6e74 6572 6e61 6c73
0x0000:  0a24 3c01
0x0000:  0a24 3c00
According to RFC5107, Server-ID is correctly forced to the relay
10.36.60.1. It's all looking good.
22:07:00.710302 IP (tos 0xc0, ttl 251, id 48805, offset 0, flags [none],
proto UDP (17), length 370)
    103.21.247.66.67 > 10.36.20.19.67: [udp sum ok] BOOTP/DHCP, Request
from a8:1e:84:c3:16:8c, length 342, hops 1, xid 0xa046c86b, secs 1738,
Flags [none] (0x0000)
  Gateway-IP 103.21.247.66
  Client-Ethernet-Address a8:1e:84:c3:16:8c
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Request
    Client-ID Option 61, length 19: hardware-type 255,
46:58:db:60:00:02:00:00:ab:11:3b:1a:a9:7f:6a:55:35:27
      Subnet-Mask, Default-Gateway, Hostname, Domain-Name
      Domain-Name-Server, Static-Route, Classless-Static-Route, NTP
      TZ-Name
    MSZ Option 57, length 2: 576
    Server-ID Option 54, length 4: 10.36.20.19
    Requested-IP Option 50, length 4: 10.36.60.49
0x0000:  0069 6e74 6572 6e61 6c73
0x0000:  0a24 3c01
0x0000:  0a24 3c00
This request never gets acknowledged by dnsmasq.
https://github.com/imp/dnsmasq/blob/master/src/rfc2131.c#L1093
If I bypass this check, the request is correctly acknowledged and
replied to. 
I don't see anything wrong with the Request, and I'm not sure what the
check is supposed to mean.
Can anyone confirm this is indeed a bug ?
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Loading...