pyrit (r199) server/client mode assistance needed

[erhardm]

For the past two days I'm trying get pyrit work on 2 boxes through network using server/client method but I can't see where I'm doing something wrong( I assume what's the problem but still don't know how to solve it)

I have 2 boxes: indexical(192.168.1.100) & serve(192.168.1.101)

Both of them are clean bt4-prefinal install with updates ( apt-get update & apt-get upgrade ) but I removed pyrit ( apt-get remove pyrit ) and installed libpq-dev, Sqlalchemy, psycopg2, pyrit from latest available sources. (Network is coming back… « Pyrit)

indexical(192.168.1.100):

root@indexical:~# ifconfig eth0 inet 192.168.1.100
root@indexical:~# iptables -I INPUT -p tcp --dport 19935 -j ACCEPT
root@indexical:~# iptables -I OUTPUT -p tcp --sport 19935 -j ACCEPT
root@indexical:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:19935

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp spt:19935
root@indexical:~# iptables-save
# Generated by iptables-save v1.4.0 on Wed Jan  6 14:09:47 2010
*filter
:INPUT ACCEPT [336:166521]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [336:166521]
-A INPUT -p tcp -m tcp --dport 19935 -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 19935 -j ACCEPT
COMMIT
# Completed on Wed Jan  6 14:09:47 2010
root@indexical:~# echo '192.168.1.101' >> ~/.pyrit/hosts

serve(192.168.1.101):

root@serve:~# ifconfig eth0 inet 192.168.1.101
root@serve:~# iptables -I INPUT -p tcp --dport 19935 -j ACCEPT
root@serve:~# iptables -I OUTPUT -p tcp --sport 19935 -j ACCEPT
root@serve:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:19935

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp spt:19935
root@serve:~# iptables-save
# Generated by iptables-save v1.4.0 on Wed Jan  6 14:01:02 2010
*filter
:INPUT ACCEPT [113:50485]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [125:51097]
-A INPUT -p tcp -m tcp --dport 19935 -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 19935 -j ACCEPT
COMMIT
# Completed on Wed Jan  6 14:01:02 2010
root@serve:~# pyrit selftest
Pyrit 0.2.5-dev (svn r199) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+


Cores incorporated in the test:
#1:  'CPU-Core (SSE2)'
#2:  'Network-Clients'

Running selftest...

All results verified. Your installation seems OK.

then I type command on serve(192.168.1.101) to act as server:

root@serve:~# pyrit serve
Pyrit 0.2.5-dev (svn r199) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+


Serving 0 active clients; 0 PMKs/s; 0.0 TTS

then, on the other box, indexial(192.168.1.100) I run following commands:

root@indexical:~# pyrit list_cores
Pyrit 0.2.5-dev (svn r199) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+


The following cores seem available...
#1:  'CPU-Core (SSE2)'
#2:  'Network-Clients'
root@indexical:~# pyrit selftest
Pyrit 0.2.5-dev (svn r199) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+


Cores incorporated in the test:
#1:  'CPU-Core (SSE2)'
#2:  'Network-Clients'

Running selftest...

All results verified. Your installation seems OK.
root@indexical:~# pyrit benchmark
Pyrit 0.2.5-dev (svn r199) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+


Running benchmark (161.3 PMKs/s)... |

Computed 160.98 PMKs/s total.
#1: 'CPU-Core (SSE2)': 148.7 PMKs/s (RTT 3.1)
#2: 'Network-Clients': 0.0 PMKs/s (RTT 0.0)

as you can see serve(192.168.1.101) doesn't show up as it's a working one

I assume that it's because the port 19935 is closed as nmap shows but I don't understand why iptables doesn't work ( I'm new to iptables but after research I hope I managed to learn something )

root@indexical:~# nmap -sS -PN -p 19935 192.168.1.101

Starting Nmap 5.00 ( http://nmap.org ) at 2010-01-06 14:21 EET
Interesting ports on 192.168.1.101:
PORT      STATE  SERVICE
19935/tcp closed unknown
MAC Address: 08:00:27:76:4C:60 (Cadmus Computer Systems)

Nmap done: 1 IP address (1 host up) scanned in 14.06 seconds
root@indexical:~# nmap -sA -PN -p 19935 192.168.1.101

Starting Nmap 5.00 ( http://nmap.org ) at 2010-01-06 14:23 EET
Interesting ports on 192.168.1.101:
PORT      STATE      SERVICE
19935/tcp unfiltered unknown
MAC Address: 08:00:27:76:4C:60 (Cadmus Computer Systems)

Nmap done: 1 IP address (1 host up) scanned in 13.86 seconds

I hope it's enough information about the problem
If someone can point me to a direction I would appreciate that.

BTW: this is reproduced data in VirtualBox ( the same results I had on real hardware but I used virtual environment to be able to record input/output data )

[purehate]

The pyrit which is in the repository is one of the latest svn's so you could use that although you will need to update to the latest kernel as well for the drivers to be working.

When I am in this situation I always turn of all firewalls first and get that working first. that way I can narrow down the issue. once that is working turn on one firewall at a time and get those working. When networking box's you have to narrow down the problem a little better since there are so many things that can go wrong.

[erhardm]

Pureh@te, I updated the kernel on both boxes and stopped the firewall as you suggested:

indexical(192.168.1.100)

root@indexical:~# uname -a
Linux indexical 2.6.30.9 #1 SMP Tue Dec 1 21:51:08 EST 2009 i686 GNU/Linux
root@indexical:~# ifconfig eth0 inet 192.168.1.100
root@indexical:~# ufw disable
Firewall stopped and disabled on system startup
root@indexical:~# iptables -F
root@indexical:~# iptables -X
root@indexical:~# iptables -t nat -F
root@indexical:~# iptables -t nat -X
root@indexical:~# iptables -t mangle -F
root@indexical:~# iptables -t mangle -X
root@indexical:~# iptables -P INPUT ACCEPT
root@indexical:~# iptables -P FORWARD ACCEPT
root@indexical:~# iptables -P OUTPUT ACCEPT

serve(192.168.1.101)

root@serve:~# uname -a
Linux serve 2.6.30.9 #1 SMP Tue Dec 1 21:51:08 EST 2009 i686 GNU/Linux
root@serve:~# ifconfig eth0 inet 192.168.1.101
root@serve:~# ufw disable
Firewall stopped and disabled on system startup
root@serve:~# iptables -F
root@serve:~# iptables -X
root@serve:~# iptables -t nat -F
root@serve:~# iptables -t nat -X
root@serve:~# iptables -t mangle -F
root@serve:~# iptables -t mangle -X
root@serve:~# iptables -P INPUT ACCEPT
root@serve:~# iptables -P FORWARD ACCEPT
root@serve:~# iptables -P OUTPUT ACCEPT

Then I run the commands for serve(192.168.1.101) to act like server:

root@serve:~# pyrit selftest
Pyrit 0.2.5-dev (svn r199) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.
This code is distributed under the GNU General Public License v3+


Cores incorporated in the test:
#1:  'CPU-Core (SSE2)'
#2:  'Network-Clients'

Running selftest...

All results verified. Your installation seems OK.
root@serve:~# pyrit serve
Pyrit 0.2.5-dev (svn r199) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+


Serving 0 active clients; 0 PMKs/s; 0.0 TTS

Then I switched to indexical(192.168.1.100):

root@indexical:~# pyrit list_cores
Pyrit 0.2.5-dev (svn r199) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+


The following cores seem available...
#1:  'CPU-Core (SSE2)'
#2:  'Network-Clients'

As you can see serve(192.168.1.101) is still not reconized and then I checked with nmap for open port (on serve pyrit was still running):

root@indexical:~# nmap -sS -p19935 192.168.1.101

Starting Nmap 5.00 ( http://nmap.org ) at 2010-01-07 00:05 EET
Interesting ports on 192.168.1.101:
PORT      STATE  SERVICE
19935/tcp closed unknown
MAC Address: 08:00:27:76:4C:60 (Cadmus Computer Systems)

Nmap done: 1 IP address (1 host up) scanned in 14.07 seconds

Is there anything else I shoud check? I stopped ufw(which uses iptables) and I independently used iptables too, did I missed something?

[imported_sprice82]

I am having exactly the same issue, It is really really annoying, I am on r203 and have spent at least 6 hours trying different things

[adam111316]

The way I worked out how to do it was to change the config file in .pyrit/config on the server. The client to assist was on 192.168.1.5 so my config file looked like this.

default_storage = file://
rpc_announce = true
rpc_announce_broadcast = false
rpc_knownclients = 192.168.1.5
rpc_server = true

Hope it helps!

[adam111316]

[sorry double post]

[erhardm]

Thank you for your post!

Your solution is a way out but I don't think that it's reliable for more than 2 systems working together(not tested yet). I will do the test and try to find a way with more than 2 systems and will post the results.

[erhardm]

[@MODS First I edited the last post but after that I choosed to make a new post because it will show that there's something new posted in the thread]


I tried your method with more than 2 system(actually I tested 3 systems) but it didn't seemed to work that well. This is the only way I managed to make them work together:


[root]192.168.1.1-client:192.168.1.2<<<<[root-1]192.168.1.2-client:192.168.1.3<<<<[root-2]192.168.1.3


The drownback/issue is that the systems are working in a chain alike connection and each system from a higher level/root is the bottleneck for the current one. Each system that has a client with a lower level attached will have to manage the workload of it and it will be a "chain" reaction and the root will be overloaded. Theoretical the root has to be the most powerful system and this will be an inefficent way, it wastes power.

Regards

PS: Sorry for the late update but I couldn't reach the forum.