Raspberry Pi does not connect via ethernet or wireless. Remote connection isn't working

Question

Until recently, my Pi 3B was working perfectly fine on VNC using ethernet with my windows 10 laptop. The problem started after I took out my SD card one day I believe. The IP was still showing up on Advanced IP Scanner at that point but remote connection wasn't possible, even after putting in another SSH file in the SD card.

This doesn't appear to be an issue with power. This also doesn't work using raspberrypi.local or [email protected]. I figured the SD card may have been corrupted(Windows says something is wrong wih BOOT:/E but scanning yields no errors and restarts change nothing), so I formatted it and using Win32DiskImager and Raspberry Pi Imager wrote Raspbian OS back onto it (2020-02-13-raspbian-buster) as well as the SSH file, only this time the IP hasn't come up. I've written another OS to it as well to the same result (2020-08-20-raspios-buster-armhf).

I also decided to try wpa_supplicant.conf and have the Pi boot up online. This didn't work.

I know that the Pi must be registering the SD card since the SSH file was deleted (meaning it was enabled). I also made sure the file extension of the wpa_supplicant.conf file was correct. I'm not sure where else to go from here in order to solve my problem. Could I be mistaken in thinking an SSH file being deleted means that the SD card is being read? Are there any physical indicators that the Pi is connected to a network or the SD card is being read from(lights)? Could this be an issue with my computer?

Update from a comment:
It (the ip address) no longer appears (with Advanced IP Scanner) unfortunately...

Edit: Using wpa_supplicant.conf, I connected to my router and started remote access through WiFi. So that works. For some reason though, using the ethernet doesn't. WiFi is far laggier, so if possible I'd like to get ethernet to work. Now that I have access to my pi, how could I potentially troubleshoot?

Edit:

Output for 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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:58:38:7b brd ff:ff:ff:ff:ff:ff
    inet 169.254.123.193/16 brd 169.254.255.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::4de:8ab1:f694:e760/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:0d:6d:2e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.243/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0
       valid_lft 86315sec preferred_lft 75515sec
    inet6 fe80::91e6:143f:5269:b08d/64 scope link 
       valid_lft forever preferred_lft forever

Output for ip route:

default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.247 metric 202 
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.243 metric 303 
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.247 metric 202 
192.168.1.0/24 dev wlan0 proto dhcp scope link src 192.168.1.243 metric 303 

Answer 1

Shown with ip addr and ip route there is an issue with the ip address of interface eth0. With

192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.247 metric 202

from the routing table the RasPi has detected that it is connected with eth0 to your internet router on network 192.168.1.0/24 and that it has got this information from a DHCP server. So the connection and DHCP server is working. The interface eth0 should have the ip address 192.168.1.247 that is detected as source ip address on the routing table (see above). But ip addr shows that it has address 169.254.123.193/16.

169.254.123.193/16 is a link-local address that is used if a DHCP server cannot be detected on the link. I do not understand how this is possible. From the routing table it must have 192.168.1.247.

For testing you can try to set the ip address on eth0 with

rpi ~$ sudo ip addr del 169.254.123.193/16 dev eth0
rpi ~$ sudo ip addr add 192.168.1.247/24 dev eth0

Now you should have two connections to the router, one with WiFi on interface wlan0 and one wired on interface eth0. The kernel has to decide what connection to use and it selects that with the lowest metric, which is eth0 with metric 202. This will break your ssh session on wlan0. It get stuck. To avoid this you can modify the metric before changing the ip address:

rpi ~$ ip route add 192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.247 metric 404
rpi ~$ ip route del 192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.247 metric 202

When you have changed the ip address afterwards you should be able to ping your router:

rpi ~$ ping -I eth0 192.168.1.1

If this works then look what's the problem with the ip address on interface eth0. For my understanding it is not possible to have different ip addresses shown with ip addr and ip route.

Answer 2

Whether or not the removal of the SD card was an issue is hard to tell. You have apparently written a new image to it. So it is immaterial; it is now impossible to find out. The deletion of the ssh file means at least that the Pi boots; it can only do so when it reads at least the kernel from the card. Otherwise, it could not delete the file. It is an indication that the Pi writes the SSD.

Unlike the wired network, the Pi does not have a LED status for being connected to the Wifi network. I'm certain that it would be possible. A script like:

#!/bin/bash
PINgTARGET=192.168.1.1

while : ; do
    if ping -c1 $PINgTARGET ; then
        echo 1 >/sys/class/leds/led0/brightness
    fi
    if ping -c1 $PINgTARGET ; then
        echo 0 >/sys/class/leds/led0/brightness
    fi
done

would do that. Your script would then go into /usr/local/bin and, for example, be started from crontab with an @reboot. Allas, you are working from Windows, so accessing the root file-system would be a problem.

As a final note, the method documented on https://dullaart.website/raspberry/1_headless_setup.html#a1. always worked for me, but that is obvious if you understand that this is my own website.