Patrick McHardy wrote: > [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; There is one problem however, we already have the SNMP NAT helper, which also registers for the SNMP port. Those would clash if you add a second registration. -- 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
