Messages

please let us know at support(at)emergingthreats.net if you have further problems. 

Hi,

My sensor is somehow disabled again? see below:

Code Select Expand

{"sensorId":"--REDACTED--","sensor_status":"DISABLED","last_heartbeat":"2025-01-29T01:07:52+00:00","last_rule_download":"2025-01-28T20:00:07+00:00","event_received":"2025-01-28T21:22:19+00:00","created":"2025-01-23T04:50:15+00:00","disable_date":"2025-04-28T21:22:19+00:00","status":"ok"}
The last event and heartbeat are less than 24 hours ago, yet somehow the sensor is DISABLED again.
Puzzling...

Thanks

Hi all,

After 24.7.12 upgrade, it looks like the ET Pro Telemetry widget shows either empty box or "failed to load widget".

From the CLI, sensor_info.py *sometimes* works, and when it works it takes several seconds to complete, though it reports the sensor is still ACTIVE, while other times the script failed with exception stating remote end closed connection, like below:

--------
  File "/usr/local/lib/python3.11/http/client.py", line 294, in _read_status
    raise RemoteDisconnected("Remote end closed connection without"
http.client.RemoteDisconnected: Remote end closed connection without response
--------

Anyone also seeing this?

Thanks a lot.

---deleted---
3. The disk widget doesn't even show actual space, just a percentage used.
4. The thermal sensors widget, which previously detected thermal sensor names correctly, appears to have buggered up slightly with this update. My PCH temp now detects as a 2nd "Core 0".
5. Overall it feels like a heavy focus on fancy graphs and less of a focus on text, which is fine, but there needs to be an option for people who preferred the old text heavy interface.
---deleted---

Regarding 3, also the disk widget sometimes "changes" to dimension other than the set one. More easily to observe if there are another widgets in the same row adjacent to disk widget and/or directly below it.

In my case,  I set the disk widget to minimum dimension with other widgets to the side and below of it. Works through first several dashboard page reloads, but then the disk widget just grows a unused blank inside it. As result the widget below it is pushed down.

The new dashboard widgets look cool with higher update frequency and graphs, but it really takes more space than the old one.

Hi

That's because the PR hasn't been picked up in any released versions, 24.7_9 increased the number of PHP child processes and timeout so the widget is now loaded.

To get the widget back to display information like it did will need integration of the said PR.

So be patient.  :)

Yeah, glad I am not the only one. My setup does the same to me.

The widget is almost always "fail to load" with about 1 in 20 times showing "-".
While the sensor is active according to sensor_info.py

Code Select Expand

$ /usr/local/opnsense/scripts/etpro_telemetry/sensor_info.py
{"sensorId":"----redacted----","sensor_status":"ACTIVE","last_heartbeat":"2024-07-27T02:28:32+00:00","last_rule_download":"2024-07-26T11:00:24+00:00","event_received":"2023-11-17T01:14:07+00:00","created":"2022-08-10T10:15:08+00:00","status":"ok"}

Update:

First applied the patch from Franco I did a 'configctl webgui restart' and that didn't bring back GUI
Then I went to reply to Franco in this thread.

After that I rebooted opnsense, and this time GUI is working. I rebooted the second time and GUI still works, so hoping it lasts.

Thanks
Ivan.

Looks like the persistence to get this minor issue fixed made the problem worse on 23.1.4. I've written a new patch that should sidestep the underlying issue:

https://github.com/opnsense/core/commit/33ad50456

# opnsense-patch 33ad50456

Please report back if it works or not...


Cheers,
Franco

Having 503 too, but as far as I can see my IPv6 works (PPPoE+IPv6 DHCP on WAN side, stateless DHCPv6 on the LAN side)

the patch, on the other hand, unfortunately does not solve the 503 when webgui is accessed (via LAN IPv4 address, for what it worths)

also no PHP error logs under /tmp.

Thanks,
Ivan.

Unfortunately nope, current NPT6 works for statically assigned prefixes.
If upstream ISP tends to change assignments ever so often it won't work without manual reconfiguration of the NPT6

Though there some attempts to bring this into OPNsense, see https://github.com/opnsense/core/issues/5284

Welcome to voice your use case there

Ivan

The exclusion configuration line works for me, wish I had known or figured out the trick earlier
Now my log finally makes sense again, and SSD's life expectancy is not wasted on these spams
And yes Opnsense team please make it into the next release, even it's just a stopgap rather than fix.

Cheers,
Ivan

Hi there,

I stopped testing this since around 20.7.3, but given there wasn't kernel changes seemingly related to PPPoE nor update to mpd package I would assume the status hasn't changed.

My workaround is to request only prefix. This somehow avoids triggering the issue. And my WAN interface (pppoe0) still gets a global ipv6 (Note this is not in the delegated /64, but an address from ISP's pool) assigned from my ISP.

At this moment I am really tempted give ransom to my ISP and "upgrade" my plan to static ipv6  :-\

Can the element in question be rolled back to what was used in 20.1? Add a watchdog to restart it or make restarting radvd an option in the cron task menu?

Base HardenedBSD is also upgraded to 12 since 20.7 release. This issue might be more than just radvd as discussed over opnsense GitHub. So simply reverting back to old radvd package might not guarantee a solution. But not sure why radvd is used over FreeBSD native rtadvd..

For what it worths, I am restarting radvd via cron every 30 minutes as a stopgap for now

Hi there

This isn't exactly an answer to your situation, but unless you want static assignment or knowledge of how many benign nodes in your network, it will likely make the life easier by going SLAAC ("unmanaged" in your LAN interface setting) or stateless DHCP6, especially when your LAN prefix is forced to change every 24 hours.

My household network is set up similarly, only that I only use DHCP6 to supplement DNS which nodes can also get from Router Advertisement. So far so good until radvd stops responding

radvd is right now a bigger issue in that it mysteriously stops responding to solicitation. There is another thread on this in GitHub

Cheers
Ivan

Hi all,

Have been seeing this after upgraded to 20.7, it happens to my wan ipv6 99.9% of time after reboot

Symptom: WAN does not get ipv6 address, LAN (tracking ipv6 of WAN) seems to get a ipv6 address from ISP's delegated prefix (which I know by looking at GUI interface overview page), however LAN does not publish the prefix in router advertisement (which I know from Wireshark capturing on a host connected to lan)

Weird thing is it almost look like there being some timing issue or race condition at boot to amplify the underlying problem, on the other hand it has higher chance to work if I disconnect WAN side PPPoE, wait couple of seconds then redial when the system is in a rather inactive state. Meaning WAN gets ipv6 assigned from ISP, LAN gets prefix and advertising as expected.

Currently I worked around by just requesting prefix, this gives me more reliable ipv6 after boot without manual intervention.

Btw, for anyone interested my ISP gives out an address via DHCPv6 (Which is via ipv4 PPPoE) and a /64 prefix (different from the DHCPv6 address is under) it had worked until 20.7.

Anyone seeing the same?

Thanks and cheers,
Ivan

Right, functionality wise 20.7 syslog-ng seems doing its job. Albeit the log spamming and seemingly tendency to coredump.

Found several times syslog-ng coredumped at boot (found it before I disable clog) and have to start it manually. Since the direction is moving away from clog I opt to disable it in my 20.7 box too.

By the way I recall seeing Franco saying in another thread that disabling clog makes syslog to be stopped as expected.