[Release] Asuswrt-Merlin 380.61 is now available

[The Cool Dude]

I guess my logs are too long as i'm getting an error saying i'm blocked.... i'll try to condense...

Aug 14 02:47:50 dnsmasq-dhcp[17308]: BOOTP(br0) 00:26:86:00:00:00 no address configured
Aug 14 02:47:59 dnsmasq-dhcp[17308]: BOOTP(br0) 00:26:86:00:00:00 no address configured
Aug 14 02:48:02 dnsmasq-dhcp[17308]: BOOTP(br0) 00:26:86:00:00:00 no address configured
Aug 14 02:48:10 dnsmasq-dhcp[17308]: BOOTP(br0) 00:26:86:00:00:00 no address configured
Aug 14 02:48:13 dnsmasq-dhcp[17308]: BOOTP(br0) 00:26:86:00:00:00 no address configured

it went on like this for about an hour then it rebated if I'm reading this right....

Jul 31 18:00:11 syslogd started: BusyBox v1.20.2
Jul 31 18:00:11 kernel: PERCPU: Embedded 7 pages/cpu @c8215000 s5472 r8192 d15008 u65536
Jul 31 18:00:11 kernel: pcpu-alloc: s5472 r8192 d15008 u65536 alloc=16*4096
Jul 31 18:00:11 kernel: pcpu-alloc: [0] 0 [0] 1
Jul 31 18:00:11 kernel: Built 1 zonelists in Zone order, mobility grouping on. Total pages: 60416
Jul 31 18:00:11 kernel: Kernel command line: root=/dev/mtdblock2 console=ttyS0,115200 init=/sbin/preinit earlyprintk debug
Jul 31 18:00:11 kernel: PID hash table entries: 1024 (order: 0, 4096 bytes)

Thanks in advance.....

 

[Jheroen]

does anyone have any news about battery drain @ samsung devices i and others had on for instance the .59 build?

 

[RMerlin]

Aug 14 02:47:50 dnsmasq-dhcp[17308]: BOOTP(br0) 00:26:86:00:00:00 no address configured

You have a device on your LAN which tries to use BOOTP, which is not supported by the router. Locate that client, and disable BOOTP support on it.

 

[RMerlin]

does anyone have any news about battery drain @ samsung devices i and others had on for instance the .59 build?

The only reported battery drain issue was with the RT-AC87U, and reports indicate it was fixed last winter.

 

[highwire]

You have a device on your LAN which tries to use BOOTP, which is not supported by the router. Locate that client, and disable BOOTP support on it.

That device is the Quantenna SoC in the RT-AC87U itself. Mine occasionally does this too and it coincides with the 5GHz radio not working and not coming back up. To clear it up, I have to remove power from the router and try rebooting again.

Results for MAC address 00:26:86
Found 1 results.

MAC Address/OUI Vendor {Company}
00:26:86 Quantenna Communcations, Inc.

 

[RMerlin]

That device is the Quantenna SoC in the RT-AC87U itself. Mine occasionally does this too and it coincides with the 5GHz radio not working and not coming back up. To clear it up, I have to remove power from the router and try rebooting again.

Results for MAC address 00:26:86
Found 1 results.

MAC Address/OUI Vendor {Company}
00:26:86 Quantenna Communcations, Inc.

That could make sense. The Quantenna bootloader tries to boot its firmware over tftp (the tftp server running under the Broadcom firmware). I assume that if something's wrong with the Quantenna boot process, it might be trying alternative network configuration methods.

Yes, the RT-AC87U architecture is _that_ weird...

 

[Jheroen]

The only reported battery drain issue was with the RT-AC87U, and reports indicate it was fixed last winter.

Okay,

I use the AC68U and am still on .55 release from more then a year ago, after vacation this week i will upgrade to the latest version (reboot/flash/reboot/factory default/manual reconfig) and hope this one is as stable as the .55 in use now.

Tried the .59 when it was stable but my and other Samsung devices (S5 mini/tablets) were running out of power faster then with .55.

Resumé, will try next week thanks!

 

[highwire]

That could make sense. The Quantenna bootloader tries to boot its firmware over tftp (the tftp server running under the Broadcom firmware). I assume that if something's wrong with the Quantenna boot process, it might be trying alternative network configuration methods.

Yes, the RT-AC87U architecture is _that_ weird...

The Quantenna SoC is served an IP address in the LAN subnet from the DHCP server running on the Broadcom SoC. It doesn't show up in the network map (maybe there's code on the 87U to keep it from showing up there), but if you put the 87U in AP mode where IP addresses are served from outside the 87U, an IP address always shows up in the arp table and DHCP leases table with MAC 00:26:86:00:00:00 and a lease expirey of 'never'. It makes sense since the Quatenna subsystem is essentially a separate WiFi AP hanging off the Broadcom SoC but packaged in the same casing.

It is indeed a weird (and failed) design.

 

[The Cool Dude]

The Quantenna SoC is served an IP address in the LAN subnet from the DHCP server running on the Broadcom SoC. It doesn't show up in the network map (maybe there's code on the 87U to keep it from showing up there), but if you put the 87U in AP mode where IP addresses are served from outside the 87U, an IP address always shows up in the arp table and DHCP leases table with MAC 00:26:86:00:00:00 and a lease expirey of 'never'. It makes sense since the Quatenna subsystem is essentially a separate WiFi AP hanging off the Broadcom SoC but packaged in the same casing.

It is indeed a weird (and failed) design.

Hello and thanks everyone for helping me understand why my router rebooted.

What is interesting is that while I was on firmware version 378_9460 I had both of my RT-AC87U routers showing their uptimes for months straight and very little in the log and they never rebooted themselves. In fact it was rare that I ever rebooted them.

So it seems that something changed in the new firmware to tell the router to reboot itself if a certain situation arises as it did in my case. Has anyone else seen this happen on the RT-AC87U? Do we know what would trigger this to reboot?

Aside from this issue, I'd say the 380.61 is pretty good.

Thanks again everyone.

 

[vipernig]

Hi all. I am also having the same problems as dt99uk.

I finally got the USB working for saving the traffic monitor data. But now nothing appears when I select Bandwith for the last 24 hours, daily and monthly. Same thing happens when it saves the logging data in RAM. Is this a new bug? This is on an Asus rt-n66u. This bandwith monitoring is crucial to me.

 

[DeathAngel74]

All good here!

 

[Ian Holl]

I dirty flashed 61 on top of 59 on my RT-AC87U and I've got issues with port forwarding. I have my desktop running W8.1 without issues. But my 2012 Server won't port forward. It's hit and miss if I run a DMZ on the server's IP. Last night it ran the DMZ and it opened all the ports, but when I disabled- re-enabled it the ports wouldn't open again.

An online port scan reveals just these ports are open:

PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
2000/tcp filtered cisco-sccp
3389/tcp open ms-wbt-server
49152/tcp open unknown
49153/tcp open unknown
49154/tcp open unknown
49155/tcp open unknown
49156/tcp open unknown
49157/tcp open unknown

The motherboard I'm using in the server is an old Asus Pt6 X58 version 2. I'm wondering if it's a hardware problem. Any suggestions?

 

[chadm]

I have 3 AC66Us running 61 in AP mode, both bands on each using the same SSID, all 3 units supporting the same SSID, configured with non-overlapping channels. I am seeing kernel panics from all 3. Before posting here, I wanted to eliminate as many things as I could - I swapped power supplies between all three, purchased a new power supply and tested it on all 3, I cleared NVRAM and defaulted the configuration of all 3, I physically swapped all 3 66U devices with each other as well (reconfiguring from scratch each time). The kernel panic I am seeing follows:

CPU 0 Unable to handle kernel paging request at virtual address 0000000c, epc == c06db264, ra == c06eb404
Oops[#1]:
Cpu 0
$ 0 : 00000000 00000000 00000018 00000000
$ 4 : 00000000 82298210 87b60138 82291180
$ 8 : 00000008 87b6013e 00004188 87b940a0
$12 : 87d82000 87f84000 00000000 00006bf0
$16 : 00000000 00000000 00000000 00000000
$20 : 00000001 00000000 8764f200 00000000
$24 : 82291198 00000000
$28 : 80306000 80307cb8 00000024 c06eb404
Hi : 0000000d
Lo : 0000000a
epc : c06db264 wlc_rxframe_chainable+0x168/0x2e0 [wl] Tainted: P
ra : c06eb404 wlc_bmac_recv+0x290/0x3b0 [wl]
Status: 1100f403 KERNEL EXL IE
Cause : 00000008
BadVA : 0000000c
PrId : 00019749
Modules linked in: cdc_mbim qmi_wwan cdc_wdm cdc_ncm rndis_host cdc_ether asix usbnet usblp ohci_hcd ehci_hcd ufsd(P) vfat fat ext2 ext3 jbd mbcache usb_storage sg sd_mod scsi_wait_scan scsi_mod usbcore jffs2 zlib_deflate zlib_inflate nf_nat_pptp nf_conntrack_pptp nf_nat_proto_gre nf_conntrack_proto_gre nf_nat_ftp nf_conntrack_ftp wl(P) igs(P) emf(P) bcm57xx et(P) ctf(P)
Process swapper (pid: 0, threadinfo=80306000, task=80308188)
Stack : 00008040 8764f200 00000000 00000000 00000001 00000000 87b940a0 8764f200
c06eb404 c06eb448 c06eb614 c01e048c 00000000 80360000 87c26e00 80360000
00000000 b3058170 00008040 8764f200 87f84000 20000000 a8008000 00000001
80307d70 8094e6c0 00000000 c06eb9e8 80310000 80307d70 84160403 80307d70
c06ebd00 c062c288 87c24a80 80360000 80360000 80360000 8036499c 80362eb8
...
Call Trace:
[<c06db264>] wlc_rxframe_chainable+0x168/0x2e0 [wl]
[<c06eb404>] wlc_bmac_recv+0x290/0x3b0 [wl]
[<c06eb9e8>] wlc_dpc+0x1b4/0x520 [wl]
[<c06d9344>] wl_intrson+0x4a8/0x7a0 [wl]
[<c06d96dc>] wl_isr+0xa0/0x4a4 [wl]


Code: 03081023 8ca30008 0047c021 <8c64000c> 8f020008 10820052 00001021 8da40818 8c830030
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 3 seconds..Please stand by while rebooting the system...​

 

[RMerlin]

The kernel panic I am seeing follows:

The crash occurs within the wireless driver. No idea might be causing it, and not much that could be done about it either. Only thing to try is to revert to an older firmware version.

 

[Ian Holl]

Having read a lot of the posts here, I never released how temperamental and potentially buggy firmware can be for Asus routers.

I was naive enough to believe that as long as the flash completed there wouldn't be any issues. If I'm honest I never even rebooted before I flashed, which is probably the reason why I'm having issues with being unable to open ports on LAN 2.

What's the best method of relashing? Should I just reboot-flash-reboot? Or should I do the recovery thing before flashing?

BTW, great work Merlin. Even if I'm having issues, they're likely due to my ignorance and I still appreciate all of your hard work regardless

 

[vincom]

Having read a lot of the posts here, I never released how temperamental and potentially buggy firmware can be for Asus routers.

I was naive enough to believe that as long as the flash completed there wouldn't be any issues. If I'm honest I never even rebooted before I flashed, which is probably the reason why I'm having issues with being unable to open ports on LAN 2.

What's the best method of relashing? Should I just reboot-flash-reboot? Or should I do the recovery thing before flashing?

BTW, great work Merlin. Even if I'm having issues, they're likely due to my ignorance and I still appreciate all of your hard work regardless

really, if youve been reading any of these threads you should know that you should restore to factory defaults after flashing, this is what merlin suggests if having issues before making a post about fw problems

 

[RMerlin]

Having read a lot of the posts here, I never released how temperamental and potentially buggy firmware can be for Asus routers.

I was naive enough to believe that as long as the flash completed there wouldn't be any issues. If I'm honest I never even rebooted before I flashed, which is probably the reason why I'm having issues with being unable to open ports on LAN 2.

What's the best method of relashing? Should I just reboot-flash-reboot? Or should I do the recovery thing before flashing?

Re-flashing is usually pointless. If there had been a problem with the initial flash, the router would most likely not boot at all.

Rebooting before flashing is only so you can free up enough memory for the flash process to work, as your RAM might already be in use by caches and buffers, especially if you have a USB disk plugged in. If there isn't enough free RAM, the flash will simply fail with an error message when you attempt to upload the new firmware.

The most common solution to issues after a firmware upgrade is just to do a factory default reset, and manually reconfigure everything.

 

[Ian Holl]

really, if youve been reading any of these threads you should know that you should restore to factory defaults after flashing, this is what merlin suggests if having issues before making a post about fw problems

"really" Really what? Did you even read my post before spouting out your drivel? Are you suggesting code is written bug free? Did I even suggest that my problem was because of bugs? I said the reason I'm likely to be suffering problems is because of 'my ignorance' and not the firmware.

 

[eddiez]

"really" Really what? Did you even read my post before spouting out your drivel? Are you suggesting code is written bug free? Did I even suggest that my problem was because of bugs? I said the reason I'm likely to be suffering problems is because of 'my ignorance' and not the firmware.

Cool down, that is not what he is saying, is he? He is merely saying that a bug is probably not the first thing to think about when you are experiencing issues. There are some situations to be qualified as user initiated, either consciously or unconsciously. Factory reset or even unmounting a USB drive can prevent these situations. These behaviours are not really bugs but can be considered undesired or awkward features...you cannot fully take the tech nitty gritty out of firmware and nothing in the world is perfect or flawless (besides me of course...)

 

[pvonn]

for some reason ver 61 did not work for me on my rt5300 properly slowed down all my bandwidth, tried all the normal recommendations no change.
ver 58 worked great. so i switched to the latest asus firmware and everything works great. no sure what i missed or did wrong.

will wait and try out next new version of merlin.