No scan results for IP range 192.168.1.1 - 255 in the new version

wondering about new unwanted DHCP Servers 192.168.1.1 and 192.168.178.1 found in our LAN by the DHCP Server Discovery but no scan results at all were shown by a scan of theese ranges, I did a scan with an older 32-bit version.

Results with version 6.0.6 64-bit:
Range 192.168.1 .1 - 192.168.1 .255 - No scan results
Range 192.168.178.0 - 192.168.178.255 - No scan results

Results with version 5.5.9.0 32-bit:
Range 192.168.1 .1 - 192.168.1 .255 - 3 connected Devices were found by scan
Range 192.168.178.0 - 192.168.178.255 - No scan results

Is this a bug in 6.0.6 ???

So far I returned to the older version hoping to get all devices found by a scan.

Thank you

Check if the scan settings are identical (especially on the General tab).

If they are, then it's most likely your firewall blocking Network Scanner. Turn any firewalls and AV products off or try from a different computer.

Yes, scan settings are absolutely identical in ALL tabs - (except "timeout, ms" in Browsing tab doesn't exist any more) -
and
No, it is not a firewall problem.
and
Yes, it's the same from a different 64-bit computer.
and
Yes, it's the same for the 32-bit version of 6.0.6.

Any ideas?
I think it's supposed to be a bug in 6.0.6.

Unfortunately I don't have any other older versions any more to check which version started showing this behaviour.

Interesting. Could you please do two more things?

1. Post here a complete output of the ipconfig /all command launched at a command prompt.
2. Try to scan with the older (working) version with ping method set to ICMP only and let me know if it still works.

1. here is the output ...
--------------------------------
Windows-IP-Konfiguration

Hostname . . . . . . . . . . . . : Fujitsu
Prim„res DNS-Suffix . . . . . . . :
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein

Ethernet-Adapter LAN-Verbindung:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Intel(R) 82567LM-3-Gigabit-Netzwerkverbindung
Physikalische Adresse . . . . . . : 00-19-99-72-69-09
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::9d65:9098:fc7f:ac6f%11(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.0.27(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Montag, 6. Juli 2015 09:35:18
Lease l„uft ab. . . . . . . . . . : Dienstag, 7. Juli 2015 09:35:17
Standardgateway . . . . . . . . . : 192.168.0.1
DHCP-Server . . . . . . . . . . . : 192.168.0.1
DHCPv6-IAID . . . . . . . . . . . : 234887577
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-19-2E-BE-91-00-19-99-72-69-09
DNS-Server . . . . . . . . . . . : 80.69.100.206
80.69.100.182
NetBIOS ber TCP/IP . . . . . . . : Aktiviert

Tunneladapter isatap.{76B1D657-4A8E-4D04-BDD6-1F096766E582}:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja

Tunneladapter Teredo Tunneling Pseudo-Interface:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja

2. with ping method set to ICMP only ...
---------------------------------
same thing.

I get results for this IP range from the old version, but not from the new one.

I am afraid I am out of ideas in this case. It's by no means a widespread issue as thousands of users have updated to the latest version and no one has reported an issue like this.

I suggest to try sniffing ICMP traffic in and out of the computer using Wireshark to see whether it actually sends echo requests and receives any response. We can also do a teamviewer session where I could have a look at what's happening.

@plotz

I have found that depending on the anti-virus software used on the client you are trying to scan/ping it can block ping for a while or all traffic from your IP address. If you try to scan the same subnet too quickly the AV software may block the scan as a threat. Plus the more you are scanning a device the more AV software can think it is a threat I have this happen all the time. I need the client information but I want my AV software to protect the computer so there is a hard balance between the two. I hope that helps -WS

Stopping AV Guard doesn't change the situation.

Addendum:
switching on "Show Dead Devices" the IPs of the living devices in this IP range shown by Version 5.5.9.0 will be listed as dead devices in Version 6.0.6.

@plotz
Here i upload my collection of old netscan may be u need for test purpose at here Old NetScan

@Hendry

Thanks. Your collection ends at version 5.5.12.0.

5.5.12.0 also works fine.

There are much more IP ranges 6.0.6 doesn't show, e.g. 192.168.10.0 - 255
Version 5.5.x.x shows 5 cell phones in this range, Version 6.0.6 nothing.

Any older versions between 5.5.12.0 and 6.0.6 available for testing?

Thank you

Try these builds and let me on which one it stops working.

It is 6.0.4 which stops working.
Last working Version is 6.0.3 for both 64bit and 32bit version.

Hope this helps.

Cheers

That's what I thought. Now please try this build and before launching the scan, turn on the new option named "Allow ARP outside current subnet".

Yes !

What's the background?
Thanks alot

Basically what happens is this:
Network Scanner discovers devices by sending an ICMP request aka ping and an ARP request. As some devices don't respond to ICMP requests, sending an ARP request is the only way to detect them.

The problem is that ARP doesn't work across subnets and if we send an ARP request to another subnet, one of the following may happen:

1. The router silently drops the request as non-routable. In this case no device is detected as there is no response.
2. The router responds to the request with its own MAC address. In this case all IP addresses are incorrectly detected as devices.
3. The router runs a proxy ARP service and correctly forwards ARP back and forth. In this case the devices are detected normally.

Your network seems to be configured as in scenario 3, though scenarios 1 and 2 are more common. As of version 6.0.4 Network Scanner no longer sends ARP requests when scanning a different subnet, because in scenario 2 it detects devices that are not there on every IP address. We did this due to receiving a lot of messages from users claiming Network Scanner was detecting non-existent devices.

So the latest build simply has an option that allows ARP requests to be sent to a different subnet, which works for scenario 3, but for scenario 2 it would produce false positives and should be disabled.

Thanks for your great work, Andrew!
And for this great tool!

Hello,

I'm having the exact same problem, I've been using this prog for many years and the latter versions are giving me this problem (no results), FYI, I'm running version 6.0.9 x64 on a Win10 machine. I had a very old version nearby (version 3.5 ) and ran it successfully, I can see the results and no problems at all. From what I read above, it looks like version 6.0.3 was still working, would it be possible to let us download this file again ?
Thank you.

PS. If you want me to test things, just let me know.

I meant version 6.0.8 and NOT 6.0.9 as I wrote in my previous post, since it's not yet released

Did you try turning the above-mentioned Allow ARP outside current subnet option on?

If so I need details, screen shots of working and not working cases, as well as your IP address configuration.

With or without the Allow ARP outside current subnet option on, it doesn't change anything, that's the first thing I tried since you have recommended it to others previously.

I have no recent version working, I have only a very old one the 3.5 that does work perfectly, that's why I asked if I could download the version 6.0.3, is it possible to make it available again so I can test with it ?

I don't have version 6.0.3 at hand, but I have version 5.4.12. Give it a go and make sure your old version and the new one have identical settings, in particular both are set to use ping (ICMP) and arping (ARP) for device discovery.

I have most versions going back to the early 5 versions if needed. -WS

@Andrew
I have just tried your version 5.4.12 and it worked flawlessly, I can see the results as I used to.
Now let me know which screenshots you need to investigate ?


@WindowsStar
Thanks for your proposition, do you have the most recent version before 6.0.4 ? for example 6.0.3 and below ? Thank you.

Version 6.0.8 x64


As you can see it finds something but doesn't display anything.
___________


Version 5.4.12 x64


Everything is OK here.

I see, there was a similar report from another guy, though I am not sure if the reason is the same.

Please check under View - Visible Columns in the main menu, it appears somehow they are all deactivated.

you made it !!!

I never thought of looking there, as I've never needed to go there, never ever !

So I guess in the next releases you need to force those columns !

Thanks again for your help, and long live to Network Scanner --> the best scanner I've ever found !

In fact it's almost fixed... I can see the results now but the MAC address column is still empty !! I can see the IP address, the host names and the response time, but nothing shows up in the MAC address column (expect the column name itself). Should I tick some other option somewhere ?

Ok, I can see the MAC addresses now, in fact I had to check the "Resolve MAC addresses" option in the "Additional" tab, I thought this option was used to resolve MAC addresses to NIC vendors, wrong interpretation I guess

It's all good now !

No worries, I'll add a warning for the case when no columns are shown to make it easier for users to rectify