Unix/Linux Go Back    


UNIX for Beginners Questions & Answers If you're not sure where to post a Unix or Linux question, post it here. All unix and Linux beginners welcome in this forum!

DHCP Issue Possibly due to Hardware Clock?

UNIX for Beginners Questions & Answers


Reply    
 
Thread Tools Search this Thread Display Modes
    #1  
Old Unix and Linux 10-12-2017   -   Original Discussion by mrm5102
mrm5102 mrm5102 is offline
Registered User
 
Join Date: Jul 2012
Last Activity: 13 October 2017, 11:49 AM EDT
Posts: 198
Thanks: 100
Thanked 11 Times in 10 Posts
DHCP Issue Possibly due to Hardware Clock?

Hello All,

OS: openSUSE 13.1 (Bottle) (armv7hl)
PC: CuBox-i (*mini-pc)

The PC in question is a CuBox-i mini-pc. Since this PC doesn't have a battery, everytime the PC reboots the hardware clock is reset back to the same date every time, which is "2014-07-08 00:00".

I have NTP configured to get the current date and time from our NTP server, which does work eventually once the network comes up. Once the network is up, the NTP daemon runs and fixes the date and time.

However, I believe once NTP runs and changes the date and time, the DHCP lease timeout is reached (*14400 I believe). And because the time jumps ahead so far, it thinks the DHCP lease has timed-out and it gets a new IP Address. So within about a couple minutes of powering on, or rebooting the PC, it renews its DHCP Address and gets a new/2nd address.

I was wondering if maybe there is a way I can write the current system date and time so when it reboots, it doesn't think its 2014... Is anything like that possible?

Thanks in Advance,
Matt
Sponsored Links
    #2  
Old Unix and Linux 10-12-2017   -   Original Discussion by mrm5102
Scrutinizer's Unix or Linux Image
Scrutinizer Scrutinizer is offline Forum Staff  
Moderator
 
Join Date: Nov 2008
Last Activity: 18 November 2017, 12:20 AM EST
Location: Amsterdam
Posts: 11,617
Thanks: 516
Thanked 3,380 Times in 2,979 Posts
You could try using the date command to write the date to a file at shutdown and letting date set the date to what was recorded in that file at boot time before the network comes up.
The Following User Says Thank You to Scrutinizer For This Useful Post:
mrm5102 (10-12-2017)
Sponsored Links
    #3  
Old Unix and Linux 10-12-2017   -   Original Discussion by mrm5102
mrm5102 mrm5102 is offline
Registered User
 
Join Date: Jul 2012
Last Activity: 13 October 2017, 11:49 AM EDT
Posts: 198
Thanks: 100
Thanked 11 Times in 10 Posts
Hey, thanks for the reply.

That's a good idea. Where would be the best place to run the command/script so it executes as soon as possible during the boot process?

Thanks Again,
Matt
    #4  
Old Unix and Linux 10-12-2017   -   Original Discussion by mrm5102
Scott's Unix or Linux Image
Scott Scott is offline Forum Staff  
Administrator
 
Join Date: Jun 2009
Last Activity: 18 November 2017, 1:29 AM EST
Location: Zürich
Posts: 8,820
Thanks: 366
Thanked 1,196 Times in 1,022 Posts
You could use a @reboot cron job to read the date at boot time, but of course that's only effective when the cron daemon is started, and you need something else to write the file before shutting down.

As you want to tightly couple it to the DHCP daemon as much as possible, not a great solution, but is modifying the dhcpd start / stop script an option? You could also just run ntp to update the time before it starts the DHCP daemon.

Changing the order services start in could be another option, but there's no guarantee that ntdp will update the time before it gets to dhcpd.

(edit, after Bakunin's reply): I presume also that assigning static address(es) to the client(s) is not an option?

Last edited by Scott; 10-12-2017 at 05:15 PM.. Reason: edit
The Following User Says Thank You to Scott For This Useful Post:
mrm5102 (10-12-2017)
Sponsored Links
    #5  
Old Unix and Linux 10-12-2017   -   Original Discussion by mrm5102
bakunin bakunin is offline Forum Staff  
Bughunter Extraordinaire
 
Join Date: May 2005
Last Activity: 15 November 2017, 4:57 AM EST
Location: In the leftmost byte of /dev/kmem
Posts: 5,633
Thanks: 107
Thanked 1,603 Times in 1,180 Posts
Scott's idea is valid anyway, but if i remember TCP/IP correctly (my copy of TCP/IP Illustrated is not within reach right now) the DHCP server manages lease times, not the client.

You can also configure the DHCP server to always give the same IP-address to this client, because DHCP is the supersset of the older bootp-protocol, which did exactly that. Clients are identified by the MAC-address(es) of the interface(s) requiring an address. This way it doesn't matter if the address is requested once or twice.

I hope this helps.

bakunin
The Following User Says Thank You to bakunin For This Useful Post:
mrm5102 (10-12-2017)
Sponsored Links
    #6  
Old Unix and Linux 10-12-2017   -   Original Discussion by mrm5102
mrm5102 mrm5102 is offline
Registered User
 
Join Date: Jul 2012
Last Activity: 13 October 2017, 11:49 AM EDT
Posts: 198
Thanks: 100
Thanked 11 Times in 10 Posts
Hey Guys, thanks again for the replies. Much appreciated!

All good ideas. I do have the ability to do any of those that you suggested, as I have access to the DHCP server(s) that we run. But, these little mini-PCs are located in each of our branch locations, and their local Router/Switches are running as their DHCP servers, so that would be a lot of editing I would need to do in each location in order to statically assign the IP Address. And occasionally I need them to ship the PC back as it runs off an SDCard and gets all screwy, so I need to re-image the SDCard. When this happens I usually ship them a new one before they ship back the current one, so the MAC Address changes from time to time.

I guess I could modify each CuBox PC to assign its own address statically, that's another good option...

The date/time thing on these little PCs is annoying though. Not only does it have the DHCP thing going on, all the log's timestamps are all screwy inside the log files, as well as their file's modification times. It's like every file was modified 7-8-2014 or whatever the current day's date is. When looking at the boot log file, or messages, etc... You can see at boot it shows "7-8-2014 00:xx" and then during the boot you see NTP start, (*and then the Network services) which corrects the time. Like this below:

Code:
2014-07-08T00:00:12.180148-04:00 CuBox-PC2 ntpd[515]: ntpd 4.2.6p5@1.2349-o Tue Jul 22 08:39:03 UTC 2014 (1)
2014-07-08T00:00:12.186116-04:00 CuBox-PC2 ntpd[516]: proto: precision = 0.666 usec
2014-07-08T00:00:12.192294-04:00 CuBox-PC2 ntpd[516]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
2014-07-08T00:00:12.195052-04:00 CuBox-PC2 ntpd[516]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
2014-07-08T00:00:12.208862-04:00 CuBox-PC2 ntp[487]: Starting network time protocol daemon (NTPD)..done
2014-07-08T00:00:12.219279-04:00 CuBox-PC2 systemd[1]: Started LSB: Network time protocol daemon (ntpd).
2014-07-08T00:00:12.221496-04:00 CuBox-PC2 systemd[1]: Starting System Time Synchronized.
2014-07-08T00:00:12.227680-04:00 CuBox-PC2 ntpd[516]: Listen and drop on 1 v6wildcard :: UDP 123
2014-07-08T00:00:12.231513-04:00 CuBox-PC2 ntpd[516]: Listen normally on 2 lo 127.0.0.1 UDP 123
2014-07-08T00:00:12.239589-04:00 CuBox-PC2 ntpd[516]: Listen normally on 3 lo ::1 UDP 123
2014-07-08T00:00:12.249842-04:00 CuBox-PC2 ntpd[516]: peers refreshed
2014-07-08T00:00:12.252038-04:00 CuBox-PC2 ntpd[516]: Listening on routing socket on fd #20 for interface updates
................
......cut.....
................
2014-07-08T00:00:22.035161-04:00 CuBox-PC2 systemd[1]: Starting Network Manager Script Dispatcher Service...
2014-07-08T00:00:22.122828-04:00 CuBox-PC2 dbus[405]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
2014-07-08T00:00:22.129075-04:00 CuBox-PC2 systemd[1]: Started Network Manager Script Dispatcher Service.
2014-07-08T00:00:24.438413-04:00 CuBox-PC2 ModemManager[410]: <info>  Creating modem with plugin 'Generic' and '1' ports
2017-10-12T12:50:42.697027-04:00 CuBox-PC2 systemd[670]: Time has been changed
2017-10-12T12:50:42.702891-04:00 CuBox-PC2 systemd[640]: Time has been changed
2017-10-12T12:50:42.708762-04:00 CuBox-PC2 systemd[1]: Time has been changed
2017-10-12T12:50:42.959656-04:00 CuBox-PC2 systemd[1]: mgetty.service: main process exited, code=exited, status=20/n/a

I guess it's not really a huge problem, its just gotten very annoying. So maybe trying to get the date to write to a file and then write it back at boot-up (*maybe as soon as the shell starts) would kill a few birds with one stone...

Thanks Again,
Matt
Sponsored Links
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Linux More UNIX and Linux Forum Topics You Might Find Helpful
Thread Thread Starter Forum Replies Last Post
e2900 hardware issue? steve_b72 Solaris 7 09-26-2011 09:44 AM
What are the two ways the hardware clock can be configured under Linux? lemon_06 UNIX for Dummies Questions & Answers 3 10-31-2010 11:01 AM
DHCP config issue? macwunder IP Networking 1 04-28-2010 11:17 AM
how to reset the hardware clock daya.pandit Red Hat 1 11-07-2008 09:52 AM
hardware (BIOS) clock joseph kembo UNIX Desktop Questions & Answers 2 05-19-2005 03:51 PM



All times are GMT -4. The time now is 02:37 AM.