Excessive "Are you there" probes

opensuse 42.2
linux 4.4.74-18.20-default x86_64

There 6 remotely mounted volumes on a workstation, 4 NFS, 2 SMB. The connection for each volume is tested once every two (2) seconds. This seems ridiculously excessive.

I have unmounted the SMB volumes. It reduced the probes (observed by Wireshark) to only the NFS volumes. The reverse is true: unmounting the NFS volumes shows only probes for the SMB volumes. Which indicates the probes are initiated by the workstation, not the remote hosts.

Where would I find what controls how often remote volumes are tested for existence?

In your server’s smb.conf,

Do you have a keepalive setting in the “global” section?
If you see that, the value is in seconds. The default should be 300.

You can modify however you wish.

TSU

There is no “keepalive” statement in <smb.conf>.

The issue is a level above SMB (and NFS) anyway, at a more abstract network level. When the SMB volumes are unmounted, the probes continue on the NFS volumes. When the NFS volumes are unmounted, the probes continue on the SMB volumes.

Recommend reading the smb.conf documentation, an online copy is at
https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html

From what it seems to say,
If the SO_KEEPALIVE setting exists in your smb.conf, then the other setting I mentioned isn’t used. This is the “better” setting that seems to support both SMBv1 and SMBv2.
https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#SOCKETOPTIONS

If the above setting either does not exist or exists and is set to a value of zero, then it is disabled and then the setting I mentioned can be set, but it also supports only SMBv1
https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#keepalive

TSU

READ MY POSTS!

AFAICT the issue is NOT a samba issue. It also affects NFS volumes.

It appears to be some aspect of filesystems control. If I unmount all of the remote volumes, the probes disappear (no trace in Wireshark). If only NFS volumes are mounted, those receive the probes, If only the SMB volumes are mounted, those receive the probes. If both are mounted, both receive the probes.

OK,
I’m having some problems working with your unusual terminology, “probes” is not a typical way to properly describe what you should be experiencing, keepalives are what are implemented to maintain connectivity.
Your description about seeing them when shares are mounted only (and not seen when unmouted) has only limited value because keepalives might be expected for each type of network share.

If you’re captured and inspected packets using Wireshark, then what does Wireshark say about these “probes?”
How does Wireshark classify these packets?
Have you inspected the payloads for any clues?
Is there a pattern and is there any other traffic which might be related to your “probe” traffic?

If you don’t know what to look for in a packet analysis, you can post a screenshot or relevant logs to a pastebin and post the link here.

TSU

Request packet first, reply packet second.
[FONT=courier new]protocol    description
NFS         GETATTR
NFS         GETATTR FH: 0xnnnnnn

SMB         Trans2 Request, QUERY_FS_INFO Umknown (0x210)
SMB         Trans2 Response, QUERY_FS_INFO

[/FONT]The NFS packet pair occurs for each NFS volume; there are 4.
The SMB packet pair occurs for each SMB volume; there are 2.
FH = file handle? The same number repeats for each volume.

Have you inspected the payloads for any clues?

Yes. The packets are small, about 200 bytes. There is no textual information. There are probably flags and bit values; I do not know how to read them.

Is there a pattern and is there any other traffic which might be related to your “probe” traffic?

Yes, there is a pattern. The above keepalives (aka: probes), 6 pairs of packets, occur every two seconds.
No, there is no other regular traffic associated with these packets.

Generally when people ask for packet captures, you should post the raw data, either the complete capture or very carefully removing what you know cannot be relevant. And, additional packet data might provide context to the packet streams.

It’s unlikely that anyone can offer any new insight into a couple lines,
There is a chance someone might look at the raw data and see something new.

By a screen capture, I also would have meant displaying a Wireshark display which might show a fair amoun of info although would duffer from not being interactive.

TSU

Two files; a png and a PCAP.
<https://www.dropbox.com/sh/b6t28azor5x6swv/AACwEycyRdj5I27KDkztVZ1aa?dl=0>

I don’t find this excessive. AFAIK network filesystems need to be checked for their existence all the time.

I don’t find this excessive. AFAIK network filesystems need to be checked for their existence all the time.

None of the other workstations (2 of them) indulge such frequent updates. In fact none of the other systems use those packet types; they use an “Echo” or “Renew” request once a minute.