Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wireless issues - WLE200NX (Atheros AR9280) - no 5Ghz option #5765

Closed
adamast0r opened this issue May 11, 2022 · 17 comments
Closed

Wireless issues - WLE200NX (Atheros AR9280) - no 5Ghz option #5765

adamast0r opened this issue May 11, 2022 · 17 comments
Assignees
Labels
bug Production bug
Milestone

Comments

@adamast0r
Copy link

adamast0r commented May 11, 2022

Describe the bug

When using a very supported wireless card (WLE200NX (Atheros AR9280) in AP mode I cannot select 802.11NA to allow channel 36 in 5Ghz.

To Reproduce

Steps to reproduce the behavior:

  1. Interfaces: Wireless: Devices -> add new device
  2. Interfaces: Assignments -> assign the new wireless device
  3. A new interface is created :
    3.1 in the " Standard" there is only 802.11B, 802.11GN 802.11N
    3.2 In the channel there are only 2.4GHz channels

Expected behavior

The wireless card supports the 802.11NA. I want to select channel 36, no 5GHz channels are there.

root@OPNsense:/ # ifconfig ath0_wlan1 mode 11na
root@OPNsense:/ # ifconfig ath0_wlan1 channel 36:ht/20
root@OPNsense:/ # ifconfig
ath0_wlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
       description: OPT1
       ether 01:01:01:01:01:01
        inet6 ee00::0000:0000:0000:00ee%ath0_wlan1 prefixlen 64 scopeid 0x8
        groups: wlan
        ssid bartolo channel 36 (5180 MHz 11a ht/40+) bssid 00:00:00:00:00:00
        regdomain FCC country US ecm authmode WPA privacy MIXED deftxkey 3
        TKIP 2:128-bit TKIP 3:128-bit txpower 17 mcastrate 6 mgmtrate 6
        scanvalid 60 ampdulimit 64k ampdudensity 8 shortgi -ldpc -uapsd wme
        burst -apbridge dtimperiod 1 -dfs
        parent interface: ath0
        media: IEEE 802.11 Wireless Ethernet autoselect mode 11na <hostap>
        status: running
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

The wireless card works fine after this.

Describe alternatives you considered

I tried to modify the wireless configuration directly to restore a config file where I changed the:
<wireless>
<mode>hostap</mode>
<standard>11na</standard>
....
<channel>36</channel>
</wireless>

However it didn't work, since I don't have any other 5GHz card I also cannot confirm if the config was fully correct for 5Ghz.

By running the following script at boot it seems to work, but not sure how reliable is long term?

/usr/local/etc/rc.syshook.d/start/96-wireless-5GHz-hack

ifconfig ath0_wlan1 down;ifconfig ath0_wlan2 down; ifconfig ath0_wlan3 down;
ifconfig ath0_wlan1 mode 11na; ifconfig ath0_wlan2 mode 11na; ifconfig ath0_wlan3 mode 11na
ifconfig ath0_wlan1 channel 36:ht/20; ifconfig ath0_wlan2 channel 36:ht/20; ifconfig ath0_wlan3 channel 36:ht/20
ifconfig ath0_wlan1 up;ifconfig ath0_wlan2 up; ifconfig ath0_wlan3 up;

in the end this should be fixed in the web interface. If there is other option I am happy to try it.

Screenshots

bug_interface_wireless
Environment

OPNsense OPNsense-22.1.2L (amd64, OpenSSL).
PCengines APU2 with WLE200NX a/b/g/n wireless card - https://www.pcengines.ch/wle200nx.htm

Update 22/06/2022
I can confirm the script works long term however don't try to change wireless configurations in the web interface after running the script.
Just tried to do "wireless" -> "devices" -> "add" and I got an infinite crash loop and had to reinstall :(

Update 26/10/2023
I have updated to opnsense 23.11 and it seems the channel 36:ht/20 config now was crashing, but it seems that 36:ht/40 works fine:

ifconfig ath0_wlan1 channel 36:ht/40; ifconfig ath0_wlan2 channel 36:ht/40; ifconfig ath0_wlan3 channel 36:ht/40

@OPNsense-bot
Copy link

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.

@OPNsense-bot OPNsense-bot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 7, 2022
@OPNsense-bot OPNsense-bot added the help wanted Contributor missing / timeout label Nov 7, 2022
@fichtner fichtner self-assigned this Oct 30, 2023
@fichtner fichtner added bug Production bug and removed help wanted Contributor missing / timeout labels Oct 30, 2023
@fichtner fichtner added this to the 24.1 milestone Oct 30, 2023
@fichtner fichtner reopened this Oct 30, 2023
@fichtner fichtner linked a pull request Oct 30, 2023 that will close this issue
@fichtner
Copy link
Member

@adamast0r how about 23a6d680db instead? I looked at the page and it's a bit unfortunate that it can select a standard and a mismatching channel. I suppose we could prevent that in validation, but for now I've just made it more visible in the channel selection.

@adamast0r
Copy link
Author

adamast0r commented Oct 30, 2023

That looks good, I can confirm it displayed correctly after I patched the interfaces.php file...

I know wireles is probably not a priority on opnsense but since your are improving the code why not allowing the user to submit also the channel width (HT) on that dropbox or by creating other drop box ?

This is the ifconfig command you are extracting the info:

 # ifconfig  ath0_wlan1 list chan
Channel   1 : 2412  MHz 11g ht       Channel  11 : 2462  MHz 11g ht
Channel   2 : 2417  MHz 11g ht       Channel  36 : 5180  MHz 11a ht
Channel   3 : 2422  MHz 11g ht       Channel  40 : 5200  MHz 11a ht
Channel   4 : 2427  MHz 11g ht       Channel  44 : 5220  MHz 11a ht
Channel   5 : 2432  MHz 11g ht       Channel  48 : 5240  MHz 11a ht
Channel   6 : 2437  MHz 11g ht       Channel 149 : 5745  MHz 11a ht
Channel   7 : 2442  MHz 11g ht       Channel 153 : 5765  MHz 11a ht
Channel   8 : 2447  MHz 11g ht       Channel 157 : 5785  MHz 11a ht
Channel   9 : 2452  MHz 11g ht       Channel 161 : 5805  MHz 11a ht
Channel  10 : 2457  MHz 11g ht       Channel 165 : 5825* MHz 11a

The channel width could be displayed using the -v flag:

# ifconfig -v ath0_wlan1 list chan
Channel   1 : 2412      MHz 11b          Channel   9 : 2452      MHz 11g
Channel   1 : 2412      MHz 11g          Channel   9 : 2452      MHz 11g ht/20
Channel   1 : 2412      MHz 11g ht/20    Channel   9 : 2452      MHz 11g ht/40-
Channel   1 : 2412      MHz 11g ht/40+   Channel  10 : 2457      MHz 11b
Channel   2 : 2417      MHz 11b          Channel  10 : 2457      MHz 11g
Channel   2 : 2417      MHz 11g          Channel  10 : 2457      MHz 11g ht/20
Channel   2 : 2417      MHz 11g ht/20    Channel  10 : 2457      MHz 11g ht/40-
Channel   2 : 2417      MHz 11g ht/40+   Channel  11 : 2462      MHz 11b
Channel   3 : 2422      MHz 11b          Channel  11 : 2462      MHz 11g
Channel   3 : 2422      MHz 11g          Channel  11 : 2462      MHz 11g ht/20
Channel   3 : 2422      MHz 11g ht/20    Channel  11 : 2462      MHz 11g ht/40-
Channel   3 : 2422      MHz 11g ht/40+   Channel  36 : 5180      MHz 11a
Channel   4 : 2427      MHz 11b          Channel  36 : 5180      MHz 11a ht/20
Channel   4 : 2427      MHz 11g          Channel  36 : 5180      MHz 11a ht/40+
Channel   4 : 2427      MHz 11g ht/20    Channel  40 : 5200      MHz 11a
Channel   4 : 2427      MHz 11g ht/40+   Channel  40 : 5200      MHz 11a ht/20
Channel   5 : 2432      MHz 11b          Channel  40 : 5200      MHz 11a ht/40-
Channel   5 : 2432      MHz 11g          Channel  44 : 5220      MHz 11a
Channel   5 : 2432      MHz 11g ht/20    Channel  44 : 5220      MHz 11a ht/20
Channel   5 : 2432      MHz 11g ht/40+   Channel  44 : 5220      MHz 11a ht/40+
Channel   5 : 2432      MHz 11g ht/40-   Channel  48 : 5240      MHz 11a
Channel   6 : 2437      MHz 11b          Channel  48 : 5240      MHz 11a ht/20
Channel   6 : 2437      MHz 11g          Channel  48 : 5240      MHz 11a ht/40-
Channel   6 : 2437      MHz 11g ht/20    Channel 149 : 5745      MHz 11a
Channel   6 : 2437      MHz 11g ht/40+   Channel 149 : 5745      MHz 11a ht/20
Channel   6 : 2437      MHz 11g ht/40-   Channel 149 : 5745      MHz 11a ht/40+
Channel   7 : 2442      MHz 11b          Channel 153 : 5765      MHz 11a
Channel   7 : 2442      MHz 11g          Channel 153 : 5765      MHz 11a ht/20
Channel   7 : 2442      MHz 11g ht/20    Channel 153 : 5765      MHz 11a ht/40-
Channel   7 : 2442      MHz 11g ht/40+   Channel 157 : 5785      MHz 11a
Channel   7 : 2442      MHz 11g ht/40-   Channel 157 : 5785      MHz 11a ht/20
Channel   8 : 2447      MHz 11b          Channel 157 : 5785      MHz 11a ht/40+
Channel   8 : 2447      MHz 11g          Channel 161 : 5805      MHz 11a
Channel   8 : 2447      MHz 11g ht/20    Channel 161 : 5805      MHz 11a ht/20
Channel   8 : 2447      MHz 11g ht/40-   Channel 161 : 5805      MHz 11a ht/40-
Channel   9 : 2452      MHz 11b          Channel 165 : 5825*     MHz 11a

The options on my specific card seem to be (ht/20, ht/40+, ht/40-), I am currently configuring this with a external bash script:

ifconfig ath0_wlan1 channel 36:ht/40;

@fichtner
Copy link
Member

fichtner commented Oct 31, 2023

@adamast0r that sounds like a plan. my proposal:

  1. merge the current improvement. it doesn't require any additional changes or testing..
  2. work on the channel width addition but I think in this case we should merge the channel, mode and width into a single drop down and remove the old "mode" selection from the GUI. This will be a bit more work, but it will prevent mismatches between mode and channel as you can already do now and adding the width as an extra dropdown will make this much worse.

agreed? If you don't mind can you make a ticket for step 2 with all the info you posted here that would be lovely.

Cheers,
Franco

@adamast0r
Copy link
Author

@fichtner thanks for you work into fixing this problem, that sounds like a good plan. I have created the new ticket for the improvement.

Like I mentioned in the ticket my WLE200NX (Atheros AR9280) crashes with specific channel width configurations (ht/20), what is the best way for reporting/fixing in freeBSD? should I bother to report this upstream or are we moving soon to freeBSD 14 and I it is probably better to wait and see if the same happens there?

@fichtner
Copy link
Member

@adamast0r can you try skimming https://bugs.freebsd.org/bugzilla/ first for similar issues? I'm discussing with FreeBSD when and how to make upstream tickets so we may have to test against a "clean" kernel from their code state (e.g. 13.2-RELEASE) beforehand.

I can also look for patches in the source code if you give me a bit of time. Typically we only try to be up to date with wired drivers but maybe something was already fixed for this one.

@adamast0r
Copy link
Author

adamast0r commented Oct 31, 2023

@fichtner I spend some time already searching for similar bugs but I can't find any that looks similar.

While I was convinced that the bug was related with 5Ghz with ht/20 it already crashed with ht/40 also. The crash happens sometimes when I configure the card:

ifconfig ath0_wlan1 channel 36:ht/40; ifconfig ath0_wlan2 channel 36:ht/40; ifconfig ath0_wlan3 channel 36:ht/40;
ifconfig ath0_wlan1 up;ifconfig ath0_wlan2 up; ifconfig ath0_wlan3 up;

If it does not crash after 5 min it keeps working without any issues., the problem is that it seems there is a high probability it will crash. Of course this might mean that there is a crash boot loop, because it will setup wireless and crash again.

  • The errors I got in the past were: "Fatal trap 12: page fault while in kernel mode", I am happy to gather more recent kernel dumps, does OPNsense store them by default?
  • pfsense 2.4.5 FreeBSD 11.3 worked fine, Pfsense 2.6.0 FreeBSD 12.3 crashed
  • OPNsense 22.1 or versions after - have all crashed

Happy to raise other ticket with these details if it is easier to track...

@fichtner
Copy link
Member

fichtner commented Nov 1, 2023

@adamast0r I looked at what stable/13 branch had to offer and it comes up completely empty in this regard. Not too surprising since we use 13.2 so all that was on stable/13 we already have WRT fixes available. stable/14 and main branches are not too promising either but at least have a bunch of changes to them, but not specific fixes for the issue describe here. It doesn't look like it's being actively worked on at the moment.

@adamast0r
Copy link
Author

adamast0r commented Nov 1, 2023

@fichtner thanks for checking, what would be the next step, openning a new bug with freeBSD regarding this?

@fichtner
Copy link
Member

fichtner commented Nov 2, 2023

What we could do is try a debug kernel first and get a backtrace of the panic. Do you have a textdump available already from a previous crash? I'd briefly look at the code, see if a fix exists in that area and try that out otherwise we'd move to a FreeBSD 13.2 debug kernel and reproduce there to make a report over at FreeBSD.

fichtner added a commit that referenced this issue Nov 2, 2023
(cherry picked from commit 6f6284f)
(cherry picked from commit 6946f27)
@adamast0r
Copy link
Author

adamast0r commented Nov 2, 2023

I am assuming this will be the relevant kernel message you are looking for:

Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address	= 0x0
fault code		= supervisor write data, page not present
instruction pointer	= 0x20:0xffffffff80e1f4b0
stack pointer	        = 0x28:0xfffffe0062c95d40
frame pointer	        = 0x28:0xfffffe0062c95d90
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 12 (irq40: ath0)
trap number		= 12
panic: page fault
cpuid = 2
time = 1698872847
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0062c95b00
vpanic() at vpanic+0x151/frame 0xfffffe0062c95b50
panic() at panic+0x43/frame 0xfffffe0062c95bb0
trap_fatal() at trap_fatal+0x387/frame 0xfffffe0062c95c10
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe0062c95c70
calltrap() at calltrap+0x8/frame 0xfffffe0062c95c70
--- trap 0xc, rip = 0xffffffff80e1f4b0, rsp = 0xfffffe0062c95d40, rbp = 0xfffffe0062c95d90 ---
ieee80211_beacon_update() at ieee80211_beacon_update+0x7f0/frame 0xfffffe0062c95d90
ath_beacon_generate() at ath_beacon_generate+0x46/frame 0xfffffe0062c95de0
ath_beacon_proc() at ath_beacon_proc+0x241/frame 0xfffffe0062c95e30
ath_intr() at ath_intr+0x4b3/frame 0xfffffe0062c95e60
ithread_loop() at ithread_loop+0x25a/frame 0xfffffe0062c95ef0
fork_exit() at fork_exit+0x7e/frame 0xfffffe0062c95f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0062c95f30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

I don't see anything anything else relevant on the textdump but let me know if you need the tar file.

@fichtner
Copy link
Member

fichtner commented Nov 2, 2023

Pretty interesting... the Internet can't find this particular panic... but it gives a number of hints here:

https://github.com/opnsense/src/blob/16d02f7cefda175ea02f0bd675d15aee29bda6bc/sys/dev/ath/if_ath_beacon.c#L722

Both this file and the other end

sys/net80211/ieee80211_output.c:ieee80211_beacon_update(struct ieee80211_node *ni, struct mbuf *m, int mcast)

seem to indicate a passed pointer is NULL and from previous issues/fixes in other drivers you can see that it is most likely the mbuf:

https://svnweb.freebsd.org/base/stable/10/sys/dev/usb/wlan/if_run.c?r1=273636&r2=273635&pathrev=273636

So we could try a simple patch first before making this too complicated.

@adamast0r
Copy link
Author

adamast0r commented Nov 2, 2023

thanks for checking, that last commit fix type looks very plausible to me (without being an expert) to be able to fix the issue. I am happy to test any kernel patches when you have time to supply them.

@adamast0r
Copy link
Author

@fichtner I just noticed that this ticket was closed, should I create a new ticket for that patch related with the atheros wireless driver?

@fichtner
Copy link
Member

#6967 still good and this channel thing was a bug and fixed. 😊

@fichtner
Copy link
Member

Oh sorry you mean for the src.git. Let me give you a test kernel and see what happens tomorrow.

@adamast0r
Copy link
Author

adamast0r commented Nov 26, 2023

@fichtner I created other ticket (opnsense/src#190) only related with the wireless driver crash so it is easy to track the issue, I hope that is not a problem...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Production bug
Development

Successfully merging a pull request may close this issue.

3 participants