Combability with later kernel verisons

[Aqualie]

• Version: 8.15.0
• Operating System: Linux 6.10.0
• Discuss Forum URL:
• Steps to Reproduce:

1. Deploy Linux machine with 6.10.0
2. Deploy elastic-agent with Elastic Defend policy enabled
3. Numerous inputs will all fail with the error: "error talking to the kernel (rtnetlink_send)"

https://github.com/elastic/ebpf/blob/d9a42f9959cf5b2f94134d7d3ae57b050038fe57/non-GPL/HostIsolation/Lib/TcLoader.c#L247

{"@timestamp":"2024-09-01T16:56:41.381958796Z","agent":{"id":"b4ac2bf3-8bca-41f0-8caf-83f19fb3a22a","type":"endpoint"},"ecs":{"version":"8.10.0"},"log":{"level":"warning","origin":{"file":{"line":84,"name":"Tux_HostIsolation.cpp"}}},"message":"error talking to the kernel (rtnetlink_send)\n","process":{"pid":2460681,"thread":{"id":2460798}}}

"Patch1: remove rtnetlink_send() modify rtnl_notify() to adapt more case in rtnetlink."
https://lore.kernel.org/linux-kernel//20210719122158.5037-1-yajun.deng@linux.dev/T/

[cmacknz]

CC @nfritts

[mauri870]

This issue can be reproduced by following the host isolation docs and running the TcLoaderDemo.

For me, the first time I run the demo I get:

$ sudo ./non-GPL/HostIsolation/Demos/TcLoaderDemo
rtnetlink replied: No such file or directory
error talking to the kernel (rtnetlink_send)

For subsequent runs I don't get this message anymore. I'm on Arch Linux with Kernel 6.10.7.

Weirdly enough, rtnetlink_send is still available in newer kernel versions https://elixir.bootlin.com/linux/v6.10.7/source/include/linux/rtnetlink.h#L13.

[stanek-michal]

Did you observe a change in behavior between older kernels and 6.10? Because this error has always appeared on first run, in fact it's a benign error. It is caused by the fact that we try to remove qdisc without checking that the qdisc exists on the network interface. It ends up being a no-op if there wasn't a qdisc in the first place, but a side-effect is this error message printed on the console.

[Aqualie]

@stanek-michal That's interesting so given that this error is "expected" and "normal" then it's not particularly clear what the underlying problem is that is causing the issue. Additional data supplied below:

NOTE: All the other inputs have the exact same error message, with the difference of course being the input name.

Attached start-up logs from the endpoint security agent.
endpoint_security_logs.csv

[stanek-michal]

In the logs I see we fail to detect metadata about the running system and that could be responsible for the failures. From what I remember we didn't support Arch Linux, it might work in some configurations and fail for others, I'm not entirely sure if it's about the kernel version being new.

[nicholasberlin]

Following up on 6.10+ kernel issues. We merged a fix here. The fix was only recently incorporated into Elastic Defend, however. It will be included going forward starting with v8.16.1 and v8.15.5.