Asuswrt-Merlin 378.56 Beta 1 is out

[RMerlin]

But I got an N66U dont see anything new on QoS page to limit bandwith or nothing new, Im on you latest stable the 55, no beta yet for the N66U, thanks

That would be because 378.55 is not based on 9177. See the changelog for that release.

 

[RMerlin]

On RT-AC3200 in the smart connect rules page the target bands are always shown as 1: 'empty' and 2: none. Upon hitting default values the correct bands are shown but upon applying / refresh they are displayed wrong again.

Confirmed.

 

[RMerlin]

On RT-AC3200 in the smart connect rules page the target bands are always shown as 1: 'empty' and 2: none. Upon hitting default values the correct bands are shown but upon applying / refresh they are displayed wrong again.

Was a bug in Asus's 9177 code. Fixed.

 

[DaveMishSr]

@RMerlin.

I appreciate the effort you put into making this firmware but can you tell me what you changed that would cause RT Ac87u to get wireless dropouts since version 3.54_2

I tried the latest beta - ie 3.56 beta 1 but still had this issue (same since version 3.55) - I then tried the latest original firmware from Asus - but never got any dropouts from that firmware.

Somewhere between 3.54_2 and 3.55 firmware something broke wifi on the AC87U router to cause these dropouts. I have gone back to 3.54_2 as that firmware works fine, I would appreciate if you could at least acknowledge that there is a fault and if you are going to try and find it?

Thanks.

No problems with things on my end.

Reset to factory default and fixed the problem.

The AC3200 & AC87x appear to share the same trait. I use the following method to restore the factory default settings with a 100% success rate to date:

1) With the router powered off press & hold the wps button for 7 seconds.
2) While still pressing the wps button, power up the router.
3) Continue to hold the wps button for at least 30 seconds after power up.
4) Release the wps button.
5) Immediately power down the router.
6) Repeat steps 1-5 at least twice.

Now my AC68U will start rapidly flashing or pulsating the power LED after about 5 seconds during Step 3 each & every time. However, with both my AC3200 (which I despise) & AC87x's (one R and one U variant) I have noticed that the power LED takes about 20 seconds to pulsate during Step 3 on the first effort with each subsequent effort taking only about 5 seconds to get to a pulsating power LED during Step 3.

It seems that if I do not get the 87 and/or 3200 to that "5 second pulsating phase" when resetting to factory defaults that problems start happening. It may be purely coincidental but it is very hard to argue against a 100% success rate with 2 very finicky platforms.

 

[MarkRH]

Giving the 378.56beta1 a go on my RT-AC68U. After initial installation I noticed it thought CTF+FA NAT acceleration was enabled. When it is in this state, the Traffic Monitor doesn't show data correctly. I did Factory Reset and now just CTF shows and the Traffic Monitor works as far as registering data. I then verified my timezone and DST settings.

There seems to be two clocks in this thing which seems to have been throwing off the Daily Traffic monitoring where it changes the day based on UTC time and not my local time. Time will tell if this firmware does the same. I noticed when I turned on my TV which is connected that this appeared in the log (removed any identifying numbers):

Oct 17 16:48:29 kernel: wl_module_init: passivemode set to 0x0
Oct 17 16:48:29 kernel: wl_module_init: igs set to 0x0
Oct 17 16:48:29 kernel: wl_module_init: txworkq set to 0x1
Oct 17 16:48:29 kernel: eth1: Broadcom BCM4360 802.11 Wireless Controller
Oct 17 16:48:29 kernel: eth2: Broadcom BCM4360 802.11 Wireless Controller
Oct 17 21:49:23 dnsmasq-dhcp[442]: DHCPDISCOVER(br0)
Oct 17 21:49:23 dnsmasq-dhcp[442]: DHCPOFFER(br0)
Oct 17 21:49:23 dnsmasq-dhcp[442]: DHCPREQUEST(br0)
Oct 17 21:49:23 dnsmasq-dhcp[442]: DHCPACK(br0)

You'll notice the time difference of 16:48 and 21:49. Above, the router shows Oct 17 17:15:13 at the moment. Shouldn't the new log entries be based on my local time and not UTC time?

Update: Yep, the Daily Traffic monitor is on the 18th now even though it's only 7:26pm locally: http://i.imgur.com/WGZwgPt.png

 

[fafot]

I don't know if it was mentioned before but when I am switching my device from 2.4 to 5Ghz network the System Log - Wireless Log is not updating the 2.4Gh table for 1min and 30 seconds so I have the device showing on both 2.4 and 5Gh networks. On the other hand when I disconnect it from 5Gh and connect to 2.4Gh the 5Gh log is updating on the spot as it should be IMO and as it was in Marlin 378.53.

 

[RMerlin]

I don't know if it was mentioned before but when I am switching my device from 2.4 to 5Ghz network the System Log - Wireless Log is not updating the 2.4Gh table for 1min and 30 seconds so I have the device showing on both 2.4 and 5Gh networks. On the other hand when I disconnect it from 5Gh and connect to 2.4Gh the 5Gh log is updating on the spot as it should be IMO and as it was in Marlin 378.53.

It means your client isn't telling the router that it's disconnecting itself as it switches to the other radio. The wireless driver therefore has no way of knowing so, and it take until the connection times out before it gets removed by the wireless driver from its internal tables.

Don't forget that, unlike Ethernet, wireless relies on beacons to determine if someone's at the other virtual end of a connection.

 

[fafot]

Thanks Marlin. The clients are iPhone 6 plus, iPad Air, other Apple devices and my PC with ASUS PCE-AC68 Wireless Adapter. In 387.53 the 2.4Gh table was updated on the spot with the same devices so I wonder why on 378.56b1 it takes time?

 

[RMerlin]

Thanks Marlin. The clients are iPhone 6 plus, iPad Air, other Apple devices and my PC with ASUS PCE-AC68 Wireless Adapter. In 387.53 the 2.4Gh table was updated on the spot with the same devices so I wonder why on 378.56b1 it takes time?

No idea, wireless are closed source. I doubt anything was changed there, and the firmware merely asks the wireless drivers to report the list of authenticated clients. I do see a lot of Apple devices in your list however, and they've made a lot of changes in recent OS updates related to wifi as they were trying to fix issues that iOS 8 and the last OS X releases caused.

 

[RMerlin]

Beta 1 testing is now closed. Please move to this thread for the Beta 2 release discussions.