A little offtopic, but important to mention - if you host any domain name zone using WRT DNS server - check you Bind/Unbound version!
Others - check firewall settings (default is ok, but if you play with DNS filtering before - better disable it now). DNSCrypt users - keep calm and watch the show ^_^.
Details is here - https://dnsflagday.net/
I have sometimes DNS resolv issues on my clients, and I never figured out, why or whats causing it. Shouldnt this actually never happen, because dnsmasq should cache IPs once resolved? Is there a config I have to set, to enable this or to increase to time it wont retry resolving it?
I have set a bit more not default configuration, where all traffic is going through a OpenVPN connection, also the DNS traffic of the router:
iptables -w -A OUTPUT -t mangle -p tcp --dport 53 -j MARK --set-mark 2
iptables -w -A OUTPUT -t mangle -p udp --dport 53 -j MARK --set-mark 2
And I also use a ipset resolver to route specific traffic, for example twitch, not over the VPN:
list server '/twitch.tv/127.0.0.1#53003'
list server '/secure.twitch.tv/127.0.0.1#53003'
list server '/justin.tv/127.0.0.1#53003'
list server '/hls.ttvnw.net/127.0.0.1#53003'
The problem actually happens for example on a client when watching twitch.tv via VLC, and then randomly, the video closes. Looking into the VLC log, it says couldnt resolve host, which it does every 10 seconds or so over and over again because of the m3u8 file. When this happens, I found out, I have maybe a time out for DNS resolv of about 1-2 seconds globally on the laptop, and Chrome shows for example "waiting for cache".
I have tried 1.1.1.1 + 8.8.8.8, which should give a backup if one doenst work or the other, but this doesnt help anything actually. Isnt dnsmasq smart enough to handle this? If one answeres in maybe 100ms try the other, if it doesnt answer, use cache?
Anything else I could try? Maybe go away from dnsmasq? What is the current bleeding edge solution for DNS on this ROM? dnscrypt-proxy2 isnt implemented by default so far, right? I actually had lots of problems in the past with dnscrypt-proxy because then randomly the dnsprocy server had timeouts, even with using 3 backup services running, it never worked properly.
I actually think for the VLC twitch dns issue, it sometimes happen like every 10 minutes or so. Found a comment about that dnsmasq uses a default value of --min-cache-ttl=600. Could this be related?
Hey Guys -
I use a David502c image (kernel 4.14.91) on my Linksys1900ACS and have a quick question, please...
I'm trying to install a package which after extraction requires moving a few of the files into specific paths. The only thing is, I don't have enough free space to do so despite having plenty of free space in /tmp. Is it possible to (easily) reallocate some of the free space between partitions or is there an alternate way to accomplish what I'm trying to do? Full details below...
The package I'm trying to install is the ARM version of Telegraf using the steps at this post. The 1900ACS has plenty of storage - it's the allocation of partitions that seems to be the issue.
When trying to simply download the file in my home path, I get a message that I'm out of free space. I checked the mount points and see the "overlayfs:/overlay" mounted to "/" has "10.99 MB / 12.21 MB" free. It seems all my free space resides in "tmpfs" mounted to "/tmp" with "180.29 MB / 249.47 MB" free. I was able to download and extract the file into "/tmp", but obviously can't move the files to the paths specified in the post.
If you have suggestions if possible to reallocate - or - know another package which can send the same info to InfluxDB, it would be a huge help. So far, it seems the only way to reallocate between partitions is to completely rebuild the image - which I'm hesitant to do as I've never done so before.
Thanks!
I apologize, I don't have a lot of time, so I'll answer quick to one point before I go, and it is about /tmp. You will noticed whatever you put into /tmp doesn't survive a reboot, and that is because /tmp is volatile. Meaning, whatever you put into tmpfs, goes directly into RAM. So, just a heads up there, and I'm guessing that might just answer your question about not having "enough free space despite having plenty in /tmp".
EDIT
What is the size of the package? I'm thinking you should have 38MB free in / unless there are other packages installed besides what is on the base build.
Thumb drive?
Thanks for the reply...
The package is ~50mb but in / I only have 12.21mb total as you can see in my mount points below:
Even if I had 38, it still wouldn't be enough. I wasn't planning on keeping it in /tmp - just extracted it there but found out I had to move extracted files to /usr/bin, /usr/lib, /etc, and a couple other places which I obviously don't have room for.
That's why I didn't know if possible to do one of the following:
Thanks
Seems like the issue is the speed of resolving, it can be both between router and DNS server (most probably) or between you host and router.
You have 2 easy ways to solve it - increase TTL in dnsmasq settings or use other player, which is not resolve DNS for every chunk of video (f.e. PotPlayer).
You can just connect USB/eSATA drive and mount /bin, /usr, /var etc from it at boot time.
You should copy current data from them to drive first.
We discuss this trick some pages above, for the same reason.
@T-Troll Thank you very much for answering. This is really really weird. I dont have this issue actually on my clients which are connected via lan, just on my laptop via wifi (could be pure luck I havent seen it on my lan clients). I have two issues, that when watching twitch.tv over VLC, it randomly collapses at some time mostly after 5-10 minutes, with the error log saying:
main debug: using tls client module "gnutls"
main debug: resolving video-edge-c2b288.fra02.abs.hls.ttvnw.net ...
gnutls debug: TLS handshake: Resource temporarily unavailable, try again.
gnutls debug: TLS handshake: Resource temporarily unavailable, try again.
gnutls debug: TLS handshake: Success.
...
main debug: using tls client module "gnutls"
main debug: resolving video-edge-c2b288.fra02.abs.hls.ttvnw.net ...
gnutls debug: TLS handshake: Resource temporarily unavailable, try again.
gnutls debug: TLS handshake: Success.
...
main error: TLS session handshake timeout
main error: connection error: Resource temporarily unavailable
I actually asked the VLC devs about it, and they were ignorant as usual and moody, saying it isnt a VLC issue and closed the ticket. As I see it, it is badly programmed, of doing a DNS translate every 2-3 seconds for the m3u8 chunks, like you said, over and over again in a loop. Maybe this causes a block for the DNS server for my ip because of "DNS spam"? It also seems, the VLC lookup has a very shot TTL or retry setup, being really picky about it, the tiny little hickup results in the video to force close.
Not sure if it is the TTL setting of dnsmasq, it also happens when using dnscrypt-proxy and set noresolv to 1 for dnsmasq, I just tested it.
It seems to happen more often, when I browse next to VLC with Chrome.
Could the TTL actually be the problem? VLC wants the IP, it gets it for x minutes "too fast", and when the TTL is over, it takes longer then usual and the VLC breaks, because it calculacted the times before "too short"?
@davidc502 Hey David, can you consider adding a couple items to the repo?
I don't see a problem adding this to the repo. Will look into this.
Just did a opkg update and searched. Looks like both are already there.
luci-app-vpnbypass - git-19.025.11637-a0a78ba-4 - Provides Web UI for VPNBypass service.
vpnbypass - 1.3.1-1Thanks @cybrnook - I assume when someone asks they've already searched.
I must have made an error typing it in when I searched; pretty embarrassing regardless though.
No worries... It's like something I would do.
There is no need to switch the tcpdump package (at least from adblock perspective). Adblock should work with both tcpdump package flavours just fine.
Sorry, assumed it was mini that you wanted since that's what your log calls out specially. Not trying to share false info 
No worries, the reporting stuff in adblock is quite new ... I've already refined the log message ...
If you still receive unusual error messages with the standard 'tcpdump' package, please enable debug in adblock and start /etc/init.d/adblock report in CLI and send back the output to me via PM.
Thanks!
Soory for the delay, thank cybrnook for confirming this. No issue here, everything work ok with tcpdump-mini
Hmm... Looks like it's not a DNS issue. Server reply to 503 error instead of next chunk.
Anyway, you can play with "Advanced settings" in "Network - DHCP and DNS" - it have 2 parameters - "Max. concurrent queries" and "Size of DNS query cache". First is about flood, second about caching more. But if increased values didn't change the picture - use other IPTV provider (or even use TorrentTV).
Thanks david for your fast help. My WRT1200Ac is unbelievable stable now. Take a look at my current uptime (maybe i really need to update to fix some security issues 
)
//Edit:
Just did the upgrade and it worked perfectly. First i uploaded the dnscryptv2 script to /root, set the folder to the backup and after the upgrade i executed the script (make sure the script is executable)
