[Dnsmasq-discuss] Option82 subnet selection and DHCPREQUEST bug

Simon Kelley simon at thekelleys.org.uk
Sat Jan 20 23:47:16 GMT 2018


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.


On 22/12/17 22:25, Jérôme Fleury wrote:
> 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
> <http://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 <http://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 ?
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20180120/b1d4fc9d/attachment.sig>


More information about the Dnsmasq-discuss mailing list