[networkd] Assertion '!(msg.msg_flags & MSG_TRUNC)' failed

[gdamjan]

systemd compiled from git (b304283) (Arch AUR package)
the system is a libvirt/kvm archlinux guest. It has a single ens5 interface set to use DHCP (just [Network] DHCP=yes).

networkd crashes with:

Jan 28 07:34:26 arch-uefi-test systemd[1]: Starting Network Service...
Jan 28 07:34:26 arch-uefi-test systemd-networkd[10140]: ens5: Gained IPv6LL
Jan 28 07:34:26 arch-uefi-test systemd-networkd[10140]: Enumeration completed
Jan 28 07:34:26 arch-uefi-test systemd[1]: Started Network Service.
Jan 28 07:34:26 arch-uefi-test systemd-networkd[10140]: ens5: Could not drop address: No such process
Jan 28 07:34:26 arch-uefi-test systemd-networkd[10140]: Assertion '!(msg.msg_flags & MSG_TRUNC)' failed at src/libsystemd-network/sd-ndisc.c:536, function ndisc_router_advertisment_recv(). Aborting.
Jan 28 07:34:26 arch-uefi-test systemd[1]: systemd-networkd.service: Main process exited, code=killed, status=6/ABRT
Jan 28 07:34:26 arch-uefi-test systemd[1]: systemd-networkd.service: Unit entered failed state.

[poettering]

@teg, any idea?

[gdamjan]

logging out len and buflen before that assert they are both 74.

[gdamjan]

But!
I've set buflen to a fixed 1500, len (from recvmsg) now is 144 bytes, and the assert no longer applies. it seems that the r = ioctl(fd, FIONREAD, &buflen); doesn't return the proper value??

[poettering]

Strange... that would indicate a kernel bug...

[gdamjan]

I tried both 4.4.1 and 4.1.17 (arch kernels) same behaviour. isn't it possible for data to arrive after FIONREAD is called?

[poettering]

well, but it's a datagram interface... datagrams should not change their size just because more datagrams have been received...

But maybe the local queuing drops datagrams for some reason (after all, they are allowed to do that, it's IP). and hence between FIONREAD and recvmsg() the packet we are about to process changes...

[gdamjan]

a quick workaround would be to use a uint8_t buffer[BUFFER_MAX_SIZE]; on the stack to read into instead of the dynamically malloc/cleanup_free heap variable?

(edit) … or malloc enough bytes for an RA.

[gdamjan]

Any ideas? I will send a pull request to just malloc a buffer of 2048, it seem the better option than the current.

ps. there are no 74 byte icmp6 datagrams on the network, only 144 byte ones (checked with sudo tcpdump -i bridge0 -nv icmp6).

[teg]

Thanks for the report. This seems really odd. I'll have a look.

[teg]

how reproducible is this for you? if you add logging to record every successful packet, does it get the wrong size every time, or just some of the time?

[gdamjan]

fully reproducible
I get the same thing all the time

[poettering]

@gdamjan could you check if the patch in #2626 fixes the problem for you?