[Test builds] 380.58 alpha builds are now available

[RMerlin]

Ah oki, I see that the fix is also in for the 68U 3.0.0.4.380.1842, so hopefully it will make its way to your hands soon enough


Sent from my iPhone using Tapatalk

I have the 380_2345 GPL but it's impossible for me to isolate this single fix out of hundreds of lines of changed code, so this will most likely wait until 380.59.

Sent from my Nexus 5X using Tapatalk

 

[elorimer]

Does it show the [P] flag for power save in the wireless log?

Nexus 6P:

On 2.4, yes, on 5, no.

 

[binggesoft]

3.0.0.4.380_2346

 

[L&LD]

3.0.0.4.380_2346

Your linked can't point to a private IP address.

 

[The Asgard]

Nexus 6P:

On 2.4, yes, on 5, no.

I don't think the issue is fixed then.

 

[ChriscomIT]

3.0.0.4.380_2346

Your link will be leading to http://192.168.2.1/Advanced_FirmwareUpgrade_Content.asp .

Is this version available? Is it the latest non-beta firmware? Can u provide a proper link please? Thanks!

 

[ChriscomIT]

I have the 380_2345 GPL but it's impossible for me to isolate this single fix out of hundreds of lines of changed code, so this will most likely wait until 380.59.

Sent from my Nexus 5X using Tapatalk

Does that mean a merge from ur side is expectable in the next days or a official release from Asus ?

 

[punkinduster]

Is this version available? Is it the latest non-beta firmware? Can u provide a proper link please? Thanks!

The proper link to non-beta firmware from Asus is on their support website. Have patience and it will appear when it is ready.

 

[Alfsu]

Dear RMerlin,

Build 380.58_alpha3-gcf77301 is running smoothly in an RT-AC68P, thank you for your hard work. No more issues with WIFI connections.

I don't know if this is any relevant, but there are several entries in the log with:

kernel: BUG: scheduling while atomic: mtdblock3/256/0x00000002

A quick google search offered this: ..."Problem was caused by usb_submit_urb()..." I hope this is helpfull

Any idea about the origin of this message?


Using 380.58_alpha3-gcf77301 in an RT-AC68P, running Samba, FTP, Download Master and AiCloud; VPN Client with routing rules and DNS Base Filtering.

 

[RMerlin]

Does that mean a merge from ur side is expectable in the next days or a official release from Asus ?

I already merged it locally, but I haven't pushed it to Github for various reasons, one being I can only reliably compile for the RT-AC88U/RT-AC3100 due to the need for newer binary blobs for all other models. And the RT-AC5300 crashes during boot time.

380.58 will remain based on 1354, 380.59 will be the one based on newer GPL (either 2345, or anything newer if Asus releases an official version in the meantime.)

 

[bayern1975]

@RMerlin; i tested right now this beta, found here on forum....beta firmware 9.0.0.4_380_2295-g1423616 (updated in 2016/2/24).....IPTV over udpxy working very good here....so, i do not know what code you using now for your next release but please check section for IPTV, because i tested your latest alpha2 and 3 but IPTV didn`t working.....we talk about this you know.....

 

[andyman]

I have uploaded updated builds (380-58 alpha3-gcf77301). Changelog:

cf77301 openvpn: Mark OpenVPN traffic for CTF bypass
bcc5cc4 fw: change NAT loopback mark to a single bit, and use a mask to avoid trashing other bits
05f2ee1 webui: Add setting to enable/disable the IPv6 neigh sol broadcoast drop on Comcast
3a07398 openvpn: ensure that clients set to route traffic through WAN are also excluded from DNS redirection.
976d14c rc: revert watchdog led handling code to pre-1354 as a workaround to RT-AC56U LED issues
4e221ad shared: ensure our custom led ID values don't interfere with Asus's code for cases where they rely on LED_ID_MAX
2557876 wl: Downgraded RT-AC68U driver to  6.37.14.105 (r485445).  Tested functional with both rev. A1 and C1.
3a1c0c1 Revert "openvpn: Uniformize the use of  over backticks; ensure that the fw setup script gets overwritten rather than appen

Hi Merlin

Been using your firmware for years now..truly excellent stuff!

A question if I may as it's of some importance as I have an Asus N66-U over in Portugal and I'm here in the UK..and I shouldn't like to break the remote router or access to it ( it sits behind a service suppliers cable modem with a forward on port 8086 to access the web) but I need to set up an automatic reboot and some other stuff that would be much easier on the latest version..I've had one hang-up.

The version in the N66-U in Portugal is 3.0.0.4.270.26 (old I know, I'm a big fan of 'if it ain't broke, don't fix it!) but if I upgrade it remotely to a much later version , 380.57 (which I'm also running on a local AC-68U) will it lose it's config on reboot?

Thanks a lot for any help.

Andy

 

[L&LD]

andyman, you won't be able to do that type of upgrade remotely. A reset to factory defaults is required and physical access to the router will probably be needed to do that properly.

http://www.snbforums.com/threads/no...l-and-manual-configuration.27115/#post-205573

It may not lose it's config, but you will more than likely have multiple phantom bugs and issues if you don't reset and configure it properly again.

To me, 'if it ain't broke, don't fix it' doesn't apply to network hardware like a router where security is a moving target that changes daily and hourly.

Keeping up with the latest firmware is work, granted. But the situation you're in now, I don't envy you.

 

[Tin Raz]

Tested alpha 3 on a AC66 and it keeps rebooting in repeater mode. When linked the 5ghz band.

Rolled back to 56.2 and its stable linked to my ac3200 with a 1053mb link

 

[RMerlin]

Never remotely upgrade a firmware. I've seen more than a few cases where physically power cycling the router is required, as the router crashed during its shutdown (this is caused by Asuswrt not using two separate partitions for the current and upgraded firmware).

The issue is less common these days as Asus started using a temporary RAM disk to help protect against it, but it still happens on occasion.

 

[PabloAbonia]

I am seeing a problem with large packets and the stable .57 as well as 58 alpha 3. Specifically when using the GUI or a terminal to the router to ping an IPv6 address it fails with any size greater than 1452 (e.g. ping -s 1453 www.v6.facebook.com, using RT-AC88U).

I became frustrated with native IPv6, so I tried 6in4 again only to find the same problem.

I think it is at the level of the router, and not the cable modem since the modem responds appropriately to external pings while the router does not.

I tried working with asus regarding this, but given the failure with the new alpha and some reticence to turn away from your Merlin variant given its feature set and enhancements.

First question, for those who have native IPv6 or 6in4 do you see the same problem?

Merlin, it's good to see that you are getting better! Best wishes, Pablo

 

[chamberc]

My AC68 also spontaneously reboots with 380.57 onward, its fine with the previous SDK. I'm curious to see if others are experiencing this.

My AC 87u has also been doing this for several versions 380.57 onward. The log for me looks like this:

Mar 9 17:27:40 miniupnpd[1319]: upnp_event_recv: recv(): Connection reset by peer

Jul 31 19:00:11 syslogd started: BusyBox v1.20.2

The event before the crash varies, and is hardly ever the same. Happens about 3 times a day and is driving me nuts!

 

[nfshp253]

Hi Merlin,

Can you please look into the issue of OpenVPN selective routing not working in some configurations? For example, the default table 111 after setting up the routing in the GUI is

42.60.195.254 dev vlan10 scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
42.60.194.0/23 dev vlan10 proto kernel scope link src 42.60.195.62
100.64.16.0/21 dev tun11 proto kernel scope link src 100.64.16.2
127.0.0.0/8 dev lo scope link

What I have to do is to flush table 111, and run the command "ip route add default via 100.64.16.2 dev tun11 table 111".

default via 100.64.16.2 dev tun11

This line makes everything work. Any ideas why this is happening?

 

[RMerlin]

Hi Merlin,

Can you please look into the issue of OpenVPN selective routing not working in some configurations? For example, the default table 111 after setting up the routing in the GUI is

42.60.195.254 dev vlan10 scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
42.60.194.0/23 dev vlan10 proto kernel scope link src 42.60.195.62
100.64.16.0/21 dev tun11 proto kernel scope link src 100.64.16.2
127.0.0.0/8 dev lo scope link

What I have to do is to flush table 111, and run the command "ip route add default via 100.64.16.2 dev tun11 table 111".

default via 100.64.16.2 dev tun11

This line makes everything work. Any ideas why this is happening?

I can't reproduce any problem with it when testing with vpnbook. Check what your server is pushing to your client.

 

[andyman]

andyman, you won't be able to do that type of upgrade remotely. A reset to factory defaults is required and physical access to the router will probably be needed to do that properly.

http://www.snbforums.com/threads/no...l-and-manual-configuration.27115/#post-205573

It may not lose it's config, but you will more than likely have multiple phantom bugs and issues if you don't reset and configure it properly again.

To me, 'if it ain't broke, don't fix it' doesn't apply to network hardware like a router where security is a moving target that changes daily and hourly.

Keeping up with the latest firmware is work, granted. But the situation you're in now, I don't envy you.

Hi 'L'

Many thanks for taking the time to answer my question ..much appreciated. I feared that might be the case. It's a shame that some mechanism doesn't exist for applying large-step version changes, factory resets and config replacement remotely. We did something similar years ago on a router that had one area protected through all version changes where a basic config file to modify the current (read factory after you upgrade) config on reboot could be tagged for execution. It was used simply to either 'call home to a management system' or generate the correct WAN setup for a remote access that could be used to restore other mote complicated settings.

Anyway..thanks again for your reply.