[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[Nullity]

Hi John - happy to report 17E8 is going strong and IPV6 (Comcast) is working great (so far; fingers crossed ). Thank you very much!!! I have been using your fork from day one (and Merlin prior).

P.S. I have searched high and low on IPV6 MTU and there is no one answer for the best setting (outside of the MIN 1280). I found one mention somewhere about Comcast IPV6 MTU being the same as their IPV4 of 1500 although elsewhere people say the IPV6 MTU has to be less than IPV4 for overhead. I have found 1432, 1360, lots of 1280, etc

I have set my MTU at 1500 and run some tests and it seems fine. I would like to know what others are doing or what is the right answer.

FWIW, my Cisco 877 defaults to 1500, AFAICT. ("show running-config all | include mtu" in Cisco IOS.)

Also, there is http://www.cisco.com/c/en/us/td/doc...n/15-2s/ip6-15-2s-book/ip6-mtu-path-disc.html which states:

Note
In IPv6, the minimum link MTU is 1280 octets. We recommend using an MTU value of 1500 octets for IPv6 links.

 

[Chrysalis]

The change is actually harder to explain than it was to implement....

- First, the change is only when you select VPN DNS 'Exclusive' mode AND check the 'Only VPN clients use VPN DNS' checkbox. Without checking the box, everything is the same as it's been in every prior release (including 17E5)

Now for the change at a high level with the checkbox checked...

V17E5 - dnsmasq (the router) acted as the DNS server for NON-VPN clients, and VPN Clients were routed directly to the VPN DNS server bypassing the router dnsmasq

V17E8 - it's reversed. dnsmasq (the router) is acting as the DNS server for the VPN clients. NON-VPN clients are routed around the router directly to your ISP's DNS servers (or whatever DNS server you specified in normal gui DNS setup).

The only place I can think of where this may affect things, is if you are also using Parental Controls/DNS Filter to also do DNS routing, in which case the definition of router would change. But with the new implementation, the definition of 'router' would be consistent with when a VPN was active and Exclusive mode set on for all the fork releases prior to V17.

hmm John i am not sure if this is good desired behaviour.

Personally I want to not ever touch my isp dns servers, and you bypassing the dnsmasq and routing directly to them seems at odds with expected behaviour. Can you please add a nvram switch that controls which behaviour is used?

 

[john9527]

hmm John i am not sure if this is good desired behaviour.

Personally I want to not ever touch my isp dns servers, and you bypassing the dnsmasq and routing directly to them seems at odds with expected behaviour. Can you please add a nvram switch that controls which behaviour is used?

No...no switch on this one. If you don't want this behavior, then don't check the checkbox that pops up when you select VPN exclusive mode (it defaults to unchecked). Also, it's not necessarily your ISP DNS servers....it's whatever you have set under the WAN DNS settings.

 

[john9527]

@john9527 - Does this update has the nvram set fw_nat_loopback=1 fix in it or do i have to wait for the V18 update ?

The V17E8 behavior is the same as V17E5....so you need to set this switch for your particular case. It will stick with and nvram commit until you do a factory reset.

For other readers....this user had run into a limitation of the older kernel used on the MIPS routers when using multiple functions that use iptables marks. In this case, using the ASUS NAT loopback method, as opposed to the default Merlin NAT loopback, was able to work around the problem. So, if you have an N16, N66 or AC66 and are having trouble with NAT loopback, this would be one of the things to try.

 

[john9527]

P.S. I have searched high and low on IPV6 MTU and there is no one answer for the best setting (outside of the MIN 1280). I found one mention somewhere about Comcast IPV6 MTU being the same as their IPV4 of 1500 although elsewhere people say the IPV6 MTU has to be less than IPV4 for overhead. I have found 1432, 1360, lots of 1280, etc

I may be mistaken as I'm certainly no expert on IPv6, but I expect we really won't know until much more until more of the internet becomes IPv6 enabled. And how they are providing that support, either natively or through some type of tunnel. I tested multiple values and everything seems to work for me as well with a 1500 MTU. In the end, I just decided to stay with 1452 (which was the value for when I was using the HE tunnel).

 

[Lotta Cox]

I always get weird bugs with PC's and networking. Here is one.
Today I could not log into my router or my repeater in windows 8.1 wired, I would get the login credentials window, then it would just hang for a long time. One time it got to the GUI, but it was soooo slow it was unusable. Using Iron Chrome. Same results with Firefox and IE 11.

So I reboot router. Nope
Reboot PC. Nope
Unplug all the network gear restart everything. Nope
So I try with my Dell 1820 windows tablet. Instant login. So I logout of the router.
Try again on PC. Nope. It's a multiboot PC. So I boot it to windows 10 and instant login.
I make a backup image of 8.1 and restore an image made from 3 days ago while in win10.
Boot to the restored 8.1 and I can login just fine.
IDK what happened to cause this. But it's good to have backups.

 

[Lotta Cox]

Well looks like that issue was caused by an update to Adguard.
It just updated to 6.0.223.1092 beta and I get the router login problem. Even with Adguard disabled, I can't get to the GUI.

 

[john9527]

@Lotta Cox Interesting.....another one to potentially add to the list of extensions that can cause problems. Thanks for the follow-up.
According to their site 'it works at a network level' and 'uses custom css elements'...lot of room for issues to arise.

 

[Chrysalis]

john can you redo the version with dnsmasq 2.76 please? I want to test it.

 

[john9527]

john can you redo the version with dnsmasq 2.76 please? I want to test it.

How's those old sayings go?

Patience is a virtue....
Good things come to those who wait....

 

[rtn66uftw]

Updated for both AC68U & N66U without any problem. So far so good. Thanks again John!

 

[YasharF]

I am running into an issue with OpenVPN on RT-N16 which seems to have been surfaced after updating from release 15 to 17. Prior to doing the update, I had OpenVPN installed using Entware on a USB stick, with start through post-mount script on JFFS and it was working. On RT-N16, native OpenVPN is disabled since the device doesn't have enough NVRAM for the certificates.

Since the upgrade, in the OpenVPN logs I get the following after each restart:

Fri Dec 31 16:00:35 2010 Socket Buffers: R=[118784->118784] S=[118784->118784]
Fri Dec 31 16:00:35 2010 ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such device (errno=19)
Fri Dec 31 16:00:35 2010 Exiting due to fatal error

If I try to start OpenVPN manually using "/opt/etc/init.d/S20openvpn start", the router crashes and needs to be unpluged and repluged into the power.

I also found this thread , and manually over SSH checked to see if running the following two commands make a difference

modprobe tun
openvpn --mktun --dev tun1

Maybe a clue, but not a total fix, since the router crashes anyway if I try to start OpenVPN manually using "/opt/etc/init.d/S20openvpn start", however the OpenVPN logs are no longer complaining as seen bellow:

Thu Apr 14 06:27:42 2016 OpenVPN 2.3.10 mipsel-openwrt-linux-gnu [SSL (PolarSSL)] [LZO] [EPOLL] [MH] [IPv6]
Thu Apr 14 06:27:42 2016 library versions: PolarSSL 1.3.16, LZO 2.08
Thu Apr 14 06:27:42 2016 Diffie-Hellman initialized with 2048 bit key
Thu Apr 14 06:27:42 2016 Socket Buffers: R=[118784->118784] S=[118784->118784]
Thu Apr 14 06:27:42 2016 TUN/TAP device tun0 opened
Thu Apr 14 06:27:42 2016 TUN/TAP TX queue length set to 100
Thu Apr 14 06:27:42 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Apr 14 06:27:42 2016 /sbin/ifconfig tun0 192.168.116.1 pointopoint 192.168.166.2 mtu 1500
Thu Apr 14 06:27:42 2016 /sbin/route add -net 192.168.116.0 netmask 255.255.255.0 gw 192.168.166.2
Thu Apr 14 06:27:42 2016 UDPv4 link local (bound): [undef]
Thu Apr 14 06:27:42 2016 UDPv4 link remote: [undef]
Thu Apr 14 06:27:42 2016 MULTI: multi_init called, r=256 v=256
Thu Apr 14 06:27:42 2016 IFCONFIG POOL: base=192.168.116.4 size=62, ipv6=0
Thu Apr 14 06:27:42 2016 Initialization Sequence Completed

I also checked to see if the tun.ko kernel module is loaded using "lsmod" and it was (probably because of "insmod tun.ko" that I have in firewall-start)

Any idea on how to get the OpenVPN to work again on RT-N16?

 

[john9527]

I am running into an issue with OpenVPN on RT-N16 which seems to have been surfaced after updating from release 15 to 17.

First, as a general comment and thing to remember....there is no guaranteed order in which many of the services will be started. As I did some additional 'hardening' of the ability of the router to recover from modem reboots it's entirely possible that the startup sequence may have changed slightly.

So, for your case I'd go after this one first.

Since the upgrade, in the OpenVPN logs I get the following after each restart:
Fri Dec 31 16:00:35 2010 Socket Buffers: R=[118784->118784] S=[118784->118784]
Fri Dec 31 16:00:35 2010 ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such device (errno=19)
Fri Dec 31 16:00:35 2010 Exiting due to fatal error

Notice that the timestamp is still showing that the router time hasn't been sync'd (most probably because other services have started faster, like the USB drives coming online) and VPN will never work without a valid timestamp. A couple of things you can try.....
- add a delay to your startup script
- check the nvram value of 'ntp-ready' (was the last sync successful) or 'ntp-sync' (this is unique to my fork and indicates if a time sync was ever successful) for a value of 1 before trying to start the VPN. The built in VPN does the valid time check before starting on the routers that support it.

Let's see if that gets things going.

 

[Sprokket]

Flashed a couple of old Dlink Routers back in the days, but if someone can point me to a guide on how to do the flash to get this firmware up and running.

 

[sbailey4]

Flashed a couple of old Dlink Routers back in the days, but if someone can point me to a guide on how to do the flash to get this firmware up and running.

Well 1st you need to state which router you are using in your posts here to help get the correct answer. Also take a look at post#1 to see if its a supported model for this firmware. If so, after you login the router, simply click on the firmware version up top (on most routers) and it will take you to the admin tab where you can select the firmware you want and upload. Pretty straight forward. Just reset to defaults afterwards and run back through setting it up as you want it.

 

[Sprokket]

Well 1st you need to state which router you are using in your posts here to help get the correct answer. Also take a look at post#1 to see if its a supported model for this firmware. If so, after you login the router, simply click on the firmware version up top (on most routers) and it will take you to the admin tab where you can select the firmware you want and upload. Pretty straight forward. Just reset to defaults afterwards and run back through setting it up as you want it.

RT-N66U
Supported

Been too long since i lurked around on forums, kinda forgot how they work. Thought I might had to flash it in a spesific way with usb or something. But if the built in way works im gonna do it as fast as i get home from work.

 

[YasharF]

First, as a general comment and thing to remember....there is no guaranteed order in which many of the services will be started. As I did some additional 'hardening' of the ability of the router to recover from modem reboots it's entirely possible that the startup sequence may have changed slightly.

So, for your case I'd go after this one first.



Notice that the timestamp is still showing that the router time hasn't been sync'd (most probably because other services have started faster, like the USB drives coming online) and VPN will never work without a valid timestamp. A couple of things you can try.....
- add a delay to your startup script
- check the nvram value of 'ntp-ready' (was the last sync successful) or 'ntp-sync' (this is unique to my fork and indicates if a time sync was ever successful) for a value of 1 before trying to start the VPN. The built in VPN does the valid time check before starting on the routers that support it.

Let's see if that gets things going.

Checking NTP:

[myUser@router]:/tmp/home/root# nvram show |grep ntp
size: 31308 bytes (1460 left)
ntp_server0=utcnist.colorado.edu
ntp_server1=time.nist.gov
ntp_ready=1
ntp_log_x=1
ntp_sync=1
ntp_server_tried=time.nist.gov
ntpd_server=0
ntp_update=1

In the post-mount script I added "sleep 30s" right before "/opt/etc/init.d/S20openvpn start", rebooted and it caused the crashing. More specifically, there was a period of time after a hard reboot (unplug and replug of the router) that I could connect to the web or the router and then it would stop. Fortunately, over a course of a couple of tries I got WinSCP to revert post-mount and now it is rebooting.

Another experiment to see if it is related to ntp/time: After the reboot I SSH's and tried the following. The router crashed at the end when stating "Starting openvpn..."

[myUser@router]:/tmp/home/root# date
Thu Apr 14 09:44:50 DST 2016
[myUser@router]:/tmp/home/root# modprobe tun
[myUser@router]:/tmp/home/root# openvpn --mktun --dev tun1
Thu Apr 14 16:45:15 2016 TUN/TAP device tun1 opened
Thu Apr 14 16:45:15 2016 Persist state set to: ON
[myUser@router]:/tmp/home/root# /opt/etc/init.d/S20openvpn start
Starting openvpn...

and the OpenVPN log section related to the above manual attempt:

Thu Apr 14 16:45:24 2016 OpenVPN 2.3.10 mipsel-openwrt-linux-gnu [SSL (PolarSSL)] [LZO] [EPOLL] [MH] [IPv6]
Thu Apr 14 16:45:24 2016 library versions: PolarSSL 1.3.16, LZO 2.08
Thu Apr 14 16:45:24 2016 Diffie-Hellman initialized with 2048 bit key
Thu Apr 14 16:45:24 2016 Socket Buffers: R=[118784->118784] S=[118784->118784]
Thu Apr 14 16:45:24 2016 TUN/TAP device tun0 opened
Thu Apr 14 16:45:24 2016 TUN/TAP TX queue length set to 100
Thu Apr 14 16:45:24 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Apr 14 16:45:24 2016 /sbin/ifconfig tun0 192.168.116.1 pointopoint 192.168.116.2 mtu 1500
Thu Apr 14 16:45:24 2016 /sbin/route add -net 192.168.116.0 netmask 255.255.255.0 gw 192.168.116.2
Thu Apr 14 16:45:24 2016 UDPv4 link local (bound): [undef]
Thu Apr 14 16:45:24 2016 UDPv4 link remote: [undef]
Thu Apr 14 16:45:24 2016 MULTI: multi_init called, r=256 v=256
Thu Apr 14 16:45:24 2016 IFCONFIG POOL: base=192.168.116.4 size=62, ipv6=0
Thu Apr 14 16:45:24 2016 Initialization Sequence Completed

It seems like that OpenVPN can manage to start, but for whatever reason the router doesn't like it and the router blows up.

I don't see a difference between a good and bad OpenVPN start in the logs. Just to check my sanity , the following is how the log looked like the last time when OpenVPN started before upgrading the firmware from 15 to 17:

Mon Mar 21 17:11:35 2016 OpenVPN 2.3.10 mipsel-openwrt-linux-gnu [SSL (PolarSSL)] [LZO] [EPOLL] [MH] [IPv6]
Mon Mar 21 17:11:35 2016 library versions: PolarSSL 1.3.16, LZO 2.08
Mon Mar 21 17:11:35 2016 Diffie-Hellman initialized with 2048 bit key
Mon Mar 21 17:11:35 2016 Socket Buffers: R=[118784->118784] S=[118784->118784]
Mon Mar 21 17:11:35 2016 TUN/TAP device tun0 opened
Mon Mar 21 17:11:35 2016 TUN/TAP TX queue length set to 100
Mon Mar 21 17:11:35 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Mar 21 17:11:35 2016 /sbin/ifconfig tun0 192.168.116.1 pointopoint 192.168.116.2 mtu 1500
Mon Mar 21 17:11:35 2016 /sbin/route add -net 192.168.116.0 netmask 255.255.255.0 gw 192.168.116.2
Mon Mar 21 17:11:35 2016 UDPv4 link local (bound): [undef]
Mon Mar 21 17:11:35 2016 UDPv4 link remote: [undef]
Mon Mar 21 17:11:35 2016 MULTI: multi_init called, r=256 v=256
Mon Mar 21 17:11:35 2016 IFCONFIG POOL: base=192.168.116.4 size=62, ipv6=0
Mon Mar 21 17:11:35 2016 Initialization Sequence Completed

 

[L&LD]

RT-N66U
Supported

Been too long since i lurked around on forums, kinda forgot how they work. Thought I might had to flash it in a spesific way with usb or something. But if the built in way works im gonna do it as fast as i get home from work.

A few tips:

Before you start, make a backup of your current setup so you can go back to something that works (quickly).

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

http://www.snbforums.com/threads/user-nvram-save-restore-utility-r23.19521/

The first link above spells out the steps for you. The utility in the link above will give you a text based capture of your settings (human readable).

I suggest you use both the built in gui 'save config' file feature and the NVRAM Save/Restore utility until you become more comfortable with the latter. And don't forget to download and put in a safe place the current firmware version you are running right now.

If you have any custom scripts created, make sure you back them up to another device or USB stick.

Now, unplug all USB devices from your router and reboot it. Wait 5 minutes or more before you attempt to flash a new firmware.

After patiently waiting for the router to fully boot, flash the firmware you want to test.

After it has flashed and the router has rebooted (wait 5 minutes again) reset to factory defaults at this point. When it has rebooted this final time, I would do a hard reboot (pull the power plug from the router, wait 2 minutes), then power it up and wait 5 minutes before you start configuring it (preferably manually).

When you have finished configuring it, do another hard reboot and now test how it is performing for you (after the requisite 5 minutes post boot time has passed).

 

[john9527]

It seems like that OpenVPN can manage to start, but for
whatever reason the router doesn't like it and blows up.

Other than the possibility of the start sequence (which was a problem with the Dec 31 date), I don't know what may have changed.

One thing I did notice.....you are making a persistent tunnel, tun1

[myUser@router]:/tmp/home/root# openvpn --mktun --dev tun1
Thu Apr 14 16:45:15 2016 TUN/TAP device tun1 opened
Thu Apr 14 16:45:15 2016 Persist state set to: ON

But OpenVPN is connecting on tun0

Thu Apr 14 16:45:24 2016 TUN/TAP device tun0 opened

 

[YasharF]

Other than the possibility of the start sequence (which was a problem with the Dec 31 date), I don't know what may have changed.

One thing I did notice.....you are making a persistent tunnel, tun1

[myUser@router]:/tmp/home/root# openvpn --mktun --dev tun1
Thu Apr 14 16:45:15 2016 TUN/TAP device tun1 opened
Thu Apr 14 16:45:15 2016 Persist state set to: ON

But OpenVPN is connecting on tun0

Thu Apr 14 16:45:24 2016 TUN/TAP device tun0 opened

You are correct. I just tried it with tun0 and it crashed again.

Could this be because of the dns service on the router? This is why I am suspicious: I had Pandora open this last time that it crashed, and after the router crashed I refreshed the page in Chrome and got:

This site can’t be reached
192.168.16.162 refused to connect.

ERR_CONNECTION_REFUSED​

192.168.16.162 is the IP for the router on the lan side which is also the DNS server on the lan. I'm surprised it says the router refused to connect since the initial URL was for Pandora.com, interestingly chrome also changed the URL to "http://192.168.16.162/index.asp" (not even using the port for the router web interface). I do have the following in my jffs/configs/dnsmasq.conf.add which is to get the DNS entries from OpenVPN clients pushed to the server instead of client's local ISP DNS.

interface=tun0

There are also some routes that I have added manually in the firewall script to get the VPN working. Let me know if I should post them here, in case if some change in the firmware may be causing issues with OpenVPN firewall routes.