4. Scopo dell'esperienza (2)
• Tre nodi
– node1
– node2
– node3
• Due sottoreti
– 192.168.1.0, legata a switch1
– 192.168.2.0, legata a switch2
– Per entrambe netmask=255.255.255.0
• Obiettivo: far comunicare i nodi attraverso le due
sottoreti
4
5. Presentazione dei componenti della rete (1)
• switch1
– connesso alla socket unix /tmp/uml1.ctl
• switch2
– connesso alla socket unix /tmp/uml2.ctl
• node1
– 1 scheda di rete eth0
– indirizzo 192.168.1.1
– legata alla sottorete 192.168.1.0
– si collega allo switch switch1
• node3
– analogo a node 1 ma sulla sottorete 192.168.2.0
5
6. Presentazione dei componenti della rete (2)
• node2
– scheda di rete eth0
su sottorete 192.168.1.0
indirizzo 192.168.1.254
fa da gateway per quella sottorete
si collega a switch1
– scheda di rete eth1
eth1 su sottorete 192.168.2.0
indirizzo 192.168.2.254
fa da gateway per quella sottorete
si collega a switch2
6
7. Primo passo: preparare i sistemi UML
• Assicurarsi di avere le immagini dei filesystem nella
opportuna directory
– NOTA: MAI lavorare in $HOME, SEMPRE in /tmp
– usiamo l'immagine debian5b.ext2
• Fare partire il supporto per la rete (i due switch
virtuali)
– switch1
$ ./uml_switch -unix /tmp/uml1.ctl
– switch2
$ ./uml_switch -unix /tmp/uml2.ctl
7
8. Due parole su come si scompatta un archivio
• tar (TApe aRchive)
• Opzioni
– -v (verbose operation)
– comando
-x scompatta
-t mostra contenuto
– algoritmo di compressione
-Z compress (archivi .tar.Z)
-z gzip (archivi .tar.gz)
-j bzip2 (archivi .tar.bz2)
– -f file
• Esempio:
tar -xzvf archivio.tar.gz 8
9. Secondo passo: lanciare i sistemi virtuali (1)
• node1
$ ./linux
ubd0=node1.cow,debian5b.ext2
eth0=daemon,,unix,/tmp/uml1.ctl
interfaccia di
rete: eth0 su
• node3 switch1
$ ./linux (/tmp/uml1.ctl)
ubd0=node3.cow,debian5b.ext2
eth0=daemon,,unix,/tmp/uml2.ctl interfaccia di
rete: eth0 su
switch2
(/tmp/uml2.ctl)
9
10. Secondo passo: lanciare i sistemi virtuali (2)
• node2
$ ./linux
ubd0=node2.cow,debian5b.ext2
2 interfacce
eth0=daemon,,unix,/tmp/uml1.ctl di rete
eth1=daemon,,unix,/tmp/uml2.ctl • eth0 su
switch1
• eth1 su
switch2
• Ogni volta che si lancia un nodo dovrebbe apparire
un'indicazione nelle schermate dove girano gli
switch
10
11. Errori comuni
• Mettere lo spazio tra i sottoparametri del kernel
– NO: ubd0=file.cow, file.ext2
– SI: ubd0=file.cow,file.ext2
• Sbagliare a scrivere i nomi dei parametri
– NO: udb
– SI: ubd
– NO: demon o damon
– SI: daemon
• Terminare in modo sporco i processi UML
– MAI chiudere le finestre di UML, dare il comando
shutdown dalla linea di comando del sistema UML
11
12. Terzo passo: configurare i nodi (1)
• Si fa il login su ciascuno dei nodi e si lavora da linea
di comando sui nodi virtuali
• Login:
– Username: root
– Password nulla (basta battere invio, se non funziona
provare con “root”)
• Dare un nome ai nodi:
– Editare il file /etc/hostname in modo che contenga il
nome del nodo
12
13. Terzo passo: configurare i nodi (2)
• Inserire le giuste informazioni di rete per risolvere i
nomi
– Si agisce sul file /etc/hosts
– Alla fine ogni nodo dovrebbe avere un file fatto in
questo modo:
127.0.0.1 localhost
192.168.1.1 node1
192.168.2.1 node3
192.168.1.254 node2
192.168.2.254 node2
13
14. Quarto passo: configurare le interfacce di
rete (1)
• Si usa il file /etc/network/interfaces
• Il file contiene diverse direttive
– Direttiva auto: quali interfacce vanno inizializzate
all'avvio della macchina
auto lo
auto eth0
auto eth1 (per node2)
– Direttiva iface: una per ogni interfaccia
iface <nome> inet <modalità>
<nome> vale lo, eth0, eth1
inet indica che sono interfacce TCP/IP
14
15. Quarto passo: configurare le interfacce di
rete (2)
• Direttiva iface nel file /etc/network/interfaces
– <modalità> vale
dhcp = inizializzazione dell'interfaccia in modo automatico col
protocollo dhcp
loopback = interfaccia locale (127.0.0.1)
static = seguono parametri per configurare l'interfaccia
– Configurazione statica di un'interfaccia
address = indirizzo IP dell'interfaccia (192.168.X.Y)
netmask = 255.255.255.0
network = indirizzo della rete (192.168.X.0)
broadcast = indirizzo di broadcast (192.168.X.255)
gateway = solo per node1 e node3, l'indirizzo dell'interfaccia
di node2 che si affaccia sulla sottorete
15
16. Esempio
# File di configurazione per node1
# The loopback network interface
auto lo
iface lo inet loopback
# Interface eth0
auto eth0
# iface eth0 inet dhcp
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
broadcast 192.168.1.255
network 192.168.1.0
gateway 192.168.1.254
16
17. Quinto passo: mettere tutto insieme (1)
• Possiamo riavviare tutti e tre i sistemi
$ reboot
• In alternativa possiamo forzare il riavvio delle
interfacce di rete con i comandi
– ifdown <interfaccia>, ifup <interfaccia> oppure
– /etc/init.d/networking restart
• In entrambi i casi abbiamo comunicazione entro una
sottorete
– Facendo login da node 1 riusciamo a fare ping su
node 2 e viceversa
– Stessa cosa tra node 3 e node 2
17
18. Quinto passo: mettere tutto insieme (2)
• Perché node 1 e 3 non comunicano?
• Serve che node 2 diventi un vero router e passi il
traffico tra le sue due interfacce (eth0 e eth1)
# echo “1” >/proc/sys/net/ipv4/ip_forward
• Ora dovremmo essere in grado di far comunicare
anche node1 e node3 attraverso node2
18
19. Configurare le interfacce “da uomini veri”
• Comandi ifconfig e route
• ifconfig <interface> <address> netmask <mask> up
– Configura l'interfaccia di rete specificata con:
indirizzo IP
netmask
– ifconfig consente di fare anche molte altre cose,
verificare la manpage per vedere le altre opzioni
– Ad ogni reboot il comando va di nuovo lanciato
• route add default gw <gwaddr>
– Inserisce l'indirizzo del gateway di default (come
comando gateway in /etc/network/intefaces)
19
20. Configurare le interfacce “al volo”
• Nel nostro caso i comandi da lanciare sono:
• Su node1
– ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
– route add default gw 192.168.1.254
• Su node2
– ifconfig eth0 192.168.1.254 netmask 255.255.255.0 up
– ifconfig eth1 192.168.2.254 netmask 255.255.255.0 up
• Su node3
– ifconfig eth0 192.168.1.2 netmask 255.255.255.0 up
– route add default gw 192.168.2.254
20
21. Salvare il lavoro fatto
• Alla fine di una sessione di lavoro può far comodo
salvare le proprie immagini UML
• Il meccanismo Copy on Write è molto pignolo sulla
consistenza file cow/file ext2
– L'età dei file deve corrispondere
– In caso contrario UML si rifiuterà all'avvio successivo di
montare I dischi
• Bisogna preservare le date di accesso
– Opzione -p (preserve) del comando copy
– Opzione --atime-preserve del comando tar
• Esempio:
– $ tar -cSzvf mie_immagini.tgz *.cow *.ext2
--atime-preserve
21
23. Campo Time-To-Live del datagramma IP
• Poiché le tabelle di instradamento dei router non sono
sempre “corrette”, è possibile che un pacchetto entri in cicli
da cui non riesca ad uscire
• Per evitare congestioni dovute a situazioni di questo tipo, si
fissa un limite al tempo entro cui un pacchetto può restare
sulla rete. Nei pacchetti IP il campo Time-To-Live misura il
tempo di vita rimanente al pacchetto.
• Ciascun router deve decrementare il TTL di almeno una unità
(RFC 1812). Nella pratica, i pacchetti raramente rimangono in
un router per più di un secondo ed i router semplicemente
decrementano di uno il TTL prima di instradare un pacchetto
23
24. Campo Time-To-Live del datagramma IP (2)
• Quindi, indipendentemente dal nome, il TTL conta il numero
di hop che il pacchetto può fare prima di giungere a
destinazione o di essere scartato.
• I router controllano se il TTL è uguale a zero dopo il
decremento, subito prima dell’inoltro. Se il destinatario del
pacchetto è il router stesso questo non viene mai scartato
(RFC 1812).
24
25. Protocolli di supporto
protocolli che protocolli di supporto
offrono servizi portano dati “di controllo” e non
offrono direttamente servizi
portano “dati utente”
le loro pdu vengono la loro posizione nella pila è
imbustate” in accordo indipendente da come vengono
alla pila iso-osi imbustate le pdu
esempi: esempi:
4 tcp 4
3 IP
viaggia in pdu di ICMP IP protocolli
livello 3 (ip)
di routing 3
2 et ARP/RARP
er n
1 eth 2
viaggiano in pdu
di livello 2 1
25
27. Internet Control Message Protocol (ICMP)
• Definito da IETF rfc792 (Settembre 1981)
• Scopi
– Notifica situazioni di errore o anomalie
(congestione e controllo di flusso dei datagram)
– Supporta “debugging” interattivo della rete
( determinare cammini circolari o eccessivamente lunghi,
stimare il tempo di trasmissione da mittente a destinatario)
• ICMP è funzionale ad IP e viaggia in pacchetti IP
• ICMP porta informazioni di controllo e di notifica di errori.
Non porta dati. I pacchetti ICMP viaggiano all’interno dei
pacchetti IP.
• Le funzionalità fornite da ICMP sono accessorie al livello 3,
quindi ICMP è considerato un protocollo di livello 3. ICMP è
sempre presente a fianco di IP.
27
29. Relazione tra ICMP e IP
icmp hdr icmp data
ip header ip data
frame header frame data trailer
regola 1: nessun messaggio ICMP viene generato a seguito ad eventuali errori
rilevati su messaggi ICMP
regola 2: se il pacchetto viene frammentato solo il primo frammento può generare
messaggi di errore ICMP
regola 3: i broadcast e multicast non generano ICMP
29
30. Messaggi di informazione
• ECHO_REQUEST e REPLY (richiesta di echo e relativa
risposta)
– controllo di raggiungibilità di un host
• TIMESTAMP e TIMESTAMP_REPLY
come ECHO più informazioni su orario invio
– misura di velocità del collegamento
– sincronizzazione (approssimativa) dell’ora di sistema
• REDIRECT Un router intermedio si accorge che il percorso
che il datgram sta seguendo non è ottimale: gli dice di
cambiare percorso, ma nel frattempo inoltra il datagram
originale verso la sua destinazione
30
31. Messaggi di errore
Questi messaggi di errore seguono un pacchetto scartato:
• TIME_ EXCEEDED (tempo scaduto)
– il pacchetto ha TTL=0
• DESTINATION_UNREACHABLE
– un gateway vede la rete destinazione a distanza infinita (net unreachable)
– l'host non risponde ad una chiamata ARP (host unreachable)
– l'host destinazione non conosce il protocollo nel pacchetto (protocol
unreachable)
– il pacchetto non può essere frammentato (fragmentation needed and DF
set)
31
32. Messaggi di errore (2)
• PARAMETER_PROBLEM (problema con i parametri).
– Il gateway non riesce ad interpretare il pacchetto ricevuto a causa di un valore
errato, possibile errore software
• SOURCE_QUENCH obsoleto (rallentamento, soffocamento
della sorgente)
– congestione di un gateway intermedio
– host destinazione lento nell’acquisizione
Far riferimento alla RFC 792 per ulteriori approfondimenti in
particolare alle sezioni “description” per ciasun messaggio.
32
33. ping
• Invia una successione di pacchetti ICMP ECHO_REQUEST e
attende la relativa risposta ECHO_REPLY
• Misura il tempo che intercorre tra l’invio e la ricezione di ogni
pacchetto e riporta semplici statistiche
• Il comando ping fa parte della dotazione standard di tutte le
macchine sia Unix che Windows anche se con sintassi
leggermente diverse.
• L’indirizzo localhost viene risolto in un indirizzo IP normale
che dall’output è 127.0.0.1
• Ulteriori informazioni: manuale in linea di ping (sui sistemi
Unix: man ping)
33
34. ping
Esempio di ping con pacchetti persi
<utente@pascal ~> ping wilma.cs.brown.edu
PING wilma.cs.brown.edu: (128.148.19.15): 56 data bytes
64 bytes from 128.148.19.15: icmp_seq=1 ttl=239 time=1736 ms
64 bytes from 128.148.19.15: icmp_seq=2 ttl=239 time=1507 ms
64 bytes from 128.148.19.15: icmp_seq=6 ttl=239 time=1209 ms
64 bytes from 128.148.19.15: icmp_seq=8 ttl=239 time=762 ms
64 bytes from 128.148.19.15: icmp_seq=9 ttl=239 time=1235 ms
64 bytes from 128.148.19.15: icmp_seq=11 ttl=239 time=1566 ms
64 bytes from 128.148.19.15: icmp_seq=13 ttl=239 time=586 ms
64 bytes from 128.148.19.15: icmp_seq=14 ttl=239 time=352 ms
64 bytes from 128.148.19.15: icmp_seq=22 ttl=239 time=910 ms
^C
----wilma.cs.brown.edu PING Statistics----
29 packets transmitted, 9 packets received, 68% packet loss
round-trip min/avg/max = 352/1095/1736 ms
• <utente@pascal ~>
34
35. traceroute
• Il comando traceroute permette di capire per quali router
passano i pacchetti IP quando sono diretti ad una data
destinazione.
• traceroute è compreso nella dotazione standard di tutte i
sistemi Unix.
• Nei sistemi Windows il comando ha il nome tracert e
sintassi leggermente differente.
• traceroute trova utilizzo anche nell’ambito
dell’amministrazione della rete per isolare guasti o
incoerenze nelle tabelle di routing.
• Dal punto di vista didattico la sua utilità è di mostrare il
percorso dei pacchetti svelando un po’ della topologia
nascosta di Internet.
35
36. traceroute
<utente@pascal ~>traceroute wilma.cs.brown.edu
traceroute to wilma.cs.brown.edu (128.148.19.15), 30 hops max, 40 byte packets
1 gw1.fis.uniroma3.it (193.204.160.1) 3 ms 3 ms 2 ms
2 141.108.132.1 (141.108.132.1) 832 ms 967 ms 402 ms
3 mp4rm1.roma1.infn.it (141.108.127.6) 267 ms 106 ms 417 ms
4 atm-garrten-rm.infn.it (192.135.31.5) 100 ms 939 ms 839 ms
5 cnafint-ten34.infn.it (192.135.34.21) 1100 ms * 1056 ms
6 mix-serial3-4.Washington.mci.net (204.189.152.161) 618 ms * *
7 * core1-fddi-0.Washington.mci.net (204.70.2.1) 1249 ms *
8 ***
9 wtn-bbn-nap.Washington.mci.net (206.157.77.218) 766 ms * *
10 * * chicago1-br1.bbnplanet.net (4.0.1.5) 857 ms
11 * * *
12 * boston1-br1.bbnplanet.net (4.0.2.245) 846 ms *
13 boston1-br2.bbnplanet.net (4.0.2.250) 680 ms * *
14 * * boston1-mr4.bbnplanet.net (4.0.44.19) 648 ms
15 providence-cr1.bbnplanet.net (4.0.45.106) 416 ms providence-cr1.bbnplanet.net
(4.0.45.102) 1298 ms *
16 brown.bbnplanet.net (131.192.32.2) 1444 ms 615 ms 802 ms
17 * * *
18 * ftp.cs.brown.edu (128.148.19.15) 834 ms 435 ms
<utente@pascal ~>
36
37. Esempio: traceroute
• Si ipotizzi di inviare un pacchetto, ad esempio un
ECHO_REQUEST con TTL=n “basso”. Se il destinatario è troppo
lontano l’ultimo router risponderà con un TIME_EXCEEDED, se il
destinatario risponde con ECHO_REPLY allora è raggiungibile con
n hop
• In realtà alcuni traceroute non utilizzano gli ECHO_REQUEST se
non gli viene chiesto esplicitamente ma altri protocolli (UDP).
Inoltre manda 3 pacchetti per ogni valore di n. Se non si osserva
un TIME_EXCEEDED entro un tempo prestabilito traceroute
visualizza un asterisco “*”
• Il manuale in linea di traceroute è estremamente interessante e
mostra anche esempi di strani comportamenti da parte dei router
37
41. Comando ifconfig
• Ifconfig è il comando principe per l'interazione con le
interfacce di rete
• Esso consente di:
– controllare i dati di un'interfaccia di rete
– modificare lo stato di un'interfaccia
• In questa parte ci si concentra sull'uso di ifconfig per
leggere lo stato di un'interfaccia di rete
41
42. Uso di ifconfig: un esempio pratico
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:10:5A:9D:88:AF
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:92 errors:0 dropped:0 overruns:0 frame:0
TX packets:52 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14162 (13.8 KiB) TX bytes:6744 (6.5 KiB)
Interrupt:9 Base address:0xfc00
42
43. Analisi di un'interfaccia ethernet
# ifconfig eth0 #voglio tutte le informazioni sulla interfaccia di rete eth0
# se non sono root dovrò inserire il percorso completo /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:5A:9D:88:AF
# eth0 e' un'interfaccia di tipo ethernet
# il suo indirizzo MAC è 00:10:5A:9D:88:AF
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
# l'interfaccia è configurata con un indirizzo IP, ovvero 192.168.1.3
# l'indirizzo IP usato per i broadcast è 192.168.1.255
# la netmask vale 255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
# i flag dell'interfaccia sono
# UP: l'interfaccia è configurata
# BROADCAST: si usa un canale broadcast
# RUNNING: l'interfaccia è attiva
43
44. Analisi di un'interfaccia ethernet (2)
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
# MULTICAST: l'interfaccia può essere usata per il multicast
# MTU: dimensione massima di un frame trasmissibile con questa interfaccia
# Metric: parametro usato per calcolare la lunghezza dei cammini che
attraversano questa interfaccia (parametro usato nei calcoli per il routing)
RX packets:92 errors:0 dropped:0 overruns:0 frame:0
TX packets:52 errors:0 dropped:0 overruns:0 carrier:0
# dati sul traffico dell'interfaccia: quanti pacchetti abbiamo spedito e ricevuto e
collisions:0 txqueuelen:1000
# dati sul numero di collisioni avute sull'interfaccia (questo parametro fornisce
una stima della congestione della rete)
RX bytes:14162 (13.8 KiB) TX bytes:6744 (6.5 KiB)
# dati trasmessi e ricevuti
Interrupt:9 Base address:0xfc00
# dati del dispositivo fisico (interrupt e indirizzo di I/O) 44
45. Altro esempio: un'interfaccia point-to-point
• Interfacia ppp (point to point protocol)
• Al posto del dispositivo fisico abbiamo un software che
gestisce il prtocollo per le comunicazioni via modem.
# ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:151.30.166.243 P-t-P:151.6.143.246 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
Quali sono le differenze con il caso precedente?
45
46. Altro esempio: un'interfaccia point-to-point
# ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:151.30.166.243 P-t-P:151.6.143.246 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
# l'interfaccia usa il protocollo PPP (Point-to-Point Protocol)
# L'altro punto della connessione ha indirizzo IP 151.6.143.246
# Il canale e' di tipo point to point invece che broadcast
# non c'e' bisogno del protocollo ARP per risolvere gli indirizzi fisici (NOARP)
perche' non ci sono indirizzi MAC associati alla scheda
ESERCIZIO: Guardiamo le interfacce eth0 e lo
46
48. Protocollo ARP
• Le reti utilizzano gli indirizzi IP come elemento
identificativo della sorgente dei dati
• Tuttavia a livello più basso le schede di rete
ragionano in termini di indirizzi MAC
• Serve un sistema per stabilire una corrispondenza
tra IP e MAC address
• Uso di protocolli appositi (ARP=Address Resolution
Protocol) per interrogare le schede di rete remote al
fine di conoscere l'indirizzo MAC corrispondente ad
un dato indirizzo IP
• Uso di una cache per conservare le risoluzione ARP
fatte di recente
48
49. Analisi della tabella ARP
• comando ARP consente di visualizzare il contenuto della
cache ARP
• La cache ARP ci fornisce un'immagine dei nodi con cui la
macchina ha interagito
riccardo@chrysophylax:~$ sudo arp # altrimenti /usr/sbin/arp
Address HWtype Hwaddress Flags Mask Iface
ns1.ing.unimo.it ether 00:01:03:11:6B:63 C eth0
info-gw.ing.unimo.it ether 00:0A:57:05:A0:00 C eth0
riccardo@chrysophylax:~$ ping brandy.ing.unimo.it
[...]
riccardo@chrysophylax:~$ sudo arp
Address HWtype Hwaddress Flags Mask Iface
brandy.ing.unimo.it ether 00:11:11:5A:EB:41 C eth0
ns1.ing.unimo.it ether 00:01:03:11:6B:63 C eth0
info-gw.ing.unimo.it ether 00:0A:57:05:A0:00 C eth0
49
50. Analisi della tabella di routing
• Contiene le informazioni su come un pacchetto deve
essere instradato in base alla sua destinazione.
• Struttura dati chiave usata a livello di rete
• Comando principale per conoscere il contenuto della
tabella di routing:
• Comando route
50
51. Esempio di uso del comando route
$ /sbin/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.84.0 * 255.255.255.0 U 0 0 0 vmnet8
192.168.99.0 * 255.255.255.0 U 0 0 0 vmnet1
155.185.48.0 * 255.255.255.0 U 0 0 0 eth0
default info-gw.ing.uni 0.0.0.0 UG 0 0 0 eth0
• 4 entries nella tabella
• Una entry per raggiungere ogni sottorete sui è connessa
un'interfaccia di rete (prime 3 entry)
• Una entry per raggiungere “tutto il resto della rete”, ovvero il
default gateway
51
52. Analisi delle connessioni attive e delle porte
• Utilizzo dello strumento netstat
• Netstat consente di capire
– Quali connessioni TCP sono attive
– Quali porte sono usate da server che attendono
connessioni
– ...
• Noi vedremo solo alcune delle opzioni di netstat. Per
uno studio più approfondito si rimanda alla man page del
comando
52
53. Comando netstat
netstat [-tuelapn]
• -t mostra connessioni TCP
• -u mostra connessioni UDP
• NOTA: se non si mette ne -t ne -u netstat mostra tutte le
socket, anche quelle di tipo unix (non IP)
• -e mostra informzioni aggiuntive
• -l mostra le socket in stato “listen”
• -a mostra le socket in qualsiasi stato esse siano
• NOTA: se non si mette ne -l ne -a vengono mostrate solo
le socket relative a connessioni aperte
• -p mostra il programma associato a quelle socket
• -n mostra informazioni numeriche invece che simboliche
per i numeri di porta
53
54. Esempio nell'uso del comando netstat
$ netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:38960 localhost:ipp ESTABLISHED
tcp 1 0 localhost:42807 localhost:ipp CLOSE_WAIT
tcp 0 0 localhost:ipp localhost:38960 ESTABLISHED
$ netstat -ltu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:time *:* LISTEN
tcp 0 0 localhost:905 *:* LISTEN
tcp 0 0 *:discard *:* LISTEN
tcp 0 0 localhost:mysql *:* LISTEN
udp 0 0 *:xdmcp *:*
udp 0 0 localhost:sunrpc *:*
54
55. Intrpretazione dell'output
• Caso 1
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:ipp localhost:38960 ESTABLISHED
– cosa significa la coppia localhost:ipp in local address?
– cosa sinifica la coppia localhost:38960 in foreign address?
– Cosa e' lo stato ESTABLISEHED?
• Caso 2
tcp 0 0 *:time *:* LISTEN
tcp 0 0 localhost:mysql *:* LISTEN
– Cosa sono gli * negli indirizzi IP
– Cosa cambia se metto localhost al posto di *?
• Caso 3
udp 0 0 *:xdmcp *:*
– Perchè manca lo stato?
55
