Re: SNMP conntrack module a la netbios_ns

[Patrick McHardy <kaber@trash.net>]

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.