Will give this a shot. Yeah, I figured if I just restart the modem after changing the cables it would suffice. Clearly it was still locked to the old router MAC. Thank you!
1 Like
Nice! I’ve seen locks for half an hour to an hour but could be longer. You could try leaving it off overnight
1 Like
Would anyone happen to know if there's any benefits (or if it's necessary) from flashing the latest installer (v0.6.2) given the switch to firewall 4? The installer I used was v0.5.3 and currently on an iptables build.
Not that I'm aware of. The latest installer has updated u-boot loader. firewall4 is built into the sysupgrade image, so it doesn't matter whether you're on the 0.5.3 or 0.6.2 installer.
3 Likes
Hi,
I just got this afternoon my new router, a Linksys E8450. I did the UBI installation without any major issue, keeping the original firmware backup in a good place.
When installing basic modules such as luci-ssl-openssl I get these errors from opkg:
Collected errors:
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-nf-reject
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-nf-reject6
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-crypto-crc32c
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-nft-core
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-nf-flow
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-nf-nat6
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-nf-ipt
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-ipt-core
luci-app-nlbwmon is not installed. I get the following error:
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for luci-app-nlbwmon:
* kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1)
* opkg_install_cmd: Cannot install package luci-app-nlbwmon.
luci-app-banip cant be installed error:
Collected errors:
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-nf-reject
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-nf-ipt
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-ipt-core
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-nf-reject6
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-crypto-crc32c
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-nft-core
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1) for kmod-nft-compat
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-nft-compat found, but incompatible with the architectures configured
* satisfy_dependencies_for: Cannot satisfy the following dependencies for luci-app-banip:
* kernel (= 5.10.102-1-c52cbcf17c7afa063d140662123758e1)
* opkg_install_cmd: Cannot install package luci-app-banip.
I haven't continued yet, however, I assume there might be more issues with the dependencies with other packages. Anyway I could fix this? Thanks
You need to update to the latest snapshot if you want to install packages from the repo or build them yourself. See https://openwrt.org/releases/snapshot
You can use Attended Sysupgrade in luci or auc in cli to update.
1 Like
I went with 0.6.1 and then Attended Sysupgrade, had to change to firewall4 from firewall when selecting packages to include in the sysupgrade. I also removed iptables from the selected packages. So if you go with 0.6.2 then you don't have to do this step to get firewall4 and no iptables.
btw I think offloading only works with nftables and not iptables.
1 Like
Yes, I've tried updating to the latest snapshot, but with it, 5G radio is not working.
Please be aware that the latest version of luci-app-attendedsysupgrade (git-22.061.35311-de3e0bb) seems broken as this is what I've got in luci:
NotFoundError
Resource not found
Is there a way to install the previous version (git-21.258.26848-0d0fcb3) using opkg?
The main advantages of nftables over iptables are the simplification of the Linux kernel ABI, reduction of code duplication, improved error reporting, and more efficient execution, storage and incremental changes of filtering rules.
4 Likes
Came here to see if there's a way around my fw4 issue. On my older router I ran AdGuardHome right off the USB stick (tutorial here: [HowTo] Running Adguard Home on OpenWrt), and then simply forwarded all client DNS traffic to it:
iptables -t nat -A PREROUTING -i br-lan -p udp --dport 53 -j DNAT --to 192.168.1.1:5353
iptables -t nat -A PREROUTING -i br-lan -p tcp --dport 53 -j DNAT --to 192.168.1.1:5353
I'm currently missing the custom rules section on my snapshot (OpenWrt SNAPSHOT r18646-3869ccbcc8 / LuCI Master git-22.025.79016-22e2bfb). This is the dangowrt Release v0.6.2. Is there a way to enable it?
Or is there a way to translate the above code to be nftable compatible perhaps? And where would I put it anyway? Ideally I'd stick to fw4 as that will be the standard going forward I assume. Otherwise, I need to drop back down to fw3? Or what do you all suggest?
in the latest git, luci-app-attendysupgrade is still broken, but you can log in via ssh and use 'auc' cli util to sysupgrade
1 Like
5G Wifi fails when using 160MHz channel in the low contiguous band (CH36-64) using CH36 to CH48 as the configured channel in the configuration. However the 160MHz connection from CH36 to CH64 works when selecting any channel from CH52 to CH64.
In all 8 cases, the system log is the same, but wifi is not available to the clients when using the lower 4 channels in the configuration. Maybe the fact that the lower 4 IEEE channels are not DFS could be something.
In any case, this is something new, as you can see it happening for instance in today's SNAPSHOT r19040-247eaa4416 but not in older SNAPSHOT r18646-3869ccbcc8.
The system log reports the expected information but 5G is not working in this case:
Sat Mar 5 01:15:33 2022 daemon.notice hostapd: wlan1: interface state HT_SCAN->DFS
Sat Mar 5 01:15:33 2022 daemon.notice hostapd: wlan1: DFS-CAC-START freq=5180 chan=36 sec_chan=1, width=2, seg0=50, seg1=0, cac_time=60s
Sat Mar 5 01:15:34 2022 daemon.notice netifd: Wireless device 'radio1' is now up
Sat Mar 5 01:16:35 2022 daemon.notice hostapd: wlan1: DFS-CAC-COMPLETED success=1 freq=5180 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5250 cf2=0
Sat Mar 5 01:16:35 2022 daemon.warn hostapd: Can't set DFS state for freq 5180 MHz
Sat Mar 5 01:16:35 2022 daemon.warn hostapd: Can't set DFS state for freq 5200 MHz
Sat Mar 5 01:16:35 2022 daemon.warn hostapd: Can't set DFS state for freq 5220 MHz
Sat Mar 5 01:16:35 2022 daemon.warn hostapd: Can't set DFS state for freq 5240 MHz
Sat Mar 5 01:16:35 2022 kern.info kernel: [ 2845.222641] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
Sat Mar 5 01:16:35 2022 kern.info kernel: [ 2845.229167] br-lan: port 6(wlan1) entered blocking state
Sat Mar 5 01:16:35 2022 kern.info kernel: [ 2845.234530] br-lan: port 6(wlan1) entered forwarding state
Sat Mar 5 01:16:35 2022 daemon.notice netifd: Network device 'wlan1' link is up
Sat Mar 5 01:16:35 2022 daemon.notice hostapd: wlan1: interface state DFS->ENABLED
Sat Mar 5 01:16:35 2022 daemon.notice hostapd: wlan1: AP-ENABLED
However, When using any channel 52, 56, 60 or 64 in the config file everything works fine, and the system log is the same:
Sat Mar 5 01:05:10 2022 daemon.notice hostapd: wlan1: interface state HT_SCAN->DFS
Sat Mar 5 01:05:10 2022 daemon.notice hostapd: wlan1: DFS-CAC-START freq=5280 chan=56 sec_chan=-1, width=2, seg0=50, seg1=0, cac_time=60s
Sat Mar 5 01:05:10 2022 daemon.notice netifd: Wireless device 'radio1' is now up
Sat Mar 5 01:06:15 2022 daemon.notice hostapd: wlan1: DFS-CAC-COMPLETED success=1 freq=5280 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5250 cf2=0
Sat Mar 5 01:06:15 2022 daemon.warn hostapd: Can't set DFS state for freq 5180 MHz
Sat Mar 5 01:06:15 2022 daemon.warn hostapd: Can't set DFS state for freq 5200 MHz
Sat Mar 5 01:06:15 2022 daemon.warn hostapd: Can't set DFS state for freq 5220 MHz
Sat Mar 5 01:06:15 2022 daemon.warn hostapd: Can't set DFS state for freq 5240 MHz
Sat Mar 5 01:06:15 2022 kern.info kernel: [ 2225.676669] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
Sat Mar 5 01:06:15 2022 kern.info kernel: [ 2225.683161] br-lan: port 6(wlan1) entered blocking state
Sat Mar 5 01:06:15 2022 kern.info kernel: [ 2225.688499] br-lan: port 6(wlan1) entered forwarding state
Sat Mar 5 01:06:15 2022 daemon.notice netifd: Network device 'wlan1' link is up
Sat Mar 5 01:06:16 2022 daemon.notice hostapd: wlan1: interface state DFS->ENABLED
Sat Mar 5 01:06:16 2022 daemon.notice hostapd: wlan1: AP-ENABLED
It is strange, as the configuration works in the Netgear R7800.
This is the /etc/config/wireless that duplicates the issue:
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/18000000.wmac'
option channel '1'
option band '2g'
option htmode 'HT40'
option country 'US'
option cell_density '0'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid '2G'
option encryption 'sae-mixed'
option key 'PasswordHere'
config wifi-device 'radio1'
option type 'mac80211'
option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
option band '5g'
option country 'US'
option cell_density '0'
option htmode 'HE160'
option channel '36'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid '5G'
option encryption 'sae-mixed'
option key 'PasswordHere'
So far the easy workaround is to avoid CH36 to CH48 when using 160MHz channel until the problem was fixed.
1 Like
Might be fixed in future by
3 Likes
@daniel
Have you thought what you are going to do with the forthcoming 22.0x release in a few weeks?
Can the ubi installer build be integrated/upstreamed to OpenWrt repo?
Additionally, I would suggest that on the release branch, the bootcmd would be modified so that the router would recover/restart normally e.g. after a WiFi driver caused crash/reboot, instead of being stuck in the recovery initramfs mode until pstore files are deleted. (The pstore feature is useful for debugging by enthusiasts, but may be confusing for casual users)
5 Likes
Thanks for the link, it seems to fix the issue. The fix was committed 9 days ago on master, but the problem is still happening today. How long does it take for a fix to arrive in the download section, imagebuilder, etc? Usually fixes in the openwrt/Packages and OpenWrt/OpenWrt are immediately applied in the next snapshot.
Was it????
Yes, the fix has been committed into the mt76 repo.
But to my knowledge the driver Makefile in OpenWrt has not yet been updated by @nbd to actually use that mt76 upstream version...
3 Likes
If you want to try the new mt76 version with that VHT160 DFS fix , you can test it by yourself by patching the mt76 Makefile:
--- a/package/kernel/mt76/Makefile
+++ b/package/kernel/mt76/Makefile
@@ -8,9 +8,9 @@ PKG_LICENSE_FILES:=
PKG_SOURCE_URL:=https://github.com/openwrt/mt76
PKG_SOURCE_PROTO:=git
-PKG_SOURCE_DATE:=2022-02-15
-PKG_SOURCE_VERSION:=c67df0d3130a51d79b558f0329c2ca289c73b16e
-PKG_MIRROR_HASH:=57526f62adc1c1cc2c594ff23b883314ad83df8cdfab54c9e3503a8ec4c3a33f
+PKG_SOURCE_DATE:=2022-02-24
+PKG_SOURCE_VERSION:=64c74dc93f68566cd2c199d2951482ee55ca8b9a
+PKG_MIRROR_HASH:=5b3d60047ff9ee97e091b7a2cd20778d1eea61e9210ad19944f2b942a3c16d90
PKG_MAINTAINER:=Felix Fietkau <nbd@nbd.name>
PKG_USE_NINJA:=0
EDIT:
with that patch, VHT160 at 36 succeeds.
2 Likes
I want to try it, I have already patched the mt76 Makefile but I am kinda lost with the .config. Can anyone provide a good reliable .config to start with for the E8450? I always get lost with the kernel modules.
You can start with just an empty .config, and then select the device and add LuCI.
EDIT:
I have uploaded my own r19043-c2d7896a65 build with that patch to:
Also my build config can be seen there as "diffconfig.txt"
2 Likes