OpenWrt Forum Archive

Topic: davidc502 1900ac 3200acm builds

The content of this topic has been archived between 26 Feb 2018 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

Ok guys
Downloaded from here:
https://mirrors.a-m-v.pl/downloads.lede … u/generic/

and THIRD RADIO present and correct, as device mlan0, using driver mwifiex_sdio module.

PERFECT!

My issue resolved

...I also installed package luci-theme-material to make it look like Dave's :-)

(Last edited by ninjaef on 14 Feb 2018, 23:11)

i'm curious.  does the 3rd radio only exist in the wrt3200acm?  how about other belkin/linksys wrt routers e.g. wrt1900ac, wrt1900acs, etc ?

wrtboy wrote:

i'm curious.  does the 3rd radio only exist in the wrt3200acm?  how about other belkin/linksys wrt routers e.g. wrt1900ac, wrt1900acs, etc ?

Only the WRT3200ACM has 3 radios.


ops..

And the WRT32x too.

(Last edited by gufus on 14 Feb 2018, 21:17)

wrtboy wrote:

i'm curious.  does the 3rd radio only exist in the wrt3200acm?  how about other belkin/linksys wrt routers e.g. wrt1900ac, wrt1900acs, etc ?

Sorry, No!

Only the 3200

The 3rd radio has WiFi, NFC and FM radio capability. Who knows, maybe an FM tuner in time, or swipe your router up at the till machine to pay for goods

ninjaef wrote:
wrtboy wrote:

i'm curious.  does the 3rd radio only exist in the wrt3200acm?  how about other belkin/linksys wrt routers e.g. wrt1900ac, wrt1900acs, etc ?

Sorry, No!

Only the 3200

The 3rd radio has WiFi, NFC and FM radio capability. Who knows, maybe an FM tuner in time, or swipe your router up at the till machine to pay for goods

Dear ninjaef,
I hate to say " I told so " but I did. This is an absolutely wonderful Community for the support that is so generously and kindly offered here. I will say that you might just exercise a bit of patience. 
I am glad that you got your third radio working, and I apologize for being among those that misinformed you regarding the third radio support.
I have the WRT 3200ACM  1900ACS v2 and 1200AC - and today I put Lede Snapshot on my 1200AC  ( Lede and OpenWrt have merged under OpenWrt trademark - that is why the firmware images are labeled OpenWrt ) .
Once again be cool and I wish you all the best. I did manage to deploy GETDNS AND STUBBY FOR ( ENCRYPTED ) DNS OVER TLS. It works great - maybe you and others should give a try.

In Peace,

Directnupe

hnyman wrote:
davidc502 wrote:
rs.se wrote:

Have you had any success being able to build LEDE/Openwrt over the last two weeks, I have been trying many different ways to get it to build even with using the make command to ignore packages that fail to build, my source code hasn't successfully built since r5988.

Anyone else having a problem with mvebu, for WRT3200ACM/Rango?

Did you finally get this to complete successfully?  I have yet to get a good build.  Maybe this is because of the re-merging of OpenWrt/LEDE?

Usually, if I hang back for a few days the developers will solve the issues.....  Patience.

There is likely no fix forthcoming, because there is no problem in the main code. mvebu builds just fine for the default kernel 4.9.

Buildbot builds the official master snapshots fo mvebu regularly, latest build today:
http://downloads.lede-project.org/snaps … u/generic/

I have been compiling my own vanilla WRT3200ACM kernel 4.9 build (with the CPU frequency scaling code) regularly, and have had no problems. Latest build today from r6150-dc7a1e8555. (And the 3rd radio driver included by default).

If you still have a compilation problem, there is something incompatible in your source tree or config and you maybe need to go carefully through your source & config changes.

Or you could drop some individual package that does not compile. But the faillogs list is rather short at the moment, so there aren't that many packages that do not compile.

Thanks... Yeah, it's probably time to completely redo the .conf.  *sigh*... It's just time consuming.

However, I'm testing a fresh .conf with default values, so I'll see how it goes.

Has anyone been getting this issue when enabling 5Ghz on WRT3200ACM with the latest build?

pastebin.com/kdduisuB

It reboots after this error and cycles through indefinitely. I have enough time to go into the config and disable the interface while it searches for a channel.

(Last edited by pmcduff on 15 Feb 2018, 03:07)

Sir, I have no idea where you are coming from with those statements??
"told me so"? Told me what? So far as i can read, you indicated that the radio functionality was already in by virtue of it being in 4.9 kernel. As I have clearly demonstrated above, this was not the case with images I have downloaded using links you and other had kindly provided. Im sorry. But it did not work.

My own programmatic analysis clearly showed that the CONFIG_MWIFIEX_SDIO=y option was not set and thus the neceesary .ko modules were not present when building/compiling the fw image on this platform. Anyone who claims to have the 3rd radio is either using a different image , a different chipset, or confused :-) After some digging and weeding, I managed to find a snapshot with the drivers in. I could have compiled them myself  from source, into an .ipk and installed them, but why replicate Dave's good work?

In so far as patience, I am merely reporting as I go. If I go to fast for you, then sorry, but that's my pace, fast, determined, thorough, successful. I have posted a link to a fuctional 3rd radio image , above.

Yes! you are right, it is a great community. Lets keep it that way hmm

Indeed, I also seek EDNS so would be dleighted to exchange with you , Stubby setup/config/ideas . I will look into this at the weekend. Definitely a superb capability to encrypt DNS fron snopping ISPs hmm

directnupe wrote:

Dear ninjaef,
I hate to say " I told so " but I did. This is an absolutely wonderful Community for the support that is so generously and kindly offered here. I will say that you might just exercise a bit of patience. 
I am glad that you got your third radio working, and I apologize for being among those that misinformed you regarding the third radio support.
I have the WRT 3200ACM  1900ACS v2 and 1200AC - and today I put Lede Snapshot on my 1200AC  ( Lede and OpenWrt have merged under OpenWrt trademark - that is why the firmware images are labeled OpenWrt ) .
Once again be cool and I wish you all the best. I did manage to deploy GETDNS AND STUBBY FOR ( ENCRYPTED ) DNS OVER TLS. It works great - maybe you and others should give a try.

In Peace,

Directnupe

(Last edited by ninjaef on 15 Feb 2018, 09:53)

My two cents about the third radio issue:

I have a WRT3200ACM running LEDE 17.01.4 plus my [packages for the] updated drivers (available at https://github.com/eduperez/mwlwifi_LEDE), and the third radio is fully functional. Those packages were compiled using the exact same options as the stock stable release.

Hope this helps!

(Last edited by eduperez on 16 Feb 2018, 09:03)

Agreed. Snapshots , for some reason, do not all have the option set. Although I was led to believe the snapshots are daily botbuilds so if stable sets the option, so should snapshot.. But this is not what I found? Anyway, its working now and I have shared what needs to be set a build time to get support built in should  the 3rd radio disappear in subsequent images.

By thew way , what have you updated in the driver? I could go through the code, but I'm guessing you know (!) because 9.3.2.4 firmware is buggy , and I'm guessing they are not "your updated drivers" but rather you have b/ported into your "build"  as many are doing , kaloz being but one?
https://github.com/kaloz/mwlwifi/issues/256

eduperez wrote:

My two cents about the third radio issue:

I have a WRT3200ACM running LEDE 17.01.4 plus my updated drivers (available at https://github.com/eduperez/mwlwifi_LEDE), and the third radio is fully functional. Those packages were compiled using the exact same options as the stock stable release.

Hope this helps!

(Last edited by ninjaef on 15 Feb 2018, 11:30)

ninjaef wrote:

what have you updated in the driver? I could go through the code, but I'm guessing you know (!)

eduperez wrote:

I have a WRT3200ACM running LEDE 17.01.4 plus my updated drivers (available at https://github.com/eduperez/mwlwifi_LEDE), and the third radio is fully functional.

All the "updated drivers" references are about the main radios' driver mwlwifi, which is still under heavy development. Old stable 17.01 branch has an ancient version 2017-06-06 of that, so eduperez has backported the newer and better versions.

mwlwifi development discussions and update logs can be found at https://github.com/kaloz/mwlwifi/commits/master

To my knowledge, nobody is doing any updates for the 3rd radio.

Agreed. Marvel are not releasing fw for their chipset (3rd radio - 88W8887) so there's not much one can do with the kernel module to improve performance of it.

Here is the PB from Marvel on that chip:
http://www.marvell.com/documents/hybjierhqiidmojjazan/

hnyman wrote:

All the "updated drivers" references are about the main radios' driver mwlwifi, which is still under heavy development. Old stable 17.01 branch has an ancient version 2017-06-06 of that, so eduperez has backported the newer and better versions.

mwlwifi development discussions and update logs can be found at https://github.com/kaloz/mwlwifi/commits/master

To my knowledge, nobody is doing any updates for the 3rd radio.

(Last edited by ninjaef on 15 Feb 2018, 11:34)

For Those Who May Need GetDns and Stubby Packages For ( ENCRYPTED ) DNS OVER TLS

I uploaded ipk packages to 4shared here below:

https://www.4shared.com/file/MQmjoryHei … 9_vfp.html

https://www.4shared.com/file/UVFVW1XPca … 9_vfp.html

My reason for doing this is because I noticed that some days these packages are available in Lede Snapshot Repo and on others they are not. So if you wish to grab a copy - store them locally - and then install via Winscp - you will be able to do so.

In case you missed the post for the instructions to get GetDns and Stubby working - I will add it again at the end of this post. I use Unbound for caching forwarded to Stubby  / dnsmasq for DHCP - so it is speedy - no lag -   see setup for that here -  https://blog.grobox.de/2018/what-is-dns … r-openwrt/

FOR THOSE INTERESTED IN GETDNS AND STUBBY FOR ( ENCRYPTED ) DNS OVER TLS


iamperson347 aka cliobrando is the maintainer developer for these packages - He was kind enough to get back to me over on The Lede Forum  thusly :

https://forum.lede-project.org/t/help-n … ls/11463/2


Hello @directnupe

I helped put the getdns and stubby packages together, so hopefully I can help get them running on your device. (Note: There will be a few changes coming to the package defaults during the next release of getdns/stubby, as well as further explanation on the config choices that were included in the stubby.)

First, to answer your questions:

1 - No, there is no luci app yet
2 - There is currently no guide/etc. written up to get this working with lede/openwrt.

Assumptions:

1 - You have unbound or dnsmasq configured for your device, and it is the primary dns serving your network. (Or… at the very least, the unbound/dnsmasq config will not conflict with the default port currently set in the lede/openwrt stubby package, which is 5453.)
a) I recommend running unbound to utilize the caching. Sometimes the connections from stubby to the resolver can have a little but of lag, so caching + prefetch helps minimize the effects.

2 - You have a ca cert bundle installed on your router.
a) You can do this by running the following: opkg install ca-certificates

To get the packages to show up, you must subscribe to the correct feed. You can add the following to the “/etc/opkg/customfeeds.conf” file:

src/gz openwrt_packages http://downloads.lede-project.org/snaps … c/packages

Note: “mips_24kc” needs to be replaced with the proper instruction set for your device. You can find this info via the hardware table and then viewing “tech data” https://lede-project.org/toh/start


Edit: for WRT 1200AC  1900AC Version 1  1900AC Version 2   1900ACS Version1 or 2  3200ACM   - this is correct feed in order to save you time and for the sake of accuracy -

src/gz openwrt_packages https://downloads.lede-project.org/snap … /packages/


Make sure the “openwrt_packages” does not conflict with any other feed you have.

Note 2: The snapshot feed (master) is the only branch where the packages currently exist. You will have to wait for the next lede/openwrt branch if you want to stick to release branches.

Note 3: When adding the snapshot branch, be careful with “upgrading” packages.

After you add the correct feed, run:

opkg update

After that, you should be able to install the packages:

opkg install getdns stubby

You can change the default resolvers packaged with the current package by editing /etc/stubby/stubby.yml

Note: There has been some discussions about the current defaults. I believe on the next release, I’m going to change the lede/openwrt stubby defaults to use quad9 non-filtering service: 9.9.9.10 and appropriate ipv6 equivalent.

The last step is to point you local resolver (unbound/dnsmasq) to stubby for name resolution.

For unbound, simply edit “/etc/unbound/unbound_ext.conf” and add the following:

forward-addr: 127.0.0.1@5453

OR

forward-addr: ::1@5453
(The lede/openwrt package of stubby currently defaults to listening on the loopback adapters only.)

Be sure to restart/reload your resolver afterwards.

To ensure stubby starts correctly after config file changes, please check the syslog after a restart of the service. You should see something similar to below (no errors reported):

stubby[24047]: [21:28:10.228569] STUBBY: Read config from file /etc/stubby/stubby.yml
stubby[24047]: [21:28:10.254679] STUBBY: Starting DAEMON…

Hopefully this helps.


For those interested you can get Stubby from this custom feed for our devices  -

src/gz openwrt_packages http://downloads.lede-project.org/snaps … /packages/

Lastly - Dave said that he will be adding GetDns and Stubby to his repo if they build properly in his next upcoming release

(Last edited by directnupe on 15 Feb 2018, 15:02)

Hei David,

just did the reflash with the latest from your repository on the wrt3200acm.
As far I can see the problem with the 5 ghz wlan @ 160 mhz setting is still present. It do not start.

What are the current "best" settings to use regarding performance and stability?

I needed to open the wrt3200 from a client and there I have seen there is an extra 5th antenna (pcb antenna). Looks like some kind of bluetooth. What is that and can it be used for something?

Regards

What client of yours uses 160mhz? What's the wifi hardware card/model/name?

The antenna is for third radio. You are reading this thread...no?  Lol

NeuerLinuxfan wrote:

Hei David,

just did the reflash with the latest from your repository on the wrt3200acm.
As far I can see the problem with the 5 ghz wlan @ 160 mhz setting is still present. It do not start.

What are the current "best" settings to use regarding performance and stability?

I needed to open the wrt3200 from a client and there I have seen there is an extra 5th antenna (pcb antenna). Looks like some kind of bluetooth. What is that and can it be used for something?

Regards

(Last edited by ninjaef on 15 Feb 2018, 17:46)

NeuerLinuxfan wrote:

Hei David,

just did the reflash with the latest from your repository on the wrt3200acm.
As far I can see the problem with the 5 ghz wlan @ 160 mhz setting is still present. It do not start.

What are the current "best" settings to use regarding performance and stability?

I needed to open the wrt3200 from a client and there I have seen there is an extra 5th antenna (pcb antenna). Looks like some kind of bluetooth. What is that and can it be used for something?

Regards

Keep in mind, when wifi is started in the 160mhz width, DFS rules take over. The wifi radio will not turn on until it listens, and determines there's not radar. This process can take up to 5 minutes or more.  If it can't find a clear channel, it will not start, so just beware.

Bluetooth module is not compiling. I tested it with a fresh .conf and bluetooth failed to compile last nigh... Unknown reason as I haven't looked into it.

I've found 5Ghz with 80mhz width on Auto works best for me as it will bounce around during the day finding the best frequency - Including DFS frequencies.  If you need absolutely no drops, then set the SSID for a particular frequency and don't select auto.

2.4Ghz is usually saturated in neighborhoods, so depending on the time of day speeds can be slow.  If you're fortunate enough to be out in the woods away from other homes, the 2.4Ghz spectrum is really good, but must slower than the 5Ghz AC.

Searching hasn't been my friend.  Some how i have flashed both partitions on my 3200acm.  Can i just change flash stock back to selected partition or do i have to do it another way??  I remember seeing something about having to use a USB drive but i cant find the info.  Please any help is appreciated.

Thanks in advance

Here.

worked

Thanks

(Last edited by kylum on 16 Feb 2018, 00:48)

Does anyone have too issues with dnscrypt-proxy? It isnt working anymore for me since a few hours and I am not sure why. Was it taken down because of the owner change (there is a new version out I think called 2.0)? Or is it a local issue on my side. Logs say it's connected but I cant resolve any hosts anymore over it. It worked about 12h ago still perfectly fine.

(Last edited by makedir on 16 Feb 2018, 03:03)

I am using dnscrypt.nl-ns0 without issues. Haven’t had any problems ever with this one.

No issues with dnscrypt over here... I've been gone, so there may have been some blips and didn't know it.

Ok this is really weird now. I got dnscrypt-proxy working again, by changing my ns1 resolver from 'dnscrypt.eu-nl' to 'dnscrypt.nl-ns0'. I dont know whats going on, but the logs say even with 'dnscrypt.eu-nl' that it is connected, but it doesn't work anymore with this resolver. No host resolves anymore via that one. Also, this doesn't should happen really, because I have two backup resolver configured:

config global

config dnscrypt-proxy 'ns1'
    option address '127.0.0.1'
    option port '5353'
    option block_ipv6 '1'
    option local_cache '1'
    list blacklist 'domains:/tmp/adb_list.overall'
    #option resolver 'dnscrypt.eu-nl'
    option resolver 'dnscrypt.nl-ns0'

config dnscrypt-proxy 'ns2'
    option address '127.0.0.1'
    option port '5354'
    option block_ipv6 '1'
    option local_cache '1'
    list blacklist 'domains:/tmp/adb_list.overall'
    option resolver 'dnscrypt.eu-dk'

config dnscrypt-proxy 'ns3'
    option address '127.0.0.1'
    option port '5355'
    option block_ipv6 '1'
    option local_cache '1'
    list blacklist 'domains:/tmp/adb_list.overall'
    option resolver 'd0wn-se-ns1'
config dnsmasq
    option domainneeded '1'
    option localise_queries '1'
    option rebind_protection '1'
    option rebind_localhost '1'
    option local '/lan/'
    option domain 'lan'
    option expandhosts '1'
    option authoritative '1'
    option readethers '1'
    option leasefile '/tmp/dhcp.leases'
    option localservice '1'
    option allservers '1'
    option nonwildcard '1'
    #option noresolv '1'
    #option resolvfile '/tmp/resolv.conf.auto'
    option resolvfile '/root/resolv-crypt.conf'
    list server '127.0.0.1#5353'
    list server '127.0.0.1#5354'
    list server '127.0.0.1#5355'
    list server '/pool.ntp.org/8.8.8.8'
    list server '/netflix.com/127.0.0.1#53003'
    list server '/netflix.de/127.0.0.1#53003'
    list server '/nflxvideo.net/127.0.0.1#53003'
    list server '/zattoo.com/127.0.0.1#53003'
    list server '/zattoo.de/127.0.0.1#53003'
resolv-crypt.conf
options timeout:1

Logs both with 'dnscrypt.eu-nl' to 'dnscrypt.nl-ns0' say they are connected, but resolving doesnt work with the first (worked for months though):

Fri Feb 16 05:34:25 2018 daemon.notice dnscrypt-proxy[6710]: dnscrypt-proxy Starting dnscrypt-proxy 1.9.5
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6710]: dnscrypt-proxy Generating a new session key pair
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6710]: dnscrypt-proxy Done
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6709]: dnscrypt-proxy Generating a new session key pair
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6711]: dnscrypt-proxy Generating a new session key pair
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6709]: dnscrypt-proxy Done
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6711]: dnscrypt-proxy Done
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6710]: dnscrypt-proxy Server certificate with serial '0001' received
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6710]: dnscrypt-proxy This certificate is valid
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6710]: dnscrypt-proxy Chosen certificate #808464433 is valid from [2017-09-11] to [2018-09-11]
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6710]: dnscrypt-proxy The key rotation period for this server may exceed the recommended value. This is bad for forward secrecy.
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6710]: dnscrypt-proxy Server key fingerprint is D616:D268:09D2:29A7:9457:DE07:3DE8:EBD8:3C24:BFF3:2BF7:B406:108B:44DA:51FE:3711
Fri Feb 16 05:34:25 2018 daemon.notice dnscrypt-proxy[6710]: dnscrypt-proxy Proxying from 127.0.0.1:5354 to 77.66.84.233:443
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6709]: dnscrypt-proxy Server certificate with serial '0001' received
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6709]: dnscrypt-proxy This certificate is valid
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6709]: dnscrypt-proxy Chosen certificate #808464433 is valid from [2017-09-10] to [2018-09-10]
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6709]: dnscrypt-proxy The key rotation period for this server may exceed the recommended value. This is bad for forward secrecy.
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6709]: dnscrypt-proxy Server key fingerprint is 72DF:BE14:531F:F2AD:FD0F:BC8B:F711:B93D:799F:E4D0:34EC:D26B:8BF9:FFA9:32E7:2B79
Fri Feb 16 05:34:25 2018 daemon.notice dnscrypt-proxy[6709]: dnscrypt-proxy Proxying from 127.0.0.1:5353 to 176.56.237.171:443
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6711]: dnscrypt-proxy Server certificate with serial #1518755161 received
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6711]: dnscrypt-proxy This certificate is valid
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6711]: dnscrypt-proxy Chosen certificate #1518755161 is valid from [2018-02-16] to [2018-02-17]
Fri Feb 16 05:34:25 2018 daemon.info dnscrypt-proxy[6711]: dnscrypt-proxy Server key fingerprint is EF46:D92C:8EC6:19D9:0180:999C:D490:F409:74B3:FF28:4FBD:898A:BF68:2CC4:D1A2:077B
Fri Feb 16 05:34:25 2018 daemon.notice dnscrypt-proxy[6711]: dnscrypt-proxy Proxying from 127.0.0.1:5355 to 95.215.44.124:443

changed ns1 to dnscrypt.nl-ns0:

Fri Feb 16 05:48:55 2018 daemon.notice dnscrypt-proxy[6710]: dnscrypt-proxy Stopping proxy
Fri Feb 16 05:48:55 2018 daemon.notice dnscrypt-proxy[6709]: dnscrypt-proxy Stopping proxy
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[6710]: dnscrypt-proxy UDP listener shut down
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[6709]: dnscrypt-proxy UDP listener shut down
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[6710]: dnscrypt-proxy TCP listener shut down
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[6709]: dnscrypt-proxy TCP listener shut down
Fri Feb 16 05:48:55 2018 daemon.notice dnscrypt-proxy[6711]: dnscrypt-proxy Stopping proxy
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[6711]: dnscrypt-proxy UDP listener shut down
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[6711]: dnscrypt-proxy TCP listener shut down
Fri Feb 16 05:48:55 2018 user.info : dnscrypt-proxy + DNS Security Extensions are supported
Fri Feb 16 05:48:55 2018 user.info : dnscrypt-proxy + Provider supposedly doesn't keep logs
Fri Feb 16 05:48:55 2018 daemon.notice dnscrypt-proxy[8524]: dnscrypt-proxy Starting dnscrypt-proxy 1.9.5
Fri Feb 16 05:48:55 2018 user.info : dnscrypt-proxy + DNS Security Extensions are supported
Fri Feb 16 05:48:55 2018 user.info : dnscrypt-proxy + Provider supposedly doesn't keep logs
Fri Feb 16 05:48:55 2018 daemon.notice dnscrypt-proxy[8522]: dnscrypt-proxy Starting dnscrypt-proxy 1.9.5
Fri Feb 16 05:48:55 2018 user.info : dnscrypt-proxy + DNS Security Extensions are supported
Fri Feb 16 05:48:55 2018 user.info : dnscrypt-proxy + Provider supposedly doesn't keep logs
Fri Feb 16 05:48:55 2018 daemon.notice dnscrypt-proxy[8523]: dnscrypt-proxy Starting dnscrypt-proxy 1.9.5
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8523]: dnscrypt-proxy Generating a new session key pair
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8523]: dnscrypt-proxy Done
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8522]: dnscrypt-proxy Generating a new session key pair
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8522]: dnscrypt-proxy Done
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8524]: dnscrypt-proxy Generating a new session key pair
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8524]: dnscrypt-proxy Done
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8523]: dnscrypt-proxy Server certificate with serial '0001' received
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8523]: dnscrypt-proxy This certificate is valid
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8523]: dnscrypt-proxy Chosen certificate #808464433 is valid from [2017-09-11] to [2018-09-11]
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8523]: dnscrypt-proxy The key rotation period for this server may exceed the recommended value. This is bad for forward secrecy.
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8523]: dnscrypt-proxy Server key fingerprint is D616:D268:09D2:29A7:9457:DE07:3DE8:EBD8:3C24:BFF3:2BF7:B406:108B:44DA:51FE:3711
Fri Feb 16 05:48:55 2018 daemon.notice dnscrypt-proxy[8523]: dnscrypt-proxy Proxying from 127.0.0.1:5354 to 77.66.84.233:443
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8522]: dnscrypt-proxy Server certificate with serial #1518714001 received
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8522]: dnscrypt-proxy This certificate is valid
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8522]: dnscrypt-proxy Chosen certificate #1518714001 is valid from [2018-02-15] to [2018-02-16]
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8522]: dnscrypt-proxy Server key fingerprint is 05E8:B216:ACF0:1171:A827:32C6:4FA2:DDD6:6561:3A21:A4F8:80B3:9B19:5AF7:FC47:F342
Fri Feb 16 05:48:55 2018 daemon.notice dnscrypt-proxy[8522]: dnscrypt-proxy Proxying from 127.0.0.1:5353 to 45.76.35.212:443
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8524]: dnscrypt-proxy Server certificate with serial #1518755161 received
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8524]: dnscrypt-proxy This certificate is valid
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8524]: dnscrypt-proxy Chosen certificate #1518755161 is valid from [2018-02-16] to [2018-02-17]
Fri Feb 16 05:48:55 2018 daemon.info dnscrypt-proxy[8524]: dnscrypt-proxy Server key fingerprint is EF46:D92C:8EC6:19D9:0180:999C:D490:F409:74B3:FF28:4FBD:898A:BF68:2CC4:D1A2:077B
Fri Feb 16 05:48:55 2018 daemon.notice dnscrypt-proxy[8524]: dnscrypt-proxy Proxying from 127.0.0.1:5355 to 95.215.44.124:443

Anyone has an idea why this started to happen? And why the backup resolver failed?

Update:

Aaand it is not working anymore. After about 5minutes of switching to dnscrypt.nl-ns0, it stopped working again. I was totally confused and did this and it seems:

root@wrtarm:~# netstat-nat -L -d 95.215.44.124
Proto Source Address                 Destination Address            State
udp   10.0.1.199:33127               95.215.44.124:https            ASSURED
root@wrtarm:~# /etc/init.d/dnscrypt-proxy restart
root@wrtarm:~# /etc/init.d/dnsmasq restart
root@wrtarm:~# ping heise.de
ping: bad address 'heise.de'
root@wrtarm:~# netstat-nat -L -d 77.66.84.233
Proto Source Address                 Destination Address            State
root@wrtarm:~# /etc/init.d/dnscrypt-proxy restart
root@wrtarm:~# netstat-nat -L -d 77.66.84.233
Proto Source Address                 Destination Address            State
udp   10.0.1.199:39401               77.66.84.233:https             UNREPLIED

I get a status UNREPLIED for the connection to them after a while. How does this come? Totally sure there is something not working properly on their side.

It is working now again with:

Feb 16 07:10:54 2018 daemon.notice dnscrypt-proxy[13279]: dnscrypt-proxy Proxying from 127.0.0.1:5353 to 45.76.35.212:443
Fri Feb 16 07:10:54 2018 daemon.info dnscrypt-proxy[13280]: dnscrypt-proxy Server certificate with serial '0001' received
Fri Feb 16 07:10:54 2018 daemon.info dnscrypt-proxy[13280]: dnscrypt-proxy This certificate is valid
Fri Feb 16 07:10:54 2018 daemon.info dnscrypt-proxy[13280]: dnscrypt-proxy Chosen certificate #808464433 is valid from [2017-09-11] to [2018-09-11]
Fri Feb 16 07:10:54 2018 daemon.info dnscrypt-proxy[13280]: dnscrypt-proxy The key rotation period for this server may exceed the recommended value. This is bad for forward secrecy.
Fri Feb 16 07:10:54 2018 daemon.info dnscrypt-proxy[13280]: dnscrypt-proxy Server key fingerprint is D616:D268:09D2:29A7:9457:DE07:3DE8:EBD8:3C24:BFF3:2BF7:B406:108B:44DA:51FE:3711
Fri Feb 16 07:10:54 2018 daemon.notice dnscrypt-proxy[13280]: dnscrypt-proxy Proxying from 127.0.0.1:5354 to 77.66.84.233:443
Fri Feb 16 07:10:54 2018 daemon.info dnscrypt-proxy[13281]: dnscrypt-proxy Server certificate with serial #1518755161 received
Fri Feb 16 07:10:54 2018 daemon.info dnscrypt-proxy[13281]: dnscrypt-proxy This certificate is valid
Fri Feb 16 07:10:54 2018 daemon.info dnscrypt-proxy[13281]: dnscrypt-proxy Chosen certificate #1518755161 is valid from [2018-02-16] to [2018-02-17]
Fri Feb 16 07:10:54 2018 daemon.info dnscrypt-proxy[13281]: dnscrypt-proxy Server key fingerprint is EF46:D92C:8EC6:19D9:0180:999C:D490:F409:74B3:FF28:4FBD:898A:BF68:2CC4:D1A2:077B
Fri Feb 16 07:10:54 2018 daemon.notice dnscrypt-proxy[13281]: dnscrypt-proxy Proxying from 127.0.0.1:5355 to 95.215.44.124:443

but one of them still is broken it seems, yet the log says connection is established:

root@wrtarm:~# netstat-nat -L -d 45.76.35.212
Proto Source Address                 Destination Address            State
udp   10.0.1.199:41943               ns0.dnscrypt.nl:https          ASSURED
root@wrtarm:~# netstat-nat -L -d 77.66.84.233
Proto Source Address                 Destination Address            State
udp   10.0.1.199:40876               resolver2.dnscrypt.eu:https    UNREPLIED
root@wrtarm:~# netstat-nat -L -d 95.215.44.124
Proto Source Address                 Destination Address            State
udp   10.0.1.199:57740               95.215.44.124:https            ASSURED

So it seems if the first breaks, whatever reason, the two fall backs arent working. Is there something else I need to put in the dnsmasq config for it to work?

(Last edited by makedir on 16 Feb 2018, 07:27)

ninjaef wrote:

By thew way , what have you updated in the driver?]

As others have pointed out, I have just repackaged the updated drivers at kaloz's repo.

@makedir I have noticed the exact same bug with unbound as nameserver, using 3 upstream dnscrypt-proxy's, in some cases unbound seems to get confused using multiple upstream servers, resulting in nxdomains for valid domains.

I also tested with dnscrypt-proxy2 but it seems the same resolving issue appears, I think it might be related to anti ddos measures at the dnscrypt server side. Or some strict dnssec validation proces.

Weirdest part is that it happens to me after a few hours and some domains fail to resolv in unbound but not in dnscrypt, which lead me to believe that a random request to a upstream dnscrypt proxy resulted in a nxdomain.

I will test soms more but this bug is really annoying