Hi all,

Haven't been here for a long time; likely before the OpenWrt / LEDE split.

Many years ago when programming in C for Windows; the group I was with used Borland and Microsoft compilers.
Over the course of a few years we compiled ALL software with both and ALWAYS tested both.

We preferred Borland because of the smaller result. BUT, as Microsoft updated Windows versions; Microsoft always had the edge because of information passed between departments at Microsoft and ALWAYS seemed to work until Microsoft posted changes and Borland caught up.

Code previously used and compiled successfully would fail when newer development tools were used to compile the old code and spit out pages of errors.

My question is this.

As Linux evolves; are the companies / groups / individuals that make development tools all on the same page at any point in time.

Are some calls / commands being deprecated (early on) and then denied (in new development versions).

Do each of you know; we (collectively) know the tools used for the Linus / Linux base code; the tools used by LEDE; the tools used by OpenWrt; etc.

Respectively; not all dev tools will recognize EVERY PIECE OF CODE that is used (to create a new branch; fix an old issue or generally consolidate old code into new code)

Might some of the current issues fall into the above.

Could @davidc502 ALL other code producers here; ALWAYS list their tools (with version numbers) so that apples ARE NOT compared to oranges or a squash.

Could this post be posted (forwarded) to LEDE and dd-wrt and others currently generating Linksys firmware.

Maybe; just maybe; some of the issues are caused by variances in development tools.

THEY ARE NOT ALL THE SAME and IF they are; one is the original and the rest are selling bootlegged copies.

Please don't take this the wrong way; but if every tool is the same; (which should NOT be possible because of tweaks) the others are copies. I have never seen original anything that is identical.

Over time all tools will level out; BUT the future ALWAYS interferes to chase tomorrow which is always good.

Current kernel is 4.9; 4.4 is dead ( kicking up compile errors that never used to fail) and 4.14 is on the horizon.

Exactly what tools are being used with 4.14? and where we (you guys - not me - a Windows programmer from here).

Thank you Davidc502 for all your efforts.

There are some anomolies / aberations here that make little sense.  Code that worked should NOT fail (Time) as newer versions of anything are introduced. A clock is a Clock is a clock; unless code cleanup generated tighter code and a NEW Compiler.

Welcome to tomorrow! Yesterday IS ALWAYS IN THE PAST.

Perhaps this post can help.

Rick

RickStep
Hamilton, ON, Canada

Currently running with 1.5 days uptime. No problems so far.

Thank you.  Same results over here as well.

Uptime = 2d 3h 7m 52s

I just tried this again less than 24 hours later with different results:

BusyBox v1.27.2 () built-in shell (ash)

     _________
    /        /\      _    ___ ___  ___
   /  LE    /  \    | |  | __|   \| __|
  /    DE  /    \   | |__| _|| |) | _|
 /________/  LE  \  |____|___|___/|___|                      lede-project.org
 \        \   DE /
  \    LE  \    /  -----------------------------------------------------------
   \  DE    \  /    Reboot (SNAPSHOT, r4901-ab26fc6c8d)
    \________\/    -----------------------------------------------------------

root@LEDE:~# date
Wed Nov 15 17:14:28 PST 2017
root@LEDE:~# hwclock
Wed Nov 15 23:53:59 2017  0.000000 seconds
root@LEDE:~# hwclock -wu
root@LEDE:~# hwclock
Wed Nov 15 23:54:10 2017  0.000000 seconds
root@LEDE:~# date
Wed Nov 15 17:15:21 PST 2017
root@LEDE:~# hwclock -w -u
root@LEDE:~# hwclock
Thu Nov 16 01:15:43 2017  0.000000 seconds
root@LEDE:~# 

Note how the hardware clock has drifted about 80 minutes in less than 24 hours. Also notice how the -wu that worked before now has failed while -w -u worked. The hwclock would need to be updated on a frequent basis to be accurate.

Yes, the cure might have been worse than the disease. I do wonder how much the rtc is really used when most everything relies on the kernel's system time.

Please notice where the 'hwclock -w' would not have been enough anyway even if the rtc was enabled and requires the 'hwclock -w -u' command. Of course the rtc won't function any more anyway since that has been recently disabled in the build.

I am not a developer and won't be participating in the Lede Developer forum so feel free to use the results of my tests for Lede r4901 from before the rtc was disabled for your investigation.

(Last edited by beginner67890 on 16 Nov 2017, 03:01)

@beginner67890, some clarification:

• I don't run the build from this thread, I was just commenting on the common issue being witnessed here, and seen by others including myself.

• If you compare your first RTC output to mine, you will notice that your RTC is actually working (i.e. it has a time). My RTC always comes up as Wed Dec 31 16:59:59 1969  0.000000 seconds, which interestingly enough is equal to (*nix epoch - (1 second + my UTC offset(-7)).

• In my image I have the RTC as it was, so my use of hwclock should allow setting the RTC, except the RTC is not accessible.

• The OP regarding this issue, plus the FS#831, indicate the problems encountered. I don't experience any of those issues, but I dropped collectd years ago, don't use vnstat, and send my logs to a linux box running syslog down the wire.

• Drift in a correctly running system would be handled by the RTC update of the kernel (with userspace NTP configured), but she be dead jim.

• It is not really the LEDE developer forum per se. It is the LEDE community forum, but I opened that thread in the developer section. Feel free to add any input you feel adds value to the conversation regarding the issue.

Just got me first reboot after 2 days up time when a qualcomm phone tried to connect to the 5G network. It looks like yuhhaurlin prepared a new driver to go with this updated firmware.

There will be another build this weekend to include yuhhaurlin's latest firmware as well as the latest commit.  Earlier in the week I posted a link to the latest firmware for 3200acm owners to download.

Just found this below thought it might be helpful to anyone having same problem. Worked like a lucky charm.
https://lede-project.org/docs/user-guid … e-warnings

(Last edited by th0r on 17 Nov 2017, 18:37)

For 3200ACM owners --

Another Firmware update has bee posted by yuhhaurlin.  This firmware addresses Crash with re-authorization issue.

https://drive.google.com/open?id=1sEUvE … zOKwDP295V

(Last edited by davidc502 on 17 Nov 2017, 02:21)

I should include that I am running  on David's R5297 build with the new firmware from yuhhaurlin when the reboot happened.
driver name: mwlwifi
chip type: 88W8964
hw version: 7
driver version: 10.3.4.0-20170810
firmware version: 0x0903bee1
power table loaded from dts: no
firmware region code: 0x0
mac address: 60:38:e0
2g: disable
5g: enable
antenna: 4 4
irq number: 45
ap macid support: 0000ffff
sta macid support: 00010000
macid used: 00000001
radio: enable
iobase0: e1080000
iobase1: e1300000
tx limit: 1024
rx limit: 16384

(Last edited by degroe on 17 Nov 2017, 04:09)

Please capture those logs to USB, so they can be viewed.

Rick,
You have a better chance of participation in your discussion over at the LEDE developers forum:
https://forum.lede-project.org/c/devel

Finally upgraded WRT3200 davidc build for the first time. It took just 6hours to restore the settings. After upgrade, almost no settings are preserved, nothing works, no internet connectivity to start with, so it's extremelly difficult to restore the previous operation. Requires hundreds of command line operations.
There's basic dnsmasq with dnscrypt, which doesn't make sense. Around 100 packages need to be reinstalled, many throwing errors. Init.d, hotplug.d scripts need to be restored. Permissions need to be set on files. And much much more. Backup of all files is recommended.
The question is, is LEDE seriously continue this way? I don't find it comfortable, and again, won't upgrade in a year. Will keep watching the thread for some good news, but noone is concerned except me, which is shocking! Why not (automatically) flash firmware like other brand routers, instead of providing useless choice to keep the settings?

(Last edited by wrtuser123 on 18 Nov 2017, 02:37)

I use the keep settings frequently and it works every time.  Perhaps if you didn't wait until your packages were so out of date to upgrade you wouldn't have such issues.

The config.seed file is provided so you can see ahead of time what packages are included by default.  I seriously doubt anyone else here had to install 100 packages after flashing.  The base build has everything a stock OEM firmware has and much much more.

There is also an option to do a backup of your settings as an added safety net.

I have LEDE running on 4 different routers and I've not once seen a permissions issue or any of the init.d scripts needed to be restored or modified in any way.  install the packages and they work.

I'm not sure what happened in your flash but it certainly is not normal or typical.

(Last edited by WWTK on 18 Nov 2017, 03:00)

What happened is LEDE. That's the only router i have that doesn't preserve configuration. Formatting all memory, then copying back 20 files is a joke. In other routers configuration was preserved through years of updates. Imagine Windows asked at each update to go through registry and fix inconsistencies there.
6 hours of very efficient operation speak of itselves. It's definitely not right for me. Might be ok for super basic configuration.

What I had to fix:
- almost all screens of UI
- /etc (tons of files, init.d, hotplug.d, adblock corruption, ..)
- /mnt (if you don't have folders created, mounting fails)
- readd ssh certificates, remove dropbear
- /home/* restore
- /lib required readd of some LUAs
- /overlay started filling up its space while mounts were not working (yup, it simulates samba and copies files there until free space is zero and packages cannot be installed lol)
- /usr some script fixes
- file permissions to improve security
- dnsmasq-full just to get connectivity and install 258 packages (some already installed), since dont have comparison script, had to do manually

It is NOT right.

This build is not for you.  Recommend going back to where you were.

Best Regards,

*Edit*

Looking through the logs at the packages downloaded, you are an advanced user with special needs    Maybe one day as this build continues to grow it will be ready for you. It's going to need to catch up to you, and not the other way around.

(Last edited by davidc502 on 18 Nov 2017, 03:46)

Hi wrtuser123  if you would like some changes pleas rite some bug reports on the LEDE fly spray.
https://bugs.lede-project.org/
That's the best way to get LEDE the way you would like. The devs are always looking for feedback.

Hi davidc502 as we have loads of space on the flash of the wrt routers, could we swich to using dnsmasq-full pleas? For dnsecc.

So I got my WRT1200AC v2 yesterday and put the latest build on it and it runs decent so far. There were a few glitches with LUCI in the beginning not able to set the default root password. I had to disable all the non working and redundant stuff like dnscrypt, igmpproxy, qos, samba, ect. 5GHz wifi signal seems a bit weak of about 60% of what Luci says even with all clients directly in the same room or just 1-2m from the router in direct view, though I am not sure if thats a correct value. A few questions:

1. is there a way to tweak HW AES acceleration more for OpenVPN-openssl (if even possible)? So far I am able to reach about 70mbit/s down and around 25mbit/s up with then CPU0 or 1 capping at 100% (I know it cant use more than 1 core). I am using AES-256-GCM and also put "engine cryptodev" in the client files, which doesnt seem to make a difference though it stays at around 70mbit/s. So I am not sure if it really uses an acceleration library.

2. I am having https/DNS issues randomly at my clients where for example Chrome says "resolving host..." or "establishing secure connection..." and nothing happens for 20-30 seconds, then suddenly the page pops up and all is working for  a few minutes, then randomly it happens again. Pinging works constantly though so there is no package loss.

3. noticed some files are saved directly into / why? For example ".rnd" or ".wget-hsts". Shouldnt those go into /tmp (ramdisk) or ~?

4. how come the build just uses 16MB of the 128MB flash? Is the old Linksys partition not touched or? Would sysupgrades work normally from now on or are they dangerous? I read something about that before on here.

5. is the above talked about wifi fw fix/update also coming for the wrt1200ac or ins that one affected?

(Last edited by makedir on 18 Nov 2017, 13:04)

Do you know if full dnsmasq has been fixed?  At one time it was causing issues. I'll add it back to the build, and see what happens.

Hello @makedir

1.  You are doing really good with those speeds using openvpn. Cryptodev has never worked as well as it should in my opinion.
2.  Seems dnscrypt is being used? What IP is being used to forward requests?
3. Not sure if there's an environment variable which would need to be set up to make all downloads go to a certain directory like /tmp.  If so, I've never tweaked them.
4. This build uses some of the more popular packages and luci-apps, and leaves the rest to be installed by the user. If you have a specific request to add, depending on what it is and what it does it could get added.
5. The current wifi issues are all related to the 3200acm. However, expect additional wifi teaks which will affect the 1200/1900 line.

This same thing had always happened to me too. I think it's fixed by using the resolv-crypt.conf file to specify a timeout, at least I haven't noticed it as much after I started using that, but I haven't done any formal testing to confirm.

Anything in the logs around the same time? Check in Services - DNSCrypt - View logfile and Status - System log.

For what it's worth, I've been using dnscrypt without any noticed issue. Basically default from the 5297 build; I do have the resolv-cryptconf defined in config dnsmasq as the resolvfile and the file itself has timeout:1.

(Last edited by dreary_ennui on 18 Nov 2017, 16:56)

This appears to be the same binary file as in post 3934 above of Nov 13:
# diff 88W8964.bin 88W8964.bin.Nov13
#

That's the kicker, in logs things look normal. I have four dnscrypt instances and each will show they're successfully retrieving server certs. Occasionally one will start misbehaving and I'll see one of the instances unable to fetch new certs. In that situation, refreshing the resolver file can fix it, or the issue will appear to fix itself after some time. Either way, when the all servers option is used in dnsmasq I would assume it wouldn't matter anyway if one fails when there are three others that don't have issues. Yet, it's usually when just one is malfunctioning that I see the long pause in resolution before serving the website as @makedir was describing.

(Last edited by anymouse617 on 18 Nov 2017, 17:47)