I have a (Xen) VM running CentOS Linux that had been inventoried for [a long time] under Spiceworks v6, but now, under v7, it is unscannable. I’ve tried directly entering the SSH credentials, and SNMP info, and it says ~“It Worked!” “Rescanning…” etc., but then goes back to being unknown. The SSH creds work fine in PuTTY. What else can I try?

1 Spice up

Hi Pete,

If you delete that device from inventory, does it scan back in properly on the next go around?

Nope. Just keeps showing up as just an IP address, unknown type, “No open ports for this device were found to be responding.” – even though it also says that SSH and RDP ports are open (I’m running xrdp on it).

I’ll try it again, just for kicks :slight_smile:

Do the SSH creds work in PuTTY from the Spiceworks host specifically?

Ah… you might be onto something there. Now that I’ve deleted it (again), I have to set up a custom one-time scan for just that IP unless I want to wait until tomorrow, right?

Yes, or edit/modify the time for the Scheduled scan to something sooner, then restart the app to flush the schedules and have it run the “All” scan sooner.

Well, my 6am full scan discovered the VM, but again refused to inventory it:

“No open ports for this device were found to be responding.” yet it also says that SSH (22) and RDP (3389) are both open.

If I tell SW it’s a “Unix Machine”, and enter the SSH creds, I get the “Yep! Worked. We’re rescanning this device now.” messages, and then it goes back to “No open ports…” Same thing if I provide the SNMP info.

Do you have any HTTP accounts defined under Settings → Network Scan → Stored Passwords?

Nope. Why?

That can sometimes cause some confusion.

I’ll send you some instructions on getting your log files to us.

Standby… :slight_smile:

Scott Miller sez that the fact I have RDP open on this Linux box is what’s fouling up the scan - he said SW thinks it’s a Windows box because of the RDP.

1 Spice up

Scott Miller may well be correct, but the fact that you’ve tried to tell Spiceworks specifically what the device is and provided the port to use would indicate that there’s a problem with that logic. The logs will help identify whether that’s the case.

Yup, that will definitely do it.

Turn off the service/block the port, rescan the device. That’d be a quick way to determine whether it’ll resolve the issue.

1 Spice up

Done. SW scan was now able to get the VM’s name - but it stopped there and asked me if it was a desk lamp. So I told it it was a Unix Computer, again, and reentered the SSH creds, and it scanned.

Yay!

Now, how do I make this work while having RDP enabled?

2 Spice ups

The log files also support Scott’s notion - I’m poking around to see if it’s already been logged as a defect. I’ll keep you posted!

It’s a well known issue in the community. Would be surprising if it wasn’t logged.

I think I earned a BA via another thread on this one :slight_smile:

It was logged and resolved, but for a slightly different case.