I was having this issue with chrome as well. What I think fixed it for me was removing my self signed cert config in LuCI uHTTPd tab with firefox and then using the Cookie Autodelete extension for chrome to clear local storage and cookies for the LuCI domain.
Welcome to the forum @kory25! First post I see.
Okay.. the easiest way to tell if this is a false positive is to find a windows machine, and run the following command - ipconfig /all
From the output, of the command, take a look at the line that says "DNS Servers" for either the Ethernet Interface or Wifi Interface if connected by wifi. Need to know the value from that line.
Thanks,
David
Hello @aftershocks
From the Gui, can you grab the Firmware Version please? Also, can you explain what kind of problems?
Also, I'll see if the dev's will be willing to take "lede" off and replace it with "openwrt", but a different issue.
Thanks,
David
I seriously doubt the small changes that have been made to the Wifi Driver since r9028 would make any difference, but you are welcome to try.
As others alluded to on the dd-wrt forum, there are IOT devices that just refuse to connect. I have heard disabling WMM was a work around, but appears you have already tried it and it didn't work.
My recommendation, for people having Wifi issues, has been to buy a separate Wifi Access Point, and just use OpenWrt as a router.
Also, if you do get 5Ghz working, I recommend staying off the DFS channels as they have been known to cause issues. Sticking with channels 36 or 161 has been very solid.
I had a great deal of difficulty getting some "dumb" IoT style devices to connect to my WRT32X running this build. Specifically: they would get stuck in DHCPDISCOVER/DHCPOFFER loop, never doing a REQ/ACK. All of my Amazon kit (Echos and Dots) and a couple of Logitech Harmony Hubs did this.
The solution was to ensure "Allow legacy 802.11b rates" was ticked/enabled in the Advanced Settings pane of my 2.4GHz radio. I have no idea why this would fix it and I've discussed it at length with some very knowledgeable wifi professionals. So it may be worth a try.
I also found that some Amazon kit (Kindle Fire and Echo, specifically, maybe others) advertise that they have 5GHz 802.11AC capability but they will only connect to the ch36.
This is a similar case with the Amazon FireTV as it will not connect to any DFS channels (5Ghz). I can select a DFS channel, and the FireTV can see the SSID, but trying connecting it gets stuck in a loop. Eventually, it does give up after about 60 seconds but never actually receives an IP address whilst looping. So, I just keep it on one of the Non DFS Channels, and it works just fine.
Thank, it work ok if I remove my self signed certificate but I must find the reason why it's only Chrome that is giving me this error.
Thanks for that. I had a quick scan through the thread and can confirm that using static IP assignments (properly static, set on the client, not just in dhcpd) didn't solve it for me. Even though the clients would connect they still dropped off the network regularly (obvservable as radio streams on my Amazon Echo never playing for more than 10 minutes).
My aforementioned fix, allowing legacy 802.11b rates, seemed to resolve the issue. I've no idea why, though, as the devices all connect at relatively high phy rates
dns-crypt proxy v1 stopped working for me today. I'm connected to my two DNS servers but i couldn't resolve any websites. Happend 3 times allready and I had to restore the dhcp/dns config to default and set up dns crypt proxy again to get it working normaly...
Any ideas?
Hi @davidc502
Sure thing, here it is...
Firmware Version
Lede SNAPSHOT r9287-7ebbbda293 / LuCI Master (git-19.038.66435-4e5111e)
I'm expericing random wifi disconnects... Happends about 1 to 3 times in a day.. It takes about 20 - 30 second for wifi to come back online. At the time of the disconnect, all devices connected to the LEDE drops wifi signal...
Is this just on 5ghz? If so check if you are on 80mhz, this is usually what causes this for me.
Thanks for the reply! I ended up enabling option 6 anyways. It wasn't until I unselected the "Use DNS servers advertised by peer" option in advanced settings for the WAN interface that my dns leak test were finally working. Thanks for all of your work on this firmware! Next up is getting Wireguard up and running
What is being described sounds like how DFS channels work on 5Ghz.
Please set the 5Ghz channel to either 36 or 161 and not on auto. Using auto will cruse the DFS channels and every time radar is detected will drop all wifi connected devices for 30-60 seconds whilst it joins another channel.
Best Regards,
David
Hey @Kherby
It has been a while since I used v1, but do recall folks talking about dns disconnects. It seemed to be one of the frustrations with v1 and v2 was supposed to help clear those types of problems up.
If you can do it, I highly recommend going to v2. v2 is faster, load balanced, and is rock solid stable. If you are low on space, v2 has a compressed binary that works great too that doesn't use much... just a thought.
It was set on 20Mhz... I just want to make sure it's not the firmware that is at fault but rather my settings that is causing this... I guess you had the same symptons too but was able to rectify it... Thank you!
Hi @davidc502... Yeah, I had it on 161.. I'll try 36 now... It wasn't set to auto... I'll give it a shot and let you know... As for the width, any recommendation?
The log will say "Radar Detected" if it decides Radar was detected and must vacate the channel.
If you had it set to 161 then that isn't a DFS channel, and you shouldn't have any drops.
80Mhz width should be find for channel 36 and 161. Try 40Mhz as well.
Check channel 36, but when you get the drop, please check both the system and kernel logs to see what might be happening. This may be a new but case that needs to be reported.
Hey David,
when will you be moving over to DNS-Crypt proxy V2 as stock instead of v1, at present installing new firmware means we have to then manually update to dns-crypt proxy v2.
you said yourself it's stable, load balanced and faster...