Okay, keep calm. Let's see what is going on.
You have probably seen this graph before:
You might know all about it, or not understand anything about it. Either is fine. The only thing you need to understand is that when you're connecting to the internet, you're peeling an onion: it has layers.
Before doing anything, ask yourself this: When was the last time it worked? What has changed since? This applies to anything related to computers. Stuff doesn't magically stop working out of the blue.
If you can't immediately think of what has changed since last time, it's time to navigate the stack. Let's summarise what each level of the stack is:
- Physical Layer: Where the little lemmings walk or fly to reach their destination.
- In most cases, this is the Ethernet cable, or the air in the case of Wi-Fi or Bluetooth.
- It could also be an HDMI cable, satellite, or a USB... but that's out of the scope for this.
- Data Link Layer: The discovery of devices on the other side of the cable/air.
- MAC addresses uniquely identify a hardware device.
- Network Layer: The devices knowing how to reach each other.
- Think of an IP address as a virtual GPS coordinate. For each device, reaching a coordinate is as easy as following the map!
- Transport Layer: Connecting devices
- Ultimately, if devices are connected, your network works. The rest is up to applications to implement.
Fine.
If you're like me, you have more than one device in your home.
-
Can any other device in your home connect to the internet?
- Did you change any settings on the router? The Wi-Fi password, perhaps?
- No? Restart your router.
- Verify that your router is connected to the RJ11 or fiber socket.
- Still nothing? Wait 30 minutes.
- Still nothing? Reset router to factory settings.
- Still nothing? Call your Internet Service Provider
-
Okay, so the problem is inbound, not router-related.
- Is there a physical connection between the router and your device?
- Using an Ethernet cable is more reliable.
- Make sure the cable hasn't been bitten by a cat, or crushed by a door. Yes, this happens.
- If using Wi-Fi, check if there are any interfering channels in the neighbourhood.
- You want to be as far away as any other frequency channels.
- I use PingTools Pro on my phone for this.
- Using an Ethernet cable is more reliable.
- Is there a physical connection between the router and your device?
Check if you have an IP address.
-
On Windows, use
ipconfig
. Good luck. -
On Linux, run
ip -c addr
in a terminal- You should see some interfaces. Interfaces are essentially network devices.
- Ignore the
lo
device. wlp
andwlan
are Wi-Fi devices.eth
andenp
are Ethernet cable devices.
- Ignore the
- Look for
inet
, andinet6
under the device you're debugging.
- You should see some interfaces. Interfaces are essentially network devices.
-
If you don't see your interface, see if appears under
ip -c link
.- If it appears now, that's weird. There seems to be a problem with setting up the IP protocol itself.
- If it doesn't appear, let's see if its drivers are running:
lspci -vvv | awk '/Ethernet|Network/,/^$/'
for PCI devices.- Expect to see something like "Kernel driver in use: somedriver"
- If the device appears, but no driver is in use, figure out which driver you need for your specific hardware.
- If the device doesn't appear, good luck. This means the kernel is not recognising your hardware as a network device.
- Expect to see something like "Kernel driver in use: somedriver"
lsusb
exists for USB devices
If you have a driver loaded, make sure you have a network manager loaded. There exist a multitude of these, depending on distributions. In general, though, you probably want to use NetworkManager. Make sure it's loaded.
- On systemd distributions,
sudo systemctl enable --now NetworkManager.service
. - On OpenRC distributions,
sudo rc-update add NetworkManager default && sudo openrc
- If you're using OpenRC, you should probably be reading the Gentoo wiki anyway.
netifrc
is the default network manager on this distribution.
- If you're using OpenRC, you should probably be reading the Gentoo wiki anyway.
Most network managers will automatically assign IP addresses by using the DHCP protocol (in other words, asking the router for the proper configuration), but it's often better to use static configuration if you know what you're doing, and your requirements don't involve a lot of changes in the network.
If you need to use automatic IP assignment, make sure a DHCP daemon is running, On systemd systems, you probably want to do as follows:
sudo systemctl enable --now systemd-dhcpd.service
Note: You don't reaaaaally need a network manager, but it just makes stuff easier/automatic.
Nice! Let's try pinging some stuff:
-
First ping yourself. That's the IP address you saw with
ip -c addr
.- If it doesn't work, try pinging
127.0.0.1
. If this doesn't work, good luck.
- If it doesn't work, try pinging
-
Let's ping your router.
-
If there's no response, make sure the IP is in the proper IP pool as defined by your router.
- Also, make sure your router responds to inbound ping requests.
- You could use your phone for this.
- Again, I use PingTools Pro for this, and sometimes Termux.
- Also, make sure your router responds to inbound ping requests.
-
If you're in the wrong IP pool, did you assign a wrong static IP address on your machine? Fix it.
- If you didn't, try using a static IP. Fix DHCP later.
-
If your router can see your machine, and you have a valid IP address, pings should work. If it doesn't, good luck.
-
-
Let's ping
1.1.1.1
. This is an IP address provided by CloudFlare, and is almost always available. This makes it good for testing connectivity.- If it doesn't work, make sure you're routing non-local IP addresses properly.
ip -c route
should have a default entry. This will often look like this:default via 192.168.1.1 dev eth0 metric 1
- Default just means "if there is no other rule", the address after "via" is the router's IP, the device is the interface we look at above, and metric is the priority. Lower metric means more important.
- You can create a route as following:
ip route add default via 192.168.1.1 dev eth0
- If it doesn't work, make sure you're routing non-local IP addresses properly.
-
Let's ping
gentoo.org
-
If this doesn't work, but the previous step worked, your Domain Name Resolution (aka the thing which translates names into ip addresses---remember, that's like virtual coordinates---) is broken.
- On systemd distributions, you have
systemd-resolved.service
. Make sure it's running.sudo systemctl enable --now systemd-resolved.service
- On systemd distributions, you have
-
That means you've got internet, and your DNS works.
-
If you still have problems, that's likely an application fault.