Mittwoch, 27. Februar 2008

Network failover with quagga (ospfd)

Hallo,

diesmal in Deutsch.
Für das erfolgreiche ausweichende Routing (das Benutzen anderer Netzwerkkarten, bekannt als failover, einfache Hochverfügbarkeit) kann man das Paket quagga (z.B. in der OpenSUSE 10.3 Distribution) nutzen.

Quagga (vormals Zebra)
hierbei ist "Free Routing Software (for BGP, OSPF and RIP, for example)".

Hier ein Beispiel mit zwei virtuellen Instanzen (via Xen) auf einem Hostsystem. Ziel ist es die ICMP -'ping' Aufforderung bei dem Ausfall einer Netzwerkroute auf die andere umzuleiten.

Konfiguration:
- einen Xen Host, mit zwei virtuellen Instanzen,
- die Instanz A ist mit drei virtuellen Netzwerkkarten, die Instanz B ist mit zwei Netzwerkkarten ausgerüstet,
- beide sind über das Xen Domain0 Routing miteinander verbunden (das ist Standard)
- beide Instanzen verfügen über eine OpenSUSE 10.3 Standardinstallation mit zusätzlichem Paket quagga

Instanz A:
Nun müssen die Dateien ospfd.conf und zebra.conf editiert werden:
linux-ynzp:~ # cat /etc/quagga/ospfd.conf
hostname node1-ospf
password quagga
enable password quagga
debug ospf zebra
log file /var/log/quagga/ospfd.log debugging
!
!
!
interface eth2
!
interface eth4
!
interface lo
!
interface eth3
!
router ospf
redistribute connected
!passive-interface eth3
!passive-interface eth4
!passive-interface eth2
network 192.168.1.0/24 area 0.0.0.0
network 192.168.2.0/24 area 0.0.0.0
network 192.168.3.0/24 area 0.0.0.0
network 172.16.1.0/24 area 0.0.0.0
!
line vty
!

linux-ynzp:~ # cat /etc/quagga/zebra.conf
hostname node1-quagga
password quagga
enable password quagga
log file /var/log/quagga/quagga.log
!
interface eth2
ipv6 nd suppress-ra
!
interface eth1
ipv6 nd suppress-ra
!
interface lo
!
interface eth3
ipv6 nd suppress-ra
!
interface eth4
ipv6 nd suppress-ra
!
interface eth0
ipv6 nd suppress-ra
!
ip forwarding
!
line vty
!

Instanz B
die Konfigurationsdaten:
linux-5c5k:~ # cat /etc/quagga/ospfd.conf
hostname node2-ospf
password quagga
enable password quagga
debug ospf zebra
log file /var/log/quagga/ospfd.log debugging
!
!
!
interface eth0
!
interface eth1
!
interface lo
!
interface eth2
!
router ospf
redistribute connected
network 192.168.1.0/24 area 0.0.0.0
network 192.168.2.0/24 area 0.0.0.0
network 192.168.3.0/24 area 0.0.0.0
line vty

linux-5c5k:~ # cat /etc/quagga/zebra.conf
hostname node2-quagga
password quagga
enable password quagga
log file /var/log/quagga/quagga.log
!
interface eth2
ipv6 nd suppress-ra
!
interface eth1
ipv6 nd suppress-ra
!
interface lo
!
interface eth0
ipv6 nd suppress-ra
!
ip forwarding
!
line vty

Zusammendfassend
Es müssen auf beiden Instanzen der ospfd sowie der zebra Dienst laufen:
rcospfd start
rczebra start

Versuchsaufbau der Instanzen

Ergänzung: die Benennung der Interfaces (eth2-eth4) ist beliebig, wichtig ist nur:

eth4 eth2, eth3 eth0, eth1
------------- 192.168.1.1/24 --- 192.168.1.2/24 -------------
172.16.1.0 -- Instanz A- - Instanz B-
------------- 192.168.2.1/24 --- 192.168.2.2/24 -------------

Das Instanz A ein Netzwerk hat, welches nur Instanz A kennt.



Netzwerkausfall Simulation
Wichtig ist es die Netzwerkarten hochzufahren:
linux-ynzp:~ # cat setup.sh
#!/bin/bash -x
#ifconfig eth0 down
#ifconfig eth1 down
ifconfig eth2 down
ifconfig eth3 down
ifconfig eth4 down

#ifconfig eth0 192.168.1.1/24 up
#ifconfig eth1 192.168.2.1/24 up
ifconfig eth2 192.168.1.1/24 up
ifconfig eth3 192.168.2.1/24 up
ifconfig eth4 172.16.1.1/16 up
ifconfig

Auf Instanz A nutzt man hierbei folgenden Skript:
linux-ynzp:~ # o interface_cycle.sh
#!/bin/bash -x
ifconfig eth2 up
ifconfig eth3 up
while true; do
echo "neustart";
sleep 1;
ifconfig eth2 down;
sleep 20;
ifconfig eth2 up;
sleep 1;
ifconfig eth3 down;
sleep 20;
ifconfig eth3 up;
sleep 3;
ifconfig eth2 down;
ifconfig eth3 down;
sleep 3;
ifconfig eth3 up
ifconfig eth2 up
ps aux | grep ospf
done

Wie man leicht sehen kann, es schaltet periodisch einzelne Netzwerke ab und zwingt damit den OSPF Dienst dieses bei den Partnersystem (Instanz B) bekannt zu machen.


Auf der Instanz B:
fährt man ebenfalls die Netzwerkkarten hoch:
linux-5c5k:~ # cat setup.sh
#!/bin/bash -x
ifconfig eth0 down
ifconfig eth1 down
ifconfig eth2 down

ifconfig eth0 192.168.1.2/24 up
ifconfig eth1 192.168.2.2/24 up
ifconfig eth2 192.168.3.2/24 up
ifconfig

Danach erfolgt dann die Ping-Aufforderung:
ping 172.16.1.1
Zeitgleich kann man sich das Ergebnis anschauen:
while true; do route -n | grep 172; sleep 2;done
Mit der Schleife sieht man die Veränderung der Routingschnittstelle.

Dazu startet man auf der Instanz das Skript interface_cycle.sh, danach kann man die Veränderung der Routingschnittstelle auf der Instanz B verfolgen.

Ergebnis:
bei der Abschalten der Netzwerkarte auf Instanz A erfolgt ein Routingwechsel auf Instanz B:

64 bytes from 172.16.1.1: icmp_seq=3 ttl=64 time=0.110 ms
64 bytes from 172.16.1.1: icmp_seq=4 ttl=64 time=0.082 ms
172.16.0.0 192.168.1.1 255.255.0.0 UG 20 0 0 eth0
64 bytes from 172.16.1.1: icmp_seq=5 ttl=64 time=0.096 ms
64 bytes from 172.16.1.1: icmp_seq=6 ttl=64 time=3.64 ms
172.16.0.0 192.168.1.1 255.255.0.0 UG 20 0 0 eth0
64 bytes from 172.16.1.1: icmp_seq=7 ttl=64 time=0.072 ms
64 bytes from 172.16.1.1: icmp_seq=8 ttl=64 time=0.104 ms
172.16.0.0 192.168.2.1 255.255.0.0 UG 20 0 0 eth1
64 bytes from 172.16.1.1: icmp_seq=9 ttl=64 time=3.18 ms
64 bytes from 172.16.1.1: icmp_seq=10 ttl=64 time=0.105 ms
172.16.0.0 192.168.2.1 255.255.0.0 UG 20 0 0 eth1
64 bytes from 172.16.1.1: icmp_seq=11 ttl=64 time=0.101 ms
64 bytes from 172.16.1.1: icmp_seq=12 ttl=64 time=0.081 ms

CUDA, part2

Hey,
here is only a small update on the CUDA example . The idea behind this is available on idea.opensuse.org.

Bye

Donnerstag, 14. Februar 2008

Aircrack speed up with CUDA

Hey,
recently I created a patch (better a aircrack trunk), which is capable of using NVIDIA's CUDA interface.

So what changed?
- parts of the function body of "crack_wep_thread" changed to separate the KoreK attack steps in a (in real that are 32 ) GPU thread.

For now, the negative part?
- maximal 16KByte local variables transmission towards GPU, due to this at the moment only 15 of 17 Korek attacks possible (error message: "Entry function '_Z13KoreK_attacksPlS_PiS0_S0_PhS0_S1_S0_' uses too much local data (0x40 bytes + 0x4700 bytes system, 0x4000 max)"
- the votes matrix is (sadly) serialized for transmission to GPU (sadly on CPU)
- at least, I do not know, how the GPU threads are working, so is there really a loop unrolling towards the threads?
-> If not, then the for-loop has to be parallelized too
- probably there is a mutex problem, if max_cpu is too small the program exits, I tried it with max_cpu=1 and the program stops with the message not enough IVs present, but from debug messages I see, that it did not try all the whole read IVs
- Still do not know if the calculated values are correct (better: valid), for the moment it is only interesting, that there is speed up.

What is the benefit (performance)?
Some data*:
- this aircrack
airrack + GPU + 03:
~8480.5 keys/s
[00:00:07] Tested 62206 keys
[00:00:18] Tested 151153 keys
[00:01:01] Tested 504845 keys
[00:01:42] Tested 852933 keys

- aircrack Aircrack-ng 0.9.2
~5644.9 keys/s
[00:00:06] Tested 28673 keys
[00:00:19] Tested 123649 keys
[00:01:02] Tested 350977 keys
[00:02:01] Tested 681473 keys

-> round about 50% faster, by transferring one calculation-intensive function to GPU
* Colfax, 2x Dual-Core AMD Opteron(tm) Processor 2218, 8GB DRAM ECC, Tyan S2915 MCP55, GeForce 8800 GT, SLES-10-SP1

What will be changed?
- the function "do_wep_crack1" is a real good candidate for transferring it on GPU . The functions includes a lot of for-loops which seems pretty promising for speed up.

Mittwoch, 23. Januar 2008

Gaming with Linux, speed up

Btw, here is my configuration (instruction) for games (hardware: my good old Intel Pentium III, 786 MByte RAM, OpenSUSE 10.2, Nvidia Geforce MX2 400 32MByte):
* first do a init 1
* /etc/rc.d/boot.udev start
udev is needed for sound card device creation ("/dev/dsp")
* /etc/init.d/alsasound start
this starts your sound card
* dhcpd eth0
of course start the ethernet network, you probably want to play online
* chmod 0777 /dev/dsp
so you can use your sound card
* X & xterm -display :0.0 &
this starts a X-server, most games like America's Army need a running X server
* with the started xterm, you can start your preferred game
of course you should now change from root user to your day-by-day user
* su yourusername

The noticed performance benefit is overwelming. A nearly empty process table, excellent. So for America's Army v2.5 in runlevel 5 with Gnome the game judders, within the minimalistic it runs fluid. Sadly I cannot provide any frames per second.
But with this, my good old P III is still competive.

Samstag, 5. Januar 2008

Privacy!

Hi,
i can only encurage everybody to run tor+privoxy+squid for your (web) anonymity. As of the 1st January 2008 in Germany the "Vorratsdatenspeicherung"/1/ /2/ started and every IP based access is logged from your internet service provider and can be used against you. So be aware if you are surfing torrent sites :-) . One good solution is tor (the onion router), tor is a set of proxy hosts, where your request is routed between a huge set of tor-hosts. This makes your surfing slower of course. The benefit is that in the tor cloud there is no logging, so in past it is not (as current date) possible which way a request has gone. Important to remember is, that this kind of networking is still a Point to Point connection
.

OpenSUSE 10.3 provides the neccessary open source projects packets (source: http://download.opensuse.org/distribution/10.3/repo/oss/suse/x86_64/ for AMD64 X86_64[Hammer architecture]) privoxy-3.0.6-71.x86_64.rpm, squid-2.6.STABLE14-22.x86_64.rpm and torcs-1.3.0-81.x86_64.rpm but no fear you can install it out of the box via Yast2 :-).

In here the OpenSUSE 10.3 helps you:
- use Yast2 software installation and install privoxy, tor and squid
- do following configuration:
* enable in file "/var/lib/privoxy/etc/config" the line 1053 "forward-socks4a / localhost:9050", this is important for other services that they can use the SOCKS v4 protocol for transfver,
* copy the sample configuration file "/etc/tor/torrc.sample" to "/etc/tor/torrc" to default enable the tor
* create in your home directory the file "~/.kde/Autostart/tor", this one is for automatic starting the tor service with KDE start (if you use KDE), edit this file that it contains "#!/bin/bash
tor &", and make it executeable via chmod u+x tor
* now edit the file /etc/squid/squid.conf (ok it is a lot):
line 1034 "cache_dir ufs /var/cache/squid 100 16 256"
line 2544 "http_access allow localhost"
line 594 "cache_peer localhost parent 8118 7 no-query default"
line 2864 "visible_hostname localhost"
line 3777 "never_direct allow all"
- now start these services with rctor start, rcsquid start, rcvivoxy start (you need root priviledges)
- if you want these services be started with every boot time, do:
chkconfig privoxy on;chkconfig tor on; chkconfig squid on or configure it via Yast2 (of course as root)
- last but not least, configure your browser to use the proxy at 127.0.0.1:3128, for Firefox at configuration->network->connection
- do not forget, if you have other applications which uses internet to point them to use the local proxy to use tor, probably you have to set the SOCKS usage.

/1/ see the CCC (chaos computer club), http://chaosradio.ccc.de/cre051.html
/2/ http://www.vorratsdatenspeicherung.de/, http://de.wikipedia.org/wiki/Vorratsdatenspeicherung


More links:
- Tor FAQ
- Firefox Tor Button