On Tue, Dec 07, 2010 at 09:50:22AM +0000, Tim Waugh wrote:
On Mon, 2010-12-06 at 21:50 +0000, Richard W.M. Jones wrote:
> Still not seeing how /etc/iptables.d wouldn't work ...
Here is how:
When I ask CUPS for a list of network printers, it runs the backends
in /usr/lib/cups/backend. One of those is /usr/lib/cups/backend/snmp,
which:
a) binds to a local unprivileged UDP port
b) sends a broadcast SNMP request
c) listens for (unicast) responses to that request
We don't hear any of those responses because they are not recognised as
"related" by the kernel. The iptables rules drop them.
If the CUPS snmp backend could say to "the firewall", "hey, please allow
responses on this port I've got for the next few seconds" -- which can
be controlled using PolicyKit -- then this network discovery would
finally work.
There's no way to know the local UDP port in advance
so /etc/iptables.d-like systems all fail here.
Does firewalld solve this? Surely a solution to this is going to have
to live in a stateful extension to iptables in the kernel, or a fix to
the 'related' packets function?
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top