Samba: remote Win XP and Mac OS X machines can no longer mount shares

[Patrick Goetz]

Binary package hint: samba

Distro: Ubuntu Lucid Alpha 3
Package: samba 2:3.4.5~dfsg-2ubuntu3

I've been holding off on reporting this as a bug for several days, but simply am not able to make any more progress. Previously we were running Samba 3.0.2 on a Debian machine behind a firewall which redirects Port 445 traffic to the samba (PDC) server. Authenticated Win XP, Mac OS X, and linux users outside the firewall were all able to mount CIFS shares from the samba server.

Recently I upgraded to Lucid/Samba 3.4.5. Nothing else was changed, and the smb.conf is roughly the same as before. (Let me note that I went through the package maintainer's smb.conf file with a fine-toothed comb, read the smb.conf man page completely twice, and ran testparm to make sure everything in the smb.conf file was OK.) Everything inside the firewall works as before. From outside, Win XP and Mac OS X users are no longer able to mount shares; *however* linux hosts have no problems. Using Wireshark, I did a packet trace of an unsuccessful mount attempt from a Win XP machine outside the firewall to and from the Samba server and a successful mount on a linux machine outside the firewall. The .pcap files are attached.

As far as I can tell, the Samba server is simply not responding to the Win XP TCP SYN request, but is responding to the linux machines TCP SYN request. The Wireshark packet summary differences are listed below. The server IP address is 216.110.51.120:

From Windows XP:
192.168.1.64 216.110.51.120 TCP 4617 > microsoft-ds [SYN] Seq=0 Win=65535 Len=0 MSS=1360
(server never responds to this)

From linux:
128.83.133.100 216.110.51.120 TCP 42098 > microsoft-ds [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=347894238 TSER=0 WS=7
(server immediately responds to this)

Let me note again that we never had any problems with Samba 3.0.2, same Win XP/Mac OS X clients. I'm not including the smb.conf file, because I assume this information is irrelevant: everything works on the local network and for linux hosts being redirected through the firewall. Unfortunately, all the actual users have Win XP and/or Mac OS X machines, hence: problem.

[Thierry Carrez (ttx)]

Looks like a networking issue more than a samba issue... as samba is probably not involved in deciding to ACK a specific SYN packet or not. One difference between your Windows XP and your Linux hosts is the IP address (192.168.1.64 in one case, 128.83.133.100 in the other): are both of those networks routable from 216.110.51.120 ? If yes, could you place a Linux system in that 192.168.1.0/24 network and reproduce the trace ?

AFAICT it looks like the Lucid server TCP queue considers the 192.168.1.64 packet a martian and just discards it. Anything in your kernel logs ? Do other TCP-based services on that Lucid host succeed in talking with the Windows XP host ?

[Patrick Goetz (pgoetz)]

Thierry, as usual, thanks for your rapid response/attention to these issues.

Good suggestion; I will try using a linux machine to connect from 192.168.1.x, which is my home network. First, let me point out that Win XP and Mac OS X machines on various networks have been unable to connect to the Samba server -- I only tested linux from one location, but will try your suggestion this weekend.

128.83.133.100 is routable from 216.110.51.120, but 192.168.1.64 is not, as this is a private network using NAT. The external address for 192.168.1.64 is 99.91.6.24, and this is routable from 216.110.51.120. Using an ssh proxy on the firewall for the Samba server (i.e. using iptables to route port 2222 on the firewall to port 22 on the samba server), I can ssh from the Win XP machine directly to the Samba server, and using a windows SSH FS tool called ExpanDrive, can map and use drives over ssh; i.e. other TCP/IP protocols do work from the (firewalled) 192.168.1.64 Windows desktop to the (firewalled) Samba server.

Re: server logs:
The only thing in the server logs regarding 99.91.6.24 are the ssh connections:
root@data:/var/log# rgrep '99.91.6.24' *
auth.log:Mar 3 21:07:10 data sshd[26848]: Accepted password for pgoetz from 99.91.6.24 port 1085 ssh2
auth.log:Mar 3 21:21:51 data sshd[26920]: Accepted password for pgoetz from 99.91.6.24 port 1118 ssh2
(etc. -- several ssh connections listed)

Note that the new Samba server keeps track of all connection attempts (mostly unfriendly probes) and creates individual log files for them:
  log.__ffff_82.64.100.254 (attempted hack)
  log.ea103 (legitimate internal desktop)
  log.lizard (linux desktop used for testing)
  (etc.)

Log files exist even for failed connection attempts, but none exists for 99.91.6.24.

[Patrick Goetz (pgoetz)]

"could you place a Linux system in that 192.168.1.0/24 network and reproduce the trace?"

Good call, Thierry! I was certain that the linux machine would be able to connect from 192.168.1.0/24, but was shocked to discover that it doesn't. A trace of the packets shows the same lack of response from the SMB server. This lead to a few more tests indicating that the problem must be that the ISP is blocking incoming port 445 traffic.

Normally I would have suspected this, but in this case I have Windows XP users on another subnet for which this was working right up until the day of the system upgrade, and didn't work subsequently. Since (presumably) nothing changed on their end during this 3-day period; i.e. no new ISP, no new firewall, same Windows XP machines, I assumed the problem must be with the server. Since I've subsequently been able to mount shares from a Windows XP machine on a different subnet, this can't be the problem. I still don't have an explanation for why the TCP SMB connection was working for the actual Win XP users prior to the upgrade from Debian to Lucid, but not after.

Please mark this bug as "Invalid" with my humble apologies!! I plan not to be fooled by this trick again.

[Mathias Gug (mathiaz)]

Marking invalid as requested by the bug reporter.