What's new

[Release] Asuswrt-Merlin 380.65 is now available

  • 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!

Hi RMerlin,

I'm having issue with Entware-NG Python3 package 'requests' where it thrown an exception,
('Connection aborted.', OSError(89, 'Function not implemented'))

Yes, the problem should be on either the Entware-NG, Python3 package for it or the 'requests' package. However, when I posted this issue in Entware-NG at https://github.com/Entware-ng/Entware-ng/issues/581, this is his reply,
"Probably it is related to the old kernel of your firmware. I have tested it on a modern router running 3.x kernel with entware-3x. No error"

I've also posted it at 'request' https://github.com/kennethreitz/requests/issues/3906 and so far, no reply yet.

Any help on this?
 
Hi RMerlin,

I'm having issue with Entware-NG Python3 package 'requests' where it thrown an exception,
('Connection aborted.', OSError(89, 'Function not implemented'))

Yes, the problem should be on either the Entware-NG, Python3 package for it or the 'requests' package. However, when I posted this issue in Entware-NG at https://github.com/Entware-ng/Entware-ng/issues/581, this is his reply,
"Probably it is related to the old kernel of your firmware. I have tested it on a modern router running 3.x kernel with entware-3x. No error"

I've also posted it at 'request' https://github.com/kennethreitz/requests/issues/3906 and so far, no reply yet.

Any help on this?

I received replies from Lukasa at https://github.com/kennethreitz/requests/issues/3906. Quote,
Requests, when using PyOpenSSL, needs to implement some logic to do non-blocking I/O. We do this by looking for the best available selector on the platform and using that. We check for the available selectors by looking at which names are defined in the select namespace.


It seems that this Python distribution is defining the epoll selector, but cannot actually use it. This is probably because the underlying OS defines the epoll syscall but cannot actually use it, and returns ENOSYS.

The following Python script shows that the Epoll is reported as available but when called, returned an exception,
Code:
Python 3.6.0 (default, Feb 17 2017, 13:43:51)
GCC 5.4.0 on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import select
>>> print( select.epoll )
<class 'select.epoll'>
>>> select.epoll()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 89] Function not implemented
 
Hi RMerlin,

Is there any special reason for this line in dnsmasq.conf:
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600

not have ra-names on it? so we could hopefully make the router knows ipv6 by host in the local domain? (ipv6 surely)
 
Hi RMerlin,

Is there any special reason for this line in dnsmasq.conf:
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600

not have ra-names on it? so we could hopefully make the router knows ipv6 by host in the local domain? (ipv6 surely)

Ask Asus. I don't know anything about IPv6 RA, it's not my code.
 
RT-AC87U as Main router. After restart, 5 GHz will not work for AC devices. Such as iPhone 7 (Global model with Intel modem). It has problem from Merlin 380.64-65.
 
RT-AC87U as Main router. After restart, 5 GHz will not work for AC devices. Such as iPhone 7 (Global model with Intel modem). It has problem from Merlin 380.64-65.

Works fine with my all my apple devices (including iPhone 7, MacBook pro, iPad Pro) and non-apple devices. Suggest you factory reset and setup settings manually. Should also verify that your Quantenna firmware is 37.4.0.56 under Tools->Sysinfo.
 
Hi in the last few builder there seem to be a issue with the Traffic Analyzer - Statistic
Traffic history location = Custom Location
Save frequency = Every 1 Hour
Save history location = /mnt/SYSTEM/Logs (Front USB port)

Seem be failing to write data on USB stick after about 3 to 4 days and of one core has High CPU usage

I have a similar problem like the above, but the difference is that I have portable two USB hard disk drives plugged into both USB 2.0 and 3.0 ports. Just yesterday, the Western Digital (WD) HDD can be read from, but any time I try to write something to the WD, Windows 7 Explorer would lock up and I see that core 1 CPU of the router is at 100%, until I end the write transfer, then would the core 1 CPU drop back down to 0%. I rebooted the Asus RT-AC68U router. Still wouldn't solve it. I had WD scanned using the built in health scanner on the front page of the router web screen. The router failed to fix allocation problem, so I took the WD and plugged it into my Windows computer, scanned the WD and fixed some errors. I replugged it in and it was okay to write to the WD HDD again, no more core 1 CPU running at a high 100% utilization. I then noticed my other USB portable HDD, Seagate, after scanning with the built in health scanner, the Seagate developed a red ring around the USB icon. I took the Seagate and scanned it from my Windows computer and it was fine. Still, the router thinks that the Seagate has a problem after being plugged back in.

Fast forward to today, about 16 hours later, both cores 1 and 2 CPUs are running at 100%, slowed down my network response, and crashed my Wi-Fi such that another device trying to log into the Wi-Fi, failed to connect. I decided to downgrade the firmware from 380.65 back down to 380.64_2. So far, everything works fine. One thing I like to note is that I have not done a full default wipe/reset for the last few firmware upgrades. I'll probably try to upgrade the firmware back to 380.65 with a reset and configure everything back. But as of right now, it seems that 380.65 has an issue with USB writing similar to the poster above.

Update 3/7/17: After downgrading to 380.64_2, read and writing to the Seagate and WD HDDs were fine. But when I used MiBox (Android TV box) with Kodi v17 to access Seagate HDD, something was wrong. Kodi wasn't able to read from the Seagate HDD. I rebooted the router many times because CPU utilization shot up to 100% and made the router unresponsive, and also Kodi was unresponsive, so the MiBox was restarted many times. I decided to test the Seagate HDD (model # STEA4000400, 4 TB USB 3.0 portable HDD) with SeaTools for Windows. I did the basic test, such as Short Drive Self Test. It passed. I then moved onto Short Generic. That's when it failed constantly. The Seagate failed at the inner test. I checked the warranty and I have about 3 months of warranty left on the 1 year warranty. BTW, the Seagate HDD was assembled and product of China. I don't know if country plays a role, but just throwing it out there for the record of where the Seagate HDD came from. This will probably be my first and last purchase of Seagate HDD. They're notorious for failures, especially some reviews have already noted this type of model drive is questionable in reliability. I've had many WD HDDs that lasted much longer, even though 1 died out of the many I have. I will update the router back to 380.65 and observe if the router's CPU is abnormally very high. I highly suspect that it was because the Seagate HDD was failing and causing the router to get locked up communicating with a dying HDD. BTW, WD HDD (My Passport 2 TB USB 3.0) tested fine through the two tests that I've put the Seagate HDD through. System log shows a lot of this:
Mar 7 03:00:47 kernel: device blocksize: 512
Mar 7 03:00:47 kernel: __find_get_block_slow() failed. block=4841037888, b_blocknr=546070592
Mar 7 03:00:47 kernel: b_state=0x00000020, b_size=512
Mar 7 03:00:47 kernel: device blocksize: 512
Mar 7 03:00:47 kernel: __find_get_block_slow() failed. block=4841037888, b_blocknr=546070592
Mar 7 03:00:47 kernel: b_state=0x00000020, b_size=512
Mar 7 03:00:47 kernel: device blocksize: 512
Mar 7 03:00:47 kernel: __find_get_block_slow() failed. block=4841037888, b_blocknr=546070592

Update 3/13/17: Looks like the Seagate HDD was the culprit, the router is running just fine with 380.65. I used the SeaTools and ran through the "Fix All Long", it finished with a "Pass" (success), then I run "Short Generic" test, and it failed. So off for warranty processing it is for the Seagate HDD.

Update 3/18/2017: Looks like the WD HDD also exhibited similar situation where 1 of the 2 core CPU was near 100% (it was hovering around 80%) when I tried to transfer files to it over the wireless network. I decided to scan it with WD Drive Utilities, it passed all checks (Drive Status Check, Quick Drive Test, and Complete Drive Test). The Complete Drive Test is basically fix any bad sectors while testing. I viewed previous Chkdsk results from within Windows and I see that WD HDD lost one allocation unit (4096 KB) when I ran a Chkdsk in 2016. Jumping back to the Seagate HDD, I didn't process the Seagate HDD for warranty given how Seagate explained on their website that they would just do a low level format and fix bad sectors, when I have access to fixing bad sectors tool. I ran SeaTools and chose Fix All Long (also fixes bad sectors). The Seagate HDD passed. Of course, it failed the Short Generic Test again after that. So I now see that the Short Generic Test is unreliable. I also compared Chkdsk results and I see that Seagate lost over 1,000 allocation units. Both drives are now accessible and do not create anymore surge in CPU usage on the Asus router and transfer data fine. It seems that since both USB HDD had bad sectors, I suspect that power must have disrupted and cause the HDD to shutdown improperly. Therefore, I would like to conclude that if your Asus router has a constant surge in CPU usage and there is a USB drive attached to the router, run Chkdsk or similar utility to scan for bad sectors and fix them.
 
Last edited:
I've had good uptime with 380.65, but on my RT-AC3100 I am starting to have problems with Traffic Analyzer and incoming traffic. It just stopped, and stays at 0 when there's TONS of traffic passing.

Not sure what's going on. Reboots do not help, and neither does reflashing and setting up from scratch.
 
@Merlin
I'm not sure if it's just my router (Asus RT-AC87R), but since the upgrade TOR is no longer working. Is there something I should be correcting? Is anybody else experiencing this issue?
 
What is the issue?
 
RMerlin,

Traffic Analyzer is hanging after a few days and consuming 100% of one core indefinitely. Occurred twice in 15 days. Had to reboot.
 
RMerlin,

Traffic Analyzer is hanging after a few days and consuming 100% of one core indefinitely. Occurred twice in 15 days. Had to reboot.

Delete the /jffs/traffic.db database to reset it.
 
I've got a new and interesting bug with 380.65 on both an RT-N66 and an RT-AC68. Specifically, when I upgraded from 380.62_1 to 380.65 our VOIP (FreePBX) phone system quit being able to receive inbound calls. Outbound still worked fine, but all inbound SIP INIT's were being somehow blocked by the router. I tried all possible settings of Disabled/Enabled/Enabled+NAT Helper under WAN NAT Passthrough and it made no difference whatsoever with regards to receiving inbound calls. No changes were made to the FreePBX box. Initially, I had thought it had something to do with our SIP trunking service, but, after a bit more investigation, it became apparent that they were sending the SIP INIT properly, but it was never making it through the router. So, I downgraded back to 380.62_1 and everything immediately started working correctly again. I haven't (yet) tried versions between 62_1 and 65 to see exactly when the NAT Passthrough behavior changed.

Any ideas as to what might have changed?

Thanks!
 
I've got a new and interesting bug with 380.65 on both an RT-N66 and an RT-AC68. Specifically, when I upgraded from 380.62_1 to 380.65 our VOIP (FreePBX) phone system quit being able to receive inbound calls. Outbound still worked fine, but all inbound SIP INIT's were being somehow blocked by the router. I tried all possible settings of Disabled/Enabled/Enabled+NAT Helper under WAN NAT Passthrough and it made no difference whatsoever with regards to receiving inbound calls. No changes were made to the FreePBX box. Initially, I had thought it had something to do with our SIP trunking service, but, after a bit more investigation, it became apparent that they were sending the SIP INIT properly, but it was never making it through the router. So, I downgraded back to 380.62_1 and everything immediately started working correctly again. I haven't (yet) tried versions between 62_1 and 65 to see exactly when the NAT Passthrough behavior changed.

Any ideas as to what might have changed?

Thanks!
You have two choices

1. Do incremental firmware upgrades, move to .63, 64 etc, test with each upgrade to ensure SIP functionality still works
2. Do another upgrade to .65 but reset your router to default and configure from scratch and test. Do not do a restore configuration.

Good luck!!
 
380.65_2 was uploaded, fixing two CVE security issues and two minor webui bugs.

Code:
   - FIXED: CVE-2017-6549 (implemented temporary workaround,
            until a proper fix from Asus)
   - FIXED: CVE-2017-6548 (backport from GPL 7266)
   - FIXED: WOL page fails to load if adding a client with a
            quote in its name.
   - FIXED: Couldn't add a DHCP reservation client if its name
            contained a quote
 
You have two choices

1. Do incremental firmware upgrades, move to .63, 64 etc, test with each upgrade to ensure SIP functionality still works
2. Do another upgrade to .65 but reset your router to default and configure from scratch and test. Do not do a restore configuration.

Good luck!!

A full reset was the first thing I tried following the upgrade -- it was a no go in terms of making any difference.

I will check 63 and 64 over the weekend, but after perusing the forum a bit more, I have found two other threads with regards to SIP Passthrough/WiFi Calling/etc. problems that seem to be describing the exact same problem I am seeing. It looks like the issue started sometime around Nov/Dec 2016 and, based on comments in one thread, it sounds like the problem first showed up in the original Asus firmwares. In other words, it sounds like there is an issue in the newer Asus code bases rather than it being anything Merlin specific.


On a side note, the entire reason I was upgrading both of my locations to 65 was to see if I could get the network services filter to actually work to totally block internet access to specific device via the GUI. With 62_1 my luck was totally nil -- I could add the devices IP address, TCP and UDP, and port 1:65535 and it didn't actually block ANYTHING. Does anyone know if this works better in 65? If not, I'll just do it the hard way with an iptables script.
 
Last edited:
380.65_2 was uploaded, fixing two CVE security issues and two minor webui bugs.

Code:
   - FIXED: CVE-2017-6549 (implemented temporary workaround,
            until a proper fix from Asus)
   - FIXED: CVE-2017-6548 (backport from GPL 7266)
   - FIXED: WOL page fails to load if adding a client with a
            quote in its name.
   - FIXED: Couldn't add a DHCP reservation client if its name
            contained a quote

I notice when am doing speedtest and looking at the CPU via GUI, core 1 goes up to 30-37%, core 2 10-12% However if I monitor via SSH Top CPU shows at 0.0% , idle goes to 87% IRQ 12.0% is this normal behavior to show such a difference between GUI and CL.
 
I have found a possible bug and this could help other that have issue with QoS.
I have been using Merlin firmware for a while just with basic setting. I like it very much.
Since the last few updates, my Ethernet internet speed drops significantly when I have the QoS on. The wireless speed remains very fast. My download speed is about 34 Mb/s and my Upload is 0.9 Mb/s. I have entered these in their appropriate cells but when I did the download speed test, it maxed out suspiciously to 0.9Mb/s.
I have decided to reverse the entry and to my surprise the download speed maxed out at 32 Mb/s.
I believe the code could have been reversed.
 
380.65_2 was uploaded, fixing two CVE security issues and two minor webui bugs.

Code:
   - FIXED: CVE-2017-6549 (implemented temporary workaround,
            until a proper fix from Asus)
   - FIXED: CVE-2017-6548 (backport from GPL 7266)
   - FIXED: WOL page fails to load if adding a client with a
            quote in its name.
   - FIXED: Couldn't add a DHCP reservation client if its name
            contained a quote

I tried loading 360.65_2 onto my AC3200 and noticed severe webui slowdowns and even timeouts trying to save settings or access other parts of the UI. Internet access was also affected. It would work again after a minute and then start doing it again. Did the proper flash procedure (Upload new firmware...wait 4 mins...manually reset router...Factory Defaults). Tried 380.65_2 a second time with the same results. Went back to 380.65 and all is fine.
 
Last edited:
I have decided to reverse the entry and to my surprise the download speed maxed out at 32 Mb/s.
I believe the code could have been reversed.

Despite popular belief, this does NOT fix the problem. The values are not inverted, you can see for yourself by putting an even lower value in the download field - your upload won't use that lower value.

It's a low-level architectural problem.
 

Sign Up For SNBForums Daily Digest

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