I too have encountered the same behavior you're seeing, however I'm using kernel 4.9.5-200.fc25.x86_64 (Fedora Core).
My server is Windows 2008 R2 DC 7601 SP1 I've been able to capture two traces of exactly what's happening, on this kernel vs a 3.19.0 kernel from Ubuntu, if anyone is interested in looking at them. It appears that, although CIFS client is sending an echo request packet every 30 on kern 4.9 and 60 seconds on kern 3.19, if there is no other SMB traffic, the server will reset the TCP connection after a period of time. For my server, it is 900 seconds (15min). The open CIFS TCP connection, using the same port for the initial mount and echos request/responses, receives a [RST ACK] from the server after this "inactivity timeout" period. At this point, kernel 3.19 will attempt to re-connect with a [SYN], [SYN ACK], [ACK] sequence, but DOESN'T appear to actually send any more echo request packets. This connection is subsequently [RST, ACK]'d by the server after 60 seconds. This goes on for a while, but around once per minute. Kernel 4.9 tries to re-open the connection and resend it's echo request packet immediately; the server [RST, ACK]'s this packet for whatever reason, and this process repeats itself, incrementing the CIFS client source port each time (as you would expect). In my pcap dump, this happens ~1000 times per second. Attempting to access the mount results in a "server offline" or something to that effect. At this point, it appears it could be a Windows configuration issue, for why would it reset the new CIFS connection attempt? Either way, the kernel's behavior is different, evident in my dumps. I can easily duplicate this behavior on my employer's network: 1. start wireshark capture with "host a.b.c.d and port 445" 2. mount /mnt/ftp 3. get & drink coffee / bathroom & smoke break. 4. 910 seconds later, I've captured 25201 packets, although no data has been written or read from the mount point. 120 packets are exchanged up to the 905 second point. The other 25k are in the next 5 seconds until I stopped the trace. Believe it or not, my workaround is to add: */5 * * * * ls -l /mnt/ftp to my crontab, and that keeps the CIFS connection active enough to prevent this. --Luke Suchocki
