What's new

[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Hey guys, I am kinda remembering @john9527 saying something about the ideal place to put scripts for vlan, but I can't find that anymore. The "problem" that I am facing, I had to put this stuff in two scripts, init-start & services-start to have it working reliably. Is there a better solution?
You're probably thinking of the new lan-start script that was added in the last dev build.

http://www.snbforums.com/threads/fork-asuswrt-merlin-374-43-lts-releases-v44ea.18914/post-610628
 
@ColinTaylor Do you or anyone else think that lan-start will solve that issue, that services-start is to late for wired vlan and init-start to early for everything else?
 
Hi. First things first - huge thanks for keeping this alive!
My good old RT-N66U was running 374.43_44EAj9527 for quite a while but recently I noticed it drops packages over WiFi between the router and the clients from time to time, at least on 5GHz (I wasn't monitoring 2.4GHz closely as my main work machines are connected to 5GHz). It's kind of random, not in similar time periods. Sometimes it's a single package, sometimes it's a few, so it can break the streaming of internet radios, hang my work VPN connection, or disturb the feed on video calls. I monitored the pings to the router (simply 192.168.1.1) and to Google's DNS server (8.8.8.8) with PingPlotter.
First thing I did - I replaced the power supply with over two times more powerful one, as I read some threads saying that the original power supply may deteriorate over time (mine is ~7 years old) and cause such effects. Unfortunately - that didn't help.
So I've just flashed the development firmware: 3.0.0.4.374.43_45D5j9527
This apparently didn't help either, as I've just noticed another lost pings. I checked the logs and couldn't find anything suspicious except:
Code:
Sep  7 20:30:15 (none) cron.err crond[402]: time disparity of 5094390 minutes detected
but I presume it's also normal as the router updated the time from the NTP after the reboot after flashing the firmware. I pasted the full log (after a bit of anonymization :) ) at: https://pastebin.com/49Ymyp9F

FYI, otherwise the build looks stable after 2 hours of testing.

But any idea what might cause those lost packages? I don't really have the need to buy a new router, if not that...

EDIT01 after a day: I've just got a huge package drop lasting over 30 seconds (from 10:08:43 to 10:09:14). This surely came in the worst possible moment, killing my video conference call :( I checked the router logs but I can't see nothing else but plenty DHCP-related entries around that time (I'm not sure though how well the time of my PC and the router are synced), like those (I manually replaced last bytes of MAC with xx:xx):

Code:
Sep  9 10:06:54 (none) user.info kernel: device br0 entered promiscuous mode
Sep  9 10:06:57 (none) daemon.info dnsmasq-dhcp[651]: DHCPDISCOVER(br0) ac:9e:17:e9:xx:xx 
Sep  9 10:06:57 (none) daemon.info dnsmasq-dhcp[651]: DHCPOFFER(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:06:57 (none) daemon.info dnsmasq-dhcp[651]: DHCPREQUEST(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:06:57 (none) daemon.info dnsmasq-dhcp[651]: DHCPACK(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:07:09 (none) user.info kernel: device br0 left promiscuous mode
Sep  9 10:07:10 (none) daemon.info dnsmasq-dhcp[651]: DHCPDISCOVER(br0) ac:9e:17:e9:xx:xx 
Sep  9 10:07:10 (none) daemon.info dnsmasq-dhcp[651]: DHCPOFFER(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:07:10 (none) daemon.info dnsmasq-dhcp[651]: DHCPREQUEST(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:07:10 (none) daemon.info dnsmasq-dhcp[651]: DHCPACK(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:07:12 (none) user.info kernel: device br0 entered promiscuous mode
Sep  9 10:07:15 (none) daemon.info dnsmasq-dhcp[651]: DHCPRELEASE(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:07:44 (none) daemon.info dnsmasq-dhcp[651]: DHCPDISCOVER(br0) ac:9e:17:e9:xx:xx 
Sep  9 10:07:44 (none) daemon.info dnsmasq-dhcp[651]: DHCPOFFER(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:07:44 (none) daemon.info dnsmasq-dhcp[651]: DHCPDISCOVER(br0) ac:9e:17:e9:xx:xx 
Sep  9 10:07:44 (none) daemon.info dnsmasq-dhcp[651]: DHCPOFFER(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:07:44 (none) daemon.info dnsmasq-dhcp[651]: DHCPREQUEST(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:07:44 (none) daemon.info dnsmasq-dhcp[651]: DHCPACK(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:07:55 (none) daemon.info dnsmasq-dhcp[651]: DHCPDISCOVER(br0) ac:9e:17:e9:xx:xx 
Sep  9 10:07:55 (none) daemon.info dnsmasq-dhcp[651]: DHCPOFFER(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:07:55 (none) daemon.info dnsmasq-dhcp[651]: DHCPREQUEST(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:07:55 (none) daemon.info dnsmasq-dhcp[651]: DHCPACK(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:08:16 (none) daemon.info dnsmasq-dhcp[651]: DHCPDISCOVER(br0) ac:9e:17:e9:xx:xx 
Sep  9 10:08:16 (none) daemon.info dnsmasq-dhcp[651]: DHCPOFFER(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:08:16 (none) daemon.info dnsmasq-dhcp[651]: DHCPREQUEST(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:08:16 (none) daemon.info dnsmasq-dhcp[651]: DHCPACK(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:08:41 (none) daemon.info dnsmasq-dhcp[651]: DHCPDISCOVER(br0) ac:9e:17:e9:xx:xx 
Sep  9 10:08:41 (none) daemon.info dnsmasq-dhcp[651]: DHCPOFFER(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:08:41 (none) daemon.info dnsmasq-dhcp[651]: DHCPREQUEST(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:08:41 (none) daemon.info dnsmasq-dhcp[651]: DHCPACK(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:10:03 (none) daemon.info dnsmasq-dhcp[651]: DHCPDISCOVER(br0) ac:9e:17:e9:xx:xx 
Sep  9 10:10:03 (none) daemon.info dnsmasq-dhcp[651]: DHCPOFFER(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:10:04 (none) daemon.info dnsmasq-dhcp[651]: DHCPREQUEST(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:10:04 (none) daemon.info dnsmasq-dhcp[651]: DHCPACK(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:10:13 (none) daemon.info dnsmasq-dhcp[651]: DHCPDISCOVER(br0) ac:9e:17:e9:xx:xx 
Sep  9 10:10:13 (none) daemon.info dnsmasq-dhcp[651]: DHCPOFFER(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:10:13 (none) daemon.info dnsmasq-dhcp[651]: DHCPREQUEST(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:10:13 (none) daemon.info dnsmasq-dhcp[651]: DHCPACK(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:10:21 (none) daemon.info dnsmasq-dhcp[651]: DHCPRELEASE(br0) 192.168.1.56 ac:9e:17:e9:xx:xx 
Sep  9 10:12:02 (none) user.info kernel: device br0 left promiscuous mode

Is there a way to log/check what actually happened causing packages drop?
Why there's so many DHCP-related activity for a single node spanning over 5 minutes in the logs above? I see similar logs for other nodes in my network, too.

EDIT02:
I don't know if that matters, but that node 192.168.1.56 is an old RT-N18U working as a Media Bridge. Can this cause issues?

EDIT03:
I realized there's over 4 minutes difference in clocks between my PC and RT-N66U. PC has correct time while the router is lagging behind. Surprising, as the router settings seem correct:
1599644650292.png
 
Last edited:
Router AC68U
Firmware 44EA

Im missing AiDisk Manager. under USB Disk. When I click on AiDisk, im taken to an empty page.
 
Router AC68U
Firmware 44EA

Im missing AiDisk Manager. under USB Disk. When I click on AiDisk, im taken to an empty page.
I have never, ever used it but I checked it out to confirm that I also see a blank page where there seemingly should not be. 45D5, iOS 14 Safari
 
Works fine for me. Chrome on Windows.
Yeah, I posted my platform and browser because I suspect it’s at fault. I’ve since checked Safari 14 on macOS 11, same result with the blank page. Works properly on Safari 13.1.2 on macOS 10.15
 
Router AC68U
Firmware 44EA

Im missing AiDisk Manager. under USB Disk. When I click on AiDisk, im taken to an empty page.

I'm missing parts of Traffic Manager on Firefox but it only happens with firstparty cookie isolation enabled. Could that be the problem?
 
I was on 380.70 for a long time on my N66U. Recently I observed the router getting reset while my phone gets connected to the 5GHz network. Could it be a issue with the AC standard client connection causing problem? I have the phone for over a year but the issue is observed only recently.

Anyway, I moved to 374.43_44EAj9527 today and it is working good so far. I will continue to monitor the router for the coming days. Thanks John @john9527 for keeping this alive.
 
I have never, ever used it but I checked it out to confirm that I also see a blank page where there seemingly should not be. 45D5, iOS 14 Safari
Yeah, I posted my platform and browser because I suspect it’s at fault. I’ve since checked Safari 14 on macOS 11, same result with the blank page. Works properly on Safari 13.1.2 on macOS 10.15
I'm missing parts of Traffic Manager on Firefox but it only happens with firstparty cookie isolation enabled. Could that be the problem?

I was able to figure out the issue.
If I disable the Media Server, by clicking on the USB Drive Icon on main page, which takes me to whole different menu, then AiDisk Manager comes back.
 
Today I noticed something, I am on 3.0.0.4.374.43_44EAj9527. Yesterday my phone was connected to the 5GHz guest network (with vlan) and I enabled the wireless scheduler for the 5GHz band to be off at night. This morning I noticed that my phone had no connection. Manually trying both bands had no success, the phone tried it but there was no connection. I then disabled the wireless scheduler and did a reboot of the asus and the phone could connect. Any thoughts?
 
Easy question for anyone familiar with nvram show|grep commands...
Every time I execute an nvram show|grep command on the router the results contain the size and space left for nvram-
size: xxxxx bytes (xxxxx left)

Is there a way to execute an nvram show|grep command without showing this?
 
Easy question for anyone familiar with nvram show|grep commands...
Every time I execute an nvram show|grep command on the router the results contain the size and space left for nvram-
size: xxxxx bytes (xxxxx left)

Is there a way to execute an nvram show|grep command without showing this?
Fortunately the unwanted "size:" line is being sent to stderr so it can be removed like so:
Code:
nvram show 2>/dev/null | grep wan0_hwaddr
 
I was on 380.70 for a long time on my N66U. Recently I observed the router getting reset while my phone gets connected to the 5GHz network. Could it be a issue with the AC standard client connection causing problem? I have the phone for over a year but the issue is observed only recently.
Quoting myself just to update about this issue. The reset was still happening and upon further googling, it seems many have reported the issue with the OnePlus 6 phone and N66U combination causing the router to reset when connected in either wireless bands.

Solution suggested is to disable the NAT acceleration and seems to have worked for many. I have also tried and monitoring now. Though I am not very convinced with the solution because the issue cropped up only very recently though I have been using this phone for last 1.5 years.

Before trying this out, i tried disabling the MAC randomization in the Phone, but still the router was resetting.

Question: Is there any way to debug the router logs to see what is causing this issue? I don't see anything in the system logs before the reset happened.

PS. This issue has nothing to do with this build, but seems affecting all firmwares.
 
Hi all,
I've been using john's fork and lurking this forum for awhile now but finally decided to get an account.
The discussion on this thread is great and everyone seems so helpful.

As for my (minor, but possibly important to some such as myself) contribution, I have discovered that recent versions of Linux are using samba 4.11+ which defaults to SMB2 as the minimum protocol.
Samba does not appear to allow decoupling NetBIOS from the SMB version like Windows 10 does.
This has the effect of breaking the Network Map -> Client Status screen in the sense that Linux PCs receive the "other" icon rather the "PC" icon (even with samba and winbind installed and firewall set correctly).

The fix/workaround I have found is relatively easy:
On the affected client, under /etc/samba/smb.conf place "server min protocol = NT1" under the "workgroup = WORKGROUP" line, save, then reboot.
This will restore NetBIOS (and SMB1 :/) functionality to make the PC icon appear on the Client List once again and should not interfere with connecting to Windows 10 machines.
Connecting from Windows 10 to Linux may be affected but that was not the case on my network; based on distro/version, YMMV.

Ultimately, it may be better for someone more knowledgeable than myself to find a way to make the Client List use a newer discovery method such as avahi/wsdd.
As you are all likely to be aware, re-enabling SMB1 may introduce a security risk in some environments.
I found I can mitigate this somewhat by adding "restrict anonymous = 2" under the "server min protocol = NT1" line.
 
Last edited:
Hi

is it possible to update vpn client to "cipher CHACHA20-POLY1305" or must openvpn need to update first?
@john9527
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top