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.

Re: SNMP conntrack module a la netbios_ns

[Tim Waugh]

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

On Fri, 2009-12-04 at 11:22 +0100, Patrick McHardy wrote:
> 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.

Does that mean that even a simple copy of nf_conntrack_netbios_ns.c with
the port changed to 161 wouldn't work, or just that a more general
solution would be hard to implement?

What's the solution to that?  Must there be a single conntrack module to
handle both the SNMP broadcast queries and SNMP NAT?

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]

Tim Waugh wrote:
> On Fri, 2009-12-04 at 11:22 +0100, Patrick McHardy wrote:
>> 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.
> 
> Does that mean that even a simple copy of nf_conntrack_netbios_ns.c with
> the port changed to 161 wouldn't work, or just that a more general
> solution would be hard to implement?
> 
> What's the solution to that?  Must there be a single conntrack module to
> handle both the SNMP broadcast queries and SNMP NAT?

Correct, its not valid to have two helpers registered for the
same tuple. The SNMP NAT helper is an exception among the helpers
in that it doesn't register any expectations, but only rewrites
packets. What you'd need to do is change it to not register a
helper itself, but have your new module pass packets to the NAT
module in case its loaded, just as the other conntrack helpers do.

But as I said, the better way is to add generic broadcast tracking.
It shouldn't be that much more work and I'm not sure I really want
to add more workarounds like the netbios_ns helper since we'll have
to deal with compatibility problems once we do add broadcast tracking.