Asus RT87 - Merlin

[initrd]

I think you are confusing things here.

Asuswrt is the firmware developed by Asus - this is what you have on your router.
Asuswrt-Merlin (there is no MerlinWRT) is a third party firmware intended for Asus routers. At the time I'm writing this there is still no public release of Asuswrt-Merlin for the RT-AC87U.

Oops sorry for confusing you... yep aware that I am running AsusWRT

Is anyone one else facing the problem I mentioned ?

 

[initrd]

Now that's odd. Two on 2044, and you get different results with that LAN port.

If others can also post their results (either with 1779 or 2044) that'd be appreciated.

Firmware Version:3.0.0.4.376_2044

admin@RT-AC87R:/tmp/home/root# et port_status all
Port Link Speed(Mbps) Duplex
---- ---- ----------- ------

0 Up 1000 Full
1 Up 100 Full
2 Down
3 Up 1000 Full
4 Down
admin@RT-AC87R:/tmp/home/root#

Lan 1 & 2 & 4 connected

 

[scottts]

2044 Firmware
All LAN ports in use

0 Up 1000 Full
1 Up 1000 Full
2 Up 100 Full <-- Slower powerline adapter
3 Up 1000 Full
4 Down

 

[usmarine0622]

Merlin,

I returned the router I had because the 5Hz band kept going out. Here are the results of the new one I just picked up Firmware 20444

0 Up 1000 Full
1 Down
2 Down
3 Down
4 Down

I old one showed port 1 as up, this one shows it as down

 

[lilstone87]

Merlin,

I returned the router I had because the 5Hz band kept going out. Here are the results of the new one I just picked up Firmware 20444

0 Up 1000 Full
1 Down
2 Down
3 Down
4 Down

I old one showed port 1 as up, this one shows it as down

I notice 5Ghz band acting funny last night for me as well, as my one 5GHz bridge would be green for a couple minutes then suddenly go red, and offline. I had my 5GHz band using channel 36, with 80mhz. I changed it to channel 48, and 40mhz. So far its been staying good, but I wonder if there is a 80mhz issue on the 5ghz band. Because I have used channel 36 on my previous routers without ever having an issue, and it was the better channel. Because I have a wireless headset that uses the 5.8ghz range, so I try to stay away from the higher set of channel's.

 

[lilstone87]

As for this port status Merlin is trying to find more information on. Would it be smart when testing this to only have lan port 1 being used? Because I wonder after seeing my result's, if it's improperly reporting port status. As mine, and at least one others results here show a port being down on a active port being used, that's not port 1. Because on my test, lan port 1, and 3 were active. Yet my results showed both port 1, and 3 as down.

 

[RMerlin]

As for this port status Merlin is trying to find more information on. Would it be smart when testing this to only have lan port 1 being used? Because I wonder after seeing my result's, if it's improperly reporting port status. As mine, and at least one others results here show a port being down on a active port being used, that's not port 1. Because on my test, lan port 1, and 3 were active. Yet my results showed both port 1, and 3 as down.

No, having test results about the other ports as well is also good data. I asked about port 1 because that was the only port showing odd results here, and it also exhibited odd behaviour in Recovery Mode (side note: if using Firmware Recovery with this router, make sure you use port 2 or 3. Either 1 or 4 wouldn't work at all - I couldn't tell which one, that was back when I had an engineering sample without a case.)

At this point it seems pretty clear that the port status report is vastly unreliable, and the issue exists in both robocfg (which I had updated to support the AC87U) and Broadcom's own et tool. I suspect it might be related to this switch running in RGMII mode. So for now I will just disable that functionality in my firmware, and revisit this in the future after a few updates from Asus.

 

[usmarine0622]

I notice 5Ghz band acting funny last night for me as well, as my one 5GHz bridge would be green for a couple minutes then suddenly go red, and offline. I had my 5GHz band using channel 36, with 80mhz. I changed it to channel 48, and 40mhz. So far its been staying good, but I wonder if there is a 80mhz issue on the 5ghz band. Because I have used channel 36 on my previous routers without ever having an issue, and it was the better channel. Because I have a wireless headset that uses the 5.8ghz range, so I try to stay away from the higher set of channel's.

I'll see if I have the issue with this one, if it comes back I'll change it to 40.

 

[usmarine0622]

I'll see if I have the issue with this one, if it comes back I'll change it to 40.

Changed it to 40 and still having issues

 

[jim769]

This is actually an interesting topic. Asus's solution in their new firmware releases has been to modify the Linux Kernel so the error message does not appear in Syslog's default loglevel.

My solution might not be ideal, but I think it's still more optimal to drop those packets than to keep processing them throughout the whole networking stack, so yes, for the time being my current fix will remain there, as I haven't heard of any negative side-effect from it (and just in case, I did leave an nvram setting that allows disabling it).

Does this mean the latest Asus build 3.0.0.4.376.1663 will not log the comcast overflow issue like 5656 did ? Or did Asus just fix it for the new 87U ?

 

[RMerlin]

Does this mean the latest Asus build 3.0.0.4.376.1663 will not log the comcast overflow issue like 5656 did ? Or did Asus just fix it for the new 87U ?

I didn't notice starting with which FW version they did that, nor if they applied it to both the MIPS and ARM kernel or just one of the two.

Either way, I think it's just brushing the real issue under the carpet rather than addressing it. Possible (and I think it's also probable) that this is something that is more in Comcast's hands than Asus', so Asus did the only thing they could do: stop filling up logs with these messages. The amount of generated traffic for starter seem quite excessive to me.

 

[jim769]

I didn't notice starting with which FW version they did that, nor if they applied it to both the MIPS and ARM kernel or just one of the two.

Either way, I think it's just brushing the real issue under the carpet rather than addressing it. Possible (and I think it's also probable) that this is something that is more in Comcast's hands than Asus', so Asus did the only thing they could do: stop filling up logs with these messages. The amount of generated traffic for starter seem quite excessive to me.

100% agree that this is a comcast issue but as said before they ask for information from people we give them the info they want and then never hear anything back from there v6 expert. But i know for sure as far as the 68U the 5656 firmware still logs the error.

 

[usmarine0622]

Hey Merlin,

Have you noticed that port forwarding doesn't work when inside Lan during your testing. The only way I can get it to work is the disable NAT acceleration. The same thing happened when the AC68U was released and it took them awhile to fix it. It works fine outside lan with NAT acceleration on.

 

[RMerlin]

Hey Merlin,

Have you noticed that port forwarding doesn't work when inside Lan during your testing. The only way I can get it to work is the disable NAT acceleration. The same thing happened when the AC68U was released and it took them awhile to fix it. It works fine outside lan with NAT acceleration on.

NAT loopback works fine for me with HW acceleration enabled.

Anyway, locking this thread, since not only it doesn't belong in this sub-forum, but it's also redundant.