Raspberry network problems after update

ARM Technical Assistance
6

You do know that using /16 you are creating a gigantic network - for most networks - at least in this forum - /24 is adequate

As a side note - I have just synced a pi running Manjaro - and I had no network issues.

I should say that my network is using dhcp and where the device is running a network service like nginx or my dev workstation and vm - the service assigns ip based on the mac address.

The only systems in my network configured with static adresses is

  • router
  • bind/isc-dhcp service (Raspberry Pi OS)
  • swtiches
7

I know perfectly that using /16 you are creating a gigantic network but this is not the problem.

It uses only few resources compared to the utility to have this address space.

You could be upgraded after the bug-solution and be lucky.

My Rasp is a DHCP and bind server. The static IP is owned by this Rasp and an OpenWRT router. Now the router is working as DHCP server /16 without a problem.

But these are only words that do not help to understand and resolve the problem. A solution is the use of RaspbianOs Bullseye, it is working perfectly but I have to configure the services.

At the end, I think that this is not a race but a collaborative place.

Perhaps the problem is too hard to be resolved for the community too, and the best solution is to change OS.

Finally, I just downloaded a minimal manjaro ISO for Rasp (Raspberry Pi 4, I have a Pi3), and does not get the IP from the DHCP server.

I think that there is a problem in the last rolling release but this does not resolve the problem. I hope that this information helps other users… cheers

8

If the latest image (22.08) does not get an IP either, then it’s not an issue with this update, as that happened after the release of the images.

9

Perhaps we are having a language issue here - I have no idea what you are talking about.

It seems you are saying you have the same ip on both devices.

And there is far too little information to provide any meaningful response.

Which network daemon to you use?

  • systemd
  • network manager
  • netctl

So the PI in question was responsible for dhcp and dns?

I didn’t say it was a problem - I just wondered about the size of the network.

As I understand from the quoted sentence - your router issues dhcp for the subnet

But you also say your pi is running dhcp/dns for the same subnet or should I understand it that you have setup the router because the pi lost network?

I am confused - which device does what?

You cannot have two dhcp services for the same subnet.

Ok - did you actually move the sd card back into the pi?

Should it be assumed the following is on the pi or the laptop?

Is this on the laptop? pinging the router?

still on the laptop?

If you have successfully assigned an IP address to NIC then you can ping yourself.

If you cannot ping the router - then there is no connection from the NIC with .100 address to the network.

A physical connection does not imply an actual network connection - if the address, subnet, gateway etc. is wrong then a connection cannot be made despite the physical connection.

All that makes sense if you are actually executing the commands on your laptop with the mounted sd-card because you likely changed the assigned address on your laptop from an IP actually connected to a network to an IP which is not connected to a network.

10

I try to simplify the description by answering the important question you provide.

Before the upgrade, OpenWRT and Rasp obviously had two different static IP.

As written in the previous message

./dbus-org.freedesktop.network1.service
./sockets.target.wants/systemd-networkd.socket
./sysinit.target.wants/systemd-network-generator.service
./network-online.target.wants
./network-online.target.wants/systemd-networkd-wait-online.service
./multi-user.target.wants/systemd-networkd.service

It is a systemd. I think that the minimal version I used for the first installation had only systemd and I did non changed it.

yes…

Before choosing to have a private network this size, I tested different performances with different network sizes, and this solution has some advantages. For example, it is easy to isolate some IP in order to avoid some entity communicating with the network. It is sufficient to configure a firewall with a blocking interval.

I set up the router after that I “lost” the Pi.

Usually, the router does not manage IP addresses.

I mounted the microSD in my laptop to provide you the exact text copy of the config files. The test are performed directly from Rasp with the mounted microSD mounted.

10.10.100.100 is the IP of the Rasp.

Right. After the upgrade, the Rasp lost the network connection, and the tests I show before failed.

The problem is that the eth0 Rasp interface remains down, despite the command to up it!

I can only write that the hardware works perfectly, RaspbianOS works perfectly.

The solution is…?

Thx for the help provided

11

What is the status of the systemd-networkd service?

systemctl status systemd-networkd

One could suspect the service has failed.

journalctl -xe -u systemd-networkd

You can use networkctl

networkctl status

Set a device up

networkctl up eth0

Changes to the network file can be reloaded

networkctl reconfigure eth0

Reload everything

networkctl reload

To see what you are up against I have

  • used ssh to reconfigure my raspberry pi webserver (Manjaro arm-stable serving https://root.nix.dk)

    $ uname -a
Linux pw1 5.15.61-1-MANJARO-ARM-RPI #1 SMP PREEMPT Wed Aug 24 12:01:00 UTC 2022 aarch64 GNU/Linux

  • from dhcp to static and with no error or outage

Dumped a file in /etc/systemd/network with

$ cat eth0.network 
[Match]
Name=eth0

[Network]
Address=172.30.30.50/24
Gateway=172.30.30.1
DNS=172.30.30.4

Then

sudo networkctl reload

My ssh connection didn’t even break - likely because I didn’t change the IP as such - just changed the assignment type.

Rereading the thread to see if I missed something and caugth my eye

If I recall correct you should have the broadcast address as well

sudo ip addr add 10.10.100.100/16 broadcast 10.10.255.255 dev eth0

I learned something new - the actual broadcast address can be a + sign instructing the system to calculate the correct broadcast address.

12

Here there is no solution, I continue this thread going that it helps other users to resolve the problem.

I have followed your notes… the IP is assigned only by forcing it with the command:

sudo ip addr add 10.10.100.100/16 dev eth0

Now I write the step one by one.

These are the results of logs and commands:

IMG_20220913_164830
IMG_20220913_1648301920×864 97.7 KB

IMG_20220913_164931
IMG_20220913_1649311920×864 34.9 KB

IMG_20220913_165344
IMG_20220913_1653441920×864 160 KB

IMG_20220913_165430
IMG_20220913_1654301920×864 105 KB

IMG_20220913_165642
IMG_20220913_1656421920×864 171 KB

IMG_20220913_165702
IMG_20220913_1657021920×864 217 KB

IMG_20220913_165719
IMG_20220913_1657191920×864 234 KB

IMG_20220913_170155
IMG_20220913_1701551920×864 175 KB

IMG_20220913_170218
IMG_20220913_1702181920×864 161 KB

Here I am and I will not format this microSD for some days…

13

Please use text instead of pictures

The command should like this - you didn’t enter the word broadcast - in any case this should not be necessary

What does the journal say? example

$ journalctl -xe -u systemd-networkd
~
Aug 10 01:29:28 pw1 systemd[1]: Starting Network Configuration...
░░ Subject: A start job for unit systemd-networkd.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit systemd-networkd.service has begun execution.
░░ 
░░ The job identifier is 109.
Aug 10 01:29:28 pw1 systemd-networkd[214]: lo: Link UP
Aug 10 01:29:28 pw1 systemd-networkd[214]: lo: Gained carrier
Aug 10 01:29:28 pw1 systemd-networkd[214]: Enumeration completed
Aug 10 01:29:28 pw1 systemd[1]: Started Network Configuration.
░░ Subject: A start job for unit systemd-networkd.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit systemd-networkd.service has finished successfully.
░░ 
░░ The job identifier is 109.
Aug 10 01:29:28 pw1 systemd-networkd[214]: eth0: Configuring with /etc/systemd/network/eth0.network.
Aug 10 01:29:28 pw1 systemd-networkd[214]: eth0: Link UP
Sep 13 17:07:50 pw1 systemd-networkd[214]: eth0: Gained carrier
Sep 13 17:07:52 pw1 systemd-networkd[214]: eth0: Gained IPv6LL

What does networkctl say after a reboot - mine goes like this

$ networkctl status
●        State: routable                         
  Online state: online                           
       Address: 172.30.30.50 on eth0
                fe80::f6dd:a94b:8b37:a05e on eth0
       Gateway: 172.30.30.1 on eth0
           DNS: 172.30.30.4

Aug 10 01:29:28 pw1 systemd[1]: Starting Network Configuration...
Aug 10 01:29:28 pw1 systemd-networkd[214]: lo: Link UP
Aug 10 01:29:28 pw1 systemd-networkd[214]: lo: Gained carrier
Aug 10 01:29:28 pw1 systemd-networkd[214]: Enumeration completed
Aug 10 01:29:28 pw1 systemd[1]: Started Network Configuration.
Aug 10 01:29:28 pw1 systemd-networkd[214]: eth0: Configuring with /etc/systemd/network/eth0.network.
Aug 10 01:29:28 pw1 systemd-networkd[214]: eth0: Link UP
Sep 13 17:07:50 pw1 systemd-networkd[214]: eth0: Gained carrier
Sep 13 17:07:52 pw1 systemd-networkd[214]: eth0: Gained IPv6LL
14

This network issue is probably due to this bug:

Network not working after updating to 5.15.61

Upgrading kernel from 5.15.61 to 5.19.3 fixed issue on Pi3 yesterday.

core/linux-rpi4 5.15.61-1
core/linux-rpi4-headers 5.15.61-1
core/linux-rpi4-mainline 5.19.3-1 [installed]
core/linux-rpi4-mainline-headers 5.19.3-1 [installed]

2 Likes
15

Apparently:

[Re: After kernel update 5.15.56-4 → 5.15.61-1 network is lo]

The now available 5.15.61-3 fixes the issue.

1 Like
16

How can I update the kernel without a network?

17

a special thanks to @MrDuck for having identified the problem

1 Like
18

:grinning:

interesting - I just happened to have the kernel which has no issues :slight_smile:

19

This bricked my headless Raspberry Pi NAS on Monday. I re-flashed with the current Manjaro minimal and it was fine, but sudo pacman -Syu bricked it again. I planned to connect a keyboard and monitor to troubleshoot it this weekend. I’m glad it’s been fixed in the interim.

20

I have only one comment. MAnjaro for Rasp supports only RaspberryPi 4. My Rasp is another model. I am not happy, but I have to change the distro. I like rolling-release distros and, in particular, Manjaro, but I can risk facing this problem again. I switch on RasbianPi. I hope that Bullseye is a rolling-version, as I read somewhere.
I still use Manjaro for my desktops, even if I had problems with it in the past. NVidia stopped supporting my old card, and I had to manually configure the nouveau drivers manually…

21

Not entirely correct.
We support the Raspberry Pi 4, 400, 3B+ and 3. And a couple of Zeros. With the same image.

1 Like
22

Ok, the update made unusable my Raspberry Pi 3 Model B Rev 1.2

23

Through earlier today, linux-rpi4 stable was 5.15.61-1, with broken Ethernet.

I’m happy to report that linux-rpi4 stable now is 5.15.67-0.1, with working Ethernet. So it’s safe to perform “pacman -Syu” again. :slight_smile:

Thanks!

1 Like
24

2 posts were split to a new topic: Raspberry Pi Zero W Support