Release Asuswrt-Merlin 3004.388.6 is now available
- Thread starter RMerlin
- Start date
Many thanks Merlin and the rest of the team
Ghettorat
New Around Here
I have a strange problem on my RT-AX86U that with this firmware (the beta and some other earlier releases too) where my physical wired LAN clients refuse to communicate after updating. They do not see each other and do not connect to the internet. Cannot ping or anything. Have tried rebooting etc for new DHCP address but does not work. Wifi is fine for all clients and all other settings fine too.
I have tried hard reset and manually entering settings from scratch etc but the pcs connected and other various android devices say the physical connection is unavailable. I use standard LAN settings with no other configurations. No idea why this should be an issue.
Just reloaded 3004-388-5 and LAN and all other connectivity OK again instantly. Appreciate if anyone has any suggestions to what can be the issue. I do have logs etc.
Thanks
I have tried hard reset and manually entering settings from scratch etc but the pcs connected and other various android devices say the physical connection is unavailable. I use standard LAN settings with no other configurations. No idea why this should be an issue.
Just reloaded 3004-388-5 and LAN and all other connectivity OK again instantly. Appreciate if anyone has any suggestions to what can be the issue. I do have logs etc.
Thanks
Merlin firmware performs an additional check for AX clients.
httpd: report MU-MIMO and STBC support for AX clients · RMerl/asuswrt-merlin.ng@e365a66
Third party firmware for Asus routers (newer codebase) - httpd: report MU-MIMO and STBC support for AX clients · RMerl/asuswrt-merlin.ng@e365a66
github.com
nlurker
Regular Contributor
In case this helps @Ghettorat or anyone else:
After upgrading, all my devices dropped from the network and would not reconnect. After an hour of panicked troubleshooting, I managed to get back into the router and found the problem.
dnsmasq was failing to start, due to an illegal repeated keyword in dnsmasq.conf. I fixed it by removing dns-forward-max=1000 from my dnsmasq.conf.add. This has never been a problem before, so dnsmasq must have changed in this release. All is working normally now.
After upgrading, all my devices dropped from the network and would not reconnect. After an hour of panicked troubleshooting, I managed to get back into the router and found the problem.
dnsmasq was failing to start, due to an illegal repeated keyword in dnsmasq.conf. I fixed it by removing dns-forward-max=1000 from my dnsmasq.conf.add. This has never been a problem before, so dnsmasq must have changed in this release. All is working normally now.
It looks like the DLNA service doesn't even start. The minidlna.log file is not created. The database is not created.
Jan 22 19:51:31 rc_service: httpds 1335:notify_rc restart_media
Jan 22 19:51:31 avahi-daemon[3669]: Files changed, reloading.
Jan 22 19:51:31 avahi-daemon[3669]: Loading service file /tmp/avahi/services/mt-daap.service.
Jan 22 19:51:31 iTunes: daemon is stopped
Jan 22 19:51:32 avahi-daemon[3669]: Service "Router" (/tmp/avahi/services/mt-daap.service) successfully established.
Jan 22 19:51:31 avahi-daemon[3669]: Files changed, reloading.
Jan 22 19:51:31 avahi-daemon[3669]: Loading service file /tmp/avahi/services/mt-daap.service.
Jan 22 19:51:31 iTunes: daemon is stopped
Jan 22 19:51:32 avahi-daemon[3669]: Service "Router" (/tmp/avahi/services/mt-daap.service) successfully established.
Jan 22 19:53:14 rc_service: httpds 1335:notify_rc restart_media
Jan 22 19:53:14 avahi-daemon[3669]: Got SIGTERM, quitting.
Jan 22 19:53:14 avahi-daemon[3669]: Leaving mDNS multicast group on interface br1.IPv4 with address 192.168.101.1.
Jan 22 19:53:14 avahi-daemon[3669]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.1.1.
Jan 22 19:53:14 avahi-daemon[3669]: Leaving mDNS multicast group on interface lo.IPv4 with address 127.0.1.1.
Jan 22 19:53:14 avahi-daemon[3669]: avahi-daemon 0.8 exiting.
Jan 22 19:53:16 avahi-daemon[5042]: Found user 'nobody' (UID 65534) and group 'nobody' (GID 65534).
Jan 22 19:53:16 avahi-daemon[5042]: Successfully dropped root privileges.
Jan 22 19:53:16 avahi-daemon[5042]: avahi-daemon 0.8 starting up.
Jan 22 19:53:16 avahi-daemon[5042]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jan 22 19:53:16 avahi-daemon[5042]: Loading service file /tmp/avahi/services/alexa.service.
Jan 22 19:53:16 avahi-daemon[5042]: Loading new alias name RT-AX88U.
Jan 22 19:53:16 iTunes: daemon is stopped
Jan 22 19:53:16 avahi-daemon[5042]: Joining mDNS multicast group on interface br1.IPv4 with address 192.168.101.1.
Jan 22 19:53:16 avahi-daemon[5042]: New relevant interface br1.IPv4 for mDNS.
Jan 22 19:53:16 avahi-daemon[5042]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.1.
Jan 22 19:53:16 avahi-daemon[5042]: New relevant interface br0.IPv4 for mDNS.
Jan 22 19:53:16 avahi-daemon[5042]: Joining mDNS multicast group on interface lo.IPv4 with address 127.0.1.1.
Jan 22 19:53:16 avahi-daemon[5042]: New relevant interface lo.IPv4 for mDNS.
Jan 22 19:53:16 avahi-daemon[5042]: Network interface enumeration completed.
Jan 22 19:53:16 avahi-daemon[5042]: Registering new address record for 192.168.101.1 on br1.IPv4.
Jan 22 19:53:16 avahi-daemon[5042]: Registering new address record for 192.168.1.1 on br0.IPv4.
Jan 22 19:53:16 avahi-daemon[5042]: Registering new address record for 127.0.1.1 on lo.IPv4.
Jan 22 19:53:16 avahi-daemon[5042]: Registering new address record for 127.0.0.1 on lo.IPv4.
Jan 22 19:53:16 custom_config: Using custom /jffs/configs/minidlna.conf config file.
Jan 22 19:53:17 avahi-daemon[5042]: Server startup complete. Host name is Router.local. Local service cookie is 1757952664.
Jan 22 19:53:17 avahi-daemon[5042]: Alias name "RT-AX88U" successfully established.
Jan 22 19:53:18 avahi-daemon[5042]: Service "Router" (/tmp/avahi/services/alexa.service) successfully established.
Jan 22 19:53:14 avahi-daemon[3669]: Got SIGTERM, quitting.
Jan 22 19:53:14 avahi-daemon[3669]: Leaving mDNS multicast group on interface br1.IPv4 with address 192.168.101.1.
Jan 22 19:53:14 avahi-daemon[3669]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.1.1.
Jan 22 19:53:14 avahi-daemon[3669]: Leaving mDNS multicast group on interface lo.IPv4 with address 127.0.1.1.
Jan 22 19:53:14 avahi-daemon[3669]: avahi-daemon 0.8 exiting.
Jan 22 19:53:16 avahi-daemon[5042]: Found user 'nobody' (UID 65534) and group 'nobody' (GID 65534).
Jan 22 19:53:16 avahi-daemon[5042]: Successfully dropped root privileges.
Jan 22 19:53:16 avahi-daemon[5042]: avahi-daemon 0.8 starting up.
Jan 22 19:53:16 avahi-daemon[5042]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jan 22 19:53:16 avahi-daemon[5042]: Loading service file /tmp/avahi/services/alexa.service.
Jan 22 19:53:16 avahi-daemon[5042]: Loading new alias name RT-AX88U.
Jan 22 19:53:16 iTunes: daemon is stopped
Jan 22 19:53:16 avahi-daemon[5042]: Joining mDNS multicast group on interface br1.IPv4 with address 192.168.101.1.
Jan 22 19:53:16 avahi-daemon[5042]: New relevant interface br1.IPv4 for mDNS.
Jan 22 19:53:16 avahi-daemon[5042]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.1.
Jan 22 19:53:16 avahi-daemon[5042]: New relevant interface br0.IPv4 for mDNS.
Jan 22 19:53:16 avahi-daemon[5042]: Joining mDNS multicast group on interface lo.IPv4 with address 127.0.1.1.
Jan 22 19:53:16 avahi-daemon[5042]: New relevant interface lo.IPv4 for mDNS.
Jan 22 19:53:16 avahi-daemon[5042]: Network interface enumeration completed.
Jan 22 19:53:16 avahi-daemon[5042]: Registering new address record for 192.168.101.1 on br1.IPv4.
Jan 22 19:53:16 avahi-daemon[5042]: Registering new address record for 192.168.1.1 on br0.IPv4.
Jan 22 19:53:16 avahi-daemon[5042]: Registering new address record for 127.0.1.1 on lo.IPv4.
Jan 22 19:53:16 avahi-daemon[5042]: Registering new address record for 127.0.0.1 on lo.IPv4.
Jan 22 19:53:16 custom_config: Using custom /jffs/configs/minidlna.conf config file.
Jan 22 19:53:17 avahi-daemon[5042]: Server startup complete. Host name is Router.local. Local service cookie is 1757952664.
Jan 22 19:53:17 avahi-daemon[5042]: Alias name "RT-AX88U" successfully established.
Jan 22 19:53:18 avahi-daemon[5042]: Service "Router" (/tmp/avahi/services/alexa.service) successfully established.
I use custom minidlna.conf config file. But only path to mediafiles is changed.
Last edited:
Ghettorat
New Around Here
Thank you very much for this suggestion! I will try it tomorrow.
Mine's an A1.1
"Kinda" glad to see it's not just me with a problem.
It's been totally fine since factory reset and re-configure.
Full disclosure - I have found a dodgy ethernet cable running from my wall socket to the RTR, now replaced. Although that was bypassed at some stage when I was trying to upload the backup config so not sure it's related
John Adler
Regular Contributor
Dirty flash from beta
everything fine so far
thxs Merlin !
everything fine so far
thxs Merlin !
Asus made changes to dnsmasq and the config file now includes this line:
dns-forward-max=1500
so your entry repeated the command.
I had the same issue in the alpha release! https://www.snbforums.com/threads/3...s-testing-available-build-s.88112/post-881674
nlurker
Regular Contributor
Thank you, this known problem should have been mentioned in the change log for people who do not follow alpha/beta testing. It would have saved me a lot of panic when the release completely broke my network.
Last edited:
If I remember correctly, Asus only checks for Wifi 5 MU-MIMO, while I check for explicit Wifi 6 MU-MIMO (HE). My report is more accurate here.
Meanshadows35
Occasional Visitor
AX68U is rock solid like always. Went from the Beta to full release. I'll report back by this weekend. But so far so smooth.
It`s not a "known problem". If you make any customization to the configuration file, then you become responsible for managing these customizations, as nobody but you can tell what kind of changes you or anyone else might be doing. I cannot foresee the thousands of possible changes someone might be doing through customized config files...
The system log is the first place to check in case of an issue, and a dnsmasq issue would get logged there.
That would imply you don’t have a br0 LAN interface on the router.
what is the output of
Code:
tc qdisc show rootnlurker
Regular Contributor
I meant that it was a problem found by several alpha testers. Is it possible for the change log to include a summary of problems like this discovered during testing, since they are likely to impact others as well? I would have checked the system log first, however I could not access the router since nothing would connect. It took me a while to figure out how to get back into the router, having no internet access to research the problem.
I am not criticizing you foreseeing thousands of problems. I am asking to document known issues discovered during alpha testing, to help regular users who do not follow alpha testing.
I use a post-config script to modify minidlna.conf, but only to change the location of the log file and similar items.
So nothing at all in /jffs/.minidlna/minidlna.log? Odd. Definitely not starting, then.
Mine builds the database, and even seems to broadcast ok, but the transition to the new version is evident:
[2024/01/21 04:33:07] upnphttp.c:1365: error: send(res_buf): Connection reset by peer
[2024/01/21 11:21:56] minidlna.c:167: warn: received signal 15, good-bye
------------------------------------------------------------
[1969/12/31 17:01:06] minidlna.c:550: warn: Unset locale
[1969/12/31 17:01:06] minidlna.c:1432: warn: Starting MiniDLNA version 1.3.3.
[1969/12/31 17:01:06] minidlna.c:419: warn: Creating new database at /tmp/mnt/M_db/.minidlna/files.db
[1969/12/31 17:01:06] minidlna.c:1480: warn: HTTP listening on port 8200
To avoid flooding the changelog with content that would be relevant to a very small number of people, I generally try to stick with notes that might affects many users. Like in the case of the SSL certificate. For the dnsmasq issue, I never expected anyone to be doing that particular change, or at most a very small number of users, that's why I didn't include it (in fact I had even completely forgotten it had happened).
So, I generally pick and chose what to add and what to skip to keep the changelog a manageable size. This case just happen to be a very rare case that affected you specifically.
BTW, that error should have shown in your system log.
snapieee
Occasional Visitor
fyi, it was working fine on 388.5
Here is the output after upgrading to 388.6:
Code:
# tc qdisc show root
qdisc noqueue 0: dev lo root refcnt 2
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth2 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth3 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth4 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc htb 1: dev eth0 root refcnt 2 r2q 10 default 0 direct_packets_stat 5 direct_qlen 1000
qdisc pfifo_fast 0: dev eth5 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev spu_us_dummy root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev spu_ds_dummy root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth6 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth7 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc htb 1: dev br0 root refcnt 2 r2q 10 default 0 direct_packets_stat 2 direct_qlen 1000
qdisc pfifo_fast 0: dev wl0.1 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wl1.1 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc noqueue 0: dev eth1.501 root refcnt 2
qdisc noqueue 0: dev eth2.501 root refcnt 2
qdisc noqueue 0: dev eth3.501 root refcnt 2
qdisc noqueue 0: dev eth4.501 root refcnt 2
qdisc noqueue 0: dev eth5.501 root refcnt 2
qdisc noqueue 0: dev eth6.501 root refcnt 2
qdisc noqueue 0: dev eth7.501 root refcnt 2
qdisc noqueue 0: dev br1 root refcnt 2
qdisc noqueue 0: dev eth1.502 root refcnt 2
qdisc noqueue 0: dev eth2.502 root refcnt 2
qdisc noqueue 0: dev eth3.502 root refcnt 2
qdisc noqueue 0: dev eth4.502 root refcnt 2
qdisc noqueue 0: dev eth5.502 root refcnt 2
qdisc noqueue 0: dev eth6.502 root refcnt 2
qdisc noqueue 0: dev eth7.502 root refcnt 2
qdisc noqueue 0: dev br2 root refcnt 2
qdisc pfifo_fast 0: dev tun21 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1Similar threads
Similar threads
Similar threads
-
-
-
Asuswrt-Merlin 3004.388.8_2 - Switching from ‘automatic IP’ to ‘PPPoE’- Started by AsusFreak
- Replies: 6
-
-
-
-
-
-
-
Beta Asuswrt-Merlin 3004.388.6_x test builds (dnsmasq 2.90)
- Started by RMerlin
- Replies: 102
Latest threads
-
AdGuardHome Use DNS encryption automatically via AdGuard DHCP server
- Started by Milan
- Replies: 1
-
-
Ubuntu Linux impacted by decade-old 'needrestart' flaw that gives root- Started by PR3MIUM
- Replies: 0
-
-
Support SNBForums w/ Amazon
If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!
Sign Up For SNBForums Daily Digest
Get an update of what's new every day delivered to your mailbox. Sign up here!