Score:2

Server

DHCP unicast packets processing in Linux

Volodymyr Litovka

8/25/24, 1:54 AM

I'm trying to catch and process (in 3rd party analytics app) DHCP packets from ERSPAN session, but cannot do this. There is PHY interface which receive ERSPAN traffic and erspan-type interface to get decapsulated packets (ip link add inspan type erspan seq key 10 local 10.171.165.65 erspan_ver 1)

I'm using nftables to match and handle and the easiest rule:

table netdev inspan {
  chain catch {
    type filter hook ingress device "inspan" priority filter ; policy accept;
    iifname "inspan" udp dport 67 counter meta nftrace set 1 accept
  }
}

shows ONLY broadcast packets (ip daddr 255.255.255.255):

# nft monitor trace

trace id 6fd1132b inet filter input packet: iif "inspan" ether saddr 00:1a:64:33:8d:fa ether daddr ff:ff:ff:ff:ff:ff ip saddr 0.0.0.0 ip daddr 255.255.255.255 ip dscp cs0 ip ecn not-ect ip ttl 128 ip id 20986 ip protocol udp ip length 328 udp sport 68 udp dport 67 udp length 308 @th,64,96 0x1010600d5d272d200000000
trace id 6fd1132b inet filter input rule iifname "inspan" udp dport 67 counter packets 0 bytes 0 meta nftrace set 1 accept (verdict accept)

while ALL unicast packets (being present in encapsulated ERSPAN-traffic on PHY) are missing in this trace like they consumed (and dropped) somewhere between PHY and inspan.

Note that EVERYTHING ELSE appear in the inspan (when looking using tcpdump) - any other TCP, UDP, etc, EXCEPT DHCP uincast and it does not depend on promisc settings of all interfaces in the chain.

The system looks to be clean. This is Ubuntu 22.04, but without any DHCP server, DHCP clients as well, netplan, ifupdown and other DHCP-related stuff; systemd-networkd completely disabled (for the test purposes I'm configuring networking manually).

Any ideas where unicast DHCP packets lost? For me, it looks like something in kernel catch these packets and drop them since they aren't targeted for this host.

Thank you.

0 + 8

networking

dhcp

nftables

A.B

8/25/24, 5:21 PM

Can you capture these missing packets using tcpdump *with* option `-p`?, to be sure it's an nftables problem and not something else (such as non-promisc interface)? Also, since ARP would be part of this (eg: the server sending ARP to check the lease isn't squatted etc.) it might be useful to capture in the netdev family instead of the inet family.

Volodymyr Litovka

8/26/24, 12:36 PM

This don't look nftables issue. I don't see these packets even in tcpdump on 'inspan' interface (decapsulated), regardless of promisc mode on 'inspan' interface. While the command (on PHY enp2s0) ` tcpdump -s0 -w- -i enp2s0 'proto gre and ether[73:1]=17 and (ether[84:2]=67 or ether[84:2]=68)' | tshark -r- -l ` (upd and src port 67 or 68) shows me lot of DHCP traffic (both unicast and broadcast), the command ` tcpdump -i inspan -p 'port 67 or port 68' ` shows me just broadcast packets. Unicast dropped somewhere in the middle.

A.B

8/26/24, 12:39 PM

Can you try putting the parent interface in promisc mode? If you intend to capture frames not targetting the NIC, that's what is usually required. Note that your 1st tcpdump uses promisc mode (no -p).

Volodymyr Litovka

8/26/24, 12:58 PM

3: enp2s0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 7: inspan@NONE: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UNKNOWN group default qlen 1000 Doesn't help - regardless of promisc mode on either phy and inspan.

A.B

8/26/24, 1:01 PM

I guess no difference? You should edit your question with this additional piece of information. Sorry, no idea left.

Volodymyr Litovka

8/26/24, 1:01 PM

I just want to add, that everything else reach inspan interface - TCP, UDP, whatever - there are about 11k packets during 10 seconds. I don't see exactly DHCP unicast packets. Like something in KERNEL handles BOOTP/DHCP packets and drops them (since they aren't for this host).

Tom Yan

8/26/24, 1:23 PM

Does it make any difference if you don't enslave inspan to a bridge (br0)? Or does it if you try to capture at the bridge?

Volodymyr Litovka

8/26/24, 1:31 PM

Regardless of whether I add or don't inspan to br0, behavior do not change. If inspan bridged into br0, then same picture on the br0 - ALL traffic is here, except DHCP unicast.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: DHCP unicast packets processing in Linux

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.