Messages

The reason they do that is because that same PCB is used on a completely different system that has no space constraints and classic SATA drive(s) fit perfectly. Qotom does this. They have mini PCs with PCBs that have 2 or more SATA connectors that you cant really use. I mean, you can, if you dont mind your drives dangling on the cables outside the case. And then, they use same PCB on a system that has huge metal case with drive bays where you can even mount full size SATA hard drives. They cut the costs this way.

There is space in the case for the drive, the issue is that the power connector and data connector are so close together they cant be both in at the same time.

TopTon have done a board revision on later revisions, I posted a picture of my board on I think is snbforums and my PCB layout is different to later models where the connectors have been moved apart.  Basically if I forced both cables in it likely would have ripped one of the connectors of the PCB or at least bent it partially off.

If its a complete freeze, its 100% hardware. 

My suggestion put windows on it, use it, let it idle overnight etc, run stress tools, benchmarks etc, try to make it fall over.

I do this will all my new NUC's.

My current N100, I brought with NVME and RAM preinstalled, and it wasnt stable (primary instability was data becoming corrupted on storage silently), however it passed every test I threw at it, so ended up just replacing both NVME and RAM and it has been stable since.  The bios's on these units tend to be of low quality, so I wouldnt use any C-state above 1.

If temps in windows dont look great, then do something about it, bear in mind the thing runs hotter in FreeBSD than Windows.  I have a couple of tiny fans placed on top of my unit blowing down on it, an easy 10-15C gain, I also have a attenuator attached so the RPM is slow enough that they effectively silent.  NVME without this gets extremely hot it basically idles at its limit 70C, and ends up heating everything else inside. (on windows it has an idle state that makes it run cooler, but FreeBSD it idles in full power state)

Ideally use SATA for storage if its possible, in my unit I couldnt as there is no m.SATA and the normal SATA power/data connectors are next to each other making them not possible to use (design flaw on the PCB).

[...]I do feel the decision all those years ago to keep the custom multi threaded PF over keeping up with OpenBSD PF has continued to hunt FreeBSD.[...]

Improving FreeBSD's pf is an obvious goal, but pining for OpenBSD's implementation doesn't seem realistic. Unfortunately any attempts at real improvement would run straight into the politics being discussed here.

Yep, for sure.

Nope, cant volunteer, so basically it sounds like its still not clear if its properly resolved upstream, my view is, if it isnt regression tested, it shouldnt have been committed in the first place, which aligns with the view that Dok posted.

So another broken network path in FreeBSD potentially lasting several years and multi generations of release.  At least OPNsense has backed it out.

I do feel the decision all those years ago to keep the custom multi threaded PF over keeping up with OpenBSD PF has continued to hunt FreeBSD.  This situation is part of that fallout with picking specific patches from OpenBSD in the hope of fixing it on FreeBSD.  A Frankenstein PF.  I did mention this on reddit not that long ago and ironically the guy who responded to me quite angry is the same person making the commit's in that big report.  He really did not like me mentioning that.

I can offer my 5 pence on that long bug report conversation.  I apologise if anyone is offended by it.

First, my view is that the nature of the bug is pretty scary, we have had issues over the years with weird IPv6 behaviours, weird PF issues, which can be very frustrating for people operating misbehaving networks, if it also affected ICMP packet too big stuff, then it is especially nasty, and I think its clear regression testing is inadequate on FreeBSD. 
Second I can see the asks's to back out the original security patch, as a end user I definitely see the logic in the request, but I very rarely see developers back out code, they usually die on that hill.  I agree with dok's comment that the issues the patch was causing are far more serious than a vague low risk security bug. 
Third, I think the idea to use a vanilla FreeBSD kernel on OPNsense to get the bug moving again was sound and should have been done right away after it was suggested.  It doesnt matter if its felt it was wrong, just do it to satisfy all parties for democratic reasons. 
Fourth was some bickering which was not a good luck on anyone. 
Fifth the entire bug report makes FreeBSD look pretty bad in many areas, which its lask of regression testing as well as urgency in getting the issue fixed, even if it means backing out.

Is this still not properly fixed in FreeBSD upstream?

In the UI settings.  Read the docs as suggested above.

ZFS on opnsense already defaults to 90 sec async flush interval to help wear, I agree with the others, use a ram disk when using SSD storage.

Hi, will chime in here.

One thing I always considered a strength of opnsense was its dashboard, and will admit was surprised to read in the changelog when it changed, the "modern" phrase as I already considered it modern.

I updated and now have had a moment to generate some thoughts on it, I will try to be as respectable as possible as I respect the work that will have gone in to it.

I think that you can drag stuff around, resize and such is nice.  I cant remember if you could do all of that on the old dash, but that is nice.

I also like seeing interrupt usage on the cpu graph.

But some of the widgets have regressed on the information they provide.  I will give some examples.

Old dash widgets, you had all memory usage view on the screen, could quickly eye ball it, now have to move mouse over a half pie chart, and get some very limited information. 
Same issue with interface stats, although I think all the info is still there when mouse is in right place, I still have to move the mouse to see it.
The firewall widget, I am not sure is working, previously I would see live log entries flow in the widget box, now if I hover over it is just a number 1, and if I click it, then takes me to firewall log.
Disk usage widget used to show partition info, now its a generic used and free.

I think the main dash is ok, just I think the widgets need to be able to do what the old widgets did, no lost functionality.

Did ISC reveal the reason they abandoning software that works in favour of something thats incomplete and buggy?

I am guessing they have a new generational of developers who dont want to work on the old code so its the typical solution of rewriting.

Please dont remove ISC DHCP from future builds of opnsense.

I am just giving you an answer which might explain why it sits there for a long time on the installer boot.  I could I guess revert the assignments on the host and see if it speeds things up.

Well your case is a local install, if OPNsense is remote you need to at the very least have some kind of initial WAN access.  Even if its to setup a VPN.

Strange. What sort of WAN are we talking about here?


Cheers,
Franco

In my case its not even WAN as the auto assignment wrongly assigns the port.

OPNsense running in VM, two nic's one for WAN and one for LAN, it assigns the LAN port as WAN, and vice versa and I have to wait quite a while on the live system boot, interestingly the first boot post install is much quicker.

Output when vmstat -m ran manually.

# /usr/local/bin/vnstat -m

vtnet0  /  monthly

        month        rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
       Mar '24      1.23 MiB |    8.28 MiB |    9.50 MiB |   32.96 kbit/s
     ------------------------+-------------+-------------+---------------
     estimated    726.49 MiB |    4.79 GiB |    5.50 GiB |

Code Select Expand

[bf40d3d6-8e4f-4c8e-9815-621df3882190] Script action failed with Command '/usr/local/bin/vnstat -m ' returned non-zero exit status 1. at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/actions/script_output.py", line 44, in execute subprocess.check_call(script_command, env=self.config_environment, shell=True, File "/usr/local/lib/python3.9/subprocess.py", line 373, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '/usr/local/bin/vnstat -m ' returned non-zero exit status 1.

The stats are accumulating.

Thanks, that does work.