Messages

Resize the widget, it should appear if you widen the widget

Can confirm. I can see the speed column after widening the widget.

It's just that before 26.7.2, resizing the widget was not required to see the interface speed.

After updating to OPNsense 26.7.2 I noticed the Interface section in the Dashboard no longer shows the interface's speed and duplex (e.g. 1000base-T <full-duplex>).

In fact, when I loaded the Dashboard page, the interface speed (and duplex) can be seen for a very brief moment then disappears.

Previously on 26.7.1_1 and before the interface speed is correctly displayed on the Dashboard. This is making diagnosing network speed issues harder, such as a cable being connected unreliably that it's only operating at 100base-T capping transmit speed at 10MB/s.

I wonder if this is a bug or an intended change. The Interface -> Overview section doesn't have a column for showing network speed and duplex, either.

EDIT: I just looked at the changelog of 26.7.2 and could not find anything explicitly related to the display of interface speed and duplex on the dashboard.

As of commit 4912a67 WLAN appears to work again.
On a freshly-updated 26.1, apply the following two patches in order.

# opnsense-patch 45597a9
# opnsense-patch 4912a67

After reboot WLAN interfaces should be configured.
Haven't checked other possible issues regarding WLAN yet, as right now I've a lot of other things to do for 26.1, like migrating old firewall rules.

Same here on PC Engines APU2C4 and wle200nx card (Atheros AR9280).
The upgrade log is available at the following link, in case it is helpful:
https://paste.debian.net/hidden/22cde1ad

Thanks.

I just checked your upgrade log. It appears you have the same issue I encountered. On line 2285, "ath0: only 1 sta vap supported".

However, looks like you have two Atheros adapter installed. The other one (ath1) is not reporting that message, but neither is working.

Can you check if you have a "wlan0" (and "wlan1" in your case for your second adapter) interface with OPNsense 26.1? You can use "ifconfig" from console but Interfaces -> Overview will also work. From my experience, those interfaces would be in a red "no carrier" state.

Would somebody check the logs for command errors? I have the feeling most reports around the last weeks omit obvious log entries in their installations.


Cheers,
Franco

I'm not seeing anything out of ordinary from that upgrade log, other than the line regarding "only 1 sta vap supported" which happened after finishing update from 25.7 to 26.1.

From my experience, that error message seems to be what was preventing OPNsense Web UI from adding new devices in Interface -> Wireless -> Devices. As soon as I tried adding a new device there and failed with error, I get that message printed on the console.

Still, I wonder what might be responsible for the creation of interfaces "wlan0" (without the ath0 prefix) that I saw with "ifconfig" or Interfaces -> Overview.

Hello,
After updating to 26.1, the wifi interfaces are still broken and impossible to recreate them (Firefox and EDGE)

Can confirm this issue with my firewall device as well. I'm also using an Atheros Wi-Fi adapter just like OP.

As the AP on my OPNsense device is not being used often, I only noticed this when I found the ISC DHCPv6 Server is not bringing up after upgrading to 26.1, and when checking the logs I noticed the cause for DHCPv6 startup failure was that my Wi-Fi interface has disappeared.

After further inspection, it seems Wi-Fi functionality is in a mess with 26.1 at the moment. I've seen the following inconsistencies on my device:
- In Interfaces -> Overview, instead of "ath0_wlan1" as I previously configured, I get a "wlan0" interface that's in "no carrier" state. However, it correctly shows the info of my Wi-Fi adapter.
- Moving the interface assignment to this "wlan0" will not activate it. Also, if you reboot while configured this way, on next boot the firewall will no longer recognize your current interface configuration and will ask you to reconfigure all interfaces (LAN, WAN, etc.). This means this "wlan0" is created at a much later point during system startup.
- If you were asked to reconfigure your interfaces, trying to assign your WLAN interface to "ath0" (which is how the Wi-Fi adapter appears in the interface list, although its MAC address appears as 00:00:00:00:00:00) will assign it to "ath0_wlan0". However, that interface is not being shown in Interaces -> Wireless -> Devices section, and only appears as a "wireless clone" in Interfaces -> Assignments.
- It's no longer possible to add devices in Interfaces -> Wireless -> Devices section. Trying to add one will fail with this error: "Error creating interface with mode Infrastructure (BSS). The ath0 interface may not support creating more clones with the selected mode." Additionally, I get this message printed in the console, "ath0: only 1 sta vap supported".
- I can only configure the Wi-Fi interface as "Infrastructure (BSS)" mode rather than "Access Point" mode. While the option to set it as "Access Point" mode is available to me initially (Interfaces -> OPTx (the Wireless interface) -> Network-specific wireless configuration -> Mode), after setting up the parameters and applying changes, the mode automatically became "Infrastructure (BSS)" and it is the only option available.

As I cannot get the Wi-Fi adapter configured to work as it used to with 26.1 I've reverted my device back to 25.7 via snapshot. My Atheros Wi-Fi adapter works as expected in that version.

Off-topic FYI: The option 13 in OPNsense console (to restore backup) is not the same as System -> Snapshots.

I just did some packet capture and found the upstream DHCPv6 server was indeed advertising /62 for some reasons not explained even when looking at the capture in high detail, although OPNsense was requesting whatever prefix I asked (/61 in this case).

After some further inspection on the OpenWrt side of I noticed that the specific port I dedicated for OPNsense had the same MAC address as the rest of the LAN ports, even though I separated that port from the default bridge (br-lan) which combined LAN ports and Wi-Fi as a single interface.

This router actually uses DSA to configure individual LAN/WAN ports instead of VLAN which was the old usual way that's still used in a good amount of devices. I then altered the MAC address of that port to a slightly different one from others just in case. However, this kind of broke the connectivity due to ARP still remembering the old address so I had to disconnect the cable and reboot both sides to make them forget.

Even so, OpenWrt still advertised /62 to OPNsense so the ports having the same MAC address was not the real cause of the issue. OpenWrt's firewall appeared to have handled the zones correctly so even with ports having the same MAC address -- the OPNsense port was correctly isolated from the rest of the router LAN ports.

I ended up changing the configuration like this:
- Make the rest of the router (br-lan) get a /64 (which is enough as the router itself needs only a single subnet).
- Make the OPNsense port get a /61.

And to my surprise, OpenWrt finally advertised /61 to OPNsense and everything's working as expected for the time being. I'll continue monitoring the status on my devices just to be sure it'll stay this way even after some maintenance, like system/FW updates once in a while.

On the OpenWrt side I can assign the whole /60 to a single interface or dividing the prefix into two /61s. All I need to do is choose IPv6 prefix assignment length there.

In the former case OPNsense can claim the whole /60 (or /61), but not the whole /61 in the latter case (instead it gets /62). The interfaces on OpenWrt also have their own IPv6 addresses and this does not interfere with prefix delegation. Choosing to "request IPv6 prefix only" on OPNsense side makes no difference, either.

Will see if I can install or configure some utilities on OPNsense to conduct a packet capture and have a look at the DHCPv6 interactions between OPNsense WAN and OpenWrt.

The original post I made was here while OPNsense was still 23.1. As 23.1 entered legacy and my device is currently running 23.7 I decided not to bump that thread and made some edits there instead while I continued the experiment.

Context: Quite a while ago I was struggling to get my OPNsense device to get a /61 IPv6 prefix so I could let all 6 individual LAN interfaces on the device track WAN for IPv6. Originally I thought I had solved the problem with IPv6 prefix allocation, however, turned out I was wrong.

The OPNsense device is connected to an OpenWrt router which connects to the ISP router (providing a /60 prefix). Ideally I'd like to evenly split the ISP-provided prefix (that would be /61 each) for both OpenWrt LAN and OPNsense WAN (which connects to a dedicated port on the OpenWrt router configured to be isolated from the rest). As I currently have 6 individual LAN interfaces on my OPNsense device, to enable IPv6 on all of them I need at least /61.

Originally I split the prefix on the OpenWrt side into two /61 (one for the rest of OpenWrt router LAN/WiFi, the other for OPNsense WAN). However, in this way, no matter how hard I try OPNsense WAN can only get a /62 prefix, which means I can only enable IPv6 on 4 out of 6 LAN interfaces on the OPNsense side.

When I allocated the entire /60 (from ISP router) to the interface dedicated to OPNsense WAN on my OpenWrt router, however, OPNsense can obtain the entire /60 on WAN after a reset (release DHCPv6, reboot without renewing/reloading). I can also set it to obtain just /61 under this circumstance, but this means the rest of the OpenWrt router (LAN/WiFi) will not have proper IPv6 capability so it's still not the most ideal scenario.

In the end, my problem turned out to be still not fully solved. Is there any way to diagnose DHCPv6 on OPNsense so I can find out why the device is only getting a /62 instead of /61 as I expected?

> All directly connected ethernet like interfaces must use /64 in IPv6.

I'm aware. All interfaces on the device, including WAN itself (which connects directly to the specific port on my OpenWrt router), have a /64 address for its own usage.

The problem is the prefix delegation. I don't know if it's even possible to let the WAN interface claim the entire /61 block I assigned on the OpenWrt side (which is half of the /60 given by the ISP), so I could then get eight /64 ranges.

So far I can only make the OPNsense device's WAN get a /62 prefix range which means I have only four /64 ranges. Attempts to let it get a /61 prefix have so far failed. As such, I can only enable IPv6 on four of all my interfaces (which track against WAN).

(PS: I've six LAN interfaces on the OPNsense device, which consists of five ethernet ports and one wireless adapter in AP mode. Each LAN interface has its own subnet, and I've necessary firewall rules to manage cross-subnet accesses.)

Not to mention the Track Interface function is rather fragile. If something happens on the WAN side or the upstream (OpenWrt side), dhcpd6 would go down and requires a manual reload of WAN before I could bring up dhcpd6 again (in order to restore IPv6 connectivity).

[LATE EDIT:]

I only started using OPNsense recently, and I'm having some IPv6 related questions...

1. The maximum possible prefix problem
My OPNsense device is connected to another OpenWrt-powered router that is connected directly to internet, with an IPv4 address and a /60 IPv6 prefix given. On the OpenWrt side I've configured the port on which the OPNsense device is connected as a separate, isolated interface, and gave both the port for OPNsense and the rest of the LAN each a /61 prefix.

However, on OPNsense side I can only at best configure the interface that would be used as WAN to get a /62 prefix when configured this way. Trying to let it get the whole /61 prefix was not successful. I wonder if it's even possible to hand over the entire prefix to a single device per respective IPv6 specifications...

My IPv6 addresses and prefixes are dynamic, so there's no way I could use static configurations...

2. Problems with dhcpd6 and Track Interface
I've made 4 of my 6 LAN interfaces of the OPNsense device set to Track Interface against WAN (since I can only make WAN get a /62).

However, it seems with this configuration, dhcpd6 would go down whenever something wrong happens on the upstream router or the WAN side of the OPNsense device (usually due to a change to the dynamic IPv6 addresses and prefixes), and I cannot bring it back up without doing a manual reload of WAN interface.

Although the loss of IPv6 connectivity does not completely disable my systems from accessing the Internet, it can affect stability to some extent, as in my place, IPv6 is more stable than IPv4. I wonder if it's possible to make a trigger that whenever dhcpd6 goes down (or fails to start), force WAN to reload (preferrably only the IPv6 address), and repeat this once in a while until dhcpd6 is brought back up successfully, so the issue can be handled all by itself.

LATE EDIT: I'm updating my OPNsense device's system software as time goes. It's currently running 23.7 but so far everything remained the same as when I was writing this thread. To avoid bumping this thread (as 23.1 is now EOL) I'm editing this directly and will be starting a new thread on the 23.7 forum for more questions.

The 1st question (regarding maximum prefix) may not be valid as I noticed something odd when I tinkered the settings on the OpenWrt side, that I've now given the entire /60 to the interface connecting to the OPNsense device (the rest of the LAN on the OpenWrt side will no longer have IPv6 as a result).

I then tried modifying the OPNsense device to let it get /61 and set the interfaces that previously had its IPv6 turned off to Track Interface, but it did not work -- The WAN is still getting /62, even after rebooting both this device and the upstream OpenWrt router several times, as well as releasing/reloading/renewing the WAN DHCP several times. Eventually, I released the WAN DHCP, rebooted OPNsence without renewing (so that WAN was still down), and now it finally gets a /61 as desired, and all my interfaces can obtain IPv6.

Maybe it was always possible to let my device get /61 prefix with the upstream OpenWrt IPv6 having either /60 or /61. It was just the lingering memories of the previously delegated /62 prefix that was preventing it when I initially tried changing the setting on the OPNsense side from /62 to /61.

As for the fragile dhcpd6 "Track Interface" issue... it's still there across all the versions. I'm not sure if the "Prevent Release" option would help somehow. I've just turned it on and see how it looks for the next few days. There's no fixed pattern on when and how dhcpd6 would go down -- sometimes everything could be fine for several days, while other times it would not last for even a single hour.

ANOTHER LATE EDIT: I was wrong. While I was able to manage to get /60 or /61 when I allocated the entire /60 on the OpenWrt side, I simply can only get up to /62 when I split the prefix as two /61s. I wonder if there's a way to diagnose why I'm not getting the desired prefix length...