Re: [Ninux-Wireless] Tinc
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 tonyp...@gmail.com: 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 From 192.168.100.1 icmp_seq=3 Destination Net Unknown From 192.168.100.1 icmp_seq=4 Destination Net Unknown From 192.168.100.1 icmp_seq=5 Destination Net Unknown From 192.168.100.1 icmp_seq=6 Destination Net Unknown From 192.168.100.1 icmp_seq=7 Destination Net Unknown From 192.168.100.1 icmp_seq=8 Destination Net Unknown From 192.168.100.1 icmp_seq=9 Destination Net Unknown From 192.168.100.1 icmp_seq=10 Destination Net Unknown root@nano:/etc/tinc/meshboard# route -n Tabella di routing IP del kernel Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 meshboard 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0 10.0.0.0 0.0.0.0 255.0.0.0 U 1 0 0 eth0 0.0.0.0 10.112.248.1 0.0.0.0 UG 0 0 0 eth0 Sul server invece : root@jigen:/etc/tinc/meshboard/hosts# ping 192.168.100.2 PING 192.168.100.2 (192.168.100.2) 56(84) bytes of data. ^C --- 192.168.100.2 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3023ms root@jigen:/etc/tinc/meshboard/hosts# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 meshboard 95.142.172.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 0.0.0.0 95.142.175.254 0.0.0.0 UG 0 0 0 eth0 ??? Il 01 settembre 2011 17:42, ZioPRoTo (Saverio Proto) ziopr...@gmail.com ha scritto: ConntectTo = server questo è sbagliato, ConnectTo era questo il problema ? Saverio ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless -- Filippo Sallemi -- Filippo Sallemi ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Tinc
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 ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Tinc
Ciao Filippo Il 01 settembre 2011 14:43, Filippo Sallemi tonyp...@gmail.com 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] Name=server AddressFamily=ipv4 BindToInterface=eth0 Device=/dev/net/tun PrivateKeyFile=/etc/tinc/meshboard/rsa_key.priv Mode=switch [Sicilia] Name=nano ConntectTo=server TCPOnly=yes AddressFamily=ipv4 BindToInterface=wlan0 Device=/dev/net/tun PrivateKeyFile=/etc/tinc/meshboard/rsa_key.priv i file contenuti all'interno della cartella hosts contengono: [Sicilia] Subnet = 192.168.100.0/24 -BEGIN RSA PUBLIC KEY- ... -END RSA PUBLIC KEY- [Server] devi stare attento al nome di questo file Server != server cmq se esegui tinc con -D -d 5 ti può aiutare, è molto verboso... -- Claudio pub 1024D/0DFD7CBB C94D 759A 2EF0 172F 9673 65E4 C4C1 8627 0DFD 7CBB ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Tinc
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 port 655 Ready Entrambe le macchine dicono questo e nessun'altro messaggio di debug viene stampato. Cmq adesso controllo se ho scritto tutto correttamente. Ciao Il 01 settembre 2011 15:07, Claudio claudyu...@gmail.com ha scritto: Ciao Filippo Il 01 settembre 2011 14:43, Filippo Sallemi tonyp...@gmail.com 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] Name=server AddressFamily=ipv4 BindToInterface=eth0 Device=/dev/net/tun PrivateKeyFile=/etc/tinc/meshboard/rsa_key.priv Mode=switch [Sicilia] Name=nano ConntectTo=server TCPOnly=yes AddressFamily=ipv4 BindToInterface=wlan0 Device=/dev/net/tun PrivateKeyFile=/etc/tinc/meshboard/rsa_key.priv i file contenuti all'interno della cartella hosts contengono: [Sicilia] Subnet = 192.168.100.0/24 -BEGIN RSA PUBLIC KEY- ... -END RSA PUBLIC KEY- [Server] devi stare attento al nome di questo file Server != server cmq se esegui tinc con -D -d 5 ti può aiutare, è molto verboso... -- Claudio pub 1024D/0DFD7CBB C94D 759A 2EF0 172F 9673 65E4 C4C1 8627 0DFD 7CBB ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless -- Filippo Sallemi ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Tinc
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 tonyp...@gmail.com 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] Name=server AddressFamily=ipv4 BindToInterface=eth0 Device=/dev/net/tun PrivateKeyFile=/etc/tinc/meshboard/rsa_key.priv Mode=switch [Sicilia] Name=nano ConntectTo=server TCPOnly=yes AddressFamily=ipv4 BindToInterface=wlan0 Device=/dev/net/tun PrivateKeyFile=/etc/tinc/meshboard/rsa_key.priv i file contenuti all'interno della cartella hosts contengono: [Sicilia] Subnet = 192.168.100.0/24 -BEGIN RSA PUBLIC KEY- ... -END RSA PUBLIC KEY- [Server] Address = 95.142.174.146 Subnet = 192.168.100.0/24 -BEGIN RSA PUBLIC KEY- ... -END RSA PUBLIC KEY- Premetto che vengo da openvpn e per quanto dicono sia complessa mi ha sempre funzionato a primo colpo. Con Tinc non capisco dove sbaglio. Ovviamente i file all'interno della cartella hosts sono stati correttamente scambiati tra le due macchine ma quando faccio ping da una macchina verso l'altra non ottengo risultati. Premetto inoltre che la macchina server non ha alcun firewall e se faccio un nmap -p 655 mi viene detto che la porta è aperta. Ovviamente neanche il laptop ha firewall attivi ma è dietro nat. Ho sempre sentito parlare Saverio e altri su quanto tinc sia valido e mi piacerebbe passare a questo. P.S. Le versioni di tinc che ho sono per quanto riguarda il laptop 1.0.13 e sul server 1.0.11 ma non penso che questo sia il problema. Sto perdendo la pazienza -- Filippo Sallemi ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Tinc
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- ... -END RSA PUBLIC KEY- [tinc.conf on server] Name = server AddressFamily = ipv4 #BindToInterface = eth0 Device = /dev/net/tun PrivateKeyFile = /etc/tinc/meshboard/rsa_key.priv Mode = switch [hosts/server on server and laptop] Address = 95.142.174.146 Subnet = 192.168.100.0/24 -BEGIN RSA PUBLIC KEY- ... -END RSA PUBLIC KEY- ed ecco il debug di tinc su entrambe le macchine root@nano:/etc/tinc/meshboard# tincd -n meshboard -d2 -D tincd 1.0.13 (May 12 2010 22:10:20) starting, debug level 2 /dev/net/tun is a Linux tun/tap device (tap mode) Executing script tinc-up Listening on 0.0.0.0 port 655 Ready root@server:/etc/tinc/meshboard# tincd -n meshboard -d2 -D tincd 1.0.11 (Nov 18 2009 03:31:26) starting, debug level 2 /dev/net/tun is a Linux tun/tap device (tap mode) Executing script tinc-up Listening on 0.0.0.0 port 655 Ready Ciao Il 01 settembre 2011 15:59, ZioPRoTo (Saverio Proto) ziopr...@gmail.com ha scritto: 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 tonyp...@gmail.com 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] Name=server AddressFamily=ipv4 BindToInterface=eth0 Device=/dev/net/tun PrivateKeyFile=/etc/tinc/meshboard/rsa_key.priv Mode=switch [Sicilia] Name=nano ConntectTo=server TCPOnly=yes AddressFamily=ipv4 BindToInterface=wlan0 Device=/dev/net/tun PrivateKeyFile=/etc/tinc/meshboard/rsa_key.priv i file contenuti all'interno della cartella hosts contengono: [Sicilia] Subnet = 192.168.100.0/24 -BEGIN RSA PUBLIC KEY- ... -END RSA PUBLIC KEY- [Server] Address = 95.142.174.146 Subnet = 192.168.100.0/24 -BEGIN RSA PUBLIC KEY- ... -END RSA PUBLIC KEY- Premetto che vengo da openvpn e per quanto dicono sia complessa mi ha sempre funzionato a primo colpo. Con Tinc non capisco dove sbaglio. Ovviamente i file all'interno della cartella hosts sono stati correttamente scambiati tra le due macchine ma quando faccio ping da una macchina verso l'altra non ottengo risultati. Premetto inoltre che la macchina server non ha alcun firewall e se faccio un nmap -p 655 mi viene detto che la porta è aperta. Ovviamente neanche il laptop ha firewall attivi ma è dietro nat. Ho sempre sentito parlare Saverio e altri su quanto tinc sia valido e mi piacerebbe passare a questo. P.S. Le versioni di tinc che ho sono per quanto riguarda il laptop 1.0.13 e sul server 1.0.11 ma non penso che questo sia il problema. Sto perdendo la pazienza -- Filippo Sallemi ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless -- Filippo Sallemi ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Tinc
ConntectTo = server questo è sbagliato, ConnectTo era questo il problema ? Saverio ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Tinc
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 From 192.168.100.1 icmp_seq=3 Destination Net Unknown From 192.168.100.1 icmp_seq=4 Destination Net Unknown From 192.168.100.1 icmp_seq=5 Destination Net Unknown From 192.168.100.1 icmp_seq=6 Destination Net Unknown From 192.168.100.1 icmp_seq=7 Destination Net Unknown From 192.168.100.1 icmp_seq=8 Destination Net Unknown From 192.168.100.1 icmp_seq=9 Destination Net Unknown From 192.168.100.1 icmp_seq=10 Destination Net Unknown root@nano:/etc/tinc/meshboard# route -n Tabella di routing IP del kernel Destination Gateway Genmask Flags Metric RefUse Iface 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 meshboard 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlan0 10.0.0.00.0.0.0 255.0.0.0 U 1 00 eth0 0.0.0.0 10.112.248.10.0.0.0 UG0 00 eth0 Sul server invece : root@jigen:/etc/tinc/meshboard/hosts# ping 192.168.100.2 PING 192.168.100.2 (192.168.100.2) 56(84) bytes of data. ^C --- 192.168.100.2 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3023ms root@jigen:/etc/tinc/meshboard/hosts# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 meshboard 95.142.172.00.0.0.0 255.255.252.0 U 0 00 eth0 0.0.0.0 95.142.175.254 0.0.0.0 UG0 00 eth0 ??? Il 01 settembre 2011 17:42, ZioPRoTo (Saverio Proto) ziopr...@gmail.com ha scritto: ConntectTo = server questo è sbagliato, ConnectTo era questo il problema ? Saverio ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless -- Filippo Sallemi ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc CPU optimization
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 di cpu ma se la si disabilita' non c'e' modo di capire se ti stanno iniettando pacchi a caso oppure se sono i pacchetti giusti che ti arrivano Il 03 luglio 2011 11:10, Gioacchino Mazzurco gmazzurc...@gmail.com 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 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' leggendo il man di tinc ho trovato questo Cipher = cipher (blowfish) The symmetric cipher algorithm used to encrypt UDP packets. Any cipher supported by OpenSSL is recognised. Fur†thermore, specifying none will turn off packet encryption. It is best to use only those ciphers which support CBC mode. mettendo none dovrebbe essere disabilitata l' encryption e quindi avere piu' banda, il meccanismo degli host con il file con la chiave pubblica continua a funzionare disabilitando la cifratura, e soprattutto bastera' aggiungere quell'opzione li oppure bisogna cambiare altre conf? ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc CPU optimization
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 gmazzurc...@gmail.comha 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 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' leggendo il man di tinc ho trovato questo Cipher = cipher (blowfish) The symmetric cipher algorithm used to encrypt UDP packets. Any cipher supported by OpenSSL is recognised. Fur†thermore, specifying none will turn off packet encryption. It is best to use only those ciphers which support CBC mode. mettendo none dovrebbe essere disabilitata l' encryption e quindi avere piu' banda, il meccanismo degli host con il file con la chiave pubblica continua a funzionare disabilitando la cifratura, e soprattutto bastera' aggiungere quell'opzione li oppure bisogna cambiare altre conf? ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc CPU optimization
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 dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com 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 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' leggendo il man di tinc ho trovato questo Cipher = cipher (blowfish) The symmetric cipher algorithm used to encrypt UDP packets. Any cipher supported by OpenSSL is recognised. Fur†thermore, specifying none will turn off packet encryption. It is best to use only those ciphers which support CBC mode. mettendo none dovrebbe essere disabilitata l' encryption e quindi avere piu' banda, il meccanismo degli host con il file con la chiave pubblica continua a funzionare disabilitando la cifratura, e soprattutto bastera' aggiungere quell'opzione li oppure bisogna cambiare altre conf? ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc CPU optimization
Hai gia controllato i valori tra le 2 pico con e senza tinc? Il giorno 03 luglio 2011 11:45, Gioacchino Mazzurco gmazzurc...@gmail.comha 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, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com 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 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' leggendo il man di tinc ho trovato questo Cipher = cipher (blowfish) The symmetric cipher algorithm used to encrypt UDP packets. Any cipher supported by OpenSSL is recognised. Fur†thermore, specifying none will turn off packet encryption. It is best to use only those ciphers which support CBC mode. mettendo none dovrebbe essere disabilitata l' encryption e quindi avere piu' banda, il meccanismo degli host con il file con la chiave pubblica continua a funzionare disabilitando la cifratura, e soprattutto bastera' aggiungere quell'opzione li oppure bisogna cambiare altre conf? ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc CPU optimization
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 dark...@darkman.it ha scritto: Hai gia controllato i valori tra le 2 pico con e senza tinc? Il giorno 03 luglio 2011 11:45, Gioacchino Mazzurco gmazzurc...@gmail.com 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, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com 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 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' leggendo il man di tinc ho trovato questo Cipher = cipher (blowfish) The symmetric cipher algorithm used to encrypt UDP packets. Any cipher supported by OpenSSL is recognised. Fur†thermore, specifying none will turn off packet encryption. It is best to use only those ciphers which support CBC mode. mettendo none dovrebbe essere disabilitata l' encryption e quindi avere piu' banda, il meccanismo degli host con il file con la chiave pubblica continua a funzionare disabilitando la cifratura, e soprattutto bastera' aggiungere quell'opzione li oppure bisogna cambiare altre conf? ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc CPU optimization
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 gmazzurc...@gmail.comha scritto: 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 dark...@darkman.it ha scritto: Hai gia controllato i valori tra le 2 pico con e senza tinc? Il giorno 03 luglio 2011 11:45, Gioacchino Mazzurco gmazzurc...@gmail.com 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, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com 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 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' leggendo il man di tinc ho trovato questo Cipher = cipher (blowfish) The symmetric cipher algorithm used to encrypt UDP packets. Any cipher supported by OpenSSL is recognised. Fur†thermore, specifying none will turn off packet encryption. It is best to use only those ciphers which support CBC mode. mettendo none dovrebbe essere disabilitata l' encryption e quindi avere piu' banda, il meccanismo degli host con il file con la chiave pubblica continua a funzionare disabilitando la cifratura, e soprattutto bastera' aggiungere quell'opzione li oppure bisogna cambiare altre conf? ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc CPU optimization
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 quindi sono 3 iperf via internet senza tinc 500KB/s iperf via mesh senza tinc ~ 20Kb/s iperf via mesh tunnellata su internet con tinc ~100Kb/s Il 03 luglio 2011 12:27, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it ha scritto: Hai gia controllato i valori tra le 2 pico con e senza tinc? Il giorno 03 luglio 2011 11:45, Gioacchino Mazzurco gmazzurc...@gmail.com 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, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com 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 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' leggendo il man di tinc ho trovato questo Cipher = cipher (blowfish) The symmetric cipher algorithm used to encrypt UDP packets. Any cipher supported by OpenSSL is recognised. Fur†thermore, specifying none will turn off packet encryption. It is best to use only those ciphers which support CBC mode. mettendo none dovrebbe essere disabilitata l' encryption e quindi avere piu' banda, il meccanismo degli host con il file con la chiave pubblica continua a funzionare disabilitando la cifratura, e soprattutto bastera' aggiungere quell'opzione li oppure bisogna cambiare altre conf? ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc CPU optimization
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 gmazzurc...@gmail.comha scritto: 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 quindi sono 3 iperf via internet senza tinc 500KB/s iperf via mesh senza tinc ~ 20Kb/s iperf via mesh tunnellata su internet con tinc ~100Kb/s Il 03 luglio 2011 12:27, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it ha scritto: Hai gia controllato i valori tra le 2 pico con e senza tinc? Il giorno 03 luglio 2011 11:45, Gioacchino Mazzurco gmazzurc...@gmail.com 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, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com 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 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' leggendo il man di tinc ho trovato questo Cipher = cipher (blowfish) The symmetric cipher algorithm used to encrypt UDP packets. Any cipher supported by OpenSSL is recognised. Fur†thermore, specifying none will turn off packet encryption. It is best to use only those ciphers which support CBC mode. mettendo none dovrebbe essere disabilitata l' encryption e quindi avere piu' banda, il meccanismo degli host con il file con la chiave pubblica continua a funzionare disabilitando la cifratura, e soprattutto bastera' aggiungere quell'opzione li oppure bisogna cambiare altre conf? ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc CPU optimization
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 97.3 Kbits/sec [ 4] 0.0-20.8 sec 384 KBytes 151 Kbits/sec [ 4] 0.0-27.7 sec 256 KBytes 75.8 Kbits/sec [ 4] 0.0-21.8 sec 256 KBytes 96.3 Kbits/sec [ 4] 0.0-14.3 sec 512 KBytes 294 Kbits/sec [ 4] 0.0-14.0 sec 512 KBytes 299 Kbits/sec [ 4] 0.0-37.6 sec 512 KBytes 112 Kbits/sec [ 4] 0.0-18.7 sec 512 KBytes 224 Kbits/sec [ 4] 0.0-21.3 sec 384 KBytes 148 Kbits/sec [ 4] 0.0-17.9 sec 640 KBytes 293 Kbits/sec [ 4] 0.0-24.8 sec 512 KBytes 169 Kbits/sec [ 4] 0.0-23.5 sec 512 KBytes 178 Kbits/sec [ 4] 0.0-16.4 sec 384 KBytes 192 Kbits/sec [ 4] 0.0-21.4 sec 384 KBytes 147 Kbits/sec ho spento dnsmasq che non serviva a niente e andiamo di poco ma meglio Il 03 luglio 2011 13:16, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 nel fratempo Il 03 luglio 2011 13:01, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it 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 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 gmazzurc...@gmail.com ha scritto: 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 quindi sono 3 iperf via internet senza tinc 500KB/s iperf via mesh senza tinc ~ 20Kb/s iperf via mesh tunnellata su internet con tinc ~100Kb/s Il 03 luglio 2011 12:27, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it ha scritto: Hai gia controllato i valori tra le 2 pico con e senza tinc? Il giorno 03 luglio 2011 11:45, Gioacchino Mazzurco gmazzurc...@gmail.com 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, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com 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 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' leggendo il man di tinc ho trovato questo Cipher = cipher (blowfish) The symmetric cipher algorithm used to encrypt UDP packets. Any cipher supported by OpenSSL is recognised. Fur†thermore, specifying none will turn off packet encryption. It is best to use only those ciphers which support CBC mode. mettendo none dovrebbe essere disabilitata l' encryption
Re: [Ninux-Wireless] tinc CPU optimization
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 se ti vuoi levare il dubbio perchè non metti il device sotto cacti? così puoi tenere monitorato cpu, ram etc e capire meglio che cos'è 100kbps comunque mi sembrano troppo pochi pure a me per dare la colpa al calcolo crittografico Lorenzo ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc CPU optimization
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 volta c'e' ne e' attivo solo uno Il 03 luglio 2011 13:40, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 97.3 Kbits/sec [ 4] 0.0-20.8 sec 384 KBytes 151 Kbits/sec [ 4] 0.0-27.7 sec 256 KBytes 75.8 Kbits/sec [ 4] 0.0-21.8 sec 256 KBytes 96.3 Kbits/sec [ 4] 0.0-14.3 sec 512 KBytes 294 Kbits/sec [ 4] 0.0-14.0 sec 512 KBytes 299 Kbits/sec [ 4] 0.0-37.6 sec 512 KBytes 112 Kbits/sec [ 4] 0.0-18.7 sec 512 KBytes 224 Kbits/sec [ 4] 0.0-21.3 sec 384 KBytes 148 Kbits/sec [ 4] 0.0-17.9 sec 640 KBytes 293 Kbits/sec [ 4] 0.0-24.8 sec 512 KBytes 169 Kbits/sec [ 4] 0.0-23.5 sec 512 KBytes 178 Kbits/sec [ 4] 0.0-16.4 sec 384 KBytes 192 Kbits/sec [ 4] 0.0-21.4 sec 384 KBytes 147 Kbits/sec ho spento dnsmasq che non serviva a niente e andiamo di poco ma meglio Il 03 luglio 2011 13:16, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 nel fratempo Il 03 luglio 2011 13:01, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it 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 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 gmazzurc...@gmail.com ha scritto: 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 quindi sono 3 iperf via internet senza tinc 500KB/s iperf via mesh senza tinc ~ 20Kb/s iperf via mesh tunnellata su internet con tinc ~100Kb/s Il 03 luglio 2011 12:27, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it ha scritto: Hai gia controllato i valori tra le 2 pico con e senza tinc? Il giorno 03 luglio 2011 11:45, Gioacchino Mazzurco gmazzurc...@gmail.com 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, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha
Re: [Ninux-Wireless] tinc CPU optimization
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 precedenti 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 volta c'e' ne e' attivo solo uno Il 03 luglio 2011 13:40, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 97.3 Kbits/sec [ 4] 0.0-20.8 sec 384 KBytes 151 Kbits/sec [ 4] 0.0-27.7 sec 256 KBytes 75.8 Kbits/sec [ 4] 0.0-21.8 sec 256 KBytes 96.3 Kbits/sec [ 4] 0.0-14.3 sec 512 KBytes 294 Kbits/sec [ 4] 0.0-14.0 sec 512 KBytes 299 Kbits/sec [ 4] 0.0-37.6 sec 512 KBytes 112 Kbits/sec [ 4] 0.0-18.7 sec 512 KBytes 224 Kbits/sec [ 4] 0.0-21.3 sec 384 KBytes 148 Kbits/sec [ 4] 0.0-17.9 sec 640 KBytes 293 Kbits/sec [ 4] 0.0-24.8 sec 512 KBytes 169 Kbits/sec [ 4] 0.0-23.5 sec 512 KBytes 178 Kbits/sec [ 4] 0.0-16.4 sec 384 KBytes 192 Kbits/sec [ 4] 0.0-21.4 sec 384 KBytes 147 Kbits/sec ho spento dnsmasq che non serviva a niente e andiamo di poco ma meglio Il 03 luglio 2011 13:16, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 nel fratempo Il 03 luglio 2011 13:01, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it 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 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 gmazzurc...@gmail.com ha scritto: 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 quindi sono 3 iperf via internet senza tinc 500KB/s iperf via mesh senza tinc ~ 20Kb/s iperf via mesh tunnellata su internet con tinc ~100Kb/s Il 03 luglio 2011 12:27, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it ha scritto: Hai gia controllato i valori tra le 2 pico con e senza tinc? Il giorno 03 luglio 2011 11:45, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: iperf -c su computer che usa una picostation come gateway - Picostation con tinc - adsl 8 megabit - iperf --server su eigenlab.org
Re: [Ninux-Wireless] tinc CPU optimization
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 2.00 MBytes 174 Kbits/sec [ 4] 0.0-89.8 sec 2.00 MBytes 187 Kbits/sec [ 4] 0.0-66.4 sec 2.00 MBytes 253 Kbits/sec [ 4] 0.0-99.9 sec 2.00 MBytes 161 Kbits/sec [ 4] 0.0-88.1 sec 2.00 MBytes 190 Kbits/sec Il 03 luglio 2011 13:57, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 or...@autistici.org ha scritto: 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 precedenti 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 volta c'e' ne e' attivo solo uno Il 03 luglio 2011 13:40, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 97.3 Kbits/sec [ 4] 0.0-20.8 sec 384 KBytes 151 Kbits/sec [ 4] 0.0-27.7 sec 256 KBytes 75.8 Kbits/sec [ 4] 0.0-21.8 sec 256 KBytes 96.3 Kbits/sec [ 4] 0.0-14.3 sec 512 KBytes 294 Kbits/sec [ 4] 0.0-14.0 sec 512 KBytes 299 Kbits/sec [ 4] 0.0-37.6 sec 512 KBytes 112 Kbits/sec [ 4] 0.0-18.7 sec 512 KBytes 224 Kbits/sec [ 4] 0.0-21.3 sec 384 KBytes 148 Kbits/sec [ 4] 0.0-17.9 sec 640 KBytes 293 Kbits/sec [ 4] 0.0-24.8 sec 512 KBytes 169 Kbits/sec [ 4] 0.0-23.5 sec 512 KBytes 178 Kbits/sec [ 4] 0.0-16.4 sec 384 KBytes 192 Kbits/sec [ 4] 0.0-21.4 sec 384 KBytes 147 Kbits/sec ho spento dnsmasq che non serviva a niente e andiamo di poco ma meglio Il 03 luglio 2011 13:16, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 nel fratempo Il 03 luglio 2011 13:01, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it 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 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 gmazzurc...@gmail.com ha scritto: 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 quindi sono 3 iperf via internet senza tinc 500KB/s iperf via mesh senza tinc ~ 20Kb/s iperf via mesh tunnellata su internet con tinc ~100Kb/s Il 03 luglio 2011 12:27, Darkman dark...@darkman.it ha scritto: 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?
Re: [Ninux-Wireless] tinc CPU optimization
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? on puoi fare un test fra gli stessi endpoint peròpassando attraverso internet? se i due si ragigungono per connettersi con tinc potranno anche raggiungersi per far connettere iperf, no? Il 03 luglio 2011 13:51, Antonio Quartulli or...@autistici.org ha scritto: 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 precedenti 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 volta c'e' ne e' attivo solo uno Il 03 luglio 2011 13:40, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 97.3 Kbits/sec [ 4] 0.0-20.8 sec 384 KBytes 151 Kbits/sec [ 4] 0.0-27.7 sec 256 KBytes 75.8 Kbits/sec [ 4] 0.0-21.8 sec 256 KBytes 96.3 Kbits/sec [ 4] 0.0-14.3 sec 512 KBytes 294 Kbits/sec [ 4] 0.0-14.0 sec 512 KBytes 299 Kbits/sec [ 4] 0.0-37.6 sec 512 KBytes 112 Kbits/sec [ 4] 0.0-18.7 sec 512 KBytes 224 Kbits/sec [ 4] 0.0-21.3 sec 384 KBytes 148 Kbits/sec [ 4] 0.0-17.9 sec 640 KBytes 293 Kbits/sec [ 4] 0.0-24.8 sec 512 KBytes 169 Kbits/sec [ 4] 0.0-23.5 sec 512 KBytes 178 Kbits/sec [ 4] 0.0-16.4 sec 384 KBytes 192 Kbits/sec [ 4] 0.0-21.4 sec 384 KBytes 147 Kbits/sec ho spento dnsmasq che non serviva a niente e andiamo di poco ma meglio Il 03 luglio 2011 13:16, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 nel fratempo Il 03 luglio 2011 13:01, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it 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 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 gmazzurc...@gmail.com ha scritto: 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 quindi sono 3 iperf via internet senza tinc 500KB/s iperf via mesh senza tinc ~ 20Kb/s iperf via mesh tunnellata su internet con tinc ~100Kb/s Il 03 luglio 2011 12:27, Darkman dark...@darkman.it ha scritto: 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
Re: [Ninux-Wireless] tinc CPU optimization
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 or...@autistici.org ha scritto: 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? on puoi fare un test fra gli stessi endpoint peròpassando attraverso internet? se i due si ragigungono per connettersi con tinc potranno anche raggiungersi per far connettere iperf, no? Il 03 luglio 2011 13:51, Antonio Quartulli or...@autistici.org ha scritto: 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 precedenti 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 volta c'e' ne e' attivo solo uno Il 03 luglio 2011 13:40, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 97.3 Kbits/sec [ 4] 0.0-20.8 sec 384 KBytes 151 Kbits/sec [ 4] 0.0-27.7 sec 256 KBytes 75.8 Kbits/sec [ 4] 0.0-21.8 sec 256 KBytes 96.3 Kbits/sec [ 4] 0.0-14.3 sec 512 KBytes 294 Kbits/sec [ 4] 0.0-14.0 sec 512 KBytes 299 Kbits/sec [ 4] 0.0-37.6 sec 512 KBytes 112 Kbits/sec [ 4] 0.0-18.7 sec 512 KBytes 224 Kbits/sec [ 4] 0.0-21.3 sec 384 KBytes 148 Kbits/sec [ 4] 0.0-17.9 sec 640 KBytes 293 Kbits/sec [ 4] 0.0-24.8 sec 512 KBytes 169 Kbits/sec [ 4] 0.0-23.5 sec 512 KBytes 178 Kbits/sec [ 4] 0.0-16.4 sec 384 KBytes 192 Kbits/sec [ 4] 0.0-21.4 sec 384 KBytes 147 Kbits/sec ho spento dnsmasq che non serviva a niente e andiamo di poco ma meglio Il 03 luglio 2011 13:16, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 nel fratempo Il 03 luglio 2011 13:01, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it 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 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 gmazzurc...@gmail.com ha scritto: 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 quindi sono 3 iperf via internet senza tinc 500KB/s iperf via mesh senza tinc ~ 20Kb/s iperf via mesh tunnellata su internet con tinc ~100Kb/s Il 03 luglio 2011 12:27, Darkman dark...@darkman.it ha scritto: Fammi capire: - tra le tua pico(A) e quella(Z) con l'adsl ci sono diversi nodi e con
Re: [Ninux-Wireless] tinc CPU optimization
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 gmazzurc...@gmail.comha scritto: 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 2.00 MBytes 174 Kbits/sec [ 4] 0.0-89.8 sec 2.00 MBytes 187 Kbits/sec [ 4] 0.0-66.4 sec 2.00 MBytes 253 Kbits/sec [ 4] 0.0-99.9 sec 2.00 MBytes 161 Kbits/sec [ 4] 0.0-88.1 sec 2.00 MBytes 190 Kbits/sec Il 03 luglio 2011 13:57, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 or...@autistici.org ha scritto: 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 precedenti 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 volta c'e' ne e' attivo solo uno Il 03 luglio 2011 13:40, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 97.3 Kbits/sec [ 4] 0.0-20.8 sec 384 KBytes 151 Kbits/sec [ 4] 0.0-27.7 sec 256 KBytes 75.8 Kbits/sec [ 4] 0.0-21.8 sec 256 KBytes 96.3 Kbits/sec [ 4] 0.0-14.3 sec 512 KBytes 294 Kbits/sec [ 4] 0.0-14.0 sec 512 KBytes 299 Kbits/sec [ 4] 0.0-37.6 sec 512 KBytes 112 Kbits/sec [ 4] 0.0-18.7 sec 512 KBytes 224 Kbits/sec [ 4] 0.0-21.3 sec 384 KBytes 148 Kbits/sec [ 4] 0.0-17.9 sec 640 KBytes 293 Kbits/sec [ 4] 0.0-24.8 sec 512 KBytes 169 Kbits/sec [ 4] 0.0-23.5 sec 512 KBytes 178 Kbits/sec [ 4] 0.0-16.4 sec 384 KBytes 192 Kbits/sec [ 4] 0.0-21.4 sec 384 KBytes 147 Kbits/sec ho spento dnsmasq che non serviva a niente e andiamo di poco ma meglio Il 03 luglio 2011 13:16, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 nel fratempo Il 03 luglio 2011 13:01, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it 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 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 gmazzurc...@gmail.com ha scritto: 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 quindi sono 3 iperf via internet senza tinc 500KB/s iperf via mesh senza tinc ~ 20Kb/s iperf via mesh
Re: [Ninux-Wireless] tinc CPU optimization
sulla mia macchina sembra che siano disponibili solo cubic e reno Il 03 luglio 2011 14:23, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: non so quale usa di default tu quale mi consigli di usare? Il 03 luglio 2011 14:18, Darkman dark...@darkman.it 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 gmazzurc...@gmail.com ha scritto: 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 2.00 MBytes 174 Kbits/sec [ 4] 0.0-89.8 sec 2.00 MBytes 187 Kbits/sec [ 4] 0.0-66.4 sec 2.00 MBytes 253 Kbits/sec [ 4] 0.0-99.9 sec 2.00 MBytes 161 Kbits/sec [ 4] 0.0-88.1 sec 2.00 MBytes 190 Kbits/sec Il 03 luglio 2011 13:57, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 or...@autistici.org ha scritto: 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 precedenti 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 volta c'e' ne e' attivo solo uno Il 03 luglio 2011 13:40, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 97.3 Kbits/sec [ 4] 0.0-20.8 sec 384 KBytes 151 Kbits/sec [ 4] 0.0-27.7 sec 256 KBytes 75.8 Kbits/sec [ 4] 0.0-21.8 sec 256 KBytes 96.3 Kbits/sec [ 4] 0.0-14.3 sec 512 KBytes 294 Kbits/sec [ 4] 0.0-14.0 sec 512 KBytes 299 Kbits/sec [ 4] 0.0-37.6 sec 512 KBytes 112 Kbits/sec [ 4] 0.0-18.7 sec 512 KBytes 224 Kbits/sec [ 4] 0.0-21.3 sec 384 KBytes 148 Kbits/sec [ 4] 0.0-17.9 sec 640 KBytes 293 Kbits/sec [ 4] 0.0-24.8 sec 512 KBytes 169 Kbits/sec [ 4] 0.0-23.5 sec 512 KBytes 178 Kbits/sec [ 4] 0.0-16.4 sec 384 KBytes 192 Kbits/sec [ 4] 0.0-21.4 sec 384 KBytes 147 Kbits/sec ho spento dnsmasq che non serviva a niente e andiamo di poco ma meglio Il 03 luglio 2011 13:16, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 nel fratempo Il 03 luglio 2011 13:01, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it 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 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 gmazzurc...@gmail.com ha scritto: la picostation a e la z sono la stessa picostation... dalla picostation a posso decidere se accendere tinc e quindi far passare
Re: [Ninux-Wireless] tinc CPU optimization
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' credo che sia il noto problema dell'MTU settata male. leggi qui: http://www.mail-archive.com/tinc@tinc-vpn.org/msg00924.html http://www.mail-archive.com/tinc@tinc-vpn.org/msg00937.html A Freifunk avevano lo stesso problema con tincd ed abbiamo risolto con la soluzione in quel link. Saverio ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc CPU optimization
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, Gioacchino Mazzurco gmazzurc...@gmail.comha scritto: non so quale usa di default tu quale mi consigli di usare? Il 03 luglio 2011 14:18, Darkman dark...@darkman.it 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 gmazzurc...@gmail.com ha scritto: 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 2.00 MBytes 174 Kbits/sec [ 4] 0.0-89.8 sec 2.00 MBytes 187 Kbits/sec [ 4] 0.0-66.4 sec 2.00 MBytes 253 Kbits/sec [ 4] 0.0-99.9 sec 2.00 MBytes 161 Kbits/sec [ 4] 0.0-88.1 sec 2.00 MBytes 190 Kbits/sec Il 03 luglio 2011 13:57, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 or...@autistici.org ha scritto: 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 precedenti 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 volta c'e' ne e' attivo solo uno Il 03 luglio 2011 13:40, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 97.3 Kbits/sec [ 4] 0.0-20.8 sec 384 KBytes 151 Kbits/sec [ 4] 0.0-27.7 sec 256 KBytes 75.8 Kbits/sec [ 4] 0.0-21.8 sec 256 KBytes 96.3 Kbits/sec [ 4] 0.0-14.3 sec 512 KBytes 294 Kbits/sec [ 4] 0.0-14.0 sec 512 KBytes 299 Kbits/sec [ 4] 0.0-37.6 sec 512 KBytes 112 Kbits/sec [ 4] 0.0-18.7 sec 512 KBytes 224 Kbits/sec [ 4] 0.0-21.3 sec 384 KBytes 148 Kbits/sec [ 4] 0.0-17.9 sec 640 KBytes 293 Kbits/sec [ 4] 0.0-24.8 sec 512 KBytes 169 Kbits/sec [ 4] 0.0-23.5 sec 512 KBytes 178 Kbits/sec [ 4] 0.0-16.4 sec 384 KBytes 192 Kbits/sec [ 4] 0.0-21.4 sec 384 KBytes 147 Kbits/sec ho spento dnsmasq che non serviva a niente e andiamo di poco ma meglio Il 03 luglio 2011 13:16, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 nel fratempo Il 03 luglio 2011 13:01, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it 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 tunnellata? Hai provato a lanciare 2 iperf in parallelo?
Re: [Ninux-Wireless] tinc CPU optimization
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 dark...@darkman.it ha scritto: 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, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: non so quale usa di default tu quale mi consigli di usare? Il 03 luglio 2011 14:18, Darkman dark...@darkman.it 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 gmazzurc...@gmail.com ha scritto: 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 2.00 MBytes 174 Kbits/sec [ 4] 0.0-89.8 sec 2.00 MBytes 187 Kbits/sec [ 4] 0.0-66.4 sec 2.00 MBytes 253 Kbits/sec [ 4] 0.0-99.9 sec 2.00 MBytes 161 Kbits/sec [ 4] 0.0-88.1 sec 2.00 MBytes 190 Kbits/sec Il 03 luglio 2011 13:57, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 or...@autistici.org ha scritto: 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 precedenti 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 volta c'e' ne e' attivo solo uno Il 03 luglio 2011 13:40, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 97.3 Kbits/sec [ 4] 0.0-20.8 sec 384 KBytes 151 Kbits/sec [ 4] 0.0-27.7 sec 256 KBytes 75.8 Kbits/sec [ 4] 0.0-21.8 sec 256 KBytes 96.3 Kbits/sec [ 4] 0.0-14.3 sec 512 KBytes 294 Kbits/sec [ 4] 0.0-14.0 sec 512 KBytes 299 Kbits/sec [ 4] 0.0-37.6 sec 512 KBytes 112 Kbits/sec [ 4] 0.0-18.7 sec 512 KBytes 224 Kbits/sec [ 4] 0.0-21.3 sec 384 KBytes 148 Kbits/sec [ 4] 0.0-17.9 sec 640 KBytes 293 Kbits/sec [ 4] 0.0-24.8 sec 512 KBytes 169 Kbits/sec [ 4] 0.0-23.5 sec 512 KBytes 178 Kbits/sec [ 4] 0.0-16.4 sec 384 KBytes 192 Kbits/sec [ 4] 0.0-21.4 sec 384 KBytes 147 Kbits/sec ho spento dnsmasq che non serviva a niente e andiamo di poco ma meglio Il 03 luglio 2011 13:16, Darkman dark...@darkman.it ha scritto: 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 gmazzurc...@gmail.com ha scritto: 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 nel fratempo Il 03 luglio 2011 13:01, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: Hai la possibilità di usare una CPU + potente (tincare dal PC)? dovrei installarmi anche
Re: [Ninux-Wireless] tinc CPU optimization
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 dice che i pacchetti che escono dalla mia macchina sono ~700byte e l'mtu e' settato a 1280) l' interfaccia tunnel che ha nome nnx-adv ha l'mtu settato a 1400 mentre quello del bridge che contiene bat0 e' 1350 bat0 invece riporta 1373 nonostante quello del bridge sia 1350... ( questo credo sia causato dal fatto che ho disabilitato la fragmentation su batman-adv ) root@OpenWrt:~# brctl show bridge name bridge id STP enabled interfaces br-clients 8000.7aa872dfafbe no bat0 root@OpenWrt:~# ip a s 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:15:6d:7b:96:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global eth0 inet6 fe80::215:6dff:fe7b:967a/64 scope link valid_lft forever preferred_lft forever 4: wlan0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1524 qdisc mq state UNKNOWN qlen 1000 link/ether 00:15:6d:7a:96:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global wlan0 inet6 2001:470:ca42:ee:ab:15:6d7a:967a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::215:6dff:fe7a:967a/64 scope link valid_lft forever preferred_lft forever 5: bat0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1373 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 7a:a8:72:df:af:be brd ff:ff:ff:ff:ff:ff 7: br-clients: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1350 qdisc noqueue state UNKNOWN link/ether 7a:a8:72:df:af:be brd ff:ff:ff:ff:ff:ff inet 192.168.167.21/24 brd 192.168.167.255 scope global br-clients inet6 2001:470:ca42:ee:ab:15:6d7b:967a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::78a8:72ff:fedf:afbe/64 scope link valid_lft forever preferred_lft forever 8: nnx-adv: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 500 link/ether a2:19:0b:84:4f:5e brd ff:ff:ff:ff:ff:ff inet6 fe80::a019:bff:fe84:4f5e/64 scope link valid_lft forever preferred_lft forever Il 03 luglio 2011 16:12, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it ha scritto: 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, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: non so quale usa di default tu quale mi consigli di usare? Il 03 luglio 2011 14:18, Darkman dark...@darkman.it 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 gmazzurc...@gmail.com ha scritto: 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 2.00 MBytes 174 Kbits/sec [ 4] 0.0-89.8 sec 2.00 MBytes 187 Kbits/sec [ 4] 0.0-66.4 sec 2.00 MBytes 253 Kbits/sec [ 4] 0.0-99.9 sec 2.00 MBytes 161 Kbits/sec [ 4] 0.0-88.1 sec 2.00 MBytes 190 Kbits/sec Il 03 luglio 2011 13:57, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 or...@autistici.org ha scritto: 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 precedenti usa un vincolo temporale o quantitativo, sti valori sono troppo deviati.. quei test non sono fatti
Re: [Ninux-Wireless] tinc CPU optimization
OK sembra un problema specifico di batman... non so aiutarti. Saverio Il 03 luglio 2011 16:43, Gioacchino Mazzurco gmazzurc...@gmail.com 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 resta piu' o meno uguale ma la cpu non schizza piu'... perche' batman frammenta anche se non dovrebbe essere necessario? ( wireshark dice che i pacchetti che escono dalla mia macchina sono ~700byte e l'mtu e' settato a 1280) l' interfaccia tunnel che ha nome nnx-adv ha l'mtu settato a 1400 mentre quello del bridge che contiene bat0 e' 1350 bat0 invece riporta 1373 nonostante quello del bridge sia 1350... ( questo credo sia causato dal fatto che ho disabilitato la fragmentation su batman-adv ) root@OpenWrt:~# brctl show bridge name bridge id STP enabled interfaces br-clients 8000.7aa872dfafbe no bat0 root@OpenWrt:~# ip a s 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:15:6d:7b:96:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global eth0 inet6 fe80::215:6dff:fe7b:967a/64 scope link valid_lft forever preferred_lft forever 4: wlan0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1524 qdisc mq state UNKNOWN qlen 1000 link/ether 00:15:6d:7a:96:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global wlan0 inet6 2001:470:ca42:ee:ab:15:6d7a:967a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::215:6dff:fe7a:967a/64 scope link valid_lft forever preferred_lft forever 5: bat0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1373 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 7a:a8:72:df:af:be brd ff:ff:ff:ff:ff:ff 7: br-clients: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1350 qdisc noqueue state UNKNOWN link/ether 7a:a8:72:df:af:be brd ff:ff:ff:ff:ff:ff inet 192.168.167.21/24 brd 192.168.167.255 scope global br-clients inet6 2001:470:ca42:ee:ab:15:6d7b:967a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::78a8:72ff:fedf:afbe/64 scope link valid_lft forever preferred_lft forever 8: nnx-adv: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 500 link/ether a2:19:0b:84:4f:5e brd ff:ff:ff:ff:ff:ff inet6 fe80::a019:bff:fe84:4f5e/64 scope link valid_lft forever preferred_lft forever Il 03 luglio 2011 16:12, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it ha scritto: 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, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: non so quale usa di default tu quale mi consigli di usare? Il 03 luglio 2011 14:18, Darkman dark...@darkman.it 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 gmazzurc...@gmail.com ha scritto: 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 2.00 MBytes 174 Kbits/sec [ 4] 0.0-89.8 sec 2.00 MBytes 187 Kbits/sec [ 4] 0.0-66.4 sec 2.00 MBytes 253 Kbits/sec [ 4] 0.0-99.9 sec 2.00 MBytes 161 Kbits/sec [ 4] 0.0-88.1 sec 2.00 MBytes 190 Kbits/sec Il 03 luglio 2011 13:57, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 or...@autistici.org ha scritto: 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
Re: [Ninux-Wireless] tinc CPU optimization
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 gmazzurc...@gmail.com 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 resta piu' o meno uguale ma la cpu non schizza piu'... perche' batman frammenta anche se non dovrebbe essere necessario? ( wireshark dice che i pacchetti che escono dalla mia macchina sono ~700byte e l'mtu e' settato a 1280) come vedi che batman frammenta? se usi batctl td dovresti vedere i singoli pacchetti (e puoi appurare se sono frammentati o meno). E poi dove leggi l'MTU a 1280? Comunque hai detto che usi ipv6 con pmtu discovery giusto? quindi i pacchetti verrano creati della dimensione esatta per non essere frammentati l' interfaccia tunnel che ha nome nnx-adv ha l'mtu settato a 1400 mentre quello del bridge che contiene bat0 e' 1350 bat0 invece riporta 1373 nonostante quello del bridge sia 1350... ( questo credo sia causato dal fatto che ho disabilitato la fragmentation su batman-adv ) root@OpenWrt:~# brctl show bridge name bridge id STP enabled interfaces br-clients 8000.7aa872dfafbe no bat0 root@OpenWrt:~# ip a s 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:15:6d:7b:96:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global eth0 inet6 fe80::215:6dff:fe7b:967a/64 scope link valid_lft forever preferred_lft forever 4: wlan0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1524 qdisc mq state UNKNOWN qlen 1000 link/ether 00:15:6d:7a:96:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global wlan0 inet6 2001:470:ca42:ee:ab:15:6d7a:967a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::215:6dff:fe7a:967a/64 scope link valid_lft forever preferred_lft forever 5: bat0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1373 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 7a:a8:72:df:af:be brd ff:ff:ff:ff:ff:ff 7: br-clients: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1350 qdisc noqueue state UNKNOWN link/ether 7a:a8:72:df:af:be brd ff:ff:ff:ff:ff:ff inet 192.168.167.21/24 brd 192.168.167.255 scope global br-clients inet6 2001:470:ca42:ee:ab:15:6d7b:967a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::78a8:72ff:fedf:afbe/64 scope link valid_lft forever preferred_lft forever 8: nnx-adv: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 500 link/ether a2:19:0b:84:4f:5e brd ff:ff:ff:ff:ff:ff inet6 fe80::a019:bff:fe84:4f5e/64 scope link valid_lft forever preferred_lft forever Il 03 luglio 2011 16:12, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it ha scritto: 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, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: non so quale usa di default tu quale mi consigli di usare? Il 03 luglio 2011 14:18, Darkman dark...@darkman.it 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 gmazzurc...@gmail.com ha scritto: 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 2.00 MBytes 174 Kbits/sec [ 4] 0.0-89.8 sec 2.00 MBytes 187 Kbits/sec [ 4] 0.0-66.4 sec 2.00 MBytes 253 Kbits/sec [ 4] 0.0-99.9 sec 2.00 MBytes 161 Kbits/sec [ 4] 0.0-88.1 sec 2.00 MBytes 190 Kbits/sec Il 03 luglio 2011 13:57, Gioacchino Mazzurco gmazzurc...@gmail.com
Re: [Ninux-Wireless] tinc CPU optimization
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 or...@autistici.org ha scritto: 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 gmazzurc...@gmail.com 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 resta piu' o meno uguale ma la cpu non schizza piu'... perche' batman frammenta anche se non dovrebbe essere necessario? ( wireshark dice che i pacchetti che escono dalla mia macchina sono ~700byte e l'mtu e' settato a 1280) come vedi che batman frammenta? se usi batctl td dovresti vedere i singoli pacchetti (e puoi appurare se sono frammentati o meno). E poi dove leggi l'MTU a 1280? Comunque hai detto che usi ipv6 con pmtu discovery giusto? quindi i pacchetti verrano creati della dimensione esatta per non essere frammentati l' interfaccia tunnel che ha nome nnx-adv ha l'mtu settato a 1400 mentre quello del bridge che contiene bat0 e' 1350 bat0 invece riporta 1373 nonostante quello del bridge sia 1350... ( questo credo sia causato dal fatto che ho disabilitato la fragmentation su batman-adv ) root@OpenWrt:~# brctl show bridge name bridge id STP enabled interfaces br-clients 8000.7aa872dfafbe no bat0 root@OpenWrt:~# ip a s 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:15:6d:7b:96:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global eth0 inet6 fe80::215:6dff:fe7b:967a/64 scope link valid_lft forever preferred_lft forever 4: wlan0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1524 qdisc mq state UNKNOWN qlen 1000 link/ether 00:15:6d:7a:96:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global wlan0 inet6 2001:470:ca42:ee:ab:15:6d7a:967a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::215:6dff:fe7a:967a/64 scope link valid_lft forever preferred_lft forever 5: bat0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1373 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 7a:a8:72:df:af:be brd ff:ff:ff:ff:ff:ff 7: br-clients: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1350 qdisc noqueue state UNKNOWN link/ether 7a:a8:72:df:af:be brd ff:ff:ff:ff:ff:ff inet 192.168.167.21/24 brd 192.168.167.255 scope global br-clients inet6 2001:470:ca42:ee:ab:15:6d7b:967a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::78a8:72ff:fedf:afbe/64 scope link valid_lft forever preferred_lft forever 8: nnx-adv: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 500 link/ether a2:19:0b:84:4f:5e brd ff:ff:ff:ff:ff:ff inet6 fe80::a019:bff:fe84:4f5e/64 scope link valid_lft forever preferred_lft forever Il 03 luglio 2011 16:12, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it ha scritto: 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, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: non so quale usa di default tu quale mi consigli di usare? Il 03 luglio 2011 14:18, Darkman dark...@darkman.it 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 gmazzurc...@gmail.com ha scritto: 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 [
Re: [Ninux-Wireless] tinc CPU optimization
ho provato ma viene un listone enorme di warning unknown packet type Il 03 luglio 2011 22:24, Antonio Quartulli or...@autistici.org 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 la cpu che parametro devo passare a td per farmi dire la dimensione dei pacchetti? questo non credo tu possa farlo. Cioe` le informazioni sono quelle che vedi, non ha opzioni per dirti roba in piu`, a quel punto ti conviene usare tcpdump vero :P Pero` tramite -p puoi dirgli di visualizzare solo i pacchetti unicast frammentati. A quel punto vedi se vengon fuori pacchetti frammentati o no 1280 l'ho settato a mano sulle interfacce sui computer con iperf Il 03 luglio 2011 19:47, Antonio Quartulli or...@autistici.org ha scritto: 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 gmazzurc...@gmail.com 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 resta piu' o meno uguale ma la cpu non schizza piu'... perche' batman frammenta anche se non dovrebbe essere necessario? ( wireshark dice che i pacchetti che escono dalla mia macchina sono ~700byte e l'mtu e' settato a 1280) come vedi che batman frammenta? se usi batctl td dovresti vedere i singoli pacchetti (e puoi appurare se sono frammentati o meno). E poi dove leggi l'MTU a 1280? Comunque hai detto che usi ipv6 con pmtu discovery giusto? quindi i pacchetti verrano creati della dimensione esatta per non essere frammentati l' interfaccia tunnel che ha nome nnx-adv ha l'mtu settato a 1400 mentre quello del bridge che contiene bat0 e' 1350 bat0 invece riporta 1373 nonostante quello del bridge sia 1350... ( questo credo sia causato dal fatto che ho disabilitato la fragmentation su batman-adv ) root@OpenWrt:~# brctl show bridge name bridge id STP enabled interfaces br-clients 8000.7aa872dfafbe no bat0 root@OpenWrt:~# ip a s 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:15:6d:7b:96:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global eth0 inet6 fe80::215:6dff:fe7b:967a/64 scope link valid_lft forever preferred_lft forever 4: wlan0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1524 qdisc mq state UNKNOWN qlen 1000 link/ether 00:15:6d:7a:96:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global wlan0 inet6 2001:470:ca42:ee:ab:15:6d7a:967a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::215:6dff:fe7a:967a/64 scope link valid_lft forever preferred_lft forever 5: bat0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1373 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 7a:a8:72:df:af:be brd ff:ff:ff:ff:ff:ff 7: br-clients: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1350 qdisc noqueue state UNKNOWN link/ether 7a:a8:72:df:af:be brd ff:ff:ff:ff:ff:ff inet 192.168.167.21/24 brd 192.168.167.255 scope global br-clients inet6 2001:470:ca42:ee:ab:15:6d7b:967a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::78a8:72ff:fedf:afbe/64 scope link valid_lft forever preferred_lft forever 8: nnx-adv: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 500 link/ether a2:19:0b:84:4f:5e brd ff:ff:ff:ff:ff:ff inet6 fe80::a019:bff:fe84:4f5e/64 scope link valid_lft forever preferred_lft forever Il 03 luglio 2011 16:12, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it ha scritto: 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, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: non so quale usa di default tu quale
Re: [Ninux-Wireless] tinc CPU optimization
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 or...@autistici.org 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 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 Comunque se hai disattivato la frammentazione su batman puoi star ben sicuro che lui non la fara` :D Il 03 luglio 2011 19:47, Antonio Quartulli or...@autistici.org ha scritto: 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 gmazzurc...@gmail.com 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 resta piu' o meno uguale ma la cpu non schizza piu'... perche' batman frammenta anche se non dovrebbe essere necessario? ( wireshark dice che i pacchetti che escono dalla mia macchina sono ~700byte e l'mtu e' settato a 1280) come vedi che batman frammenta? se usi batctl td dovresti vedere i singoli pacchetti (e puoi appurare se sono frammentati o meno). E poi dove leggi l'MTU a 1280? Comunque hai detto che usi ipv6 con pmtu discovery giusto? quindi i pacchetti verrano creati della dimensione esatta per non essere frammentati l' interfaccia tunnel che ha nome nnx-adv ha l'mtu settato a 1400 mentre quello del bridge che contiene bat0 e' 1350 bat0 invece riporta 1373 nonostante quello del bridge sia 1350... ( questo credo sia causato dal fatto che ho disabilitato la fragmentation su batman-adv ) root@OpenWrt:~# brctl show bridge name bridge id STP enabled interfaces br-clients 8000.7aa872dfafbe no bat0 root@OpenWrt:~# ip a s 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:15:6d:7b:96:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global eth0 inet6 fe80::215:6dff:fe7b:967a/64 scope link valid_lft forever preferred_lft forever 4: wlan0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1524 qdisc mq state UNKNOWN qlen 1000 link/ether 00:15:6d:7a:96:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global wlan0 inet6 2001:470:ca42:ee:ab:15:6d7a:967a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::215:6dff:fe7a:967a/64 scope link valid_lft forever preferred_lft forever 5: bat0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1373 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 7a:a8:72:df:af:be brd ff:ff:ff:ff:ff:ff 7: br-clients: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1350 qdisc noqueue state UNKNOWN link/ether 7a:a8:72:df:af:be brd ff:ff:ff:ff:ff:ff inet 192.168.167.21/24 brd 192.168.167.255 scope global br-clients inet6 2001:470:ca42:ee:ab:15:6d7b:967a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::78a8:72ff:fedf:afbe/64 scope link valid_lft forever preferred_lft forever 8: nnx-adv: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 500 link/ether a2:19:0b:84:4f:5e brd ff:ff:ff:ff:ff:ff inet6 fe80::a019:bff:fe84:4f5e/64 scope link valid_lft forever preferred_lft forever Il 03 luglio 2011 16:12, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it ha scritto: 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, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: non so quale usa di default tu quale mi consigli di usare? Il 03 luglio 2011 14:18, Darkman dark...@darkman.it ha scritto: Bene, ora puoi ripetere le prove cambiando l'algoritmo di
Re: [Ninux-Wireless] tinc CPU optimization
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 aiutare? almeno per capire.. Il 03 luglio 2011 22:24, Antonio Quartulli or...@autistici.org 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 la cpu che parametro devo passare a td per farmi dire la dimensione dei pacchetti? questo non credo tu possa farlo. Cioe` le informazioni sono quelle che vedi, non ha opzioni per dirti roba in piu`, a quel punto ti conviene usare tcpdump vero :P Pero` tramite -p puoi dirgli di visualizzare solo i pacchetti unicast frammentati. A quel punto vedi se vengon fuori pacchetti frammentati o no 1280 l'ho settato a mano sulle interfacce sui computer con iperf Il 03 luglio 2011 19:47, Antonio Quartulli or...@autistici.org ha scritto: 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 gmazzurc...@gmail.com 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 resta piu' o meno uguale ma la cpu non schizza piu'... perche' batman frammenta anche se non dovrebbe essere necessario? ( wireshark dice che i pacchetti che escono dalla mia macchina sono ~700byte e l'mtu e' settato a 1280) come vedi che batman frammenta? se usi batctl td dovresti vedere i singoli pacchetti (e puoi appurare se sono frammentati o meno). E poi dove leggi l'MTU a 1280? Comunque hai detto che usi ipv6 con pmtu discovery giusto? quindi i pacchetti verrano creati della dimensione esatta per non essere frammentati l' interfaccia tunnel che ha nome nnx-adv ha l'mtu settato a 1400 mentre quello del bridge che contiene bat0 e' 1350 bat0 invece riporta 1373 nonostante quello del bridge sia 1350... ( questo credo sia causato dal fatto che ho disabilitato la fragmentation su batman-adv ) root@OpenWrt:~# brctl show bridge name bridge id STP enabled interfaces br-clients 8000.7aa872dfafbe no bat0 root@OpenWrt:~# ip a s 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:15:6d:7b:96:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global eth0 inet6 fe80::215:6dff:fe7b:967a/64 scope link valid_lft forever preferred_lft forever 4: wlan0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1524 qdisc mq state UNKNOWN qlen 1000 link/ether 00:15:6d:7a:96:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global wlan0 inet6 2001:470:ca42:ee:ab:15:6d7a:967a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::215:6dff:fe7a:967a/64 scope link valid_lft forever preferred_lft forever 5: bat0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1373 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 7a:a8:72:df:af:be brd ff:ff:ff:ff:ff:ff 7: br-clients: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1350 qdisc noqueue state UNKNOWN link/ether 7a:a8:72:df:af:be brd ff:ff:ff:ff:ff:ff inet 192.168.167.21/24 brd 192.168.167.255 scope global br-clients inet6 2001:470:ca42:ee:ab:15:6d7b:967a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::78a8:72ff:fedf:afbe/64 scope link valid_lft forever preferred_lft forever 8: nnx-adv: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 500 link/ether a2:19:0b:84:4f:5e brd ff:ff:ff:ff:ff:ff inet6 fe80::a019:bff:fe84:4f5e/64 scope link valid_lft forever preferred_lft forever Il 03 luglio 2011 16:12, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 dark...@darkman.it ha scritto: Quello che va meglio :) Ce ne saranno una dozzina nel
Re: [Ninux-Wireless] tinc ninux wiki
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 Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc ninux wiki
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 gmazzurc...@gmail.com ha scritto: 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 quindi ogni volta ci troviamo 20 volte questa regola su iptables secondo me sarebbe meglio metterla su /etc/rc.local per openwrt e salvarla direttalmente con /etc/init.d/iptables save su gentoo anche perche' e' una regola che serve comunque vpn o non vpn ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc ninux wiki
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 Saverio Il 07 gennaio 2011 18:30, Gioacchino Mazzurco gmazzurc...@gmail.com ha scritto: 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 quindi ogni volta ci troviamo 20 volte questa regola su iptables secondo me sarebbe meglio metterla su /etc/rc.local per openwrt e salvarla direttalmente con /etc/init.d/iptables save su gentoo anche perche' e' una regola che serve comunque vpn o non vpn ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc ninux wiki
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? -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto Che Guevara ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc ninux wiki
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 uguale di quella, cosi' non c'e' bisogno di frammentazione, pero' questo metodo funziona solo con tcp, io di solito setto l'mtu delle schede di rete sulle macchine finali, o a mano oppure quelle settate via dhcp c'e' l'opzione 26 che puoi far passare al dhcp server in modo che il client venga settato con un certo mtu e questo funziona sia con tcp che con udp, icmp ecc ecc Il giorno 09 gennaio 2011 16:30, Antonio Quartulli or...@ritirata.org ha scritto: 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? -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto Che Guevara ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc ninux wiki
no quella e' la frammentazione, famosa per uccidere le prestazioni... Il giorno 09 gennaio 2011 16:42, Antonio Quartulli or...@ritirata.org 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 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 uguale di quella, cosi' non c'e' bisogno di frammentazione, pero' questo metodo funziona solo con tcp, A quindi clamp-mss-to-pmtu modifica solo il valore dell'mss...ok, credevo che comunque spezzasse il pacchetto in transito per adattarlo a quel nuovo valore io di solito setto l'mtu delle schede di rete sulle macchine finali, o a mano oppure quelle settate via dhcp c'e' l'opzione 26 che puoi far passare al dhcp server in modo che il client venga settato con un certo mtu e questo funziona sia con tcp che con udp, icmp ecc ecc Il giorno 09 gennaio 2011 16:30, Antonio Quartulli or...@ritirata.org ha scritto: 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? -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto Che Guevara ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto Che Guevara ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc ninux wiki
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 ..each of us alone is worth nothing.. Ernesto Che Guevara ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc ninux wiki
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? ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc ninux wiki
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 forwardarlo?! No, che vuoi splittare un syn? Ecco il tassello mancante :) ora mi quadra tutto :) Semplicemente mi ero fissato su quel --clamp-mss-to-pmtu che non avevo badato al resto :P così l'mss viene fissato subito e bon! Grazie ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto Che Guevara ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc muore
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 pisa ) Il giorno 20 dicembre 2010 07:50, ZioPRoTo (Saverio Proto) ziopr...@gmail.com ha scritto: 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 automaticamente Saverio ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc muore
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 automaticamente Saverio ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] tinc auth, nickname Hedgehog e mfp
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 wrote: Il 25/02/10 22:32, ZioPRoTo (Saverio Proto) ha scritto: 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 Ancora che mi censuri? Il mio non e' un comportamento nei confronti della community, ma di taluni individui che dal 2006 continuano imperterriti a farsi le pippe vicendevolmente, nella cantina di Nino. Non confondere te con la community ( http://www.meganetwork.org/index5.html ). Non usare le persone come paravento (Pilato alla folla: Popolo, chi vuoi liberare? Gesu' o Barabba? Barabba, Barabba!, ma Gesu' non era li' a dire la sua perche' Pilato, in lista, abusava della fiducia pubblica censurandogli le mail). A forza di comportarvi cosi' vi state spaventando vicendevolmente piu' del necessario, es: un paio di domeniche fa, Simone, mentre bevevamo una birra al Pibrok: Vogliono spegnere Internet!; rega', la tecnologia una volta distribuita non si spegne mai perche' se viene censurata in un punto del globo, il resto del globo se ne avvantaggia e fa il culo a quelli dove e' stata censurata... o i cinesi hanno scoperto il segreto dei quanti, o stamo in una botte de fero... sempre che si riesca a volersi bene tra sconosciuti. La community - i singoli individui che aggreghi a parrocchia invece di integrare pragmaticamente - e' solo un insieme di povere bestiole che passano il tempo residuo dal lust for life (lavoro, traffico, gente che sclera, etc) approfondendo il networking elettronico Baran_C[1]. Non centrano niente e - anzi - sante bestiole che provano a smantellare le telco! Che oramai si son smantellate da sole, eheh, cfr. vicenda Fastweb e Telecom Sparkle. Certo e' che se nel 2006 mi aveste dato retta a quest'ora avrebbero una alternativa sostenibile uprunning, invece di rischiare il crollo strutturale da un momento all'altro... E poi i nerd da sempre hanno gia' altri stronzi che gli danno addosso (es: la mia ex, giurista chic, che passata al Fusolab dopo un bagno di chiccheria in un localino chic ha detto: voi siete gli sfigati, lo sapete questo?; la sera del giovedi' nerd sul w-o-t, e io a litigarci perche' sono solidale con i miei simili... poi grazie al cazzo che mi molla); e altri che li usano (es: gli autori di The Big Bang Theory); non meritano di essere usati anche dagli accademici per autopromozione[2]. Io non so se l'hai capito... ma siete arrivati tardi[3] per fare i fighetti con le TLC elettroniche (tip: vai sullo spin dell'elettrone o la quantistica; se ci riesci; e fallo prima di qualunque altro essere umano sulla faccia del pianeta, se ci riesci... sei nell'universita', e' quello il tuo lavoro), e sempre secondi[4]... capisco che da' fastidio, ma e' qui nel confrontarti con me che si vede l'onesta' intellettuale. Se scappi hai gia' perso. E senza quell'onesta'[5] poi c'e' poco da lamentarsi se Gli Altri sono stronzi... dei Berlusconi... delle Carlucci... e di tutti coloro che campano di arrivismo e immagine (anche solo perche', poveracci, non hanno poi molto da produrre se non hanno mai vissuto niente). Ti ho gia' detto, e ripetuto, e ri-ri-ripetuto decine di volte che il networking e' PRIMA DI TUTTO l'umilita' di proporre un semplice peering agreement tra nodi indipendenti. Ma se sei solo un pinocchio, Saverio, come faccio IO a fidarmi del fatto che onorerai quell'accordo di peering nel tempo invece di bispensierare alla bisogna? Trova la pace (es: come Nino che s'e' sposato; e' uno dei tanti modi possibili) o aggregati a chi gia' ha una storia necessaria e sufficiente a fare la guerra; altrimenti fai Plonk come tanti e tanti prima di te... tu non puoi passare, torna nell'ombra ( http://www.youtube.com/watch?v=tZxwt39zack )... ciao Michele [1] http://www.attivissimo.net/timeline/paul-baran-on-distributed-comms.pdf [2] cfr. stiamo diventando famosi, ultimamente in lista. Cfr. profilo Facebook (con quel video sfigato sui tetti di Berlino; rega', veramente, poi grazie al cazzo che i giuristi ci danno degli sfigati nonostante quelli obsoleti siano loro). Cfr. Wikipedia (non siamo enciclopedici). [3] es. vicenda MobiMesh Srl con il Prof. Capone. Devo mettermi a cercare e girare le email della lista Ninux in cui (a) delineavo quella tecnologia per nodi mobili un anno prima - su cui Clauz ha gia' glissato sorridendo - come presentata due anni prima in altre sedi piu' formali prima ancora della primissima azienda inglese che la mise su strada in UK, e l'altra in cui (b) dicevi che tu e clauz state collaborando con il
Re: [Ninux-Wireless] tinc auth, nickname Hedgehog e mfp
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 m...@meganetwork.org ha scritto: Rispettivamente IP 4 e 5. Se vuoi dare un peering server di backup pubblica anche questo: Address: hedgehog.meganetwork.org -BEGIN RSA PUBLIC KEY- MIGJAoGBAOgAkZ6EdJXOSrD9jl+/h+eZiYmun62TTnOI55GYHecKU784Zk/OZgCS KeaV4mQRt2F4KJszT4U1RFP7c3ivVIqe4AurjctFSDWUb4xTr1uLtZ42hNJ0FTJu oUcj0WHNfXE5Ea4tXcW3jjbBWf53PeHhIX2CkMP03ZGiQHvu0k0DAgMBAAE= -END RSA PUBLIC KEY- ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
