[Beta] Asuswrt-Merlin 380.65 Beta is now available

[Jonesy]

Hi there,

I'm experiencing a problem on my Asus RT-AC88u

I upgraded from the 380.64_2 which didn't seem to be having any connectivity issues, but upon trying the 3850.65 beta, I am, specifically around the appearance of the term "WAN Connection: ISP's DHCP did not function properly."

It's also important to note that I had a similar issue when using the ASUSwrt 380.4180 build. Changing to Merlin's 380.64_2 seemed to fix that.

I read that the 380.65 beta incorporates 380.4180, so seems as though it may be an issue with the 4180 build in particular??

I'm sorry for posting much that may be irrelevant, but I'm not sure what is and isn't relevant to my issue in the log. I am also seeming to be having trouble uploading a text file of the log as well...

Am having trouble uploading the plain txt file logs, so have uploaded them to Google Drive here:

Merlin 380.65 Beta Log
asuswrt 380.4180 Log

When I had the asuswrt 4180 installed, it would seem as though the connection would be lost from anywhere from 5 minutes to a couple of hours. I haven't used the merlin beta for long enough to see if that behaviour is the same.

Any ideas?

Cheers,
Jonesy

 

[Wutikorn]

Hi there,

I'm experiencing a problem on my Asus RT-AC88u

I upgraded from the 380.64_2 which didn't seem to be having any connectivity issues, but upon trying the 3850.65 beta, I am, specifically around the appearance of the term "WAN Connection: ISP's DHCP did not function properly."

It's also important to note that I had a similar issue when using the ASUSwrt 380.4180 build. Changing to Merlin's 380.64_2 seemed to fix that.

I read that the 380.65 beta incorporates 380.4180, so seems as though it may be an issue with the 4180 build in particular??

I'm sorry for posting much that may be irrelevant, but I'm not sure what is and isn't relevant to my issue in the log. I am also seeming to be having trouble uploading a text file of the log as well...

Am having trouble uploading the plain txt file logs, so have uploaded them to Google Drive here:

Merlin 380.65 Beta Log
asuswrt 380.4180 Log

When I had the asuswrt 4180 installed, it would seem as though the connection would be lost from anywhere from 5 minutes to a couple of hours. I haven't used the merlin beta for long enough to see if that behaviour is the same.

Any ideas?

Cheers,
Jonesy

You are not using Dual WAN are you? I got those messages when using Dual WAN in failover mode. However, if you are not, have you tried restarting router after firmware installation?

 

[Jonesy]

You are not using Dual WAN are you? I got those messages when using Dual WAN in failover mode. However, if you are not, have you tried restarting router after firmware installation?

No, not using dual WAN.

I had tried rebooting and restoring to factory defaults. Neither seems to fix the issue on either firmware (380.65 beta or 380.4180)

 

[gffmac]

No, not using dual WAN.

I had tried rebooting and restoring to factory defaults. Neither seems to fix the issue on either firmware (380.65 beta or 380.4180)

I presume you tried to powercycle the modem too?

 

[Jonesy]

I presume you tried to powercycle the modem too?

Yes, that also.

 

[MarkRH]

Been using beta1 for a couple days now on my RT-AC68U. One thing that seems to have been fixed for me is that when I click the shortcut for the daily traffic monitor and it asks me to login, it redirects back to that page now instead of the network map. So far so good.

 

[rlcronin]

Yes, that also.

I've had this happen several times of late when upgrading Merlin firmware. I found that I need to power off the modem for a fairly long time (at least 15 minutes, perhaps more, I don't have a precise measurement) in order to solve it. Perhaps the procedure to force the modem to explicitly drop its WAN IP given above might help?

/bin/kill -USR2 $(/bin/pidof udhcpc) # release the WAN IP
/usr/sbin/nvram unset wan0_ipaddr # forget about it
/usr/sbin/nvram unset wan_ipaddr # forget about it
/usr/sbin/nvram commit
/sbin/halt
--
bc

 

[elorimer]

Been using beta1 for a couple days now on my RT-AC68U. One thing that seems to have been fixed for me is that when I click the shortcut for the daily traffic monitor and it asks me to login, it redirects back to that page now instead of the network map. So far so good.

Is this new? For a while I've used shortcuts to the Wake-on-Lan page to wake up a server, and after a stop on the login page it goes directly.

 

[RMerlin]

I just tried playing around with some of the new OpenVPN 2.4 options and I'm getting an error in the system log of:
Jan 17 20:37:41 openvpn[1067]: tls-crypt unwrap error: packet too short

The three things I'm playing around with - and I should probably have done one at a time - is the compression LZ4, cipher negotiation, and TLS control channel encryption. I see that in my OVPN file that there's a static key for <tls-crypt> but is there supposed to be a declaration above to use it? The static key also seems pretty short compared to the others, but I'm not exactly certain how long it should be. Google pointed me to another thread (with another guy who also has an AC87U) about creating a new dhparam. Same fix?

tls-crypt worked for me when I tested it.

The key is not a key/cert pair like used for other fields, it's a static key that must be generated by the openvpn exe:

openvpn --genkey --secret /tmp/file.txt

See the OpenVPN 2.4 manual for more information.

 

[bradbort]

Zikes! I spoke too soon. The MFC stopped scanning wirelessly again. Error messages say cannot connect. Rebooting MFC did not clear the error this time. Setting back to the last non-beta software fixed the problem again.

I did some more trouble shooting. on the 88u router, rolling back to the last Merlin non beta/alpha build, all scanning functionality works. Upgrading to the newest alpha, it stops. I then went back and reflashed the latest ASUS stock firmware that the new alpha incorporates. No scanning. Reflashed the Merlin version that was working, scanning started working again, although I did have to reboot my router.

My sense is that the newest ASUS code has an issue with wireless scanning in some instances, and also wireless sonos when the sonos is set up to use wifi instead of its own mesh network. I'm not sure where to go from here, since I seem to have to avoid any firmware that uses the newest asus firmware.

 

[Arkadiusz]

Managed to restore to very old original asus firmware and installed the stable asus-merlin version for now.

 

[MarkRH]

Is this new? For a while I've used shortcuts to the Wake-on-Lan page to wake up a server, and after a stop on the login page it goes directly.

Well, I just know that in 380.64 that stopped working for me and now it is. Coincidence, hard to say.

 

[jimf]

380.65 adds a new update-notification user script. Here is an example script that will email you when a new firmware is available. This script is designed for GMail, shouldn't be too hard to adapt to your own ISP's SMTP.

#!/bin/sh

# SMTP parameters
SMTP="smtp.gmail.com"
PORT="465"
USERNAME="you@gmail.com"
PASSWORD="gmail-password"

# Mail Enveloppe
FROM_NAME="Router"
FROM_ADDRESS="you@gmail.com"
TO_NAME="Your Name"
TO_ADDRESS="you@gmail.com"


### Do not change below

# Retrieve version
TMPVERS=$(nvram get webs_state_info)
VERS=${TMPVERS:5:3}.${TMPVERS:8:10}
ROUTER_IP=$(nvram get lan_ipaddr)

echo "From: \"$FROM_NAME\" <$FROM_ADDRESS>" > /tmp/mail.txt
echo "To: \"$TO_NAME\" <$TO_ADDRESS>" >> /tmp/mail.txt
echo "Subject: New router firmware notification" >> /tmp/mail.txt
echo "" >> /tmp/mail.txt
echo "New firmware version $VERS is now available for your router at $ROUTER_IP." >> /tmp/mail.txt


curl --url smtps://$SMTP:$PORT \
  --mail-from "$FROM_ADDRESS" --mail-rcpt "$TO_ADDRESS" \
  --upload-file /tmp/mail.txt \
  --ssl-reqd \
  --user "$USERNAME:$PASSWORD" --insecure


rm /tmp/mail.txt

Might be a good idea to define an application password to use here, since your GMail password would end up stored in the clear in that script.

I tried modifying this script. Works fine on Cox email, but I'm having an issue with a server that I use for mail running the qmail server. I had a problem (yet to be solved) with certs and TLS, so I just tried mailing in the clear. It looks like the message gets transferred, but there is this error at the end (in curl verbose mode):

* Connection #0 to host mail.xxxx.com left intact
curl: (56) Failure when receiving data from the peer

Verbose mode also gives this tidbit:
* We are completely uploaded and fine
< 451 See http://pobox.com/~djb/docs/smtplf.html.

This page talks about ending the message with a "." surrounded by crlf's and how the error probably is a malformed end of message as qmail is extra picky about standards.

My question to you smart guys: Is there an easy way to capture the output of curl in this case to verify the ending set of characters? I can't see any server logs so if I wanted to do that, I'd have to set up a qmail and hope the log shows something.

 

[bbunge]

I did some more trouble shooting. on the 88u router, rolling back to the last Merlin non beta/alpha build, all scanning functionality works. Upgrading to the newest alpha, it stops. I then went back and reflashed the latest ASUS stock firmware that the new alpha incorporates. No scanning. Reflashed the Merlin version that was working, scanning started working again, although I did have to reboot my router.

My sense is that the newest ASUS code has an issue with wireless scanning in some instances, and also wireless sonos when the sonos is set up to use wifi instead of its own mesh network. I'm not sure where to go from here, since I seem to have to avoid any firmware that uses the newest asus firmware.

I've noticed this issue reported with HP printer, scanner, copiers and possible one other brand. Am wondering if this is actually an issue with Windows 10 like I had with a newly installed Windows 10 PC a couple of months ago. I had problems getting the HP software to connect to the printer. It would find it but not connect. What finally brought the issue to a head is when Windows would not connect to the network. Nothing had changed in the router or the HP printer as the customers tablet and phone still could print. Issue was with a Windows update that messed up winsock. Problem solved by:
From an admin command prompt:

netsh winsock reset catalog
netsh int ipv4 reset reset.log

Reboot PC.
Microsoft was supposed to issue an update to fix this but...

 

[effortless]

I've noticed this issue reported with HP printer, scanner, copiers and possible one other brand. Am wondering if this is actually an issue with Windows 10 like I had with a newly installed Windows 10 PC a couple of months ago. I had problems getting the HP software to connect to the printer. It would find it but not connect. What finally brought the issue to a head is when Windows would not connect to the network. Nothing had changed in the router or the HP printer as the customers tablet and phone still could print. Issue was with a Windows update that messed up winsock. Problem solved by:
From an admin command prompt:

netsh winsock reset catalog
netsh int ipv4 reset reset.log

Reboot PC.
Microsoft was supposed to issue an update to fix this but...

I have a couple of macs also unable to find the printers. All the devices were able to found prior to the first beta.


Sent from my iPhone using Tapatalk

 

[Gitsum]

Hi there,

I'm experiencing a problem on my Asus RT-AC88u

I upgraded from the 380.64_2 which didn't seem to be having any connectivity issues, but upon trying the 3850.65 beta, I am, specifically around the appearance of the term "WAN Connection: ISP's DHCP did not function properly."

I was getting that same error with a new ISP I had signed up with. For some reason they're DHCP server didn't like me rebooting the router to much. After many phone calls and the usual "did you try restarting your router?" questions and "check the wiring" the fix was for my ISP to give me a fixed IP address. Never had a problem since. Might try asking your ISP for the same.

 

[el_Captain]

tls-crypt worked for me when I tested it.

The key is not a key/cert pair like used for other fields, it's a static key that must be generated by the openvpn exe:

openvpn --genkey --secret /tmp/file.txt

See the OpenVPN 2.4 manual for more information.

OK - I think I'm heading the right direction after reading over that link - thank you. I've generated the shared secret and I've added a secret segment to the ovpn file but where on the router side does this key go? Sorry if this is hijacking the 65 beta thread. I've been able to get literally everything else working but this encrypted TLS channel business.

 

[bbunge]

AC66U_B1 working well on this beta.

 

[RMerlin]

Is there an easy way to capture the output of curl in this case to verify the ending set of characters

Curl has a command-line switch to enable verbose logging. Check its usage help - I don't remember what the switch was.

where on the router side does this key go?

In the Static Key field, same page where all keys/certs are defined.

 

[RMerlin]

You add a client, it works - but when you try to remove a client so that the list is empty and click Apply, you get this:

This is working as intended. You must disable "Allow only specified IP address" if you clear the list, otherwise you would effectively lock yourself out of your router, by not allowing anyone in.