[CLOSED] Asuswrt-Merlin 378.50 Beta 1 is out

[RMerlin]

One last thing to add about the ftp server, if I disable IPv6 completely then the ftp server will launch properly when turned on from the Web UI. Consistent with the error I reported earlier of course.

Thanks, I'll see if I can reproduce it with an HE tunnel.

 

[RussellInCincinnati]

Have as others noticed, seen the weird client counts (negative numbers) etc on the status screen with an AC68u on _50 beta. And indeed my 4 port wireless bridge does not show up directly as a client. Instead all that is visible in the client list is one of the devices wired to that client--with a number 5 attached (kind of neat actually, it is an accurate count of all the devices on the bridge plus the bridge itself).

This is all cosmetic stuff that no ordinary person is ever going to see. Much less care, for example have freeware network scanners that are better than an incidental router feature, at displaying the client IP's on a given 0..254 network.

After one day of Samba file sharing and net browsing, a small user pool reports that they are not seeing the intermittent (3 times/day?) slowdowns in file access (lasting say 30 seconds) that they had been seeing with _49 Merlin on the 68u. Encouraging.

Windows 7/XP/Ubuntu 14.04 users, WiFi clients all using EW-7822UAC USB WiFi adapters.

 

[RMerlin]

Some more tests with the ftp server lead to a reboot of my AC56U, it seems that vsftpd corrupts the memory, for example the text editor nano stops working after I try to start vsftpd, it segfaults. Not a show stopper for me since I do not need ftp, but those who do, beware.

I had similar random issues with vsftpd 2.x. Just closing your shell and starting a new SSH session fixes it, I suspect vsftpd messes up with the terminal when it outputs an error message.

 

[win465]

Is this Normal in my system logs? I keep getting this same message over and over again

Jan 26 20:15:44 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:30 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:30 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:31 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:31 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:32 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:32 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:33 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:33 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:34 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:35 kernel: net_ratelimit: 1 callbacks suppressed
Jan 26 20:23:35 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:35 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:36 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:36 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:37 kernel: br0: received packet on vlan1 with own address as source address
Jan 26 20:23:37 kernel: br0: received packet on vlan1 with own address as source address

 

[charlie2alpha]

And now to report some more on the RT-AC56U dpi enabled beta; the adaptive QoS seems to work, as well as the traffic analyzer. Did not try the AI protection stuff, I suspect they will cause more problems than solve. WiFi seems to be working OK but I did not do any specific testing except some rudimentary OOKLA speedtests for the internet speed itself. At least the connection is stable which is what matters most to me, I rarely do heavy transfers on the WiFi.

On the IPv6 front, one bug I had on the 376.49 release seems to be gone, now the router will successfully get an IPv6 address every time it has to reconnect (using native IPv6/DHCP PD).

Overall, from my point of view, by using the AC68U dpi drivers RMerl managed to provide us owners of the RT-AC56U with a working dpi enabled firmware. In the following days I expect to find out if this dpi engine does any good.

 

[JockC]

Is this Normal in my system logs? I keep getting this same message over and over again
Jan 26 20:15:44 kernel: br0: received packet on vlan1 with own address as source address

That message has been raised numerous times in various forums. I've never seen a complete explanation as to why it occurs but it seems to be pretty much business as usual for these devices.
It's a good reason to go in and clear the log every few days.

 

[RMerlin]

One last thing to add about the ftp server, if I disable IPv6 completely then the ftp server will launch properly when turned on from the Web UI. Consistent with the error I reported earlier of course.

Seems it's a limitation of vftpd (maybe introduced in recent versions). vsftpd can't listen to both IPv4 and IPv6 interfaces at the same time, which sounds like a pretty silly design limitation.

For now you can get around that problem with the following postconf script:

#!/bin/sh

source /usr/sbin/helper.sh
CONFIG=$1

pc_append "listen=NO" $1

When told to listen to ::1 with listen_ipv6, vsftpd will also answer to the IPv4 interfaces.

I'll have to see if I can modify the config file generation to handle both vsftpd 2.x and 3.x.

 

[win465]

That message has been raised numerous times in various forums. I've never seen a complete explanation as to why it occurs but it seems to be pretty much business as usual for these devices.
It's a good reason to go in and clear the log every few days.

So i shouldn't worry about it?

 

[JockC]

So i shouldn't worry about it?

One or two other more savvy posters might be able to give you more details but everything I've ever read says that it's something that can be simply ignored.
I get those messages on both my RT-AC68U (Merlin firmware) and my DSL-AC68U (Asus firmware) devices.

 

[win465]

One or two other more savvy posters might be able to give you more details but everything I've ever read says that it's something that can be simply ignored.

Okay thanks

 

[bigmag]

@RMerlin Good Moning from Germany

Why HW acceleration Enabled (CTF only) ?

 

[SVettel]

Hi Merlin,
I found in "/etc/resolv.conf", there's only one line "nameserver 127.0.0.1". I wonder if it's what makes adding "strict-order" to dnsmasq.conf render pinging from router unusable, because according to the man page of dnsmasq, it says "Setting this flag forces dnsmasq to try each query with each server strictly in the order they appear in /etc/resolv.conf".
Thx

------------edit------------
With "strict-order" on.
After I append "nameserver 208.67.220.220" to /etc/resolv.conf and send a SIGHUP to dnsmasq to force it to reload /etc/resolv.conf, ping can work from router, but the interval between issuing the ping command and getting the response from it is abnormal, about 4-5 seconds(it's not the long pinging time, pinging time being normal like 23ms.)
If I remove "nameserver 127.0.0.1" from it and only leave "nameserver 208.67.220.220" in /etc/resolv.conf, and let it reload the /etc/resolv.conf, then the behavior of ping back to normal, very quick response from ping command.
It's like dnsmasq gets stuck if both "nameserver 127.0.0.1" and "strict-order" are there. And if there's only "nameserver 127.0.0.1" in resolv.conf accompanied with "strict-order", all pinging from router would get responded with "Bad Address" if that address is not cached, like a deadlock.

 

[KevTech]

Is the GUI supposed to say "Daylight saving time is enabled in this time zone" even though I am on standard time right now?

DST does not start until March in my area.

 

[Jimmy8881]

This is a filesystem check that's failing due to the disk being too large for the amount of memory on the router.

thanks for the explanation! but why 3.0.0.4.378.3873 works fine? Is there a different file system driver on your build?

 

[GoNz0]

That build should not be required anymore. 378.50 is supposed to be doing the CFE upgrade.

Try rebooting the router then check again. If it still shows an older CFE, then try doing a factory default reset and rebooting again (just save a backup of your settings so you can restore them after you are done doing this test).

I wish Broadcom hadn't made the frigging CFE updater closed source. This makes it impossible for me to debug anything, and I see zero reason for them to close source this - there's hardly any trade secret in such a process.

It's impossible for the firmware to have downgraded your CFE since the only CFE image contained in it is 1.0.2.0.

I went by my 2nd 68u for bootloader version but I never checked the original one, either way it is up to date so it may be worth pointing out that running the latest asus > factory reset > 50 beta would be the better roadmap to reduce issues for now if you cannot troubleshoot the updater.

 

[Gnoty]

Have you reset to factory defaults and manually enter only the necessary settings to secure the router / wifi and connect to your ISP?

Have you used a new ssid?

I did the factory reset yes, necessary settings as change from stock ssid to my old one, nothing more was done. i did however fint it hard to connect the first 10minutes, dont know why but eventually it connected.

Also dubble wan doesnt work for some reason.

 

[charlie2alpha]

Did some tests and compared to the Asus online demo, seems that the AdaptiveQoS_Bandwidth_Monitor.asp page is not working properly for me, the buttons do nothing since the clients do not get classified, also the traffic bars stay blank.

EDIT: seems to work better after I disabled CTF acceleration. The bars show traffic but the colored buttons still won't work properly, seems the clients do not get classified per priority. I am comparing with this page: http://nw-dlcdnet.asus.com/AdaptiveQoS_Bandwidth_Monitor.asp

EDIT2: thanks to the power of Google, I found this so I dragged the buttons instead of just clicking them and that worked! What it does, I am not sure, prioritizing traffic on the client level maybe?

EDIT3: in the end CTF wasn't the issue, the browser was! Cleared Chrome's cache and everything started working even with CTF enabled.

 

[Igor]

ASUS RT-AC68U Firmware version 3.0.0.4.378.3813 and 3.0.0.4.378.3873 supported ZTE MF823 LTE modem but Asuswrt-Merlin 378.50 Beta1 has no this modem in list USB Adapter. Please add.

 

[octopus]

Try rebooting the router then check again. If it still shows an older CFE, then try doing a factory default reset and rebooting again (just save a backup of your settings so you can restore them after you are done doing this test).

I wish Broadcom hadn't made the frigging CFE updater closed source. This makes it impossible for me to debug anything, and I see zero reason for them to close source this - there's hardly any trade secret in such a process.

Mine either have not change CFE 1018 => 1020.
I found in folder, /rom/cfe 3st CFE:s.
cfe_1.0.2.0.bin
cfe_1.0.2.0_esmt.bin
cfe_tmo_2.1.2.2.bin
and mtd-write (newest one v3).
If I look inside cfe_1.0.2.0.bin ccode=US which should been loaded I can se some default mac and secret code.
So something went wrong when trying to change CFE.

Octopus

 

[tibere86]

AC Mode

I'm running the DPI version of the AC56U firmware and for the life of me, I cannot get 80mhz active on the 5ghz network. I have tried all the settings combinations, AUTO, N/AC MIXED, 80MHZ, 20/40/80MHZ. Someone mind posting their successful settings.