Closed GoogleCodeExporter closed 8 years ago
I pulled the latest from R7's repository and was unable to reproduce this
behavior. It works for me. Do you have any other details that may help me? Does
this happen every single time or did it happen once?
Original comment by rsmu...@gmail.com
on 26 Apr 2013 at 12:00
It happens every time, and persists across reboots. msfupdate doesn't show any
new versions either. The following error appears in the console in which
armitage is running:
[lib/msf/core/rpc/v10/rpc_base.rb:16:in `error',
lib/msf/core/rpc/v10/rpc_session.rb:215:in `_find_module',
lib/msf/core/rpc/v10/rpc_session.rb:203:in `block in rpc_compatible_modules',
lib/msf/core/rpc/v10/rpc_session.rb:202:in `each',
lib/msf/core/rpc/v10/rpc_session.rb:202:in `rpc_compatible_modules',
lib/msf/core/rpc/v10/service.rb:149:in `block in process',
lib/ruby/1.9.1/timeout.rb:68:in `timeout',
lib/msf/core/rpc/v10/service.rb:149:in `process',
lib/msf/core/rpc/v10/service.rb:89:in `on_request_uri',
lib/msf/core/rpc/v10/service.rb:71:in `block in start',
lib/rex/proto/http/handler/proc.rb:38:in `call',
lib/rex/proto/http/handler/proc.rb:38:in `on_request',
lib/rex/proto/http/server.rb:355:in `dispatch_request',
lib/rex/proto/http/server.rb:289:in `on_client_data',
lib/rex/proto/http/server.rb:149:in `block in start',
lib/rex/io/stream_server.rb:48:in `call', lib/rex/io/stream_server.rb:48:in
`on_client_data',
lib/rex/io/stream_server.rb:192:in `block in monitor_clients',
lib/rex/io/stream_server.rb:190:in `each', lib/rex/io/stream_server.rb:190:in
`monitor_clients', lib/rex/io/stream_server.rb:73:in `block in start',
lib/rex/thread_factory.rb:22:in `call', lib/rex/thread_factory.rb:22:in `block
in spawn', lib/msf/core/thread_manager.rb:100:in `call',
lib/msf/core/thread_manager.rb:100:in `block in spawn']
Warning: invalid use of index operator: $null['modules'] at modules.sl:258
Warning: variable '$__frame__' not declared at gui.sl:98
Original comment by y2k...@gmail.com
on 26 Apr 2013 at 7:07
Try:
db_rebuild_cache
Wait a few minutes. If this doesn't work, reinstall the Metasploit Framework or
at least drop the msf database so it gets recreated. This error isn't an
Armitage error. It's coming from the framework. I still can't reproduce it.
Original comment by rsmu...@gmail.com
on 27 Apr 2013 at 12:29
Setting up bundler (1.1.4-6) ...
Setting up rubygems-integration (1.1) ...
Setting up metasploit-framework (4.6.0-2013041701-1kali0) ...
Setting up metasploit (4.6.0-2013041701-1kali0) ...
Ok, I have Kali Linux and I ran msfupdate. I can't reproduce this error--but, I
did do service metasploit stop to make sure all the non-framework stuff is not
running. Try that too.
Original comment by rsmu...@gmail.com
on 27 Apr 2013 at 1:14
After a database drop, restarting and stopped the services, and then restarting
the box, it's finally working again. Not entirely sure what the issue was, but
it looks to have been resolved. Sorry to take up your time
Original comment by y2k...@gmail.com
on 27 Apr 2013 at 3:30
Cool, it sounds like the module cache was corrupted in some way.
Original comment by rsmu...@gmail.com
on 27 Apr 2013 at 1:14
Can you detail how exactly to drop the database? The problem seems to have
returned, and none of my previous steps have fixed the issue.
I've done a db_rebuild_cache, stopped and started all services, and restarted
multiple times. Not sure what is causing the issue exactly.
Original comment by y2k...@gmail.com
on 29 Apr 2013 at 12:49
y2kspy: Have you run any of the commercial products (Community Edition,
Express, or Pro) in your current install?
Original comment by rsmu...@gmail.com
on 29 Apr 2013 at 12:52
As far as I know, no. I installed this with a simple apt-get install armitage.
The only things that have been changed configuration wise should be some custom
modules I wrote myself.
Original comment by y2k...@gmail.com
on 29 Apr 2013 at 12:56
Try:
source /opt/metasploit/script/setenv.sh
dropdb 'msf3'
Original comment by rsmu...@gmail.com
on 29 Apr 2013 at 12:57
Done. Are there any special procedures necessary for recreating the database?
Or just create a new database called msf3?
Original comment by y2k...@gmail.com
on 29 Apr 2013 at 1:00
It'll recreate itself.
Original comment by rsmu...@gmail.com
on 29 Apr 2013 at 1:04
After a full database drop, the problem persists. Perhaps I'll just reinstall
metasploit from scratch. Not sure if a purge will remove the custom scripts
that I wrote, so should I back those up?
Original comment by y2k...@gmail.com
on 29 Apr 2013 at 1:06
before you reinstall... can you email me the ~/.msf4/logs/framework.log file. I
suspect that this is an environment issue and out of my control, but, I'd like
to know what's happening too so I can better support folks with the same
question in the future.
Original comment by rsmu...@gmail.com
on 29 Apr 2013 at 1:13
Absolutely. I'll email it to you right now.
Original comment by y2k...@gmail.com
on 29 Apr 2013 at 1:15
apt-get purge metasploit && apt-get install metasploit enough to do what's
necessary?
Original comment by y2k...@gmail.com
on 29 Apr 2013 at 1:20
There are several metasploit related packages including metasploit-framework.
TBH though, I don't really know what it will take under Kali only because I'm
not that familiar with that environment yet.
Original comment by rsmu...@gmail.com
on 29 Apr 2013 at 1:24
Real quick--you'll want to recreate the db. Try that before a reinstall and
make sure you restart everything. Try
source /opt/metasploit/script/setenv.sh
createdb 'msf3'
Original comment by rsmu...@gmail.com
on 29 Apr 2013 at 1:27
Also, going through your framework.log file, I'm seeing errors trying to load a
module. This could explain part of the issue you're experiencing. I don't know
where this module came from, but I don't have it in my git pull of the source.
[04/28/2013 20:27:11] [e(0)] core:
/opt/metasploit/apps/pro/msf3/modules/post/linux/gather/sucrack.rb failed to
load due to the following error:
NameError
uninitialized constant Msf::Core
Call stack:
Original comment by rsmu...@gmail.com
on 29 Apr 2013 at 1:29
That was a module I was working on at the time. I fixed the error, but the
issue was unrelated. I did an aptitude reinstall metasploit and aptitude
reinstall metasploit-framework. I also killed the database and recreated it. It
seems to be working now. I still have no idea what caused it. My best guess is
that the framework was unhappy about some of the modules I wrote.
Original comment by y2k...@gmail.com
on 29 Apr 2013 at 1:44
Original issue reported on code.google.com by
y2k...@gmail.com
on 26 Apr 2013 at 6:06