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

[ColinTaylor]

@guss That looks essentially the same as mine so I can't see why it would have stopped working in the way you describe.

Can you remember the version number that worked before you updated?

EDIT: Just seen you updated post. So you were on 374.43_44E5j9527. I'd assumed you were trying to access devices on your LAN by IP address not name therefore whether the DNS server address is valid shouldn't matter.

Could you post the output of iptables-save please?

 

[guss]

You are right. The DNS shouldn't matter.

Here is the output from iptables-save:

ASUSWRT-Merlin RT-N66U_3.0.0.4 Mon Jul 13 01:59:47 UTC 2020
admin@RT-N66U-DD50:/tmp/home/root# iptables-save
# Generated by iptables-save v1.3.8 on Sat Oct 10 08:27:25 2020
*nat
:PREROUTING ACCEPT [277:27597]
:POSTROUTING ACCEPT [45:2771]
:OUTPUT ACCEPT [24:2519]
:DNSFILTER - [0:0]
:LOCALSRV - [0:0]
:PUPNP - [0:0]
:VSERVER - [0:0]
:VUPNP - [0:0]
-A PREROUTING -p udp -m udp --dport 1195 -j ACCEPT
-A PREROUTING -p udp -m udp --dport 1194 -j ACCEPT
-A PREROUTING -d xx.xx.xx.xx -j VSERVER
-A POSTROUTING -o eth0 -j PUPNP
-A POSTROUTING -s ! xx.xx.xx.xx -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.1.0/255.255.255.0 -d 192.168.1.0/255.255.255.0 -o br0 -j MASQUERADE
-A VSERVER -p tcp -m tcp --dport 22 -j DNAT --to-destination 192.168.1.51:22
-A VSERVER -p tcp -m tcp --dport 8920 -j DNAT --to-destination 192.168.1.51:8920
-A VSERVER -p udp -m udp --dport 9987 -j DNAT --to-destination 192.168.1.51:9987
-A VSERVER -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.1.51:443
-A VSERVER -j VUPNP
COMMIT
# Completed on Sat Oct 10 08:27:25 2020
# Generated by iptables-save v1.3.8 on Sat Oct 10 08:27:25 2020
*mangle
:PREROUTING ACCEPT [171803:21072551]
:INPUT ACCEPT [94177:8999853]
:FORWARD ACCEPT [62308:8055822]
:OUTPUT ACCEPT [92948:55579671]
:POSTROUTING ACCEPT [155280:63645397]
-A PREROUTING -i tun21 -j MARK --set-mark 0x1/0xf
-A PREROUTING -i tun22 -j MARK --set-mark 0x1/0xf
-A FORWARD -s 192.168.1.0/255.255.255.0 -d 192.168.1.0/255.255.255.0 -o br0 -j MARK --set-mark 0x1/0x1ff
COMMIT
# Completed on Sat Oct 10 08:27:25 2020
# Generated by iptables-save v1.3.8 on Sat Oct 10 08:27:25 2020
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [5129:1371501]
:FUPNP - [0:0]
:PControls - [0:0]
:PTCSRV - [0:0]
:logaccept - [0:0]
:logdrop - [0:0]
-A INPUT -i tun21 -j ACCEPT
-A INPUT -p udp -m udp --dport 1195 -j ACCEPT
-A INPUT -i tun22 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22 -j PTCSRV
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -j DROP
-A FORWARD -i br0 -o eth0 -p ipv6-auth -j DROP
-A FORWARD -i tun21 -j ACCEPT
-A FORWARD -i tun22 -j ACCEPT
-A FORWARD -i br0 -o eth0 -p ipv6-crypt -j DROP
-A FORWARD -i br0 -o eth0 -p gre -j DROP
-A FORWARD -i br0 -o eth0 -p udp -m udp --dport 4500 -j DROP
-A FORWARD -i br0 -o eth0 -p udp -m udp --dport 500 -j DROP
-A FORWARD -i br0 -o eth0 -p udp -m udp --dport 1701 -j DROP
-A FORWARD -i br0 -o eth0 -p tcp -m tcp --dport 1723 -j DROP
-A FORWARD -i eth0 -m state --state INVALID -j DROP
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ! br0 -o eth0 -j DROP
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -i eth0 -p icmp -j DROP
-A FORWARD -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j ACCEPT
-A FORWARD -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j ACCEPT
-A FORWARD -i eth0 -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -i br0 -j ACCEPT
-A PControls -j ACCEPT
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -m state --state NEW -m limit --limit 4/sec -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP
COMMIT
# Completed on Sat Oct 10 08:27:25 2020

 

[smyr]

Disabling JFFS scripts in the GUI is certainly an option, but it’s overkill. Entware can be removed by:

• Eject the USB from the GUI to stop any installed services that may be running from Entware.
• Delete the Entware line from /jffs/scripts/post-mount or just delete the /jffs/scripts/post-mount script if nothing else is using it. Same for unmount and services-stop scripts.
• rm /tmp/opt
• Plug the USB back in and remove the /tmp/mnt/<usbname>/entware directory.

There may be better prescribed ways to get rid of Entware, but this is what I’d do.

EDIT: added 3rd bullet to remove link

Ok, thanks. Will try that.

You know the answer to my question regarding flashing from Merlin to Freshtomato?!
Anyone else try Freshtomato!?

Thanks

 

[guss]

I tested some more and still can't find the problem. If I disable "Push LAN to clients" I can't even ping the router itself via 192.168.1.1. If it's enabled this does work, so "Push LAN to clients" does something.

I had a look at the server config and it looks well for me:

# Automatically generated configuration
daemon
topology subnet
server 10.8.1.0 255.255.255.0
local xx.xx.xx.xx        
proto udp    
port 1194    
dev tun22    
txqueuelen 1000
ncp-ciphers AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
cipher AES-128-CBC          
comp-lzo adaptive          
keepalive 15 60
verb 3        
push "route 192.168.1.0 255.255.255.0"                    
client-config-dir ccd      
client-to-client            
duplicate-cn  
push "dhcp-option DOMAIN orion"                          
push "dhcp-option DNS 192.168.1.1"                        
tls-auth static.key        
auth-user-pass-verify /usr/sbin/ovpnauth.sh via-file      
script-security 2          
ca ca.crt    
dh dh.pem    
cert server.crt
key server.key
status-version 2            
status status 10            
             
# Custom Configuration

I guess my next step is setting up a OpenVPN server on my raspberry pi and check if this works.

Edit: I installed PiVPN on my raspberry and it works fine. So my guess is now, that the OpenVPN is broken in the last firmware for the Asus RT-N66U. Now I use the Pi for redirect traffic with the benefit of a Pi-hole.
Only for work I need a connection without redirection. The Asus works with a TAP interface. With it I can connect to my LAN. But with my preferred way TUN it's not possible. I have now limited the TAP OpenVPN on my Asus for my work ip only and deactivated the second OpenVPN on the Asus. So I'm fine for now.

 

[ColinTaylor]

Edit: I installed PiVPN on my raspberry and it works fine. So my guess is now, that the OpenVPN is broken in the last firmware for the Asus RT-N66U. Now I use the Pi for redirect traffic with the benefit of a Pi-hole.
Only for work I need a connection without redirection. The Asus works with a TAP interface. With it I can connect to my LAN. But with my preferred way TUN it's not possible. I have now limited the TAP OpenVPN on my Asus for my work ip only and deactivated the second OpenVPN on the Asus. So I'm fine for now.

Thanks for the update. Your iptables output looks fine so I don't know what the problem is. Maybe some sort of bug in the routing table on the router. Anyway, unless you want to debug this any further it looks like you have a workaround.

 

[guss]

Thanks ColinTaylor and yes, for me the matter is settled for the time being. But if the problem occurs with other people and I can somehow help to fix it, I'm happy to help.

 

[ngc5195]

Hello everybody

I have an Asus RT-N66U with Firmware:374.43_44EAj9527.

On it I use two OpenVPN servers for many years without a problem. One does direct clients to redirect Internet traffic and one does not.

Since the latest update I have the problem that the option "Push LAN to clients" seems not longer to work. I can connect to the RT-N66U without any problem but I can't connect or ping any devices in my LAN. Normally I only connect to my Ubuntu desktop where a vnc server runs. But I can't connect to my Raspberry Pi either. Only the LAN ip of the RT-N66U itself does respond.

There is no firewall running on the Raspberry Pi and I didn't change the ufw settings on the Ubuntu client:
Anywhere ALLOW IN 192.168.1.0/24
Anywhere ALLOW IN 10.8.0.0/24
Anywhere ALLOW IN 10.8.1.0/24

Does anyone have the same problem?

Can I add something via the custom configuration to fix my problem or has anyone another suggestion for me?

Many thanks in advance
Guss

I've been having the same issue on recent versions. I can't ping any devices on my LAN either; this used to work fine...
I think it may have something to do with changes on the OpenVPN side, because using the latest OpenVPN Connect iOS client (official) I cannot get it to work at all. However, I was able to get it to work using Passepartout.
Additionally, I disabled the Direct clients to redirect Internet traffic and Push LAN to clients options and instead am manually pushing the following:

push 'redirect-gateway def1'
push 'route 192.168.2.0 255.255.255.0'

 

[guss]

Thanks ngc5195. For me that doesn't work either. I experimented with custom code and manually push my LAN before and just tested your suggestion again. But I can't connect to my LAN.

 

[ColinTaylor]

Thanks ngc5195. For me that doesn't work either. I experimented with custom code and manually push my LAN before and just tested your suggestion again. But I can't connect to my LAN.

The most noticeable change between the firmware you previously had and the current one is the change to OpenVPN 2.4.9. In light of @ngc5195's post I'm wondering whether there's a compatibility issue on the client side rather than the router. Can you have a look in the client's log and see if there are any clues there?

 

[guss]

I started testing with Windows 10 64bit OpenVPN client in version 2.4.x. I don't remember the exact version and at some point installed the newest available client (OpenVPN-2.5-rc2-I601-2-amd64.msi). The same problem occurred on my Android (v8.1) phone running LineageOS 15.1 with OpenVPN for Android 0.7.21. Both clients worked perfectly before. So to be honest, I don't think this is a client issue.

But nevertheless I post you the logs.

Windows:

2020-10-12 19:27:55 Note: Treating option '--ncp-ciphers' as  '--data-ciphers' (renamed in OpenVPN 2.5).
2020-10-12 19:27:55 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2020-10-12 19:27:55 OpenVPN 2.5_rc2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 30 2020
2020-10-12 19:27:55 Windows version 10.0 (Windows 10 or greater) 64bit
2020-10-12 19:27:55 library versions: OpenSSL 1.1.1h  22 Sep 2020, LZO 2.10
Enter Management Password:
2020-10-12 19:28:12 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:1194
2020-10-12 19:28:12 UDP link local: (not bound)
2020-10-12 19:28:12 UDP link remote: [AF_INET]xx.xx.xx.xx:1194
2020-10-12 19:29:13 [UNDEF] Inactivity timeout (--ping-restart), restarting
2020-10-12 19:29:13 SIGUSR1[soft,ping-restart] received, process restarting
2020-10-12 19:29:18 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:1194
2020-10-12 19:29:18 UDP link local: (not bound)
2020-10-12 19:29:18 UDP link remote: [AF_INET]xx.xx.xx.xx:1194
2020-10-12 19:29:18 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2020-10-12 19:29:18 [RT-N66U] Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:1194
2020-10-12 19:29:19 open_tun
2020-10-12 19:29:19 tap-windows6 device [OpenVPN TAP-Windows6] opened
2020-10-12 19:29:19 Set TAP-Windows TUN subnet mode network/local/netmask = 10.8.0.0/10.8.0.2/255.255.255.0 [SUCCEEDED]
2020-10-12 19:29:19 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.2/255.255.255.0 on interface {8B1EBAC6-1D99-49CD-8AE0-C595B27095B6} [DHCP-serv: 10.8.0.254, lease-time: 31536000]
2020-10-12 19:29:19 Successful ARP Flush on interface [18] {8B1EBAC6-1D99-49CD-8AE0-C595B27095B6}
2020-10-12 19:29:19 IPv4 MTU set to 1500 on interface 18 using service
2020-10-12 19:29:24 Initialization Sequence Completed

Android:

2020-10-12 19:46:15 F-Droid built and signed version 0.7.21 running on ZTE ZTE A2017G (ailsa_ii), Android 8.1.0 (OPM7.181205.001) API 27, ABI arm64-v8a, (ZTE/P996A01_O/ailsa_ii:8.0.0/OPR1.170623.032/20180718.100630:user/release-keys)

[...] (edited because post exceeds 10000 character)

2020-10-12 19:46:52 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2020-10-12 19:46:52 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2020-10-12 19:46:52 LZO compression initializing
2020-10-12 19:46:52 Control Channel MTU parms [ L:1622 D:1184 EF:66 EB:0 ET:0 EL:3 ]
2020-10-12 19:46:52 MANAGEMENT: >STATE:1602524812,RESOLVE,,,,,,
2020-10-12 19:46:53 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
2020-10-12 19:46:53 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
2020-10-12 19:46:53 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
2020-10-12 19:46:53 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:1194
2020-10-12 19:46:53 Socket Buffers: R=[212992->212992] S=[212992->212992]
2020-10-12 19:46:53 MANAGEMENT: CMD 'needok 'PROTECTFD' ok'
2020-10-12 19:46:53 UDP link local: (not bound)
2020-10-12 19:46:53 UDP link remote: [AF_INET]xx.xx.xx.xx:1194
2020-10-12 19:46:53 MANAGEMENT: >STATE:1602524813,WAIT,,,,,,
2020-10-12 19:46:53 MANAGEMENT: >STATE:1602524813,AUTH,,,,,,
2020-10-12 19:46:53 TLS: Initial packet from [AF_INET]xx.xx.xx.xx:1194, sid=e5ffad75 20efc2e9
2020-10-12 19:46:53 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2020-10-12 19:46:53 VERIFY KU OK
2020-10-12 19:46:53 Validating certificate extended key usage
2020-10-12 19:46:53 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2020-10-12 19:46:53 VERIFY EKU OK
2020-10-12 19:46:53 VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=ASUS, CN=RT-N66U, emailAddress=me@myhost.mydomain
2020-10-12 19:46:53 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 1024 bit RSA, signature: RSA-SHA256
2020-10-12 19:46:53 [RT-N66U] Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:1194
2020-10-12 19:46:54 MANAGEMENT: >STATE:1602524814,GET_CONFIG,,,,,,
2020-10-12 19:46:54 SENT CONTROL [RT-N66U]: 'PUSH_REQUEST' (status=1)
2020-10-12 19:46:54 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DOMAIN orion,dhcp-option DNS 192.168.1.1,route 192.168.1.0 255.255.255.0,route-gateway 10.8.0.1,topology subnet,ping 15,ping-restart 60,ifconfig 10.8.0.3 255.255.255.0,peer-id 1,cipher AES-128-GCM'
2020-10-12 19:46:54 OPTIONS IMPORT: timers and/or timeouts modified
2020-10-12 19:46:54 OPTIONS IMPORT: --ifconfig/up options modified
2020-10-12 19:46:54 OPTIONS IMPORT: route options modified
2020-10-12 19:46:54 OPTIONS IMPORT: route-related options modified
2020-10-12 19:46:54 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2020-10-12 19:46:54 OPTIONS IMPORT: peer-id set
2020-10-12 19:46:54 OPTIONS IMPORT: adjusting link_mtu to 1625
2020-10-12 19:46:54 OPTIONS IMPORT: data channel crypto options modified
2020-10-12 19:46:54 Data Channel: using negotiated cipher 'AES-128-GCM'
2020-10-12 19:46:54 Data Channel MTU parms [ L:1553 D:1450 EF:53 EB:406 ET:0 EL:3 ]
2020-10-12 19:46:54 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
2020-10-12 19:46:54 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
2020-10-12 19:46:54 ROUTE_GATEWAY 127.100.103.119 IFACE=android-gw
2020-10-12 19:46:54 do_ifconfig, ipv4=1, ipv6=0
2020-10-12 19:46:54 MANAGEMENT: >STATE:1602524814,ASSIGN_IP,,10.8.0.3,,,,
2020-10-12 19:46:54 MANAGEMENT: CMD 'needok 'IFCONFIG' ok'
2020-10-12 19:46:54 MANAGEMENT: >STATE:1602524814,ADD_ROUTES,,,,,,
2020-10-12 19:46:54 MANAGEMENT: CMD 'needok 'ROUTE' ok'
2020-10-12 19:46:54 MANAGEMENT: CMD 'needok 'DNSSERVER' ok'
2020-10-12 19:46:54 MANAGEMENT: CMD 'needok 'DNSDOMAIN' ok'
2020-10-12 19:46:54 MANAGEMENT: CMD 'needok 'PERSIST_TUN_ACTION' OPEN_BEFORE_CLOSE'
2020-10-12 19:46:54 Opening tun interface:
2020-10-12 19:46:54 Local IPv4: 10.8.0.3/24 IPv6: (not set) MTU: 1500
2020-10-12 19:46:54 DNS Server: 192.168.1.1, Domain: orion
2020-10-12 19:46:54 Routes: 10.8.0.0/24, 192.168.1.0/24
2020-10-12 19:46:54 Routes excluded: 
2020-10-12 19:46:54 VpnService routes installed: 10.8.0.0/24, 192.168.1.0/24
2020-10-12 19:46:54 Disallowed VPN apps:
2020-10-12 19:46:54 MANAGEMENT: CMD 'needok 'OPENTUN' ok'
2020-10-12 19:46:54 Initialization Sequence Completed
2020-10-12 19:46:54 MANAGEMENT: >STATE:1602524814,CONNECTED,SUCCESS,10.8.0.3,xx.xx.xx.xx,1194,,
2020-10-12 19:46:55 Debug state info: CONNECTED LTE to MOBILE internet, pause: userPause, shouldbeconnected: true, network: SHOULDBECONNECTED

I can't see anything wrong there but perhaps somebody else can.

 

[ColinTaylor]

UPDATE:

@guss @ngc5195 I've just dug out my old RT-N66U and installed V44EA on it. I've configured it as identical as I can determine to guss' setup based on the information posted (although some of the port numbers appear to have been changed in the later posts). I had no problem at all pinging a Windows PC connected to it once I had disabled the Windows Firewall. I'm using the latest version of standard free Android client.

So at the moment I'm at a loss as to why you're having this problem. All I can suggest is that you a) backup your current router settings, b) do a factory reset, and c) do a minimal setup just enough to test the VPN configuration. If it still doesn't work then you can always restore your settings from the backup file.

---------------------------------------------------------------------------

I can't see anything wrong there but perhaps somebody else can.

Thanks for that. Alas I can't see anything wrong with that either. If you have the time could you post the output of the following (obviously when it's in the "non-working" configuration). But I'm clutching at straws here.

route -n
cat /proc/sys/net/ipv4/ip_forward
cat /proc/sys/net/ipv4/conf/*/forwarding
cat /proc/sys/net/ipv4/conf/*/rp_filter
ip rule show

 

[guss]

I did it twice, once with "Push LAN to clients Yes" and once with "No" and this custom configuration:

route 192.168.1.0 255.255.255.0
push 'route 192.168.1.0 255.255.255.0'

Direct clients to redirect Internet traffic in both cases "No"

The output is identical:

route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xx.xx.xx.1      0.0.0.0         255.255.255.255 UH    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun22
xx.xx.xx.0      0.0.0.0         255.255.240.0   U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         xx.xx.xx.1      0.0.0.0         UG    0      0        0 eth0

cat /proc/sys/net/ipv4/ip_forward

1

cat /proc/sys/net/ipv4/conf/*/forwarding

1
1
1
1
1
1
1
1
1

cat /proc/sys/net/ipv4/conf/*/rp_filter

-1
1
1
1
1
1
1
1
1

ip rule show

0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default

Edit: Oh, I see just now you edited your post. Thank you very much for your time ColinTaylor. It's good to know it's working for you with the same router model. So the problem has to be something else in my case. If I find the solution I will post it.

Edit2: I did a factory reset and somehow bricked my router. It doesn't boot anymore, I can't connect in any way. The poor thing is dead. I have no idea what happened.

 

[nekkihs]

Just register to say thank you to John
My router had been running laggy and buggy ever since they stop updating asuswrt-merlin for ac66u
After a firmware restoration and clean install of your latest release, it's running buttery smooth now

 

[SomeWhereOverTheRainBow]

What is the main differences with ipv6 setup on John's fork versus ipv6 on merlin

 

[ColinTaylor]

What is the main differences with ipv6 setup on John's fork versus ipv6 on merlin

What type of IPv6 connection do you have, native or static?

 

[SomeWhereOverTheRainBow]

What type of IPv6 connection do you have, native or static?

Native

 

[ColinTaylor]

Native

I don't have IPv6 myself but this is what I see in the GUI:

 

[djphilosophy]

I have an RT-N66U running this latest version (V44EA) in AP mode. I remember setting the IP to 192.168.101.2 (router on 101.1), and the primary router shows the N66U at this address. Everything works fine, except ... I can no longer access the admin page at the assigned IP address.

I've tried:

• Connecting both via http and https
• Connecting directly via LAN port
• Disconnecting WAN cable, setting PC manual IP to 192.168.0.3 assuming N66U at 192.168.0.1
• Same as above with 192.168.1.3 to 192.168.1.1

What's strange is I could swear I remember accessing the admin page after putting it into AP mode when first setting it up a few weeks ago. I know I can just reset the router to regain access, but obviously I'm trying to avoid that given everything is working - plus this has me wondering if this is a bug or by design.

Is there a way to access the admin page while in AP mode? A default IP address it takes if it isn't assigned one?

 

[ColinTaylor]

@djphilosophy Download the ASUS Device Discovery utility and see if that can find it.

https://dlcdnets.asus.com/pub/ASUS/wireless/RT-AC68U/Discovery_v1480.zip

 

[djphilosophy]

@djphilosophy Download the ASUS Device Discovery utility and see if that can find it.

https://dlcdnets.asus.com/pub/ASUS/wireless/RT-AC68U/Discovery_v1480.zip

Thanks for the reply. It finds it at 192.168.101.2 as well. If I click configure there it attempts to load the webpage, which gives the error "refused to connect" (same as before - should have mentioned that).

Worth adding that I've attempted access on both Linux and now Windows (after running the Device Discovery app just now), so it's not an OS/firewall issue.

Edit: Also tried unplugging the WAN cable, rebooting and running Device Discovery again. Same IP, still no access.