kevbradwick / pyrit

Automatically exported from code.google.com/p/pyrit
0 stars 0 forks source link

Pyrit network functionality not working in 0.4.0 r308? #378

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Install Pyrit, configure bt5 pc's with static ip on a netgear gs105e switch.
2. configure config.py on client to point to server, set rpc_server to true on 
both machines (tried toggling as per recommendations).
2. disable firewall and open port 17935 with iptables.
3.

What is the expected output? What do you see instead?
I should see network clients when I perform pyrit list_cores

What version of the product are you using? On what operating system?
bt5r1, cpyrit_svn 0.4.0 r308

Please provide any additional information below.
Pulling my hair out for days, new to Linux and switches, I desperatly need the 
help, but forgive the nobbishness of this post, I can't find and help online:
I have BT5 installed on 2 computers, linked via a gs105e switch. Both machines 
have pyrit with cuda installed from trunk. I start pyrit serve on one machine, 
but I can't see any network cores on the other. I updated iptables to this on 
both machines:

root@bt:/pentest/cpyrit-cuda-0.3.0# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:17935 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere            tcp spt:17935 

This is my config.py on the server:
config = {'default_storage': 'file://', \
              'rpc_server': 'true', \
              'rpc_announce': 'true', \
              'rpc_announce_broadcast': 'true', \
              'rpc_knownclients':'192.168.0.57', \
              'workunit_size': '75000', \
              'limit_ncpus': 0}
    return config

and on the client:

config = {'default_storage': 'file://', \
              'rpc_server': 'false', \
              'rpc_announce': 'true', \
              'rpc_announce_broadcast': 'true', \
              'rpc_knownclients':'192.168.0.55', \
              'workunit_size': '75000', \
              'limit_ncpus': 0}
    return config

I made sure ufw was disabled. One thing catching me is that I can't ping port 
17935 on either maine, although I opened it earlier and disabled the firewall. 
An nmap of either machine shows it as closed, but some forums have told me that 
if there isn't anything listening on that port, it will appear closed. Even 
with pyrit serve running on one machine, I can't ping that port. I tried 
"netstat -an |grep "LISTEN " on the serving machine, but it doesn't appear to 
be listening on that port. Any help appreciated, it's my first cluster and 
needless to say I'm learning alot. 

Original issue reported on code.google.com by noli...@gmail.com on 25 Jan 2012 at 5:36

GoogleCodeExporter commented 9 years ago
Still messing around with it, realized that the db connect string on the client 
should change. I now have working network functionality with postgresql 8.4, 
but pyrit still cannot connect to network clients (they simply don't exist when 
I list_cores) PLZ any info is appreciated.

Original comment by noli...@gmail.com on 23 Feb 2012 at 2:53

GoogleCodeExporter commented 9 years ago
this is a known issue, see previous tickets, it hasnt been fixed yet as far as 
I know, and it looks like Lukas was abducted my gorillas about a year ago, 
because the svn hasnt been updated since.

Original comment by MrNicho...@gmail.com on 4 Apr 2012 at 3:39

GoogleCodeExporter commented 9 years ago
If it's about PAW2 Buffer error then I fixed it for ya!

Apply this patch with:

patch -p0 < pyrit_paw2bufferfix.patch

inside pyrit_svn branch. In one place cpyrit.py uses PAW2_Buffer constructor 
instead of .pack() method.

Tested it on ubuntu 13.04 and fixes the issue with pyrit serve. The error is on 
the running machine side, not on the serving one.

Original comment by kichadal...@gmail.com on 8 May 2013 at 6:53

Attachments: