I have it here already ... in my 1900ACS v2, not sure how it got here

root@RouterACS:/etc# opkg list-installed | grep mwl
kmod-mwlwifi - 4.9.30+10.3.4.0-20170512-1

starcms wrote:

The latest official version of the mwlwifi driver has finally been merged into the LEDE snapshot/master branch.

I know it's a bit off topic (and I won't do that again ), but how can you be sure ? Any links ?

For me:

opkg list-installed | grep mwl
kmod-mwlwifi - 4.9.30+10.3.2.0-20170110-1

Edit: Ok, i've seen this:

//git.lede-project.org/?p=source.git;a=commitdiff;h=e783f588eba1ef56365f1293e01509140b115f7a;hp=c87aa0d7ca8f2dcd3cf559a4933fef3cb44f7a21

but no 10.3.4.0.git-2017-05-26 in the update package....

Edit2: I think it will available tomorrow after compilation...

RADIUS: starting accounting session

mariano.silva wrote:

I have it here already ... in my 1900ACS v2, not sure how it got here

root@RouterACS:/etc# opkg list-installed | grep mwl
kmod-mwlwifi - 4.9.30+10.3.4.0-20170512-1

Sarcasm?  I'm pretty damn sure , but if not, it's there because @david specifically compiled and included it from the kaloz/mwlwifi sources.  Just one of the reasons why @david's builds are the best out there, imho.

I don't know now since it'll be included in the snapshot/master branch, if it will possibly make it easier for @david to make his builds in the future.  I'm sure there will be new commits added to kaloz/mwlwifi sooner rather than later, and who knows how long until the snapshot branch gets a new push of the latest version again.  It still had 10.3.2.0-20170110 included before the merge yesterday (which is over 45 commits out of date).

aqwserf wrote:

starcms wrote:

The latest official version of the mwlwifi driver has finally been merged into the LEDE snapshot/master branch.

I know it's a bit off topic (and I won't do that again ), but how can you be sure ? Any links ?

For me:

opkg list-installed | grep mwl
kmod-mwlwifi - 4.9.30+10.3.2.0-20170110-1

Edit: Ok, i've seen this:

//git.lede-project.org/?p=source.git;a=commitdiff;h=e783f588eba1ef56365f1293e01509140b115f7a;hp=c87aa0d7ca8f2dcd3cf559a4933fef3cb44f7a21

but no 10.3.4.0.git-2017-05-26 in the update package....

Edit2: I think it will available tomorrow after compilation...

Are you running @david's build?  It should show you have version 20170512-1 (plus it also has all the latest commits made after 5/12/2017; the version number simply hasn't changed because there hasn't been a commit to update it)

root@WRT1200AC:~# opkg list-installed | grep mwlwifi
kmod-mwlwifi - 4.9.30+10.3.4.0-20170512-1

starcms wrote:

mariano.silva wrote:

I have it here already ... in my 1900ACS v2, not sure how it got here

root@RouterACS:/etc# opkg list-installed | grep mwl
kmod-mwlwifi - 4.9.30+10.3.4.0-20170512-1

Sarcasm?  I'm pretty damn sure , but if not, it's there because @david specifically compiled and included it from the kaloz/mwlwifi sources.  Just one of the reasons why @david's builds are the best out there, imho.

I don't know now since it'll be included in the snapshot/master branch, if it will possibly make it easier for @david to make his builds in the future.  I'm sure there will be new commits added to kaloz/mwlwifi sooner rather than later, and who knows how long until the snapshot branch gets a new push of the latest version again.  It still had 10.3.2.0-20170110 included before the merge yesterday (which is over 45 commits out of date).

Apparently all the new commits are in the Snapshot:

https://forum.lede-project.org/t/wrt320 … 05-30/4070

In quotes below,  one of the comments from yesterday:

"Yep. Buildbot compiles new version after any new commits.
Depending on the pace of the new commits there may also be days without a build, if there are no commits. Like e.g. for mvebu there has been 3 builds today, but no build on 28th"

@davidc502 , @starcms,

i upgraded again to r4222 then removed the wpad package then installed wpad mini package , the good news is the message of

RADIUS: starting accounting session

disappeared from the log as @starcms suggested, this is the log:

however, the delay problem is still there

Okay, I have disabled http (port 80) traffic to the site as well as disabled SSLv3 . This may cause issue for some users who are running older builds that only leveraged http via opkg. Let me know if this is the case and I can re-enable http for a short time allowing users to download the packages they need to support TLS.

SSLv3 has been depreciated for some time, and I keep getting dinged on the websites security certification..... So, the support has been removed.

Let me know if there are questions/concerns.

@davidc502 , @starcms,

i upgraded again to r4222 then removed the wpad package then installed wpad mini package , the good news is the message of

RADIUS: starting accounting session

disappeared from the log as @starcms suggested, this is the log:

Wed May 31 19:06:01 2017 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED ec:88:92:73:12:a4
Wed May 31 19:06:01 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: disassociated
Wed May 31 19:06:02 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed May 31 19:06:09 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: authenticated
Wed May 31 19:06:09 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: associated (aid 2)
Wed May 31 19:06:09 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED ec:88:92:73:12:a4
Wed May 31 19:06:09 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 WPA: pairwise key handshake completed (RSN)
Wed May 31 19:06:14 2017 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED ec:88:92:73:12:a4
Wed May 31 19:06:14 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: disassociated
Wed May 31 19:06:15 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed May 31 19:06:31 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: authenticated
Wed May 31 19:06:31 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: associated (aid 2)
Wed May 31 19:06:31 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED ec:88:92:73:12:a4
Wed May 31 19:06:31 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 WPA: pairwise key handshake completed (RSN)
Wed May 31 19:07:07 2017 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED ec:88:92:73:12:a4
Wed May 31 19:07:07 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: disassociated
Wed May 31 19:07:08 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed May 31 19:07:15 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: authenticated
Wed May 31 19:07:15 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: associated (aid 2)
Wed May 31 19:07:15 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED ec:88:92:73:12:a4
Wed May 31 19:07:15 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 WPA: pairwise key handshake completed (RSN)
Wed May 31 19:07:51 2017 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED ec:88:92:73:12:a4
Wed May 31 19:07:51 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: disassociated
Wed May 31 19:07:52 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed May 31 19:07:55 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: authenticated
Wed May 31 19:07:55 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 IEEE 802.11: associated (aid 2)
Wed May 31 19:07:55 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED ec:88:92:73:12:a4
Wed May 31 19:07:55 2017 daemon.info hostapd: wlan1: STA ec:88:92:73:12:a4 WPA: pairwise key handshake completed (RSN)
Wed May 31 19:08:11 2017 user.warn igmpproxy[2719]: MRT_DEL_MFC; Errno(2): No such file or directory

however, the delay problem is still there

Let's try something different, and hopefully eliminate a client issue.  Delete the SSID and create a new one with a different name. On the clients, forget or remove the old SSID, and connect to the new SSID.

If that doesn't work, try changing encryption levels including no encryption, and see how that goes.  Also, make sure WMM mode is enabled.

*EDIT*

This is happening on the MAC and android, but not the Windows machine?

mariano.silva wrote:

I have it here already ... in my 1900ACS v2, not sure how it got here

root@RouterACS:/etc# opkg list-installed | grep mwl
kmod-mwlwifi - 4.9.30+10.3.4.0-20170512-1

Sarcasm?  I'm pretty damn sure , but if not, it's there because @david specifically compiled and included it from the kaloz/mwlwifi sources.  Just one of the reasons why @david's builds are the best out there, imho.

starcms wrote:

mariano.silva wrote:

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

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.

Sorry for the delay in getting back to you @starcms. I'm not using a DNSSEC resolver , and I'm not getting the entropy warnings. I've switched to 'd0wn-it-ns1' which supports DNSSEC now, and will leave it running for some time to see if I see the warning and report back to you.

mariano.silva wrote:

starcms wrote:

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.

Sorry for the delay in getting back to you @starcms. I'm not using a DNSSEC resolver , and I'm not getting the entropy warnings. I've switched to 'd0wn-it-ns1' which supports DNSSEC now, and will leave it running for some time to see if I see the warning and report back to you.

@starcms ... i had dnsproxy running for over 24 hours now with a DNSSEC DNS, and I had no entropy warning messages... going back to my old DNS now, can I?

I have a WRT1900AC v1 router. I had tried using the firmware with the 4.9 kernel, which gave me the rebooting error, so I downgraded to 4.4 (r4222) and restoring a backup. While the rebooting is solved, there are some warningsin the logs that I can't solve. I am getting a lot of warnings from igmpproxy (see below). I have a static lease for an NAS device at 192.168.1.101. These redirects are happening several times per minute, which may be making the wireless connection worse and causing the router to run hotter than usual.

When searching for answers online to this warning, most results were bug reports with a maintainer saying "try this new version and see if it fixes it", which is not helpful to me...

...
Wed May 31 21:54:31 2017 user.warn igmpproxy[3708]: The origin for route 239.255.255.250 changed from 192.168.1.101 to 192.168.1.159
Wed May 31 21:54:35 2017 user.warn igmpproxy[3708]: The origin for route 239.255.255.250 changed from 192.168.1.159 to 192.168.1.101
Wed May 31 21:54:43 2017 user.warn igmpproxy[3708]: The origin for route 239.255.255.250 changed from 192.168.1.101 to 192.168.1.221
Wed May 31 21:55:00 2017 cron.info crond[1425]: USER root pid 22033 cmd /sbin/fan_ctrl.sh
Wed May 31 21:55:14 2017 user.warn igmpproxy[3708]: The origin for route 239.255.255.250 changed from 192.168.1.221 to 192.168.1.101
Wed May 31 21:55:18 2017 user.warn igmpproxy[3708]: The origin for route 239.255.255.250 changed from 192.168.1.101 to 192.168.1.221
Wed May 31 21:55:53 2017 user.warn igmpproxy[3708]: The origin for route 239.255.255.250 changed from 192.168.1.221 to 192.168.1.101
Wed May 31 21:56:31 2017 user.warn igmpproxy[3708]: The origin for route 239.255.255.250 changed from 192.168.1.101 to 192.168.1.159
Wed May 31 21:56:33 2017 user.warn igmpproxy[3708]: The origin for route 239.255.255.250 changed from 192.168.1.159 to 192.168.1.101
Wed May 31 21:56:38 2017 user.warn igmpproxy[3708]: The origin for route 239.255.255.250 changed from 192.168.1.101 to 192.168.1.164
Wed May 31 21:56:47 2017 user.warn igmpproxy[3708]: The origin for route 239.255.255.250 changed from 192.168.1.164 to 192.168.1.221
Wed May 31 21:57:11 2017 user.warn igmpproxy[3708]: The origin for route 239.255.255.250 changed from 192.168.1.221 to 192.168.1.101
Wed May 31 21:57:18 2017 user.warn igmpproxy[3708]: The origin for route 239.255.255.250 changed from 192.168.1.101 to 192.168.1.221
...

I'm also getting several errors of

daemon.info odhcpd[1357]: Using a RA lifetime of 0 seconds on br-lan

If you aren't using igmpproxy like myself (@david added it for those with IPTV), simply remove or disable it.  That's what I did because of similar log entries. 

Odhcpd is for DHCPv6.  Do you have IPv6 set up?  If not, you can disable Router-Advertisement(RA)-service and DHCPv6-service under the IPv6 tab of DHCP Server in your LAN interface.

The warnings only occur once upon boot, because on boot, the entropy pool is low (<1000, around 800).  After a few minutes, it rises and maintains a very healthy level (>>>1000, around 3400).  So at that time, dnscrypt will automatically try loading again and succeed.  Entropy level should always be >1000 for proper functioning of all packages.

However, to get a larger entropy pool on boot and get rid of the warning messages, you can simply install the package haveged.  No configuration is required at all.

Entropy may decrease also later if your apps consume lots of entropy. E.g. VPN keys, sessions etc. will take entropy.

Low entropy will be a problem with the new mwlwifi driver. It generates much less interrupt based entropy for the kernel than the previous radio driver. The problem is visible at least on wrt3200acm.

Sera made a good suggestion to yuhhaurlin that mwlwifi would act like ath9k and insert additional natural entropy (from radio noise) to kernel, but so far the feature has not been implemented and the discussion got badly hijacked/sidetracked by some users :-(
https://github.com/kaloz/mwlwifi/issues/150
I wrote my observations on:
https://github.com/kaloz/mwlwifi/issues … -297695929

Using haveged with the mwlwifi driver is a good idea. Otherwise there may be a risk of running out of entropy.

I don't know if is has beeen said before, but on the 1200AC the 5ghz is reporting wrong signal strength on connected devices.
For example I get -90 for my iPhone, being 5m away from the router.
And on the iPhone, signal strength is full.