[Release] Asuswrt-Merlin 384.12 is now available

[Sonyrolfy]

Clean install on my RT-AC86U, working excellent! The only familiar downside I still have is on the Wireless log page with a couple of no names. A mouse click on the <no name> to see what it is, jee-A-sus when will they fix it. My NAS on network couldn’t be found in the list, but fixed it by input of the mac address and set to static. DoT, Local caching, intercept ntp, all working great. My nas always lost ntp, don’t know why, I just set ntp server to 192.168.1.1 and now it works?!. As some tested the CF NTP, for me the standard has better ping. Thanks Merlin!

 

[John Adler]

dirty from beta to 12
all working fine so far...
thxs Merlin

 

[Swistheater]

Folks, what's wrong with using XXX.pool.ntp.org ?

What's the benefit of using Cloudflare's time service? Is there an actual benefit, or is Cloudflare attempting to keep their name in the news by "reinventing" all of the legacy Internet services on a regular basis?

well nothing wrong with pool.ntp.org , people are moving to try newer stuff, that is all, there is nothing wrong with the old.

 

[Swistheater]

Minor cosmetic issue on the new page. The "Ping (Continuous)" dropdown shows the text for nslookup. All the other options change the text to match the chosen function. This is on AC68U.

Ping (Continuous) with nslookup description
View attachment 18347
Ping with expected ICMP description
View attachment 18348

yea I am not experiencing this issue with my 68U's

 

[Swistheater]

Clean install on my RT-AC86U, working excellent! The only familiar downside I still have is on the Wireless log page with a couple of no names. A mouse click on the <no name> to see what it is, jee-A-sus when will they fix it. My NAS on network couldn’t be found in the list, but fixed it by input of the mac address and set to static. DoT, Local caching, intercept ntp, all working great. My nas always lost ntp, don’t know why, I just set ntp server to 192.168.1.1 and now it works?!. As some tested the CF NTP, for me the standard has better ping. Thanks Merlin!

 time.cloudflare .POOL.          16 p    -   64    0    0.000    0.000   0.002
 time.nist.gov   .POOL.          16 p    -   64    0    0.000    0.000   0.002
-2610:20:6f97:97 .NIST.           1 u  371  512  377   60.006    2.780   2.409
-132.163.96.3    .NIST.           1 u  163  256  377   58.719    2.078   1.095
*2606:4700:f1::1 10.155.8.4       3 u   25   64  377    9.826    0.781   1.265
+2606:4700:f1::1 10.155.8.4       3 u    9   64  377    9.906    1.064   0.602
+162.159.200.1   10.155.8.4       3 u   38   64  377   10.051    0.702   1.811
-162.159.200.123 10.155.8.4       3 u   47   64  377    9.616    0.397   1.875
-132.163.97.6    .NIST.           1 u   77  256  377   55.826    0.287   2.722
-132.163.96.2    .NIST.           1 u  165  256  377   55.689    0.358   0.774
.

here is pooling some servers with cloudflare tho I don't really see the big hype other than, OOOHHH look cloudflare is doing something NEW, note all the cloudflare servers are stratum 3 in this instance, so by the time it makes it to you what is the point in trying to figure out accuracy, unless you have servers that are 1 or 2 to help balance back the drift (though the drift isn't noticeable along with the 255 slips in a 24hour period.)

 ntpq -4 -c rv | grep jitter
mintc=3, offset=0.588236, frequency=7.437, sys_jitter=0.413541,
clk_jitter=0.192, clk_wander=0.020, tai=37, leapsec=201701010000,

 

[Gar]

Another of many RMerlin upgrades without issue. Dang it, nothing to complain about! Nice work...again.

 

[FTC]

Hi, dirty upgrade to my AX88 from beta2 . So far so good. Everything working fine, including the samba server page and NTP sync boot (although I am NOT using the NTP server function).
Many thanks to Merlin and all the team for your continued efforts!

 

[jerry6]

384-12release working well on my ac 5300 and 3200 running for 4 hours , no issues so far gui seems to load quicker .
Thanks to all that work on the FW

 

[rgnldo]

Hope it continues working for you. But using an old backup config file to restore settings is equivalent to not having done a reset to factory defaults at all.

It works for me. The problem of the backup files is for major modifications to the build. I can check this problem. It's okay with me.

 

[Starrbuck]

here is pooling some servers with cloudflare tho I don't really see the big hype other than, OOOHHH look cloudflare is doing something NEW, note all the cloudflare servers are stratum 3 in this instance, so by the time it makes it to you what is the point in trying to figure out accuracy, unless you have servers that are 1 or 2 to help balance back the drift (though the drift isn't noticeable along with the 255 slips in a 24hour period.)

My pings to us.pool.ntp.org are ~37-40 ms but to time.cloudflare.com is ~2-3 ms. Nice improvement.

 

[Swistheater]

My pings to us.pool.ntp.org are ~37-40 ms but to time.cloudflare.com is ~2-3 ms. Nice improvement.

Ping is relevant to show you can connect to the internet, but not accurate to determine the quality of a NTP server. Ping uses IMCP to get a response. completely different from methods used by ntp.

ICMP-timestamps' fields are 31-bit, carry relative-time of "touching" ICMP-packed on outgoing/incoming side of the network connection, expressed as a number of miliseconds elapsed since last UTC-midnight. Highest order bit is used for flagging a UTC-uncoordinated host-time / non-standard value.

NTP-timestamps' fields are 64 bit, carry an absolute time, recorded as a 32-bit for seconds since epoch ( Jan-01-1900 .. till .. rollover in 2036 ) and another 32-bits for fractions of a second ( thus going in a time-measurement down to a sub-nanosecond resolution ).

So even though you may have higher latency with one NTP server versus another, it can be as accurate down to a sub-nanosecond in resolution, NTPD uses the calculations to "fix" or adjust the time once it arrives to you, so as far as NTP is concerned Ping is not a good way to measure accuracy.

NTP will function better when it is used along side other NTP servers, it helps the accuracy of calculations used to make the adjustments.

 

[Starrbuck]

My name resolution of local clients, such as my NAS, on Win 10 clients stopped working with this release. Any fix?

 

[Deathbringer BZ2]

Ok, so I'm going to get incredibly douchey and report an issue with little to no backup information just on the off chance someone might want to look at it while I get funky with the flashing and resetting and reconfiguring from scratch.
I live out in the sticks in Sedona and the only thing I have is a Sprint Hotspot with a USB connection to the AC5300.
I decided to setup SipXcom along with Telnyx and port my home number to it after making sure things worked.
I did this all on 384.11.2.
As you may be aware this is a double NAT and when it ultimately worked I was thrilled and Telnyx will give you a number for 1 dollar a month plus extremely low time costs when making outgoing calls. Went with this solution for our company and saved thousands a month..
Anyway.. incoming outgoing calls were working but then had an important call that took awhile and calls were dumping after 15 or so minutes which is a keepalive issue. So last night late I decided to try and fix and did a test with my cell that lasted over 35 minutes which made me nuts but I decided to start playing with SIP passthrough and some other settings and then I would try to get someone to play with me and sit on the phone for a bit.
After making some benign changes (yeah) and updating to 384.12, I had an issue where I was unable to get audio coming from the ITSP. (Telnyx) no matter what I did. Started at 10 pm and fast forward to 5 am. I have no idea what is going on because nothing I do in my state of delirium helps and the phones were down all day until I tried just now and the first thing I did was flash back to 38.11_2 and changing nothing else, suddenly I'm back in business..
I still may have my disconnect issues, but I'm at a good place to get myself in a bad place again.
So my question is...
Anything in the NAT or UPNP code that might have changed that might be giving me the issues?
One other issue that I was hoping would go away is that when I change the DHCP function of my ZTE hotspot so that it only gives out one IP.. 192.168.128.5, it will initially connect and then upon a reboot of the router it will not get an IP address no matter what I try. I was going to set the DHCP lease time down to 15 minutes or something, but really didn't want to have it give out that many renews. I'm assuming that the router is doing a standard DHCP request and is remembering it's old IP, but even if it's not I would expect that the router would request the IP and then the ZTE would give out the leased IP already based on the matching MAC. This very well could be a ZTE thing, but was wondering how the MAC was handled on the USB port? If it's doing something random than this would be my problem as the ZTE would give me a big FU when I asked for that IP on a different MAC.
My apologies for the wordy post.
For those that like shorthand.
I flashed dirty from 384.11_2
RTP stream from auth SIP trunk side to SipxCom getting clobbered.
DHCP doesn't work when I set the Hotspot to hand out one IP.
That is all.
If someone want's to dive in and give me some direction on either one of these or wants logs, please let me know and I will provide as I can.
Thanks

 

[Swistheater]

Ok, so I'm going to get incredibly douchey and report an issue with little to no backup information just on the off chance someone might want to look at it while I get funky with the flashing and resetting and reconfiguring from scratch.
I live out in the sticks in Sedona and the only thing I have is a Sprint Hotspot with a USB connection to the AC5300.
I decided to setup SipXcom along with Telnyx and port my home number to it after making sure things worked.
I did this all on 384.11.2.
As you may be aware this is a double NAT and when it ultimately worked I was thrilled and Telnyx will give you a number for 1 dollar a month plus extremely low time costs when making outgoing calls. Went with this solution for our company and saved thousands a month..
Anyway.. incoming outgoing calls were working but then had an important call that took awhile and calls were dumping after 15 or so minutes which is a keepalive issue. So last night late I decided to try and fix and did a test with my cell that lasted over 35 minutes which made me nuts but I decided to start playing with SIP passthrough and some other settings and then I would try to get someone to play with me and sit on the phone for a bit.
After making some benign changes (yeah) and updating to 384.12, I had an issue where I was unable to get audio coming from the ITSP. (Telnyx) no matter what I did. Started at 10 pm and fast forward to 5 am. I have no idea what is going on because nothing I do in my state of delirium helps and the phones were down all day until I tried just now and the first thing I did was flash back to 38.11_2 and changing nothing else, suddenly I'm back in business..
I still may have my disconnect issues, but I'm at a good place to get myself in a bad place again.
So my question is...
Anything in the NAT or UPNP code that might have changed that might be giving me the issues?
One other issue that I was hoping would go away is that when I change the DHCP function of my ZTE hotspot so that it only gives out one IP.. 192.168.128.5, it will initially connect and then upon a reboot of the router it will not get an IP address no matter what I try. I was going to set the DHCP lease time down to 15 minutes or something, but really didn't want to have it give out that many renews. I'm assuming that the router is doing a standard DHCP request and is remembering it's old IP, but even if it's not I would expect that the router would request the IP and then the ZTE would give out the leased IP already based on the matching MAC. This very well could be a ZTE thing, but was wondering how the MAC was handled on the USB port? If it's doing something random than this would be my problem as the ZTE would give me a big FU when I asked for that IP on a different MAC.
My apologies for the wordy post.
For those that like shorthand.
I flashed dirty from 384.11_2
RTP stream from auth SIP trunk side to SipxCom getting clobbered.
DHCP doesn't work when I set the Hotspot to hand out one IP.
That is all.
If someone want's to dive in and give me some direction on either one of these or wants logs, please let me know and I will provide as I can.
Thanks

well i would first start with opening the right firewall ports/ or port forwards on the double Nat Side, or completely turning off the firewall on the double nat side to test if this is causing any conflicts. firewall is always my first place to check. if you determine it is the firewall you can make a firewall-start script and tell it to allow what ever ports you need open to come through, via the ACCEPT option. or alternatively setup port forwarding rules or you may have to do both. or just simply leave the double nat side firewall off. i do not fully remember, but there may have been improvements to the firewall on the 384.12 version. i do not recall. The problem with the double nat situation , if both firewalls are on , then your incoming ports first hit the main firewall, then if they get through , they will hit the next place before reaching you, and sometimes those ports do not get auto assigned via upnp routes and actually get assigned some random port that the firewall blocks, and sometimes you cannot determine what port it is without difficulty.

 

[bbunge]

My name resolution of local clients, such as my NAS, on Win 10 clients stopped working with this release. Any fix?

Are you using SMB 1, SMB 2 or both on router and clients? My testing the beta 1 with just smb2 on router and clients worked well.

Sent from my SM-T380 using Tapatalk

 

[Swistheater]

Are you using SMB 1, SMB 2 or both on router and clients? My testing the beta 1 with just smb2 on router and clients worked well.

Sent from my SM-T380 using Tapatalk

how was the overall performance, did you see pickups in performance, due to smb1 being turned off?

 

[Deathbringer BZ2]

well i would first start with opening the right firewall ports/ or port forwards on the double Nat Side, or completely turning off the firewall on the double nat side to test if this is causing any conflicts. firewall is always my first place to check. if you determine it is the firewall you can make a firewall-start script and tell it to allow what ever ports you need open to come through, via the ACCEPT option. or alternatively setup port forwarding rules or you may have to do both. or just simply leave the double nat side firewall off. i do not fully remember, but there may have been improvements to the firewall on the 384.12 version. i do not recall. The problem with the double nat situation , if both firewalls are on , then your incoming ports first hit the main firewall, then if they get through , they will hit the next place before reaching you, and sometimes those ports do not get auto assigned via upnp routes and actually get assigned some random port that the firewall blocks, and sometimes you cannot determine what port it is without difficulty.

Hey Swistheater,
Yeah, I actually had turned off the firewall on the AC5300 last night in my travels..
I also remember when I started in on this that the RTSP passthrough was set to "Enabled + NAT helper" and also the SIP Passthrough was set the same.
I also had Adaptive QoS turned on and I was prioritizing the audio traffic.
These were set this way from 384.11_2 unless something changed in the dirty flash.
Right now I have
RTSP passthrough Disabled
SIP Passthrough Disabled
PPPoE Relay Disabled (nothing to do with this but it's there)
Firewall Disabled
QoS disabled
No port forwarding for SIP on the ASUS or the ZTE..
The firewall on the ZTE is on because I had to do that to do any port forwarding at all and I have a Photo server and I also have an internal email server.
Therein lies my issue with the IP that gets assigned internally. On the ZTE I forward to the internal IP which is the Outside IP of the ASUS on the USB port and then on the ASUS I port forward to the internal VM's that I have running on HyperV. Then running a script on my PC that I use for my living room TV, I update my godaddy domains with the current IP of the External IP of the ZTE. Unfortunately this changes way too often..
So whenever my ASUS gets bumped it gets a different IP from the ZTE and then the port forward on the ZTE breaks and my email server sits there contemplating life and not doing much else.
I set the ZTE to give out .5 and .6 now and now the ASUS is getting an IP again, and I guess two is better than the 100 it was sifting through before, but that is still an issue for me...
Back to SIP.
Right now running 384.11_2 , I have a call with my cell phone that has lasted 57 minutes and 17 seconds and counting.
Two way RTP traffic with no loss of audio going in both directions.
And again all the router settings are exactly the same and the only thing I did was downgrade from 384.12.
Oh and as you may imagine I spent like 30 hours on this to get it going in the first place. Asterisk did not work.. Freeswitch (on it's own) did not work. I even downloaded and installed latest Kamilia (sp?) which is s sip proxy and that did not work. SipXecs doesn't work either. SipXcom which is a newer branch does however.
It has an internal SBC that you can assign to your trunk and that does all the dirty stuff and works with STUN servers to rewrite things properly. As you can imagine with my setup it would going to be impossible for me to get an external IP that a separate SBC could live on. Honestly I was floored when it connected the trunk. I had also gone down the road of forwarding ports but the stupid ZTE won't like me do a range of ports so I couldn't do 30000 to 31000. I could have done a smaller subset I suppose and changed it in SipXcom and let the SIP exchange figure things out, but I still had the issue of having to go in and redo all my forwards every time my internal (external IP of the ASUS) changed.
Oh and when I did try to do port forwards AFTER the trunk connected because I figured I was still wrong and could make it better.. it actually broke things and my trunk dropped. Then last night I found this on SipXcom site:
SIP Trunk to sipXbridge for Dialog based SIP Trunks (trunk must login):

Nothing required to be open. The act of logging in will open the proper ports in the firewall and the keepalive will keep those ports open. This is what firewalls do…

Not sure if I can post a link here, but SipXcom firewall settings will get you to this page
http://sipxcom.org/firewall_settings/
Anyway.. Anybody want me to attempt to update again in an attempt to fix this, then I am game.. The call is at One hour and 12 min and still kicking.. I did adjust some keepalives in the SipxCom trunk config that might be keeping it up, but I will have to test with someone elses landline (mine is now in this thing) to be sure.. I have seen issues before depending on where the call is in the telephone exchange.. These type of things suck when you can't just make it fail every time.
If someone can help with the USB IP thing I would appreciate it and also if someone wants to help isolate why 384.12 hates me then I'm game.
Thank you for the quick response by the way.. I appreciate it.

 

[Swistheater]

Hey Swistheater,
Yeah, I actually had turned off the firewall on the AC5300 last night in my travels..
I also remember when I started in on this that the RTSP passthrough was set to "Enabled + NAT helper" and also the SIP Passthrough was set the same.
I also had Adaptive QoS turned on and I was prioritizing the audio traffic.
These were set this way from 384.11_2 unless something changed in the dirty flash.
Right now I have
RTSP passthrough Disabled
SIP Passthrough Disabled
PPPoE Relay Disabled (nothing to do with this but it's there)
Firewall Disabled
QoS disabled
No port forwarding for SIP on the ASUS or the ZTE..
The firewall on the ZTE is on because I had to do that to do any port forwarding at all and I have a Photo server and I also have an internal email server.
Therein lies my issue with the IP that gets assigned internally. On the ZTE I forward to the internal IP which is the Outside IP of the ASUS on the USB port and then on the ASUS I port forward to the internal VM's that I have running on HyperV. Then running a script on my PC that I use for my living room TV, I update my godaddy domains with the current IP of the External IP of the ZTE. Unfortunately this changes way too often..
So whenever my ASUS gets bumped it gets a different IP from the ZTE and then the port forward on the ZTE breaks and my email server sits there contemplating life and not doing much else.
I set the ZTE to give out .5 and .6 now and now the ASUS is getting an IP again, and I guess two is better than the 100 it was sifting through before, but that is still an issue for me...
Back to SIP.
Right now running 384.11_2 , I have a call with my cell phone that has lasted 57 minutes and 17 seconds and counting.
Two way RTP traffic with no loss of audio going in both directions.
And again all the router settings are exactly the same and the only thing I did was downgrade from 384.12.
Oh and as you may imagine I spent like 30 hours on this to get it going in the first place. Asterisk did not work.. Freeswitch (on it's own) did not work. I even downloaded and installed latest Kamilia (sp?) which is s sip proxy and that did not work. SipXecs doesn't work either. SipXcom which is a newer branch does however.
It has an internal SBC that you can assign to your trunk and that does all the dirty stuff and works with STUN servers to rewrite things properly. As you can imagine with my setup it would going to be impossible for me to get an external IP that a separate SBC could live on. Honestly I was floored when it connected the trunk. I had also gone down the road of forwarding ports but the stupid ZTE won't like me do a range of ports so I couldn't do 30000 to 31000. I could have done a smaller subset I suppose and changed it in SipXcom and let the SIP exchange figure things out, but I still had the issue of having to go in and redo all my forwards every time my internal (external IP of the ASUS) changed.
Oh and when I did try to do port forwards AFTER the trunk connected because I figured I was still wrong and could make it better.. it actually broke things and my trunk dropped. Then last night I found this on SipXcom site:
SIP Trunk to sipXbridge for Dialog based SIP Trunks (trunk must login):

Nothing required to be open. The act of logging in will open the proper ports in the firewall and the keepalive will keep those ports open. This is what firewalls do…

Not sure if I can post a link here, but SipXcom firewall settings will get you to this page
http://sipxcom.org/firewall_settings/
Anyway.. Anybody want me to attempt to update again in an attempt to fix this, then I am game.. The call is at One hour and 12 min and still kicking.. I did adjust some keepalives in the SipxCom trunk config that might be keeping it up, but I will have to test with someone elses landline (mine is now in this thing) to be sure.. I have seen issues before depending on where the call is in the telephone exchange.. These type of things suck when you can't just make it fail every time.
If someone can help with the USB IP thing I would appreciate it and also if someone wants to help isolate why 384.12 hates me then I'm game.
Thank you for the quick response by the way.. I appreciate it.

you could simply try the DMZ function, but i recommend this as a last resort, it doesn't deal with the double nat issue, but it will take care of any undetermined port issues you may have. on the first router, you simply put the ip you have assigned for the second router inside the dmz of the first, this will completely eliminate your port issue if that is the problem.

 

[Deathbringer BZ2]

you could simply try the DMZ function, but i recommend this as a last resort, it doesn't deal with the double nat issue, but it will take care of any undetermined port issues you may have. on the first router, you simply put the ip you have assigned for the second router inside the dmz of the first, this will completely eliminate your port issue if that is the problem.

Yeah, I didn't really want to expose 5060 to the world, but I might try that if I find that I'm still dropping calls to people.. Right now I'm working.. I think ;-)
I had in the past used a different carrier and I had a different setup so I could get an external IP and used Freeswitch and didn't firewall / limit things properly and got spoofed and 350 dollars later I was done with my home SIP trunk project.
The good thing is that SipxCom has rate limiting and a bunch of other stuff that they do with their firewall that you can enable on it. Certainly will do that as a last resort. It might not get me on 384.12 though as I'm assuming the DMZ will have the same problem as I have with it now.

 

[Vexira]

Yeah, I didn't really want to expose 5060 to the world, but I might try that if I find that I'm still dropping calls to people.. Right now I'm working.. I think ;-)
I had in the past used a different carrier and I had a different setup so I could get an external IP and used Freeswitch and didn't firewall / limit things properly and got spoofed and 350 dollars later I was done with my home SIP trunk project.
The good thing is that SipxCom has rate limiting and a bunch of other stuff that they do with their firewall that you can enable on it. Certainly will do that as a last resort. It might not get me on 384.12 though as I'm assuming the DMZ will have the same problem as I have with it now.

If you are using a hnd based router like the AC 86u or the ax88u, just set Nat to full cone it works for me.

Or look for a symetric Nat or port option in the VoIP device.