Skip to content

npf_ip_src_addr_match() is using packet address family before it is set #100464

@zagor

Description

@zagor

Describe the bug

I'm trying network packet filtering and NPF_IP_SRC_ADDR_ALLOWLIST but struggle with it. After debugging a bit, I don't understand how this is supposed to work.

Ethernet packets enter net_recv_data(), which calls net_pkt_filter_recv_ok() to see if the packet should be accepted or dropped. If accepted, the packet is passed to net_queue_rx(), where it eventually ends up in ethernet_ip_recv(), which calls net_pkt_set_family() on it. Up until then, it is AF_UNSPEC.

One of the filters that can be called by net_pkt_filter_recv_ok() is npf_ip_src_addr_match(). It looks at the address family to see which address filter to use. But the address family is not set until later, so the address filter is never applied.

Here's the call graph:

net_recv_data()
 net_pkt_filter_recv_ok()
  lock_evaluate()
   evaluate()
    apply_tests()
     npf_ip_src_addr_match()
     {
        uint8_t pkt_family = net_pkt_family(pkt);
 net_queue_rx()
  net_process_rx_packet()
   net_rx()
    processing_data()
     process_data()
      net_if_recv_data()
       ethernet_recv()
        ethernet_ip_recv()
        {
          net_pkt_set_family(pkt, AF_INET6);

We have tests for the filters in tests/net/npf but they test the filter with a fully populated net_pkt struct. It appears we don't test passing the packet through the network stack.

Regression

  • This is a regression.

Steps to reproduce

struct in6_addr ipv6_address = {.s6_addr = { 0xaa, 0xbb, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x1 }};
NPF_IP_SRC_ADDR_ALLOWLIST(allowlist_ipv6_src_addr, (void *)&ipv6_address, 1, AF_INET6);
NPF_RULE(ipv6_allowlist, NET_OK, allowlist_ipv6_src_addr);

npf_append_recv_rule(&ipv6_allowlist);
npf_append_recv_rule(&npf_default_drop);

Relevant log output

Impact

Functional Limitation – Some features not working as expected, but system usable.

Environment

Zephyr v4.2.1, but I don't see any relevant changes since in 4.3 or master.

Tested on STM32 hardware.

Additional Context

No response

Metadata

Metadata

Assignees

Labels

area: NetworkingbugThe issue is a bug, or the PR is fixing a bugpriority: mediumMedium impact/importance bug

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions