Crash when reassigning a wireless interface

[mvglasow]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

A clear and concise description of what the bug is, including last known working version (if any).

Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)

When attempting to change an interface assignment from a wireless interface (one out if two on the same adapter) to a bridge, OPNsense stopped responding. When I checked the console, I found it in the middle of the boot cycle; it came up with the old config (wireless interface assigned, not bridge).

To Reproduce

Steps to reproduce the behavior:

1. Use a PC Engines board with the Atheros wifi chip. (Not sure if hardware matters.)
2. Configure two wifis on the chip, both with WPA2 PSK. (I had a crash when setting up the second or third wifi on the chip and was only able to configure it by installing a doctored config file, but that was 2–3 years ago and I no longer remember all of the circumstances.)
3. Create an interface assignment for both wifis.
4. Create a bridge interface.
5. Modify the assignment for the second wifi (ath0_wlan1), replacing it with the bridge.
6. Observe the crash.

Expected behavior

Obviously, nothing crashes. After changing the assignment, the optX interface points to the bridgeX rather then ath0_wlan1.

Describe alternatives you considered

Export config, doctor the file with a text editor and restore it.

Screenshots

None.

Relevant log files

Not available as the system runs off a SD card, log files are in a memory filesystem (presumably to reduce wear on the SD card) and lost on reboot.

Additional context

As I remember having problems setting up additional wifis as well, but was able to work around the issue by restoring a doctored config file, the issue seems to happen while generating the config file, not in parsing it and applying the settings in it. It somehow seems related to configuring multiple wifis off a single adapter.

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 24.7.3_1-amd64
PC Engines mainboard with Atheros wifi chip

[fichtner]

If it’s a panic provide a panic, otherwise provide what the crash is. Since wireless is flaky in FreeBSD the former issue probably goes nowhere as witnessed by other issues raised here and in their bug tracker.

[mvglasow]

Would I find any post-crash information on the system after it comes back up? If so, I can see if it’s there and provide it. Otherwise, it might be difficult as it’s a production system on which I don’t want to provoke crashes, and I don’t have a test system.

However, after installing a manually edited config file with the desired config, the system comes up fine. Therefore I suspect the issue is somewhere in OPNsense, when generating the new config file, not when applying its settings (if the latter were the case, I would expect the doctored config file to crash the system again on every boot).

[fichtner]

Simply put does it reboot when doing this? If yes it’s a kernel panic and without a swap partition you cannot record the crash. You can observe it in a console but getting g reliable information from a video/photo is not feasible either as it just textdumps and continues.

Also if this happens the issue is in the kernel. Userland like OPNsense core should not be able to panic a system. It happens but rarely for OPNsense reasons (and crashing being bad practice of a kernel anyway).

Cheers,
Franco

[mvglasow]

Yes, it reboots, so this is probably a kernel panic. I can try and capture it on the serial console if that helps (just had to rebuild the box, if I do anything that might cause another crash, I’ll do that while connected to the console).

The issue is that I am getting crashes even when I just try to change the IP config on that interface. Does that change even involve the driver?

Admittedly, I am no expert on network stacks. With the limited knowledge I have, I would expect changes to SSID, WPA keys etc. to be handled by the wireless driver, whereas IP config changes happen a layer higher. If this is the case, then a workaround would be to push changes to the L2 driver only if the new settings which are relevant for L2 actually differ from the current ones. If it’s just the IP address that has changed, leave L2 alone. It’s not really the fault of OPNsense, but if the OS is that flaky in this respect and unlikely to improve, it’s probably the only way. Would this be feasible?

PS/OT: the aim of the changes I am currently making is precisely to replace the internal wifi with a dedicated AP on a trunk line – but that means messing with the wifi one last time.