RE: conntrackd user-space helpers for multicast/broadcast

> -----Original Message-----
> From: Pablo Neira Ayuso <[email protected]>
> Sent: Wednesday, 12 November 2025 5:45 pm
> To: Joel Low <[email protected]>
> Cc: [email protected]
> Subject: Re: conntrackd user-space helpers for multicast/broadcast
> 
> On Sun, Nov 09, 2025 at 11:46:00PM +0000, Joel Low wrote:
> > Hi Pablo,
> >
> > > -----Original Message-----
> > > From: Pablo Neira Ayuso <[email protected]>
> > > Sent: Monday, 10 November 2025 2:21 am
> > > To: Joel Low <[email protected]>
> > > Cc: [email protected]
> > > Subject: Re: conntrackd user-space helpers for multicast/broadcast
> > >
> > > Hi,
> > >
> > > Are you using the br_netfilter module in your setup?
> >
> > I don't think so; `lsmod | grep br_` returns nothing on that host.
> 
> And no built-in CONFIG_BRIDGE_NETFILTER=y?
> 
> It should be possible to fix this by dropping the conntrack in the queue path,
> then nfqnl_ct_parse() performs a ct lookup from the reinject path.

From what I can tell, CONFIG_BRIDGE_NETFILTER=m, and the module is not loaded in my setup.

My apologies that I can't completely understand what you're suggesting I do; I've been trying to feel my way around the codebase to best isolate the problem. Is there some documentation or code you can point me to reference or as a starting point please? My best guess of your suggestion is to mark the flow as `notrack`, but subsequently reinject the multicast packet? My attempts with notrack seem to suggest that the entire helper assignment and processing is completely bypassed and thus I'm pretty sure I'm misunderstanding your suggestion.