> 1. Meglio tcp o udp (openvpn usa udp)
gestisce lui in automatico quando usare udp o tcp a seconda di quello
che è meglio in quel momento
> 2. E' possibile avere un sistema dhcp tipo openvpn che assegni ai
> client vpn un'indirizzo?
non integrato in tincd
Saverio
__
Ciao non so cosa ho fatto ma adesso la vpn funzia.
Due domande:
1. Meglio tcp o udp (openvpn usa udp)
2. E' possibile avere un sistema dhcp tipo openvpn che assegni ai
client vpn un'indirizzo?
Ciao
2011/9/1 Filippo Sallemi :
> Allora a questo punto facendo ping da 192.168.100.2 a 192.168.100.1
>
Allora a questo punto facendo ping da 192.168.100.2 a 192.168.100.1
ottengo questo:
root@nano:/etc/tinc/meshboard# ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
From 192.168.100.1 icmp_seq=1 Destination Net Unknown
From 192.168.100.1 icmp_seq=2 Destination Net Unknown
> ConntectTo = server
questo è sbagliato, "ConnectTo"
era questo il problema ?
Saverio
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless
Ecco qui in dettaglio:
[tinc.conf on Laptop]
Name = nano
ConntectTo = server
TCPOnly = yes
AddressFamily = ipv4
Device = /dev/net/tun
PrivateKeyFile = /etc/tinc/meshboard/rsa_key.priv
Mode = switch
[hosts/nano on server and laptop]
Subnet = 192.168.100.0/24
-BEGIN RSA PUBLIC KEY-
...
puoi lanciare
tinc -n meshboard -d2 -D
e incollarci l'output ?
io lo ho sempre usato con
Mode = switch
Se non lo hai già fatto leggi qui:
http://wiki.ninux.org/TincVPN
mi raccomando
ConntectTo = server
con gli spazi
Saverio
Il 01 settembre 2011 14:43, Filippo Sallemi ha scritto:
> Cia
Ciao Claudio,
ma in verità ho provato ad aggiungere l'opzione -D -d5 ma mi dice solo
root@nano:/etc/tinc/meshboard# tincd -D -d5 -n meshboard
tincd 1.0.13 (May 12 2010 22:10:20) starting, debug level 5
/dev/net/tun is a Linux tun/tap device (tun mode)
Executing script tinc-up
Listening on 0.0.0.0
Ciao Filippo
Il 01 settembre 2011 14:43, Filippo Sallemi ha scritto:
> Ciao Ragazzi,
> è da ieri che sto sclerando con tinc per una semplice VPN.
>
> Ho un Server in francia ed un portatile qui in Sicilia. Qui di seguito
> i file tincd.conf del server in francia e il mio laptop.
>
> [Server]
> Na
Ciao Ragazzi,
è da ieri che sto sclerando con tinc per una semplice VPN.
Ho un Server in francia ed un portatile qui in Sicilia. Qui di seguito
i file tincd.conf del server in francia e il mio laptop.
[Server]
Name=server
AddressFamily=ipv4
BindToInterface=eth0
Device=/dev/net/tun
PrivateKeyFile=
On dom, lug 03, 2011 at 10:26:29 +0200, Gioacchino Mazzurco wrote:
> ho provato ma viene un listone enorme di warning unknown packet type
azz :/ quei warning rompono parecchio...visto che ora l'interesse e`
capire se escono pacchetti frammentati o no, un semplice
| grep -v warning
potrebbe aiuta
si disattivando non schizza piu' la cpu anche se la banda resta uguale
P.S. metti in cc wireless quando rispondi ;)
Il 03 luglio 2011 22:27, Antonio Quartulli ha scritto:
> On dom, lug 03, 2011 at 10:20:13 +0200, Gioacchino Mazzurco wrote:
>> > come vedi che batman frammenta? se usi batctl td do
ho provato ma viene un listone enorme di warning unknown packet type
Il 03 luglio 2011 22:24, Antonio Quartulli ha scritto:
> On dom, lug 03, 2011 at 10:20:13 +0200, Gioacchino Mazzurco wrote:
>> > come vedi che batman frammenta? se usi batctl td dovresti vedere i
>> me ne accorgo perche' schizza
> come vedi che batman frammenta? se usi batctl td dovresti vedere i
me ne accorgo perche' schizza la cpu
che parametro devo passare a td per farmi dire la dimensione dei pacchetti?
1280 l'ho settato a mano sulle interfacce sui computer con iperf
Il 03 luglio 2011 19:47, Antonio Quartulli ha sc
On dom, lug 03, 2011 at 07:41:24 +0200, ZioPRoTo (Saverio Proto) wrote:
> OK sembra un problema specifico di batman... non so aiutarti.
>
> Saverio
>
>
> Il 03 luglio 2011 16:43, Gioacchino Mazzurco ha
> scritto:
> > nonostante l' mtu sia settato a 1280 ( quello dei pc con iperf ) la
> > cpu d
OK sembra un problema specifico di batman... non so aiutarti.
Saverio
Il 03 luglio 2011 16:43, Gioacchino Mazzurco ha scritto:
> nonostante l' mtu sia settato a 1280 ( quello dei pc con iperf ) la
> cpu della pico schizzava uguale, ho disabilitato la frammentazione su
> batman-adv la banda ora
nonostante l' mtu sia settato a 1280 ( quello dei pc con iperf ) la
cpu della pico schizzava uguale, ho disabilitato la frammentazione su
batman-adv la banda ora resta piu' o meno uguale ma la cpu non schizza
piu'...
perche' batman frammenta anche se non dovrebbe essere necessario? (
wireshark dic
e' strano..
perche' io sto usando ipv6 per fare i test quindi il path mtu
discovery dovrebbe funzionare e in effetti riducendo l'mtu a 1280 e
disabilitando cipher ottengo un misero raddoppio della banda quando va
bene...
Il 03 luglio 2011 14:37, Darkman ha scritto:
> Quello che va meglio :)
> Ce
Quello che va meglio :)
Ce ne saranno una dozzina nel kernel, aggiungili.
Così, a naso, vista la natura particolare del canale, un algo abbastanza
tollerante alle perdite/timeout.
Ma questo solo per capire sa cambia qualcosa o siamo sempre con gli stessi
valori..
Il giorno 03 luglio 2011 14:23, Gi
> Facendo dei test mi sono accorto che le vpn con tinc installato sui
> nodi ci vanno max a 100k anche se la banda dell'adsl e' molta di
> piu'... ho cominciato a cercare ed ho letto che la causa e'
> probabilmente la CPU che non ce la fa a fare encryption decryption
> piu' velocemente di cosi'
c
sulla mia macchina sembra che siano disponibili solo cubic e reno
Il 03 luglio 2011 14:23, Gioacchino Mazzurco ha scritto:
> non so quale usa di default tu quale mi consigli di usare?
>
> Il 03 luglio 2011 14:18, Darkman ha scritto:
>> Bene, ora puoi ripetere le prove cambiando l'algoritmo di co
non so quale usa di default tu quale mi consigli di usare?
Il 03 luglio 2011 14:18, Darkman ha scritto:
> Bene, ora puoi ripetere le prove cambiando l'algoritmo di controllo di
> congestione sul client iperf.
> Cosa stai usando ora? Reno?
>
> Il giorno 03 luglio 2011 14:09, Gioacchino Mazzurco
>
Bene, ora puoi ripetere le prove cambiando l'algoritmo di controllo di
congestione sul client iperf.
Cosa stai usando ora? Reno?
Il giorno 03 luglio 2011 14:09, Gioacchino Mazzurco
ha scritto:
> altri test fissando la quantita'
>
> [ 4] 0.0-62.2 sec 2.00 MBytes 270 Kbits/sec
> [ 4] 0.0-55.
ma infatti il non era per confrontare le prestazioni (mesh wireless)
vs (tinc via internet)
era per confrontare (internet) vs (tinc via internet)
Il 03 luglio 2011 14:14, Antonio Quartulli ha scritto:
> On dom, lug 03, 2011 at 01:57:00 +0200, Gioacchino Mazzurco wrote:
>> senza tinc la configura
On dom, lug 03, 2011 at 01:57:00 +0200, Gioacchino Mazzurco wrote:
> senza tinc la configurazione rimane uguale ma il traffico al posto di
> passare dal tunnel via internet passa solo attraverso i link wireless
scusa e come fai a confrontare i due valori se li fai passare da
infrastrutture diverse
altri test fissando la quantita'
[ 4] 0.0-62.2 sec 2.00 MBytes 270 Kbits/sec
[ 4] 0.0-55.3 sec 2.00 MBytes 304 Kbits/sec
[ 4] 0.0-64.2 sec 2.00 MBytes 261 Kbits/sec
[ 4] 0.0-58.8 sec 2.00 MBytes 285 Kbits/sec
[ 4] 0.0-99.6 sec 2.00 MBytes 169 Kbits/sec
[ 4] 0.0-96.4 sec
senza tinc la configurazione rimane uguale ma il traffico al posto di
passare dal tunnel via internet passa solo attraverso i link wireless
Il 03 luglio 2011 13:51, Antonio Quartulli ha scritto:
> On dom, lug 03, 2011 at 01:48:37 +0200, Gioacchino Mazzurco wrote:
>> il test e' sempre PC( iperf -c
On dom, lug 03, 2011 at 01:48:37 +0200, Gioacchino Mazzurco wrote:
> il test e' sempre PC( iperf -c ) <-- cavo lan --> Piconstation (
> btman-adv + tinc )<-- tinc ---> PC( batman-adv + tinc + iperf -s)
anche senza TINC la configurazione rimane uguale? scusa ma non ho capito
questo daalle mail prec
il test e' sempre PC( iperf -c ) <-- cavo lan --> Piconstation (
btman-adv + tinc )<-- tinc ---> PC( batman-adv + tinc + iperf -s)
>usa un vincolo temporale o quantitativo, sti valori sono troppo
>deviati..
quei test non sono fatti in parallelo sono fatti in modo sequenziale
quindi volta per volt
Magari se scegliessi un test "unico" sarebbe anche meglio,
usa un vincolo temporale o quantitativo, sti valori sono troppo
deviati..
Se non mi dicessi della CPU a palla, guardando sta roba ti direi che è
congestione..
Il giorno 03 luglio 2011 13:31, Gioacchino Mazzurco
ha scritto:
> altra serie d
ma il test senza TINC lo hai fatto dal PC o sempre dalla PICO verso la
PICO?
On dom, lug 03, 2011 at 01:31:31 +0200, Gioacchino Mazzurco wrote:
> altra serie di test
>
> [ 4] 0.0-18.8 sec 384 KBytes 167 Kbits/sec
> [ 4] 0.0-17.5 sec 384 KBytes 180 Kbits/sec
> [ 4] 0.0-20.0 sec 384
On 7/3/11 1:16 PM, Darkman wrote:
> Il sintomo è abbastanza chiaro, ma dubito sia colpa della CPU o meglio,
> secondo me qualcosa
> è stata scritta male, 100Kbps sono davvero ridicoli. A maggior ragione
> quando ste cpu hanno anche qualche set dedicato
> alla crittografia simmetrica...
Gioacchino
altra serie di test
[ 4] 0.0-18.8 sec 384 KBytes 167 Kbits/sec
[ 4] 0.0-17.5 sec 384 KBytes 180 Kbits/sec
[ 4] 0.0-20.0 sec 384 KBytes 157 Kbits/sec
[ 4] 0.0-21.1 sec 384 KBytes 149 Kbits/sec
[ 4] 0.0-23.5 sec 512 KBytes 178 Kbits/sec
[ 4] 0.0-32.3 sec 384 KBytes
Il sintomo è abbastanza chiaro, ma dubito sia colpa della CPU o meglio,
secondo me qualcosa
è stata scritta male, 100Kbps sono davvero ridicoli. A maggior ragione
quando ste cpu hanno anche qualche set dedicato
alla crittografia simmetrica...
Il giorno 03 luglio 2011 13:04, Gioacchino Mazzurco
ha
ma il problema sembra proprio l'eccessivo utilizzo di cpu per la vpn
perche' stando in ssh sulla picostation mentre c'e' traffico che passa
sulla vpn diventa completamente unresponsive non sente nemmeno ctrl+c
sulla shell... quando il traffico finisce mi esegue tutto quello che
gli avevo mandato ne
>Hai la possibilità di usare una CPU + potente (tincare dal PC)?
dovrei installarmi anche batman-adv sul pc...
Il 03 luglio 2011 12:58, Darkman ha scritto:
> E' chiaro che non può essere il tuo upstream,
> ma sei certo che il collo di bottiglia non sia nella capacità di sta rete
> mesh tunnellat
E' chiaro che non può essere il tuo upstream,
ma sei certo che il collo di bottiglia non sia nella capacità di sta rete
mesh tunnellata?
Hai provato a lanciare 2 iperf in parallelo?
Hai la possibilità di usare una CPU + potente (tincare dal PC)?
Il giorno 03 luglio 2011 12:34, Gioacchino Mazzurco
la picostation a e la z sono la stessa picostation... dalla
picostation a posso decidere se accendere tinc e quindi far passare
traffico mesh su internet oppure se usare solo i link wireless
dal computer pocco decidere sia di usare la picostation come gw sia di
usare il router adsl
le casistiche
Fammi capire:
- tra le tua pico(A) e quella(Z) con l'adsl ci sono diversi nodi e con iperf
hai risultati di 20Kbps (A->Z) in L3 puro ? Mentre se usi tinc va a 100Kbps?
- chi sono gli end-point tinc?
Il giorno 03 luglio 2011 12:12, Gioacchino Mazzurco
ha scritto:
> senza tinc praticamente non
senza tinc praticamente non c'e' connettivita' ( a volte va ma roba
tipo 20k perche' sono un sacco di op alcuni dei quali fanno schifo...)
se invece faccio iperf passando per internet senza tinc ottengo
risultati sempre sopra i 500KB/s
Il 03 luglio 2011 12:01, Darkman ha scritto:
> Hai gia contr
Hai gia controllato i valori tra le 2 pico con e senza tinc?
Il giorno 03 luglio 2011 11:45, Gioacchino Mazzurco
ha scritto:
> iperf -c su computer che usa una picostation come gateway ->
> Picostation con tinc <- adsl 8 megabit -> iperf --server su
> eigenlab.org
>
>
> Il 03 luglio 2011 11:33,
iperf -c su computer che usa una picostation come gateway ->
Picostation con tinc <- adsl 8 megabit -> iperf --server su
eigenlab.org
Il 03 luglio 2011 11:33, Darkman ha scritto:
> 100kbps mi pare davvero troppo poco anche per quelle cessonanocpu.
> Come li hai ottenuti sti valori?
>
> Il giorno
100kbps mi pare davvero troppo poco anche per quelle cessonanocpu.
Come li hai ottenuti sti valori?
Il giorno 03 luglio 2011 11:10, Gioacchino Mazzurco
ha scritto:
> Ciao a tutti!
>
> Facendo dei test mi sono accorto che le vpn con tinc installato sui
> nodi ci vanno max a 100k anche se la banda
Digest = digest (sha1)
The digest algorithm used to authenticate UDP packets.
Any digest supported by OpenSSL is recognised. Further�
more, specifying "none" will turn off packet authentication.
questa invece penso che convenga lasciarla cosi' anche se consuma un
po d
Ciao a tutti!
Facendo dei test mi sono accorto che le vpn con tinc installato sui
nodi ci vanno max a 100k anche se la banda dell'adsl e' molta di
piu'... ho cominciato a cercare ed ho letto che la causa e'
probabilmente la CPU che non ce la fa a fare encryption decryption
piu' velocemente di cos
> se l'mss viene ridotto iptables splitta il pacchetto in due prima di
> forwardarlo?!
no, modifica il pacchetto syn in modo che venga negoziata per la
sessione TCP una mss che ti permette di non avere frammenti.
Saverio
___
Wireless mailing list
Wirele
On dom, gen 09, 2011 at 05:24:21 +0100, Darkman wrote:
> > Visto che ci sono faccio una domanda..
> >
> >> > > iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS
> >> > > --clamp-mss-to-pmtu
> >
> > se l'mss viene ridotto iptables splitta il pacchetto in due prima di
> > forwarda
Visto che ci sono faccio una domanda..
> > iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS
> > --clamp-mss-to-pmtu
se l'mss viene ridotto iptables splitta il pacchetto in due prima di
forwardarlo?!
No, che vuoi splittare un syn?
__
On dom, gen 09, 2011 at 04:46:18 +0100, Gioacchino Mazzurco wrote:
> no quella e' la frammentazione, famosa per uccidere le prestazioni...
bhe e` stata deprecata anche per questo infatti :P
Il dubbio mi sorgeva appunto per questo motivo :D grazie per il
chiarimento ;)
--
Antonio Quartulli
..e
no quella e' la frammentazione, famosa per uccidere le prestazioni...
Il giorno 09 gennaio 2011 16:42, Antonio Quartulli ha
scritto:
> On dom, gen 09, 2011 at 04:36:38 +0100, Gioacchino Mazzurco wrote:
> > no l' mss ( max segment size ) e' un parametro del pacchetto tcp che
> viene
> > letto dal
On dom, gen 09, 2011 at 04:36:38 +0100, Gioacchino Mazzurco wrote:
> no l' mss ( max segment size ) e' un parametro del pacchetto tcp che viene
> letto dall' applicazione ( per esempio il browser web o il server web),
> quando al server web arriva una richiesta con pacchetti tcp il cui mss e'
> set
no l' mss ( max segment size ) e' un parametro del pacchetto tcp che viene
letto dall' applicazione ( per esempio il browser web o il server web),
quando al server web arriva una richiesta con pacchetti tcp il cui mss e'
settato a un tot lui rispondera' con segmenti di dimensione massima minore o
u
Visto che ci sono faccio una domanda..
> > > iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS
> > > --clamp-mss-to-pmtu
se l'mss viene ridotto iptables splitta il pacchetto in due prima di
forwardarlo?!
Ma perchè non si e` pensato di usare un valore di MTU uguale per tutti?
-
si puo' fare anche cosi' ma e' piu' sensato metterlo solo in rc.local
Il giorno 09 gennaio 2011 15:07, ZioPRoTo (Saverio Proto) <
ziopr...@gmail.com> ha scritto:
> altrimenti fai un tinc-down con questa:
>
> iptables -D FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS
> --clamp-mss-to-pmtu
altrimenti fai un tinc-down con questa:
iptables -D FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS
--clamp-mss-to-pmtu
Saverio
Il 07 gennaio 2011 18:30, Gioacchino Mazzurco
ha scritto:
> ciao a tutti nel wiki nella pagina tinc viene suggerito di mettere questa
> riga
>
> iptables -A F
ciao a tutti nel wiki nella pagina tinc viene suggerito di mettere questa
riga
iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS
--clamp-mss-to-pmtu
su tinc-up
solo che tinc-up viene eseguito ogni volta che il tunnel e viene ritirato su
dopo esser caduto per qualche motivo quin
>mastava fare:
>mknod /dev/net/tun c 10 200
avevo gia tentato quella strada li ma moriva lo stesso cambiava solo il
messaggio di errore prima diceva no such file or directory e dopo coldn't
open device...
e non era una questione di permessi ( li avevo settati correttamente
guardando sul server di
> SOLVED!
>
> Ricompilando il kernel mettendo tun/tap come modulo invece che inserirlo
> direttamente nel kernel
> e caricandolo a mano all'avvio prima di accendere tincd funziona!
si ma non è magia.
mastava fare:
mknod /dev/net/tun c 10 200
si vede che quando carichi il modulo viene fatto autom
SOLVED!
Ricompilando il kernel mettendo tun/tap come modulo invece che inserirlo
direttamente nel kernel
e caricandolo a mano all'avvio prima di accendere tincd funziona!
2010/12/20 Gioacchino Mazzurco
> quando provo ad avviare tinc muore all'istante e in /var/log/messages trovo
> questo
>
> De
Michele,
non mi sembra giusto che te la stia prendendo solo con Saverio.
La decisione, come riportato nell'email che ti ha inviato Saverio, è
stata persa da tutta la comunity e non dal singolo.
Quindi se vuoi contestare la decisione devi rivolgerti a tutti.
Ciao
Marco
Michele Favara Pedarsi wr
Ciao Michele,
ti scrivo dal Fusolab dove ho parlato con gli altri ragazzi di Ninux.
ti vogliamo comunicare che dopo il comportamento nei confronti della
community abbiamo deciso di non collegarti alla VPN per il momento.
Saverio
Il 22 febbraio 2010 05.02, Michele Favara Pedarsi
ha scritto:
60 matches
Mail list logo
