pgaskin / KoboStuff

Automatically updated Kobo firmware download page. Also see pgaskin/kfwproxy for the backend.
https://pgaskin.net/KoboStuff/kobofirmware.html
MIT License
49 stars 4 forks source link

Clara HD - firmware 4.25.15875 is requesting and then ignoring DHCP option 42 (NTP) #16

Closed wegotourselvesareader closed 3 years ago

wegotourselvesareader commented 3 years ago

Pretty much summed up in the title but, in case more detail is needed:

This behaviour has been observed on a Clara HD running firmware 4.25.15875

A packet capture of the DORA sequence on the DHCP server shows that the Clara HD is requesting an NTP server (option 42), and the DHCP server is responding with the details of an appropriate NTP server.

A packet capture on the NTP server shows no NTP queries received from the Clara HD.

A packet capture on the DNS server shows that the Clara HD thinks it knows better than the DHCP server, and is attempting to look up various pool.ntp.org addresses instead of using the NTP server it's been told to use.

A packet capture on the firewall shows that the Clara HD is attempting to communicate outbound on 123/udp to servers other than the one it's been told to use.

Could the next firmware update fix this, please, so that the device obeys the instructions it receives and queries the NTP server supplied to it in the Option 42 response?

pgaskin commented 3 years ago

I'm not a Kobo employee...

You'd need to modify the ntpd configuration on the Kobo itself as a workaround.

Is there a specific reason why you want to do this?

wegotourselvesareader commented 3 years ago

The network in question has restrictions on it which limit what management traffic may leave it. It also has a stratum 1 source, so an external stratum 2 or even 3 isn't necessary. In addition, well-mannered network devices should do what they're told as a matter of course.

You make a good point about prodding ntpd directly. I'll have a poke around the device's filesystem and see what I can do. Thanks for the suggestion.

wegotourselvesareader commented 3 years ago

Found the culprit: /libexec/dhcpcd-hooks/50-ntpdate has the ntp.org pool FQDNs hard-coded into it.

/etc/dhcpcd.conf contains an entry for option 42 (ntp_servers), which explains the request in the DORA sequence, but that 50-ntpdate script doesn't use the DHCP server's response. Mystery solved.

Now to get stuck into the dark art of firmware modification...

pgaskin commented 3 years ago

Now to get stuck into the dark art of firmware modification...

You can edit the script directly over Telnet, or you can create a KoboRoot.tgz (manually or with kobopatch) to use the usual update process. You'll need to do this after every firmware update, though.