A wifi network does not work on my laptop but works on all other devices.
It connects but is unable to use it (even ping does not work).
It works fine with other wifi networks.
I tried enabling ipv6 but nothing changed.
How should i start troubleshooting?
Also this card uses rtl8723de for which I had to set up dkms manually.
Assuming that you’re using NetworkManager, watch the journal logging in a terminal while trying to connect…
sudo journalctl -fu NetworkManager
Dec 31 14:18:34 orpheus NetworkManager[1354]: You can find my version in /etc/resolv.conf.netconfig ...
Dec 31 14:18:34 orpheus NetworkManager[1354]: nisdomainname: you must be root to change the domain name
Dec 31 14:18:34 orpheus NetworkManager[1354]: <warn> [1546246114.1986] dns-mgr: could not commit DNS changes: Error calling netconfig: exited with status 20
Dec 31 14:18:34 orpheus NetworkManager[1354]: <info> [1546246114.1998] policy: set 'Hotspot1' (wlp2s0) as default for IPv4 routing and DNS
Dec 31 14:18:34 orpheus NetworkManager[1354]: <info> [1546246114.2085] audit: op="statistics" arg="refresh-rate-ms" pid=2233 uid=1000 result="success"
Dec 31 14:18:34 orpheus NetworkManager[1354]: <info> [1546246114.2216] audit: op="statistics" arg="refresh-rate-ms" pid=2233 uid=1000 result="success"
Dec 31 14:18:34 orpheus NetworkManager[1354]: <info> [1546246114.2737] audit: op="statistics" arg="refresh-rate-ms" pid=2233 uid=1000 result="success"
Dec 31 14:18:34 orpheus NetworkManager[1354]: <info> [1546246114.3426] audit: op="statistics" arg="refresh-rate-ms" pid=2233 uid=1000 result="success"
Dec 31 14:18:34 orpheus NetworkManager[1354]: <info> [1546246114.4028] audit: op="statistics" arg="refresh-rate-ms" pid=2233 uid=1000 result="success"
Dec 31 14:18:35 orpheus NetworkManager[1354]: <info> [1546246115.9496] audit: op="statistics" arg="refresh-rate-ms" pid=2233 uid=1000 result="success"
Ping by ip does work sometimes, ping by website address is too slow and does not work.
Ping by ip does work sometimes, ping by website address is too slow and does not work.
I’m not sure what you’re trying to convey with that log snippet, and your vague comments above suggest that you do have internet connectivity. Can you resolve internet host names at all?
Show us
grep name /etc/resolv.conf
If it really is just slow resolving, you may be able explicitly configure the DNS to servers which have better performance perhaps.
nameserver 8.8.8.8
nameserver 8.8.4.4
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=4 ttl=122 time=101 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=122 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=122 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=122 time=12.2 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=122 time=12.9 ms
^C
--- 8.8.8.8 ping statistics ---
8 packets transmitted, 5 received, 37.5% packet loss, time 69ms
rtt min/avg/max/mdev = 12.212/30.078/100.600/35.261 ms
ping www.google.com (no output for a long time)
^C
again ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
11 packets transmitted, 0 received, 100% packet loss, time 248ms
Is your router or service provider blocking Google DNS perhaps?
What happens if you force a DNS update using the following?
sudo netconfig -f update
grep name /etc/resolv.conf
I assume this will now report/use the DHCP-assigned name server(s)?
Can you then resolve by host name?
BTW, I note that your ping responses report significant packet loss…
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=4 ttl=122 time=101 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=122 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=122 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=122 time=12.2 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=122 time=12.9 ms
^C
--- 8.8.8.8 ping statistics ---
8 packets transmitted, 5 received, 37.5% packet loss, time 69ms
rtt min/avg/max/mdev = 12.212/30.078/100.600/35.261 ms
You’ll need to investigate this issue, as it will have a huge impact with network services you try to use.
Most common solution which should be tried before anything else is to reboot your router. If you have physical access but not login credentials, simply pulling the power, waiting 30 seconds and then re-connecting power will recycle successfully.
TSUc
Yes, that’s worth a shot as well.
after the netconfig update:
nameserver 192.168.100.1
nameserver fe80::1%wlp2s0
nothing changed
I tried restarting the modem as told, but same result
I used an external wifi card and it also failed on this same network.
I have tumbleweed installed on another pc too and it works fine with this network.
It is using google dns.
It’s certainly a strange issue being encountered here. You mention that the problem is only experienced with this network, and with this one TW machine right? It does make we wonder if your router is blocking this particular host…are you the administrator of the network/router?
What is reported by the following command from this host?
nmap -sU -p53 -A 192.168.100.1
Reading back through this thread, I note that you have not followed up on my comment (post #8) about the packet loss that’s being encountered. That will cause problems of course. Weak signal level or interference issues perhaps?
/usr/sbin/iwconfig wlan0
Starting Nmap 7.70 ( https://nmap.org ) at 2019-01-01 16:46 IST
Nmap scan report for 192.168.100.1
Host is up (0.00018s latency).
PORT STATE SERVICE VERSION
53/udp open domain dnsmasq 2.80
| dns-nsid:
|_ bind.version: dnsmasq-2.80
Too many fingerprints match this host to give specific OS details
Network Distance: 0 hops
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.04 seconds
On this device there is no wlan0 but there is wlp2s0
sudo iwconfig wlp2s0
wlp2s0 IEEE 802.11bgn ESSID:"Hotspot1" Nickname:"<WIFI@REALTEK>"
Mode:Managed Frequency:2.412 GHz Access Point: 10:C1:72:B0:D0:38
Bit Rate:72.2 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Encryption key:****-****-****-****-****-****-****-**** Security mode:open
Power Management:off
Link Quality=100/100 Signal level=40/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
I can control the router, It was recently installed.
The iwconfig output shows that you’re connecting to a Huawei device (deduced from MAC address). Is this a 4G router that you’ve set up as a hotspot? I’m wondering if that is impacting here somehow.
Starting Nmap 7.70 ( https://nmap.org ) at 2019-01-01 16:46 IST
Nmap scan report for 192.168.100.1
Host is up (0.00018s latency).
PORT STATE SERVICE VERSION
53/udp open domain dnsmasq 2.80
| dns-nsid:
|_ bind.version: dnsmasq-2.80
Too many fingerprints match this host to give specific OS details
Network Distance: 0 hops
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.04 seconds
I was a bit surprised by the “0 hops” output. I would expect this to be “1 hop” given that the host and router are one hop away from each other (but I might be misinterpreting that perhaps).
What does the following show?
/usr/sbin/traceroute 8.8.8.8
/usr/sbin/traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 * * *
2 124.253.28.1 (124.253.28.1) 6.839 ms 6.823 ms 7.306 ms
3 202.164.51.225 (202.164.51.225) 6.652 ms 7.130 ms 7.066 ms
4 202.164.51.35 (202.164.51.35) 7.015 ms 7.498 ms 8.752 ms
5 72.14.213.36 (72.14.213.36) 14.131 ms 14.104 ms 14.055 ms
6 108.170.251.113 (108.170.251.113) 15.039 ms 12.638 ms 12.565 ms
7 108.170.228.183 (108.170.228.183) 12.510 ms 74.125.37.137 (74.125.37.137) 13.966 ms 74.125.37.149 (74.125.37.149) 13.853 ms
8 google-public-dns-a.google.com (8.8.8.8) 12.742 ms 13.663 ms 13.425 ms
It is a regular fibreoptic connection.
FWIW, a reddit discussion that mentions the same error
dns-mgr: could not commit DNS changes: Error calling netconfig: exited with status 20
that you reported in post #3, which is why I later recommended using
netconfig update -f
to force an update of the assigned name servers. You could try deleting /etc/resolv.conf, and then run that command again.
Hopefully, others who can help might have further ideas about why name resolution is failing for this particular connection.
Some network troubleshooting basics…
A fast, low latency experience is based on a fully working IP based networking, and on top of that a name resolution system… The two systems can be considered completely separate, each with its own possible issues and so need to be investigated separately.
Since name resolution is built on top of IP based networking, you need to establish no issues with your IP networking first. Your initial post and subsequent posts aren’t entirely clear that you’ve done your work completely on this first. Your traceroute post by IP address is important, and IMO your result while not exceedingly fast is within an acceptable window (no more than about 10-15ms latency). That result also shows that congestion didn’t happen until deeper towards the Internet which is beyond your ability to control and is your ISP’s problem. You need to run similar tests at least 3 times at various times of the day to see if your results vary, and to the Internet sites you connect to… Depending on where in the world you are and what you’re connecting to, your connection may be passing through congested networks at various times of the day. Save your results so you can build a profile what is happening and possibly present to your ISP as evidence they need to make changes… Your ISP has control not only of their own routers but also what gateways they use to connect to the Internet backbone providers and then on to your destinations. And, of course if you present evidence your ISP’s upstream provider itself is causing problems, then your evidence can be passed on to people who can address the problem.
When you have done all you can to address your IP based networking, only then can you then turn your attention to any name resolution issues, and for that you need to have an understanding of how the DNS system works. You can find many fully detailed descriptions around, but I’ll try to provide a brief description of the essentials you need to look at issues.
The first thing to know is that you can perform the identical PING and traceroute tests using names instead of IP addresses, remembering that if you don’t already know the effect of any IP based latencies, you can’t possibly identify any name resolution issues accurately.
You should also know that the DNS system is built on the idea that only one or a very few DNS have the most authoritative (ie original) records for your queries, but in the old days when machines were less powerful, if the world queried these few servers, they would be overwhelmed. So, it’s today possible for anyone (including your ISP) to set up their own DNS server to service their networks or customers but even then no single DNS server can be expected to hold all of the Internet’s addresses. The DNS system allows anyone to connect to any DNS server of their own choice to query for any address, and if the local DNS server doesn’t have that address, then the query is passed upstream to another server, and if that server doesn’t have the answer will pass it upstream again, repeating until the answer is found, and then the answer has to be passed back down the chain until it gets back to you. Unresolved queries don’t get passed upstream instantaneously, there is always a long delay of many, many seconds at each hop, so if the DNS server you’re using is very “remote,” the answer won’t be found and passed back downstream before you have timed out.
If you understand what has been described above, then it becomes clear that your choice of DNS can be important, you want to use either a very busy DNS server(which would probably be surprising to the student) or an “original” server that holds the records you need… And ISP DNS servers can be lacking in both. It used to be forbidden, but with today’s ample bandwidth and powerful hardware,it’s now acceptable to use DNS servers run by Internet giants like Google, IBM, major Internet ISPs, security companies, etc. And, they often have business interests for doing so, everyone that uses their DNS servers provides some information about how the Internet is behaving even if no private information is retained (well, you’d hope so but that’s company and service policy). This is why a troubleshooting solution for many is to use a Google name server (eg 8.8.8.8) instead of your ISP’s DNS.
When troubleshooting name resolution, you should use the “nslookup” utility. Get to know it, it’s extremely useful in a variety of situations, with it you can test and query not only your default name server, you can also temporarily connect to, test connections and query any other name server on the Internet… all without making any changes to your system like editing /etc/resolv.conf or making changes in YaST or Network Manager.
In summary,
Troubleshoot step by step, the order in which you test can be important to isolate and build on top of information already gathered.
The tools you use (eg ping, traceroute, nslookup) and how they’re used are essential to gathering information.
Have confidence you’ll find your answer. If you’ve done a good job collecting relevant information but still aren’t able to analyze what you’re looking at, you can post and others will offer their own analysis.
HTH,
TSU
No time to read all, but try to set it up manually, i.e. provide DNS’s, gateway and then connect?