Comment # 39 on bug 1209457 from St���phane DESNEUX

Hi,

As Neil asked, I captured the traffic for showmount/mount/ls/umount with
different configs.

I made a first test (namely "Test 1" in attachments) between two Leap 15.4
hosts and captured the traffic with wireshark on server side (see attached
tarball).

I confirm that I'm able to showmount/mount with kernel .55.3 between the two
machines (the client is on .55.3, the server is on .46.1). But, with .55.3 on
the client side, the commands are less "reactive". Studying the captures may
help, as they seem different.

This confirms the comment #36 by Peter Varga, but... I tested the same commands
with my old QNAP NAS which has not been updated recently and used to work like
a charm for the past 10 years... and it still fails.

First result with the QNAP NAS:
- showmount works
- mount fails (blocking forever, no error in kernel messages)

I'll redo the same tests with my QNAP NAS instead of the Leap 15.4 Server and
post the results and captures here.

NB: I noticed a strange behavior: usually, when a NFS resource is not
available, all accesses are blocked. But after a "short" timeout (30s maybe),
the blocking calls are unblocked and everything "fails correctly". In the
current case, the mount operation and all accesses to the mounted folder are
blocked forever (or with a very high timeout, that I never reached = more than
10mn at least). This is really an unexpected behavior and it has really nasty
side effects :\ like a gnome session not really starting: the gnome-shell
process can be blocked for any reason due to an access to the mounted folder =>
black screen with a single mouse pointer on it... My wife who is not a Linux
expert had the issue just after an automatic update on her Leap 15.4 laptop...
and asked me for tech support. I hope that not all laptop users with a QNAP NAS
will have the same experience and that we're on a corner case!