search

opnsense / core

OPNsense GUI, API and systems backend
https://opnsense.org/
BSD 2-Clause "Simplified" License
3.33k stars 748 forks source link

Crash when reassigning a wireless interface #8018

Open mvglasow opened 6 days ago

mvglasow commented 6 days ago

Important notices

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

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 commented 6 days ago

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 commented 6 days ago

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 commented 6 days ago

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 commented 6 days ago

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.