@David. I've tested the last two releases of your Lede build in my 1900ACv1 but I'm having some problems with DNS.

DNS assigned by provider doesn't seem to be used. In the previous one (r3293) it works fine, but not in the latest. It seems that /tmp/resolv,conf.auto (or /tmp/resolv.conf.ppp, I don't know which one should be used) is ont used at all. If I modify by hand /tmp/resolv.conf the router can get anywhere and download the packages I need, but I think that this should be done automatically. In r3293 it does. And I would prefer DNS servers to be set by my provider, because not only Internet, but IPTV depends on them

"Use DNS servers advertised by peer" checkbox is checked. I tried unchecking it and checking again, but it does nothing.

If you want to take a look on this and I can help, I would be glad to do it.

Regards.

@aluisperezh

Are you still on the latest build? Am I assuming r3716 is correct?

Please list what is in your resolv.conf.auto

root@lede:~# cat /tmp/resolv.conf.auto
# Interface wan
nameserver 8.8.8.8
nameserver 8.8.4.4

Please get a screen shot of the Server Settings > Resolv and Host Files  (Found under DHCP and DNS)

I'm curious if Ignore resolve file is checked or not.

Sorry, no, my daughter had to do an exam online and couldn't take any risk of the router rebooting.

I can tell you that /tmp/resolv.conf.auto was exactly as it is now, because I checked it:

# Interface wan
nameserver 80.58.61.250
nameserver 80.58.61.254

About the "Ignore resolve file", it was not checked (I went there too). But maybe there is some change in behaviour between the build I'm using and latest ones, and it goes wrong because I restore my saved config. Could that be a reason?

I was assuming that flashing over one build would be mostly the same as restoring the configuration, but maybe that's not right...

Regards and thanks for your support.

Lede Testing SNAPSHOT r3901 is available for those who would like to try it out. This would be for kernel 4.9.17

It isn't an official release, but am interested in V1 users who could report back on the reboot issue.

https://davidc502sis.dynamic-dns.net/sn … /r3901.zip

It should behave the same, and since the nameservers haven't changed on the wan interface, the only other thing I can think of is if you checked the ip configuration on the desktop/laptops?

I'm wondering if they were pointing to the gateway OR another dns server?

(Last edited by davidc502 on 2 Apr 2017, 23:36)

@davidc502

Hi David out of curiosity as you mentioned you hadn't had much feedback on the WRT1900ACSv2 have you had any reports of the below that i posted on another forum

"@yuhhaurlin Is it a known issue with the 88W8864 5GHZ driver that devices connected to 5GHZ when the radio is scheduled to turn off do not disconnect and actually stay connected? I have tried stock and DD-WRT firmwares and i have the same issue with all which is obviously due to the driver.

The 2.4GHZ does not have this issue, devices connected to 2.4GHZ when the radio is switched off are disconnected immediately.
@shauno100
shauno100
commented about 6 hours ago
Also doing a wifi analysis from another device shows the 5ghz is still broadcasting when the schedule has meant to turn off the radio.

To replicate

Use a device with 88w8864 chip (im using wrt1900acsv2)
Connect a device to 5ghz band
Set wireless schedule to turn off both 2.4ghz and 5ghz (linksys stock or custom dd wrt script)
When schedule takes affect you will notice the device connected to 5ghz is still connected and using wifi analyzer on other device 5ghz is still broadcasting whilst 2.4ghz is turned off successfully.
As mentioned if a device was connected to 2.4ghz instead the issue does not occur and the device would be disconnected immediately and both 2.4 and 5ghz bands would be turned off."

I have experienced this issue on both stock and DD WRT and im not sure if OpenWRT/LEDE has a wireless scheduler? as im willing to give it a try.

Just seems that due to the fact i experience the issue on both stock and DD WRT that it must be a driver bug.

Any advice would be much appreciated.

Cheers

Shaun

(Last edited by shauno100 on 3 Apr 2017, 06:29)

Well, there was no problem with clients, I mean, any system connected to the network (wired or wireless) works fine. The only problem is in the router. It's strange because I understand that the router is using itself as DNS server. /tmp/resolv.conf only has one nameserver line (127.0.0.1). While clients use the router as nameserver and work fine, the router does not.

I'm not at home now so I can't check it, but perhaps there's some option telling dnsmasq to answer only requests on LAN interface? If there is such option and the default value changed in one of those builds, that could be the reason. My configuration wouldn't overwrite it because it was not set previously... Just wondering, anyway.

Regards.

I can confirm DNS issues with the OpenVPN client and dnsmasq (running r3716 on 1900ACSv2). The provided DNS server by the external OpenVPN server is not put into the resolv.conf.auto. (And I am using the options pull and register_dns in the OpenVPN client config).
I only managed to fix it by running a script upon VPN connect (see

 github.c om/jlund/streisand/wiki/Setting-an-OpenWrt-Based-Router-as-OpenVPN-Client

at step 9).
My guess it is the following issue(s):

dev.openwrt.or g/ticket/20830

bugs.launchpad.n et/ubuntu/+source/network-manager-openvpn/+bug/1169437

feed.cbmland.c om/2016/10/19/resolving-dns-through-openvpn.html

And excuse the spaces in the links, I am not allowed to post any

Hi all and thanks for the work.

I'm using a Linksys WRT1900acs v2 and just tried out david's image davidc502sis.dynamic-dns.net/mvebu/Shelby/lede_Shelby

As far as I can see it works great at the moment. I use it as a wireless bridgerepeater to the main router and as a NAS.

The only thing I'm missing is the kmod-usb3. Is there a posibility to make the USB 3 work, or do I miss something?

Thanks.

@david
Thanks for all of your hard work.
R3901 build is running well on my wrt1900acs v1. No issues so far and do not expect any at this time.
One thing I noticed was taking a period of time when wrt1900acs first starts up before the Luci web interface is responsive.

Thanks for all the feedback.

So far r3901 is rock solid on the ACS v1. One thing I did notice is that my old printer will no longer connect to wifi via 5Ghz. Not a show stopper as this has been coming.

In the last firmware I could not connect to the retracker.local torrent and really have problems with dnsmasq. router wrt1900ac v.1

(Last edited by Armik on 5 Apr 2017, 22:42)

What is the most stable build for the WRT1200AC-V2? I'm am using David's newest build but I still wonder if there's something better out there.

Sorry for a newbi question, but i'm not sure how i can get back on a stock firmware. I flashed my Linksys wrt1200ac v2 with  LEDE ...-factory.img software (lede-17.01.0-r3205-59508e3-mvebu-linksys-wrt1200ac-squashfs-factory.img). Its kernel version 4.4.14. Then I flashed it once again with lede-17.01.0-r3205-59508e3-mvebu-linksys-wrt1200ac-squashfs-sysupgrade.bin to get the latest kernel (4.4.50). It worked fine and I managed to set everything i needed. Then I wanted to try a build from David. In SSH I used the command fw_printenv boot_part. It showed me boot=1. Then I tipped fw_setenv boot_part 2 in order to get back the stock firmware. I rebooted my Linksys and suddenly I got into the   LEDE image (4.4.14). It means now I have two partitions with two different LEDE images, but no stock software. And I'm a bit confused. Does someone know what I shall do in this situation? A little how-to would be nice.

(Last edited by ollifin on 6 Apr 2017, 11:22)

Since the 5 GHz DFS channels are completely unusable with the WRT1900ACS v2, I'm wondering does anybody know if there is working reghack for that router?
I'd really love to use these channels but with DFS they are just not working. I've applied the reghack found here:

forum.lede-project.o rg/t/wrt1900acs-v2-how-to-update-mwlwifi-driver/1491/10

but that only patches the world (00) and US region.
But my router is hardcoded (eeprom I guess) to the FR region.

EDIT: @davidc502
alternatively, would you consider setting the CONFIG_ATH_USER_REGD=y flag to allow users to change the region?

(Last edited by kkowrt on 6 Apr 2017, 14:17)

@kkowrt

Will look for the setting in the next build.

*EDIT*

Just so you know.... It's well known DFS does not work properly, and there is a thread on kaloz's site describing the problem. Is it something being worked on? No idea.

I do know the current wifi driver for the 3200acm, DFS works like it is supposed two, but wonder if that will change with the new driver.

(Last edited by davidc502 on 6 Apr 2017, 14:26)

You need to boot back to the stock firmware, and flash from that partition. Otherwise, if on the other partition running lede, and flash again, it will over-write the first partition with the stock firmware.

At this point, boot to the partition of lede you wish to keep, and then flash OEM using  sysupgrade -F /tmp/image.img

Thanks david, and yes I know about the thread. The problem is that the wifi driver falsely detects radar (even if it's just another 5 GHz wifi) and prohibits the use of the DFS channels.

Using a proper reghack or adding the CONFIG_ATH_USER_REGD=y flag in the image would allow us to remove the DFS restriction and make those channels usable. Also, it should allow us to enable the non-DFS channels above 140 which right now are disabled for some reason.

@davidc502,

You also have my +1 vote to compile with CONFIG_ATH_USER_REGD=y and possibly a modified regdb, to allow users to enable and use the DFS channels, until the driver gets fixed.
Being restricted to just channel 36-48 here in europe, due to failing DFS implementation, makes the 5 Ghz far less usable.

Adri.

I hear you both, and understand exactly because I'm affected by DFS not working. I live in a neighborhood with a lot of wifi, and with people now using 80mhz widths, there's only 2 effective channels on 5Ghz (non DFS USA).

However, having said that, doing anything that may allow users to over-ride DFS restrictions could cause issues.  On top of that, I hold a current FCC radio license, and could lose that license, not including other potentially bad stuff happening to me.

So what's the answer? This all has to go back to the OpenSource driver/firmware which we all use, and Linksys. The testing I've done so far, with DFS, on the 3200acm looks good.  As soon as that driver is solid, I know for a fact I'll be using it instead of the 1900acm.

I can see you're in a difficult position and I'd understand if you rather not change anything.
As a trade-off would you consider just enabling a reghack just for us Euro people (I think most, if not all, of the routers are set to the region FR here)? That way you wouldn't violate the FCC rules.

Considering the driver: are you suggesting that we could use the 3200acm driver for our 1900ac(s) once it's stable?
Or are you saying to get he 3200acm instead of the 1900ac(s). The latter would really be shame as I've just bought it last week (and besides the 5 GHz wifi it's just perfect).

@davidc502

I understand your reluctance to provide options for users to override FCC regulations, especially if you could be affected by loosing your FCC radio license.
Our best hope is probably a backporting of the new 3200acm driver for the older 1x00ac(s) devices.
Hopefully @yurhalin will be able to do so.
I currently have both a wrt1900acs which I use and a wrt3200acm gathering dust, waiting for a usable driver.

@david,@adri
I hope you excuse my off-topic question but since all of you seem to own an 3200acm as well as 1900ac:
Is the the 3200acm worth the upgrade? Any issues besides the wifi ones (albeit they should be fixed shortly, right?)? Since I'm using OpenVPN in client and server mode a cpu upgrade never hurts, I guess (and I still have a one week return window for the 1900acs).

What about replacing wifi cards?

@davidc502

With the WRT1200AC-v2 on the newest build (r3716) the WPA2 password on 2.4ghz cannot be changed without deleting the network altogether and making a new one. The settings will not stick and it will revert back to the previous password upon reboot. This does not apply to the 5ghz radio.