orm@doc-tcpip.org

Erstellt: November 2000 - Letzte Modifikation: September 2003

[ Main | Local ]


Trace von showmount und NFS Mount

Wie RPC funktioniert

Einführung

Ein Trace zur Funktion des Mount-Protokolles. In diesem Trace wird zuerst per showmount vom Client beim Server angefragt. Der Server antwortet mit den Filesystemen, die er exportiert. Der Client wählt ein Filesystem, downloads, und mountet das an sein lokales /mnt.

Der Client setzt also folgende Befehle ab:

 
nfsclient # showmount -e nfsserver
export list for nfsserver:
/tmp      (everyone)
/download (everyone)
nfsclient #
nfsclient # mount nfsserver:/download /mnt
nfsclient #
nfsclient # mount

  node       mounted        mounted over    vfs       date        options      
-------- ---------------  ---------------  ------ ------------ --------------- 
         /dev/hd4         /                jfs    Sep 03 21:05 rw,log=/dev/hd8 
         /dev/hd2         /usr             jfs    Sep 03 21:05 rw,log=/dev/hd8 
         /dev/hd9var      /var             jfs    Sep 03 21:05 rw,log=/dev/hd8 
         /dev/hd3         /tmp             jfs    Sep 03 21:05 rw,log=/dev/hd8 
         /dev/hd1         /home            jfs    Sep 03 21:06 rw,log=/dev/hd8 
         /proc            /proc            procfs Sep 03 21:06 rw              
nfsserver /download        /mnt             nfs3   Sep 03 21:58                 

Der Trace

 
Packet Number 1
ETH: ====( 98 bytes received on interface en0 )==== 09:56:04.699087247
ETH:    [ 08:00:5a:93:bc:ea -> 08:00:5a:ba:da:a6 ]  type 800  (IP)
IP:  	< SRC =      172.16.1.3 >  (nfsclient)
IP:  	< DST =      172.16.1.2 >  (nfsserver)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=40454, ip_off=0
IP:  	ip_ttl=30, ip_sum=a46d, ip_p = 17 (UDP)
UDP: 	< source port=956, destination port=111(sunrpc) >
UDP: 	[ udp length = 64 | udp checksum = 7c43 ]
RPC: **CALL**	XID=1062983720
RPC: Program=100000 (PMAPPROG) Version=2 Procedure=3 (PMAPPROC_GETPORT)
RPC: AUTH_NULL Opaque Authorization Base 0 Opaque Authorization Length 0
PMP: Prog=100005 Vers=1 Prot=6 Port=0

Im ersten Paket meldet sich der Client auf der bekannten Portnummer des Portmappers: Port 111. Bei diesem Dienst registrieren sich alle NFS-Dienste, der Portmapper weiß also, wer aktuell auf welchem Port lauscht. Die Anfrage ist an das Programm 100000, was der Portmapper selber ist; die Version ist 2, die Prozedur ist 3, was eine GETPORT Anfrage ist. Die Anfrage erfolgt per UDP. Das interessante ist der RPC (Remote Procedure Call) und PMP (Portmapper) Teil. Die Anfrage kann über die eindeutige XID (eXtenden ID) jeder Antwort zugeordent werden. Dann erklärt der Client, das er sich nicht authorisieren möchte und am Ende fragt er nach dem Port des Programmes 100005 in der Version 1 und dem Protokoll 6 (das ist TCP, bei NFSv3 Standard) und den Port weiss er natürlich noch nicht. Es handelt sich bei dem Programm 100005 um den mountd (das vergisst man leicht, kann es aber mit rpcinfo -p nachsehen).

 
Packet Number 2
ETH: ====( 70 bytes transmitted on interface en0 )==== 09:56:04.701132461
ETH:    [ 08:00:5a:ba:da:a6 -> 08:00:5a:93:bc:ea ]  type 800  (IP)
IP:  	< SRC =      172.16.1.2 >  (nfsserver)
IP:  	< DST =      172.16.1.3 >  (nfsclient)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=56, ip_id=23318, ip_off=0
IP:  	ip_ttl=30, ip_sum=e779, ip_p = 17 (UDP)
UDP: 	< source port=111(sunrpc), destination port=956 >
UDP: 	[ udp length = 36 | udp checksum = 9ca ]
RPC: **REPLY**	XID=1062983720
RPC: 100000(PMAPPROG) 3(PMAPPROC_GETPORT)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat:  SUCCESS 
PMP: Returning 32774

Die Antwort des Servers. Im RPC-Teil wird der Typ (REPLY) und die XID angegeben, sowie die Anfrage wiederholt und der Status festgestellt. Dann kommt der eigentliche Inhalt der Anfrage (der Teil des Portmappers): Es wird für den mountd in der gewünschten Version und Protokoll der Port 32774 zurückgegeben.

 
Packet Number 3
TCP: 	th_off=6, flags< SYN >
Packet Number 4
TCP: 	th_off=6, flags< SYN | ACK >
Packet Number 5
TCP: 	th_off=5, flags< ACK >

Die NFS Version 3 läuft über TCP (da immer mehr Leute NFS über WANs machten). Das TCP Handshake ist hier rausgeschnitten.

 
Packet Number 6
ETH: ====( 98 bytes received on interface en0 )==== 09:56:04.703945854
ETH:    [ 08:00:5a:93:bc:ea -> 08:00:5a:ba:da:a6 ]  type 800  (IP)
IP:  	< SRC =      172.16.1.3 >  (nfsclient)
IP:  	< DST =      172.16.1.2 >  (nfsserver)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=40457, ip_off=0
IP:  	ip_ttl=60, ip_sum=8675, ip_p = 6 (TCP)
TCP: 	< source port=956, destination port=32774 >
TCP: 	th_seq=fc8edf26, th_ack=98d1a6cd
TCP: 	th_off=5, flags< PUSH | ACK >
TCP: 	th_win=17520, th_sum=7f54, th_urp=0
RPC: Record Marker: Size = 40, Last Fragment     (0x80000028)
RPC: **CALL**	XID=1062972524
RPC: Program=100005 (MOUNTPROG) Version=1 Procedure=5 (MOUNTPROC_EXPORT)
RPC: AUTH_NULL Opaque Authorization Base 0 Opaque Authorization Length 0
RPC: 00000000     00000000                                |....            |

Jetzt steht die Verbindung, und die erste Anfrage an den mountd des Servers ist Prozedur 5, MOUNTPROC_EXPORT, also welche Exporte der Server zur Verfügung stellt. Die Angabe von Typ, XID und Authorisierung ist wie gehabt.
Im RPC-Teil taucht jetzt ein Record Marker auf. Das ist bei TCP erforderlich, es wird die Größe des RPC-Teils angegeben und das letzte Fragment.

 
Packet Number 7
ETH: ====( 126 bytes transmitted on interface en0 )==== 09:56:04.711556040
ETH:    [ 08:00:5a:ba:da:a6 -> 08:00:5a:93:bc:ea ]  type 800  (IP)
IP:  	< SRC =      172.16.1.2 >  (nfsserver)
IP:  	< DST =      172.16.1.3 >  (nfsclient)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=112, ip_id=23320, ip_off=0
IP:  	ip_ttl=60, ip_sum=c94a, ip_p = 6 (TCP)
TCP: 	< source port=32774, destination port=956 >
TCP: 	th_seq=98d1a6cd, th_ack=fc8edf52
TCP: 	th_off=5, flags< PUSH | ACK >
TCP: 	th_win=17520, th_sum=8800, th_urp=0
RPC: Record Marker: Size = 68, Last Fragment     (0x80000044)
RPC: **REPLY**	XID=1062972524
RPC: 100005(MOUNTPROG) 5(MOUNTPROC_EXPORT)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat:  SUCCESS 
MNT: Export entries:
MNT: 	Path: /tmp
MNT: 		Groups: (everyone)
MNT: 	Path: /download
MNT: 		Groups: (everyone)

Die Antwort ist wieder als REPLY gekennzeichnet, wiederholt die Anfrage und zeigt den Status. Die eigentliche Antwort wird wieder vom mountd geliefert (MNT - Teil). Dieser Server exportiert /tmp und /download an jeden Client.

 
Packet Number 8
TCP: 	th_off=5, flags< FIN | ACK >
Packet Number 9
TCP: 	th_off=5, flags< ACK >
Packet Number 10
TCP: 	th_off=5, flags< FIN | ACK >
Packet Number 11
TCP: 	th_off=5, flags< ACK >

Der Abbau der TCP Verbindung erfolgt wie gewohnt und ist gekürzt.

 
Packet Number 12
ETH: ====( 98 bytes received on interface en0 )==== 09:57:44.324512026
ETH:    [ 08:00:5a:93:bc:ea -> 08:00:5a:ba:da:a6 ]  type 800  (IP)
IP:  	< SRC =      172.16.1.3 >  (nfsclient)
IP:  	< DST =      172.16.1.2 >  (nfsserver)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=40578, ip_off=0
IP:  	ip_ttl=30, ip_sum=a3f1, ip_p = 17 (UDP)
UDP: 	< source port=732, destination port=111(sunrpc) >
UDP: 	[ udp length = 64 | udp checksum = dfc0 ]
RPC: **CALL**	XID=1063155078
RPC: Program=100000 (PMAPPROG) Version=2 Procedure=3 (PMAPPROC_GETPORT)
RPC: AUTH_NULL Opaque Authorization Base 0 Opaque Authorization Length 0
PMP: Prog=100005 Vers=3 Prot=6 Port=0

Das NFS Protokoll ist weitgehend stateless, und so merkt sich der Client auch grundsätzlich keine Portnummern. Deshalb fragt er hier nochmal nach dem Port des mountd, analog zu Paket 1.

 
Packet Number 13
ETH: ====( 70 bytes transmitted on interface en0 )==== 09:57:44.326539836
ETH:    [ 08:00:5a:ba:da:a6 -> 08:00:5a:93:bc:ea ]  type 800  (IP)
IP:  	< SRC =      172.16.1.2 >  (nfsserver)
IP:  	< DST =      172.16.1.3 >  (nfsclient)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=56, ip_id=23350, ip_off=0
IP:  	ip_ttl=30, ip_sum=e759, ip_p = 17 (UDP)
UDP: 	< source port=111(sunrpc), 
UDP: 	[ udp length = 36 | udp checksum = 6d49 ]
RPC: **REPLY**	XID=1063155078
RPC: 100000(PMAPPROG) 3(PMAPPROC_GETPORT)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat:  SUCCESS 
PMP: Returning 32774

Die Antwort ist analog zu Paket 2, und da der Server oder einer der Deamons nicht neu initialisiert wurden, ist die Portnummer immer noch die gleiche.

 
Packet Number 14
TCP: 	th_off=6, flags< SYN >
Packet Number 15
TCP: 	th_off=6, flags< SYN | ACK >
Packet Number 16
TCP: 	th_off=5, flags< ACK >

Das TCP Handshake ist wieder gekürzt.

 
Packet Number 17
ETH: ====( 98 bytes received on interface en0 )==== 09:57:44.329334864
ETH:    [ 08:00:5a:93:bc:ea -> 08:00:5a:ba:da:a6 ]  type 800  (IP)
IP:  	< SRC =      172.16.1.3 >  (nfsclient)
IP:  	< DST =      172.16.1.2 >  (nfsserver)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=40581, ip_off=0
IP:  	ip_ttl=60, ip_sum=85f9, ip_p = 6 (TCP)
TCP: 	< source port=732, destination port=32774 >
TCP: 	th_seq=90c68d42, th_ack=dd704330
TCP: 	th_off=5, flags< PUSH | ACK >
TCP: 	th_win=17520, th_sum=a7ad, th_urp=0
RPC: Record Marker: Size = 40, Last Fragment     (0x80000028)
RPC: **CALL**	XID=1063149982
RPC: Program=100005 (MOUNTPROG) Version=3 Procedure=0 (MOUNTPROC3_NULL)
RPC: AUTH_NULL Opaque Authorization Base 0 Opaque Authorization Length 0
RPC: 00000000     00000000                                |....            |

Jetzt kommt mein Lieblings-Call: Diese Prozedur (*.NULL) macht nichts und dient nur zum Testen der Verbindung und um Grundwerte zum setzen der Timer zu erhalten.
Im Zusammenhang mit erweiterter Sicherheit (RPCSEC_GSS) wird über diese Pakete der Kontext ausgehandelt (Verschlüsselungsmethoden etc.).

 
Packet Number 18
ETH: ====( 82 bytes transmitted on interface en0 )==== 09:57:44.336077549
ETH:    [ 08:00:5a:ba:da:a6 -> 08:00:5a:93:bc:ea ]  type 800  (IP)
IP:  	< SRC =      172.16.1.2 >  (nfsserver)
IP:  	< DST =      172.16.1.3 >  (nfsclient)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=68, ip_id=23352, ip_off=0
IP:  	ip_ttl=60, ip_sum=c956, ip_p = 6 (TCP)
TCP: 	< source port=32774, destination port=732 >
TCP: 	th_seq=dd704330, th_ack=90c68d6e
TCP: 	th_off=5, flags< PUSH | ACK >
TCP: 	th_win=17520, th_sum=2e4c, th_urp=0
RPC: Record Marker: Size = 24, Last Fragment     (0x80000018)
RPC: **REPLY**	XID=1063149982
RPC: 100005(MOUNTPROG) 0(MOUNTPROC3_NULL)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat:  SUCCESS 
RPC: 00000000     00000000                                |....            |

Die Antwort tut natürlich auch nichts... (außer mit RPCSEC_GSS).

 
Packet Number 19
ETH: ====( 98 bytes received on interface en0 )==== 09:57:44.337170702
ETH:    [ 08:00:5a:93:bc:ea -> 08:00:5a:ba:da:a6 ]  type 800  (IP)
IP:  	< SRC =      172.16.1.3 >  (nfsclient)
IP:  	< DST =      172.16.1.2 >  (nfsserver)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=40582, ip_off=0
IP:  	ip_ttl=30, ip_sum=a3ed, ip_p = 17 (UDP)
UDP: 	< source port=732, destination port=111(sunrpc) >
UDP: 	[ udp length = 64 | udp checksum = 1478 ]
RPC: **CALL**	XID=1063141585
RPC: Program=100000 (PMAPPROG) Version=2 Procedure=3 (PMAPPROC_GETPORT)
RPC: AUTH_NULL Opaque Authorization Base 0 Opaque Authorization Length 0
PMP: Prog=100003 Vers=3 Prot=6 Port=0

Da alles zu gehen scheint, will der Client jetzt wissen, auf welchem Port der eigentliche NFS-Deamon lauscht. Das ist der nfsd, mit der Programm-Nummer 1000003, Version 3 und über TCP. Die Anfrage geht wieder über UDP an den well known Port 111.

 
Packet Number 20
ETH: ====( 70 bytes transmitted on interface en0 )==== 09:57:44.338590152
ETH:    [ 08:00:5a:ba:da:a6 -> 08:00:5a:93:bc:ea ]  type 800  (IP)
IP:  	< SRC =      172.16.1.2 >  (nfsserver)
IP:  	< DST =      172.16.1.3 >  (nfsclient)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=56, ip_id=23353, ip_off=0
IP:  	ip_ttl=30, ip_sum=e756, ip_p = 17 (UDP)
UDP: 	< source port=111(sunrpc), destination port=732 >
UDP: 	[ udp length = 36 | udp checksum = 1a04 ]
RPC: **REPLY**	XID=1063141585
RPC: 100000(PMAPPROG) 3(PMAPPROC_GETPORT)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat:  SUCCESS 
PMP: Returning 2049

Der NFS-Deamon läuft auch auf einem well known Port. Das ist die Nummer 2049, die hier zurück gegeben wird. Da es die Kommunikation mit dem Portmapper ist, wird by default UDP als Protokoll benutzt.

 
Packet Number 21
TCP: 	th_off=6, flags< SYN >
Packet Number 22
TCP: 	th_off=6, flags< SYN | ACK >
Packet Number 23
TCP: 	th_off=5, flags< ACK >

Das TCP Handshake wird wieder gekürzt.

 
Packet Number 24
ETH: ====( 98 bytes received on interface en0 )==== 09:57:44.345757855
ETH:    [ 08:00:5a:93:bc:ea -> 08:00:5a:ba:da:a6 ]  type 800  (IP)
IP:  	< SRC =      172.16.1.3 >  (nfsclient)
IP:  	< DST =      172.16.1.2 >  (nfsserver)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=40585, ip_off=0
IP:  	ip_ttl=60, ip_sum=85f5, ip_p = 6 (TCP)
TCP: 	< source port=733, destination port=2049(shilp) >
TCP: 	th_seq=df46c0be, th_ack=d753535a
TCP: 	th_off=5, flags< PUSH | ACK >
TCP: 	th_win=17520, th_sum=d25f, th_urp=0
RPC: Record Marker: Size = 40, Last Fragment     (0x80000028)
RPC: **CALL**	XID=1063133929
RPC: Program=100003 (NFS_PROGRAM) Version=3 Procedure=0 (NFSPROC3_NULL)
RPC: AUTH_NULL Opaque Authorization Base 0 Opaque Authorization Length 0
RPC: 00000000     00000000                                |....            |

Jetzt testet der Client, ob er mit dem NFS Deamon auch wirklich reden kann. (Mit RPCSEC würden gleich wichtige Dinge verhandelt).

 
Packet Number 25
ETH: ====( 82 bytes transmitted on interface en0 )==== 09:57:44.346979798
ETH:    [ 08:00:5a:ba:da:a6 -> 08:00:5a:93:bc:ea ]  type 800  (IP)
IP:  	< SRC =      172.16.1.2 >  (nfsserver)
IP:  	< DST =      172.16.1.3 >  (nfsclient)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=68, ip_id=23355, ip_off=0
IP:  	ip_ttl=60, ip_sum=c953, ip_p = 6 (TCP)
TCP: 	< source port=2049(shilp), destination port=733 >
TCP: 	th_seq=d753535a, th_ack=df46c0ea
TCP: 	th_off=5, flags< PUSH | ACK >
TCP: 	th_win=61276, th_sum=ae0f, th_urp=0
RPC: Record Marker: Size = 24, Last Fragment     (0x80000018)
RPC: **REPLY**	XID=1063133929
RPC: 100003(NFS_PROGRAM) 0(NFSPROC3_NULL)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat:  SUCCESS 
RPC: 00000000     00000000                                |....            |

Ja, der Deamon antwortet.

 
Packet Number 26
TCP: 	th_off=5, flags< FIN | ACK >
Packet Number 27
TCP: 	th_off=5, flags< ACK >
Packet Number 28
TCP: 	th_off=5, flags< FIN | ACK >

Der Abbau der TCP Verbindung - gekürzt.

 
Packet Number 29
ETH: ====( 170 bytes received on interface en0 )==== 09:57:44.348939973
ETH:    [ 08:00:5a:93:bc:ea -> 08:00:5a:ba:da:a6 ]  type 800  (IP)
IP:  	< SRC =      172.16.1.3 >  (nfsclient)
IP:  	< DST =      172.16.1.2 >  (nfsserver)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=156, ip_id=40587, ip_off=0
IP:  	ip_ttl=60, ip_sum=85ab, ip_p = 6 (TCP)
TCP: 	< source port=732, destination port=32774 >
TCP: 	th_seq=90c68d6e, th_ack=dd70434c
TCP: 	th_off=5, flags< PUSH | ACK >
TCP: 	th_win=17520, th_sum=2dbb, th_urp=0
RPC: Record Marker: Size = 112, Last Fragment     (0x80000070)
RPC: **CALL**	XID=1063149981
RPC: Program=100005 (MOUNTPROG) Version=3 Procedure=1 (MOUNTPROC3_MNT)
RPC: AUTH_UNIX 
RPC: Cred:
RPC: 	Time=0x3f5647d9 (Wed Sep  3 21:58:17 2003)
RPC: 	Machine=nfsclient Uid=0 Gid=0 Group List Length=7 
RPC: 	Groups= ( 0 2 3 7 8 10 11 )
MNT: Path: /download

Hier geht es jetzt endlich los. Der User hat sich entschieden, das vom Server exportierte Filesystem /download zu mounten. Der User hat also so etwas wie mount nfsserver:/download /mnt abgesetzt. Der NFS-Client (biod, Basic IO Deamon) ruft daher die per RPC die Prozedur 1 des Servers auf, MOUNTPROC3_MNT. Zu Authentifizierung gibt er den normalen Host-Namen, die Unix-UID und GID des Users, der den Mount ausführt, sowie einen Zeitstempel an.
Es mountet also der User root (UID 0, GID 0) von der Maschine nfsclient. Der User root gehört zu einer Reihe Gruppen, und er möchte das Verzeichnis /download mounten.

 
Packet Number 30
TCP: 	th_off=5, flags< ACK >

Das ACK dazu, der Server muß es sich genau überlegen, daher geht das ACK alleine und nicht Huckepack raus.

 
Packet Number 31
ETH: ====( 130 bytes transmitted on interface en0 )==== 09:57:44.472549810
ETH:    [ 08:00:5a:ba:da:a6 -> 08:00:5a:93:bc:ea ]  type 800  (IP)
IP:  	< SRC =      172.16.1.2 >  (nfsserver)
IP:  	< DST =      172.16.1.3 >  (nfsclient)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=116, ip_id=23360, ip_off=0
IP:  	ip_ttl=60, ip_sum=c91e, ip_p = 6 (TCP)
TCP: 	< source port=32774, destination port=732 >
TCP: 	th_seq=dd70434c, th_ack=90c68de2
TCP: 	th_off=5, flags< PUSH | ACK >
TCP: 	th_win=17520, th_sum=ab41, th_urp=0
RPC: Record Marker: Size = 72, Last Fragment     (0x80000048)
RPC: **REPLY**	XID=1063149981
RPC: 100005(MOUNTPROG) 1(MOUNTPROC3_MNT)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat:  SUCCESS 
MNT: Fhandle:
MNT:           000a0004 00000003 000a0000 04661f82
MNT:           1d020000 000a0000 04661f82 1d020000
MNT: Authentication Flavors:
MNT: Length: 0001 Flavors: AUTH_UNIX 
MNT: Status=OK (0)

Der Server gibt einen Status des RPC und dann kommt, im MNT-Teil, der Filehandle für das gewünschte Verzeichnis sowie die Bestätigung, das Unix-Authentifizierung in Ordnung ist. Im Filehandle kann man unter Unix das Device an seiner Major/Minor Nummer erkennen, und die Inode des Files:

 
MNT:           000a0004 00000003 000a0000 04661f82
.              ^^^^^^^^              ^^^^ ^^^^
.              |Major                Inode
.                  |Minor
Beide Werte sind in Hex. Mit mount und ls -i findet man so das entsprechende File. Der Filehandle ist von NFS unabhängig, er ist eine reine Angelegenheit des Betriebssystemes. NFS nutzt ihn als Ticket oder Token.

 
Packet Number 32
TCP: 	th_off=5, flags< FIN | ACK >
Packet Number 33
TCP: 	th_off=5, flags< ACK >
Packet Number 34
TCP: 	th_off=6, flags< SYN >
Packet Number 35
TCP: 	th_off=6, flags< SYN | ACK >
Packet Number 36
TCP: 	th_off=5, flags< ACK > 

Abbau der einen Verbindung, Aufbei einer neuen.

 
Packet Number 37
ETH: ====( 190 bytes received on interface en0 )==== 09:57:44.475668614
ETH:    [ 08:00:5a:93:bc:ea -> 08:00:5a:ba:da:a6 ]  type 800  (IP)
IP:  	< SRC =      172.16.1.3 >  (nfsclient)
IP:  	< DST =      172.16.1.2 >  (nfsserver)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=176, ip_id=40592, ip_off=0
IP:  	ip_ttl=60, ip_sum=8592, ip_p = 6 (TCP)
TCP: 	< source port=32779, destination port=2049(shilp) >
TCP: 	th_seq=cad6e18b, th_ack=a9cc5f5
TCP: 	th_off=5, flags< PUSH | ACK >
TCP: 	th_win=60000, th_sum=40e6, th_urp=0
RPC: Record Marker: Size = 132, Last Fragment     (0x80000084)
RPC: **CALL**	XID=993839064
RPC: Program=100003 (NFS_PROGRAM) Version=3 Procedure=19 (NFSPROC3_FSINFO)
RPC: AUTH_UNIX 
RPC: Cred:
RPC: 	Time=0x3f5647d9 (Wed Sep  3 21:58:17 2003)
RPC: 	Machine=oepd1 Uid=0 Gid=0 Group List Length=7 
RPC: 	Groups= ( 0 2 3 7 8 10 11 )
NFS: Fhandle:
NFS:           000a0004 00000003 000a0000 04661f82
NFS:           1d020000 000a0000 04661f82 1d020000

Der Client kennt jetzt den Filehandle und besorgt sich ein paar allgemeine Informationen zum Filesystem. Er spricht dabei mit dem NFS Deamon, dessen Port er ja kennt. Die Prozedur ist die Nummer 19, FSINFO. Damit der Server weiß, worauf sich der Client bezieht, schickt er den Filehandle mit - den der Client weder versteht noch auswertet.

 
Packet Number 38
TCP: 	th_off=5, flags< FIN | ACK >
Packet Number 39
TCP: 	th_off=5, flags< ACK >

Abbau der TCP Verbindung - Clientseitig. Der Server darf noch senden.

 
Packet Number 40
ETH: ====( 222 bytes transmitted on interface en0 )==== 09:57:44.517438424
ETH:    [ 08:00:5a:ba:da:a6 -> 08:00:5a:93:bc:ea ]  type 800  (IP)
IP:  	< SRC =      172.16.1.2 >  (nfsserver)
IP:  	< DST =      172.16.1.3 >  (nfsclient)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=208, ip_id=23364, ip_off=0
IP:  	ip_ttl=60, ip_sum=c8be, ip_p = 6 (TCP)
TCP: 	< source port=2049(shilp), destination port=32779 >
TCP: 	th_seq=a9cc5f5, th_ack=cad6e213
TCP: 	th_off=5, flags< PUSH | ACK >
TCP: 	th_win=61184, th_sum=d00e, th_urp=0
RPC: Record Marker: Size = 164, Last Fragment     (0x800000a4)
RPC: **REPLY**	XID=993839064
RPC: 100003(NFS_PROGRAM) 19(NFSPROC3_FSINFO)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat:  SUCCESS 
NFS: Stat: (0) NFS3_OK 
NFS: File System Attributes:
NFS: 	Type=2(NFDIR) Mode=240755 Nlink=2 Uid=0 Gid=0 Rdev=(0,1535)
NFS: 	Size=512 Used=4096
NFS: 	Fsid=655364 Fileid=1126
NFS: 	Access Time: Sec=1061817176 Nsec=284071923
NFS: 	Modify Time: Sec=1046945738 Nsec=252802649
NFS: 	Create Time: Sec=1046945738 Nsec=252802650
NFS: Max Read Size:		65536
NFS: Preferred Read Size:	32768
NFS: Read Multiple:		512
NFS: Max Write Size:		65536
NFS: Preferred Write Size:	32768
NFS: Write Multiple:		512
NFS: Preferred READDIR Size:	4096
NFS: Max File Size:		2147483647
NFS: Time Granularity: Sec=0 Nsec=1000
NFS: Properties: (5e355bb) HARDLINK  SYMLINK  HOMOGENEOUS  CANSETTIME 

Die Filesystem Information ist analog der Information, die man auf der Maschine mit ls erhalten kann. Dann werden noch die Größen der Schreib- und Lese-Puffer sowie die Größe des Filesystems und die gesetzten Flags übertragen. Diese Information merkt sich der Client.

 
Packet Number 41
ETH: ====( 60 bytes received on interface en0 )==== 09:57:44.633495209
ETH:    [ 08:00:5a:93:bc:ea -> 08:00:5a:ba:da:a6 ]  type 800  (IP)
IP:  	< SRC =      172.16.1.3 >  (nfsclient)
IP:  	< DST =      172.16.1.2 >  (nfsserver)
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=40595, ip_off=0
IP:  	ip_ttl=60, ip_sum=8617, ip_p = 6 (TCP)
TCP: 	< source port=32779, destination port=2049(shilp) >
TCP: 	th_seq=cad6e213, th_ack=a9cc69d
TCP: 	th_off=5, flags< ACK >
TCP: 	th_win=60000, th_sum=651d, th_urp=0

Das ACK dazu.

 
++++++ END OF REPORT ++++++

processed 41 packets
Summary of RPC CALL packets
reqid=993839064 prog=100003 vers=3 proc=19 caller=172.16.1.3
reqid=1063149981 prog=100005 vers=3 proc=1 caller=172.16.1.3
reqid=1063133929 prog=100003 vers=3 proc=0 caller=172.16.1.3
reqid=1063141585 prog=100000 vers=2 proc=3 caller=172.16.1.3
reqid=1063149982 prog=100005 vers=3 proc=0 caller=172.16.1.3
reqid=1063155078 prog=100000 vers=2 proc=3 caller=172.16.1.3
reqid=1062972524 prog=100005 vers=1 proc=5 caller=172.16.1.3
reqid=1062983720 prog=100000 vers=2 proc=3 caller=172.16.1.3

Am Ende des Reports sind nocheinmal die verschiednen RPCs aufgeführt. Es handelt sich um die ausgeführten Anfragen des Client, der letzte Call steht an erster Stelle. Die reqid wird im Trace als XID bezeichnet. Man kann so leicht den problematischen Call identifizieren und dann gezielt nach der XID suchen.


[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | SMTP | Tracing | GPS ]

Copyright 2001-2014 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )