The default firewall rules in this tool block NMB traffic, which prevents Windows Network Neighbourhood browsing from working correctly. The best fix is not the proposed patch, but this is the best that can be done in the short term. Given that the most likely effect of this problem is users disabling the firewall entirely, I think it should be applied.
Created attachment 99360 [details] A "cannonball" approach: Enable all incoming traffic on UDP port 137.
notting: opinion?
Eek, a SMB/NMB checkbox is better.
That's fine, as long as it's not blocked by default. I'd guess most users could not link "nothing appears in windows network browsing" to "NMB is checked in the firewall config program".
Mike: When you enable the firewall, all ports and services are blocked by default. The user has to intentionally select those checkboxes to open those ports. Being "secure by default" has its advantages even if it means losing a bit of convenience out of the box.
Alright, I understand that. In that case there needs to be some ultra-clear way of letting the user know that the reason they are seeing nothing in the NetHood is because of the firewall. At the moment it silently fails, which is really bad. Unfortunately code which accesses the SMB network is all over the place. For instance, in gnome-vfs, in system-config-printer, and so on. So it's probably better to add a checkbox and warn the user inside system-config-securitylevel that if this box is checked they won't be able to browse windows networks.
Created attachment 99431 [details] patch to lokkit to create an SMB checkbox notting: This is a patch to add a SMB checkbox to lokkit. Can you take a look at it and see if it's sane? If this is ok, I'll add a SMB checkbox to the s-c-securitylevel GUI.
a) you probably need more than just TCP b) ideally, the kernel's stateful firewall would catch this c) this unintentionally opens up any local SMB server for general access.
notting: what would be a better way?
Technically, this is a dup of #58004, one way or another. The kernel fix is the 'preferred' one, but that may take a while.
*** This bug has been marked as a duplicate of 58004 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.