Asuswrt-Merlin 3.0.0.4.354.27 Beta 1

[wewen]

Trying out 3.0.0.4.354.27 here. Results are very good. Better signal, more stable, better ac speed.

I have a Nexus 7 that I always had problems with after waking up from sleep. I had often reconnect to the network again. Thought it might been bad drivers from nvidia or something.

But since 354 thoose problems disappeared.

 

[dombera]

Hi guys,

3.0.0.4.354.27 Beta 1 seems to be running very stable. I have checked my system logs and I am having some strange errors:

Apr 1 12:41:09 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:41:09 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:41:11 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:41:11 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:41:15 kernel: printk: 316 messages suppressed.
Apr 1 12:41:15 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:41:20 kernel: printk: 1 messages suppressed.
Apr 1 12:41:20 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:41:24 kernel: printk: 17 messages suppressed.
Apr 1 12:41:24 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:41:39 kernel: printk: 2 messages suppressed.
Apr 1 12:41:39 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:41:39 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:41:39 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:42:07 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:42:07 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:42:09 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:42:09 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:42:09 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:42:15 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:42:15 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:42:39 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:42:39 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:42:39 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:43:01 kernel: protocol 0000 is buggy, dev eth0
Apr 1 12:43:02 kernel: protocol 0000 is buggy, dev eth1
Apr 1 12:43:02 kernel: protocol 0000 is buggy, dev eth0

Any idea on what this could be? I would appreciate any help.

Thank you,

 

[Cool Breeze]

Try disabling broadcast support on the VPN server & the search button on the forum.
http://forums.smallnetbuilder.com/showpost.php?p=44194&postcount=326

 

[RMerlin]

got quite a bit of log spamming also

Apr  1 08:51:39 dnsmasq-dhcp[5798]: not giving name RT-N66U to the DHCP lease of 192.168.2.160 because the name exists in /etc/hosts with address 192.168.2.1

You have two devices on your network trying to use the same name (RT-N66U). Might want to rename one of the two.

 

[RMerlin]

Definitely no SSH or DHCP logging here, even toggled the DHCP logging setting saved and rebooted and still no logging. I have changed the IP Pool Starting Address to .100 , not sure if that would have any effect.

Edit:

Cleared browser cache, reflashed firmware, restored to factory defaults and still no logging.

Can you try accessing the log over SSH/Telnet, to ensure the issue isn't with the webui?

tail /tmp/syslog.log

That will show you the last entries in the logfile. See if they match what's on the webui.

 

[lilstone87]

Can you try accessing the log over SSH/Telnet, to ensure the issue isn't with the webui?

tail /tmp/syslog.log

That will show you the last entries in the logfile. See if they match what's on the webui.

Yes matches the router log, and nothing DHCP related.

 

[RMerlin]

Yes matches the router log, and nothing DHCP related.

But do you have anything else actually being logged? If not, then the issue has nothing to do with DHCP, but is with logging itself. That's what I need to know.

 

[lilstone87]

But do you have anything else actually being logged? If not, then the issue has nothing to do with DHCP, but is with logging itself. That's what I need to know.

No stuff is being logged, as I was switching wireless channel's early this morning, and the log showed wireless restarts due to it. Other stuff gets logged also. I was just saying stuff hasn't been logged in over a day yesterday, because no change's were made. Most the time my log is filled by DHCP spam anyway's. So it really doesn't matter much to me, but wanted to help out with the people who like seeing this stuff being logged. Also I always wipe the nvram on firmware update's, and redo all my settings manually.

 

[cmillar6]

my DHCP logging actually worked when I initially flashed, its when I got paranoid after reading other posts and I wiped my nvram and reconfigured that I started seeing the problem. Not a huge concern for me either, DHCP functioning just fine despite the logs, I just know Merlin likes bugs reported.

 

[RMerlin]

I just know Merlin likes bugs reported.

And this is the goal of beta releases such as this one.

This is why I need feedback from different persons, especially since I can't reproduce it on my end - have to figure out the common factor between those who do experience the problem.

 

[Magoo]

Yes matches the router log, and nothing DHCP related.

Same here and also cleared NVRAM with the WPS button after flashing the firmware.

 

[lfbb]

Yeah I can tell you on my N66U it's not logging either. Hell nothing has been recorded in the log for over a day, and I can tell you using previous firmware version's. It's almost like spam to me seeing DHCP stuff being logged. I have multiple thing's with assigned IP's, and yes the option is set to "Yes", which if I am correct is "Yes" by default anyway's.

Same problem here...

 

[applesnowleo]

Hello Merlin,

Finely after a few days I got home, installed 354 from asus and made a print screen capture of the overlay I am refering from de mac adress, hope is better to understand what I mean.

Hoping it is possible to implement in your firmware this way, if not, It's not important, only a cosmetic issue that I find beautifull

Thanks.

 

[RMerlin]

Hello Merlin,

Finely after a few days I got home, installed 354 from asus and made a print screen capture of the overlay I am refering from de mac adress, hope is better to understand what I mean.

Hoping it is possible to implement in your firmware this way, if not, It's not important, only a cosmetic issue that I find beautifull

Thanks.

I'll have to dig through the GPL code to check why this didn't get merged in, cause it should have.

Could possibly be something that was still under development, and was only present in the 3.0.0.5.354 test build that was accidentally released at first.

 

[lfbb]

Jan 1 00:01:35 rc_service: httpd 495:notify_rc start_autodet
Jan 1 00:01:42 rc_service: httpd 495:notify_rc start_autodet
Jan 1 00:02:07 rc_service: httpd 495:notify_rc restart_wan_if 0
Jan 1 00:02:07 stop_wan(): perform DHCP release
Jan 1 00:02:07 WAN Connection: ISP's DHCP did not function properly.
Jan 1 00:02:10 pppd[602]: Connected to 08:76:ff:9a:b7:b9 via interface eth0
Jan 1 00:02:10 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Jan 1 00:02:11 kernel: nf_conntrack_rtsp v0.6.21 loading
Jan 1 00:02:11 kernel: nf_nat_rtsp v0.6.21 loading
Jan 1 00:02:11 rc_service: ip-up 606:notify_rc stop_upnp
Jan 1 00:02:11 rc_service: ip-up 606:notify_rc start_upnp
Jan 1 00:02:11 rc_service: ip-up 606:notify_rc stop_ntpc
Jan 1 00:02:11 rc_service: ip-up 606:notify_rc start_ntpc
Jan 1 00:02:12 rc_service: httpd 495:notify_rc start_autodet
Jan 1 00:02:12 WAN Connection: WAN was restored.
Jan 1 00:02:23 rc_service: httpd 495:notify_rc restart_wireless
Jan 1 00:02:26 rc_service: httpd 495:notify_rc start_webs_update
Jan 1 00:02:26 rc_service: start_webs_update is waitting restart_wireless...
Jan 1 00:02:26 RT-N66U: swmode: router repeater ap
Jan 1 00:02:29 kernel: wl_module_init: passivemode set to 0x0
Jan 1 00:02:29 kernel: eth1: Broadcom BCM4331 802.11 Wireless Controller 5.110.27.20012
Jan 1 00:02:29 kernel: eth2: Broadcom BCM4331 802.11 Wireless Controller 5.110.27.20012
Mar 30 19:07:58 rc_service: ntp 657:notify_rc restart_upnp
Mar 30 19:07:58 rc_service: ntp 657:notify_rc restart_diskmon
Mar 30 19:07:58 rc_service: restart_diskmon is waitting restart_upnp...
Mar 30 19:07:58 disk monitor: be idle
Mar 30 19:08:09 rc_service: httpd 495:notify_rc restart_net_and_phy
Mar 30 19:08:11 FTP Server: daemon is stoped
Mar 30 19:08:11 Samba Server: smb daemon is stoped
Mar 30 19:08:14 miniupnpd[742]: Failed to get IP for interface ppp0
Mar 30 19:08:14 miniupnpd[742]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Mar 30 19:08:14 stop_wan(): perform DHCP release
Mar 30 19:08:15 stop_wan(): perform DHCP release
Mar 30 19:08:17 RT-N66U: swmode: router repeater ap
Mar 30 19:08:18 kernel: wl_module_init: passivemode set to 0x0
Mar 30 19:08:18 kernel: eth1: Broadcom BCM4331 802.11 Wireless Controller 5.110.27.20012
Mar 30 19:08:18 kernel: eth2: Broadcom BCM4331 802.11 Wireless Controller 5.110.27.20012
Mar 30 19:08:18 crond[497]: time disparity of 1180506 minutes detected
Mar 30 19:08:20 stop_nat_rules: apply the redirect_rules!
Mar 30 19:08:20 WAN Connection: Fail to connect with some issues.
Mar 30 19:08:20 start_nat_rules: apply the nat_rules(/tmp/nat_rules__eth0)!
Mar 30 19:08:20 dhcp client: bound 192.168.1.66 via 192.168.1.254 during 3600 seconds.
Mar 30 19:08:20 RT-N66U: start httpd
Mar 30 19:08:21 miniupnpd[742]: SSDP packet sender 192.168.2.1:1900 not from a LAN, ignoring
Mar 30 19:08:21 miniupnpd[742]: SSDP packet sender 192.168.2.1:1900 not from a LAN, ignoring
Mar 30 19:08:21 miniupnpd[742]: SSDP packet sender 192.168.2.1:1900 not from a LAN, ignoring
Mar 30 19:08:21 miniupnpd[742]: SSDP packet sender 192.168.2.1:1900 not from a LAN, ignoring
Mar 30 19:08:21 pppd[921]: Connected to 08:76:ff:9a:b7:b9 via interface eth0
Mar 30 19:08:21 Samba Server: daemon is started
Mar 30 19:08:21 miniupnpd[742]: Failed to get IP for interface ppp0
Mar 30 19:08:21 miniupnpd[742]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Mar 30 19:08:21 miniupnpd[742]: Failed to get IP for interface ppp0
Mar 30 19:08:21 miniupnpd[742]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Mar 30 19:08:21 miniupnpd[742]: SendNATPMPPublicAddressChangeNotification: sendto(s_udp=16): Invalid argument
Mar 30 19:08:21 miniupnpd[742]: SendNATPMPPublicAddressChangeNotification: sendto(s_udp=16): Invalid argument
Mar 30 19:08:21 miniupnpd[742]: SendNATPMPPublicAddressChangeNotification: sendto(s_udp=16): Invalid argument
Mar 30 19:08:21 miniupnpd[742]: SendNATPMPPublicAddressChangeNotification: sendto(s_udp=16): Invalid argument
Mar 30 19:08:21 miniupnpd[742]: SendNATPMPPublicAddressChangeNotification: sendto(s_udp=16): Invalid argument
Mar 30 19:08:21 miniupnpd[742]: SendNATPMPPublicAddressChangeNotification: sendto(s_udp=16): Invalid argument
Mar 30 19:08:21 miniupnpd[742]: SendNATPMPPublicAddressChangeNotification: sendto(s_udp=16): Invalid argument
Mar 30 19:08:22 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Mar 30 19:08:22 rc_service: ip-up 960:notify_rc stop_upnp
Mar 30 19:08:22 miniupnpd[742]: sendto(udp_shutdown=14): Invalid argument
Mar 30 19:08:22 miniupnpd[742]: sendto(udp_shutdown=14): Invalid argument
Mar 30 19:08:22 miniupnpd[742]: sendto(udp_shutdown=14): Invalid argument
Mar 30 19:08:22 miniupnpd[742]: sendto(udp_shutdown=14): Invalid argument
Mar 30 19:08:22 miniupnpd[742]: sendto(udp_shutdown=14): Invalid argument
Mar 30 19:08:22 miniupnpd[742]: sendto(udp_shutdown=14): Invalid argument
Mar 30 19:08:22 miniupnpd[742]: sendto(udp_shutdown=14): Invalid argument
Mar 30 19:08:22 miniupnpd[742]: sendto(udp_shutdown=14): Invalid argument
Mar 30 19:08:22 miniupnpd[742]: sendto(udp_shutdown=14): Invalid argument
Mar 30 19:08:22 miniupnpd[742]: Failed to broadcast good-bye notifications
Mar 30 19:08:22 rc_service: ip-up 960:notify_rc start_upnp
Mar 30 19:08:25 WAN Connection: WAN was restored.
Mar 30 19:09:02 nmbd[954]: [2013/03/30 19:09:02, 0] nmbd/nmbd_become_lmb.c:become_local_master_stage2(392)
Mar 30 19:09:02 nmbd[954]: Samba name server RT-N66U is now a local master browser for workgroup WORKGROUP on subnet 192.168.2.1
Mar 30 19:10:13 rc_service: httpd 932:notify_rc restart_wireless
Mar 30 19:10:17 RT-N66U: swmode: router repeater ap
Mar 30 19:10:19 kernel: wl_module_init: passivemode set to 0x0
Mar 30 19:10:19 kernel: eth1: Broadcom BCM4331 802.11 Wireless Controller 5.110.27.20012
Mar 30 19:10:19 kernel: eth2: Broadcom BCM4331 802.11 Wireless Controller 5.110.27.20012
Mar 30 19:10:33 rc_service: httpd 932:notify_rc restart_wireless
Mar 30 19:10:37 RT-N66U: swmode: router repeater ap
Mar 30 19:10:39 kernel: wl_module_init: passivemode set to 0x0
Mar 30 19:10:39 kernel: eth1: Broadcom BCM4331 802.11 Wireless Controller 5.110.27.20012
Mar 30 19:10:39 kernel: eth2: Broadcom BCM4331 802.11 Wireless Controller 5.110.27.20012
Mar 30 19:10:58 rc_service: httpd 932:notify_rc restart_time;restart_httpd;restart_upnp
Mar 30 07:11:06 RT-N66U: start httpd
Mar 30 07:11:06 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Mar 30 07:11:06 RT-N66U: start httpd
Mar 30 07:12:06 rc_service: httpd 1150:notify_rc restart_time;restart_httpd;restart_upnp
Mar 30 19:12:06 RT-N66U: start httpd
Mar 30 19:12:06 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Mar 30 19:12:06 RT-N66U: start httpd
Mar 30 19:15:42 rc_service: httpd 1188:notify_rc restart_dnsmasq
Mar 31 01:03:36 rc_service: httpd 1188:notify_rc restart_time;restart_httpd;restart_upnp
Mar 31 02:03:36 RT-N66U: start httpd
Mar 31 02:03:37 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Mar 31 02:03:37 RT-N66U: start httpd
Apr 1 21:12:25 rc_service: httpd 1337:notify_rc restart_dnsmasq
Apr 1 21:13:09 rc_service: httpd 1337:notify_rc restart_dnsmasq

Here's the Syslog for the past 2 days, just for the record.

EDIT: I also noted that nvram usage drop from around 36100 to 35200 bytes.

 

[Soul--Reaver]

I once had an issue where some setting was enabled but did not work properly and i fixed it by disabling and enabling the setting (saving in between of course)

Maybe this will fix the problem with the DHCP logging as well...

 

[greenythebeast]

Hi guys,

I just got an RT-AC66R and flashed Asuswrt-Merlin 3.0.0.4.354.27 Beta 1 to it and am having a major problem with the 5Ghz radio. The temperature is idling around 76-78°C! The 2.4Ghz radio is idling around 55°C. Does anyone know what could be causing this? Nothing is connected to the 5Ghz radio because it isn't even broadcasting (I assume the router is shutting it down due to the high temps?). It's also not hot in the room at all. Please help

 

[Magoo]

I once had an issue where some setting was enabled but did not work properly and i fixed it by disabling and enabling the setting (saving in between of course)

Maybe this will fix the problem with the DHCP logging as well...

Thought that myself, tried your suggestion yesterday and still no logging.

 

[cmillar6]

Hi guys,

I just got an RT-AC66R and flashed Asuswrt-Merlin 3.0.0.4.354.27 Beta 1 to it and am having a major problem with the 5Ghz radio. The temperature is idling around 76-78°C! The 2.4Ghz radio is idling around 55°C. Does anyone know what could be causing this? Nothing is connected to the 5Ghz radio because it isn't even broadcasting (I assume the router is shutting it down due to the high temps?). It's also not hot in the room at all. Please help

I just started playing with the 5GHz band and I noticed my AC66U ran much hotter. I mounted with the stand provided and my temps dropped. If this doesn't solve your problem I would return it, 78C is a little warm.

 

[RMerlin]

Found the DHCP issue. As I suspected, it has nothing to do with DHCP at all.

Asus decided to change the default loglevel for syslog, probably to get rid of some of the log spam. The new default loglevel is 5, instead of 7. So if you reset back to factory defaults, the new default loglevel is written in NVRAM, and dnsmasq log entries are of a higher level, therefore they never get logged. I never saw the issue on my main router because it hasn't been reset to factory defaults in months - but the development RT-N66U just reproduced the issue.

The manual workaround for now is to change the default loglevel back to its original value:

nvram set log_level=7
nvram commit
reboot

Now I have to figure out if I just want to change the default loglevel back to 7, or fiddle with the log priority used by dnsmasq.