Messages

Looks like my modem needed a reboot.  IPv6 gateway is back.  Closing.

Ok, I just noticed the IPv6 gateway is down.  Switched on "Settings->General->Prefer IPv4 over IPv6" and the updates completed successfully.

Is there a known issue with DHCPv6?  I've been away for a few weeks.

Hi all,

I'm trying to upgrade 26.7.7 to 26.7.8_2 and the base package is failing with:

Code Select Expand

***GOT REQUEST TO UPDATE***
Currently running OPNsense 26.7.8_2 (amd64) at Sun Nov  8 16:47:57 EST 2026
Updating OPNsense repository catalogue...
Waiting for another process to update repository OPNsense
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (177 candidates): .......... done
Processing candidates (177 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: .......... done
Nothing to do.
Nothing to do.
Flushing temporary package files... done
Starting web GUI...done.
Fetching base-26.7.8-amd64.txz: ................................[fetch: transfer timed out
fetch: /var/cache/opnsense-update/51236/base-26.7.8-amd64.txz.sig appears to be truncated: 0/1332 bytes] failed, no signature found
***DONE***

I tried with two mirrors so far, official and LeaseWeb US in Washington, DC.  The other packages updated fine and the running OPNsense version is already bumped to 26.7.8_2, but the base and kernel package updates are outstanding.

Maybe my question could be misinterpreted as lack of appreciation so I want to clarify that is not the case.  I thought you were implying an older version as your starting point and maybe had a typo.  That's all.

I agree, smooth bi-weekly updates are much appreciated and not to be taken for granted :)

Did you really mean to write 26.7.5?  That's only a couple weeks old.

Why do the regular USB ports remain functional when the CMOS battery gets low but only the serial console port stops working?

I think that even if the FTDI chip doesn't directly use the battery, something else related to the COM port clearly depends on it.

I didn't consider USB controllers being active and keeping the battery hot.  In that case, I'm not suprised- I keep a UPS and an external fan plugged into it as well.

There's no RS-232 serial port on the Protectli.  It has a USB-C port labeled "COM" which is internally wired to the FTDI UART and can only be used for that purpose:

https://kb.protectli.com/kb/v1000-hardware-overview/

They supply a USB cable with the unit.

Would it be an option to have something like this : https://www.aten.com/global/en/products/usb-solutions/converters/uc232a/
Attached 24/7 to it as the backup of the onboard Serial Console ?!

No RS-232 port :-/

Just a USB-C interface to an FTDI chip.

Can now confirm: the serial console comes up again immediately after battery change.  I'm left with some thoughts about this after having experienced it twice on two different units (same model):

1) The CR1220 battery that it uses is quite small relative to the typical CMOS batteries e.g. CR2025/2032.  It has only <40 mAh capacity, whereas the other types have 160-225+.

2) I think the embedded USB/serial converter must be powered from it as it's the first thing to go.

I think I'm comfortable to say that if you own one of these you should keep a spare battery and best to replace it annually, regardless.  Don't keep the USB serial cable connected to the port 24/7 like I do because even if the terminal session is closed the chip is apparently still active.

I waited for a new battery to arrive but it's still dead, will send it to them tomorrow.

Hope you had some resolution on this.

Incidentally, mine is now again failing to enumerate the USB serial console on the admin PC (currently a Linux box).

You cannot view this attachment.

In 'dmesg' there's some USB related error:

Code Select Expand

[  158.544011] usb 1-1: new full-speed USB device number 12 using xhci_hcd
[  158.748063] usb 1-1: device descriptor read/64, error -71
[  159.032069] usb 1-1: device descriptor read/64, error -71
[  159.313023] usb 1-1: new full-speed USB device number 13 using xhci_hcd
[  159.517076] usb 1-1: device descriptor read/64, error -71
[  159.800081] usb 1-1: device descriptor read/64, error -71
[  159.905782] usb usb1-port1: attempt power cycle
[  160.354040] usb 1-1: new full-speed USB device number 14 using xhci_hcd
[  160.380898] usb 1-1: Device not responding to setup address.
[  160.616897] usb 1-1: Device not responding to setup address.
[  160.822041] usb 1-1: device not accepting address 14, error -71
[  160.822140] usb 1-1: WARN: invalid context state for evaluate context command.
[  161.001048] usb 1-1: new full-speed USB device number 15 using xhci_hcd
[  161.027898] usb 1-1: Device not responding to setup address.
[  161.264898] usb 1-1: Device not responding to setup address.
[  161.470051] usb 1-1: device not accepting address 15, error -71
[  161.470150] usb 1-1: WARN: invalid context state for evaluate context command.
[  161.473864] usb usb1-port1: unable to enumerate USB device

On the OPNsense side, 'dmesg' shows that the console is up.  The 'FCR is broken' part was always there, so ignoring that.

Code Select Expand

[1] uart: ns8250: UART FCR is broken (0x1)
[1] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
[1] uart0: console (115200,n,8,1)

Anything else I can check in OPNsense?  The serial console is already enabled and set as primary in admin settings.  Haven't changed anything there.

I hope it's just the battery again and ordered a couple to try.

lol, shots fired :)

Here is: https://github.com/opnsense/core/issues/10892

Where oh where have my auto rules gone... where oh where can they be? :)

You cannot view this attachment.


(Kidding aside, thanks for another great update.  I'm loving the advanced mode markers.)

as my emmc is dead and I'm barely within warranty I might still send it to them

did you try updating the NIC's firmware with the newer build?

I kept the NIC firmware as-is and honestly now with OPNsense 26.7.x I feel even less of a reason to change it.  Things seem to be behaving.

If they're going to ship you a new one anyway you might as well ask them if they can update it.

BTW, you probably saw my note above about setting the date manually in FreeBSD the first time you boot after a battery change / CMOS reset.  Coreboot doesn't let you set the system time unfortunately so until you do it in the OS you'll have problems getting NTP to sync.  FYI.

I agree w/ Nullman, these things do seem to go through batteries faster than the typical PC/laptops I'm used to.  However, I think the first production units (the "v1" if you will) did have some issue.

Hi @cottec,

Not sure what's going on with yours specifically but the COM issue sounds familiar.  I have a newer production run of the V1410 now and these issues haven't come back.  I would reach out to Protectli support.

You might be able to get COM port responding again with a CMOS reset: https://kb.protectli.com/kb/cmos-reset/.  I remember this working for me.

Replace the battery first if you can, and make sure you are on the latest firmware.