-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Sun, 14 Jul 2013 17:29:21 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> пишет:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday, 2013-07-14 at 12:09 +0400, Andrey Borzenkov wrote:
В Thu, 11 Jul 2013 14:54:52 +0200 (CEST) "Carlos E. R." <> пишет:
Right, see above.
By default client should negotiate NFS version, depending on which one is supported by server. So leaving explicit version will result in different behavior depending on what client/server combination support. As NFS V3 and NFS V4 have completely different models for sharing and user mappings you usually cannot simply drop in NFS V4 in place of NFS V3 and expect it to work.
Look:
eleanor3:~ # mount | grep nfs rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) telcontar.valinor:/data/storage_c/repositorios_zypp on /var/cache/zypp/nfs_packages type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.74.127,local_lock=none,addr=192.168.1.14) eleanor3:~ #
minas-tirith:~ # mount | grep nfs 192.168.1.14:/data/storage_c/repositorios_zypp/ on /var/cache/zypp/nfs_packages type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=192.168.1.14,mountvers=3,mountport=35298,mountproto=udp,local_lock=none,addr=192.168.1.14) minas-tirith:~ #
You see, the same server is working with versions 4 and 3, simultaneously.
Ehh ... minas-tirith mounts also using UDP and not TCP, which confirms that there is some connectivity issue.
A packet capture, edited to reduce size:
No. Time Source Destination Protocol Length Info 249 15:35:33.385373000 192.168.1.129 192.168.1.14 TCP 74 telnets > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=26851809 TSecr=0 WS=64 Transmission Control Protocol, Src Port: telnets (992), Dst Port: nfs (2049), Seq: 0, Len: 0
No. Time Source Destination Protocol Length Info 250 15:35:33.385445000 192.168.1.14 192.168.1.129 TCP 74 nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647243754 TSecr=26851809 WS=128 279 15:35:34.586491000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647244956 TSecr=26851809 WS=128
So SYN request comes to NFS server and NFS server answers to this. But your client apparently ignores it. So issues are with your client, not your server. [...]
428 15:35:40.586502000 192.168.1.14
192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647250956 TSecr=26851809 WS=128 Server tries to retransmit SYN ACK packet.
502 15:35:42.408036000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] telnets > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=26860832 TSecr=0 WS=64
Client times out and sends SYN again
503 15:35:42.408057000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647252777 TSecr=26851809 WS=128
Server gets it just fine and answers.
641 15:35:48.786494000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647259156 TSecr=26851809 WS=128
But never gets response from client as it looks like.
Retransmission? From both sides?
Yes. Which part surprises you?
A sucesful connection (version 3) goes like this:
No. Time Source Destination Protocol Length Info 90 15:59:58.752892000 192.168.1.129 192.168.1.14 TCP 74 57233 > sunrpc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=28317123 TSecr= 91 15:59:58.752967000 192.168.1.14 192.168.1.129 TCP 74 sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=6487 98 15:59:59.133783000 192.168.1.129 192.168.1.14 ICMP 98 Echo (ping) request id=0x2636, seq=2424/30729, ttl=64 99 15:59:59.133811000 192.168.1.14 192.168.1.129 ICMP 98 Echo (ping) reply id=0x2636, seq=2424/30729, ttl=64 116 15:59:59.754500000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 160 16:00:01.754498000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 161 16:00:01.757790000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 57233 > sunrpc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 162 16:00:01.757808000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 173 16:00:02.341905000 192.168.1.14 192.168.1.129 ICMP 98 Echo (ping) request id=0x70f4, seq=8814/28194, ttl=64 174 16:00:02.343809000 192.168.1.129 192.168.1.14 ICMP 98 Echo (ping) reply id=0x70f4, seq=8814/28194, ttl=64 259 16:00:05.754505000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 302 16:00:07.774018000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 57233 > sunrpc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 303 16:00:07.774053000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S
You get *EXACTLY* the same problem. Client never replies to SYN ACK from server so connection is never established.
329 16:00:08.763987000 192.168.1.129 192.168.1.14 Portmap 98 V2 GETPORT Call (Reply In 332) NFS(100003) V:3 UDP
And client falls back to UDP. Which of course cannot work with NFS V4 which dropped support for UDP entirely. So from information you provided it is either client or network issue. If trace was captured on client, it is most likely client. For a start check firewall on client ... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHi81EACgkQR6LMutpd94wftACdHlDtjXYX7uZEyzIWWaYkTG02 aJQAoMqHw18Zz8y5by4p7OWuphfWBQz+ =5ro4 -----END PGP SIGNATURE----- N▀╖╡ФЛr╦⌡yИ ┼Z)z{.╠О╝·к⌡╠йБmЙ)z{.╠Й+│: ╒{Zrшaz▄'z╥╕j)h╔ИЛ╨г╬ё ч╝┼^·к╛z┼Ю