I think a bridge device needs to exist if you are using the WiFi (WLAN) as part of LAN network. If you are not using WiFi, I think you can remove the "br-lan" and directly use "eth0" instead.
2 Likes
Has anyone gotten 802.11s to work with wolfssl? I’m getting a mesh-sae-auth-failure error. Switching to OpenSSL works fine
R7800 to R7800
I've got the same issue with wifi radio behaving erratically.
It's been an issue for me since RC2, but not from the onset. It came lately, that's why I moved to RC3.
Now, I'm using OpenWrt 21.02.0-rc3 r16172-2aba3e9784
I hope we'll soon get a patch for it.
D-Link DIR-878 Rev. A1
WLAN: MediaTek MT7615N
Same problem with the D-Link DIR-882 Rev. A1 tested/mentioned earlier,
During first day of testing, encountered an android smartphone on 5 GHz WiFi occasionally displaying: Connected, no internet.
Signal strength was excellent.
Connecting to 2.4 GHz WiFi then switching back to 5 GHz resolved issue.
Did not notice anything in the system log.
Halted test of RC3
and
Tried two different development snapshots, such as the recent r17187-ca31755af9. Same problem.
unfortunately this release does not work with clearfog pro when using an ath10k based wifi chip, see https://bugs.openwrt.org/index.php?do=details&task_id=3948
not sure since when this problem occurs, guess its related to the kernel version
if anyone can recommend another wifi card (mini pcie full size), please let me know
Target: x86/64
I have been struggling to get UPnP working with an Xbox with recent OpenWrt versions. From what I can tell, its related to IGDv1 vs IGDv2 and recent versions of minupnpd.
Looking at UPnP port forwarding not working for Windows 10 and Xbox One, I see https://github.com/openwrt/packages/pull/14656 was merged into trunk, and I can confirm on latest snapshots that using miniupnpd-igdv1 fixes my issue.
Is there any chance this could be merged into the 21.02 branch?
I also wish to report that my Linksys WRT1900ACS v2 has been running great for about a week with this new release. Thank you to all the devs who fixed the Linksys connectivity issues that were present in the earlier release candidates.
Also, applying the tweaks mentioned in the quoted post has resulted in huge performance improvements. Nothing has been measured but it sure feels like there's a noticable difference. Thanks to @User34 for sharing.
1 Like
But is there no wireguard or kmod-wireguard package available in opkg for this release? Seems to be missing for me.
I am on rc3 for a few days. There is a mod package listed for wireguard.
Did you update the opkg package list first?
If it still does not show for your device, probably drop your full device name here.
Yeah I do update the package listing but they’re still missing. I’m on a Linksys WRT1900ACS v2.
Device: dir-1960:
OpenWrt 21.02.0-rc3, r16172-2aba3e9784
-----------------------------------------------------
root@OpenWrt:~# opkg list | grep -e wireguard | grep -v i18n
kmod-wireguard - 5.4.124-1 - WireGuard is a novel VPN that runs inside the Linux Kernel ...
luci-app-wireguard - git-20.244.42172-21563a2 - WireGuard Status
luci-proto-wireguard - git-21.163.62622-a6a6d61 - Support for WireGuard VPN
wireguard-tools - 1.0.20210223-2 - WireGuard is a novel VPN that runs inside the Linux Kernel ...
It is also a driver parameter.
echo "Y" > /sys/module/mwifiex/parameters/disable_tx_amsdu
Oh, you were asking about which software version is being used. I'm running OpenWrt 21.02.0-rc3, r16172-2aba3e9784.
After updating the opkg lists, I do not have the "wireguard" or "kmod-wireguard" packages availble. Besides the luci-i18n packages, the only ones I have related to wireguard are luci-proto-wireguard, wg-installer-client, wg-installer-server, wg-installer-server-hotplug-babeld, wireguard-tools, luci-app-wireguard.
So this is kind of strange. Anyone know why they're missing?
Hi,
Do you mean
echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
should be changed to
echo "Y" > /sys/module/mwifiex/parameters/disable_tx_amsdu
?
One is the driver for radios 0 and 1, the other is the driver for radio 3.
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?