Unable to ping DNS/NTP

[Beaker]

After the recent updates, I’m just discovering that I’m no longer able to ping my statically set DNS for my wan, and NTP directly from the R10:

Cloudflare DNS: 1.1.1.1
Cloudflare NTP: time.cloudflare.com

Verified both function while bypassing the R10. Anyone else with a locally controlled network able to confirm theirs and also the DNS above?

[rutman286]

I will try to test tonight for you if I can Beaker.

[Beaker]

Thanks @rutman286. Very strange. As mentioned, I began noticing slower response times on resolution which prompted me to check and lo and behold, both were unreachable, through both SSH and cut-through. Still down as of today for those particular DNS/NTP services. Quite ridiculous.

[rutman286]

Hi @Beaker. So far I have not been able to cause the issue on my Route10. I am hoping Alta support can help us figure out what’s up!

[Beaker]

All roads in my opinion continue to lead to this unreliable Control appliance. Either that or the Route10. Nothing ever appears to go wrong, or can be emulated in the lab. I find it hard to believe that I’m the only one on this planet with such a simplified configuration experiencing issue after issue. I’m only glad I didn’t toss the original boxes.

[Beaker]

I just tried again this morning, and all of a sudden after removing the static Cloudflare DNS for 12 hours or so and replacing with another, all of a sudden I can now ping both. I’m not going to mark this as resolved. Clearly something is up. In addition, the logs are still showing wrong dates.

[Alta-Josh]

@Beaker

In addition, the logs are still showing wrong dates.

I can’t speak on the other issue you experienced, but the logs viewer should be in local time while the on-device logs are in UTC instead. In my experience the dates and timestamps are correct if you account for that.

[Beaker]

I’m speaking of the actual messages file. The dates are showing October when we’re in August.

Oct 24 09:01:51.224 XX-XX-RTR-01 daemon.info dnsmasq-dhcp[6590]: DHCPACK(br-lan_10)

[ebuckland81]

I can confirm I have seen October 24, last year, in the logs too.

Edit: For me, a portion of the log since reboot says October 24. Seems like some logs are time stamped before clock has synchronized?!

[jmszuch]

I think you might be on to something there @ebuckland81

I have persistent logging eanbled on most of my sites, but a quick check of one of the sites that doesn’t have persistent logging enabled showed some logs with the October 24 time stamp. I’ll see if I can check a couple others and better confirm if that’s part of the difference when I have a little more time

[Alta-Josh]

Do the logs start in October after boot, and then skip over to the current date after some time?

[jmszuch]

I’ll need to double check but I think that’s what I observed, @Alta-Josh

[ebuckland81]

So, it seems pretty consistent. After a reboot, a portion of the logs are time stamped with the mysterious October 24, 2024. Then, after some 25-30 s (at least for the S8 switch), the time stamp turns correct. Breaking point for one startup marked in screenshot below. The specific log event does not seem to be associated to the point where time stamp turns correct. I guess this might be hard to work around altogether if there is no built in battery that help maintain time over reboots?!

If @Beaker sees these erroneous logs even later on (?!), then that is another issue, related or not.

And, I guess this has diverted away from the original topic

[Alta-Jeff]

The logs on October 24 are expected, and are due to the device not having a time sync when it first boots.

[jmszuch]

Understood! Although, and forgive me if this is incorrect, isn’t there a script called sysfixtime that should be pulling a more recent date and time from a file in /etc on boot before any syncing kicks in? That’s my understanding anyway

# cat /etc/init.d/sysfixtime 
#!/bin/sh /etc/rc.common
# Copyright (C) 2013-2014 OpenWrt.org

START=00
STOP=90

RTC_DEV=/dev/rtc0
HWCLOCK=/sbin/hwclock

boot() {
        start && exit 0

        local maxtime="$(maxtime)"
        local curtime="$(date +%s)"
        [ $curtime -lt $maxtime ] && date -s @$maxtime
}

start() {
        [ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -s -u -f $RTC_DEV
}

stop() {
        [ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -w -u -f $RTC_DEV && \
                logger -t sysfixtime "saved '$(date)' to $RTC_DEV"
}

maxtime() {
        local file newest

        for file in $( find /etc -type f ) ; do
                [ -z "$newest" -o "$newest" -ot "$file" ] && newest=$file
        done
        [ "$newest" ] && date -r "$newest" +%s
}

[Alta-Jeff]

There is no RTC in the Route10 hardware, so you would need a UPS to ensure that the time is never lost on the device, at least if you used it as an NTP server. We have considered storing the time periodically to flash, but we are balancing that feature with trying to avoid wearing the flash as well.

[jmszuch]

Gotcha, thanks Jeff. I imagine with the implementation of the persistent logging feature, unnecessary wear to the flash really has to be kept top of mind.