[BUG?] udhcpc makes use of DHCP options which weren't specifically requested

For Developers
1

Hi, guys!

Today I noticed that my local NTP server is using two additional upstream servers which aren't specified in the system configuration…

 6383 root      1084 S<   /usr/sbin/ntpd -n -N -l -S /usr/sbin/ntpd-hotplug -p ntp01.oal.ul.pt -p ntp02.oal.ul.pt -p ntp03.oal.ul.pt -p ntp04.oal.ul.pt -p ntp05.oal.ul.pt -p ntp06.oal.ul.pt -p 213.205.64.133 -p 213.205.64.197

… now, those last two servers are being obtained by udhcpc, as we can see when executing ifstatus wan:

	"data": {
		"leasetime": 14400,
		"ntpserver": "213.205.64.133 213.205.64.197",
		"timezone": 0
	}

After noticing this, I changed my WAN network configuration to…

config interface 'wan'
	option ifname 'eth2'
	option ipv6 '0'
	option proto 'dhcp'
	option peerdns '0'
	option defaultreqopts '0'
	option reqopts '1 3 15 50 51 54 58 59'

… and, sure enough, udhcpc only requests these specific options, as shown on this tcpdump capture:

15:36:06.369290 IP (tos 0x0, ttl 64, id 13144, offset 0, flags [DF], proto UDP (17), length 328)
    a95-94-77-68.cpe.netcabo.pt.68 > a109-49-15-254.cpe.netcabo.pt.67: BOOTP/DHCP, Request from d8:58:d7:00:41:9b (oui Unknown), length 300, xid 0x5c727e04, Flags [none]
	  Client-IP a95-94-77-68.cpe.netcabo.pt
	  Client-Ethernet-Address d8:58:d7:00:41:9b (oui Unknown)
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Request
	    MSZ Option 57, length 2: 576
	    Parameter-Request Option 55, length 9: 
	      Subnet-Mask, Default-Gateway, Domain-Name, Requested-IP
	      Lease-Time, Server-ID, RN, RB
	      Classless-Static-Route
	    Vendor-Class Option 60, length 12: "udhcp 1.30.1"
	    Hostname Option 12, length 12: "heimdall.lan"
15:36:06.377908 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 362)
    a109-49-15-254.cpe.netcabo.pt.67 > a95-94-77-68.cpe.netcabo.pt.68: BOOTP/DHCP, Reply, length 334, hops 1, xid 0x5c727e04, Flags [none]
	  Client-IP a95-94-77-68.cpe.netcabo.pt
	  Your-IP a95-94-77-68.cpe.netcabo.pt
	  Gateway-IP a109-49-15-254.cpe.netcabo.pt
	  Client-Ethernet-Address d8:58:d7:00:41:9b (oui Unknown)
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: ACK
	    Subnet-Mask Option 1, length 4: 255.255.240.0
	    Default-Gateway Option 3, length 4: a95-94-79-254.cpe.netcabo.pt
	    Domain-Name Option 15, length 10: "netcabo.pt"
	    Lease-Time Option 51, length 4: 14400
	    Server-ID Option 54, length 4: a109-49-15-254.cpe.netcabo.pt
	    RN Option 58, length 4: 7200
	    RB Option 59, length 4: 12600
	    Time-Zone Option 2, length 4: 0
	    Time-Server Option 4, length 8: indhcp111a.nos.pt,indhcp111b.nos.pt
	    Domain-Name-Server Option 6, length 8: a212-113-191-130.cpe.netcabo.pt,62.169.70.160.rev.optimus.pt
	    LOG Option 7, length 4: a212-113-188-209.cpe.netcabo.pt
	    NTP Option 42, length 8: indhcp111a.nos.pt,indhcp111b.nos.pt

So, my question is, how do I stop the system from using DHCP options which weren't requested, even if the server chooses to send them?

1 Like
2

Set option use_dhcp 0 in the ntp section of /etc/config/system if you do not want the NTP service to pick up DHCP leased NTP servers.

I am not aware of other default services picking up the published DHCP info.

2 Likes
3

Yeah, that did the trick, thanks. Should be documented, though. I spent a couple of hours reading the netifd source code, I guess I was digging in the wrong place. :wink:

4

I exposed the option in the gui as well now.
For reference, the code would've been here: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/utils/busybox/files/sysntpd;h=52866ba32acd26a490f9c9024fc3e43e0f757496;hb=e39d1cf34f97667b8fc1cdb60beec7a12e70839d#l76

4 Likes
5

Still, that only helps people who use LuCI. I have no need for a web interface and do all configuration through SSH. Anyway, I updated the wiki page accordingly.

Hm. Aren't we violating the principle of least surprise by defaulting to 1?

1 Like
6

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.