Which exact vakues did you Set?
installed r6 on Cudy-X6
Ran tyrekick.sh
No problems.
model,OUI,testID,result-v1
CUDY-X6,b44bd6,inet-dns-000001,pass
CUDY-X6,b44bd6,ntp-000001,pass
CUDY-X6,b44bd6,uhttpd-000001,pass
CUDY-X6,b44bd6,firewall-fw4-test-000001,pass
CUDY-X6,b44bd6,opkg-unzip-000001,pass
CUDY-X6,b44bd6,iperf3-000001,pass
CUDY-X6,b44bd6,all-radio-on-000001,pass
CUDY-X6,b44bd6,wireless-extra-options-radio0-2g-11-10-psk2,pass
CUDY-X6,b44bd6,wireless-extra-options-radio1-5g-36-10-psk2+ccmp,pass
CUDY-X6,b44bd6,radio0-2g-6-10-psk2,pass
CUDY-X6,b44bd6,radio1-5g-36-4-psk2,pass
Yes same one!
1 Like
Tested on NanoPI R4S ... works smooth.
(there are quite a lot information about ipsets from wiki articles to posts but) quick summary:
as the page explains you can specify ipset and domain name filter mappings. purpose is that when a domain name is resolved the resolved ip addresses are added to ipset.
then you can for example use the ipset in firewall config (*). whole things is dynamic in nature, in firewall you just reference to ipset name and not all the ip addresses individually, and also if ip address behind a domain name is changed then new ip address will also be added to ipset. mapping is many-to-many by the way, a domain name filter can be mapped to multiple ipsets, and multiple domain name filter can be mapped to single ipset. domain name filter matches from right to left, so example.com will match to *.example.com sub domains too.
it used to work with dnsmasq-full not sure if it's still the case in 22.03. also you'll need ipset package.
(*) with 22.03's fw4/nftables this might not work though as it requires nftset supported dnsmasq which is in 2.87 as I guess, and not yet in the 2.86 version 22.03 release is coming with.
3 Likes
Any chance, that ModemManager 1.18.8 will be part of OpenWRT 22.03 final package repository?
An important feature has been added in MM 1.18.8:
1 Like
For Apple devices, DTIM 3 seems to work best. On a busy 2.4, DTIM 4 might work better.
3 Likes
Installed and running on a BTHH5, connected to an ADSL service.
The bootloop issue, https://github.com/openwrt/openwrt/issues/9829 is a pain.
The more immediate issue I have is that the system log is recording several lines stating:
Mon Aug 15 06:34:23 2022 daemon.err odhcp6c[12566]: Failed to send SOLICIT message to ff02::1:2 (Network unreachable) Mon Aug 15 06:36:16 2022 daemon.err odhcp6c[12566]: Failed to send SOLICIT message to ff02::1:2 (Network unreachable) Mon Aug 15 06:38:09 2022 daemon.err odhcp6c[12566]: Failed to send SOLICIT message to ff02::1:2 (Network unreachable),
every few minutes.
Although I do not use IPv6, it is enabled and addresses are assigned for all connected devices.
Disabling IPv6 in all the places I can find, increases the number of error messages.
One thread suggests it is caused by the package "Odhcpd-ipv6", and can be resolved by disabling 'it'.
Unfortunately I do not understand the given solution.
How do I eliminate this error?
Regards.
I actually googled a lot but couldn't figure out what information was actually relevant here. Most is with reference to fw3 and a lots of the information does not fit together. One doc say an ipset is to be defined within the dhcp scope, which LUCI also does. Another doc says it's to be defined within the firewall scope. I also saw some comments about ipsets within the release candidate threads. Maybe this topic needs to have some updated docs.
I even tried to create an ipset and to use it with the firewall configuration but without success. I did not install the ipset package though. Is the assumption right, that ipset based firewall rules cannot be created via LUCI but only via UCI commands or via uci config files? Too many riddles for me still.
not sure if should continue here or rather in a dedicated thread because afaik the ipset related functionality is not complete in 22.03-rc6. but i could be wrong.
let admins decide ...
pre 22.03 fw3 has been the firewall solution based on iptables, according to https://openwrt.org/docs/guide-user/firewall/firewall_configuration: "fw3 supports referencing or creating ipset". meaning in a config ipset section you could define an ipset for later usage. and in firewall rules you could reference to ipset name created in a config ipset. a connection would match to a firewall rule if connection's ip address matched to any ip address stored in the ipset (either source or destination ip depending how you defined ipset type).
so, that's the creation/referencing part. now to fill the ipset with actual ip addresses:
as per https://openwrt.org/docs/guide-user/base-system/dhcp#ip_sets you have two options. either using the config dnsmasq section with list ipset option; or adding a config ipset section. either way the goal is to let dnsmasq know which domain filter is mapped to which ipset which is assumed to be created already (hence you specify it in firewall config, or you can do manually). once a domain name filter is matched against a requested DNS name then resolved ip addresses are added to configured ipsets. mind the plurals.
or you use ipset utility and add ip addresses manually.
or there is ipset-dns package which does DNS resolution -> ipset addition stuff, and was created when dnsmasq did not support ipset yet.
packages you'd need (plus their dependencies of course):
ipset - for admininstration of ipsets
kmod-ipt-ipset - this is the netfilter module, "the" ipset func
dnsmasq-full - which is built with ipset support ( or ipset-dns + dnsmasq )
with 22.03 though this whole stuff changed afaik. the new fw4 is based on nftables which comes with builtin ipset functionality called set. but this is only supported by dnsmasq 2.87 which is not yet used, and the ipset admin utility is not compatible with nftables, you'd need to use nft set command instead. this means if you want to use ip address sets in fw4 you can but at this moment you have to manually add the ip addresses.
2 Likes
Hi dears,
Archer C7 v4,
I decided to go back to 21.02.03. Then, I repeated exactly the same procedure:
removed odhcpdv6only and odhcp6c
installed odhcpd and disable it.
Then added all the same features:
- adsl modem in bridged mode
- static ip to access to the bridged modem
- wireless Wan for WISP mode support
- guest wifi for both bands
- odhcpd is disabled to get rid of being spammed with error logs regarding ip v6
All configurations are the same as 22.03. However, in 21.02.03, I have no problem if I intentionally power off the router. After turning it on, it successfully assigns dynamic ip to all devices. As mentioned before, version 22.03 does not assign dynamic ip to the devices under the same configurations.
Again I thank you for all your efforts.
Regards
1 Like
You don't need to disable IPv6, even when your ISP only provides IPv4. Just use the defaults and everything will work.
The ff02::1:2 is a "sollicited node" multicast address used by the IPv6 multicast system which needs link local addresses (non-routable, fe80::/10) to be set up.
3 Likes
WRT1900ACSv2 running OpenWrt 22.03.0-rc6 r19590. Upgraded from rc5 with retained configuration. 5Ghz set to channel 36. WPA2. I continue to have the following:
- irqbalance enabled (from '0' to '1' in '/etc/config/irqbalance')
- SQM QoS enabled
- tx_amsdu disabled. Luci > startup > local startup (nano /etc/rc.local) the following commands:
echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo "0" >> /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu
18h uptime.
No significant issues! Excellent performance.
- reboot/reload adblock required after installation.
Do you also run banip ... does it support firewall4?
22.03-rc6 is working nicely on RPi Computer Module 4 plus DFRobot dual gigabit board
1 Like
Hi dear,
thanks for your reply.
When using default setup I was spammed in the log section with some messages like this :. err... network unreachable,
I've forgotten the exact message but searching the forum I had found a topic regarding the same error which was tagged as solved by disabling odhcpd.
let me reproduce the error just now...
Fri Aug 19 23:52:30 2022 daemon.err odhcpd[26218]: Failed to send to ff02::1%lan@br-lan (Permission denied)
I just enabled odhcpd and got the above error in the log section.
I disable IPv6 in devices configuration and all other settings. the same error happens when using default configuration.
Anyway, I am on 21.02.03 now. When I simply disable odhcpd there is no error in the logs. And, the router successfully assigns dynamic ip to all devices. However, in 22.03 rc6 if the router is rebooted under the above-mentioned conditions it does not assign dynamic ip to the devices.
Thanks again for your attention.
Thanks,
Solved it.
The ADSL (pppoa-wan) interface was the only one not reporting an IPv6 address on the Network/Interfaces page in LUCI.
On the Advanced tab I enabled "Delegate IPv6 prefixes", changed the "IPv6 assignment length" to match the other interfaces; saved-and-applied.
(It added the line "option ip6assign '60'" to the "config interface 'wan'" part of the file /etc/config/network).
I have not had any 'loop-local' errors since.
Regards.
Seems to be working well on my BT hub5 which I'm using on my VDSL connection, not noticed any issues so far.
I've got it to boot reliably without encountering the really annoying BT hub5 boot loop issue by building it from source with most packages and modules built using the 'm' option so that they are omitted from the sysupgrade bin file and installing them using opkg after first boot. I've rebooted the 2 routers its installed on multiple times and they appeared to boot successfully every time, or at least there was no obvious sign of a delay.
I used the guide here to get a matching kernel vermagic so I can still use the install feeds
I also tried including some of the omitted packages such as for wireless support, but still without luci, but that bootlooped for ages.
@mjs could you please check whether using https://firmware-selector.openwrt.org/ with the minimal set of packages, as opposed to building the image from source, also avoids the boot loop?
Full disclosure: the installation mentioned in my earlier comment (OpenWrt 22.03.0-rc6 sixth release candidate - #50 by patrakov) was also performed using https://firmware-selector.openwrt.org/ using a customized set of packages. However, for me, the boot-loop problem clearly correlates with the physical location of the router and the power supply used. That installation still works (personally tested yesterday), and my friend doesn't complain about anything.