kanedauy
3217
Hello David and like always thanks for your work,
With the new update I'm seeing this in my system logs:
Sat Sep 14 13:41:25 2019 daemon.err collectd[4788]: Not sleeping because the next interval is 193.713 seconds in the past!
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: uc_update: Value too old: name = OpenWrt/interface-br-lan/if_packets; value time = 1568468486.158; last cache update = 1568468486.158;
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: Filter subsystem: Built-in target `write': Dispatching value to all write plugins failed with status -1.
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: uc_update: Value too old: name = OpenWrt/cpu-1/cpu-idle; value time = 1568468486.157; last cache update = 1568468486.158;
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: uc_update: Value too old: name = OpenWrt/cpu-0/cpu-idle; value time = 1568468486.157; last cache update = 1568468486.158;
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/load/load.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/interface-br-lan/if_octets.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/interface-br-lan/if_errors.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/interface-br-lan/if_dropped.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/memory/memory-used.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/memory/memory-buffered.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/memory/memory-cached.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/memory/memory-free.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/memory/memory-slab_unrecl.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/memory/memory-slab_recl.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-0/cpu-user.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-1/cpu-user.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-0/cpu-system.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-1/cpu-system.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-0/cpu-wait.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-1/cpu-wait.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-0/cpu-nice.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-1/cpu-nice.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-0/cpu-interrupt.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-1/cpu-interrupt.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-0/cpu-softirq.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-1/cpu-softirq.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-0/cpu-steal.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: Filter subsystem: Built-in target `write': Some write plugin is back to normal operation. `write' succeeded.
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/iwinfo-wlan1/bitrate.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/iwinfo-wlan1/signal_power.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/iwinfo-wlan1/signal_noise.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/iwinfo-wlan1/signal_quality.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/iwinfo-wlan1/stations.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/iwinfo-wlan0/bitrate.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/iwinfo-wlan0/signal_power.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/iwinfo-wlan0/signal_noise.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/iwinfo-wlan0/signal_quality.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Sat Sep 14 13:41:26 2019 daemon.err collectd[4788]: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/iwinfo-wlan0/stations.rrd: illegal attempt to update using time 1568468486 when last update time is 1568468486 (minimum one second step)
Any idea why collectd is having al this issues?
slim0287
3218
I use dnscrypt-proxy v2, so it would be great if you'd bake it directly into your build. While I'm at it, I'll also request wireguard and vpn-policy-routing to be in your build as well. 
2 Likes
Kherby
3219
+1 for vpn-policy-routing
Hi All. To work in Windows 7 I had to buy an adapter ASUS PCE-AC88. And I came across a strange situation. If I use channels above 100 (inclusive), I get a connection break after a while (4-10 hours). In the log I find the following entries:
Thu Sep 5 00:55:30 2019 kern.info kernel: [45405.578366] ieee80211 phy0: radar detected by firmware
Thu Sep 5 00:55:30 2019 daemon.notice hostapd: wlan0: DFS-RADAR-DETECTED freq=5540 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5530 cf2=0
Thu Sep 5 00:55:30 2019 daemon.notice hostapd: wlan0: DFS-NEW-CHANNEL freq=5180 chan=36 sec_chan=1
Thu Sep 5 00:55:30 2019 kern.info kernel: [45406.128684] ieee80211 phy0: channel switch is done
Thu Sep 5 00:55:30 2019 kern.debug kernel: [45406.133502] ieee80211 phy0: change: 0x60
Thu Sep 5 00:55:30 2019 daemon.info hostapd: wlan0: IEEE 802.11 driver had channel switch: freq=5180, ht=1, vht_ch=0x0, offset=1, width=3 (80 MHz), cf1=5210, cf2=0
Thu Sep 5 00:55:30 2019 daemon.notice hostapd: wlan0: AP-CSA-FINISHED freq=5180 dfs=0
As I understand it, this is due to "DFS-RADAR-DETECTED." But here is the question. This only happens in the bundle WRT32X + ASUS PCE-AC88. WRT32X + Intel AC 9260 and WRT32X + Realtek RTL8814AU do not have such a problem. Also TP-Link Archer C59 + ASUS PCE-AC88 do not have such a problem.
Routers use OpenWrt 18.06.4. And WRT32X is UK(EU) version.
I had the same issue and tried to track it down. Best I could determine it has sometime to do with the system time on the router i.e. NTP. I did not find the actual problem but when I reboot after syncing with NTP/Browser I do not get the error.
I just left it and will see if it is an issue on Davidc502's next image.
I am hoping it goes away with updates to Collectd or RRD in the next image.
All seems to work OK even with those error lines you mentioned.
Sorry I couldn't be of more help.
Means you have either an Emergency/Radar etc near you using said frequency. However it may not happen on other routers as it changes automatically to another channel. However the Marvell driver doesn't as far as I can seem even when channel is set to auto.
Much appreciate those who would like to add packages. Right now my hands are tied in doing so due to size restrictions. I've tried to bring up to the developers what I though was improper allocation of space, and was clearly told it was working as expected.
Bottom line is if I add more programs it will break some others.
1 Like
Side not just built an R1100 version from master. Seems a bit more snappier then last one.
I understand where you coming from though with space as is tight on the older WRT's.
It's not hard to run the dnscrypt-proxy V2 script so it's all good.
WRT32X + Intel AC 9260 and WRT32X + Realtek RTL8814AU do not have such a problem. Only WRT32X + ASUS PCE-AC88. This means that there is no radar. It's some kind of mistake. How to fix it?
I'm not aware that it can be fixed. I can't use DFS channels either because its so dang sensitive.
Sorry. Why are you reasoning like this? Here's the obvious malfunctioning of something inside OpenWrt for WRT32X.
For several months I used the bundle WRT32X + Intel AC 9260. And there were no disconnections and channel changes by the router. The same day that I installed the ASUS PCE-AC88, disconnects started. I checked again the WRT32X with other adapters on channels above 100. And I did not find any problems. I checked the ASUS PCE-AC88 with another router (TP-Link Archer C59) on channels above 100. And there were no problems.
Is it possible that the WRT32X begins to consider the ASUS PCE-AC88 adapter itself as a radar after some time? Can I contact the OpenWrt developers? And what is the best way to do this?
Do you mean the ASUS PCE-AC88 settings?
slh
3230
There are device constellations which will (falsely) trip the DFS detection algorithms of different chipsets/ drivers (but different drivers might be more or less susceptible to mis-detections). Who's actually at fault is impossible to answer outside of a highly qualified rf/ hf lab - and it doesn't just affect mwlwifi hardware.
Writing a DFS pattern detector that survives regulatory scrutiny is easy, but it's very hard to fine tune (it mustn't ever miss a real DFS event) it sufficiently to reduce falsely detected DFS events - and the quality between firmware/ driver combinations differs massively.
But this cannot be left just like that. There is a specific case with specific devices. Can I notify someone who worked on this in OpenWrt? By the way, stock firmware (which is also OpenWrt) also has this problem. I will also try to ask the question to Linksys.
slh
3232
This would be an upstream issue, not an OpenWrt specific one (and no, the OEM firmware is not OpenWrt, nor does it use OpenWrt's kernel or the opensource mwlwifi driver - it uses a proprietary one). No, it doesn't help you that mwlwifi has never been merged into the mainline kernel, neither does it help that most of this is done in proprietary firmware. Even less does it help that Marvell has sold their wireless division to NXP, which won't actually assume ownership before 2020, nor that Marvell has effectively ceased 88W8964 development (if at all, their focus would be on 802.11ax hardware and drivers at this point).
So, if you want to get hold of someone in charge, someone accountable, to look into your issue and get it fixed -pronto-, the most helpful thing would probably to go outside and scream into a well…
Unless you can offer Marvell/ NXP big money (with many zeroes, at least six or seven of them, as it will inevitably will require changes to the proprietary firmware), that's probably as effective as filing a bug report at https://github.com/kaloz/mwlwifi/issues (the canonical upstream for mwlwifi development) at this point, but feel free to entertain that route.
You are not quite right. The original firmware is based on OpenWrt. There is a proprietary .bin on the original firmware. On OpenWrt 18.06.4 there is mwlwifi. But there is a problem on both.
Maybe this is hostapd/wpad ...
Let's look at the facts and see if we can at least guess what is wrong:
-
issue occurs on wrt32x stock
-
issue occurs on wrt32x OpenWrt
-
issue has not been reported on other platforms
-
stock uses proprietary driver
-
stock uses proprietary firmware bin
-
OpenWrt uses mwlwifi
-
OpenWrt uses proprietary firmware bin
Link the common things and cross out the ones that don't match, and you end up screaming into the well, as suggested by @slh.
And we can't even begin to figure out what might be wrong because at line 1762 of hif/fwcmd.c, we can see the driver handing all radar detection responsibility over to the black box.
You might not like the answer, but that's the reality of where this driver got to and now likely to stay indefinitely.
The only hope of rescue would be someone like candelatech signing and NDA and creating a mwlwifi-ct type driver. But no one is currently interested and even if they were, do you think a company in the middle of divesting its wireless division is particularly interested in dealing with onboarding a new client?
All we can hope for is 88W9064 gaining momentum and developer backing, and raising such issues while someone is still being paid to look at it. However, that is not going to fix the legacy hardware.
But you are not inclined to think that hostapd/wpad does not work correctly on this platform?
