I have a time restriction to shut down access at 23:00. Today with time change the restriction came into effect at 22:00. My system shows time of 22:20, for instance. I do not have the UTC box clicked. my system does show local time. I speculate that the fw is using X hours off of UTC and not recognizing that the diff is no long X hours now that local time has changed with "fall back" (daylight savings time is OFF now).
What version of OpenWrt are you using?
ubus call system board
And what package did you install for this functionality?
1 Like
I think I've only added adblock and luci-app-adblock. Is there a natural way to find out the more recent packages I might have added?
BusyBox v1.36.1 (2024-03-22 22:09:42 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 23.05.3, r23809-234f1a2efa
-----------------------------------------------------
root@OpenWrt:~# ubus call system board
ubus call system board
{
"kernel": "5.15.150",
"hostname": "OpenWrt",
"system": "Qualcomm Atheros QCA956X ver 1 rev 0",
"model": "TP-Link Archer A7 v5",
"board_name": "tplink,archer-a7-v5",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "23.05.3",
"revision": "r23809-234f1a2efa",
"target": "ath79/generic",
"description": "OpenWrt 23.05.3 r23809-234f1a2efa"
}
}
root@OpenWrt:~# opkg list
opkg list
adblock - 4.1.5-9
ath10k-board-qca988x - 20230804-1
ath10k-firmware-qca988x-ct - 2020-11-08-1
base-files - 1554-r23809-234f1a2efa
busybox - 1.36.1-1
ca-bundle - 20230311-1
cgi-io - 2022-08-10-901b0f04-21
coreutils - 9.3-1
coreutils-sort - 9.3-1
dnsmasq - 2.90-2
dropbear - 2022.82-6
firewall4 - 2023-09-01-598d9fbb-1
fstools - 2023-02-28-bfe882d5-1
fwtool - 2019-11-12-8f7fe925-1
getrandom - 2022-08-13-4c7b720b-2
hostapd-common - 2023-09-08-e5ccbfc6-6
iw - 5.19-1
iwinfo - 2023-07-01-ca79f641-1
jansson4 - 2.14-3
jshn - 2023-05-23-75a3b870-1
jsonfilter - 2024-01-23-594cfa86-1
kernel - 5.15.150-1-34a8cffa541c94af8232fe9af7a1f5ba
kmod-ath - 5.15.150+6.1.24-3
kmod-ath10k-ct - 5.15.150+2022-05-13-f808496f-5
kmod-ath9k - 5.15.150+6.1.24-3
kmod-ath9k-common - 5.15.150+6.1.24-3
kmod-cfg80211 - 5.15.150+6.1.24-3
kmod-crypto-acompress - 5.15.150-1
kmod-crypto-aead - 5.15.150-1
kmod-crypto-ccm - 5.15.150-1
kmod-crypto-cmac - 5.15.150-1
kmod-crypto-crc32c - 5.15.150-1
kmod-crypto-ctr - 5.15.150-1
kmod-crypto-gcm - 5.15.150-1
kmod-crypto-gf128 - 5.15.150-1
kmod-crypto-ghash - 5.15.150-1
kmod-crypto-hash - 5.15.150-1
kmod-crypto-hmac - 5.15.150-1
kmod-crypto-manager - 5.15.150-1
kmod-crypto-null - 5.15.150-1
kmod-crypto-rng - 5.15.150-1
kmod-crypto-seqiv - 5.15.150-1
kmod-crypto-sha512 - 5.15.150-1
kmod-gpio-button-hotplug - 5.15.150-3
kmod-hwmon-core - 5.15.150-1
kmod-lib-crc-ccitt - 5.15.150-1
kmod-lib-crc32c - 5.15.150-1
kmod-lib-lzo - 5.15.150-1
kmod-mac80211 - 5.15.150+6.1.24-3
kmod-nf-conntrack - 5.15.150-1
kmod-nf-conntrack6 - 5.15.150-1
kmod-nf-flow - 5.15.150-1
kmod-nf-log - 5.15.150-1
kmod-nf-log6 - 5.15.150-1
kmod-nf-nat - 5.15.150-1
kmod-nf-reject - 5.15.150-1
kmod-nf-reject6 - 5.15.150-1
kmod-nfnetlink - 5.15.150-1
kmod-nft-core - 5.15.150-1
kmod-nft-fib - 5.15.150-1
kmod-nft-nat - 5.15.150-1
kmod-nft-offload - 5.15.150-1
kmod-nls-base - 5.15.150-1
kmod-phy-ath79-usb - 5.15.150-1
kmod-ppp - 5.15.150-1
kmod-pppoe - 5.15.150-1
kmod-pppox - 5.15.150-1
kmod-random-core - 5.15.150-1
kmod-slhc - 5.15.150-1
kmod-usb-core - 5.15.150-1
kmod-usb-ehci - 5.15.150-1
kmod-usb-ledtrig-usbport - 5.15.150-1
kmod-usb2 - 5.15.150-1
libblobmsg-json20230523 - 2023-05-23-75a3b870-1
libc - 1.2.4-4
libgcc1 - 12.3.0-4
libiwinfo-data - 2023-07-01-ca79f641-1
libiwinfo20230701 - 2023-07-01-ca79f641-1
libjson-c5 - 0.16-3
libjson-script20230523 - 2023-05-23-75a3b870-1
liblucihttp-ucode - 2023-03-15-9b5b683f-1
liblucihttp0 - 2023-03-15-9b5b683f-1
libmbedtls12 - 2.28.7-2
libmnl0 - 1.0.5-1
libnftnl11 - 1.2.6-1
libnl-tiny1 - 2023-07-27-bc92a280-1
libpthread - 1.2.4-4
libubox20230523 - 2023-05-23-75a3b870-1
libubus20230605 - 2023-06-05-f787c97b-1
libuci20130104 - 2023-08-10-5781664d-1
libuclient20201210 - 2023-04-13-007d9454-1
libucode20230711 - 2023-11-07-a6e75e02-1
libustream-mbedtls20201210 - 2023-02-25-498f6e26-1
logd - 2022-08-13-4c7b720b-2
luci - git-23.051.66410-a505bb1
luci-app-adblock - git-24.086.45142-09d5a38
luci-app-firewall - git-24.067.01746-69867db
luci-app-opkg - git-24.043.63812-c89a68b
luci-base - git-24.073.29889-cd7e519
luci-light - git-23.024.33244-34dee82
luci-mod-admin-full - git-19.253.48496-3f93650
luci-mod-network - git-24.075.44893-ac63bea
luci-mod-status - git-24.064.82650-3cbf270
luci-mod-system - git-24.067.01860-7a82b2f
luci-proto-ipv6 - git-23.355.78874-80140aa
luci-proto-ppp - git-21.158.38888-88b9d84
luci-ssl - git-23.035.26083-7550ad6
luci-theme-bootstrap - git-24.072.69878-ca51167
mtd - 26
netifd - 2024-01-04-c18cc79d-1
nftables-json - 1.0.8-1
odhcp6c - 2023-05-12-bcd28363-20
odhcpd-ipv6only - 2023-10-24-d8118f6e-1
openwrt-keyring - 2022-03-25-62471e69-2
opkg - 2022-02-24-d038e5b6-2
ppp - 2.4.9.git-2021-01-04-4
ppp-mod-pppoe - 2.4.9.git-2021-01-04-4
procd - 2023-06-25-2db83655-2
procd-seccomp - 2023-06-25-2db83655-2
procd-ujail - 2023-06-25-2db83655-2
px5g-mbedtls - 10
rpcd - 2023-07-01-c07ab2f9-1
rpcd-mod-file - 2023-07-01-c07ab2f9-1
rpcd-mod-iwinfo - 2023-07-01-c07ab2f9-1
rpcd-mod-luci - 20240305-1
rpcd-mod-rrdns - 20170710
rpcd-mod-ucode - 2023-07-01-c07ab2f9-1
swconfig - 12
uboot-envtools - 2023.04-1
ubox - 2022-08-13-4c7b720b-2
ubus - 2023-06-05-f787c97b-1
ubusd - 2023-06-05-f787c97b-1
uci - 2023-08-10-5781664d-1
uclient-fetch - 2023-04-13-007d9454-1
ucode - 2023-11-07-a6e75e02-1
ucode-mod-fs - 2023-11-07-a6e75e02-1
ucode-mod-html - 1
ucode-mod-math - 2023-11-07-a6e75e02-1
ucode-mod-nl80211 - 2023-11-07-a6e75e02-1
ucode-mod-rtnl - 2023-11-07-a6e75e02-1
ucode-mod-ubus - 2023-11-07-a6e75e02-1
ucode-mod-uci - 2023-11-07-a6e75e02-1
ucode-mod-uloop - 2023-11-07-a6e75e02-1
uhttpd - 2023-06-25-34a8a74d-2
uhttpd-mod-ubus - 2023-06-25-34a8a74d-2
urandom-seed - 3
urngd - 2023-11-01-44365eb1-1
usign - 2020-05-23-f1f65026-1
wireless-regdb - 2024.01.23-1
wpad-basic-mbedtls - 2023-09-08-e5ccbfc6-6
root@OpenWrt:~#
You may want to upgrade to 23.05.5, but that's not going to affect this issue.
I asked which packages you are using to ensure that there would be appropriate context... "filter-parental-controls" is not part of the default OpenWrt install, so the specific methods by which you were doing filtering just needed a bit of clarification.
Anyway, I'm not the right person to help with Adblock, but now that we know what you're using, hopefully Adblock users on the forum can chime in to help out. I'll also update the title to indicate that this is an Adblock related question.
1 Like
I guess it could be adblock.
If you're unsure, we have no way to read your mind or guess what packages you've installed. All we can go on is what you tell us. Maybe you can show a screenshot of the page you're looking at?
On cursory investigation this seems to be part of standard firewall. In luci.
Perhaps you should start a new thread, containing facts, instead of guesses ?
So far, 3 out of 3 things you've posted, have been incorrect.
Parental controls is not part of the standard OpenWrt firewall.
What are you actually looking at? Screenshots, please?
Perhaps the parental is just a name i gave the rule. The rule took effect at 22:00 tonight. What else can i tell you?
Thanks
Yeah, that's your own rule. It's not related to AdBlock (I'll change the title again).
Let's see the following:
cat /etc/config/firewall
cat /etc/config/system
My speculation is the firewall is perhaps using systemd timers and not adapting to local time chances. I’m too lazy to investigate this.
If you're not interested in spending a little bit of energy to provide the answers to our questions so that we can learn about the config and details of the issue at hand, we obviously cannot help you resolve it. That's fine, but shall I close this thread since it seems that you've indicated that it's not worth your time to troubleshoot?
In the underlying nftables rules, the start and end times are stored as seconds relative to 00:00 UTC. So you may see the timing sync up again by restarting the firewall or rebooting the router.
Disclaimer: I have no clue about nftables and the firewall settings in this regard, just picking brains here.
nftales not knowing about local dates and time zones would mean time based rules are fundamentally broken in nftables. A little hard to imagine, unless "don't use local dates, they will come back and hurt you" is part of the nftables documentation.
Even if I converted from local time to UTC at the time of saving, I'd cause an off-by-one error whenever switching from standard time to daylight saving time. My current time zone is "UTC+1" in winter and will bei "UTC+2" in summer. There can't be a static "just substract {$h} when local time zone is {$z}" all year long, since that {$h} changes, and the dates when {$h} n change depends on {$z}.
Are you sure about that?
I'm just assuming you are. Both, sure and correct.
Such a thing could, of course, explain the described behavior. Most parts of the world are currently around daylight saving time (Northern Hemisphere countries, basically). Since the time field has not date value assigned to it but, on its own, is meant as "all year round", it would totally make sense to convert time from local to UTC in standard time, not daylight saving.
@golialive - to your point about time zones, that's why I asked for both the system and firewall config files.
I think (but don't know for sure) that if the time zone is set to a specific region (and not purely the UTC offset), daylight savings/standard time should be observed according to the local observance. A simple UTC offset would not guarantee that shift. (I can see this failing in some places like Arizona where they do not shift the clocks so simply setting America/Denver might not work).
But we don't know how the OP's device is configured or even what time zone they are in.
We don't
https://git.netfilter.org/nftables/commit/?id=f8f32deda31df597614d9f1f64ffb0c0320f4d54
According to the commit that added the feature in nftables, the Linux kernel has no concept of time zones internally.
I recall that Asus routers will restart the firewall after a DST time change is detected, probably for the sake of their own parental controls feature.
If it only happens twice a year, I would hesitate to say it’s fundamental broken, but it isn’t user friendly.
@dave14305 - just to make sure it doesn't come across the wrong way... I'm now curious and just want to know more... so I'm asking questions in that mindset, not challenging you.
Fair enough. So would that mean that the time zone setting specifically affects the higher level calls that need localized time (i.e. date, logging timestamps, etc.)? Those calls would query the kernel's time and assume it is in UTC, then apply the offiset?
If that's the case, and assuming that the DST/ST change happens as a function of the time zone data (since some parts of the world either don't change or may have different dates for the changes to take effect)?
And then tying it back to the firewall and net filter stack as implemented in OpenWrt, isn't the UTC checkbox the mechanism to tell the firewall if you are referencing UTC or local time? That is to say, even if the kernel itself isn't time zone aware, wouldn't the routines that translate the config file/UCI data into the underlying nf rules/chains be time zone aware? (otherwise, why have the UTC checkbox?)
https://en.m.wikipedia.org/wiki/Principle_of_least_astonishment
I wasn’t astonished but i was surprised when the firewall cut me off. Overall I’m so happy with openwrt that i hesitate to even file reports. Well also no cause.