[netfilter-devel is the correct list for development questions, CCed] Tim Waugh wrote: > I maintain the printing stack for Fedora and Red Hat Enterprise Linux, > and I've become aware of a need for another conntrack module very > similar to nf_conntrack_netbios_ns. > > When CUPS searches for network printers it issues an SNMP broadcast > query from a random source port and to the SNMP destination port, and > waits for (unicast) replies from printers, following up each reply with > a set of unicast SNMP queries. > > The problem is that the iptables rules discard the replies to the > initial broadcast query. > > It looks like a conntrack module is what's needed to fix the problem, > and the netbios_ns module very nearly solves it: the only changes I can > see would be needed are the port number and the maximum number of > expected replies. Yes, I think Samir Bellabes mentioned this as well back when I added that module. > Is this something that warrants a more generic module so that code can > be shared between them, or would it be better to just copy the code and > make the changes? The best solution would be to add generic broadcast tracking, the use of expectations for this is a bit of abuse. The second best choice I guess would be to move the help() function to a shared module and generalize it so it can be used for both. Basically I think it would come down to changing: exp->tuple.dst.u.udp.port = htons(NMBD_PORT); to: struct nf_conn_help *help = nfct_help(ct); ... exp->tuple.dst.u.udp.port = help->helper->tuple.src.u.udp.port; -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
