SNMP conntrack module a la netbios_ns

SNMP conntrack module a la netbios_ns

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]

Hi,

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.

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?

Thanks,
Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: SNMP conntrack module a la netbios_ns

[Patrick McHardy]

[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;

Re: SNMP conntrack module a la netbios_ns

[Patrick McHardy]

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.