Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
nmap can't do the work. I have checked that.
ps: I just use the basic nmap function(nmap host).
Oh, My god. Trust me i don't plan to do bad things. I am just curious! Please don't do -1!
update, use command: nmap -v -p1-65535 -sV
Scanning hidethehostaddress [2 ports]
Completed Ping Scan at 21:38, 0.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 21:38
Completed Parallel DNS resolution of 1 host. at 21:38, 0.00s elapsed
Initiating Connect Scan at 21:38
Scanning hidethehostaddress [65535 ports]
Connect Scan Timing: About 11.88% done; ETC: 21:43 (0:03:50 remaining)
Connect Scan Timing: About 32.96% done; ETC: 21:41 (0:02:04 remaining)
Completed Connect Scan at 21:40, 83.98s elapsed (65535 total ports)
Initiating Service scan at 21:40
Nmap scan report for hidethehostaddress
Host is up (0.080s latency).
Not shown: 65532 filtered ports
PORT STATE SERVICE VERSION
23/tcp closed telnet
80/tcp closed http
443/tcp closed https
Read data files from: /usr/share/nmap
Service detection performed. Please report any incorrect results at http://nmap.org /submit/ .
Nmap done: 1 IP address (1 host up) scanned in 84.13 seconds
It can:
nmap -v -p1-65535 -sV scanme.nmap.org
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
Improve this question
rfkill list 1
command gives me:
1: ideapad_bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
However, when I run the following command,
sudo systemctl status bluetooth.service
I get this error:
bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2019-01-27 13:55:21 +03; 1h 4min ago
Docs: man:bluetoothd(8)
Main PID: 950 (bluetoothd)
Status: "Running"
Tasks: 1 (limit: 4915)
CGroup: /system.slice/bluetooth.service
└─950 /usr/lib/bluetooth/bluetoothd
systemd[1]: Starting Bluetooth service...
bluetoothd[950]: Starting SDP server
systemd[1]: Started Bluetooth service.
bluetoothd[950]: Bluetooth management interface 1.14 initialized
bluetoothd[950]: Failed to set mode: Blocked through rfkill (0x12)
bluetoothd[950]: Failed to set mode: Blocked through rfkill (0x12)
bluetoothd[950]: Failed to set mode: Blocked through rfkill (0x12)
bluetoothd[950]: Failed to set mode: Blocked through rfkill (0x12)
bluetoothd[950]: Failed to set mode: Blocked through rfkill (0x12)
bluetoothd[950]: Failed to set mode: Failed (0x03)
I use Ubuntu 18.04.1 LTS. When I start bluetooth, it searches for the devices, but it never finishes.
I currently have this problem in Mint 19.3 (kernel 5.4.0-48-generic) on an X1 Carbon ThinkPad. My rfkill showed Bluetooth as Hard blocked. No idea why the following is necessary, but it worked for me:
sudo rfkill unblock bluetooth
I've had to do it twice in the last two weeks, which suggests something random is happening that results in Bluetooth being blocked after a restart. Random issues are always a hoot.
I had the same problem : rfkill did not show the device as blocked but the commands
# rfkill block bluetooth
# rfkill unblock bluetooth
worked for me.
I hope I was helpful
PS : the # means run as root (via sudo or directly logged in as the root user)
For my own sanity, does anyone know why rpcbind (linux) is opening a seemingly random port every time it's restarted? I know it uses port 111, but what is this other port that keeps opening up with it? Thanks.
[root#testmachine ~]# nmap -sU -p 0-65535 127.0.0.1
Starting Nmap 5.51 ( http://nmap.org ) at 2016-03-03 16:00 EST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000080s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE
111/udp open|filtered rpcbind
819/udp open|filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 3.11 seconds
[root#testmachine ~]# service rpcbind restart
Stopping rpcbind: [ OK ]
Starting rpcbind: [ OK ]
[root#testmachine ~]# nmap -sU -p 0-65535 127.0.0.1
Starting Nmap 5.51 ( http://nmap.org ) at 2016-03-03 16:00 EST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000080s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE
111/udp open|filtered rpcbind
846/udp open|filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 2.97 seconds
[root#testmachine ~]# service rpcbind restart
Stopping rpcbind: [ OK ]
Starting rpcbind: [ OK ]
[root#testmachine ~]# nmap -sU -p 0-65535 127.0.0.1
Starting Nmap 5.51 ( http://nmap.org ) at 2016-03-03 16:05 EST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000070s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE
111/udp open|filtered rpcbind
892/udp open|filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 2.86 seconds
More than likely, it's an RPC service. Try the rpcinfo command to see what it is.
Unlike most other network services (FTP, HTTP, SMTP, etc), RPC services are bound to dynamic ports. Instead of connecting directly to the server, an RPC client first sends a request to the RPC port mapper (UDP/111 by default) to find out what port the server is on (a similar is used on Windows).
On a related note, nmap is great, but there are much easier ways to learn about the listening ports on your computer. Try this instead: sudo netstat -anp | grep LISTEN. It's much faster and will even give you the process name and number.
Also, nmap 5.51 is about five years old now. If you use it often, it's worth upgrading to get some new features.
The Debian man page for rpcbind tells me that:
All RPC servers must be restarted if rpcbind is restarted.
The OP didn't mention that they'd done that, so how would any of the RPC services have reregistered? Imagine my surprise, then, on repeating the OP's experiment and applying the rpcinfo -p suggestion from #SArcher to see that all the RPC services were still registered... and on their original ports, suggesting that #SArcher wasn't quite on the money.
If, however, we also apply the other great suggestion from #SArcher, namely to sudo netstat -anp, we get something more interesting. Now we can't |grep LISTEN as suggested because the OP's post says udp and UDP sockets are never in state LISTEN. What we do find is that rpcbind doesn't just have sockets on port 111 - its job - but also another "reserved" port picked seemingly at random when rpcbind starts, just as the OP says.
So "what is this other port for?" you ask. Sorry to tease but I just answered that in my description of:
Debian bug 870579: rpcbind callit replies from a random reserved udp port, making firewalling hard
On redhat there is a separate service called rpcbind.socket. This gets started with rpcbind.service. rpcbind.service first checks if port 111 is available, if it is not available then it chooses a port and starts listening on that port.
In redhat the rpcbind.socket is started first and it startes using port 111. In netstat the port 111 will be displayed as used by systemd. When rpcbind is started it finds that port 111 is already used by systemd and hence it chooses a different port. If you mask the rpcbind.socket service and then start rpcbind.service, rpcbind will start listening on port 111.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I have two PC in my network. I want that PC1 have got ssh access to PC2.
On PC2 I have installed ssh-server. In PC2 inet addr:192.168.0.100 . Next I execute on PC1 this command: ssh root#192.168.0.100 and get error: Connection timeout. I'm use Ubuntu 15.04
Why? What I need configure for my task?
UPD:
sudo netstat -tulpen | grep ":22"
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 75804 8281/sshd
tcp6 0 0 :::22 :::* LISTEN 0 75806 8281/sshd
udp6 0 0 :::22918 :::* 0 65985 6596/dhclient
UPD2:
root#v400:/ # ssh -vv ivan#192.168.0.100
OpenSSH_6.4, OpenSSL 1.0.1j 15 Oct 2014
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.100 [192.168.0.100] port 22.
debug1: connect to address 192.168.0.100 port 22: Connection timed out
ssh: connect to host 192.168.0.100 port 22: Connection timed out
root#v400:/ # nc 192.168.0.100 22
Failed to connect nc 192.168.0.100:22
As came out in comments, disable ufw. Uncomplicated Firewall (ufw) will by default block ssh connections as well.
I am trying to connect to one of our staging Cassandra servers on port 9042 and 9160 here in our company from a dev box.. Through the code, I am not able to connect to it... The program gets hanged at my SELECT query..
So I am wondering is there any way to figure out from my dev box whether these two ports are either blocked on my Cassandra staging servers or not?
Below is the Cassandra staging server url which I am trying to connect from my dev box -
sc-host01.vip.slc.qa.host.com
And my dev box machine url is -
username-dyn-vm1-4.phx-os1.tratus.dev.host.com
Can anyone tell me how to figure out what can be the possible reason to which I am not able to connect to it..
How to check from my dev box whether these ports are opened or not on my Cassandra staging servers?
Update:-
ubuntu#username-dyn-vm1-4:~/build$ traceroute sc-host01.vip.slc.qa.host.com
traceroute to sc-host01.vip.slc.qa.host.com (10.109.107.64), 30 hops max, 60 byte packets
1 10.9.209.1 (10.9.209.1) 4.594 ms 6.628 ms 8.299 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 stgcass01-1.vip.slc.qa.host.com (10.109.107.64) 7.907 ms 3.312 ms 3.950 ms
This is what I got when I ran nmap -
ubuntu#username-dyn-vm1-4:~/build$ nmap -p T:9160 sc-host01.vip.slc.qa.host.com
Starting Nmap 6.00 ( http://nmap.org ) at 2013-10-13 20:01 UTC
Nmap scan report for sc-host01.vip.slc.qa.host.com (10.109.107.64)
Host is up (0.0037s latency).
rDNS record for 10.109.107.64: stgcass01-1.vip.slc.qa.host.com
PORT STATE SERVICE
9160/tcp open apani1
Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds
ubuntu#username-dyn-vm1-48493:~/build$ nmap -p T:9042 sc-host01.vip.slc.qa.host.com
Starting Nmap 6.00 ( http://nmap.org ) at 2013-10-13 20:02 UTC
Nmap scan report for sc-host01.vip.slc.qa.host.com (10.109.107.64)
Host is up (0.0049s latency).
rDNS record for 10.109.107.64: stgcass01-1.vip.slc.qa.host.com
PORT STATE SERVICE
9042/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds
Does that mean port is opened correctly and there is no problem?
And with telnet I get this -
ubuntu#username-dyn-vm1-4:~/build$ telnet sc-host01.vip.slc.qa.host.com 9042
Trying 10.109.107.64...
Connected to stgcass01-1.vip.slc.qa.host.com.
Escape character is '^]'.
^CConnection closed by foreign host.
ubuntu#username-dyn-vm1-4:~/build$ telnet sc-host01.vip.slc.qa.host.com 9160
Trying 10.109.107.64...
Connected to stgcass01-1.vip.slc.qa.host.com.
Have you tried telnet from the dev box?
telnet sc-host01.vip.slc.qa.host.com 9042
telnet sc-host01.vip.slc.qa.host.com 9160
if you get a telnet prompt back, you have connectivity, if it hangs there the connection may be timing out, if the command fails outright you may have firewall rules preventing access. You can try 'traceroute sc-host01.vip.slc.qa.host.com' to see the path the connection is trying to take.
I have a vm in vmware workstation, it's bridged network and DHCP. The IP assigned by DHCP server is 10.21.245.22. Here is my /etc/hosts looks like:
127.0.0.1 hadoop-namenode-01 localhost
I am running command A and B on the box itself.
Command A:
root#hadoop-namenode-01:~# nmap -sT -sU -p- localhost
Starting Nmap 5.21 ( http://nmap.org ) at 2012-08-10 09:32 PDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00029s latency).
rDNS record for 127.0.0.1: hadoop-namenode-01
Not shown: 131058 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
631/tcp open ipp
8020/tcp open unknown
9000/tcp open cslistener
9001/tcp open tor-orport
50070/tcp open unknown
53/udp open|filtered domain
68/udp open|filtered dhcpc
123/udp open ntp
5353/udp open|filtered zeroconf
47982/udp open|filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 12.45 seconds
Command B:
root#hadoop-namenode-01:~# nmap -sT -sU -p- 10.21.245.22
Starting Nmap 5.21 ( http://nmap.org ) at 2012-08-10 09:28 PDT
Nmap scan report for wn7x64-3jql0q1.dub.emea.dell.com (10.21.245.22)
Host is up (0.00029s latency).
Not shown: 131065 closed ports
PORT STATE SERVICE
22/tcp open ssh
68/udp open|filtered dhcpc
123/udp open ntp
5353/udp open|filtered zeroconf
47982/udp open|filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 12.20 seconds
My question is :
since I have no firewall or anything like that blocking ports, why nmap shows more ports open when it's running against localhost while less ports are shown when it's running against the ip.
why nmap shows more ports open when it's running against localhost
while less ports are shown when it's running against the ip
Some applications decided to explicitly listen (bind actually) only on localhost, i.e. 127.0.0.1. You can do a netstat to check things out.
Most of system running process in Linux use loopback (127.0.0.1) ip address to communicate with each other. It doesn't require to send packet outside network.