I'm trying to debug why I'm unable to mount an NFS share on a server from a linux client. After much testing around NFS server and being able to mount it locally in the same machine I've started trying to see if it is a networking problem and what I am seeing has me a bit baffled. There is no firewall running on the server and I have a bunch of other services (HTTP/S, DLNA, Mosquitto...) running flawlessly both from my internal network and from the internet in the same server. I have made a tcptraceroute from the client to the server on port 2049 and the server answers properly. I have even tried a pure telnet from client to server on port 2049 while listening with tshark at both ends and I see the proper TCP SYN, SYN,ACK sequence being established at both ends, but when I try to mount the NFS shares from the client I see the TCP SYN coming out the client machine and nothing coming in on tshark on the server machine. It is like the TCP SYN packet never arrives to the server! This is what I see on the client (.3) tshark window:
1 0.000000000 192.168.1.3 → 192.168.1.2 TCP 74 758 → 2049 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=2121012438 TSecr=0 WS=128
2 1.007908102 192.168.1.3 → 192.168.1.2 TCP 74 [TCP Retransmission] 758 → 2049 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=2121013446 TSecr=0 WS=128
3 3.024014290 192.168.1.3 → 192.168.1.2 TCP 74 [TCP Retransmission] 758 → 2049 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=2121015462 TSecr=0 WS=128
and nothing showing on the server (.2), while a pure tcptraceroute on the client shows:
tcptraceroute 192.168.1.2 2049
Selected device enx9cebe8fc1358, address 192.168.1.3, port 47199 for outgoing packets
Tracing the path to 192.168.1.2 on TCP port 2049 (nfs), 30 hops max
1 192.168.1.2 [open] 0.501 ms 0.441 ms 0.493 ms
Tshark output:
1 0.000000000 192.168.1.3 → 192.168.1.2 TCP 54 57737 → 2049 [SYN] Seq=0 Win=0 Len=0
2 0.000455085 192.168.1.2 → 192.168.1.3 TCP 60 2049 → 57737 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460
3 0.000495873 192.168.1.3 → 192.168.1.2 TCP 54 57737 → 2049 [RST] Seq=1 Win=0 Len=0
4 0.006264763 192.168.1.3 → 192.168.1.2 TCP 54 [TCP Retransmission] 57737 → 2049 [SYN] Seq=0 Win=0 Len=0
5 0.006690795 192.168.1.2 → 192.168.1.3 TCP 60 [TCP Previous segment not captured] [TCP Port numbers reused] 2049 → 57737 [SYN, ACK] Seq=97837 Ack=1 Win=64240 Len=0 MSS=1460
6 0.006737449 192.168.1.3 → 192.168.1.2 TCP 54 57737 → 2049 [RST] Seq=1 Win=0 Len=0
7 0.022031295 192.168.1.3 → 192.168.1.2 TCP 54 [TCP Retransmission] 57737 → 2049 [SYN] Seq=0 Win=0 Len=0
8 0.022406482 192.168.1.2 → 192.168.1.3 TCP 60 [TCP Previous segment not captured] [TCP Port numbers reused] 2049 → 57737 [SYN, ACK] Seq=343671 Ack=1 Win=64240 Len=0 MSS=1460
9 0.022447549 192.168.1.3 → 192.168.1.2 TCP 54 57737 → 2049 [RST] Seq=1 Win=0 Len=0
I'm out of ideas here, so any suggestions are welcomed. I don't think it is the NFS server since tshark does not show any packet arriving to the server on port 2049 that I can see on any interface... Could if be that the server kernel discards the packets before being shown in tshark for some reason? Does the NFS-kernel-server discard the packets before allowing tshark to see them? Could that be possible?
Well, thanks for all the wild possible ideas!
/Nacho
