Bug 1038959

So the obvious smoking gun I see in the wireshark output: in every failure log I've seen, there is an attempt by the client (machine trying to browse) to ping (ICMP) a server that just responded to its NBNS broadcast query, and that ping failing. In the success log, I see neither a successful nor a failed ping. See packet #5 in the 'samba-client service allowed' log.

Created attachment 833479 [details]
stock.pcapng: wireshark capture of 'smbtree -N' attempt with completely stock settings

Created attachment 833480 [details]
samba-client.pcapng: wireshark capture of 'smbtree -N' attempt with 'samba-client' service allowed in firewalld config

Created attachment 833481 [details]
trusted.pcapng: wireshark capture of 'smbtree -N' attempt with interface in trusted zone

well, maybe it's not just a ping at that. I'm no expert at reading wireshark captures, but it looks like the ICMP packet has an NBNS packet inside it.

Ah, OK, I think I grok it better now. Compare packet #5 in 'samba-client' and #12 in 'trusted'. I think they're the same packet - some kind of NBNS setup stuff - getting incorrectly blocked in 'samba-client'. wireshark's identification of it as 'ICMP' in 'samba-client' is a result of it being blocked.

It looks like the packet is rejected as "Host administratively prohibited". I guess that lines up with the rules at the end of the INPUT and FORWARD chains of firewalld's iptables config:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
INPUT_direct  all  --  anywhere             anywhere            
INPUT_ZONES_SOURCE  all  --  anywhere             anywhere            
INPUT_ZONES  all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
FORWARD_direct  all  --  anywhere             anywhere            
FORWARD_IN_ZONES_SOURCE  all  --  anywhere             anywhere            
FORWARD_IN_ZONES  all  --  anywhere             anywhere            
FORWARD_OUT_ZONES_SOURCE  all  --  anywhere             anywhere            
FORWARD_OUT_ZONES  all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

those are the only "reject-with icmp-host-prohibited" rules I see in iptables...

My guess is that there's some problem with the NetBIOS name service broadcast connection tracking helper - nf_conntrack_netbios_ns.

Adam, could you make sure it's loaded (lsmod | grep nf_conntrack_netbios_ns)
when you enable the samba-client service ?

The module appears to be loaded on boot - when I boot a live image it's loaded already. I don't see any kind of change in its status when I check/uncheck samba-client in firewall-config.

Hi, 

From https://sourceforge.net/p/smb4k/wiki/TroubleShooting_EmptyBrowser/

Open Ports in Your Firewall

Open the ports 137 (TCP+UDP), 138 (UDP), 139 (TCP+UDP), and 445 (TCP
+UDP) in your firewall.

firewalld config don't have a couple of this rules from samba or
samba-client , I add some ports and protocols  in service samba
like 137 TCP 139 UDP 445 UDP , but no luck ...

after go to here: http://www.novell.com/coolsolutions/feature/11952.html
 
Set the firewall to allow ICMP (Internet Control Message Protocol) with following types.

    0 (Echo request)
    8 (Echo Reply)
    3 (Destination unreachable)(This one is optional but useful)

Allow Traffic for the Windows network by opening the following ports for SMB both TCP and UDP

Port Number Traffic Type
445 Microsoft-DS
135 DCE endpoint resolution
136
137 NETBIOS Name Service
138 NETBIOS Datagram Service
139 NETBIOS session service

but still just works with "trusted" zone 

lsmod | grep nf_conntrack_netbios_ns
nf_conntrack_netbios_ns    12665  0 
nf_conntrack_broadcast    12527  1 nf_conntrack_netbios_ns
nf_conntrack           86430  11 nf_conntrack_netbios_ns,ipt_MASQUERADE,nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,ip6table_nat,nf_conntrack_broadcast,iptable_nat,nf_conntrack_ipv4,nf_conntrack_ipv6

The problem unless trusted zone , firewall blocks here :
11	13.536262000	10.0.2.15	192.168.1.253	ICMP	132	Destination unreachable (Host administratively prohibited)

I can I unblock it ?

The problem is firewall blocks here :
11	13.536262000	10.0.2.15	192.168.1.253	ICMP	132	Destination unreachable (Host administratively prohibited)

just don't block in "trusted" zone

How I can unblock it ? for other zone

Thomas: is there anything more I can do to help with this? It seems like a significant bug and I was kinda happy to finally trace it out to some extent, I was hoping we could get it fixed fairly soon (for F20 final ideally, but I think that ship has sailed). Thanks!

So, we poked at this quite a bit in IRC today.

We're not to the bottom of it yet, but it's not totally straightforward. This seems to be specific to F20, in some way.

If I boot an F19 live image on a clean test system and run 'smbtree -N' - absolutely no configuration of anything required, not even the 'samba-client' firewalld service - I see my servers fine.

If I boot an F20 RC1 live image on the same system, same servers, same everything, and try the same thing, I see nothing.

Adding the network interface to the 'trusted' zone works fine every time, so it's definitely the firewall causing problems, but it's not as straightforward as some firewalld config being wrong. Right now we suspect that nf_conntrack_netbios_ns is behaving differently in F19 and F20 somehow...

Adding a rule to accept all from souce port 137/udp makes it work again, but this is not a good solution.

(In reply to Adam Williamson from comment #13)
> So, we poked at this quite a bit in IRC today.
> 
> We're not to the bottom of it yet, but it's not totally straightforward.
> This seems to be specific to F20, in some way.
> 
> If I boot an F19 live image on a clean test system and run 'smbtree -N' -
> absolutely no configuration of anything required, not even the
> 'samba-client' firewalld service - I see my servers fine.
> 
> If I boot an F20 RC1 live image on the same system, same servers, same
> everything, and try the same thing, I see nothing.
> 
> Adding the network interface to the 'trusted' zone works fine every time, so
> it's definitely the firewall causing problems, but it's not as
> straightforward as some firewalld config being wrong. Right now we suspect
> that nf_conntrack_netbios_ns is behaving differently in F19 and F20
> somehow...

When you booted your "F19 live image", was that the original F19 GA live image?  Because that has a different kernel (much older) kernel than F20.

At this point F19 and F20 are on virtually identical kernels, so figuring out if this also impacts an updated F19 would be good.  If it doesn't it's likely something elsewhere that changed between F19 and F20.

If the kernel version does matter, then you can upgrade kernel major versions to see where the suspected change came in at.  Though looking at the git tree, there hasn't been a change to net/netfilter/nf_conntrack_netbios_ns.c since 2011 (2.6.39) so I'm not sure that's really the culprit.

Adding Neil, Jiri, and Jeff to CC.

Thomas mentioned on IRC that 3.12 from koji is working fine on F19.  He's going to try the F20 kernel on F19 as well.

Thomas mentioned the F20 kernel on F19 works as well.  This is looking like an issue in something other than the kernel.

jwb: when I tested a 19 live image it was GA, yeah, but a fully updated 19 install running 3.11.10-200.fc19 behaves the same (i.e. works). I'd tend to agree that as of now it doesn't look like the issue is in the kernel.

As this is actually a new bug in F20 and we didn't figure out a fix yet, we should document this...

I tested this in RHEL 7 public beta too, just for the heck of it. Bug seems to exist there too, nothing from 'smbtree -N' with OOTB config or 'samba-client' enabled, works if I stop firewalld.service (couldn't test putting it in 'restricted' zone easily because it seems incredibly RAM hungry, and when I boot it to GNOME the VM exhausts all RAM and freezes after like 2 minutes). Not sure how important this is to RHEL.

(In reply to Thomas Woerner from comment #14)
> Adding a rule to accept all from souce port 137/udp makes it work again, but
> this is not a good solution.
Not sure why you are claiming it is not a good solution since it is a requirement: NetBT browsing requires 137/udp connectivity by design since 137/udp is the port used for name services in NetBIOS over TCP/IP.

See this TechNet article for more details:
http://technet.microsoft.com/en-us/library/cc940063.aspx

*** Bug 1023918 has been marked as a duplicate of this bug. ***

Samba browsing with Nautilus is working again for me since one week.

I have verified this a bit more.

On a machine, where it is working, the incoming packets from port 137 are accepted with the RELATED,ESTABLISHED line in the firewall. On a system, where is not working the packet is not accepted by this line.

The firewall configuration is the same on both machines.

This is not a firewalld issue. It seems to be a problem somewhere in netfilter (kernel).

Reassigning to kernel.

With the latest updates in F-20 (including kernel 3.12.6-300) samba browsing is working now as expected. There has not been an update of iptables or firewalld.

This was a bug in NetworkManager. The broadcast address of the interfaces has been set to 0.0.0.0.
Using the latest NetworkManager update or fixing the broadcast address manually fixes the problem.

Reassigning to NetworkManager. Closing as duplicate for 1032819.

*** This bug has been marked as a duplicate of bug 1032819 ***