I suppose this should be used in addition to the other command but it seems the path doesn't exist? I realize the path for the other command doesn't exist either. Do these commands really work then?
They are for the WRT3200 using the 20.02 series of FW. /sys/module are the loaded modules in kernel.
Hi all,
after meshing two MIR4A routers, I'm seeing the following kernel trace on boot:
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.288365] ------------[ cut here ]------------
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.293068] WARNING: CPU: 0 PID: 720 at net/core/flow_dissector.c:960 __skb_flow_dissect+0x3b0/0x16bc
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.302339] Modules linked in: pppoe ppp_async iptable_nat xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conn
track mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 iptable_mangle iptable_filter ipt_REJECT ip_tables cfg80211 xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG x_tables slhc nf_reject_ipv4 nf_l
og_ipv4 nf_log_common nf_defrag_ipv4 crc_ccitt compat leds_gpio gpio_button_hotplug
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.347415] CPU: 0 PID: 720 Comm: kworker/u9:1 Not tainted 5.4.132 #0
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.353869] Workqueue: napi_workq napi_workfn
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.358208] Stack : 805d36e4 86d11a3c 80650000 80690000 86cf5c00 805e5644 8040f5d0 00000009
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.366528] 86c63150 872d7218 00000000 8007e048 00000000 00000001 86d119f8 4dbbc5ed
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.374847] 00000000 00000000 00000000 00000000 716b726f 0000011b 6f775f69 6e666b72
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.383165] 00000000 00000001 00000000 0005664d 00000000 806b0000 00000000 8040f5d0
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.391483] 00000009 86c63150 872d7218 00000000 00000000 8034f84c 00000000 807f0000
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.399801] ...
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.402234] Call Trace:
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.404696] [<8000b64c>] show_stack+0x30/0x100
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.409133] [<8052e958>] dump_stack+0xa4/0xdc
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.413484] [<8002c140>] __warn+0xc0/0x10c
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.417563] [<8002c1e8>] warn_slowpath_fmt+0x5c/0xac
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.422523] [<8040f5d0>] __skb_flow_dissect+0x3b0/0x16bc
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.427826] [<80410b8c>] __skb_get_hash+0x7c/0x258
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.432741] [<86f33184>] ieee80211_unreserve_tid+0x720/0x1890 [mac80211]
Wed Jul 28 11:26:40 2021 kern.warn kernel: [ 25.439699] ---[ end trace 7aaf0e496086288b ]---
This does not happen when the 802.11s mesh is commented out, so it's definately related.
The only other mention of this that I found is here:
The poster also used 802.11s.
Can anyone with a bit of insight tell me how bad this is?
The mesh at least appears to be working.
It looks like it can be ignored. I have the same warning and never had an issue with mesh using openssl. Are you able to use wolfssl?
https://bugs.openwrt.org/index.php?do=details&task_id=3459&pagenum=2
Thank you very much for the link, not sure how I missed that.
Yes, I'm currently using wolfssl, although I haven't had the time yet to test it thoroughly.
But the mesh has been up for two days now and appears to work fine so far.
Is there any current reason why one would want to use openssl instead?
So for unknown reason kmod-wireguard has suddenly appeared in the package list after it was missing for a few days. But the actual wireguard package is still absent and I guess that is the package containing the wg binary so I can't run it without installing it. Anyone know what's up with the missing wireguard package? I'm on 20.02 rc3.
Is it fair to say since OpenWrt 21.02 is using kernel 5.4 that exFAT support is "native" now with the new drivers built-into the kernel? I'm getting 120 MB/s read-write on my USB 3.0 drive with minor CPU impact (no noticible drop with SQM cake 500mbit, adblock, etc.), this speed maxes out gigabit LAN. Just wondering if the kmod-fs-exfat is using this, thanks. EDIT: using a WRT32X.
Reference: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.4-Released
Should be as mine is.
lsmod | grep -i fat
exfat 73728 1
fat 65536 1 vfat
vfat 20480 0
1 Like
nice, so now another hidden helpful gem for routers was identified in 21.02 (at least I have not seen this in announcements so far). So, now there is native exfat and Airtime fairness queue management for MT76 and Atheros.
This is experienced on VR200.
I run across many wireless problems till uncheck Keep settings and retain the current configuration while installation firmware.
I don't why, but It proceeds former error characteristic. Likewise, I did uncheck before installing then used a while. Cleaning former config should prefer.
I'm a RC2 user a while and my comparisons between RC3 and RC2. Cause need native Wi-Fi 5
It's massive update after RC2!
It's contain great Wi-Fi 5 development ever!
Thank you.
Also, I should say this is not perfect stability but the stablest Wi-Fi till now!
Openwrt core
- Great development, Ping minimized even cable connection
- Soo smooth
Ethernet
- Ports works
- Not recognized any problem
Wi-Fi
- Not duplicate propagation
- Not droping suddenly
- Speed limit increased
(I didn't test maximum of the device capacity, but getting similar cable.
I would rather test it, if you show a guide. Don't know how) - Ping issue looks good
Leds brightness
Alongside all this, all indicator leds dimmed in RC3. Just usb led bright normally others is dimmed in RC2 .
In RC3 all LEDs dimmed which cannot see in daylight but except USB indicator in RC2.
I was edited led configuration in RC2, just at last LED lighted up as much as USB led.
Similarly, I added below on RC3 via LuCI.
config led
option name 'Refreh'
option sysfs 'blue:wps'
option trigger 'heartbeat'
It is bright as much as RC2's usb led heartbeat and Defaultstate. Notable in daylight.
LEDs in RC2
Flash on.
Flash off.
Nowadays, my VDSL line little problematic.
I'd rather db gain getting more speed. But it's causing enormous instability.
Yeah, it's not a single side problem. This instability affects everything, even Wi-Fi ping,
Even sometimes LuCI refuse my login on Firefox (trivially) [but chromium works same moment so interesting] Wi-Fi dropping suddenly. But this is trivial. I'll mention my ISP.
Overall
I get so good results, Thank you.
1 Like
I get mesh authentication errors in my system log with wolf. Are you using the full wolfssl library or wolfssl-mesh. I tried the wolfssl-mesh library when I got the errors
I've been using the full wpad-wolfssl, because I need 802.11r, k, and v support.
I can't say that I've seen any mesh auth errors.
What encryption did you use on the mesh?
Last time I checked luci only allowed sae and no encryption on 802.11s, you can use psk2 as well though if you configure it manually.
In my tests sae performed quite a bit worse than psk2, so that is what I'm currently using.
Yea I'd wait for announcement to make sure packages are up to date too. I installed the latest snapshot, running great on my wrt32x.
Notwithstanding the errors you see in the logs, Is the mesh working or not?
I have obveserved errors like MESH-SAE-AUTH-FAILURE even if the mesh works normally and explained why I think this is happening here but I got no confirmation from anyone more technically involved yet.
1 Like
WRT3200ACM, freshly installed 21.02 rc4, almost vanilla, from scratch :
Working great since 1 hour.
To make the wifi appear, I had to :
-well, remember my previous config in my backup (/etc/config/network)
-Wifi0 and wifi1 refused to start. So I followed instructions below.
Indeed, at least in my country Wifi0 and Wifi1 are disabled by the firmware, if they are set to country 'XX' which is different from the 'US' for Wifi2, that cannot be changed. This is because DFS is checked through the antenna used by Wifi2. For US, there might be no such issue, as I understand.
See full story here (https://tmikey.tech/tech_daily/openwrt/2019/08/18/rango-DFS.html), drivers of the Wifi2 should be removed so that it will never start :
opkg remove kmod-btmrvl kmod-mwifiex-sdio mwifiex-sdio-firmware
reboot
After that, on 5Ghz, with 2 different devices, I get 350-450Mbps Down/Up, with peaks at 500Mbps, which I find already nice.
No drops experienced.
I had similar results with the last Davidc build.
Shouldn't cell_density set to 2 or 3 work around this?
1 Like
I'll try that and if I find anything useful I'll send an update, thanks for the hint.
rc4 has been released...
1 Like