Failure to deserialize a new neighbor notification.

[dvaembit]

Version of neli

Both 0.7.1 and commit dbacf64

Describe the bug

Failure to deserialize a new neighbor notification.

To Reproduce

Steps to reproduce the behavior:

1. Run this program as root:

use std::error::Error;

use neli::consts::socket::NlFamily;
use neli::router::synchronous::NlRouter;
use neli::utils::Groups;

const RTMGRP_NOTIFY: u32 = 2;
const RTMGRP_NEIGH: u32 = 4;

fn main() -> Result<(), Box<dyn Error>> {
    simple_logger::SimpleLogger::new()
        .env()
        .init()
        .expect("Failure to initialize simpler_logger");

    let nl_rte_groups = Groups::new_bitmask(RTMGRP_NEIGH | RTMGRP_NOTIFY);
    let (nl_rte_router, nl_recv_handle) =
        NlRouter::connect(NlFamily::Route, None, nl_rte_groups)
            .map_err(|e| format!("Failed to connect to netlink: {e}"))?;

    nl_rte_router.enable_strict_checking(false)?;
    println!("Waiting for netlink notifications.");

    for maybe_msghdr in nl_recv_handle {
        match maybe_msghdr {
            Err(e) => eprintln!("Failed to receive netlink message header: {e}"),
            Ok(msghdr) => println!("{:?}", msghdr),
        };
    }

    Ok(())
}

2. Run this command:

sudo ip neigh add 192.168.148.181 lladdr ca:bd:31:de:dc:c7 dev wlp4s0

3. Observe deserialization error:

2025-10-06T22:15:30.831Z TRACE [neli::utils::synchronous] Semaphore acquired; current count is 1, available is 2
2025-10-06T22:15:32.962Z TRACE [neli::socket::synchronous] Buffer received: [76, 0, 0, 0, 28, 0, 0, 0, 0, 0, 0, 0, 68, 0, 16, 0, 2, 0, 0, 0, 3, 0, 0, 0, 128, 0, 0, 1, 8, 0, 1, 0, 192, 168, 148, 181, 10, 0, 2, 0, 202, 189, 49, 222, 220, 199, 0, 0, 8, 0, 4, 0, 0, 0, 0, 0, 20, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0]
2025-10-06T22:15:32.962Z TRACE [neli::nl] Deserializing data type Nlmsghdr
2025-10-06T22:15:32.962Z TRACE [neli::nl] Deserializing field type u32
2025-10-06T22:15:32.962Z TRACE [neli::nl] Buffer to be deserialized: [76, 0, 0, 0]
2025-10-06T22:15:32.962Z TRACE [neli::nl] Field deserialized: 76
2025-10-06T22:15:32.962Z TRACE [neli::nl] Deserializing field type u16
2025-10-06T22:15:32.962Z TRACE [neli::nl] Buffer to be deserialized: [28, 0]
2025-10-06T22:15:32.962Z TRACE [neli::nl] Field deserialized: 28
2025-10-06T22:15:32.962Z TRACE [neli::nl] Deserializing field type neli::consts::nl::NlmF
2025-10-06T22:15:32.962Z TRACE [neli::nl] Buffer to be deserialized: [0, 0]
2025-10-06T22:15:32.962Z TRACE [neli::consts::nl] Deserializing data type NlmF
2025-10-06T22:15:32.962Z TRACE [neli::consts::nl] Deserializing field type u16
2025-10-06T22:15:32.962Z TRACE [neli::consts::nl] Buffer to be deserialized: [0, 0]
2025-10-06T22:15:32.962Z TRACE [neli::consts::nl] Field deserialized: 0
2025-10-06T22:15:32.962Z TRACE [neli::nl] Field deserialized: NlmF(0)
2025-10-06T22:15:32.962Z TRACE [neli::nl] Deserializing field type u32
2025-10-06T22:15:32.962Z TRACE [neli::nl] Buffer to be deserialized: [0, 0, 0, 0]
2025-10-06T22:15:32.962Z TRACE [neli::nl] Field deserialized: 0
2025-10-06T22:15:32.962Z TRACE [neli::nl] Deserializing field type u32
2025-10-06T22:15:32.962Z TRACE [neli::nl] Buffer to be deserialized: [68, 0, 16, 0]
2025-10-06T22:15:32.962Z TRACE [neli::nl] Field deserialized: 1048644
2025-10-06T22:15:32.962Z TRACE [neli::nl] Deserializing field type neli::nl::NlPayload<u16, neli::types::Buffer>
2025-10-06T22:15:32.962Z TRACE [neli::nl] Buffer to be deserialized: [2, 0, 0, 0, 3, 0, 0, 0, 128, 0, 0, 1, 8, 0, 1, 0, 192, 168, 148, 181, 10, 0, 2, 0, 202, 189, 49, 222, 220, 199, 0, 0, 8, 0, 4, 0, 0, 0, 0, 0, 20, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0]
2025-10-06T22:15:32.962Z TRACE [neli::nl] Deserializing data type neli::nl::NlPayload<u16, neli::types::Buffer>
2025-10-06T22:15:32.962Z TRACE [neli::nl] Field deserialized: Payload(Buffer)
2025-10-06T22:15:32.962Z TRACE [neli::iter] Message received: Nlmsghdr { nl_len: 76, nl_type: 28, nl_flags: NlmF(0), nl_seq: 0, nl_pid: 1048644, nl_payload: Payload(Buffer) }
2025-10-06T22:15:32.962Z TRACE [neli::router::synchronous] Message received: Ok(Nlmsghdr { nl_len: 76, nl_type: 28, nl_flags: NlmF(0), nl_seq: 0, nl_pid: 1048644, nl_payload: Payload(Buffer) })
2025-10-06T22:15:32.962Z TRACE [neli::genl] Deserializing data type Genlmsghdr
2025-10-06T22:15:32.962Z TRACE [neli::genl] Deserializing field type u8
2025-10-06T22:15:32.962Z TRACE [neli::genl] Buffer to be deserialized: [2]
2025-10-06T22:15:32.962Z TRACE [neli::genl] Field deserialized: 2
2025-10-06T22:15:32.962Z TRACE [neli::genl] Deserializing field type u8
2025-10-06T22:15:32.962Z TRACE [neli::genl] Buffer to be deserialized: [0]
2025-10-06T22:15:32.962Z TRACE [neli::genl] Field deserialized: 0
2025-10-06T22:15:32.962Z TRACE [neli::genl] Deserializing field type u16
2025-10-06T22:15:32.963Z TRACE [neli::genl] Buffer to be deserialized: [0, 0]
2025-10-06T22:15:32.963Z TRACE [neli::genl] Field deserialized: 0
2025-10-06T22:15:32.963Z TRACE [neli::genl] Deserializing field type neli::genl::NoUserHeader
2025-10-06T22:15:32.963Z TRACE [neli::genl] Buffer to be deserialized: []
2025-10-06T22:15:32.963Z TRACE [neli::genl] Field deserialized: NoUserHeader
2025-10-06T22:15:32.963Z TRACE [neli::genl] Deserializing field type neli::types::GenlBuffer<u16, neli::types::Buffer>
2025-10-06T22:15:32.963Z TRACE [neli::genl] Buffer to be deserialized: [3, 0, 0, 0, 128, 0, 0, 1, 8, 0, 1, 0, 192, 168, 148, 181, 10, 0, 2, 0, 202, 189, 49, 222, 220, 199, 0, 0, 8, 0, 4, 0, 0, 0, 0, 0, 20, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0]
2025-10-06T22:15:32.963Z TRACE [neli::types] Deserializing data type GenlBuffer
2025-10-06T22:15:32.963Z TRACE [neli::types] Deserializing field type alloc::vec::Vec<neli::genl::Nlattr<u16, neli::types::Buffer>>
2025-10-06T22:15:32.963Z TRACE [neli::types] Buffer to be deserialized: [3, 0, 0, 0, 128, 0, 0, 1, 8, 0, 1, 0, 192, 168, 148, 181, 10, 0, 2, 0, 202, 189, 49, 222, 220, 199, 0, 0, 8, 0, 4, 0, 0, 0, 0, 0, 20, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0]
2025-10-06T22:15:32.963Z TRACE [neli::genl] Deserializing data type Nlattr
2025-10-06T22:15:32.963Z TRACE [neli::genl] Deserializing field type u16
2025-10-06T22:15:32.963Z TRACE [neli::genl] Buffer to be deserialized: [3, 0]
2025-10-06T22:15:32.963Z TRACE [neli::genl] Field deserialized: 3
2025-10-06T22:15:32.963Z TRACE [neli::genl] Deserializing field type neli::genl::AttrType<u16>
2025-10-06T22:15:32.963Z TRACE [neli::genl] Buffer to be deserialized: [0, 0]
2025-10-06T22:15:32.963Z TRACE [neli::genl] Field deserialized: AttrType { nla_nested: false, nla_network_order: false, nla_type: 0 }
Failed to receive netlink message header: Deserialization failed: Invalid input was provided: 3

Please provide a minimal, ready-to-compile example that reproduces the bug
See above.

Expected behavior

1. I expect this message to deserialize okay since it was authored by the kernel.
2. I also expect the NlRouterReceiveHandle to be able to continue receiving additional messages. In other words, I am surprised this is considered a fatal error.

Additional context

Test on kernel: 6.16.7+deb14-amd64
Compiled with rust 1.89.0

I used an nlmon device to capture netlink traffix while running a similar ip neigh add command. Based on the wireshark decoding of those packets, I believe the 3 in the neli trace is supposed to be the interface index:

[jbaublitz]

Hi @dvaembit, thanks for the report. I've pulled your concern about deserialization out into a separate issue that I will investigate later: #305. Right now I'm working on getting 0.7.2 out but will look at this immediately after that is released.

[jbaublitz]

Hi @dvaembit, I've dug into the problem you're bumping into with the error being fatal in deserialization. I believe you mean that every subsequent deserialization will return an error, is that correct? If so, I believe this is due to the fact that neli rewinds the cursor if deserialization fails. I thought this would be helpful so as not to lose data that has not been properly deserialized but I can see how this would cause problems and essentially turn it into a fatal error if that message is not appropriately deserialized. Does this match your user experience? If so what would be the ideal outcome you'd like to see here? Would it be better to skip the message but return the raw bytes? Disregard it entirely?

[jbaublitz]

I've also looked into the trace you provided and I believe that the problem here is that the multicast group receiver is expecting a Genlmsghdr to be returned by the multicast group. This is true for many multicast groups, but it appears it is not true in this case. Do you happen to know what the expected data structure is for the payload in these multicast group messages?

[dvaembit]

If so, I believe this is due to the fact that neli rewinds the cursor if deserialization fails. I thought this would be helpful so as not to lose data that has not been properly deserialized but I can see how this would cause problems and essentially turn it into a fatal error if that message is not appropriately deserialized. Does this match your user experience?

Yeah, that sounds like what was happening to me. I can see use cases for both of these modes. If the packet capture is invalid, it doesn't help to skip forward to a location that is also likely invalid. However, if the parser just doesn't understand a packet, it's best to have an option to skip forward.

Do you happen to know what the expected data structure is for the payload in these multicast group messages?

They are notifications of changes to the neighbor tables. This is the first I'm I've tried to use netlink notifications. So I don't know all of the lower level the details.

Since filing this bug report, I was able to get something analogous working with the netlink-packet-route crate. It pushes these enum variants to me. So I suspect the details of the message structures could be found in their parsing code. The AddressMessage is the one I'm consuming.

[jbaublitz]

If so, I believe this is due to the fact that neli rewinds the cursor if deserialization fails. I thought this would be helpful so as not to lose data that has not been properly deserialized but I can see how this would cause problems and essentially turn it into a fatal error if that message is not appropriately deserialized. Does this match your user experience?

Yeah, that sounds like what was happening to me. I can see use cases for both of these modes. If the packet capture is invalid, it doesn't help to skip forward to a location that is also likely invalid. However, if the parser just doesn't understand a packet, it's best to have an option to skip forward.

There's a middle-ground. The first field of the netlink header is the length, so it is trivial (as long as there is a netlink header for each message; see #96) to skip to the start of the next valid message. How would it sound to you to return an error containing the raw bytes and skip to the next message? I'm not sure if the copying of the buffer is desirable but I feel like this would be better than simply continuing to return an error. That way it would be feasible to at least write a workaround while I upstream a patch to fix it. I'll have to consider the audit case, but I believe this may be a solution. Another option is to provide a method to manually skip to the next message which would give the user control over the behavior they want. Which sounds like it would be more desirable in the case you bumped into?

Do you happen to know what the expected data structure is for the payload in these multicast group messages?

They are notifications of changes to the neighbor tables. This is the first I'm I've tried to use netlink notifications. So I don't know all of the lower level the details.

Since filing this bug report, I was able to get something analogous working with the netlink-packet-route crate. It pushes these enum variants to me. So I suspect the details of the message structures could be found in their parsing code. The AddressMessage is the one I'm consuming.

Okay I took a look and will start working on a fix. What I believe is happening is that generic netlink returns a different packet format from routing netlink. The routing netlink format appears not to be supported in neli at the moment. Thanks for bringing this to my attention!

[dvaembit]

I think either of those approaches would work for me. I think having the bytes that were not parsed could be particularly helpful for figuring out whether I've done something wrong versus the system sending unconventional netlink packets versus a bug in neli.

[jbaublitz]

Okay thanks so much for the feedback! Often it can be hard to gather feedback unprompted so it's much appreciated.