N56U B1 disconnects

[Drezn]

Hello everyone

I'm having quite a bit of trouble with my RT-N56U B1. It came out earlier this year and is supposed to be a version 2 replacement of the original N56U and contains MediaTek hardware instead of RaLink.

It's driving me crazy though, as I simply can't get any sort of stable operation out of it on the stock firmware. There are no firmware updates available for it either on the support section of ASUS' site. I'm pretty sure the router isn't defective as such as it runs perfectly stable on Padavan's firmware. The trouble is though, Padavan takes out the QoS module in his firmware, which is exactly what I purchased the router for in the first place...

So, the N56U B1 router connects through the ZyXEL P-2601HN-F1 provided by my ISP. They've put it into bridge mode so i can't connect to its web-interface and have no influence on it apart from being able to turn it on and off and making it reload it's settings by holding down reset. This has to be done because the connection is some ancient PPPoA setup requiring a modem, so the ZyXEL translates the PPPoA into PPPoE for the N56U B1. It's not the best solution in the world but it's what I can get at my current address and it works flawlessly with the Padavan firmware.

When I'm running the stock firmware i get intermittent disconnects from games. EVE Online simply loses the connection and quits while Star Wars Battlefront suddenly lags to a standstill for 5-10 seconds before resuming the action (with me being very dead at that point of course).

The logs look like this after it happening a few times:

Dec 17 17:06:11 WAN Connection: Ethernet link up.
Dec 17 17:06:11 rc_service: wanduck 196:notify_rc restart_wan_if 0
Dec 17 17:06:11 kernel: eth3: ===> VirtualIF_close
Dec 17 17:06:11 kernel: eth3: ===> VirtualIF_open
Dec 17 17:06:17 WAN Connection: Ethernet link up.
Dec 17 17:06:17 rc_service: wanduck 196:notify_rc restart_wan_if 0
Dec 17 17:06:17 kernel: eth3: ===> VirtualIF_close
Dec 17 17:06:17 kernel: GDMA2_MAC_ADRH -- : 0x000014dd
Dec 17 17:06:17 kernel: GDMA2_MAC_ADRL -- : 0xa92dc538
Dec 17 17:06:17 kernel: eth3: ===> VirtualIF_open
Dec 17 17:06:18 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth3_eth3)!
Dec 17 17:06:18 wan: finish adding multi routes
Dec 17 17:06:18 rc_service: udhcpc 791:notify_rc stop_upnp
Dec 17 17:06:18 miniupnpd[749]: received signal 15, good-bye
Dec 17 17:06:19 rc_service: udhcpc 791:notify_rc start_upnp
Dec 17 17:06:19 miniupnpd[825]: HTTP listening on port 48316
Dec 17 17:06:19 miniupnpd[825]: Listening for NAT-PMP traffic on port 5351
Dec 17 17:06:20 ntp: start NTP update
Dec 17 17:06:21 dhcp client: bound xxx.xxx.xxx.xxx via xxx.xxx.xxx.xxx during 7200 seconds.
Dec 17 17:11:06 rc_service: httpd 237:notify_rc restart_wan_if 0
Dec 17 17:11:06 kernel: eth3: ===> VirtualIF_close
Dec 17 17:11:06 kernel: eth3: ===> VirtualIF_open
Dec 17 17:11:13 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth3_eth3)!
Dec 17 17:11:13 wan: finish adding multi routes
Dec 17 17:11:14 rc_service: udhcpc 864:notify_rc stop_upnp
Dec 17 17:11:14 miniupnpd[825]: received signal 15, good-bye
Dec 17 17:11:15 rc_service: udhcpc 864:notify_rc start_upnp
Dec 17 17:11:16 ntp: start NTP update
Dec 17 17:11:16 dhcp client: bound xxx.xxx.xxx.xxx via xxx.xxx.xxx.xxx during 7200 seconds.
Dec 17 17:11:26 ntp: start NTP update
Dec 17 17:14:54 WAN Connection: Ethernet link up.
Dec 17 17:14:54 rc_service: wanduck 196:notify_rc restart_wan_if 0
Dec 17 17:14:54 kernel: eth3: ===> VirtualIF_close
Dec 17 17:14:54 kernel: eth3: ===> VirtualIF_open
Dec 17 17:15:00 WAN Connection: Ethernet link up.
Dec 17 17:15:00 rc_service: wanduck 196:notify_rc restart_wan_if 0
Dec 17 17:15:00 kernel: eth3: ===> VirtualIF_close
Dec 17 17:15:02 kernel: GDMA2_MAC_ADRH -- : 0x000014dd
Dec 17 17:15:02 kernel: GDMA2_MAC_ADRL -- : 0xa92dc538
Dec 17 17:15:02 kernel: eth3: ===> VirtualIF_open
Dec 17 17:15:03 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth3_eth3)!
Dec 17 17:15:04 wan: finish adding multi routes
Dec 17 17:15:04 rc_service: udhcpc 940:notify_rc stop_upnp
Dec 17 17:15:04 rc_service: udhcpc 940:notify_rc start_upnp
Dec 17 17:15:05 ntp: start NTP update
Dec 17 17:15:05 dhcp client: bound xxx.xxx.xxx.xxx via xxx.xxx.xxx.xxx during 7200 seconds.
Dec 17 17:15:15 ntp: start NTP update
Dec 17 17:19:14 WAN Connection: Ethernet link up.
Dec 17 17:19:14 rc_service: wanduck 196:notify_rc restart_wan_if 0
Dec 17 17:19:14 kernel: eth3: ===> VirtualIF_close
Dec 17 17:19:16 kernel: GDMA2_MAC_ADRH -- : 0x000014dd
Dec 17 17:19:16 kernel: GDMA2_MAC_ADRL -- : 0xa92dc538
Dec 17 17:19:16 kernel: eth3: ===> VirtualIF_open
Dec 17 17:19:16 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth3_eth3)!
Dec 17 17:19:16 wan: finish adding multi routes
Dec 17 17:19:16 rc_service: udhcpc 1008:notify_rc stop_upnp
Dec 17 17:19:17 rc_service: udhcpc 1008:notify_rc start_upnp
Dec 17 17:19:18 ntp: start NTP update
Dec 17 17:19:18 dhcp client: bound xxx.xxx.xxx.xxx via xxx.xxx.xxx.xxx during 7200 seconds.
Dec 17 17:19:22 WAN Connection: Ethernet link up.
Dec 17 17:19:22 rc_service: wanduck 196:notify_rc restart_wan_if 0
Dec 17 17:19:22 ntp: start NTP update
Dec 17 17:19:22 kernel: eth3: ===> VirtualIF_close
Dec 17 17:19:22 kernel: eth3: ===> VirtualIF_open
Dec 17 17:19:28 WAN Connection: ISP's DHCP did not function properly.
Dec 17 17:19:29 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth3_eth3)!
Dec 17 17:19:29 wan: finish adding multi routes
Dec 17 17:19:29 rc_service: udhcpc 1075:notify_rc stop_upnp
Dec 17 17:19:30 rc_service: udhcpc 1075:notify_rc start_upnp
Dec 17 17:19:31 ntp: start NTP update
Dec 17 17:19:31 dhcp client: bound xxx.xxx.xxx.xxx via xxx.xxx.xxx.xxx during 7200 seconds.
Dec 17 17:19:33 WAN Connection: WAN was restored.
Dec 17 17:19:34 ntp: start NTP update
Dec 17 17:25:43 WAN Connection: Ethernet link up.
Dec 17 17:25:43 rc_service: wanduck 196:notify_rc restart_wan_if 0
Dec 17 17:25:43 kernel: eth3: ===> VirtualIF_close
Dec 17 17:25:43 kernel: eth3: ===> VirtualIF_open
Dec 17 17:25:44 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth3_eth3)!
Dec 17 17:25:44 wan: finish adding multi routes
Dec 17 17:25:44 rc_service: udhcpc 1142:notify_rc stop_upnp
Dec 17 17:25:45 rc_service: udhcpc 1142:notify_rc start_upnp
Dec 17 17:25:46 ntp: start NTP update
Dec 17 17:25:46 dhcp client: bound xxx.xxx.xxx.xxx via xxx.xxx.xxx.xxx during 7200 seconds.
Dec 17 17:25:49 WAN Connection: Ethernet link up.
Dec 17 17:25:49 rc_service: wanduck 196:notify_rc restart_wan_if 0
Dec 17 17:25:49 ntp: start NTP update
Dec 17 17:25:49 kernel: eth3: ===> VirtualIF_close
Dec 17 17:25:51 kernel: GDMA2_MAC_ADRH -- : 0x000014dd
Dec 17 17:25:51 kernel: GDMA2_MAC_ADRL -- : 0xa92dc538
Dec 17 17:25:51 kernel: eth3: ===> VirtualIF_open
Dec 17 17:25:52 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth3_eth3)!
Dec 17 17:25:52 wan: finish adding multi routes
Dec 17 17:25:52 rc_service: udhcpc 1207:notify_rc stop_upnp
Dec 17 17:25:52 ntp: start NTP update
Dec 17 17:25:53 rc_service: udhcpc 1207:notify_rc start_upnp
Dec 17 17:25:54 ntp: start NTP update
Dec 17 17:25:54 dhcp client: bound xxx.xxx.xxx.xxx via xxx.xxx.xxx.xxx during 7200 seconds.
Dec 17 17:26:04 ntp: start NTP update
Dec 17 17:27:48 WAN Connection: Ethernet link up.
Dec 17 17:27:48 rc_service: wanduck 196:notify_rc restart_wan_if 0
Dec 17 17:27:48 kernel: eth3: ===> VirtualIF_close
Dec 17 17:27:48 kernel: eth3: ===> VirtualIF_open
Dec 17 17:27:54 WAN Connection: Ethernet link up.
Dec 17 17:27:54 rc_service: wanduck 196:notify_rc restart_wan_if 0
Dec 17 17:27:54 kernel: eth3: ===> VirtualIF_close
Dec 17 17:27:54 kernel: GDMA2_MAC_ADRH -- : 0x000014dd
Dec 17 17:27:54 kernel: GDMA2_MAC_ADRL -- : 0xa92dc538
Dec 17 17:27:54 kernel: eth3: ===> VirtualIF_open
Dec 17 17:27:54 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth3_eth3)!
Dec 17 17:27:55 wan: finish adding multi routes
Dec 17 17:27:55 rc_service: udhcpc 1280:notify_rc stop_upnp
Dec 17 17:27:56 rc_service: udhcpc 1280:notify_rc start_upnp
Dec 17 17:27:57 ntp: start NTP update
Dec 17 17:27:57 dhcp client: bound xxx.xxx.xxx.xxx via xxx.xxx.xxx.xxx during 7200 seconds.
Dec 17 17:28:00 ntp: start NTP update


I've tried tinkering with everything from different NTP servers to cloning other MAC addresses, altering the DHCP request frequency setting to disabling the automatic download of IP / subnet settings from the ISP and setting them myself, but to no avail. Does anybody have any idea what's going on here? I know the obvious solution to getting a stable connection is to just run the router with Padavan's firmware, but that defeats the whole purpose of getting a router with QoS in the first place...

Thank you in advance!

 

[Drezn]

Oh, and by the way, I have of course been googling around for solutions before posting here. I'm not the only one with the connection issues question it seems, but people usually end up solving the problem by running Padavan firmware instead. I've also been looking for beta ASUS firmwares but I haven't been able to find anything at all for the N56U B1. Does anyone know of a place to look for beta ASUS firmwares?

 

[Drezn]

Hmm, it doesn't bode well for me at all that no one has replied to this thread... I guess I'll have to get in touch with ASUS customer support then, but i seriously doubt they'll know more about it than the clever people in here!

 

[JZS]

Not the answer you are looking for, but if I inherited this problem, after exhausting the (limited) firmware options (which you've apparently done), I'd RMA the unit as beyond rehabilitation and replace with well-supported (namely, Broadcom chipset) one.
56 is a lower end unit, with non-stellar reviews for connectivity and lack of firmware options. Perhaps your B1 experience may not be a lot better than other users Ralink experience.
If $ is a concern, you can pick up RT-N66u from NewEgg, frequently on sale for $50 refurb. (Non-sale price is $70). Newegg has RT-AC66u refurb frequently on sale for $90. Negative reviews for either unit seem to largely stem from users running Asus stock FW (which IS crap).
Both can be flashed with Tomato Shibby, which provides the QOS you seek. Or try other options (Merlin, DD-WRT) as these are widely supported units.
For completeness, you can of course test/eliminate your base modem (and/or ISP or external wiring) as a source of WAN connectivity woes by swapping in spare router or even direct connect (+/- run packet trace utility), but I wouldn't even bother with that step unless your particular unit or ISP is noted by others to be unreliable, or your wiring is suspect. And if you've already eliminated WAN problems with custom FW, then sounds like that part of the stack is fine.

 

[Drezn]

Well, I guess it was actually the answer I was looking for, I just didn't know it until now. That settles it, I'm going to take this unsupported piece of junk back to the store in the hopes of being able to swap it for a better unit. I didn't know about all the mods available for the higher tier routers from ASUS and didn't find out about them until after I'd run into trouble with the one I have now. If I had known about it I would've gone for a router that supported them! Silly me assuming that a product would just work right out of the box, eh?

Thanks for your reply and the suggestions, I appreciate it!

 

[JZS]

Well, I guess it was actually the answer I was looking for, I just didn't know it until now. That settles it, I'm going to take this unsupported piece of junk back to the store in the hopes of being able to swap it for a better unit. I didn't know about all the mods available for the higher tier routers from ASUS and didn't find out about them until after I'd run into trouble with the one I have now. If I had known about it I would've gone for a router that supported them! Silly me assuming that a product would just work right out of the box, eh?

Thanks for your reply and the suggestions, I appreciate it!

I learned the same lesson, the hard way, with a D-Link DIR-655 years ago. So the exact lesson is START with the target firmware you really want, and then work back from that to find the best (value) Router for that. So for me (currently), I would go here:

http://tomato.groov.pl/?page_id=69

Ironically, the AC version of your router (RT-AC56U) IS Broadcom-based and is thus supported.