Newsgroup: it.comp.os.linux.iniziare
Titolo: [slack] 2 schede di rete -> problemi con il ping


ICQ# 11129001
http://www.calogero.org/

 nulla.
E route -n che ti dice ?
Davide
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ha scritto nel messaggio
news:3C95B49C...@spam.it...
| se configuro cosi':
|
| ifconfig eth0 10.0.0.1 netmask 255.255.255.0 up
| ifconfig eth1 10.0.0.200 netmask 255.255.255.0 up
ciuspi ciuspi...
anche io ho un pc con due schede ma se do l'indirizzo
con la stessa classe la mia rh si altera e non capisce
+ nulla!
prova un po' a cambiare in 10.0.1.1 la tua 10.0.0.200
P.S.
  se di boiata picchiatemi! so solo che a casa la cosa
  non funzionava e cosi' ho risolto (a parte che ho la
  classe 192.168.x.x.)
--
[ Penguin At Work ]
-> 
http://web.tiscali.it/penguinatwork/
-> aka Fustino Di Dixan while working

Nel fausto dě di Mon, 18 Mar 2002 10:34:20 +0100, il prode _Denny_
presente alla corte di _it.comp.os.linux.iniziare_
cosě ebbe l'ardire di pronunziarsi:
| preferito non compilare il modulo, ma *embeddare* il tutto nel kernel). 
                                        ^^^^^^^^^^^
  Oh, non č che se scrivevi "di includerlo", o "di incorporarlo nel kernel"
non capivamo  ;-)
| fisicamente le 2 schede di rete esistono.
| 
| se configuro cosi':
| 
| ifconfig eth0 10.0.0.1 netmask 255.255.255.0 up
| ifconfig eth1 10.0.0.200 netmask 255.255.255.0 up
| 
| e lancio ifconfig, vedo le due schede configurate perfettamente (sono 
| sicuro che siano 2 perche' hanno un hw address diverso).
| 
| il problema e' che infilando il cavo di rete nella scheda 3com (eth1) e 
| collegandolo all'hub, riesco a pingare (da un'altra macchina in rete) 
| ENTRAMBI gli indirizzi ip 10.0.0.1 e 10.0.0.200, mentre se tolgo il cavo 
| e lo infilo in eth0 (realtek) non pingo nulla di nulla.
| 
| ora, come faccio ad essere CERTO che eth0 sia la mia scheda realtek e 
| che eth1 sia la nuova scheda 3com appena aggiunta?
  Le schede PCI sono sempre configurate prima di quelle ISA.  Fai:
ifconfig
eth0      Link encap:Ethernet  HWaddr 00:00:1C:81:62:EF
          inet addr:10.0.0.34  Bcast:10.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6610 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1659 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0
          RX bytes:2498728 (2.3 Mb)  TX bytes:131757 (128.6 Kb)
eth1      Link encap:Ethernet  HWaddr 00:A0:24:92:1F:8C
          inet addr:192.168.0.6  Bcast:192.168.0.7  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24555 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25184 errors:0 dropped:0 overruns:0 carrier:0
          collisions:290
          RX bytes:3327079 (3.1 Mb)  TX bytes:5634783 (5.3 Mb)
  Guarda gli indirizzi MAC delle due schede: "HWaddr 00:00:1C:81:62:EF" e
"HWaddr 00:A0:24:92:1F:8C" nel mio caso.  Questi numeri sono univoci per
ciascuna scheda e ti permettono di identificarle con sicurezza.  Di solito
(non nel mio caso), ifconfig riporta anche gli indirizzi di I/O e la linea di
interrupt della scheda, dalle quali pure puoi identificare la scheda PCI, che
normalmente ha un indirizzo alto, come 0xc800, da quella ISA che normalmente
ha un indirizzo basso, come 0x220.
| inoltre, come e' possibile che riesca a pingare l'ip di 2 schede se ne 
| ho collegata una sola e viceversa se collego l'altra nada?
| 
| grazie :)
  Puň dipendere dal fatto che la macchina ha un default router.  Ricevendo un
ping da un'interfaccia attiva (eth1) diretto verso l'indirizzo di una macchina
che sa risolvere sulla stessa rete (10.0.0.0), manda lei stessa la risposta
essendo il default gateway per quella rete.  Il ping per la macchina
10.0.0.200 quindi funziona anche se l'interfaccia non č attiva (eth0), viene
risposto sulla stessa interfaccia che l'ha generato (eth1).  Mentre se ti
colleghi sull'interfaccia malfunzionante (eth0) non ottieni risposta.
  Sandro
-- 
In a world without walls and fences
You would not need windows and gates.
(Confucius)

 ha scritto nel messaggio
| news:3C95B49C...@spam.it...
|| se configuro cosi':
||
|| ifconfig eth0 10.0.0.1 netmask 255.255.255.0 up
|| ifconfig eth1 10.0.0.200 netmask 255.255.255.0 up
| 
| ciuspi ciuspi...
| anche io ho un pc con due schede ma se do l'indirizzo
| con la stessa classe la mia rh si altera e non capisce
| + nulla!
| 
| prova un po' a cambiare in 10.0.1.1 la tua 10.0.0.200
|
  Giusto, mettendo la seconda interfaccia su un indirizzo di rete diverso, il
ping non dovrebbe piů essere risolto tramite il default gateway, e il
comportamento dovrebbe riflettere il vero stato delle schede.


 E route -n che ti dice ?
mi dice:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo


 colleghi sull'interfaccia malfunzionante (eth0) non ottieni risposta.
ok... allora in realta' le 2 interfacce (eth0 e eth1) vengono attivate
tramite lo script /etc/rc.d/rc.inet1 che contiene solo:
/sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.0 up
/sbin/ifconfig eth1 10.0.0.200 netmask 255.255.255.0 up
quindi niente default gateway. da un'altra macchina nella rete 
(10.0.0.2, che non ha nessun default gateway) pingo entrambi gli ip 
della prima macchina SOLO con una interfaccia di rete (la nuova scheda 
3com)... non credo percui di rientrare nel tuo esempio. oppure si e non 
ho capito niente???? :)
comunque, sicuramente l'altra scheda NON e' malfunzionante perche' se 
faccio ifconfig up SOLO su quella, tutto funziona come ha sempre 
funzionato fino a prima di aver installato la seconda eth.
grazie!


 comportamento dovrebbe riflettere il vero stato delle schede.
provero' anche cosi'. grazie.


Immagina di essere il kernel: devi mandare un pacchetto con indirizzo
10.0.0.150 al destinatario. Quel c**** di amministratore del sistema ha 
configurato i due furgoni per servire gli stessi indirizzi, 10.0.0.X.
Che fai, duplichi il pacco e lo metti su tutti e due i furgoni?
No, lo metti su uno solo. E' quello che sta succedendo sul tuo sistema.
saluti

Nel fausto dì di Mon, 18 Mar 2002 15:34:35 +0100, il prode _Denny_
presente alla corte di _it.comp.os.linux.iniziare_
così ebbe l'ardire di pronunziarsi:
|da un'altra macchina nella rete 
|(10.0.0.2, che non ha nessun default gateway) pingo entrambi gli ip 
|della prima macchina SOLO con una interfaccia di rete (la nuova scheda 
|3com)... non credo percui di rientrare nel tuo esempio. oppure si e non 
|ho capito niente???? :)
  Allora, se io ho due schede di rete installate e configurate sul mio
computer e collego ad altre macchine solo una delle due, il ping mi funziona
su entrambe le schede sulla stessa macchina.  Il sistema vede l'interfaccia
attiva e configurata con indirizzo x e quindi, dovendo spedire un ping su
quell'indirizzo, si risponde da sola senza inoltrare pacchetti verso
l'esterno.  Deve succedere qualcosa di analogo quando alla macchina giunge un
ping dall'esterno, da una delle interfacce, diretto verso la seconda scheda,
cui il sistema ha attribuito un proprio indirizzo IP.  Il ping ha successo
perché il sistema risponde alla richiesta di ping senza effettivamente usare
l'interfaccia cui il ping è diretto.
|comunque, sicuramente l'altra scheda NON e' malfunzionante perche' se 
|faccio ifconfig up SOLO su quella, tutto funziona come ha sempre 
|funzionato fino a prima di aver installato la seconda eth.
|
  Bizzarro.  Ho visto che gli indirizzi di I/O e le linee IRQ sono diverse.
Non riesco a capire cosa causi il problema.  route cosa dice?
  Sandro
-- 
"In a world without walls and fences
you would not need windows and gates."
(Confucius)

 Non riesco a capire cosa causi il problema.  route cosa dice?
mi dice:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
grazie, ciao!



mmhmm... in realta' io ho un furgone con un bel pacchetto che devo 
consegnare a 10.0.0.1. il furgone arriva a destinazione e il kernel fa 
quello che deve fare (rispondendo di aver ricevuto il pacchetto) e cosi' 
io sono sicuro di aver mandato il pacco a destinazione.
poi prendo un altro furgone con un altro pacchetto che devo consegnare a 
10.0.0.200, ma sono sicuro che ad un certo punto sulla strada manchi un 
ponte necessario a proseguire, quindi so che il pacchetto non dovrebbe 
mai arrivare a destinazione. pero' l'autista del furgone trova una 
strada alternativa e il pacchetto arriva (stranamente) a destinazione lo 
stesso, ripondendo con una bella ricevuta di ritorno :)
credo che la strada alternativa trovata dall'austista del secondo 
furgone sia spiegata nel messaggio di alessandro selli poco piu' sopra, 
in questo thread.
ciao! :)


 10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
Scusa mi spieghi perché hai due interfacce fisiche di rete (eth0 e
eth1) sulla STESSA sottorete (
10.0.0.0/24)?
??
-- 
Massimo Bacilieri AKA Crononauta 
mailto:
ulib...@libero.it
 ; ICQ:4005815
+++ antispam: l'indirizzo mittente è alterato; usare quello qui 
    sopra indicato se mi si vuole rispondere in posta.

 eth1) sulla STESSA sottorete (
10.0.0.0/24)?
??
al momento perche' non ho ancora fastweb quindi le prove
le devo fare con la stessa sottorete. sicuramente quando avro' il
collegamento attivo una scheda sara' connessa a fastweb in DHCP e l'altra
sara' su un rete privata tipo 
10.0.0.0/24
.
comunque stasera provo a cambiare sottorete, metto 
10.0.1.0/24
 e 
10.0.0.0/24
 . puo' andare bene?


 
10.0.0.0/24
 . puo' andare bene?
Esatto, poi imposti il forward tra le due interfacce con ipchains o iptables
e l'echo 1 > /proc/sys/net/ipv4/ip_forward.


 e l'echo 1 > /proc/sys/net/ipv4/ip_forward.
ok. per questo non dovrebbero esserci problemi dal momento che prima il 
router funzionava perfettamente gestendo il forward tra ppp0 e eth0 con 
iptables. ma chiaramente con 56Kbits non ci si naviga in 2 o 3 ;)
grazie!


 iptables. ma chiaramente con 56Kbits non ci si naviga in 2 o 3 ;)
Guarda che non cambia niente!!!!!
Fastweb ti assegna un indirizzo? Ok, a quella scheda attacchi il cavo, o
comunque quell'interfaccia la usi per fastweb.
Poi crei un'altra interfaccia su cui fai girare la tua LAN, imposti il
forward e navighi.
Se fastweb ti assegna un ip fisso, nessun problema, avrai una eth0 fatta con
12.34.56.78/32
 e una eth1 con 
192.168.1.0/24
.
Fai il forward fra queste due reti.


 forward e navighi.
certo. una volta messo a posto il problema di cui mi bastera' 
inizializzare la rete con un bel
/sbin/dhcpcd eth0
/sbin/ifconfig eth1 10.0.0.1 up
supponendo che ad eth0 ci sia attaccata fastweb e ad eth1 la LAN.


 supponendo che ad eth0 ci sia attaccata fastweb e ad eth1 la LAN.
Certo, ed è uguale a creare due sottoreti DISTINTE!!!
Per cui se vuoi fare le prove, devi simulare due sottoreti!


 Ma è giusto che sia così!
ok, prometto che stasera provo ad assegnare 2 sottoreti diverse.
grazie mille per i consigli :)
ciao!


 ok, prometto che stasera provo ad assegnare 2 sottoreti diverse.
mhmmmhmmm... ho provato con 10.0.0.1 su eth0 e 10.0.1.1 su eth1
(maschera a 255.255.0.0) ma il problema e' assolutamente IDENTICO.
funziona solo una scheda (pinga entrambi gli ip) e l'altra e' muta...
ma come ca@#! e' possibile????????????????????? non mi aspettavo di 
incontrare tutte queste difficolta' solo per aver aggiunto una scheda in 
piu'... boh, qualche idea?
tnx :)


 (maschera a 255.255.0.0) ma il problema e' assolutamente IDENTICO.
Bella forza, 10.0.0.1 e 10.0.1.1 con mask 255.255.0.0 è ANCORA la stessa
sottorete!!!
Scusa eh, ma 255.255.0.0 significa che la prima sottorete raccoglie gli
indirizzi da 10.0.0.1 a 10.0.254.254, la seconda... ANCHE!!!
Dovresti mettre 10.0.0.1 mask 255.255.255.0 e 10.0.1.1 mask 255.255.255.0,
allora sì che sono sottoreti distinte!!!


 allora sì che sono sottoreti distinte!!!
ok, hai ragionissimo. l'unico dubbio che ho e' di non riuscire a pingare 
  la sottorete 10.0.1.x dalla mia macchina se io faccio parte della 
sottorete 10.0.0.x. non che me ne freghi piu' di tanto, anche perche' 
una volta che ho fastweb e faccio il forwarding tra le 2 interfacce 
posso fare quello che mi pare; era solo per capire ORA se le 2 schede 
funzionano indipendentemente.
tenghiu' :)
ciao!


 funzionano indipendentemente.
Certo che pinga, se le interfacce sono fisicamente sulla stessa macchina,
quali che siano le sottoreti, tu dalla macchina le raggiungi!!!!
Se, caso diverso, la rete 
10.0.0.0/24
 fosse una LAN e tu da un client di
questa LAN volessi pingare una rete separata, come 
10.0.1.0/24
, allora
dovresti:
- sul client (es. 10.0.0.2), impostare 10.0.0.1 come default gateway.
- sul server 10.0.0.1 impostare il forward tra le due reti in modo che
faccia da router per le due sottoreti (ipotizzando che 
10.0.1.0/24
 sia una
seconda LAN distinta dalla prima).


 seconda LAN distinta dalla prima).
ok. in sostanza se da un normale client in un LAN con indirizzo 
10.0.0.0/24
 volessi pingare l'interfaccia di rete del router con 
indirizzo 
10.0.1.0/24
 NON dovrei riuscirci senza aver impostato gateway 
e forwarding, giusto?
tanto per capire se funziona, dato che per faswteb normalmente si 
aspettano anche 2 mesi prima di essere collegati :(
a-ri-grazie :)


 ha scritto nel messaggio
news:slrna9h2ds.m7...@vraptor.dynodns.net...| Se, caso diverso, la
rete 
10.0.0.0/24
 fosse una LAN e tu da un client di
| questa LAN volessi pingare una rete separata, come 
10.0.1.0/24
, allora
| dovresti:
| - sul client (es. 10.0.0.2), impostare 10.0.0.1 come default gateway.
| - sul server 10.0.0.1 impostare il forward tra le due reti in modo che
| faccia da router per le due sottoreti (ipotizzando che 
10.0.1.0/24
 sia una
| seconda LAN distinta dalla prima).
scusate se mi intrometto e premetto che sono
ignorante e che vorrei dei chiarimenti per la
soluzione che ho adottato io a casa...
2 pc di categoria 192.168.0.x
1 pc di categoria 192.168.1.x
1 server con due schede che guardano su 0.x e 1.x
per far si che il pc 1.x riesca ad arrivare ai 2 pc
0.x ho dovuto aggiungere a route (su quel pc)
un'instradamento verso eth0 dei pacchetti per 0.x se
no non capiva.
il default gw per questo pc e' la scheda 1.x del server.
e' gisuto cosi' e non ho capito che stavate dicendo
la stessa cosa? o che altro? ... idee e/o suggerimenti?
grazie.


 la stessa cosa? o che altro? ... idee e/o suggerimenti?
Fondamentalmente è quello che si diceva :-)
Però per essere precisi, la route la aggiungi se il tuo server deve fare da
router verso un gateway remoto, ma se il gateway è lui stesso allora ti
basta il forward.
Cioè, se il tuo server ha le due schede di rete, e le due reti sono su di
lui fisicamente, allora basta il forward tra le due interfacce, non c'è
bisogno di nessuna route.
Se invece il tuo server deve collegare la sua subnet a una rete attraverso
un gateway remoto, allora devi impostare una route che instradi i pacchetti
attraverso *quel* gateway.
Il primo caso è quello del server con due schede di rete, e due reti
distinte collegate ad esse.
Il secondo caso è quello banale di internet, non te ne accorgi del route
perché il demone pppd si occupa da solo di aggiungere la route opportuna,
ma se guardi la tabella di routing vedi che sull'interfaccia ppp0 è stato
aggiunto come gateway l'ip del server al quale ti colleghi, così i
pacchetti dal tuo sistema vengono indirizzati a quel gateway e da qui
possono andare su internet.
Il gateway, a sua volta, avrà impostato un forward fra le due interfacce
che collega fisicamente (una è quella cui sei collegato tu, l'altra è
quella della WAN). E ovviamente, dal tuo lato locale, avrai bisogno di un
forward tra la tua LAN e l'interfaccia che va a collegarsi al gateway.
Insomma dovrebbe essere qualcosa di questo tipo:
LAN 
192.168.0.0/24
         |
tuo server lato locale -> forward -> tuo server lato pubblico
                                                 |
                                               route 
                                                 |
                        WAN <- forward <- default gateway
 
I forward stanno sullo stesso dispositivo ma con interfacce diverse, mentre
il route c'è tra dispositivi diversi.


 aspettano anche 2 mesi prima di essere collegati :(
In pratica, la cosa funziona così: sul server che fa da router alzi due
interfacce (fisiche o virtuali, fa niente), a una colleghi la LAN e i suoi
clienti, all'altra il cavo che ti instrada sulla WAN.
Sul server imposti il forward tra le due interfacce.
Inoltre, *sempre sul server*, imposti la route per arrivare al default
gateway del provider (che è quello che ti instrada sulla WAN, ovvero
internet).
A questo punto, i tuoi clienti in LAN hanno un default gateway (il tuo
server) e una route per arrivare sulla WAN.
Se tu dalla LAN 
10.0.0.0/24
 pinghi 
10.0.1.0/24
, dovresti farcela purché sia
impostato un gateway sui client e un forward sul server, ovviamente.


 ha scritto nel messaggio
news:slrna9h9r4.p9...@vraptor.dynodns.net...
| Perň per essere precisi, la route la aggiungi se il tuo server deve fare
da
| router verso un gateway remoto, ma se il gateway č lui stesso allora ti
| basta il forward.
[cut]
mizzega che pappardella hai scritto! :)
grazie ancora per le osservazioni. ok, adesso ho le
idee un po' + chiare sui perche'.
ciauz


                         WAN <- forward <- default gateway
Ovviamente anche tra LAN e server c'è una route, se analizzi la tabella
di routing (ti presento la mia, che è eloquente, visto che ho una rete
locale, due schede di rete - una collegata alla LAN, una al modem ADSL
-, un forward impostato e poi un gateway remoto per la connessione alla
WAN tramite gateway del provider):
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.100.1   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.100.1   0.0.0.0         UG    0      0        0 ppp0
Allora, 192.168.100.1 è l'indirizzo del gateway del provider.
Le prime 3 righe indicano una route verso una rete raggiungibile, in
pratica indicano che questo computer può raggiungere le reti
192.168.100.1/32
, 
192.168.10.0/24
 e 
127.0.0.0/8
.
Queste sono semplici route che definiscono la raggiungibilità di queste
reti tramite le interfacce indicate, nota il flag U e H che significano
"up" e "host". Questo perché 192.168.100.1 è un host definito,
192.168.10.0 e 127.0.0.0 sono delle sottoreti.
Queste tre righe non "dicono" altro che il mio computer può comunicare
con queste reti, ed tra l'altro sono route che vengono aggiunge in
automatico all'attivazione delle interfacce eth1 e lo (ed è ovvio,
perché se non esistesse una route per "lo" vorrebbe dire che "lo" non
sarebbe raggiungibile, il che significa che l'interfaccia di loopback
non è attiva!!!). 
L'ultima riga invece è quella importante, perché definisce il gateway
sulla rete remota, ed è tutto aggiunto dal demone pppd quando viene
attivato: crea una route verso l'host (prima riga, 192.168.100.1, flag
"H") e lo definisce come gateway remoto (ultima riga, flag "G").
Ma comunque, se invece di ppp0 avessi un collegamento via cavo sul quale
dovessi dichiarare io semplicemente i gateway, dovrei aggiungere la
route verso il gateway come host remoto (prima riga, solo che magari
sarebbe sulla eth0 anziché ppp0) e poi dichiararlo come gateway
predefinito (ultima riga). Probabilmente basterebbe definire la route
al gateway, francamente non so come mai pppd crea *anche* una route
all'host. BOH!
Il forward serve a "congiungere" due route che portano a due interfacce
di rete, che viceversa sarebbero separate.
Per esempio, se io non impostassi il forward tra le mie interfacce di
rete, io avrei il mio server che avrebbe una route per arrivare alla LAN
e una per arrivare al gateway che mi instrada poi sulla WAN.
Ma dalla LAN non potrebbero arrivare altro che al server, non potrebbero
continuare sulla WAN!
In pratica avrei:
                  server: 
def.gw
 per LAN
LAN ---> route ---> (eh0 |   | eth1) ---> route ---> 
def.gw
 ---> WAN.
Il forward è un "ponte" che permette di unire eth0 e eth1:
LAN ---> route ---> (eth0 -fwd-> eth1) ---> route ---> 
def.gw
 ---> WAN.
In questo modo un client in LAN, indicando il tuo server come default
gateway, può approdare alle eth1 e da qui trovare una nuova route verso
un secondo gateway, che poi lo instraderà sulla WAN.
Direi che così va meglio!
E comunque prendi sempre quello che ti dico con beneficio del dubbio, in
realtà sono un grande smanettone, ma non ho mai studiato la teoria, ho
imparato quello che so facendo prove. Quando devo spiegare a qualcuno
come funzionano le cose, e tirare fuori concetti teorici, delle volte
dico delle castronerie... perché magari so che le cose funzionano in un
certo modo, e so che "così" vanno, ma se mi chiedi il perché, provo a
spiegarlo con teorie che ricreo dalla mia sperimentazione, ma che non
necessariamente sono completamente giuste.


 ha scritto nel messaggio
news:slrna9hsb5.1f...@vraptor.dynodns.net...
| Aspetta, aggiungo un paio di cose perché non sono stato poi così preciso
| e ho scritto delle mezze vaccate.
grazie ancora per l'ulteriore precisazione! apprezzo lo
sbattimento per uno che non conosci neppure...
se permetti ti tengo buono per *mie eventuali scocciature*
:)- beh! ovviamente solo se non capisco da solo.
ciauz e rigrazie
