What's new

Asuswrt-Merlin 3.0.0.4.354.28 Beta 1

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

Status
Not open for further replies.
THanks. I rebooted and the process list looks much the same. I just went back to the older beta, since it did the same thing but took about 4 days for the slowdown to occur.

I am guessing that one of the closed source pieces that you updated might be causing a problem ???? I don't know.

THanks

I've seen a few reports here and there from people also experiencing performance degradation over time, with various firmware versions (not just the newer 4.3xx builds, but also the previous 4.2xx builds), especially with the RT-AC66U. Not all could share the same cause however, as there can be many reasons for this to occur. What router model do you have?

In your case I don't think it's related to running processes, unless you see your free RAM abnormally low when the issue start to occur. You could monitor that as well as CPU usage through the Sysinfo page next time you start experiencing wifi performance issues. But since the issue seems to occur specifically on wifi, I suspect it's more related to the wifi driver or settings than to the running processes.

One temporary workaround you could do is schedule a nightly task that would restart the wireless service in the middle of the night (probably no need to restart the whole router). Not a real solution, but it might at least help in the mean time.
 
I've seen a few reports here and there from people also experiencing performance degradation over time, with various firmware versions (not just the newer 4.3xx builds, but also the previous 4.2xx builds), especially with the RT-AC66U. Not all could share the same cause however, as there can be many reasons for this to occur. What router model do you have?

In your case I don't think it's related to running processes, unless you see your free RAM abnormally low when the issue start to occur. You could monitor that as well as CPU usage through the Sysinfo page next time you start experiencing wifi performance issues. But since the issue seems to occur specifically on wifi, I suspect it's more related to the wifi driver or settings than to the running processes.

One temporary workaround you could do is schedule a nightly task that would restart the wireless service in the middle of the night (probably no need to restart the whole router). Not a real solution, but it might at least help in the mean time.

I have a RT-AC66U. i have tried resetting just the radios, but that doesn't seem to fix the issue. Right now i have gone back to .27, i have also turned off the per ip traffic monitoring. (I don't know)

i was looking at the top output before and after the issue, and the CPU usage seemed a tiny bit higher, but not unusually so.

the memory usage also seemed a bit higher.

I am okay rebooting the router every 3 days or so, but every day is kind of silly.

THanks again for all your work, i know that this is probably an issue in the closed source asus code, since nobody can ever look at it.

Thanks.
 
I have a RT-AC66U.

I remember seeing quite a few reports of that particular issue in the RT-AC66U forums, so maybe the issue is specific to that platform.

the memory usage also seemed a bit higher.

Slightly less free memory is normal, as some of it gets used for cacheing over time. Just as long it doesn't eventually reach near 0, it should be fine.

THanks again for all your work, i know that this is probably an issue in the closed source asus code, since nobody can ever look at it.

Thanks.

I suspect it might also possibly be interface-specific. My laptop always connects at 300 Mbps here, with an Intel card. However, I do use a fixed channel in my settings, and my router usually gets rebooted once or twice a week as I need to reflash it.
 
[...]
One temporary workaround you could do is schedule a nightly task that would restart the wireless service in the middle of the night (probably no need to restart the whole router). Not a real solution, but it might at least help in the mean time.

Just to be curious, can you explain how to do that?
 
I remember seeing quite a few reports of that particular issue in the RT-AC66U forums, so maybe the issue is specific to that platform.



Slightly less free memory is normal, as some of it gets used for cacheing over time. Just as long it doesn't eventually reach near 0, it should be fine.



I suspect it might also possibly be interface-specific. My laptop always connects at 300 Mbps here, with an Intel card. However, I do use a fixed channel in my settings, and my router usually gets rebooted once or twice a week as I need to reflash it.


I have an iMac in a room that connects at 270 Mbps (never moves) when i get this issue, it drops down to say 81.

My laptop (MacBook pro Retina) connects at 216 in my living room, and when i move to the office its at 450 Mbps (just like you would expect)

when the bad state happens, its 81, and then 160 or something close to that in the office.

i would switch back to the non beta version, but that version my MacBOOK Pro has issues reconnecting after waking from sleep. I think that this issue is a macosx bug (it seems that its fixed in an upcoming osx release (10.9))

i am thinking that this drop off is worse in the .28 beta then in .27. You dug out more binary blobs from the released version, i am guessing that its one of those.

The driver is the same in .27 and .28 so that can't be the problem. it does seem that it should be something else????

Thanks.
 
Just to be curious, can you explain how to do that?

You can just do that by having the radio turn off in "Wireless" -> "Professional" then look for

"Enable wireless scheduler"

There are two times there (date range) where the radio should be on.
 
You can just do that by having the radio turn off in "Wireless" -> "Professional" then look for

"Enable wireless scheduler"

There are two times there (date range) where the radio should be on.

That's one way to do it. It can also be done through a Cron job (and this method might do a more thorough job at restarting wireless).

service-start script:

Code:
#!/bin/sh
cru a RestartWifi " 0 4 * * * /sbin/service restart_wireless"

That would create a scheduled job at boot time that would entirely restart the wireless services at 4 am every night.
 
The driver is the same in .27 and .28 so that can't be the problem. it does seem that it should be something else????

Thanks.

Since both computers are Mac, it's possible that they both use the same type of wireless NIC. Do you have any other wifi device by any chance? Just curious to see how it would behave when you're in a situation where neither Mac will connect properly.

Also do test the low-numbered vs high-numbered channel theory to see if one of these ranges is more stable than the other one.
 
Since both computers are Mac, it's possible that they both use the same type of wireless NIC. Do you have any other wifi device by any chance? Just curious to see how it would behave when you're in a situation where neither Mac will connect properly.

Also do test the low-numbered vs high-numbered channel theory to see if one of these ranges is more stable than the other one.

with the old firmware the iPads (5Ghz) and iPhone (2.5Ghz) always connected and ran just fine (so did the iMac) which is why i am blaming the MacOSX 10.8.4 on the Macbook Pro. (if i rebooted the machine it connected just fine)

Okay i am going to put 0.28 back on my router, then switch to a low-numbered channel and see what happens.

BTW i DID NOT reset the nvram after upgrading or downgrading..
 
BTW i DID NOT reset the nvram after upgrading or downgrading..

You don't need to if switching between 27 and 28. There has been no change in default settings between the two (beside fixing the log_level, and I implemented additional code to work around that issue anyway in case anyone had the incorrect value).
 
Still running fine with channel 36 (too early to tell)

but i am getting this in the log


Apr 22 21:34:25 miniupnpd[938]: delete_filter_rule() : iptc_delete_num_entry(): Index of deletion too big
Apr 22 21:34:25 miniupnpd[938]: failed to remove port mapping
Apr 22 21:34:25 miniupnpd[938]: delete_filter_rule() : iptc_delete_num_entry(): Index of deletion too big
Apr 22 21:34:25 miniupnpd[938]: failed to remove port mapping

Also if i am understanding how this all works.

when i run iptables -vL

the FUPNP section has this.

Chain FUPNP (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- any any anywhere imac udp dpt:4500
0 0 ACCEPT udp -- any any anywhere imac udp dpt:5353
0 0 ACCEPT udp -- any any anywhere malt udp dpt:5353
0 0 ACCEPT udp -- any any anywhere malt udp dpt:4500

But this can't work since, we have two machines looking at the same port?

I can delete some of the entires here from FUPNP chain manually. to fix that

am i interpreting this correctly??
 
Last edited:
Hi. Been away for 2 weeks. This Merlin version works great in my N66U. Wireless is perfect on both bands.

Hi
Did you try to stream 1080p media trough 5 Ghz wireless?
Does it work fine there?
If so what adapter are you using on the receiving side?

Thanks in advance

BR
Ocram
 
Since both computers are Mac, it's possible that they both use the same type of wireless NIC. Do you have any other wifi device by any chance? Just curious to see how it would behave when you're in a situation where neither Mac will connect properly.

Also do test the low-numbered vs high-numbered channel theory to see if one of these ranges is more stable than the other one.

So i was running it with .28 and 5Ghz on a low numbered channel and nothing has changed same issue.

Here is the 5Ghz info


SSID: "XXXXX"
RSSI: 0 dBm SNR: 0 dB noise: -92 dBm Channel: 36l
BSSID: XX:XX:XX:XX:XX:XX Capability: ESS
Supported Rates: [ 6(b) 9 12(b) 18 24(b) 36 48 54 ]
VHT Capable:
Chanspec: 5GHz channel 38 40MHz (0xd826)
Primary channel: 36
HT Capabilities:
Supported MCS : [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 32 ]
VHT Capabilities:
Supported VHT (tx) Rates:
NSS: 1 MCS: 0-9
NSS: 2 MCS: 0-9
NSS: 3 MCS: 0-9
Supported VHT (rx) Rates:
NSS: 1 MCS: 0-9
NSS: 2 MCS: 0-9
NSS: 3 MCS: 0-9

Mode : AP Only

Stations List Rx/Tx speed rssi state
--------------------------------------------------------------------------------------
XX:XX:XX:XX:XX:XX 10.0.0.33 iPad 65/13 Mbps 119 dBm assoc auth
XX:XX:XX:XX:XX:XX 10.0.0.38 malt 81/81 Mbps 119 dBm assoc auth
XX:XX:XX:XX:XX:XX 10.0.0.211 imac 108/54 Mbps 119 dBm

Also if i do a /sbin/service restart_wireless

everything goes back to normal. so a daily 4am restart_wireless will be the temporary workaround.
 
Last edited:
Is there anyone else experiencing bad WAN outbound performance on highspeed links with these new betas?

I only get about 50-60mbit outbound on my 100/100 connection.

If i enable QoS i get "full" speed, but that was not neccessay before on the non beta firmwares.

Tried enabling/disabling HW acceleration and almost every other setting, including factory reset to see if anything would fix it without success.

Running RT-N66U.
 
Last edited:
Still running fine with channel 36 (too early to tell)

but i am getting this in the log


Apr 22 21:34:25 miniupnpd[938]: delete_filter_rule() : iptc_delete_num_entry(): Index of deletion too big
Apr 22 21:34:25 miniupnpd[938]: failed to remove port mapping
Apr 22 21:34:25 miniupnpd[938]: delete_filter_rule() : iptc_delete_num_entry(): Index of deletion too big
Apr 22 21:34:25 miniupnpd[938]: failed to remove port mapping

Also if i am understanding how this all works.

when i run iptables -vL

the FUPNP section has this.

Chain FUPNP (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- any any anywhere imac udp dpt:4500
0 0 ACCEPT udp -- any any anywhere imac udp dpt:5353
0 0 ACCEPT udp -- any any anywhere malt udp dpt:5353
0 0 ACCEPT udp -- any any anywhere malt udp dpt:4500

But this can't work since, we have two machines looking at the same port?

I can delete some of the entires here from FUPNP chain manually. to fix that

am i interpreting this correctly??

Looks like miniupnpd lost track of the allocated ports somehow. You could delete the rules, or reboot the router to clean it up.
 
Is there anyone else experiencing bad WAN outbound performance on highspeed links with these new betas?

I only get about 50-60mbit outbound on my 100/100 connection.

If i enable QoS i get "full" speed, but that was not neccessay before on the non beta firmwares.

Tried enabling/disabling HW acceleration and almost every other setting, including factory reset to see if anything would fix it without success.

Running RT-N66U.

Try resetting your modem. Turn it off, and leave it off for 5-10 mins, then turn it back on. I've seen quite a few users fixing their slow speed issues this way.
 
I was wondering are visited websites recorded anywhere and is it possible to do a url re-direct?
 
I was wondering are visited websites recorded anywhere and is it possible to do a url re-direct?

There's no URL logging implemented. I might eventually port Tomato's, but this is not a high priority at this time.
 
I'm not dismissing your report... I mentioned how this shouldn't be used as an important metric...There is little need to keep hitting the nail on the head if it's already well driven into the wood...

Sounds like a dismissal to me. Three times.

Otherwise, I could point it at being the other way around, and claim that the version that stays at 450 Mbps has broken power management, but the one dropping while not being used was the correct behaviour. :)

I'm running my laptop at high performance.

While this is labelled as Beta, you can probably consider the RT-AC66U version as being stable.

Not sure where I saw you mention to not report issues with speeds for the AC66U... As you can see above you mentioned that the AC66U should be stable. Therefore I submit that it is not. I think I shall just go back and wait for Asus to update their builds. This is not worth my time. Thanks but no thanks. :)
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

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