@starcms, @Sizeable Swiss, @Pasxalisk

FWIW, full disclosure:

I got my router from the "Linksys Official Store" on eBay, a REFURB.

http://stores.ebay.com/linksysofficialstore/

It came in a "Belkin" outer box with a Belkin packing list.

Label on router reads:

    s/n:        16R20606605xxx
    model:    WRT1200AC V2
                    8830 23714
                    Rev. A00
           
Luci Wireless overview says:

    signal/noise:    -55/-90 dBm
    RX/TX rate:    300.0 Mbit/s, 40MHz, MCS 15, Short GI
   
Laptop is a 2011 Macbook Pro

    Card Type:        AirPort Extreme
    Firmware Ver:    Broadcom BCM43xx 1.0
    PHY Mode:        802.11n
    Channel:            36,1
    Country Code:    US
    Network Type:    Infrastructure
    Signal / Noise:    -41 dBm / -86 dBm
    Transmit Rate:    300
    MCS Index:        15

S.

(Last edited by seanc on 29 May 2017, 17:03)

@davidc502,

I don't know when the message started appearing, but I have the same message in the logs with R4222.
My security settings are 'WPA2 personal' and certainly not 'WPA2 enterprise'.
I have also seem the same message with 'WPA personal' settings.
It seems to be an informational message about authentication only.

Yeap, same here @adri . I've changed the log verbosity to a lower level to not see that anymore

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

EDIT:   okay getting random reboots on the V1 averaging 20 - 30 minute cycles;  sorry for the delay in getting back as an unrelated RAID array configuration needed some attention.

Cheers
Hans

Kernel 4.4.70 is currently building. I'll have it out on the site in a few hours or less.

I'm thinking I should make it the primary download for 1900ac Version 1 Owners

Ahh, all the really worthwhile things in life take time and patience.

The present build is up substantially from the 5 - 15 minute reboot cycle previous.

We're now at 20 - 30 minute cycles.

Sometimes you just have to keep plinking away at it, until you hit the Bullseye!

Cheers

Hans

I tend to agree. Hopefully someone will be able to figure this out so it won't be necessary at some point in the future.

Kernel 4.4.70 build is in for 1900ac Version 1 owners  >  https://davidc502sis.dynamic-dns.net/sn … u/generic/

I'm not going to make it the primary yet on the downloads/releases page.

@david, I'm not seeing this RADIUS message.  Never have and still don't on your latest build.

However, it seems the 1900ACS V2 have as their model number as "WRT1900ACS V2" (at least on the bottom of the router, not sure about on the box).  Whereas, the WRT1900ACS V1, would simply have "WRT1900ACS" as it's model number (but again, not sure about the box).  So it should make it easy to determine if its a V1 or V2 if you can get an actual pic of the bottom of the router.  Be warned though that the 1900AC V2, 1900ACS V1, and 1900ACS V2 all have the same FCC ID.

Regarding the serial numbers of those 3 of you who have 1200AC V2's:

@Pasaxalisk and @Sizeable Swiss (who have issues with the 1200 V2's) serial numbers are:

16R20607609xxx and
16R20601703xxx

while @seanc's (who doesn't have issues with his 1200AC V2) is:

16R20606605xxx

So my interpretation of that is that all 3 come from 3 different manufacturing batches.  So at least 2 batches were bad.  And a good batch was in-between two bad batches.

Edit: Of course it's entirely possible that not the entire batches were bad, just a couple routers out of each one.  And also very interesting that @seanc's, which works properly, was a referb sold by Linksys.  My advice is if you are having ridiculously low speeds on stock Linksys firmware and @david's firmware, call Linksys and demand a replacement.

Edit2: From now on I'll abide by @david's wishes and limit conversation to things pertaining to his builds in this thread.  Sorry about that @david.

(Last edited by starcms on 30 May 2017, 05:47)

@davidc502,

through my Mac , i first forgot the SSID 2.4 GH, reboot, then tried to connect again , still have the same issue.

then i downgraded to r4114, and here you are the log

Tue May 30 13:19:19 2017 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED c8:e0:eb:19:62:79
Tue May 30 13:19:19 2017 daemon.info hostapd: wlan1: STA c8:e0:eb:19:62:79 IEEE 802.11: disassociated
Tue May 30 13:19:20 2017 daemon.info hostapd: wlan1: STA c8:e0:eb:19:62:79 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Tue May 30 13:19:22 2017 daemon.info hostapd: wlan1: STA c8:e0:eb:19:62:79 IEEE 802.11: authenticated
Tue May 30 13:19:22 2017 daemon.info hostapd: wlan1: STA c8:e0:eb:19:62:79 IEEE 802.11: associated (aid 2)
Tue May 30 13:19:22 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED c8:e0:eb:19:62:79
Tue May 30 13:19:22 2017 daemon.info hostapd: wlan1: STA c8:e0:eb:19:62:79 WPA: pairwise key handshake completed (RSN)
Tue May 30 13:19:24 2017 daemon.warn odhcpd[1600]: received DHCPV4_MSG_REQUEST from c8:e0:eb:19:62:79
Tue May 30 13:19:24 2017 daemon.warn odhcpd[1600]: sending DHCPV4_MSG_ACK to c8:e0:eb:19:62:79 - 192.168.1.250

the

entry is not there anymore, and connecting to wifi is really fast!

@starcms
i did some googling about the issue and i found this issue ticket
dev.openwrt.org/ticket/20928

according to those folks ,

this log entry represent the issue, however, in the answer it was mentioned the following :

i'm not sure if this is the same in my case , can guys advise

@david

The only difference I see that could possibly cause this is r4114 (and all older builds) used wpad-mini, while r4164 and r4222 use wpad.

However, it shouldn't cause these problems.  And I am not experiencing any connection issues nor any

RADIUS: starting accounting session

or

deauthenticated due to inactivity (timer DEAUTH/REMOVE)

log entries on r4222.

However, maybe just to be on the safe side, you should try reverting to wpad-mini for the next build to see if it solves the connection issues some are having?

Also, Look at this:

Description of wpad: This package contains a full featured IEEE 802.1x/WPA/EAP/RADIUS Authenticator and Supplicant

Description of wpad-mini: This package contains a minimal IEEE 802.1x/WPA Authenticator and Supplicant (WPA-PSK only)

Obviously, space is not a concern for us, which is why I'm guessing you decided to change to wpad, but perhaps wpad-mini is more compatible, at least for some people with certain devices.

(Last edited by starcms on 30 May 2017, 07:06)

It is not normal for odhcpd to be the DHCPv4 server.  That should be left to dnsmasq.  odhcpd is meant for IPv6 only.  I would revert to default settings if I were you.

(Last edited by starcms on 30 May 2017, 07:00)

Thanks David! Running well so far.

Btw I don't seem to have the RADIUS errors others are having. Using WPA2-PSK with forced TKIP+CCMP.

(Last edited by listerwrt on 30 May 2017, 08:56)

Thanks David.
Do you know if the DNSCrypt issue has been fixed in this relase or we still need to apply a workaround?

(Last edited by Rafkat on 30 May 2017, 08:41)

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

Yes, the same dnscrypt issue will affect this build as well. Use the work around until the next build which will contain the fix.

For those running dnscrypt, I made a very simple script that will update the dnscrypt-resolvers.csv file only if an updated version has been published to the website.  You can add a cron task (Go to System --> Scheduled Tasks in Luci) and add the line

0 3 * * 2,5     sh /etc/upgraderesolv.sh

to run it every Tuesday and Friday and 3am.  Of course, you can change how often it is run and the location and name of the script itself.  Or you can just run it manually whenever you decide to.

You should also go to LuCi --> System --> Backup / Flash Firmware and Click the configuration tab and enter

/etc/upgraderesolv.sh

or whatever you name it and where ever you save it, so that it will be added to your backups.  The cron task is automatically backed up.

Anyway, here is the script.  It's very basic, but it gets the job done.

#!/bin/sh

RESOLVERS_URL="https://download.dnscrypt.org/dnscrypt-proxy/dnscrypt-resolvers.csv"

echo "Updating the list of public DNSCrypt resolvers (if needed)..."
echo

cd /usr/share/dnscrypt-proxy/

wget -N "$RESOLVERS_URL"

echo "Restarting dnscrypt-proxy..."
echo

/etc/init.d/dnscrypt-proxy restart

echo "Done"
echo

The "wget -N" command will only download and upgrade the file if it has changed.

Hope that helps some of y'all.  I'm also working on having the dnscrypt-proxy-resolvers package updated, but even once it is, this file changes as much as a few times a week.  Obviously the package can't be upgraded that often.

(Last edited by starcms on 30 May 2017, 14:29)

Great catch.... Yes, it was requested to implement the full version of wpad, and hence removed wpad mini.

@waleed.soliman

If you want to investigate this... try removing the full version, and install wpad mini, and see if the problem persists.

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...

(Last edited by aqwserf on 30 May 2017, 19:30)

Great idea! Works like charm! Thanks dude

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

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.

Looks promising

If you are going to get the entropy warning, it will only occur on boot if you are using a DNSSEC resolver.  Or at least that's what it seems to be from what others have commented combined with my own experience.  So, if you are using a resolver that supports DNSSEC (d0wn-it-ns1) does, reboot, and check if you see the entropy warnings in the log.  I'm 99.9% positive you will.  You won't get the warnings simply by switching to a resolver that supports DNSSEC and restarting dnscrypt-proxy because a couple minutes after boot, the entropy pool reaches a very healthy level and maintains it.  The entropy level would have dropped slightly when you changed to a resolver that supports DNSSEC and restarted dnscrypt-proxy, but not to a level below 1000 to trigger the warning.

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.  This will get you an entropy of around 2000 on boot, eliminating the warning messages, and allow dnscrypt to load on it's first try.  Then, the entropy will still rise normally using the default methods to around 3400 after a couple minutes (actually it maintains a constant level of 3413 for me, regardless if you have haveged installed or not.  Of course if you do something that requires entropy, such as generating a encrypted key using openssh, it will drop some for a minute or so.  But because it maintains such a very healthy level of 3413, I can't imagine it dropping below 1000 under any circumstance).  Haveged simply puts more entropy into the pool on boot before the kernel can get entropy from it's regular sources (I believe the kernel draws entropy from the wifi driver, amongst other things).

You can easily observe the entropy level at any time by running the command:

cat /proc/sys/kernel/random/entropy_avail

I had never noticed this before, because up until a week or two ago, I had been using 'cisco' as my resolver, which doesn't support DNSSEC.  Apparently DNSSEC makes dnscrypt require more entropy to generate the additional encryption keys needed.

(Last edited by starcms on 31 May 2017, 05:56)