Linux: Macvlan is broken with kernal 4.19.97-v7l+

[LizhangX]

Describe the bug
Current raspian buster kernal 4.19.97-v7l+ has a macvlan bug where it doesn't broadcast it's IPs.
Macvlan docker containers were unreachable outside of the host machine by IPv4.

It seemed to be fixed with later version/patch.
kernel bug
fix commit

To reproduce and the behavior

1. Install docker
2. Setup macvlan network.
3. Create a container (e.g. pihole/IoBroker) using the macvlan network with a static IP.
4. From desktop/laptop(not from Rpi host), ping the container's static IP (No response, also arp -a doesn't show an entry with container's IP and mac address)
5. Exec to the container and ping the desktop/laptop used on step 4, first ping will take longer(~1s) and succeeding pings are much faster.
6. After step 5, able to ping from the desktop/laptop to the container, and an entry with container's IP and mac address shows up from arp -a
7. Cached ARP entry will be refreshed (gone) when switching/reconnect desktop/laptop network or after sometime.
8. So have to repeat step 5 or create static ARP entry in the desktop/laptop to keep it working.

System

• Which model of Raspberry Pi?

Pi4 4gb

• Which OS and version (cat /etc/rpi-issue)?

Raspberry Pi reference 2019-09-26
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 80d486687ea77d31fc3fc13cf3a2f8b464e129be, stage2

• Which firmware version (vcgencmd version)?

Feb 10 2020 15:15:59
Copyright (c) 2012 Broadcom
version d21c2d51634b793e0b0ce2816c4e3d1cf0d87e6b (clean) (release) (start)

• Which kernel version (uname -a)?

Linux raspberrypi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux

Additional context
If we ping from the container to our work station, first ping would take a while, it seem to have the desktop/laptop cache the ARP entry in local. And the connection will keep working because of that. Whenever we switch the network or after sometime, the cache will be refreshed and gone. One can verify doing arp -a command from the work station before and after pinging from the container. Current workaround would be create a static ARP entry in your work station. (So we don't need to keep pinging the work station again and again.)

[pelwell]

Thanks for the report. As that commit is tagged as a fix it should automatically be back-ported into all of the LTS branches including v4.19. rpi-4.19.y will pick up the fix as and when that happens.

[LizhangX]

Cool, thank you!

[nick2k3]

Hi, apologies for bringing this back up. Is there any roadmap as to when this fix will be available on the stable branch? (it is already fixed in the 4.19.105* trough rpi-update).
Thanks!

[flobernd]

Grrr ... I spent nearly a day debugging my network because of this bug. Took me some time to find out that the problem was caused by Raspberry Pi software itself.

when this fix will be available on the stable branch?

This just happened yesterday I guess. Was running on a 5.X kernel version after rpi-update and today after apt upgrade it reverted to 5.4.42-v7l+. This one already contains the fix required for the MacVLAN.

[cueoriginal]

I personally invested days to find this is a bug. But even after upgrading via rpi-update I am still not able to reach my IOBroker Container from my Laptop.
Trying the suggested workaround to ping my Laptop does not help as well.

As I am already on a possibly unstable firmware I am sure willing to help troubleshooting this.

Beforehand I updated to a minor build and was able to reach the Container for some days but that stopped yesterday and upgrading as described did not help.

[JamesH65]

@pelwell No idea what macvlan is but come up in the blog posts as well.

[cueoriginal]

@JamesH65 Are you able to provide a link to the post? As the issue still seems to persist I am very interested.

[flobernd]

@cueoriginal
This specific issue is definitely fixed - I'm pretty sure there is a different problem with your setup. The fact that the ping workaround does not help either adds to this guess.

[cueoriginal]

@flobernd You are probably right even if the issue is related it has to be different at some point. So you are suggesting I should open an issue myself? Any hints on which data I should provide? Never opened an issue myself but I know that it is tedious to ask for necessary information again and again so I would like to make it right from the beginning.

[flobernd]

@cueoriginal I would probably try to get help in the Raspberry Pi forum first before opening an issue on GitHub. Not sure what details to include, but probably at least all the related network config and maybe even hardware details about switches and so on.