Messages

Just found that this issue has been raised in GitHub: os-ddclient - Gateway group as monitored interface in Multi WAN configurations #2899

I use the Dynamic DNS (legacy) plugin to update DNS entries on interface changes (e.g. primary internet fails and backup 4G interface goes active). My configuration monitors my gateway group (WAN_Failover - which has my two WAN interfaces and triggers on packet loss/latency). This setup is working perfectly.

However, there is now a little note displaying:

Please make sure to upgrade to os-ddclient before 22.7 is released as this plugin will be removed from our repository

This is all well and good. But the new Dynamic DNS plugin doesn't seem to support monitoring of gateway groups - only individual gateways. Is there something I've missed here? Or is there a workaround to recreate what I have with the legacy plugin in the new one?

Hi Steve,

Not sure if this is a technical issue with updating a specific record with Cloudfare or if it's an issue of updating multiple records in general. I have no experience with Cloudfare. So if it's the former, you might need to provide some more detail around what's happening.

If it's just about updating multiple records, then your situation sounds similar to mine. I'm using dynamic DNS with Namecheap, though. I have a record for my base domain and two other sub-domains. I have configured the Dynamic DNS (legacy) service with three separate entries. All entries are the same (Namecheap service type, username, password, etc) except for the hostname. IP address changes trigger all three of the entries and update all three records at Namecheap individually.

Does that help at all?

Nigel

Will do this and report. Thanks.

I finally got around to setting up Monit monitoring for the flowd_aggregate service. I've wanted to do this because I often find when I go to the Dashboard that the service has stopped. I'm now getting spammed by monit because it's constantly picking up the service down and restarting it.

I've noticed a pattern, though. The 'down' detections seem to happen on the hour - almost every hour. This has led me to question whether the flowd_aggregate is even supposed to stay running? Does anyone have any information on that? Am I monitoring something as a 'failure' when it's 'by design'??

Also, I've had issues with flowd_aggregate in the past with logs created because of crashes. There are no logs this time (other than monit, and the vacuum messages after restart).

Yes, but I personally don't really want to kill that data, it could be useful for debug purposes.

Agreed. A dashboard widget should not be responsible for removing unrelated data from the system. IMHO.

[temperature]

Sorry, @marjohn56. Thanks for testing. I had to go to bed eventually. I've picked it up again and taken a closer look at things. Here's my analysis:

The sysctrl_output.txt I attached previously may not have been entirely helpful. Not sure if @fruit's would have been more helpful. I didn't check. Anyhoo...

The sysctrl dump contained a value for kern.msgbuf with a whole lot of junk, including what seems to be web request logs. I removed them because they contained a bunch of IPs and domain names which I didn't want to go through and sanitise. Those logs include requests (presumably from the dashboard) to /widgets/api/get.php?load=system%2Ctraffic%2Ctemperature%2Cgateway%2Cinterfaces...

Code Select Expand

<118>2020-08-18T22:38:44.491556+10:00 firewall.xxxx lighttpd 79007 - - xxxx firewall.xxxx - [18/Aug/2020:22:38:44 +1000] "GET /widgets/api/get.php?load=system%2Ctraffic%2Ctemperature%2Cgateway%2Cinterfaces&_=1597753466133 HTTP/1.1" 200 8670 "http://firewall.xxxx/index.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
<118>2020-08-18T22:38:51.924012+10:00 firewall.xxxx lighttpd 79007 - - xxxx firewall.xxxx - [18/Aug/2020:22:38:51 +1000] "GET /widgets/api/get.php?load=system%2Ctraffic%2Ctemperature%2Cgateway%2Cinterfaces&_=1597753466134 HTTP/1.1" 200 8671 "http://firewall.xxxx/index.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
<118>2020-08-18T22:38:59.269693+10:00 firewall.xxxx lighttpd 79007 - - xxxx firewall.xxxx - [18/Aug/2020:22:38:59 +1000] "GET /widgets/api/get.php?load=system%2Ctraffic%2Ctemperature%2Cgateway%2Cinterfaces&_=1597753466135 HTTP/1.1" 200 8670 "http://firewall.xxxx/index.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"

When the temperature widget API does a grep for "temperature", it's picking up all these lines as well as the correct temperature values. When the widget tries to update the progress bars, it starts looking for elements with weird names and JQuery spits the dummy. Hence, this error:

Code Select Expand

Syntax error, unrecognized expression: #thermal_sensors_widget_<118>2020-08-18T22

I have no idea why kern.msgbuf is there or if/why it's different to what it used to be. But that's definitely the issue (for me, at least). I would suggest tightening the grep expression to exclude the log lines and just return the values we're actually looking for.

I've never created a PR for an open source project before, so I thought I'd give it a crack (even for a single character change  ;)).

https://github.com/opnsense/core/pull/4300

Oh. Don't know why I didn't think of it earlier, but decided to turn the console (browser) on. There's this:

Code Select Expand

Error: Syntax error, unrecognized expression: #thermal_sensors_widget_<118>2020-08-18T22
    at Function.se.error (jquery-3.5.1.min.js:2)
    at se.tokenize (jquery-3.5.1.min.js:2)
    at se.select (jquery-3.5.1.min.js:2)
    at Function.se [as find] (jquery-3.5.1.min.js:2)
    at S.fn.init.find (jquery-3.5.1.min.js:2)
    at <anonymous>:19:23
    at Array.map (<anonymous>)
    at thermal_sensors_widget_update (<anonymous>:6:14)
    at index.php:1351
    at Array.map (<anonymous>)
    at Object.<anonymous> (index.php:1348)
    at c (jquery-3.5.1.min.js:2)
    at Object.fireWith [as resolveWith] (jquery-3.5.1.min.js:2)
    at l (jquery-3.5.1.min.js:2)
    at XMLHttpRequest.<anonymous> (jquery-3.5.1.min.js:2)

@nigelw - Yours looks correct, but you are not seeing any temperatures in the widget?

Widget just shows the header.  :(

Yes, so the grep is seeing the 'temperature' in the junk the sysctl appears to ouput. Can you do this, only if you are having problems with CPU temp:

# /sbin/sysctl -a  > /tmp/sysctrl_output.txt and then post the resultant text file here. It'll be interesting to see what's going on. Also give make model of hardware and amount of ram etc.

sysctrl output attached. Have also attached response from /widgets/api/get.php?load=temperature (not sure if that's helpful at all).

System is: PC Engines APU2 AMD GX-412TC SOC 4GB

try

# /sbin/sysctl -a | grep temperature:

Code Select Expand

# /sbin/sysctl -a | grep temperature:
dev.cpu.3.temperature: 53.2C
dev.cpu.2.temperature: 53.2C
dev.cpu.1.temperature: 53.2C
dev.cpu.0.temperature: 53.2C

A little confused. Why is a BIOS reset required to get the thermal data showing again after the 20.7 upgrade?

I'm not even sure how I perform a factory reset on my box (PCEngine APU2).  ???

Made my donation to the project. You're doing a great job. Thank you.

I remember having a number of issues when I set it up, but I have Google backups working successfully now. For a "not found" error, it sounds like it might be an issue with your Folder ID setting perhaps?

I'm seeing this too and haven't run across a fix yet.

Possibly bug #3 referenced in Current list of bugs/issues I've encountered in 20.7.

Also ref: https://github.com/opnsense/core/issues/4272