Indice del forum www.zeroshell.net
Distribuzione Linux ZeroShell
 
 FAQFAQ   CercaCerca  GruppiGruppi   RegistratiRegistrati 
 ProfiloProfilo  Log inLog in   Messaggi privatiMessaggi privati 

Problema interfaccia BOND (Risolto - Rilascio Bugfix)

 
Nuovo argomento   Rispondi    Indice del forum -> ZeroShell
Precedente :: Successivo  
Autore Messaggio
ufoonline



Registrato: 03/07/08 22:16
Messaggi: 261

MessaggioInviato: Mar Set 14, 2010 9:44 am    Oggetto: Problema interfaccia BOND (Risolto - Rilascio Bugfix) Rispondi citando

Ciao a tutti,

Ho due firewall che hanno rispettivamente due linee ADSL e due VPN attive LAN-to-LAN in bonding.

Mi sta succedendo una cosa anomala, probabilmente per problemi sulla rete sulla fw della sede secondaria, mi cade VPN00, il bonding configurato in failover tranquillamente mi switcha sulla VPN01 che è collegata sulla linea di backup della sede principale.

Solo che ad esempio, senza messaggio alcuno sui log, stamane mi sono ritrovato (ma anche ieri) la VPN passata sulla linea di backup senza alcuna dicitura nei log:
Giorno 13/Settembre.
Citazione:

Sep 13 15:46:18 fw-2 kernel: bonding: BOND00: link status definitely down for interface VPN00, disabling it
Sep 13 15:46:18 fw-2 kernel: bonding: BOND00: making interface VPN01 the new active one.
Sep 13 15:46:23 fw-2 kernel: bonding: BOND00: link status up for interface VPN00, enabling it in 7000 ms.
Sep 13 15:46:30 fw-2 kernel: bonding: BOND00: link status definitely up for interface VPN00.

Giorno 14/Settembre:
Citazione:

Sep 14 10:01:49 fw-2 kernel: bonding: BOND00: link status definitely down for interface VPN01, disabling it
Sep 14 10:01:49 fw-2 kernel: bonding: BOND00: making interface VPN00 the new active one.
Sep 14 10:02:05 fw-2 kernel: bonding: BOND00: link status up for interface VPN01, enabling it in 7000 ms.
Sep 14 10:02:12 fw-2 kernel: bonding: BOND00: link status definitely up for interface VPN01.


Alle 10:01:49 ho scollegato io VPN01 visto che è una linea di backup e rallenta tutto (oltretutto è usata in modo esclusivo per il traffico VoIP).
Ma non risulta da nessuna parte che BOND00 abbia attivato VPN01, visto che l'ultimo messaggio indica che è ritornato su VPN00.

Cosa può essere successo?

Da notare che alle 10:01 ambidue le VPN, sia la 00 che la 01 erano in stato UP.

Grazie ciao! Smile
Top
Profilo Invia messaggio privato
ufoonline



Registrato: 03/07/08 22:16
Messaggi: 261

MessaggioInviato: Ven Set 24, 2010 10:36 am    Oggetto: Rispondi citando

Visto che non ero l'unico malcapitato al quale servisse il Failover che funzionasse da Failover sulle interfaccie BOND, ma che invece si impallava quasi sempre sulla seconda interfaccia senza più tornare indietro... dopo una lunga analisi approfondita del problema, sono riuscito a tirare le somme ed ho risolto il problema del Failover (in active-backup) sul Bonding.

La prima domanda da porci è:
* Perchè BOND00 passa su VPN01 se VPN00 è UP?
# Semplice, perchè casomai qualche errore di rete, oppure semplicemente l'inattività ha fatto resettare la VPN e quindi VPN00 va DOWN per qualche instante e BOND00 giustamente attiva VPN01.

La seconda domanda che viene spontanea è:
* Perchè BOND00 non torna su VPN00 anche se l'ho configurata come Primary Slave?
# Una piccola distrazione (capita a tutti), ha fatto sfuggire il parametro "primary=$PRIMARY" durante il modprobe del modulo bonding.. ecco spiegato l'arcano del perchè in "Views" veniva mostrato NONE alla voce "Primary Slave".

Dulcis in fondu, nella speranza che sia di vostro gradimento, e che vi risolva un problemino alquanto scomodo.. ecco il file mkbonddev modificato:

Codice:

#!/bin/sh
. /etc/kerbynet.conf
BOND="$1"
MODE="$2"
[ -z "$BOND" ] && exit 1
[ -z "$MODE" ] && MODE=0
if [ "$BOND" = remove ] ; then
  rmmod $BOND 2>/dev/null
  exit
fi
if ! [ -d /sys/class/net/$BOND ] ; then
#       BugFIX for active-backup mode, set the PRIMARY flag.
#       24-09-2010 / by Massimiliano Cianelli
        if [ "$MODE" = "1" ]; then
                PRIMARY=`cat $REGISTER/system/net/interfaces/$BOND/Primary`
                modprobe bonding mode=$MODE miimon=100 use_carrier=0 updelay=7000 primary=$PRIMARY -o$BOND
        else
                modprobe bonding mode=$MODE miimon=100 use_carrier=0 updelay=7000 -o$BOND
                #  modprobe bonding mode=$MODE -o$BOND
        fi
  NEW=`ls /proc/net/bonding/ |grep bond | tail -1`
  ip link set name $BOND dev $NEW
else
#       There we will update the PRIMARY flag.
#       If the device exist and I was called, prolly Primary Slave was changed, so I'll set it into the bond device.
        PRIMARY=`cat $REGISTER/system/net/interfaces/$BOND/Primary`
        echo $PRIMARY > /sys/class/net/$BOND/bonding/primary
fi
ifconfig $BOND up


Salvate questo file in /Database, con il nome mkbonddev, dategli i permessi 755.

Poi in nello script di avvio, in Pre Boot inserite i seguenti comandi:
Codice:
rm -fr /root/kerbynet.cgi/scripts/mkbonddev
cp /Database/mkbonddev /root/kerbynet.cgi/scripts/mkbonddev


L'ultima modifica di ufoonline il Dom Set 26, 2010 5:06 pm, modificato 3 volte
Top
Profilo Invia messaggio privato
picov



Registrato: 16/09/10 09:01
Messaggi: 37

MessaggioInviato: Ven Set 24, 2010 4:29 pm    Oggetto: Feedback sul fix Rispondi citando

Ciao, ho applicato il tuo script di fix ma non sembra essere cambiato molto.
"Primary Slave" riporta sempre a none indipendentemente dalla scelta fatta sulla primary vpn.

root> cat /root/kerbynet.cgi/scripts/mkbonddev
riporta correttamente il tuo script

ma
root> cat /proc/net/bonding/BOND00
Ethernet Channel Bonding Driver: v3.2.5 (March 21, 2008)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: VPN01
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 7000
Down Delay (ms): 0

Slave Interface: VPN00
MII Status: up
Link Failure Count: 1
Permanent HW addr: 00:ff:b1:a2:a1:b0

Slave Interface: VPN01
MII Status: up
Link Failure Count: 1
Permanent HW addr: 00:ff:ed:9c:73:88
Top
Profilo Invia messaggio privato
ufoonline



Registrato: 03/07/08 22:16
Messaggi: 261

MessaggioInviato: Ven Set 24, 2010 5:37 pm    Oggetto: Rispondi citando

Devi riavviare ZS, in modo che lo script venga chiamato... almeno dovrebbe funzionare così.

Fammi sapere, io ancora non ho avuto modo di riavviare l'FW del mio cliente.

Ho solo provato configurando a mano l'interfaccia direttamente.
Top
Profilo Invia messaggio privato
picov



Registrato: 16/09/10 09:01
Messaggi: 37

MessaggioInviato: Ven Set 24, 2010 6:03 pm    Oggetto: Rispondi citando

Si ho riavviato attivando prima i comandi in pre-boot che rimpiazzano lo script originale con il tuo.
Dopo il riavvio ho verificato con il comando cat la presenza della tua versione modificata (che è stata confermata).

Il report è quello postato e non cambia se dall'interfaccia web modifico il primary oppure elimino e ricreo il bond (c'è sempre none sul "Primary Slave").
Top
Profilo Invia messaggio privato
ufoonline



Registrato: 03/07/08 22:16
Messaggi: 261

MessaggioInviato: Ven Set 24, 2010 6:27 pm    Oggetto: Rispondi citando

picov ha scritto:
Si ho riavviato attivando prima i comandi in pre-boot che rimpiazzano lo script originale con il tuo.
Dopo il riavvio ho verificato con il comando cat la presenza della tua versione modificata (che è stata confermata).

Il report è quello postato e non cambia se dall'interfaccia web modifico il primary oppure elimino e ricreo il bond (c'è sempre none sul "Primary Slave").

Modifica la riga dove imposto la variabile PRIMARY, ho sbagliato la path Smile Piccola distrazione Razz

(Ho aggiornato il post con lo script)
Top
Profilo Invia messaggio privato
picov



Registrato: 16/09/10 09:01
Messaggi: 37

MessaggioInviato: Ven Set 24, 2010 6:33 pm    Oggetto: Rispondi citando

Ok, trovato l'errore.
E' sbagliato il path che estrae il nome del Primary.

Invece che:
PRIMARY=`cat $REGISTER/net/interface/$BOND/Primary`
deve essere:
PRIMARY=`cat $REGISTER/system/net/interfaces/$BOND/Primary`

Inoltre siccome lo script mkbonddev viene sicuramente chiamato alla creazione, questo fix funziona solo rimuovendo e ricreando il bond.

Per rendere possibile anche la modifica con il tasto configure si deve un po studiare il funzionamento degli script "configbond" e "setbond".

Attendo conferme.

--------------- AGGIORNAMENTO ----------------------
Ok, vedo che abbiamo postato quasi contemporaneamente dicendo la stessa cosa Wink
Scusa ma me ne sono accorto solo dopo aver inviato il messaggio.
------------------------------------------------------------
Top
Profilo Invia messaggio privato
ufoonline



Registrato: 03/07/08 22:16
Messaggi: 261

MessaggioInviato: Ven Set 24, 2010 6:42 pm    Oggetto: Rispondi citando

picov ha scritto:
Ok, trovato l'errore.
E' sbagliato il path che estrae il nome del Primary.

Invece che:
PRIMARY=`cat $REGISTER/net/interface/$BOND/Primary`
deve essere:
PRIMARY=`cat $REGISTER/system/net/interfaces/$BOND/Primary`

Inoltre siccome lo script mkbonddev viene sicuramente chiamato alla creazione, questo fix funziona solo rimuovendo e ricreando il bond.

Per rendere possibile anche la modifica con il tasto configure si deve un po studiare il funzionamento degli script "configbond" e "setbond".

Attendo conferme.

--------------- AGGIORNAMENTO ----------------------
Ok, vedo che abbiamo postato quasi contemporaneamente dicendo la stessa cosa Wink
Scusa ma me ne sono accorto solo dopo aver inviato il messaggio.
------------------------------------------------------------


Scuse di niente, qui lavoriamo tutti insieme per la stessa causa.. far funzionare sto James bond difettoso Razz hehhehehe

Utilizza lo script aggiornato, vedi dovrebbe anche aggiornare l'interfaccia Primary Slave. (l'ho appena ri-aggiornato)
Top
Profilo Invia messaggio privato
picov



Registrato: 16/09/10 09:01
Messaggi: 37

MessaggioInviato: Ven Set 24, 2010 6:58 pm    Oggetto: Rispondi citando

Ok, cosi è perfetto.
Funziona sia in creazione che in modifica.
In effetti ho visto che gli altri script "configbond" e "setbond" alla fine richiamano sempre "mkbonddev".

Complimenti Massimiliano.

PS:
uso ZS b13 da qualche giorno senza aver mai provato le versioni precedenti e sto cercando di capirci qualcosa: in questo caso abbiamo usato uno script in pre boot che leggendo i file da un'area permanente sostituisce il file ufficiale della distribuzione (altrimenti al reboot la modifica non sopravvive). Mi chiedevo invece come funzionano i bugfix ufficiali?
Top
Profilo Invia messaggio privato
picov



Registrato: 16/09/10 09:01
Messaggi: 37

MessaggioInviato: Ven Set 24, 2010 8:30 pm    Oggetto: PS2: Rispondi citando

Ciao ufoonline,
se posso mi permetterei di approfittare delle tue competenza per chiederti gentilmente un tuo parere su questo problema:
http://www.zeroshell.net/forum/viewtopic.php?p=9287

Grazie e saluti.
Top
Profilo Invia messaggio privato
ufoonline



Registrato: 03/07/08 22:16
Messaggi: 261

MessaggioInviato: Ven Set 24, 2010 11:14 pm    Oggetto: Rispondi citando

picov ha scritto:
Ok, cosi è perfetto.
Funziona sia in creazione che in modifica.
In effetti ho visto che gli altri script "configbond" e "setbond" alla fine richiamano sempre "mkbonddev".

Complimenti Massimiliano.

Perfetto Wink
E complimenti a te per aver fatto da betatester Wink

Citazione:

PS:
uso ZS b13 da qualche giorno senza aver mai provato le versioni precedenti e sto cercando di capirci qualcosa: in questo caso abbiamo usato uno script in pre boot che leggendo i file da un'area permanente sostituisce il file ufficiale della distribuzione (altrimenti al reboot la modifica non sopravvive). Mi chiedevo invece come funzionano i bugfix ufficiali?

Alla stessa maniera, ti inserisce uno script che viene caricato durante il preboot e fa la modifica al sistema! Smile

Solo che se non erro usa un'altra voce e non il preboot ma una dedicata.
Top
Profilo Invia messaggio privato
picov



Registrato: 16/09/10 09:01
Messaggi: 37

MessaggioInviato: Sab Set 25, 2010 10:14 pm    Oggetto: Rispondi citando

Ciao ufoonline,
forse il tuo cliente continuerà a chiamarti!!!

Ti confermo che il tuo script imposta ed aggiorna correttamente il primary dell'active backup, tuttavia ho fatto un test e sembra che lo switch fra le due connessioni non funzioni comunque bene.

A me succede questo:
1) Disattivando una VPN del BOND da un lato, quel lato passa sulla connessione secondaria del BOND mentre l'altro lato dal pannello network vede entrambe le VPN del BOND ancora UP (mentre nel pannello VPN una passa a giustamente a connecting) e rimane sulla connessione primaria -> la VPN smette di funzionare

2.a) Se dopo il punto 1) riattivo la VPN il bond non si accorge dell'evento e rimane comunque sulla secondaria -> la VPN non rifunziona

oppure

2.b) Se dopo il punto 1) dall'altro lato disattivo la VPN corrispondente a quella disattivata prima, anche li si switcha sulla connessione secondaria e la VPN riprende.

3) Se dopo il punto 2.b) (quando i BOND sono entrambi sul secondario) riattivo da ambo i lati le VPN primarie il BOND rimane comunque sul secondario (per farlo tornare sul primario devo disattivare e riattivare da ambo i lati le VPN del secondario).

Ma tu hai provato se dal tuo cliente succede la stessa cosa?
Io sto usando la 1.0B13.

Fammi sapere, saluti.


PS: senza la tua modifica nel caso 1) l'altro lato si accorge e switcha sul secondario (anche se entrambe le VPN del BOND vengono riportate in UP) quindi la VPN per lo meno rimane funzionante, anche se da li non tornerà più indietro a meno di non disattivare una delle secondarie.
Top
Profilo Invia messaggio privato
ufoonline



Registrato: 03/07/08 22:16
Messaggi: 261

MessaggioInviato: Sab Set 25, 2010 10:50 pm    Oggetto: Rispondi citando

Io ho fatto la verifica.. dal pannello dove sullo ZS che fa a VPN Server\Client vedo anche io erroneamente VPN00: UP ma se clicchi su Views ti da VPN00 Mii status down e currently active slave: VPN01.

A parte questo bug... ma a livello routing funziona tranquillamente vedo.

Se pingo continua a pingare senza problemi.

Calcola che se chiudi il server, lato VPN Client devi dargli almeno una decina di secondi prima che OpenVPN se ne accorga e tiri giù l'interfaccia mentre prova a ricollegarsi.

Rettifico.. lato VPN Client sembra che se casca la connessione, lasci l'interfaccia in UP.
Domani faccio qualche prova lasciando ambidue gli OpenVPN caricati e firewallando le porte.. in modo da emulare un vero a proprio "down".

Perchè se fa così OpenVPN diventa un bel casino... visto che tira su la VPN e te la tira giù e ti fa diventare BOND instabile.. che attiva e disattiva in continuazione un morto. Se poi non è sistemabile lato openvpn, si potrebbe pensare a una soluzione alternativa.. come aumentare il timeout per l'UP di BOND, in modo da aspettare il timeout di OpenVPN.
Top
Profilo Invia messaggio privato
picov



Registrato: 16/09/10 09:01
Messaggi: 37

MessaggioInviato: Sab Set 25, 2010 11:13 pm    Oggetto: Rispondi citando

Ti aggiungo altre info che dimostrano che in realtà l'altro lato si accorge del down ma poi la prima VPN viene riattivata e sembra che torni in up quando non può essere.

Log del lato opposto a quello in cui si disattiva una delle VPN del BOND:
kernel log
00:04:11 bonding: BOND00: link status definitely down for interface VPN00, disabling it
00:04:11 bonding: BOND00: making interface VPN01 the new active one.
00:04:16 bonding: BOND00: link status up for interface VPN00, enabling it in 7000 ms.
00:04:23 bonding: BOND00: link status definitely up for interface VPN00.
00:04:23 bonding: BOND00: making interface VPN00 the new active one.

Quindi per il kernel la VPN00 torna su ed essendo primary ritorna l'active slave, ma il log della connessione riporta (giustamente) il contrario.

VPN00 log:
00:04:11 Interface VPN00 is DOWN
00:04:16 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
00:04:16 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
00:04:16 TUN/TAP device VPN00 opened
00:04:16 Attempting to establish TCP connection with x.y.z.w:1195 [nonblock]
00:04:17 TCP: connect to x.y.z.w:1195 failed, will try again in 5 seconds: Connection refused
00:04:23 TCP: connect to x.y.z.w:1195 failed, will try again in 5 seconds: Connection refused
00:04:59 message repeated 6 times
00:05:17 message repeated 3 times
00:05:23 TCP: connect to x.y.z.w:1195 failed, will try again in 5 seconds: Connection refused
00:05:59 message repeated 6 times
00:06:23 message repeated 4 times
00:06:29 TCP: connect to x.y.z.w:1195 failed, will try again in 5 seconds: Connection refused
00:07:05 message repeated 6 times
00:08:11 message repeated 11 times
00:09:17 message repeated 11 times
Top
Profilo Invia messaggio privato
ufoonline



Registrato: 03/07/08 22:16
Messaggi: 261

MessaggioInviato: Sab Set 25, 2010 11:22 pm    Oggetto: Rispondi citando

Si l'avevo letto anche io... per questo ho tirato le conclusioni di cui sopra, ovvero... se non possiamo dire a openvpn tieni giù st'interfaccia finchè non sei connesso, bhe allora... rallentiamo lo switch-back all'interfaccia primaria, e diciamo a BOND00 .. hey aspetta 20secondi invece di 7 per riattivare l'interfaccia.

Domani voglio verificare e al massimo fò questa modifica sullo script per cambiare i parametri di BOND00.

Come si dice.. se maometto non va alla montagna, è la montagna che va da maometto Razz
Top
Profilo Invia messaggio privato
ufoonline



Registrato: 03/07/08 22:16
Messaggi: 261

MessaggioInviato: Dom Set 26, 2010 9:12 am    Oggetto: Rispondi citando

Prova ad inserire questo parametro su ambidue i capi della vpn:
--up-delay

A me sembra funzionare, anche se mostra erroneamente sul pannello semprel o stato UP anche se la VPN è down.. però nello stato VIEW riporta mii down e dal dmesg non passa più avanti e indietro.

Fammi sapere Smile

Dopo che mi sto iscemonendo da un paio d'ore.. ho capito il problema del file vpn_mii, probabilmente non ha qualche path settata, e quindi non carica ifconfig.

Basta modificare le due righe con ifconfig e mettere /sbin/ifconfig.

Così:
Codice:

#!/bin/sh
. /etc/kerbynet.conf
export INTERFACE="$1"
[ -z "$INTERFACE" ] && exit 1
if [ "$INTERFACE" == VPN99 ] ; then
  exit
fi
export SEM="/tmp/VPN_MII_$INTERFACE"
[ -f $SEM ] && exit 0
echo  > $SEM
(
CONFIG="$REGISTER/system/net/interfaces/$INTERFACE"
if ! cd "$CONFIG" 2> /dev/null ; then
  rm -f $SEM
  exit
fi
NUM=${INTERFACE:3:2}
if [ "${NUM:0:1}" == 0  ] ; then
   NUM=${NUM:1:1}
fi
MGT=$[34000+$NUM]
DOWN=""
while true ; do
  STATUS=`cat $CONFIG/STATUS 2>/dev/null`
  if [ "$STATUS" = up ] ; then
    if   echo state | nc -w1 127.0.0.1 $MGT 2>/dev/null | grep -q "CONNECTED" ; then
      /sbin/ifconfig $INTERFACE up
      $SCRIPTS/routerconfig >/dev/null
      logger -t ${INTERFACE}_L2L "Interface $INTERFACE is UP"
      rm -f $SEM
      exit
    else
      if [ -z "$DOWN" ] ; then
        /sbin/ifconfig $INTERFACE down
        DOWN=yes
        logger -t ${INTERFACE}_L2L "Interface $INTERFACE is DOWN"
      fi
    fi
  else
    rm -f $SEM
    exit
  fi
  sleep 2
done

) &
Top
Profilo Invia messaggio privato
picov



Registrato: 16/09/10 09:01
Messaggi: 37

MessaggioInviato: Dom Set 26, 2010 4:05 pm    Oggetto: Rispondi citando

ufoonline ha scritto:
Prova ad inserire questo parametro su ambedue i capi della vpn:
--up-delay


Perfetto.
Con questo parametro (ed il tuo fix per impostare correttamente il primary), riattivando la VPN primaria la connessione in failover ripassa correttamente su quella (e non si perde neppure un ping!).

Ecco il log:
16:49:41 bonding: BOND00: Setting VPN00 as primary slave. (<-- ecco l'effetto del tuo fix)
16:49:50 bonding: BOND00: link status up for interface VPN00, enabling it in 7000 ms.
16:49:57 bonding: BOND00: link status definitely up for interface VPN00.
16:49:57 bonding: BOND00: making interface VPN00 the new active one.
16:49:57 bonding: BOND00: first active interface up!
16:50:08 bonding: BOND00: link status up for interface VPN01, enabling it in 7000 ms.
16:50:15 bonding: BOND00: link status definitely up for interface VPN01.
... Interrompo la VPN00 primaria dall'altro lato
16:52:41 bonding: BOND00: link status definitely down for interface VPN00, disabling it
16:52:41 bonding: BOND00: making interface VPN01 the new active one.
... Riattivo la VPN00 primaria dall'altro lato
16:53:38 bonding: BOND00: link status up for interface VPN00, enabling it in 7000 ms.
16:53:45 bonding: BOND00: link status definitely up for interface VPN00.
16:53:45 bonding: BOND00: making interface VPN00 the new active one.


Confermo inoltre che anche la modifica del path sullo script "vpn_mii" fa funzionare correttamente il pannello informativo del BOND.


A questo punto credo che il problema dei BOND in failover è risolto definitivamente (grazie a ufoonline) e mi sembra che Fulvio abbia abbastanza materiale per fissare ufficialmente il problema visto che che non mi sembra una cosetta da poco.
Ma sulle precedenti versioni la situazione era la stessa o è un problema della b13? (lo chiedo perché se così fosse allora il failover sui bond non ha mai funzionato!)
Top
Profilo Invia messaggio privato
ufoonline



Registrato: 03/07/08 22:16
Messaggi: 261

MessaggioInviato: Dom Set 26, 2010 5:04 pm    Oggetto: Rispondi citando

Alleluja =)

Finalmente cel'abbiamo fatta! Smile

Grazie per il betatesting, adesso finalmente abbiamo il failover che funziona adhoc Wink

Per quanto riguarda la domanda.. non ti sò dire se il failover sul bond abbia mai funzionato, perchè i due firewall che ho che lo utilizzano hanno girato per qualche giorno con la b12 e poi l'ho upgradati alla b13, quindi eventuali problemi non hanno avuto modo di apparire.

Però cercando in giro, è un problema conosciuto il non funzionamento del BOND in failover su ZS... solo che nessuno s'era mai messo a cercare il perchè non funzionasse.
Top
Profilo Invia messaggio privato
Mostra prima i messaggi di:   
Nuovo argomento   Rispondi    Indice del forum -> ZeroShell Tutti i fusi orari sono GMT + 1 ora
Pagina 1 di 1

 
Vai a:  
Non puoi inserire nuovi argomenti
Non puoi rispondere a nessun argomento
Non puoi modificare i tuoi messaggi
Non puoi cancellare i tuoi messaggi
Non puoi votare nei sondaggi


Powered by phpBB © 2001, 2005 phpBB Group
phpbb.it