[Test builds] 380.58 alpha builds are now available

[mstombs]

See the changelog for which GPL codebase this is based on.

[pedant mode on] - NEW: Merged with 380_1354 GPL

BUT there is a commit message

wl: Update SDK7114 userspace wl tool from GPL 1355

It is great that Asus continuing to develop but GPL release always lags, and I guess not all GPL contains all for all models, and newer releases may not update binaries, and not need to be bumped in Merlin git

We are waiting for GPL from

ASUS RT-AC68U Firmware version 3.0.0.4.380.1842

But can also see betas in the official forum

beta firmware 9.0.0.4_380_2295-g1423616 (updated in 2016/2/24)

So there is more in the pipeline!

 

[JohnDoe]

Hi,

on my N66U I can't chose the wireless channels 12 and 13 any longer. Actually they still can be selected in the web configuration, but after pressing, 'Apply', the control channel is reset to 'auto', so in fact only the channels 1 to 11 are usable.
The last (RMerlin-) firmware version where it was working was 378.56_2, so it's probably another issue with the 380 codebase.

Can anyone confirm this?

Mind you, as I'm from Germany, channels 12 and 13 should be legally usable and are my prefered choice, since those two are the only channels which are a bit less congested than the rest of the 2.4 GHz band.

I sincerly hope that's not a first sign of ASUS submitting to the FCC ruling about closing down the WiFi code in Open Source firmware.

 

[mstombs]

Can anyone confirm this?

Yes this is an Asus bug that has propagated into merlin firmware, it was fixed by Asus :-

ASUS RT-N66U Firmware version 3.0.0.4.378.9383 2015/12/11
- Release Notes –
- Added Movistar Triple VLAN profile in IPTV setting page
- Fixed too many repeat information in system log.
- Fixed VPN client UI issue when using Firefox.
- Fixed wireless channel issue when set 2.4G channel in 12 or 13 (only for EU region)
...

But the GPL for that release or a later,

ASUS RT-N66U Firmware version 3.0.0.4.378.9459 2016/01/19

not yet released, so we don't yet know if fixed in the driver, or web interface, or use of CFE nvram vars to enforce FCC...

and of course Asus have the issue that the 380 range forked off the 378 before this fix

 

[JohnDoe]

Ah, good to know it wasn't my fault after all, thank you for the quick reply.

 

[XIII]

DNSCrypt? New in this firmware? I look forward to that if it is

No, local setup with standalone files in /jffs.

 

[Zirescu]

DNSCrypt? New in this firmware? I look forward to that if it is

On that note, any recommendations on a provider that uses both? Which also has IPv6 support?

GoogleDNS -> DNSSEC - Yes | DNSCrypt - No
OpenDNS -> DNSSEC - No | DNSCrypt - Yes


Sent from my iPhone using Tapatalk

From the dnscrypt resolvers page it looks like there are only two providers that have what you're looking for:
dnscrypt.eu-dk-ipv6
dnscrypt.eu-nl-ipv6

 

[njespo]

thanks Eric, glad to hear you are feeling better!

 

[XIII]

From the dnscrypt resolvers page it looks like there are only two providers that have what you're looking for:
dnscrypt.eu-dk-ipv6
dnscrypt.eu-nl-ipv6

I'm actually using the ipv4 versions of these two servers.

In general they work quite nice, but sometimes there are hiccups and then I forget that they are the reason I have "no internet"... (no DNS resolution)

 

[Veldkornet]

No, local setup with standalone files in /jffs.

Hmmm. @RMerlin an idea to look into adding DNSCrypt like you did with DNSSEC? Or is it too much to maintain?

 

[plun]

Deer Ac68 owners! We are doomed

Well, I am not doomed with ASUS and master Merlin

I don't get your problem..... it must be something really specific!

 

[bayern1975]

@Merlin; please check why can't got picture from IPTV over udpxy in future update of firmware....with 380.57 it working but with latest 380.58 alpha3 not working....

sent from Kodi 17 Krypton

 

[RMerlin]

[pedant mode on] - NEW: Merged with 380_1354 GPL

BUT there is a commit message



It is great that Asus continuing to develop but GPL release always lags, and I guess not all GPL contains all for all models, and newer releases may not update binaries, and not need to be bumped in Merlin git

We are waiting for GPL from


But can also see betas in the official forum


So there is more in the pipeline!

Only the wl file was taken from 1355 because it was missing from the 1354 archive. It's still the same code as in 1354, I did not merge any of the few 1355 changes. So, the "based on 1354" is fully accurate.

23xx was the latest internal code as of last week, so I have no interest in the 18xx code... Just because Asus hasn't released a new firmware recently does not mean they have stopped development. People need to be patient, you cannot rush software development. It takes whatever time it takes.

I made a long post last year about it. With the increase in the amount of closed source bits, you can no longer expect every releases to support every models. The RT-AC56 and 68 are currently an example. Short of having full source code access (which is unlikely to happen), this will remain the norm now.

Sent from my Nexus 9 using Tapatalk

 

[RMerlin]

Hmmm. @RMerlin an idea to look into adding DNSCrypt like you did with DNSSEC? Or is it too much to maintain?

I have no plan to implement it. DNSSEC was trivial to add and required very little code changes.

Sent from my Nexus 9 using Tapatalk

 

[RMerlin]

@Merlin; please check why can't got picture from IPTV over udpxy in future update of firmware....with 380.57 it working but with latest 380.58 alpha3 not working....

sent from Kodi 17 Krypton

I don't use IPTV. Any fix will have to come from upstream (and Asus does have a lot of changes coming related to IPTV and vlans...)

Sent from my Nexus 9 using Tapatalk

 

[Veldkornet]

I have no plan to implement it. DNSSEC was trivial to add and required very little code changes.

Sent from my Nexus 9 using Tapatalk

Ah oki, no problem. If you ever change your mind though, I see DNSCrypt is available on Tomato Shibby and OpenWRT (if that makes it any easier to implement)

Also noticed you have it on your Wiki That helps me for now, although it would of course be awesome if it was built into the GUI


Sent from my iPhone using Tapatalk

 

[RMerlin]

Deer Ac68 owners! We are doomed

380.57 ( wireless issues)
380.58 Alpha 3( wireless issue), rebooted himself 2 times last night
and finally
beta firmware 9.0.0.4_380_2295-g1423616 (updated in 2016/2/24) , its the same.NAT disabled , No wireless for 2.4ghz clients( TESTED)

so.... there is nothing i can see " more in the pipeline "

Im a bit bored with Asus and theirs last GPL releases.
Reverting back to 378.56_2 and gonna close the case for the next few months !

Since this is a beta release, I strongly suggest reporting the issue to whoever provided you with that beta build. These are actually provided to allow users to provide feedback, and track down issues before the final release.

I know someone said Asus were notified, but it's possible that whoever notified them didn't provide enough details for Asus to reproduce the issue.

 

[bluepoint]

For 380_2295 it was just to notified a previous post.

If need to report issues it's in the first page for feedback.
http://www.snbforums.com/threads/be...6-beta-for-checking-bug-in-network-map.29269/
Also PM @vanic or @ASUS_ASUSWRT , all 68U/P owners needs to report the NAT disable bug, it will not be fix if we don't report its existence.

 

[john9527]

Thanks. I'm not at home right now so I can't look, I'll check either tonight or this weekend to see if anything comes up.

I looked at porting this over to my fork, and also had the problem. Found the offending line with some of my own debug code....the conversion from backquotes broke a function...

Original code
option=`eval "echo \\$$optionname"`
logger -t "openvpn-updown" "Processing option $option"

Feb 27 15:21:54 openvpn-updown: Processing option dhcp-option DNS 209.222.18.222
--------------------
Modified code
option=$(eval "echo \\$$optionname")
logger -t "openvpn-updown" "Processing option $option"

Feb 27 15:03:09 openvpn-updown: Processing option 4810optionname

Also, a couple of other things to consider with this implementation (at least I think these are true, please correct me if I'm wrong)
(1) If your VPN provider pushes multiple DNS servers which would be used in 'Exclusive' mode, only the first one will actually be used
(2) If you defined a CIDR range for VPN, then excludes from that range to WAN, it won't work. You need to specify each client individually

 

[LexLuthor]

• A few low-level/advanced settings were added to the new Tweaks section under Tools -> Other Settings. One of the settings there will allow you to disable hourly networkmap rescans, which were responsible for waking up sleeping LAN devices. Note that changing any of these settings will require a router reboot to fully be applied.

Files can be downloaded here:

https://www.mediafire.com/folder/bj94sbhrh7e49//Test Builds

Thank you for implementing this. So nice to not have my printer waking up all of the time. What's the negative of disabling this?

 

[CODYQX4]

I looked at porting this over to my fork, and also had the problem. Found the offending line with some of my own debug code....the conversion from backquotes broke a function...

Original code
option=`eval "echo \\$$optionname"`
logger -t "openvpn-updown" "Processing option $option"

Feb 27 15:21:54 openvpn-updown: Processing option dhcp-option DNS 209.222.18.222
--------------------
Modified code
option=$(eval "echo \\$$optionname")
logger -t "openvpn-updown" "Processing option $option"

Feb 27 15:03:09 openvpn-updown: Processing option 4810optionname

Also, a couple of other things to consider with this implementation (at least I think these are true, please correct me if I'm wrong)
(1) If your VPN provider pushes multiple DNS servers which would be used in 'Exclusive' mode, only the first one will actually be used
(2) If you defined a CIDR range for VPN, then excludes from that range to WAN, it won't work. You need to specify each client individually

Hm, I was wondering why stuff like 4810optionname was coming out of there. I had different numbers but couldn't read the options at all.