On Tuesday, 28 May 2019 9:31:04 ACST Mark Misulich wrote:
On Mon, 2019-05-27 at 23:52 +0200, Carlos E. R. wrote:
On Mon, 2019-05-27 at 19:52 +0200, Carlos E. R. wrote:
On 27/05/2019 18.36, Mark Misulich wrote: I'd prefer to see the command outputs than your interpretation, then make my own interpretation - please, no offence intended, but if I see
On 27/05/2019 20.42, Mark Misulich wrote: the commands and the output then we are at least four eyes observing, not two ;-) and chances improve.
No problem at all with that. I had been typing the readouts on my laptop onto the email that I sent from my desktop computer, and I was just trying to save some time. I'm copying everything into a document and transferring it via a usb stick from laptop to desktop now. Thanks for addressing the issue directly so I can present it in a format easier for you to understand.
OK, now we're getting somewhere. :)
Perhaps "ip addr ; ip route" would help, then the actual ping outputs.
Using wlan
~> ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: wlan3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 18:5e:0f:3b:92:0f brd ff:ff:ff:ff:ff:ff inet 192.168.1.6/24 brd 192.168.1.255 scope global noprefixroute dynamic wlan3 valid_lft 86364sec preferred_lft 86364sec inet6 fe80::2050:3958:8df1:28b/64 scope link noprefixroute valid_lft forever preferred_lft forever
Cool - so your machine has an IP address in the correct subnet. :)
~> ip route default via 192.168.1.1 dev wlan3 proto dhcp metric 20600 192.168.1.0/24 dev wlan3 proto kernel scope link src 192.168.1.6 metric 600
And it has a default route - your router's internal IP address. :)
~> ping 192.168.1.6 PING 192.168.1.6 (192.168.1.6) 56(84) bytes of data. 64 bytes from 192.168.1.6: icmp_seq=1 ttl=64 time=0.030 ms 64 bytes from 192.168.1.6: icmp_seq=2 ttl=64 time=0.025 ms 64 bytes from 192.168.1.6: icmp_seq=3 ttl=64 time=0.025 ms 64 bytes from 192.168.1.6: icmp_seq=4 ttl=64 time=0.026 ms 64 bytes from 192.168.1.6: icmp_seq=5 ttl=64 time=0.025 ms 64 bytes from 192.168.1.6: icmp_seq=6 ttl=64 time=0.025 ms 64 bytes from 192.168.1.6: icmp_seq=7 ttl=64 time=0.025 ms 64 bytes from 192.168.1.6: icmp_seq=8 ttl=64 time=0.024 ms 64 bytes from 192.168.1.6: icmp_seq=9 ttl=64 time=0.025 ms 64 bytes from 192.168.1.6: icmp_seq=10 ttl=64 time=0.042 ms ...thence continuing on to seq=61 before I quit the ping... 64 bytes from 192.168.1.6: icmp_seq=60 ttl=64 time=0.042 ms 64 bytes from 192.168.1.6: icmp_seq=61 ttl=64 time=0.043 ms ^C --- 192.168.1.6 ping statistics --- 61 packets transmitted, 61 received, 0% packet loss, time 61417ms rtt min/avg/max/mdev = 0.024/0.035/0.056/0.008 ms
You can ping your own machine's IP address, which means the network stack is working OK. Good.
~> ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=2.26 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=2.03 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.34 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.96 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=1.94 ms 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=2.28 ms 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=2.08 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.96 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=2.00 ms 64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=1.92 ms ...thence continuing on to seq=424 before I quit the ping 424 packets transmitted, 424 received, 0% packet loss, time 423617ms rtt min/avg/max/mdev = 1.510/2.013/9.831/0.737 ms
You can ping the router, so Layer 2 connectivity is fine. :)
~> ping 192.168.1.254 PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data. From 192.168.1.6 icmp_seq=1 Destination Host Unreachable From 192.168.1.6 icmp_seq=2 Destination Host Unreachable From 192.168.1.6 icmp_seq=3 Destination Host Unreachable ^C --- 192.168.1.254 ping statistics --- 6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5097ms pipe 4
This IP address does not exist on your local LAN, so you're getting an ICMP Unreachable response from your router, which your machine is then reporting from it's own network address. Expected behaviour. Good.
~> 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=1 ttl=52 time=122 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=26.2 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=26.8 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=52 time=34.0 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=52 time=25.5 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=52 time=27.1 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=52 time=25.7 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=52 time=26.0 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=52 time=25.7 ms 64 bytes from 8.8.8.8: icmp_seq=10 ttl=52 time=26.4 ms ...thence continuing on to seq=101... 64 bytes from 8.8.8.8: icmp_seq=100 ttl=52 time=26.0 ms c64 bytes from 8.8.8.8: icmp_seq=101 ttl=52 time=25.9 ms ^C --- 8.8.8.8 ping statistics --- 101 packets transmitted, 101 received, 0% packet loss, time 100147ms rtt min/avg/max/mdev = 25.140/29.068/122.254/9.909 ms
You can ping outside IP addresses, which means Layer 3 connectivity is good and you're able to route packets to/from the internet. Good.
~> ping www.google.com ping: www.google.com: Name or service not known
So you don't have any DNS servers defined, and your machine does not know how to resolve hostnames to IP addresses. That is what we have to solve now. What DNS servers are other hosts on your LAN using? If you're using DHCP, you should be able to get his information automatically from your router (or whatever is acting as the DHCP server), but you may need to tell Network Manager to get the DNS servers for this connection automatically. Alternatively, you can manually configure DNS servers to override the auto config.
[...]
As expected, your wired ethernet results match those of the wireless connection, so I've cut them out for brevity.
~> egrep -v "^[[:space:]]*$|^#" /etc/resolv.conf nameserver 192.168.1.1
When I ping www.google.com it says Name or service not known
This would point to the name resolution not working. What is the result of this:
egrep -v "^[[:space:]]*$|^#" /etc/resolv.conf
~> egrep -v "^[[:space:]]*$|^#" /etc/resolv.conf nameserver 192.168.1.1
?
Mark
So the machine in question is pointing to the router as its DNS server. Assuming that is the same as the other machines on your LAN that is probably correct. Are either nslookup or dig installed? If so, you can manually set the server used for name lookups by those utilities and test name resolution. For example (screen capture from my machine): user@hostname ~ $ nslookup
server 10.128.1.9 Default server: 10.128.1.9 Address: 10.128.1.9#53 www.google.com Server: 10.128.1.9 Address: 10.128.1.9#53
Non-authoritative answer: Name: www.google.com Address: 216.58.199.68 Name: www.google.com Address: 2404:6800:4006:809::2004
(Use Ctrl+C to exit the nslookup interactive prompt). Or with dig, you would do: dig @192.168.1.1 www.google.com It should return the IP address details. Assuming that works, it is then a matter of figuring out why your machine is not parsing /etc/resolv.conf (may be hinted at in another response) or why it is not getting the dns server address from your router and automatically creating the appropriate file/entry if /etc/resolv.conf is no longer used. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ==============================================================