DNS breaks under load(?)

[terracottalite]

My internet breaks when I am using it heavily (like emerge updates).

But, only external domains break. 192.168.1.1 pings fine, and so does 8.8.8.8 (or any ip).

I can work around it by running

[szatox]

[terracottalite]

[szatox]

Systemd or no systemd, what I said about dns and network congestion stands. Seriously, give dnsmasq a shot. The scenario you described is exactly where local dns cache really shines.

20dBm is a much more common and much more reasonable 100mW, though I've had people point me to anecdotal evidence suggesting that 2.4GHz can have adverse effects at even lower power level, unfortunately I couldn't find enough research to satisfy my curiosity. This, however, is OT.

[terracottalite]

Sorry for being late, but this solution didn't work.

I finished my long delayed system update yesterday (5 days ago) and had the chance to install dnsmasq. Using dnsmasq, my internet still breaks and I have to run wpa_cli reconfigure (I actually have a cron job for that).

I didn't have this problem with Arch or Void Linux and I still don't know what is happening.

It probably it is a misconfigured USE flag or a faulty kernel configuration seeing the problem is only on Gentoo.

Thanks for everything. I will check my USE flags... Maybe iwd will be better than wpa_supplicant.

[deagol]

I don't have a good candidate what could be wrong here. It looks odd and I assume we are not looking at the real issue, yet.
But I don't think that your wireless connection is responsible here. Reconnecting probably just kicks off some other job which fixes whatever went wrong.
wpa_supplicant or iwd are next to be sure not responsible: If something would be wrong here, it also should not work when using IPs instead of names.

I would look at that with dig first to isolate the problematic area:
When it's broken, use dig to resolve names and try different DNS servers, e.g.:

• dig @9.9.9.9 www.google.de
• dig +trace www.google.de
• dig @127.0.0.1 www.google.de (or whatever you have in /etc/resolve.conf instead 127.0.0.1)

This basically bypasses the system DNS resolution and directly queries the IP after the @. Or with the +trace option like a DNS resolver.
The output may be a bit challenging when you don't have a some DNS background, though. You can add +short to the commands with @ to get a really minimal feedback. But the more verbose the better, in my opinion!
(nslookup can be used instead. But dig has more options and is much easier to use when you need those...)

I expect the first and second dig to be working and something be broken with the system DNS resolution. (The last dig may or may not work in that case) If *none* of them are working thinks get interesting:
In that case, verify if they work without the problem. If these commands indeed only fail during the issue something is really off:
Wpa is not caring if a packet uses icmp, udp or tcp. The only special case is multicast/broadcast and that also only from the router to the clients. Clients to router is again handled like all other unicast traffic.

[terracottalite]

OK, so something is seriously wrong?

[terracottalite]

OK, turns out the problem isn't with just DNS.

When the internet is down: I can ping 142.250.74.142 (Google's IP at the time of writing). But when I try to connect to the website using Firefox or do anything like that it fails.