2

tl;dr: After my local network addressing scheme changed from 192.168.1.X to 192.168.21.X, my RPi failed to adapt and was still accessible via 192.168.1.2. When I added iface eth0 inet dhcp as the last line of /etc/network/interfaces file and rebooted my RPi, it stopped being accessible on any IP. What can I do to regain access to my box?

0. Intro

I have Raspberry Pi 3 B+ WiFi BT with 1GB RAM QuadCore 1,4 GHz and with Flightradar24 image. Previously I have reserved, on my router, a static DHCP assignment for my RPi, via MAC address, so I can access it all the time through 192.168.1.2 address. My Windows 10 is connected to the same network and also receives DHCP-based IP address, but it has no router-side reservation.

My previous router died and the new one, that I have received from my ISP, had some configuration problems so I was ultimately forced to use 192.168.21.X instead of 192.168.1.X addressing pool. All the DHCP-based devices adapted to this change, but not RPi.

I have configured my new router to always assign 192.168.21.41 this time to my RPi.

1. Old IP address

The original documentation says that RPi always uses DHCP by default. I doubt that Flightradar24 engineers has changed this when compiling their own image for RPi. But, in my case this seemed to be untrue, because I couldn't find my RPi's MAC address among list of clients connected to my new router (after replacing it and after local network addressing scheme changed from 192.168.1.X to 192.168.21.X).

Because I was aware that my old router was always assigning 192.168.1.2 to my RPi, I have temporarily forced my Windows 10 to use 192.168.1.3 IP address and 192.168.1.1 gateway and... bingo! I found my RPi at that address.

The ifconfig has confirmed this:

pi@raspberrypi:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.2  netmask 255.255.255.0  broadcast 192.168.1.255
        ether b8:27:eb:13:bd:7f  txqueuelen 1000  (Ethernet)
        RX packets 4227  bytes 352722 (344.4 KiB)
        RX errors 0  dropped 1100  overruns 0  frame 0
        TX packets 2377  bytes 382278 (373.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 11265  bytes 1287027 (1.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11265  bytes 1287027 (1.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:46:e8:2a  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

2. Not accessible at all?

I have found this cool guide which told me that after I execute cat /etc/network/interfaces on my RPi, I will see iface eth0 inet in the last line on-screen and either dhcp or static at the end, denoting the way my RPi connects to the network.

That also turned out to be not true, because in my case cat /etc/network/interfaces revealed nearly an empty file:

pi@raspberrypi:~ $ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

Following the same guide I have added missing iface eth0 inet dhcp line to the end of /etc/network/interfaces:

sudo cp /etc/network/interfaces /etc/network/interfaces.backup
sudo nano /etc/network/interfaces
iface eth0 inet dhcp

Ctrl+O (write file) / Enter (confirm filename) / "Wrote 11 lines" / Ctrl+X (Exit)

sudo shutdown -r now

After reboot, my RPi become completely not accessible:

  • not under previous / old of 192.168.1.2
  • not under auto-assigned by router of 192.168.21.41
  • and not even under fallback 169.254.0.0 IP address
  • it MAC (B8:27:EB:13:BD:7F) again doesn't appear on router's connected clients list.

(of course, I was changing my local PC with Windows 10's IP configuration each time, to match the one that I expected to have in RPi)

What should I do next? What can I do to get access to my box back?

Seamus
  • 18,728
  • 2
  • 27
  • 57
trejder
  • 129
  • 1
  • 10

3 Answers3

1

If you include dhcp in interfaces you break dhcpcd networking.

Restore to standard (or just delete it - it does nothing).

Don't follow ancient random tutorials. Try any of the official guides.

See How to set up networking/WiFi

"I am unable to … change anything i(n) my RPi's configuration" - actually there are several options:-

  1. Restore from your backup
  2. Connect the Pi to a PC with an Ethernet cable and use a Link-local address
  3. Mount the SD Card on a Linux computer (which can be a Pi with a new SD Card) and edit files
Milliways
  • 54,718
  • 26
  • 92
  • 182
  • I wish tutorials would include a date and/or OS version, so you can see if they are ancient or not. – Ljm Dullaart Jan 18 '21 at 11:51
  • Since my question specifically points out that I have lost access to my RPi and I am unable to find it in my network then I can only upvote your answer, but can't accept it. I am unable to execute any command-line command or change anything it my RPi's configuration. – trejder Jan 22 '21 at 19:00
1

tl;dr:

Q: What should I do next?

Please run the following command, and edit your question to include the results:

$ pgrep -a dhcpcd

I think the only real misstep in your procedure was following this cool guide. The fact that this cool guide doesn't have a date stamp anywhere on the page is the only real clue that it is FUBAR. But documentation was never their strong suit IMHO.

If, as you say, the Flightradar24 has not changed any of the RPi's default networking configuration, it seems to me that recovery from your present situation may be simple. But it also means you never should have seen this issue at all. Given that Flightradar24 is a complete OS, I wonder if that assumption is justified? Can you confirm this with Flightradar24's support team? I'm suspicious because:

  1. RPi OS uses dhcpcd by default, and it's very reliable under most circumstances

  2. dhcpcd should have picked up the new network address from any competent router.

  3. Networking controls are a popular target for knob dickers who think "improvements" are needed.

You can easily check if dhcpcd is on the job:

$ pgrep -a dhcpcd
556 /sbin/dhcpcd -q -w

If you get something different (or nothing at all), you'll need to learn what Flightradar24 is using - perhaps their forum can help?

In any event, this is "what you should do next". Until we've confirmed how your OS (modified OS) is doing, troubleshooting your current issue may be a waste of time. Let us know whether or not your system is using dhcpcd.

Seamus
  • 18,728
  • 2
  • 27
  • 57
  • Thank you for your long and detailed answer. As stated in the last part of my question, I cannot execute anything on my RPi, because I can't find it / access it in my network. It does not registers itself (with its DHCP) among client list on my router and it does not respond for my PuTTy calls on any of known / previously used IP addresses. The resolution that has came from FR24 support was as simple as "flash it from scratch again". – trejder Jan 20 '21 at 19:38
  • DHCP was enabled and supported by that RPi _initially_, because upon initial flashing, it correctly picked up DHCP data from router (I have pre-assigned static IP to that device a bit later). The odd thing is that when addressing scheme changed, RPi did not reflected this change and remained on old IP, effectively loosing access to the Internet. DHCP module at my router was trying to assign a static IP address from new addressing scheme, but failed to do so for some reasons. These comments are just answer to your suggestions. I think flashing from scratch is the only reasonable option here. – trejder Jan 20 '21 at 19:41
  • @trejder: I assumed you had a monitor & keyboard connected to your RPi - your Flightradar24 app *looked* like a GUI app?! Is Flightradar24 built on RPiOS **Lite**?? – Seamus Jan 20 '21 at 19:49
  • I am not sure on what [it is based](https://www.flightradar24.com/build-your-own). No, I don't use anything like keyboard and LCD. In normal conditions RPi image from FR24 is ready to go and you access its stat via local web serwer that this RPi's image makes available. – trejder Jan 20 '21 at 19:52
  • @trejder: Re-flashing might be the quickest & easiest thing for you to do. Do you have anything on the SD card that you want/need to save? And I'm curious: Does the Flightradar24 distro allow you to do anything else with your RPi, or does it become a "single app" server? – Seamus Jan 20 '21 at 20:03
  • @trejder: Just one other thing: I would recommend ***against*** trying to change your RPi's networking configuration to use a static IP. This is not to say it's *difficult* - the problem is that virtually everyone seems to do this for the wrong reasons, and they don't read or understand the documentation. – Seamus Jan 20 '21 at 20:09
  • No, as far as I know this is the single-app only solution that does not store anything locally on RPi (or stores some cache / garbage) and which main / the only purpose is to feed raw data from DVB-T stick and push it to FR24 (after some local pre-processing or not). As for your second comment -- it depends what you mean by "network configuration change to use static IP". If you mean doing anything with RPi itself then no, I only tried to bring DHCP to it. As for assigning static IP on router for RPi then yes, I do reserve it in my router's client list, as I do for more devices. – trejder Jan 22 '21 at 18:58
  • @trejder: Yes - "IP reservations" on your DHCP server/router are a different thing than setting fixed IP addresses in your RPi. And by design, IP addresses assigned in the "normal" DHCP process are sticky. Anyway - hope you get this all sorted & do let us know re-flashing works out or if there's anything else. – Seamus Jan 22 '21 at 19:46
1

A nice debugging trick for dhcpcd is "/sbin/dhcpcp -6|4 -U ". This dumps all the network information to stdout as grep'able shell variables. The -U is the secret which took me 3 month to find. Use-6 for IPv6 and -4 for IPv4. The -6 or -4 can be dropped.

I'm using dhcpcd on my RPi-4 firewall. I use a USB Ethernet dongle plugged into one of the 1000bps USB ports.

jow
  • 46
  • 4
  • Since my question specifically points out that I have lost access to my RPi and I am unable to find it in my network then I can only upvote your answer, but can't accept it. I am unable to execute any command-line command or change anything it my RPi's configuration. – trejder Jan 22 '21 at 19:00