What's new

Beta Asuswrt-Merlin 386.2 Beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
I have an RT-AX88U with Merlin FW 386.1_2, and I am located in Spain. Today, the router time is one hour more than it should (it seems that it has changed today to summer time, although I have defined to do it last Sunday of March):
View attachment 31968
Now it should be 18:53, but the router indicates 19:53:
View attachment 31967

Yesterday it was OK, and there is nothing in the syslog stating that time has been changed ...

Sorry for writting in the beta thread, but it has been just to clarify that the problem is not in the 362 beta but also in the 386.1 FW.

That is exactly the same way I have configured my DST which incorrectly looks like have happened today. And regarding the timezone nvram variables :

Code:
# nvram show 2>/dev/null | grep time_zone
time_zone=GMT0DST_1
time_zone_dst=1
time_zone_dstoff=M3.5.0/1,M10.5.0/2
time_zone_x=GMT0DST
# cat /etc/TZ
GMT0DST
# ls -l /etc/localtime
lrwxrwxrwx    1 admin    root            37 Mar 14 10:10 /etc/localtime -> /rom/usr/share/zoneinfo/Europe/Dublin

Which I assume is correct since no relation to U.S timezones. I guess there is an (Asus) bug somewhere...


EDIT----------------------------------------------- CORRECTION

The above lines are the output of the nvram timezone variables with my timezone set to GMT to have the correct time today. However, the output of those variables when I have configured 'GMT+1' is :

Code:
# nvram show 2>/dev/null | grep time_zone
time_zone=MET-1DST_1
time_zone_dst=1
time_zone_dstoff=M3.5.0/2,M10.5.0/3
time_zone_x=MET-1DST
# cat /etc/TZ
MET-1DST
# ls -l /etc/localtime
lrwxrwxrwx    1 admin    root            37 Mar 14 19:46 /etc/localtime -> /rom/usr/share/zoneinfo/Europe/Madrid
 
Last edited:
That is exactly the same way I have configured my DST. And regarding the timezone nvram variables :

Code:
# nvram show 2>/dev/null | grep time_zone
time_zone=GMT0DST_1
time_zone_dst=1
time_zone_dstoff=M3.5.0/1,M10.5.0/2
time_zone_x=GMT0DST
# cat /etc/TZ
GMT0DST
# ls -l /etc/localtime
lrwxrwxrwx    1 admin    root            37 Mar 14 10:10 /etc/localtime -> /rom/usr/share/zoneinfo/Europe/Dublin
This may help
Post in thread 'That time of year again....DST' http://www.snbforums.com/threads/that-time-of-year-again-dst.71137/post-672902
 
This may help
Post in thread 'That time of year again....DST' http://www.snbforums.com/threads/that-time-of-year-again-dst.71137/post-672902

Thanks Jack. Knowing it is a known error I will live with the 'GMT' setting until last sunday of march. Then our DST will apply and the time will hopefully match again. And for next year.. well, many Merlin/Asus releases will hopefully be posted until that time. By the way I just edited my previous post because the nvram output shown originally was not correct (I took it with Tz set to 'GMT' instead of 'GMT+1')
 
I have an RT-AX88U with Merlin FW 386.1_2, and I am located in Spain. Today, the router time is one hour more than it should (it seems that it has changed today to summer time, although I have defined to do it last Sunday of March):
View attachment 31968
Now it should be 18:53, but the router indicates 19:53:
View attachment 31967

Yesterday it was OK, and there is nothing in the syslog stating that time has been changed ...

Sorry for writting in the beta thread, but it has been just to clarify that the problem is not in the 362 beta but also in the 386.1 FW.
Same setup as yours. And it was working OK until yesterday. It seems a bug that appeared with the U.S. Daylight Savings Time change.

I’ll keep the GMT setting until the last Sunday of March, as @FTC said. Then if the GMT+1 setting is not working as expected ... I will try the @Jack Yaz solution.
 
I uploaded test builds for the SDK 7.14 models that were affected by the corrupted firewall rules, they are in https://www.asuswrt-merlin.net/test-builds .
386.2_beta2-g1e6831e65a Successful on RT-AC88U. LAN clients have internet access and RPDB rules are not getting deleted. All good so far. Thank you @RMerlin

UPDATE: Some websites do not load on first attempt. I have to refresh the web page. Also, internet access much slower than usual. I'll do some more analysis and may do a factory reset. I didn't have these issues with the Alpha version.

I have 3 OpenVPN Clients running and set to start at boot. Each time I have rebooted, one of the clients does not start up. Only clue so far is waiting on ntpd ...
 
Last edited:
Feedback from me as a casual user, 386_42095 seems like bringing back some old issues that has been fixed on previous release (386.1 or 386.1_2). One of them is wireless performance. Previously on 2.4GHz Rx/Tx, I can get 600mbps, but it's maxed out at 405mbps now.
 
Is this a "known issue"?
 

Attachments

  • ASUS_Wireless_Router_RT-AC68U_-_Daily.jpg
    ASUS_Wireless_Router_RT-AC68U_-_Daily.jpg
    111.7 KB · Views: 361
dirty flash of 386.2_beta1 over the prior version
everything fine so far...
time difference but I wait until end of March...
 
Today I noticed the same as you on my ac86u with 386.2 beta.
On administration settings I have this: "Reminder: The System time zone is different from your locale setting" yet my time zone is set properly. I'm also using ntpmerlin intercepting not requests and my devices get the right time if I force update with network.
I have exactly the same on AX88U. I am also using ntpMerlin.
Code:
* Reminder: The System time zone is different from your locale setting.
Router is incorrect by one hour now. How to fix this?
 
That is exactly the same way I have configured my DST which incorrectly looks like have happened today. And regarding the timezone nvram variables :

Code:
# nvram show 2>/dev/null | grep time_zone
time_zone=GMT0DST_1
time_zone_dst=1
time_zone_dstoff=M3.5.0/1,M10.5.0/2
time_zone_x=GMT0DST
# cat /etc/TZ
GMT0DST
# ls -l /etc/localtime
lrwxrwxrwx    1 admin    root            37 Mar 14 10:10 /etc/localtime -> /rom/usr/share/zoneinfo/Europe/Dublin

Which I assume is correct since no relation to U.S timezones. I guess there is an (Asus) bug somewhere...


EDIT----------------------------------------------- CORRECTION

The above lines are the output of the nvram timezone variables with my timezone set to GMT to have the correct time today. However, the output of those variables when I have configured 'GMT+1' is :

Code:
# nvram show 2>/dev/null | grep time_zone
time_zone=MET-1DST_1
time_zone_dst=1
time_zone_dstoff=M3.5.0/2,M10.5.0/3
time_zone_x=MET-1DST
# cat /etc/TZ
MET-1DST
# ls -l /etc/localtime
lrwxrwxrwx    1 admin    root            37 Mar 14 19:46 /etc/localtime -> /rom/usr/share/zoneinfo/Europe/Madrid
Something's going on with timezone for 386.1 also.

rule for Mountain Time Zone is incorrect. DST should end M11.1.0/2, instead of M10.2.0/2:
admin@RT-AC1900P-EB80:/tmp/home/root# nvram show 2>/dev/null | grep time_zone
time_zone_dst=1
time_zone_x=MST7DST
time_zone_dstoff=M3.2.0/2,M10.2.0/2
time_zone=MST7DST_1
 
Something's going on with timezone for 386.1 also.

rule for Mountain Time Zone is incorrect. DST should end M11.1.0/2, instead of M10.2.0/2:
admin@RT-AC1900P-EB80:/tmp/home/root# nvram show 2>/dev/null | grep time_zone
time_zone_dst=1
time_zone_x=MST7DST
time_zone_dstoff=M3.2.0/2,M10.2.0/2
time_zone=MST7DST_1
FYI, I'm in the Mountain Time Zone and my settings are showing correct.

Code:
time_zone_dst=1
time_zone_x=MST7DST
time_zone_dstoff=M3.2.0/2,M11.1.0/2
time_zone=MST7DST_1
 
If Asus made changes/fixes over time to the TZ database, you might possibly need to reapply it on the Administration page.
 
  • Like
Reactions: pmm
FYI, I'm in the Mountain Time Zone and my settings are showing correct.

Code:
time_zone_dst=1
time_zone_x=MST7DST
time_zone_dstoff=M3.2.0/2,M11.1.0/2
time_zone=MST7DST_1
Hmm. Changed TZ to Arizona (MST) and back to MDT, and now it's correct.
I did a full reset when I went to 386-Beta4.
Fixed for me.
 
Huh? It stared with 386.
It's been a problem for a long time. Measured in years. It's an Asus problem and has been attempted to fix several times over the years with varied success. It looked as though it was fixed here over the last while, but it shows up once again. This is not in @RMerlin control, you can report it Asus again if you like.
 
If Asus made changes/fixes over time to the TZ database, you might possibly need to reapply it on the Administration page.
I did reaply TZ settings (GMT+1 Madrid, Paris) after the yesterday "unexpected" change in DST, and time is still wrong. Curiously, if I change TZ to "GMT+1 Amsterdam, Berlin" now the time is correct. Both TZ should apply same correction ...
In fact, some other TZ with GMT+1 also produce the error ...
I am completely lost.
 
It's been a problem for a long time. Measured in years. It's an Asus problem and has been attempted to fix several times over the years with varied success. It looked as though it was fixed here over the last while, but it shows up once again. This is not in @RMerlin control, you can report it Asus again if you like.
Really? It's hard to believe they've had a known customer facing issue for years. It doesn't exactly build consumer confidence. One would think if it doesn't work they'd just disable/remove it until it does. Super weird.
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top