What's new

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

  • 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!

I've updated to the new version 08. Everything works, but i have a problem with my time.

Mar 19 11:10:48 crond[317]: time disparity of 2215270 minutes detected

I come from germany and at the moment it is 10AM and not 11am.

My NTP config in the gui is GMT+1 Amsterdam, Berlin, Bern and i use this ntp server: 0.de.pool.ntp.org .
I rebooted several times but the time is still wrong. What can i do to fix this problem?

This is the output of "date" at the terminal from the router:

Thu Mar 19 11:19:05 DST 2015
 
I've updated to the new version 08. Everything works, but i have a problem with my time.

Mar 19 11:10:48 crond[317]: time disparity of 2215270 minutes detected
This message is normal. There is no battery backed clock in the router, so this is just the cron task syncing with the time pulled from NTP.

I come from germany and at the moment it is 10AM and not 11am.

My NTP config in the gui is GMT+1 Amsterdam, Berlin, Bern and i use this ntp server: 0.de.pool.ntp.org .
I rebooted several times but the time is still wrong. What can i do to fix this problem?

This is the output of "date" at the terminal from the router:

Thu Mar 19 11:19:05 DST 2015
I'm just guessing here, but have there been any changes in the Daylight Savings Time rules recently (since Aug 2014). The rules in the code haven't been updated, and may be out of sync with current practice. Try selecting the option to Manually set the DST, and see if the start end dates are correct and update them as necessary.
 
Hello

I see you have a new update 9 out, would you say its important to update from update 8 to update 9, or does the old saying go "if it ain't broke".

You seem to release new updates very quick.

I gather you will be releasing an update 10 shortly with the OpenSSL fix so if I skipped update 9 would I need to do a reset.

many thanks
 
This message is normal. There is no battery backed clock in the router, so this is just the cron task syncing with the time pulled from NTP.

I'm just guessing here, but have there been any changes in the Daylight Savings Time rules recently (since Aug 2014). The rules in the code haven't been updated, and may be out of sync with current practice. Try selecting the option to Manually set the DST, and see if the start end dates are correct and update them as necessary.

Thanks john9527. The manual setting worked now with adjustments. Just wonder why the ntp sync is not working. But i think its no problem from your fork, maybe asus's problem?
 
Thanks john9527. The manual setting worked now with adjustments. Just wonder why the ntp sync is not working. But i think its no problem from your fork, maybe asus's problem?
ntp sync is working, but after that DST is screwing up.
Manual setting DST is the only way it works properly.
 
From the Using-Webmon.txt file I read this:
"NOTE: In order for this feature to work, NAT Acceleration must be disabled."

However I have NAT Acceleration enabled and Webmon is working fine. :confused:
I do see "HW acceleration Disabled - incompatible with: IPTraffic".

o_O
 
Thanks john9527. The manual setting worked now with adjustments. Just wonder why the ntp sync is not working. But i think its no problem from your fork, maybe asus's problem?
Yes it's an ASUS bug. I'm in the UK, the router changed to DST last weekend, which is wrong. Also, the DST/GMT changed two weeks late in October last year. @RMerlin said the timezone database that ASUS use is too old. Just wait until the clocks change at the end of this month and it will be correct again.
 
Last edited:
Yes it's an ASUS bug. I'm in the UK, the router changed to DST last weekend, which is wrong. Also, the DST/GMT changed two weeks early in September last year. @RMerlin said the timezone database that ASUS use is too old. Just wait until the clocks change at the end of this month and it will be correct again.

It's not an ASUS bug.

I've read it's because uClibc has not been updated in a long time.
That part is responsible for DST.
Correct me if I'm wrong.
 
From the Using-Webmon.txt file I read this:
"NOTE: In order for this feature to work, NAT Acceleration must be disabled."

However I have NAT Acceleration enabled and Webmon is working fine. :confused:
I do see "HW acceleration Disabled - incompatible with: IPTraffic".

o_O

Which means your NAT acceleration is NOT enabled.
 
Hello

I see you have a new update 9 out, would you say its important to update from update 8 to update 9, or does the old saying go "if it ain't broke".

You seem to release new updates very quick.

I gather you will be releasing an update 10 shortly with the OpenSSL fix so if I skipped update 9 would I need to do a reset.

many thanks

I didn't think it was that quick on updates......generally about 5-6 weeks

Update-06.....23-Nov-2014
Update-06E....9-Jan-2015 (emergency infosvr fix)
Update-07.....20-Jan-2015
Update-08.....10-Mar-2015 (Asus security fixes)
Update-09.....17-Mar-2015 (mainly because I accidentally broke DDNS adding custom scripting)

As far as factory resets go, I actually take steps to avoid them with some extra code when needed. My goal is you can move from any fork version to any other without a reset (either up or down).

That being said, when Update-10 is available after the OpenSSL update is released, for the first time I'm going to recommend that everyone consider updating. Starting with Update-09, I think I really reduced the possibility of hitting a lot of the single occurrence/unexplained problems which have been reported in the past.....no internet access on a reboot, all web requests being redirected to the router, the router ip has changed message and so forth. We'll see.....
 
Last edited:
I use "Always", because of notifications, updates at home, because I think it is right.
I set my tablet Wifi on "Always" as a little test.....I lost 6% on the battery over about 10 hours (with a lot of background "Awake" activity"). What's your comparison point?
Screenshot_2015-03-19-17-39-35.png
 
Last edited:
I didn't think it was that quick on updates......generally about 5-6 weeks

Update-06.....23-Nov-2014
Update-06E....9-Jan-2015 (emergency infosvr fix)
Update-07.....20-Jan-2015
Update-08.....10-Mar-2015 (Asus security fixes)
Update-09.....17-Mar-2015 (mainly because I accidentally broke DDNS adding custom scripting)

As far as factory resets go, I actually take steps to avoid them with some extra code when needed. My goal is you can move from any fork version to any other without a reset (either up or down).

That being said, when Update-10 is available after the OpenSSL update is released, for the first time I'm going to recommend that everyone consider updating. Starting with Update-09, I think I really reduced the possibility of hitting a lot of the single occurrence/unexplained problems which have been reported in the past.....no internet access on a reboot, all web requests being redirected to the router, the router ip has changed message and so forth. We'll see.....

ah ok, must of just been because only just using your firmware from update 7 and your recent update 8/9 fixes.

I may skip update 9 and wait for update 10 and do a full reset, although you state reset is not needed I dont mind doing them as I dont have a lot of settings to change.

thanks
 
I've just upgraded my n66u from 07 to 08. I decided not to mess about and reformatted the Jffs as soon as I had done the upgrade and then rebooted twice.

I was then expecting to have to put my couple of scripts back but no, for reasons I can't fathom they were still there. I plugged in my data stick and up popped my Cherokee driven Intranet. I'm confused but delighted by this.

Everything seems fine and no reset either

Thanks.

Bob.
 
Any time line when OpenSSL issue will be patched ??

Note that the one new "high risk" issue reported does NOT affect the 1.0.0 OpenSSL John and I use. As for that other issue, it was already fixed back in January, back when it was labeled as a "low risk". OpenSSL devs merely upgraded its severity to "High" this week, however the actual issue is already patched.

Patience. Updating OpenSSL isn't as simple as just unziping an archive and calling it a day. I have to merge the new version on top of the old one, while preserving any customization done by Asus or myself. That can be tricky (and it actually was in the 1.0.0r update, as the patch file was a staggering 21 MB...)
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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