Messages

I am curious to see what would be so busy then given that the first debug level shouldn't spew so much data out that it fully utilizes a CPU.

Same original boot problem when linked on ax1 after a reinstallation?

Hi,

I took the liberty of testing with an older DEC850 model (same platform, 8 instead of 4 cores). Since I had both the FS 10GSR-85 and the FS 10G-T lying around, plugged these in as well but can't seem to reproduce your issue.

It can be helpful to set both dev.ax.0.axgbe_debug_level and dev.ax.1.axgbe_debug_level to "1" in system -> settings -> tunables, and reboot. This will produce a lot of noise over serial so make sure you can access via ssh to reset these tunables by hand (# sysctl dev.ax.0|1.axgbe_debug_level=0) or make sure you're able to access the GUI to reset the tunables there.

Instead of directly fetching from the serial console you can also pipe "# dmesg" into a file, but make sure it has the ---<<BOOT>>--- in there.

Possibly unrelated, but is one of the ax ports configured for DHCP as a client?

> I would assume there's no way to treat users and vouchers differently. Is that correct?

No, this would have to apply to a different zone.

I'm not sure if you're on the community or business edition, but 26.1.8 just dropped with some Captive Portal improvements. Your issue specifically doesn't ring a bell, but best to stay on the latest version before chasing ghosts.

Be sure to restart the portal or manually reboot after the upgrade as mentioned in the release notes.

Hi,

Just wondering.. If you run the following command:

Code Select Expand

sqlite3 -header -column /var/captiveportal/captiveportal.sqlite "
SELECT 'session_info' AS table_name, zoneid, sessionid, COUNT(*) AS count
FROM session_info
GROUP BY zoneid, sessionid
HAVING COUNT(*) > 1;

SELECT 'session_restrictions' AS table_name, zoneid, sessionid, COUNT(*) AS count
FROM session_restrictions
GROUP BY zoneid, sessionid
HAVING COUNT(*) > 1;
"
Does this produce any output?

Regarding your side question, the options allow for either having concurrent users (across multiple MACs), or not. If you don't allow them, previous sessions will automatically be killed. You can split this functionality up by splitting into zones if your architecture allows. However, this shouldn't be relevant for the problem you're seeing, as multiple sessions bound to the same user/MAC should not exist in any case.

Glad you like it :)

Cheers,
Stephan

Hi all,

Work to include IPv6 support for the Captive Portal system has finished, if you'd like to give it a spin:

# opnsense-patch https://github.com/opnsense/core/commit/497ed54fe18c

The patch requires the 26.1.4 or 26.1.5 version and a reboot to take effect.

Some important notes:

- A new checkbox called "roaming" has been added and is enabled by default. This option allows the portal to sync/administrate IPv4/IPv6 client aliases. This option is required for maximum compatibility with IPv6, since multiple IPs are more common for IPv6.

- Hostwatch (Interfaces: Neighbors: Automatic Discovery) must be enabled for the administration of IPv6 addresses, as the output of NDP can be rather slow in some setups.

- A hostname must be configured for each zone wanting to do IPv6 (a certificate isn't required). Where IPv4 zone networks are usually static, IPv6 may be tracked through Identity Association or other means, in which case the portal cannot reliably guess which IPv6 address should be used for redirection. Instead, this is delegated to DNS. This also means that the proper DNS records must be available. For any default setup using Unbound, these can be synthesized with the DNS64 option in Services: Unbound DNS: General.

- The primary IP used by the client to log in to the portal will be allowed by the firewall as soon as they log in. All other IP addresses associated with this client are synchronized after the fact, meaning there can be a slight delay until these IP addresses are allowed by the firewall.

Thanks in advance if you'd like to test this, and a special mention to Alex Goodkind for his initial work and helpful testing.

Cheers,
Stephan

Hi,

I seem to have missed that regex was allowed in the old page. https://github.com/opnsense/core/commit/41664263de3f4fe211d0e7af9d0a471c300ceb21 Should address this.

# opnsense-patch 4166426

Cheers,
Stephan

However, if I resolve subdomains like 'www.facebook.com' these are not blocked:

The blocklists will consider a domain as a wildcard if the domain starts with "*." in the downloaded list. In all other cases it does an exact match.

Hi there,

Do you have a complete Unbound log snippet before & after the 13:31pm failure? What is the size of the /var/unbound/data/unbound.duckdb file around the time of the failure & after? Any clients in the network doing suspicious amounts of DNS requests around the time of the failure (should show as a pretty big spike in the reporting section)? Enough free disk space left of the device?

Cheers,
Stephan

For what it's worth, these pages have also been fixed through https://github.com/opnsense/core/commit/adc58c39511dda6429aa8d565cef924a93fc326f and https://github.com/opnsense/core/commit/cb31d64ab356d3cd82ee6941e10b95c5733d28ff respectively

Hi Toon,

This does indeed look suspicious. Perhaps it's best if you open a ticket on GitHub (https://github.com/opnsense/core/issues) with the relevant details you provided so we can track it more accurately.

Cheers,
Stephan

From the console, can you share the output of "# pfctl -vs ether -a captiveportal_zone_0" when your client is connected? (sanitize IPs as needed)

Well let me know if the issue persists on 25.7, and if so, how you tested it. Setting the idle timeout to 1 minute and leaving a ping running on the client should show quick enough if there is a problem.

For context, I tested on 25.7 but nothing has changed on the Captive Portal side between these two versions.

> There was a section where I had entered 10000 Mbp/s because there was no limit on the number of Mbp/s, and I had to retype this as 40000 Mbp/s or 4 Gbp/s, or use the command revert

Validations were added to the GUI to prevent entries above 4Gbps a long time ago, perhaps this configuration was from before this validation was added, and now crashes due to the backend service change.

Before this patch the shaping was fully handled by IPFW, so if it broke there, traffic would likely still pass through pf. However, since pf now handles this and crashes on the pipe configuration it's reasonable to assume this would lock up traffic as well. However, since it's an incorrect configuration in both scenarios the right thing to do is to ditch the 10Gbps pipes.