What's new

DNScrypt dnscrypt installer for asuswrt

  • 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'm on different branch on github for this beta, check my beta post, you can see the changelog for the beta there with all the activities.



I've been here, if you check my script code, didn't work because as I said on github, even with this info GoLang does not have the binary required to calculate the offset on asuswrt. Of course one can do it manually but it's like reinventing the wheel.
I do have some vague idea now as I have read golang code for this, but I need to test the idea first.

Maybe I can write some comment TAG there later.
Thank you sir!! This is a fantastic script!!
 
I've been here, if you check my script code, didn't work because as I said on github, even with this info GoLang does not have the binary required to calculate the offset on asuswrt. Of course one can do it manually but it's like reinventing the wheel.
I do have some vague idea now as I have read golang code for this, but I need to test the idea first.

Okay, thanks for clarifying.

Apparently I missed the info about the alternate branch, sorry. If it annoys you I'm throwing ideas at you, just let me know, I won't be offended (I'll just harrass Frank then :D). I'm not a dev, so I don't understand every discussion among you devs, which just might be why I didn't get it. My logic: I thought because nvram is available directly after boot and offsets for all timezones are known, and a table could be used to calculate the correct offset from UTC, wouldn't it be possible to pass the offset along to dnscrypt? On other OS'es it wouldn't do anything (offset=0), but on embedded devices it might just be the solution (?) to write the correct time to syslog. As far as I understand from reading in Go documentation 'func time' offers a possibility to add time, not sure whether a negative value is allowed too, though, to substract a negative offset from UTC. As 'func time' is already being used, it seems like the easiest approach. To a noob, that is. Maybe I'm thinking too simple. I'll do more reading. Okay, carry on :)
 
Uhm, not sure what has changed, but installing 2.0.0 RC using the latest installer is giving me a serious headache. My router wasn't able to resolve anything anymore. I made a backup copy of the previous version, ran the installer, installed dnscrypt-proxy and haveged, rebooted and everything went haywire as it couldn't resolve anything anymore, not even the addresses I manually have added in dnsmasq.conf.add. For now I have no other option to use WAN DNS 1, I'll give it another shot and see how that goes.
 
Uhm, not sure what has changed, but installing 2.0.0 RC using the latest installer is giving me a serious headache. My router wasn't able to resolve anything anymore. I made a backup copy of the previous version, ran the installer, installed dnscrypt-proxy and haveged, rebooted and everything went haywire as it couldn't resolve anything anymore, not even the addresses I manually have added in dnsmasq.conf.add. For now I have no other option to use WAN DNS 1, I'll give it another shot and see how that goes.
Using WAN DNS 1 set to your routers private ip it works awesome.
 
Not sure what happened, but running the installer a second time made dnscrypt-proxy v2.0.0 RC work like a charm. The only thing I could find in my log that my OpenDNS password (for the OpenDNS IP Updater in @bigeyes0x0's script) was refused. After resetting the password it was accepted again. Strange, as it hasn't changed.

Using WAN DNS 1 set to your routers private ip it works awesome.

As far as I'm aware, I think @bigeyes0x0 mentioned this in an earlier post, no-resolv in dnsmasq.conf causes WAN DNS 1 en DNS 2 to be ignored.
 
@M@rco: I had the issue you had before once, but then it went thus I removed some dns workarounds in dnsmasq. As it's not only me, I added them back.

@all The timezone issue, there's a fix. It will be in my next update ;)
 
@M@rco: I had the issue you had before once, but then it went thus I removed some dns workarounds in dnsmasq. As it's not only me, I added them back.

@all The timezone issue, there's a fix. It will be in my next update ;)
Give it to me baby!
 
Any way to install this on a usb drive instead of jffs ?

Not with the current script, but it can be done if you installed it manually. But I would strongly advice against it. If your USB-drive fails to mount, your router won't be able to resolve any address. If your USB-drive is performing lots of read and write activity it might slow down dns resolving. Not sure why you wouldn't want to install it to /jffs but it's the fastest option for a crucial component and it's ready to start during boot.
 
new version now has the time in syslog correctly set if you setup your timezone inside the installer.

Install went flawless with the latest installer with timezone fix :) Great how you fixed it for those affected. And syslog appears to be cleaned up as well from cmd touch "/jffs/dnscrypt/manager".

A suggestion: you might consider implementing the 'configure timezone' option by default into the 'install dnscrypt-proxy' steps, as anyone who's not in UTC will have the issue. You could leave the 3rd option as it is now in the menu if someone needs to reconfigure.

A question: have you taken DST into account with the fix for the incorrect timezone?
 
The new features are very welcome! Keep up the great work. This script is excellent! Works as intended. Thank you for your time and effort...:D.
 
Sorry but I cannot get the time to stick :(. When I look back through the logs to see when it started it uses my time +6 hours. Is this the expected result? What am I doing wrong?
 
Sorry but I cannot get the time to stick :(. When I look back through the logs to see when it started it uses my time +6 hours. Is this the expected result? What am I doing wrong?

That's the behavior seen so far. A new version script is expected to solve the issue.
 
Sorry but I cannot get the time to stick :(. When I look back through the logs to see when it started it uses my time +6 hours. Is this the expected result? What am I doing wrong?

Are you using the using the latest release of the script (released today)? Have you used option 3 in the installer: Configure timezone?
 
Yes I'm setting time zone by option 3.
 
Canada/Saskatchewan
 
Time zone listed as 160
 

Similar threads

Latest threads

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