Hoi,
I think I figured it out, it has to do with the move of tap to a plugin.
CC Damjan to check my analysis
Before cb19c526d, lcp_interface.c correctly reassigned hw after
tap_create_if(). It needed vif->ifindex to get the tap's Linux ifindex
(because the old code accessed virtio_main directly, and vif_index =
vif->ifindex).
When tap was moved to a plugin (cb19c526d), the virtio_main coupling was
removed and tap_get_ifindex() was introduced as the new API. Damjan
refactored Linux CP to use tap_get_ifindex() and dropped the hw
reassignment:
- /*
- * get the hw and ethernet of the tap
- */
- *hw = vnet_get_sup_hw_interface (vnm, args.sw_if_index);*
- virtio_main_t *mm = &virtio_main;
- virtio_if_t *vif = pool_elt_at_index (mm->interfaces,
hw->dev_instance);
-
/*
* Leave the TAP permanently up on the VPP side.
* This TAP will be shared by many sub-interface.
@@ -1089,7 +1078,7 @@ lcp_itf_pair_create (u32 phy_sw_if_index, u8
*host_if_name,
ei = pool_elt_at_index (ethernet_main.interfaces,
*hw->hw_instance*);
ei->flags |= ETHERNET_INTERFACE_FLAG_STATUS_L3;
}
- vif_index = vif->ifindex;
+ vif_index = tap_get_ifindex (vm, args.sw_if_index);
Damjan, I'm assuming you overlooked that the new hw from the TAP
interface was still needed for the hw->hw_instance lookup to set
STATUS_L3 (in bold). I think the gerrit is good to go.
groet,
Pim
On 05.03.2026 16:56, Pim van Pelt via lists.fd.io wrote:
Hoi folks,
I was playing around with af-packet and creating LCP pairs with them.
I noticed a bunch of errors with 'l3 mac mismatch' while multicast
worked, unicast did not.
I saw commits 1412d24ba and 3e00a101be but they are innocent, rolling
them back in my build would not fix the situation.
I realized that linux-cp has a bug in lcp_interface.c:
- After tap_create_if() on L1064, hw still points to the PHY's HW
interface from L841.
- The STATUS_L3 flag ends up on the PHY (in my case the AF_PACKET
interface), not on tapXXXX. Linux sends unicast with the peer's real
MAC, which mismatches the tap's synthetic 02:fe:... mac address and
thus gets dropped. Multicast is allowed to bypass DMAC checks, and
thus multicast works.
The fix seems simple - look up a new hw from the args.sw_if_index (the
TAP) and set the flag on that one. Considering how long we've had
Linux CP and no changes around the TAP creation that I could see, am I
perhaps misreading this?
https://gerrit.fd.io/r/c/vpp/+/45103 is a fix. Without it,
containerlab created eth1/eth2/ethN af-packet interfaces, but the
corresponding tap4096/tap4097/tap4098 were not in promiscuous mode.
With the gerrit, containerlab works and the TAPs are in promiscuous mode.
Please take a look.
--
Pim van Pelt<[email protected]>
PBVP1-RIPEhttps://ipng.ch/
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#26868): https://lists.fd.io/g/vpp-dev/message/26868
Mute This Topic: https://lists.fd.io/mt/118163322/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
