I'm using Nmap on bash shell, with Ubuntu on a Windows 10 machine( from windows developer tools), and installed Nmap.
However when I try to use it like so or with additional arguments:
nmap -v google.com
I get the following errors:
If I check the version with the -V option like so
nmap -V
I get the following at the bottom:
The issue seems to be with the compiling of the nsock engines.
I checked around the net and ubuntu's websites, however, could not find any solution.
How can I fix it?
The problem is not the nsock engines. The "Compiled without:" line is empty, meaning that no features are unavailable. Instead, the problem is running a program that expects very specialized Linux networking functions to work, when Windows Subsystem for Linux (WSL) does not implement those functions. The WSL team is working on expanding support, but the level of control necessary to do what Nmap does will not be easy to implement.
The solution is to use the official Nmap installer for Windows. Nmap works great on Windows, with full support for all features.
Related
I have a Perl script which I tried to use PAR::Packer in order to make it a standalone executable so it runs without having Perl on the target machine (because of security reasons).
I used WSL on Windows to pack the Perl script, but the problem I have when I run it on the target machine is the error: "version `GLIBC_2.29' not found".
I ran the command ldd --version and the version on the target machine is 2.17.
The problem I am facing is I cannot install anything on the target machine so I cannot install Perl + PAR::Packer to compile the script and then distribute it to the other machines that are gonna use the script (it's gonna be used in an image so lots of machines).
I cannot seem to find a solution or alternative for this, would love any help from the community.
Edit:
the ubuntu on my WSL was ubuntu 22, the target machines runs redhat and not debian variant, IDK which version as they are a custom linux made by the company i work in.
why am i stuck?
the main problem is that PAR::Packer isn't working on old ubuntu builds ( before 14) and at ubuntu 14 the glibc is already 2.22 while on version 12 its 2.15 so I need to compile the script on old ubuntu (version 12) but the compiling program (PAR::Packer) only works on ubuntu 14 and above so I am stuck in a loop and would apprentice any help or even alternatives for this problem.
Thanks!
Edit: the ubuntu on my WSL was ubuntu 22, the target machines runs redhat
Your problem is that you are trying to build on newer Linux machine, and run the resulting binary on older Linux. That doesn't work (without additional effort).
The simplest solution is to build on the oldest Linux distribution you need to support, possibly in a docker container.
Some other solutions are listed here.
dear Craig McQueen!
I am referring to: Remote debug of Rust program in Visual Studio Code
My config is slightly different that is why I cannot get everything going here:
VScode installed on WIN32 with RUST components successfully!
remote system: odroid C2 ARM64 with UBUNTU18.04 with Kernel 5.14nwith IP: 192.xxx.6.x - user odroid.
I need to remote-compile a Rust program called: c2_mmap_gpio on the OdroidC2
This is already a project on the WIN32.
I did all the steps but it doesn't work.
I think it is not possible to try to run a remote_debug.sh (bash) on a windows machine, right? If yes workaround on this?
I think I need to input my user PWD somewhere to be able to ssh into the remote linux machine, right?
Correct, the remote_debug.sh I described in my answer is good only for a Linux system, and not suitable for a Windows system. For a Windows development system, you would need to write a Windows batch file or Powershell script that provides the equivalent functionality to that remote_debug.sh Bash script.
I'm not proficient in Powershell scripts, and I'm happy using Linux
as my host development machine, so I don't have plans to write such a script.
Regarding needing to enter a password for the SSH operations... Good point. That's something I didn't think to mention in my answer. You need to remove the need for a password to be entered, in one of two ways:
Install your public SSH credentials onto the target, using ssh-copy-id (or the Windows equivalent). Then you should be able to SSH to the target without needing to enter your password.
Give a blank password to the target user on the target, using passwd -d <username>. Note this reduces security, so this is not recommended, especially if the target is accessible via the public Internet.
Recently I updated my Windows 10 Pro with May Update (version 1903, build 18362.116). Then for my existing distros: OpenSuse Leap 15 and Ubuntu (installed from MS Store), I wanted to open a linux directory by using Explorer and I'm getting this message:
[susedis#mypc ~]$ explorer.exe .
If 'explorer.exe' is not a typo you can use command-not-found to lookup the package that contains it, like this:
cnf explorer.exe
This problem happens also with VSC (code) and VSC-Insiders (code-insiders).
I've read this article and ...
OPTION 1: my current problem
OPTION 2: icon LINUX does not exist in tree view
OPTION 3: it works
Supposedly options 1 and 2 should exist and work, even more with the latest update. What's wrong? Thanks in advance.
PS1: I've found these articles Run Visual Studio Code for Linux from WSL and Using Visual Studio Code with Windows Subsystem for Linux, they talk about installing xserver and more stuff on side linux. But many other articles and videos don't talk about it, it's like it was a built-in feature of Windows. This is so dark.
I just found what is the root of my problem: the distro.
explorer, code, code-insiders commands ONLY work through UBUNTU and I was using OpenSuse.
This warning is lacking in every article on Web I read, including on VSC site (example: Developing in WSL). This is a disadvantage for other distros. Very bad.
PS1: The solution can be found here.
I am trying to use the java_kernel for jupyter (https://github.com/Bachmann1234/java9_kernel and issue 24 therein). It works fine on a Mac OSX box. But on Linux (debian), the Java shell is not starting up.
I think I tracked it down to a call like this one:
ptyprocess.PtyProcess.spawn(["/home/jupyterhub/java/jdk-9/bin/java", "-jar", "/home/jupyterhub/java/kulla/kulla.jar"])
Reading pexpect code (https://github.com/pexpect/ptyprocess/blob/master/ptyprocess/ptyprocess.py), I would expect to end up in an exec call, having the child process running python replaced by java. However, this does not happen, ps -fu shows a python child process.
I'm guessing there is some subtle difference between pty handling on linux and osx that causes the differences here?
java-9/jshell as such work from the command line.
Any help much appreciated!
Best,
Holger
There seems to be a change in the way that later versions of jdk-9 deal with terminals on Linux. I reverted to jdk-9.ea+100 and that seems to work.
I have a program that I'd like to run remotely under Valgrind using the Linux Tools remote Valgrind profiler.
I normally debug remotely on a headless server (which has special hardware, so it has to be done remotely on that machine) using RSE, which works fine. Both my machine and the target are Linux machines.
I am now trying to get Valgrind working through Eclipse using the Linux Tools plugin. I have Valgrind 3.10 installed on the remote target machine, and I can run it up manually (outside of Eclipse):
Remotely:
valgrind --vgdb=full --vgdb-error=0 /path/to/app --args
vgdb --port=2345 --pid=XXXX
Locally, connect with gdb with target remote host:2345.
However, I can't work out how to get the "Valgrind (remote)" Eclipse tooling to emulate this, aping the "RemoteTools" setup shown here: .
When I write in a "To:" executable that starts with "rse:/", I get an error in the Profiling Tools settings window top corner saying [Valgrind Options]: Couldn't determine version of Valgrind. What should I write here to get a working remote Valgrind connection?
Haven't found more recent posts on the topic, maybe it will be useful for somebody. I also didn't manage to use remote valgrind plugin with RSE. Seems like only dstore connection type will work for Linux Tools remote valgrind, because SSH or FTP didn't work for me. rseserver requires Perl and Java, and I didn't have them on my target.
I had to use this complicated solution via Launch Group combining this and this solutions. Preconditions: valgrind and vgdb are installed on remote target.
Write a script start_remote_valgrind.sh
set -x
remote_ip=192.168.7.2
remote_port=2222
app_name=test_app
remote_dir=/usr/local/bin/
local_dir=/home/project_name/
ssh -T root#$remote_ip killall -9 vgdb
ssh -T root#$remote_ip killall -9 valgrind
scp $local_dir$app_name root#$remote_ip:$remote_dir$app_name
ssh root#$remote_ip valgrind --vgdb=full --vgdb-error=0 --leak-check=full -v $remote_dir$app_name &
sleep 1
ssh root#$remote_ip vgdb --port=$remote_port
Create debug configuration Run->Debug Configurations->C/C++ remote application:
2.1 On themain tab set the project name and app binary
2.2 In the bottom of the configuration window click "Select Other" link and select "GDB (DSF) manual remote launcher"
2.3 On Debugger tab set GDB debugger for you target platform, command line script .gdbinit.
2.4 On Debugger->connection tab set TCP connection, remote ip and port.
Create external tool Run->external tools->external tools configuration...
Create Launch Group Run->Debug Configurations->Launch Group
external tool must be in Run configuration, remote gdb in Debug. The benefit of this approach is that remote valgrind output is printed in Eclipse console, so you don't need to launch vgdb manually in a separate console and see messages in separate window.