Asuswrt-Merlin 374.41 is out

[jim769]

I can't do much concerning IPv6 because I'm simply not an expert in it. However I have a couple of user submitted patches that will go in with the next release, it might help with at least some of the issues people are experiencing with IPv6. Again, I have no way of testing it - my HE tunnel always worked fine for me.

I have comcast and have not really had any v6 issues with your latest build.Seems to work fine at least for me. I also see you found a fix for the 5Ghz led that is excellent can i ask what had to be changed to make it stable for .42

 

[RMerlin]

I have comcast and have not really had any v6 issues with your latest build.Seems to work fine at least for me. I also see you found a fix for the 5Ghz led that is excellent can i ask what had to be changed to make it stable for .42

Since I was already writing the same values to the chip registers that Asus was, then I had to assume something else was at play, so I had to start the investigation from the beginning and attack it from a different angle.

It turns out that on the RT-AC68U, Asus doesn't let the hardware/wireless driver handle the flashing of the 5 GHz LED. Instead, they have the watchdog turning the LED off and on through software every few milliseconds as needed to generate the fast blinking on activity.

To achieve this, the watchdog calls the led_control() function. In the stock firmware, that function merely writes to the hardware to turn the LED off or on. In my FW, since Stealth Mode also uses that same function, I was also writing to the chip the behaviour the built-in LED flashing should use (off, or on-blinking-on-activity).

So basically, each time the software-based blinking was trying to turn the LED off or on for a few ms, the router was also disabling/enabling the hardware-based blinking function. So sometimes due to timing issues, the LED would stay on or stay off longer than expected, as the hardware was trying to do its own blinking on top of the software-based blinking done by Asus.

To resolve the issue, I had first to modify the way led_control() worked so it would no longer by default manipulate the led behaviour at the hardware level, and I had to add a special case so both Stealth Mode and user-created scripts would still work properly (disabling/enabling the LED behaviour).

No need to say that tracking down this kind of issue isn't a 5 minutes thing...

 

[jim769]

Way above my head Merlin, all i can say is thank you for taking the time to figure it out. And i am looking forward to the 42 build. Will you start 42 as a beta or will it be a final release ? I guess you truly are a Wizard !!!

 

[Raiu]

Since I was already writing the same values to the chip registers that Asus was, then I had to assume something else was at play, so I had to start the investigation from the beginning and attack it from a different angle.

It turns out that on the RT-AC68U, Asus doesn't let the hardware/wireless driver handle the flashing of the 5 GHz LED. Instead, they have the watchdog turning the LED off and on through software every few milliseconds as needed to generate the fast blinking on activity.

To achieve this, the watchdog calls the led_control() function. In the stock firmware, that function merely writes to the hardware to turn the LED off or on. In my FW, since Stealth Mode also uses that same function, I was also writing to the chip the behaviour the built-in LED flashing should use (off, or on-blinking-on-activity).

So basically, each time the software-based blinking was trying to turn the LED off or on for a few ms, the router was also disabling/enabling the hardware-based blinking function. So sometimes due to timing issues, the LED would stay on or stay off longer than expected, as the hardware was trying to do its own blinking on top of the software-based blinking done by Asus.

To resolve the issue, I had first to modify the way led_control() worked so it would no longer by default manipulate the led behaviour at the hardware level, and I had to add a special case so both Stealth Mode and user-created scripts would still work properly (disabling/enabling the LED behaviour).

No need to say that tracking down this kind of issue isn't a 5 minutes thing...

That's some crazy debugging man! I respect your work, thank you!

 

[BMWDude49120]

First of all, thank you so much for all the work you do on this firmware. I truly appreciate it, and I am sure all would agree with me.

I wanted to report that I have native IPV6 from Comcast and have had absolutely no problems with 374.41 on my RT-AC66U. I no longer get the "neighbor overflow" message flooding my log and I am able to consistently get and keep an IPV6 address assignment.

With past firmware, a router reboot often ended up with the router getting no IPV6 address assignment from Comcast's DHCP server. I would usually have to reboot the modem and router a few times to get an address. No longer, however; 374.41 cured that. Sometimes in the past, the router would just lose its IPV6 address assignment and I would have to do the above reboot dance to get another address. Again, 374.41 cured this, as well.

Thanks again!

 

[miodzicho]

RT-AC68U - 374.41 With enabled IPv6 log window is flooded with :

radvd[2195]: DNSSL suffix (here my local domain name) received on br0 from fe80::xxxx:xxxx:xxxx:xxxx is not advertised by us

Is it anything to be worry, need to be corrected or changed in configuration ?

 

[RMerlin]

RT-AC68U - 374.41 With enabled IPv6 log window is flooded with :

radvd[2195]: DNSSL suffix (here my local domain name) received on br0 from fe80::xxxx:xxxx:xxxx:xxxx is not advertised by us

Is it anything to be worry, need to be corrected or changed in configuration ?

It sounds as if you have another router on your LAN trying to advertise this network.

 

[miodzicho]

It sounds as if you have another router on your LAN trying to advertise this network.

Oh well..you right, was pfsense on esxi running...

 

[dgcruzing]

Rt-n56u

can i flash this to a RT-N56U?

 

[GoNz0]

can i flash this to a RT-N56U?

if the download link has the file in the n56u folder you can.

 

[RMerlin]

can i flash this to a RT-N56U?

No. Please refer to the list of supported devices in the sticky thread.

 

[pfuller88]

Traffic Manager

I understand there are issues with the Traffic Manager, specifcally not reporting data correctly. I set my data to my USB3 thumb drive, I get the below lines in my system log every 10 minutes. I have reset the logging files several times via the GUI. It works for a short period then the below starts.

I am on the latest Merlin build, AC68U. I have the log by IP checked.

Any ideas



May 11 12:18:13 cstats[28594]: Problem loading /mnt/PNY128GB/TrafficLog/tomato_cstats_d850e6d0c858.gz. Still trying...

May 11 12:33:13 cstats[28594]: Problem loading /mnt/PNY128GB/TrafficLog/tomato_cstats_d850e6d0c858.gz. Still trying..

 

[RMerlin]

I understand there are issues with the Traffic Manager, specifcally not reporting data correctly. I set my data to my USB3 thumb drive, I get the below lines in my system log every 10 minutes. I have reset the logging files several times via the GUI. It works for a short period then the below starts.

I am on the latest Merlin build, AC68U. I have the log by IP checked.

Any ideas



May 11 12:18:13 cstats[28594]: Problem loading /mnt/PNY128GB/TrafficLog/tomato_cstats_d850e6d0c858.gz. Still trying...

May 11 12:33:13 cstats[28594]: Problem loading /mnt/PNY128GB/TrafficLog/tomato_cstats_d850e6d0c858.gz. Still trying..

cstats is for IPTraffic (per device monitoring), not for the regular Traffic Manager (which is the one having issues, only with PPPoE connections).

Make sure you did create a database for IPTraffic - it's a separate database from the regular traffic monitoring.

 

[NoSync]

N66u - Merlin's 374.41

I cannot change frequency on the 2.4GHz band. It is currently set to 6, but WiFi Analyzer (Android app on my Nexus 7 2013) shows Ch1. When I change channel in the GUI, it does not change in Analyzer.

UPDATE:- The channel only changes if the mode is set to 20MHz. If set to 40 MHz, channel defaults to 1. Assuming that the 5GHz channel showing when one hovers the cursor over the green wireless symbol is correct, the router is also stuck on channel 36 - nothing I can do changes it.

I only noticed this as I am having probs getting 5GHz to work. Don't know if it's the router, but Amazon sending a replacement.

On 376.45 (RT-N66U, regulation mode set to IT through a CFE reflash) I had the same problem and I fixed it by disabling IGMP Snooping under Wireless -> Professional tab. I kinda miss the link, but enablng the option consistently gets my 5G channel stuck to 36/20MHz regardless of the other settings.