Thank you folks, for wanting to continue this discussion ! By the way I tried nslookup www.google.com as someone suggested on the Unix Stackexchange, and it times out BOTH on Linux as well as Windows. This could be a clue. The outputs are instantaneous, then a long wait, then the timeout message.
Non-authoritative answer:
Name: www.google.com
Address: 142.250.192.132
;; connection timed out; no servers could be reached
[ramkumarr@RR-W520 ~]$
Not yet. I assumed ping -4 would do the needful.
Yes it is lookup related for sure, because apps like Thunderbird show âLooking up xxxxxâ in the status bar for a long time. And ping with an ip address is always instantaneous. Not sure I understand the âDNS Castingâ bit
You wrote the key event in the initial post of the topic.
The answer is no investigate it: to monitor network traffic from and to the PC near that 20s delay, which realizes what protocol, port, destination host combination used to finally resolve hostnames.
Update - this problem is now solved. Thanks to all the learning from the incredibly useful inputs here and the discussion on the Unix Stackexchange (https://unix.stackexchange.com/questions/669319/ping-from-linux-distros-20s-ping-from-windows-android-instant-why) I was able to take it up with the ISP and have my router changed. The issue appears to be related to how the firmware of my router at 192.168.9.1 was handling DNS requests made to 192.168.9.1. Once Windows got the DNS addresses it appears it would cache it in the DNS Resolver Cache (I believe) and therefore there was apparently no problem with Windows. However it appears that Linux does not do OS level DNS caching as described here https://stackoverflow.com/questions/11020027/dns-caching-in-linux and therefore each ping request would, because it treated 192.168.9.1 as the DNS server, cause the router to exhibit that 20s hang. Specifying DNS servers in the Linux client in the wifi config/IPv4 tab using âMethod= Automatic(Addresses only)â would circumvent the problem by bypassing the use of 192.168.9.1 as the DNS. Change of router to a Nokia-branded one solved the problem.
Absolutely - letâs compare it with Windoze âfast startâ which is just hibernation in disguise, a piece of sheer deceit, and causes more harm than good.
Happy that you solved the problem. But I have to admit that some things donât add up.
But you made some tests requesting directly from your router (post #13 for example) and you got good response times. Was the problem just random or how can be that explained?
You are right. The DNS lookup itself was instantaneous. I reworded the Solution so that it merely indicates a problem âsomewhere in the firmware area of router if 192.168.9.1 was used as the DNS serverâ. I donât think there is enough info to get more specific than that.
I am also Glad to know that you solved the issue.
But I think reboot of Windows clears itâs DNS cache and you wrote:
So the cause of problem is still unknown as the old router hardware (or itâs firmware, as you mentioned has no problems w/ Windows), so Windows has no delays even with clean DNS cache
OR
you prefer to hibernate always instead of one-two weeks reboot? If to hibernate only, how are you got rolling and constant Windows updates came into work if no to reboot?
So or problem cause is still unknown or unusual Windows usage (long time w/o reboot to get installed updates into work).
If the issue caused by router HW or FW problem, than Windows after restart should also have that hostnames resolve delays before to push new items into its DNS cache (which got cleared by reboot).
PS May be I have obsolete/wrong data that Windows reboot clears its DNS cache. Also, DNS cache have expire time, it is not cached hostnames for forever and usually can be from several tens of minutes to several hours, so after that expired time hostname resolve retries should come into play again even on Windows, but Windows somehow got instant resolve.
