Clock: inserting leap second weirdness?

OK, have been running the 17.01.0 final for a few days now, and have seen something weird.
Earlier at the end of Dec, while running one of the pre-rc versions, I happily noted that the router knew about the Leap Second as we went into 2017. Fine.

Today, I found the last group of three entries at the end of my kernel log, Some kind of bug perhaps?

End of normal reboot.
[ 36.509315] random: nonblocking pool is initialized

Some time later, not sure what this is, but have seen it several times.
[ 922.731856] u32 classifier
[ 922.734609] input device check on
[ 922.738472] Actions configured
[ 922.752836] Mirror/redirect action on

Have seen this a few times, not sure either, maybe a "test"?
[ 7721.220394] conntrack: generic helper won't handle protocol 47. Please consider loading the specific helper module.

OK, pretty sure that we didn't need any more chrono/astronomical adjustments this year...
[100085.242114] Clock: inserting leap second 23:59:60 UTC
[186484.713698] Clock: inserting leap second 23:59:60 UTC
[272884.175938] Clock: inserting leap second 23:59:60 UTC

The router is a TP-Link Archer C7 v3 (labled v3's are found in the US, very similar to v2), running the 17.01.1 stable release version. Been up 3d almost 11hrs since the update to the release version. Hadn't seen a leap second since the actual one on that FW, didn't see any on -rc1 that I ran for a month or so prior to updating to the final release version.

Let me know if there's a better place than here for a bug report...

Linux kernel developer mailing list?

I think that leap second handling is done by the kernel itself. I don't remember seeing any commits here regarding that.

Possibly it could also be the ntpd client in Busybox(?), but sounds more unlikely. Have you installed any NTP related packages like chrony?

Somebody mentioned leap second also at the end of January, so this seems to be a monthly bug. Short February probably adds confusion to the buggy algorithm somewhere.

PS. u32 is the packet classifier controlled by tc and used e.g. by QoS tools like SQM. Conntrac warning is typical, it merely tells that protocol 47 GRE is not handled by the default tools.

Nope, nothing NTP related. I've installed luci-app-sqm, that's it. (which I now see explains the U32 entry) Interestingly, I don't have a clock 3 seconds fast... probably regular time server syncs correct out the "leap seconds" before I've noticed them.

Weird that I hadn't seen this the past couple of updates, maybe it is just in the newer kernel? Or maybe I haven't crossed the end of a month with my past upgrade before this, hmmm, not sure...

Appreciate learning about the other log entries... have quite a few questions in that category, I'm saving for other posts....

I think that the extra erroneous leap second was mentioned for the first time at the end of Jan 2017. So it is something new. And now you got three, probably dues to short February. It is either due to newer kernels, new busybox ntpd, or buggy data in ntpd servers used (so that busybox ntpd gets wrong data and passes it to kernel).

I checked kernel sources and busybox sources but did not spot any relevant recent changes.