Open mvglasow opened 1 month 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.
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).
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
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.
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:
ath0_wlan1
), replacing it with the bridge.Expected behavior
Obviously, nothing crashes. After changing the assignment, the
optX
interface points to thebridgeX
rather thenath0_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