In my firewall based on nftables, I use several different log subsystem groups for packet capturing. This setup is used for a server providing access to a large number of internet clients, with each client in a separate VLAN. To expand the number of virtual networks, QinQ technology is utilized. One group captures ARP packets (in certain situations for new clients) coming from the network, for further analysis. Another group captures DHCP packets sent by clients. Also present groups for other various subsystems. These are not heavily loaded groups in terms of packet volume. In the application where this is processed, each group is handled by its own subsystem. Each subsystem creates its own thread, where the relevant group for that service is opened. Sometimes, after a restart, one group or another would fail to function. It appeared as if data was coming through the netlink socket, but when nflog_handle_packet was called, the callback would not trigger. That's when I began investigating what was wrong. вт, 30 квіт. 2024 р. о 17:46 Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> пише: > > On Tue, Apr 30, 2024 at 01:18:29PM +0300, Evgen Bendyak wrote: > > This patch addresses a bug that occurs when the nflog_open function is > > called concurrently from different threads within an application. The > > function nflog_open internally invokes nflog_open_nfnl. Within this > > function, a static global variable pkt_cb (static struct nfnl_callback > > pkt_cb) is used. This variable is assigned a pointer to a newly > > created structure (pkt_cb.data = h;) and is passed to > > nfnl_callback_register. The issue arises with concurrent execution of > > pkt_cb.data = h;, as only one of the simultaneously created > > nflog_handle structures is retained due to the callback function. > > Subsequently, the callback function __nflog_rcv_pkt is invoked for all > > the nflog_open structures, but only references one of them. > > Consequently, the callbacks registered by the end-user of the library > > through nflog_callback_register fail to trigger in sessions where the > > incorrect reference was recorded. > > This patch corrects this behavior by creating the structure locally on > > the stack for each call to nflog_open_nfnl. Since the > > nfnl_callback_register function simply copies the data into its > > internal structures, there is no need to retain pkt_cb beyond this > > point. > > Out of curiosity: How do you use this? > > There is a fanout feature to distribute packets between consumer > threads to scale up. > > And I suspect you don't want packets that belong to the same flow be > handled by different threads.
