Messages

Well, technically I could, I assume.

However, you should consider the following: The OPNsense box is the only machine that I have access to that is capable of testing the RAM. A full memtest would mean a few hours of downtime, essentially leaving me without network for that period of time. On top of that, RAM is very cheap. The spare part cost me less than a case of my favourite beer.  ;)

So yeah, although you can test RAM before exchanging it and just "blindly" replacing it might not have fixed the underlying issue anyway, but there might be good reasons to take the chance and go forward and replace an unchecked part. Best case (my case) is fixing the issue, worst case is spending a few bucks for nothing. Compare that to the "test case" of running patterns over a RAM for hours, having no network whatsoever.  ;)

Seems that it really was the RAM. Replaced it, haven't seen any core dumps since.

RAM is one of the next things to replace, I guess.

What would you expect from a BIOS reset however?

And there come the core dumps again :(

Code Select Expand

pid 93942 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 95393 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 96661 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 2310 (cc), jid 0, uid 0: exited on signal 6 (core dumped)
pid 432 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 17313 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 19572 (cc), jid 0, uid 0: exited on signal 11 (core dumped)
pid 18855 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 21265 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 23996 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 24997 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 25505 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 28272 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 33503 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 35356 (cc), jid 0, uid 0: exited on signal 6 (core dumped)
pid 34514 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 38852 (python3.9), jid 0, uid 0: exited on signal 10 (core dumped)
pid 41862 (python3.9), jid 0, uid 0: exited on signal 10 (core dumped)
pid 43078 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 43889 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
pid 45957 (python3.9), jid 0, uid 0: exited on signal 10 (core dumped)


That kind of sounds familiar.

Do you see core dumps in dmesg?

I just reinstalled from a USB device and so far I'm not seeing the errors any more. Makes me wonder if it really was the disk, but the problem in https://forum.opnsense.org/index.php?topic=35404.0 sounds quite familiar...

I'm seeing it with PHP as well.

UFS? Disk dying?

Yup, UFS. Checked the disk, SMART says everything is OK. No reallocated sectors etc.

I wonder if it might be RAM instead? I mean, still could be the disk though.

Hi everyone,

23.7 seems quite unstable for me. The other day I had to restart unbound and today I see a lot of python3.9 core dumps, after that a kernel panic

Code Select Expand

kernel - - [meta sequenceId="2"] panic: ffs_blkfree_cg: freeing free block
and then a reboot.

I haven't noticed unstable behaviour when being on 23.1.

Any ideas?

Cheers

Frankly, DNS in OPNsense is a mess. It's lacking a lot of control/configurability. For instance, it will create a DNS record for every interface, regardless of you wanting it/it making sense or not. That's why I had to use a random hostname for my box, so that I could create an override record with the actual hostname I wanted to use.

The same is true for the host overrides. If I enter an A record, I want to have an A record in my DNS. Not another PTR.  >:(

I have filed a GitHub issue about the "DNS for every interface" issue, which mostly got ignored.

I'm now looking into alternatives. One could be to install BIND, although I think that's a little overkill. Or I could NOT run my DNS on OPNsense, which sounds even dumber to me.  :-\

Well, I guess I'm the 0.01% then. I have my passwords in a password manager and never changed them. TOTP also worked all the time for me. Only after "resetting" the passwords to their original values (via single user mode), the passwords would work again.

I had the suspicion that the disk might be the culprit. However, the disk looks okay (at least according to S.M.A.R.T.) and I can't find no other evidence of disk issues. I should have checked the passwd file before updating my passwords however.

Regardless, I find this quite suspicious somehow.

¯\_(ツ)_/¯

Hi everyone!

Out of a sudden, my OPNsense won't accept my password+TOTP for my user or the root password any longer. I have done nothing to cause this (except for updating OPNsense itself) and so I'm wondering how this could have happened.

I have checked the RTC, which still was correct, so at least this should be no issue regarding TOTP. However, as root without TOTP doesn't work either, I assume something underlying broke...?

Cheers

I tried the console, with the same result. Then I had a suspicion: my dynamic prefix IPv6 is broken (again), so I disabled IPv6 and it immediately worked!

Hi everyone!

I'm stuck with 20.7.5. Whenever I search for updates, most of the time I get "Timeout while connecting to the selected mirror.". When I click "Check for updates" again, I might get "There are no updates available on the selected mirror." or "The package manager is not responding.".

I have explicitly configured/tried several mirrors, all with the same result.  :(

Internet connection itself doesn't seem to be the issue, as I have no issues connecting to the mirrors (via the diagnostics tools in interfaces).

Cheers

Hi everyone!

I have set "Disable VLAN Hardware Filtering" in the GUI and checked that it's also set in the config.xml. However, all my interfaces have VLAN_HWCSUM set.

I'm investigating my IPv6 checksum issues (https://forum.opnsense.org/index.php?topic=14138) and are digging a bit deeper. That's where I noticed that the VLAN_HWCSUM isn't disabled after all. I don't know if this might be the root cause of the issue, but I just want to disable it to rule out errors.

Any ideas/comments?

Cheers

Hi everyone!

I run my OPNsense behind another router that provides IPv6 and a bunch of /64 prefixes to my local networks. The IPv6 setup as such seems to work just fine (at least I can use things like IPv6 websites from my local networks).

I want to use OpenVPN via IPv6, so I set up everything in the other router and OPNsense to make it work. It somehow works routing-wise as I can see SYN packets from the client and OPNsense replying with SYN-ACK which also arrive on the client. However, the TCP checksum of the packets is not OK and therefore not recognized by the client. I already did a diff of the packets on the OPNsense and the client. Both are the same, so I think I can rule out the other router manipulating packets.

What is interesting is that everything works "internally". I get several prefixes that I use in different networks. Connections from a prefix to the OPNsense OpenVPN port work just fine, so at least it can't be a general checksum calculation issue. I also played around with the offloading flags, but nothing really did help.

Also, everything works just fine in IPv6, it's just the replies to external connections to my OPNsense WAN port that get messed up. Also, connections initiated from OPNsense on WAN to the client work just fine. It's just the SYN-ACK replies from WAN which get the wrong checksums.

Any hints and ideas are highly appreciated

Cheers
  Bebef