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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
