Networking Issues

[rleasle]

OK, so I got my Pinebook Pro this week, and ran into a strange network configuration issue (with the default Debian OS): I can only access part of the internet ... a couple of the hosts I can't get to are slashdot.org and github.com (!)

I have a hidden (non-broadcast) wifi router with manually configured hosts (no DHCP) so I set up the PBP the same as every other device on my home network (had to create the connection first, the go back and edit the IPV4 setting since I don't use DHCP). I can get to some things (google, youtube, pine64,.org, ... haven't tried alot) but other destinations like github are "Destination Host unreachable" when I ping by name or IP.

When I type "netstat -rn" I see an extra route for 169.254.0.0 I think is associated with "link-local" (IPV6?) Don't know where that's set or how to get rid of it. I removed the entry by hand using the route command, but it didn't fix my problem.

I tried the latest debian build (dated 12/26) from an SD card with the same issues (not surprising). I also tried manjaro from and SD card, and things worked fine from there. No difference in how I set up the network, but the routing table was correct  and I seemed to be able to ping or connect to all of the hosts I tried.

Anybody have any thoughts, ideas, or suggestions?

[rleasle]

Well, that was fun. Turns out that the DHCP client took precedence  over the default gateway for my home network. Once I disabled that, everything came up correctly. I guess I'm the only one here stubborn enough to use static IPs?

[a0kami]

Well, that was fun. Turns out that the DHCP client took precedence  over the default gateway for my home network. Once I disabled that, everything came up correctly. I guess I'm the only one here stubborn enough to use static IPs?

I'm not sure I understand how fixed but I'm having the exact same host not resolving issue over wifi.

I connect to a shitty wifi extender and I've had a friend having issues as well (he was using x86 though). :/
Anyway in the meantime I borrowed a usb-to-ethernet adapter, but may I kindly ask you could fill me in on what exactly is the issue and how to troubleshoot ?

[rleasle]

Well, that was fun. Turns out that the DHCP client took precedence  over the default gateway for my home network. Once I disabled that, everything came up correctly. I guess I'm the only one here stubborn enough to use static IPs?

I'm not sure I understand how fixed but I'm having the exact same host not resolving issue over wifi.

I connect to a shitty wifi extender and I've had a friend having issues as well (he was using x86 though). :/
Anyway in the meantime I borrowed a usb-to-ethernet adapter, but may I kindly ask you could fill me in on what exactly is the issue and how to troubleshoot ?

TL;DR - It's probably a configuration issue. Check Network Manager for your wifi setup, try the 'ping' command to test DNS and routing.

It's not about the connection (unless you have the wrong wifi password or security settings), it's about how networking is configured. So DNS (name server) and default routing. Not sure how much you know about networking (not sure how much I know). If it's a DNS problem, you can get to a remote host by IP address, but not by name. When I was having my problem, I used the command

  

Code:

$ ping github.com

and the system would try the correct IP address. So DNS was working (the ping didn't work because of routing issues). If DNS was messed up, it would have told me "name or service not known". Even with DNS messed up, if the routing is correct, you can ping the IP directly

Code:

$ ping 192.30.255.112

You can look at or change the DNS settings from the Network Manager. It should also show up in the file /etc/resolv.conf

For the routing issue I had, I used the route command:

Code:

$ route -n

Destination    Gateway        Genmask        Flags    Metric    Ref Use    Iface
0.0.0.0        0.0.0.0        0.0.0.0        U    302    0   0    wlan0
169.254.0.0    0.0.0.0        255.255.0.0    U    302    0   0    wlan0

The above output was what it looked like when I was having my problems. That netmask value (255.255.0.0) was only allowing me to access part of the internet.


You can also check the configuration that Network Manager set up from the command line (here, I've X-ed out my actual values):

Code:

$ sudo ifconfig wan0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet xx.xx.xx.xx  netmask 255.255.255.0  broadcast xx.xx.xx.255
        inet6 xxxx::xxxx:xxxx:xxxx:xxxx  prefixlen 64  scopeid 0x20<link>
        ether xx:xx:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 253663  bytes 334990443 (319.4 MiB)
        RX errors 0  dropped 57  overruns 0  frame 0
        TX packets 135146  bytes 13434493 (12.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

If the interface doesn't say UP, you're not actually connected.

Hope something here helps.

[a0kami]

It was indeed a DNS issue, I should have looked into that directly, sorry for being dumb.
It set some custom open DNS I know the secret of.

Anyway thank you so much for all those detailed information, it really is helpful!
(Yet my wifi adapter properties are overly more complicated than I think they should have.)

Code:

# I've heard ifconfig was deprecated in favor of ip (but it's the equivalent)
ao@Debian-Desktop:~$ ip addr show dev wlan0
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   link/ether c0:84:7d:2f:82:d2 brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.163/24 brd 192.168.1.255 scope global dynamic wlan0
      valid_lft 84951sec preferred_lft 84951sec
   inet 192.168.1.162/24 brd 192.168.1.255 scope global secondary wlan0
      valid_lft forever preferred_lft forever
   inet6 2a00:23c7:c784:3700:77a9:f5b3:7d8c:1f05/64 scope global noprefixroute dynamic
      valid_lft 315359657sec preferred_lft 315359657sec
   inet6 fdaa:bbcc:ddee:0:67eb:98ea:9b3f:447c/64 scope global noprefixroute
      valid_lft forever preferred_lft forever
   inet6 2a00:23c7:c784:3700:7556:e6bc:6f25:ebdf/64 scope global mngtmpaddr noprefixroute dynamic
      valid_lft 315359339sec preferred_lft 315359339sec
   inet6 fdaa:bbcc:ddee:0:886a:e9e7:7c46:95bf/64 scope global mngtmpaddr noprefixroute
      valid_lft forever preferred_lft forever
   inet6 fe80::d512:e41e:3e0b:bc6d/64 scope link
      valid_lft forever preferred_lft forever

[gandlers]

For the routing issue I had, I used the route command:

Code:

$ route -n

Destination    Gateway        Genmask        Flags    Metric    Ref Use    Iface
0.0.0.0        0.0.0.0        0.0.0.0        U    302    0   0    wlan0
169.254.0.0    0.0.0.0        255.255.0.0    U    302    0   0    wlan0

The above output was what it looked like when I was having my problems. That netmask value (255.255.0.0) was only allowing me to access part of the internet.

Two alarm bells from the routing table alone are that there is no gateway address for the default route and the local subnet "looks suspect":

The gateway for the destination 0.0.0.0 should be the IP address of your router adn definately not 0.0.0.0 , eg 192.168.1.1 and there should also the G flag should be set as it is the gateway route.

The second entry in the routing table is the subnet for the local LAN, this is a 169.254.x.x address which part of the APIPA Subnet which clients can fall back to if DHCP registration fails. 
You should see your local IP subnet with the correct mask eg 192.168.1.0 255.255.255.0

If the local subnet route was correct but the gateway wasn't, the client will still be be able to talk to local devices but nothing on the internet.

[rleasle]

For the routing issue I had, I used the route command:

Code:

$ route -n

Destination    Gateway        Genmask        Flags    Metric    Ref Use    Iface
0.0.0.0        0.0.0.0        0.0.0.0        U    302    0   0    wlan0
169.254.0.0    0.0.0.0        255.255.0.0    U    302    0   0    wlan0

The above output was what it looked like when I was having my problems. That netmask value (255.255.0.0) was only allowing me to access part of the internet.

Two alarm bells from the routing table alone are that there is no gateway address for the default route and the local subnet "looks suspect":

The gateway for the destination 0.0.0.0 should be the IP address of your router adn definately not 0.0.0.0 , eg 192.168.1.1 and there should also the G flag should be set as it is the gateway route.

The second entry in the routing table is the subnet for the local LAN, this is a 169.254.x.x address which part of the APIPA Subnet which clients can fall back to if DHCP registration fails. 
You should see your local IP subnet with the correct mask eg 192.168.1.0 255.255.255.0

If the local subnet route was correct but the gateway wasn't, the client will still be be able to talk to local devices but nothing on the internet.

Yes indeed, this was a messed up route table. It's what the system did "for me" before I could define my static IP and gateway. Unfortunately, it still tried to keep that subnet. I had to disable the DHCP client service to keep a clean, correct route table after reboot. Helps to have a working route table from another machine for comparison.