Beta Asuswrt-Merlin 386.2 Beta is now available

[FTC]

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 :

# 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 :

# 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

 

[Jack Yaz]

That is exactly the same way I have configured my DST. And regarding the timezone nvram variables :

# 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

 

[FTC]

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')

 

[figorr]

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.

 

[Xentrk]

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 ...

 

[Sicario]

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.

 

[fearz]

Hi,

Is diversion working with this version?

 

[SBSTNGRSS]

It is working well on my end with this version.

Hi,

Is diversion working with this version?

 

[Authority]

Is this a "known issue"?

 

[skeal]

Is this a "known issue"?

Yes it is. Traffic spike.

 

[John Adler]

dirty flash of 386.2_beta1 over the prior version
everything fine so far...
time difference but I wait until end of March...

 

[Slawek P]

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.

* Reminder: The System time zone is different from your locale setting.

Router is incorrect by one hour now. How to fix this?

 

[jj22038]

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

# 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 :

# 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

 

[bluzfanmr1]

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.

time_zone_dst=1
time_zone_x=MST7DST
time_zone_dstoff=M3.2.0/2,M11.1.0/2
time_zone=MST7DST_1

 

[RMerlin]

If Asus made changes/fixes over time to the TZ database, you might possibly need to reapply it on the Administration page.

 

[jj22038]

FYI, I'm in the Mountain Time Zone and my settings are showing correct.

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.

 

[Authority]

Yes it is. Traffic spike.

Huh? It stared with 386.

 

[skeal]

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.

 

[JIPG]

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.

 

[Authority]

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.