Asuswrt-Merlin 378.55 beta 2 is now available

[RMerlin]

Asuswrt-Merlin 378.55 Beta 2 is now available for all supported models.

See this thread for the details on Beta 1: http://www.snbforums.com/threads/asuswrt-merlin-378-55-beta-is-now-available.25601/unread

Changes since Beta 1:

   - CHANGED: Updated dnsmasq to 2.73 RC9 (backport from GPL 6975)
   - CHANGED: Updated odhcp6c to newer version (backport from GPL 6975)
   - CHANGED: Updated openssl to 1.0.2d (fixes CVE-2015-1793, only present
              in Beta 1 - 54_2 was not affected)
   - CHANGED: Display existing key/certs on the OpenVPN pages once
              they've been migrated to JFFS.
   - FIXED: Time scheduler-related features (Parental Control & Wifi
            scheduler) were broken (backported fix from Asus's GPL 6975)
            (beta 1 regression)
   - FIXED: QTN firmware was still being copied to RAM rather than rely
            on the symlink to flash added in Beta 1, to save 4 MB of RAM.
            (AC87U)
   - FIXED: Dropbox cloud sync would fail on some setups (backport
            from GPL 6975)
   - FIXED: Entware-setup script would generate an invalid services-start
            script
   - FIXED: Duplicate zoneedit entry on the DDNS service list.

In addition, the wireless driver was updated for the RT-AC68U (from GPL 6975 - Asus forgot to include it in the 6117 GPL) and RT-AC56U (from GPL 6117). Please confirm there are no new major issues with this driver update (as usual I'm not interested in feedback regarding speed/range, as this is always conflicting as it depends on each user's specific environment, and a 2-3% difference can easily amount to be within the typical wifi variation).

I need the OpenVPN key/certificate management to be tested, to ensure that the code I wrote to allow the webui to still manage the certificates even after their JFFS migration does work properly.

Downloads are here.
Changelog is here.

 

[PabloAbonia]

Bug report (378.55 Beta1 and likely Beta2). The "DHCP leases" page under the "System Log" tab is having difficulty with IPV6 addresses when assigned statically. The IPV6 address is spread over the "IP Address" & "Hostname" columns with the first 3 parts of the address in the first column, and another 3 in the last column. octets.

The MAC address is entirely wrong, although ti appears to be putting in some of the DUIDs at times.

Finally, my router MAC address is badly offset, resulting in the oddity of it being called a Barracuda Security Device. The time for that one is also entirely incorrect.

Pablo

 

[RMerlin]

Bug report (378.55 Beta1 and likely Beta2). The "DHCP leases" page under the "System Log" tab is having difficulty with IPV6 addresses when assigned statically. The IPV6 address is spread over the "IP Address" & "Hostname" columns with the first 3 parts of the address in the first column, and another 3 in the last column. octets.

The MAC address is entirely wrong, although ti appears to be putting in some of the DUIDs at times.

Finally, my router MAC address is badly offset, resulting in the oddity of it being called a Barracuda Security Device. The time for that one is also entirely incorrect.

Pablo

Can you post a screenshot to provide a better idea of how the layout ends up?

I assume your static IPs are configured directly on the device's NICs?

 

[ILMostro]

Are there any changes to the USB printer share feature between beta 1 and this beta2? I am having difficulty with this on beta1 at the moment w/RT-AC56U router

 

[highwire]

On the RT-AC87U, Traffic Analyzer -> Traffic Monitor -> Ethernet WAN, realtime is either 0 (no traffic) or ~1048600KB/sec with any traffic running.

 

[kiesa1231]

Bug with minidlna not fixed.Rename real Seagate to Seagate(1) ant minildna created Seagate and save scan database

 

[joegreat]

In addition, the wireless driver was updated for the RT-AC68U (from GPL 6975 - Asus forgot to include it in the 6117 GPL) and RT-AC56U (from GPL 6117). Please confirm there are no new major issues with this driver update (as usual I'm not interested in feedback regarding speed/range, as this is always conflicting as it depends on each user's specific environment, and a 2-3% difference can easily amount to be within the typical wifi variation).

Hi,

I assume that a factory reset is recommended due to wireless driver change, or this time not needed?

With kind regards
Joe

 

[PabloAbonia]

Can you post a screenshot to provide a better idea of how the layout ends up?

I assume your static IPs are configured directly on the device's NICs?

No, I'm not statically configuring on the devices. I use features in dnsmasq to do so (see below).

• Of note, when you are looking at first record, the NaNd line appears to be an address from my router (which shouldn't be getting a DHCP lease here, I think)
• I think, that it is misinterpreting the /var/lib/misc/dnsmasq.leases file when it hits the DUID for the router. In that case, it is trying to generate a time off of "duid" in the first column of that file, which is then followed by the routers DUID being divvied up across the MAC and IP address columns. Everything after that, gets messed up due to that line I believe.
• I think the above is where the problem really lies. The rest describes my configuration, and some IPV6 oddities.
• Running in IPV6 Native Mode
• I create a host file with IPV6 address, FQDN, shortname
  • aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh shortname.home.lan shortname
  • IPV6 address is generated according to EUI64 address rules, and used locally as a static address within the entirety of the /64 address range, rather then being limited to ::1000 to ::2000
  • This file is edited using sed and the dhcp-events to update the /64 prefix with whatever one TWC deigns to hand out. The prefix changes weekly.
• I use dhcp-hosts file with a DUID to allow dnsmasq to provide the aforementioned IPV6 addresses. When used in this fashion, so long as the address ends up in /etc/hosts, it will be doled out the the requesting device
  • AA:BB:CC: DD:EE:FF,id:LO:NG: DU:ID,shortname,192.168.x.x,[::eeee:ffff:gggg:hhhh],3600s
    
  • Note that the final 4 sets of the IPV6 address match that in the host file as above. With the :: at the beginning, dnsmasq will append whatever /64 prefix is provided by the ISP.
  • This also sets the IPV4 address
  • This formatting in dnsmasq is useful, as TWC regularly changes the prefix (at least once a week), which make reassigning the addresses a bit of a hassle, but at least I don't have to edit this file all the time.
• Finally, my dhcp-range in dnsmasq.conf is:
  • dhcp-range=lan,::,constructor:br0,slaac,static,64,3600s
    
  • This provides the minor advantage of a slaac privacy address for external requests, while still allowing for direct internal IPV6 addressing using the EUI64 MAC based address.
• P.S. As an aside, for some reason, even though my router has a WAN IPV6 address, an external fe80 address as the gateway (cable modem address). I'm assuming that it is the cable modem address, as ipv6 pings to the address take an average of 15 ms, which is sad given that it is a 1000 Full duplex connection with a good cable. I'm quite suspicious of this being a significant source of networking problems, as tools such as traceroute6 from the router itself, or behind it fail at the first hop. Is this common? Thoughts?

 

[Steffe]

Anyone have PPTP working for the 68U unit using the 55.x releases?

Can't get mine to work (http://www.snbforums.com/threads/pptp-not-working.25737/)

 

[Deleted member 22229]

the wireless driver was updated for the RT-AC68U (from GPL 6975 - Asus forgot to include it in the 6117

I have not tried your beta 2 but i have tried Asus 6975 and for the 68U the 5 GHz signal has dropped. Now that i know there is a new driver i know why. Bummer. Should be interesting to see if anybody reports the same thing with this build.

 

[RMerlin]

Are there any changes to the USB printer share feature between beta 1 and this beta2? I am having difficulty with this on beta1 at the moment w/RT-AC56U router

Not a single line of code was changed.

 

[RMerlin]

On the RT-AC87U, Traffic Analyzer -> Traffic Monitor -> Ethernet WAN, realtime is either 0 (no traffic) or ~1048600KB/sec with any traffic running.

I know, and I already notified Asus about this issue two weeks ago. They recently did some change to traffic monitoring on the AC87U, I suspect it's what introduced the issue.

 

[RMerlin]

Bug with minidlna not fixed.Rename real Seagate to Seagate(1) ant minildna created Seagate and save scan database

What bug in particular? The changes I did were only to handle the case of minidlna crashing while scanning some particular files.

 

[RMerlin]

Hi,

I assume that a factory reset is recommended due to wireless driver change, or this time not needed?

With kind regards
Joe

Shouldn't be, there was no nvram change related to it. You might just want to forget the network on your clients and reconnect them again, just to be safe.

 

[hggomes]

I have not tried your beta 2 but i have tried Asus 6975 and for the 68U the 5 GHz signal has dropped. Now that i know there is a new driver i know why. Bummer. Should be interesting to see if anybody reports the same thing with this build.

What you mean by that? Weaker signal? Or disconnects?

 

[RussellInCincinnati]

Asuswrt-Merlin 378.55 Beta 2 is now available for all supported models...
In addition, the wireless driver was updated for the RT-AC68U (from GPL 6975...Please confirm there are no new major issues with this driver update

For the last several releases, have had trouble connecting to an RT-AC68u on the 5 gigahertz band with the EdiMax USB 3.0 adapter, Windows 10 default driver (from Realtek). Suddenly am connecting fine now, thanks RMerlin.

In the last few RMerlin releases, could not get a 5ghz connection at all unless the Wireless mode is set to "Auto", allowing both 2.4ghz and 5ghz connections. Now once again in this 55_2 beta, connections are immediate, even with Wireless Mode set (in adapter options) to "802.11ac"...and only 5ghz connections show up as available, as should be the case.

For large file copy from a USB 3.0-connected Solid State Drive plugged into the router USB 3.0 port, read throughput is a respectable 200 megabits per second over a connection that is nominally connected at "780 megahertz." Once again exactly as expected.

 

[dsring]

Does this beta have the latest 5GHz Quantenna firmware for the RT-AC87 (i.e. the one included in Asus beta firmwares 7010 and 6687)? Thanks.

 

[Deleted member 22229]

What you mean by that? Weaker signal? Or disconnects?

No disconnects. Weaker signal tested from multiple 5 GHZ devices. Dont use 2.4 so have no comment.

 

[RMerlin]

Does this beta have the latest 5GHz Quantenna firmware for the RT-AC87 (i.e. the one included in Asus beta firmwares 7010 and 6687)? Thanks.

No, this is based on 6117, not 6687/7010.

 

[RMerlin]

Thoughts?

That's a lot of customization, and something that would be difficult for me to reproduce here. Best I can do at this point is switch to Asus's own DHCP lease parser, which will skip the duid line as well as any entry that's not an IPv4 lease since I have no real way to test this.