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.

listerwrt wrote:
davidc502 wrote:

Okay, new builds based on kernel 4.9.30 and new wifi firmware (3200acm) have been uploaded to the site.

As usual these days, I'm interested in hearing from 1900ac Version 1 owners as to if the router reboot issue is still present.  I will be building a new image on kernel 4.4.x if the reboot issue still continues.

On a side note, dnscrypt was not working when my router came up on 4.9.30. I haven't had time to troubleshoot the issue, but noticed it doesn't appear to run even though I tried to manually start/restart the process, and there's nothing in the system or kernel logs.

Thanks,

I'm still getting reboots on official snapshot builds (https://forum.lede-project.org/t/wrt190 … =listerwrt)

I'm happy to test your build if you like. Let me know if you think it's necessary.

If already testing latest lede snapshot that includes kernel 4.9.30 then no need to test again.

davidc502 wrote:

Okay, new builds based on kernel 4.9.30 and new wifi firmware (3200acm) have been uploaded to the site.

As usual these days, I'm interested in hearing from 1900ac Version 1 owners as to if the router reboot issue is still present.  I will be building a new image on kernel 4.4.x if the reboot issue still continues.

On a side note, dnscrypt was not working when my router came up on 4.9.30. I haven't had time to troubleshoot the issue, but noticed it doesn't appear to run even though I tried to manually start/restart the process, and there's nothing in the system or kernel logs.

Thanks,

@david, to get dnscrypt working, I had to uninstall it, change my sources to point to lede snapshot sources (as I always do), and reinstall it.  Working fine now. 

Maybe an error in compiling it?

Edit: Also, I've been getting this error in my logs, I believe it is from the latest version of dnscrypt, but not certain.


Sat May 27 13:27:32 2017 user.notice : Sat May 27 13:27:32 2017 [WARNING] This system doesn't provide enough entropy to quickly generate high-quality random numbers
Sat May 27 13:27:32 2017 user.notice : Sat May 27 13:27:32 2017 [WARNING] Installing the rng-utils/rng-tools or haveged packages may help.
Sat May 27 13:27:32 2017 user.notice : Sat May 27 13:27:32 2017 [WARNING] On virtualized Linux environments, also consider using virtio-rng.
Sat May 27 13:27:32 2017 user.notice : Sat May 27 13:27:32 2017 [WARNING] The service will not start until enough entropy has been collected.

I've installed haveged to generate more entropy on boot and it successfully gets rid of the warning messages.

Edit: it is definitely the latest version of dnscrypt causing those warning messages.  However, that is unrelated to dnscrypt not working at all on fresh install of your latest build.  I believe something went wrong when building/compiling it.

Edit2: A small modification was made to dnscrypt 8 hours ago.  Don't think it made your build.

Edit3: Info here https://github.com/openwrt/packages/issues/4386 and fix here https://github.com/openwrt/packages/pull/4393.  Seems to happen because you compile dnscrypt with plugin support (awesome!), but they messed up the new check they had added to the init.d script (someone forgot that caps matter lol).  The reason the version of dnscrypt from the lede repo works is because it is built without plugin support.

So people who use dnscrypt can either grab it from your repo from an older build or from lede's snapshot repo.

Still no idea about the entropy warning on boot with latest verison of dnscrypt.  It still works without haveged, but haveged does generate more entropy directly at boot and gets rid of the warning messages and allows dnscrypt to start on it's first try.  Let me know if any of you also experience those warning messages if you are using the version from the lede snapshot repo.

(Last edited by starcms on 27 May 2017, 21:01)

@starcms

It's up and running again... I downloaded from here https://downloads.lede-project.org/snap … /packages/
and scp'd it to the /tmp directory

Then ran the following commands.

root@lede:~# opkg remove dnscrypt-proxy
Removing package dnscrypt-proxy from root...
Not deleting modified conffile /etc/config/dnscrypt-proxy.

root@lede:~# opkg install /tmp/dnscrypt-proxy_1.9.5-2_arm_cortex-a9_vfpv3.ipk
Installing dnscrypt-proxy (1.9.5-2) to root...
Configuring dnscrypt-proxy.
Collected errors:
* resolve_conffiles: Existing conffile /etc/config/dnscrypt-proxy is different                                                                                                                         from the conffile in the new package. The new conffile will be placed at /etc/co                                                                                                                        nfig/dnscrypt-proxy-opkg.

root@lede:~# /etc/init.d/dnscrypt-proxy enable

root@lede:~# /etc/init.d/dnscrypt-proxy start

root@lede:~# netstat -an |grep 5353
tcp        0      0 127.0.0.1:5353          0.0.0.0:*               LISTEN
udp        0      0 127.0.0.1:5353          0.0.0.0:*


Appreciate the research to find out what the issue was, and a work around.

@david, just to confirm, when you do compile dnscrypt-proxy, you compile it with plugins enabled  (DNSCRYPT_ENABLE_PLUGINS=y)?  I believe so, you'd have to or we wouldn't have encountered the issue of it crashing without any error message, just wanted to double check.

When you make your next build, it will have at least version 1.9.5-3 (instead of 1.9.5-2) and the issue will be resolved.  Only reason 1.9.5-2 from the snapshot repo doesn't crash silently is that it is compiled with plugins disabled and therefore not affected by the typo in the init.d script.

Do you also see those warning messages about low entropy when running version 1.9.5-2 from the lede snapshot repo in your system log?

(Last edited by starcms on 27 May 2017, 21:51)

starcms wrote:

@david, just to confirm, when you do compile dnscrypt-proxy, you compile it with plugins enabled  (DNSCRYPT_ENABLE_PLUGINS=y)?  I believe so, you'd have to or we wouldn't have encountered the issue of it crashing without any error message, just wanted to double check.

When you make your next build, it will have at least version 1.9.5-3 (instead of 1.9.5-2) and the issue will be resolved.  Only reason 1.9.5-2 from the snapshot repo doesn't crash silently is that it is compiled with plugins disabled and therefore not affected by the typo in the init.d script.

Do you also see those warning messages about low entropy when running version 1.9.5-2 from the lede snapshot repo in your system log?

Yes, plugin's are enabled... I checked the config seed and was there.

No, haven't seen any messages about entropy yet, but will keep looking.

I do now get messages about not having any plugins though.

Sat May 27 15:31:53 2017 user.warn dnscrypt-proxy: dnscrypt-proxy plugins support not present, ignoring BlockIPv6 parameter...
Sat May 27 15:31:53 2017 user.warn dnscrypt-proxy: dnscrypt-proxy plugins support not present, ignoring blacklist parameter...
Sat May 27 15:31:53 2017 user.info : dnscrypt-proxy - [cs-ussouth2] does not support DNS Security Extensions
Sat May 27 15:31:53 2017 user.info : dnscrypt-proxy + Provider supposedly doesn't keep logs
Sat May 27 15:31:53 2017 daemon.notice dnscrypt-proxy[10772]: dnscrypt-proxy Starting dnscrypt-proxy 1.9.5
Sat May 27 15:31:53 2017 daemon.info dnscrypt-proxy[10772]: dnscrypt-proxy Generating a new session key pair
Sat May 27 15:31:53 2017 daemon.info dnscrypt-proxy[10772]: dnscrypt-proxy Done
Sat May 27 15:31:53 2017 daemon.info dnscrypt-proxy[10772]: dnscrypt-proxy Server certificate with serial '0001' received
Sat May 27 15:31:53 2017 daemon.info dnscrypt-proxy[10772]: dnscrypt-proxy This certificate is valid
Sat May 27 15:31:53 2017 daemon.info dnscrypt-proxy[10772]: dnscrypt-proxy Chosen certificate #808464433 is valid from [2016-11-03] to [2026-11-01]
Sat May 27 15:31:53 2017 daemon.info dnscrypt-proxy[10772]: dnscrypt-proxy The key rotation period for this server may exceed the recommended value. This is bad for forward secrecy.
Sat May 27 15:31:53 2017 daemon.info dnscrypt-proxy[10772]: dnscrypt-proxy Server key fingerprint is 

Sat May 27 15:31:53 2017 daemon.notice dnscrypt-proxy[10772]: dnscrypt-proxy Proxying from 127.0.0.1:5353 to 108.62.19.131:443
Sat May 27 15:32:12 2017 user.warn dnscrypt-proxy: dnscrypt-proxy plugins support not present, ignoring BlockIPv6 parameter...
Sat May 27 15:32:12 2017 user.warn dnscrypt-proxy: dnscrypt-proxy plugins support not present, ignoring blacklist parameter...

(Last edited by davidc502 on 27 May 2017, 21:58)

I just went and installed the dnscrypt-proxy from your repo (the version that came with your latest build), then edited the init.d file to match the changes made to 1.9.5-3 (it's just two words).  Now it works just fine, and no longer shows the lines saying plugins are not present, because you built it with plugin support (unlike the snapshot repo version)  So best of both worlds!  Easiest solution I think is just to take your original build, and apply these changes to /etc/init.d/dnscrypt-proxy  https://github.com/openwrt/packages/com … a4ae4a2502

Edit: I may be getting the entropy warnings because I recently started using a dnscrypt resolver that supports DNSSEC.

Sat May 27 16:06:12 2017 user.info : dnscrypt-proxy + DNS Security Extensions are supported
Sat May 27 16:06:12 2017 user.info : dnscrypt-proxy + Provider supposedly doesn't keep logs
Sat May 27 16:06:12 2017 daemon.notice dnscrypt-proxy[5185]: dnscrypt-proxy Starting dnscrypt-proxy 1.9.5
Sat May 27 16:06:12 2017 daemon.info dnscrypt-proxy[5185]: dnscrypt-proxy Generating a new session key pair
Sat May 27 16:06:12 2017 daemon.info dnscrypt-proxy[5185]: dnscrypt-proxy Done
Sat May 27 16:06:12 2017 daemon.info dnscrypt-proxy[5185]: dnscrypt-proxy Server certificate with serial #1495910581 received
Sat May 27 16:06:12 2017 daemon.info dnscrypt-proxy[5185]: dnscrypt-proxy This certificate is valid
Sat May 27 16:06:12 2017 daemon.info dnscrypt-proxy[5185]: dnscrypt-proxy Chosen certificate #1495910581 is valid from [2017-05-27] to [2017-05-28]
Sat May 27 16:06:12 2017 daemon.info dnscrypt-proxy[5185]: dnscrypt-proxy Server key fingerprint is XXXXXX
Sat May 27 16:06:12 2017 daemon.notice dnscrypt-proxy[5185]: dnscrypt-proxy Proxying from 127.0.0.1:5353 to 107.181.168.52:443

(Last edited by starcms on 27 May 2017, 22:16)

Just checked and yes, that works even better... Thanks

davidc502 wrote:

Just checked and yes, that works even better... Thanks

I was the one that started the whole issue with dnscrypt and the plugins in the LEDE forum, guilty smile

Before they "fixed" it ( therefore removing plugin support in the official repo ) , I've saved a copy of version 1.9.4-3 .

Now, to avoid messing with the init.d script after I realized dnscrypt was crashing silently on the new build David did, I've just uninstalled the dnscrypt-proxy that comes with David's build, and installed my own.

I'm leaving a copy of version 1.9.4-3 for anyone to use here: https://www.dropbox.com/s/nbk7frah5061z … 3.ipk?dl=0 , until this whole thing clears out and we can use the latest version WITH plugin support ( which is great to be able to block sites and log those blocks, and also to block ipv6 requests! )

Linksys WRT1900AC  v1

Firmware Version    Lede Reboot SNAPSHOT r4222-7142cb4 / LuCI Master (git-17.145.19303-ee6110b)

Kernel Version    4.9.30
Uptime    0h 6m 54s


wlan1 SamsungNote3

-41 / -90 dBm    48.0 Mbit/s, 20MHz
433.3 Mbit/s, 80MHz, VHT-MCS 9, VHT-NSS 1, Short GI


Did the sysupgrade flash but it is early; so far in and up, so we'll see how it goes will report back later

Cheers

Hans

mariano.silva wrote:

I was the one that started the whole issue with dnscrypt and the plugins in the LEDE forum, guilty smile

Have you seen any of the entropy warning log entries I mentioned a few posts up?  If not, would you try using a resolver that supports DNSSEC (all the ones that begin with d0wn support it -- I am currently using d0wn-us-ns4).  I'm unsure if it's related to using DNSSEC alone, or using version 1.9.5-X with DNSSEC, or something else entirely.  @david is currently using his 1.9.5-2 with the simple init.d fixes and plugin support (same as me), and doesn't see the entropy warning in the log, but the resolver he is using doesn't support DNSSEC.

(Last edited by starcms on 28 May 2017, 06:10)

hancor wrote:

Linksys WRT1900AC  v1



-41 / -90 dBm   


Hans

Wow!  I have never seen a signal that high!  Mine are normally in the -50s to -60s, even if very close to the router.  Noise level is same as I get.

starcms wrote:
mariano.silva wrote:

I was the one that started the whole issue with dnscrypt and the plugins in the LEDE forum, guilty smile

Have you seen any of the entropy warning log entries I mentioned a few posts up?  If not, would you try using a resolver that supports DNSSEC (all the ones that begin with d0wn support it -- I am currently using d0wn-us-ns4).  I'm unsure if it's related to using DNSSEC alone, or using version 1.9.5-X with DNSSEC, or something else entirely.  @david is currently using his 1.9.5-2 with the simple init.d fixes and plugin support (same as me), and doesn't see the entropy warning in the log, but the resolver he is using doesn't support DNSSEC.

I had the warnings using d0wn au which doesn't support DNSSEC. Still have it after switching to one that does (dnscrypt.org-fr)

listerwrt wrote:
starcms wrote:
mariano.silva wrote:

I was the one that started the whole issue with dnscrypt and the plugins in the LEDE forum, guilty smile

Have you seen any of the entropy warning log entries I mentioned a few posts up?  If not, would you try using a resolver that supports DNSSEC (all the ones that begin with d0wn support it -- I am currently using d0wn-us-ns4).  I'm unsure if it's related to using DNSSEC alone, or using version 1.9.5-X with DNSSEC, or something else entirely.  @david is currently using his 1.9.5-2 with the simple init.d fixes and plugin support (same as me), and doesn't see the entropy warning in the log, but the resolver he is using doesn't support DNSSEC.

I had the warnings using d0wn au which doesn't support DNSSEC. Still have it after switching to one that does (dnscrypt.org-fr)

All of the d0wn servers support DNSSEC.  Did you see my post a couple days ago?

The package dnscrypt-proxy-resolvers (which provides the dnscrypt-resolvers.csv file) is extremely out of date (from 11-2016).  There have been many changes, corrections, and additions.  I'd highly recommend updating the file at /usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv with the latest one from https://download.dnscrypt.org/dnscrypt- … olvers.csv

But you did confirm my hypothesis that the warnings are caused by dnscrypt when using a resolver that supports DNSSEC. 

The issue is that on bootup, entropy is extremely low (below 1000).  After a few minutes, it rises to an acceptable level and stays there (seems to sit happily at 3413).  However, the package haveged boosts the entropy pool immediately at boot to an acceptable level (approx 2000) so that dnscrypt does not give those warnings.

You can check the level of entropy with

cat /proc/sys/kernel/random/entropy_avail

It should always be greater than 1000 for proper performance of all programs.  However, at boot and for a couple minutes afterwards, it remains below 1000.  Installing the package haveged resolves this issue.  @david, you may want to take a look at this.  It's not related to the new kernel version in your latest build.  Issue has been there for a long time, but was just never noticed before.

(Last edited by starcms on 28 May 2017, 08:55)

Last time I read the logs it was saying the provider didn't support DNSSEC extensions. You are right though, their site says they do support it on all servers now. Is that a recent change? Last I read they had turned it off due to performance issues. I'd test the d0wn-au server but it's offline at the moment

I tend to use ones outside my country as they are probably subject to our metadata retention scheme anyway which would defeat the purpose.

Anyway, point is I get the entropy error too (k4.4).

listerwrt wrote:

Last time I read the logs it was saying the provider didn't support DNSSEC extensions. You are right though, their site says they do support it on all servers now. Is that a recent change? Last I read they had turned it off due to performance issues. I'd test the d0wn-au server but it's offline at the moment

I tend to use ones outside my country as they are probably subject to our metadata retention scheme anyway which would defeat the purpose.

Anyway, point is I get the entropy error too (k4.4).

The logs were saying the d0wn servers didn't/don't support DNSSEC because of the out-of-date and incorrect dnscrypt-resolvers.csv file.

I think we need a Luci ap for DNSCrypt.

I am with a 1200AC v2 and i am keeping up to date with the last 4 builds by David.
My iperf3 results are dissapointing.

5ghz


Accepted connection from 10.10.10.154, port 1755
[  5] local 10.10.10.1 port 5201 connected to 10.10.10.154 port 1756
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  11.2 MBytes  93.5 Mbits/sec
[  5]   1.00-2.00   sec  13.4 MBytes   112 Mbits/sec
[  5]   2.00-3.00   sec  13.6 MBytes   114 Mbits/sec
[  5]   3.00-4.00   sec  13.5 MBytes   114 Mbits/sec
[  5]   4.00-5.00   sec  13.1 MBytes   110 Mbits/sec
[  5]   5.00-6.00   sec  12.7 MBytes   106 Mbits/sec
[  5]   6.00-7.00   sec  12.6 MBytes   105 Mbits/sec
[  5]   7.00-8.00   sec  11.5 MBytes  96.5 Mbits/sec
[  5]   8.00-9.00   sec  12.1 MBytes   101 Mbits/sec
[  5]   9.00-10.00  sec  12.1 MBytes   101 Mbits/sec
[  5]  10.00-10.06  sec   640 KBytes  81.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.06  sec   126 MBytes   105 Mbits/sec                  receiver


2.4Ghz

Connecting to host 10.10.10.1, port 5201
[  4] local 10.10.10.154 port 1937 connected to 10.10.10.1 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.01   sec  2.25 MBytes  18.7 Mbits/sec
[  4]   1.01-2.01   sec  2.25 MBytes  18.9 Mbits/sec
[  4]   2.01-3.01   sec  2.12 MBytes  17.8 Mbits/sec
[  4]   3.01-4.01   sec  2.12 MBytes  17.9 Mbits/sec
[  4]   4.01-5.01   sec  2.25 MBytes  18.8 Mbits/sec
[  4]   5.01-6.01   sec  2.12 MBytes  17.8 Mbits/sec
[  4]   6.01-7.01   sec  2.25 MBytes  18.9 Mbits/sec
[  4]   7.01-8.01   sec  2.12 MBytes  17.8 Mbits/sec
[  4]   8.01-9.01   sec  1.50 MBytes  12.7 Mbits/sec
[  4]   9.01-10.01  sec  1.88 MBytes  15.7 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.01  sec  20.9 MBytes  17.5 Mbits/sec                  sender
[  4]   0.00-10.01  sec  20.9 MBytes  17.5 Mbits/sec                  receiver


Device used: MacBook Pro 2016.
Distance to the router: about 3m


EDITED: I get more or less the same results with the stock firmware.

There are no other wifi networks around to interfear on the same channel.
Except 2 repeaters of my own network (can the repeater of the same network cause trouble on the wifi?)
I tried to move the router to another location inside the house, as it was placed on the wall behind the electrical panel. No improvement.
I will start believing i live in a Faraday cage.

(Last edited by Pasxalisk on 28 May 2017, 10:26)

Hi davidc502,

Thank you for the great builds!
i have WRT1900v2 , until your snapshot r4114 , everything was working fine.
but since the later two builds (r4164, r4222), my devices take A very long time to connect to the wifi network- 5g included.
can you please advice.

(Last edited by waleed.soliman on 28 May 2017, 12:48)

starcms wrote:
listerwrt wrote:

Last time I read the logs it was saying the provider didn't support DNSSEC extensions. You are right though, their site says they do support it on all servers now. Is that a recent change? Last I read they had turned it off due to performance issues. I'd test the d0wn-au server but it's offline at the moment

I tend to use ones outside my country as they are probably subject to our metadata retention scheme anyway which would defeat the purpose.

Anyway, point is I get the entropy error too (k4.4).

The logs were saying the d0wn servers didn't/don't support DNSSEC because of the out-of-date and incorrect dnscrypt-resolvers.csv file.

I only skimmed what you said sorry... Just updated the resolvers file and it seems there is no d0wn au server in it anymore. Thanks for the tip, I had no idea I could just update it manually.

davidc502 wrote:

Okay, new builds based on kernel 4.9.30 and new wifi firmware (3200acm) have been uploaded to the site.

As usual these days, I'm interested in hearing from 1900ac Version 1 owners as to if the router reboot issue is still present.  I will be building a new image on kernel 4.4.x if the reboot issue still continues.

Was a decision made on whether or not the 4.4.x version is needed for v1 owners?

@starcms

Can you please give me the EAN code from your 1200AC v1 box?

I am trying to find a v1 online to buy and i am not sure how to tell ask the eshop to see if it v1 or v2.
I guess (and hope) they have different EAN numbers.

EDIT: I also saw on my v2 box over the EAN number saying "8830-22484 Rev. B00".

What is yours saying?

(Last edited by Pasxalisk on 28 May 2017, 14:23)

zabolots wrote:
davidc502 wrote:

Okay, new builds based on kernel 4.9.30 and new wifi firmware (3200acm) have been uploaded to the site.

As usual these days, I'm interested in hearing from 1900ac Version 1 owners as to if the router reboot issue is still present.  I will be building a new image on kernel 4.4.x if the reboot issue still continues.

Was a decision made on whether or not the 4.4.x version is needed for v1 owners?

Tested the latest and in a 24hr period had 2 reboots happen.  Went back to 4.4.x

waleed.soliman wrote:

Hi davidc502,

Thank you for the great builds!
i have WRT1900v2 , until your snapshot r4114 , everything was working fine.
but since the later two builds (r4164, r4222), my devices take A very long time to connect to the wifi network- 5g included.
can you please advice.

Join a a couple of those devices, and look in the system and kernel logs and paste them here.

*EDIT*

Now that you mention it, I did do some 1900acs testing with r4164, and noticed a bit of a slow down with my devices connecting. My android and iphone connect quickly with the 3200acm.

*EDIT2*

On one of those devices turn off wifi, and turn wifi back on and time how long it takes to re-connect.

(Last edited by davidc502 on 28 May 2017, 16:10)

zabolots wrote:
davidc502 wrote:

Okay, new builds based on kernel 4.9.30 and new wifi firmware (3200acm) have been uploaded to the site.

As usual these days, I'm interested in hearing from 1900ac Version 1 owners as to if the router reboot issue is still present.  I will be building a new image on kernel 4.4.x if the reboot issue still continues.

Was a decision made on whether or not the 4.4.x version is needed for v1 owners?

Based upon what @shatazer reported, it looks like I'll need to build for kernel 4.4.

@Pasxalisk

Guess you're getting the same disappointing performance? Well at least you're looking to get a v1 or something else.. I'm stuck with my v2. I'm sad to see that at only 10 feet the speeds are that bad, wow.

Guess since you stated that there's basically no other conflicting networks in your area I can say that the v2 is just a dud. Nothing can really fix I guess sad

Sorry, posts 2051 to 2050 are missing from our archive.