[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1161
  • Last Modified:

trying to do threaded ping scan of subnet - no echo reply received

I am trying to do a fast ping scan of a private subnet using raw sockets and threads.  Reader thread is waiting on FD_READ event (raw socket) to collect echo replies.  Main thread issues a burst of echo requests (raw socket not icmp.dll) to trigger the responses.  This results in a large number of ARP requests (only 3 devices currently on subnet), which is to be expected.  I have devices at 192.168.1.1, 192.168.1.71, and 192.168.1.101 (101 is my host machine).  I see the ARPs fly, get an ARP response from 192.168.1.1, more ARPs, echo request goes out, echo response comes back (from .1), echo request goes to .71 but never get an echo response again.  Why don't I get the response from .71?  If I change 192.168.1.1 to .4 then I get no echo response at all (program starts sending with .1, so the ARPs start).  It seems as if the ARPs are causing the echo requests to be ignored.  Looking for why and how to make this work.  Need to scan multiple subnets to ensure local machines are up and running.  Waiting for seconds between pings is not acceptable.  My only alternative seems to be an "ARP scan".  Ideas?  Don't respond with "it can't be done".  If nothing else it can be done via ARP, but I at least want to know why it fails with ICMP.  Current code is written in C++ and running on winXP.  I am monitoring traffic using ethereal (on another machine - all connected to a 10-base hub).

Bob
0
bainbob
Asked:
bainbob
  • 3
  • 3
  • 2
  • +2
1 Solution
 
Bill BachPresidentCommented:
When in doubt, start with the obvious stuff.  

1) "It seems as if the ARPs are causing the echo requests to be ignored."  Have you verified that the machines are all talking 10Mbps HALF DUPLEX?  Some "auto-detect" network cards may not work correctly, and may stick on full duplex, which could certainly cause packets to become lost and give you this symptom.

2) "echo request goes to .71 but never get an echo response again." Regarding the .71 machine -- does it have a firewall enabled?  It could be blocking the PING packet.  You confirmed that NO reply came back from Ethereal/Wireshark, right?  If that's the case, then the problem is not with your code, but with the other computer.

0
 
bainbobAuthor Commented:
I actually have two other nodes out there right now (70 and 71, plus my host at 101).  No firewalls and all three respond to normal pings just fine.  I wrote another version of this code that spawns 254 threads.  Each thread creates a socket, sends the echo request, and waits 1 second for the resonse before terminating (terminates immediately if it gets an echo reply).  I fire off all 254 threads (each with IDLE priority) in a loop and I get the two echo replies.  This pretty much kills any ideas about half/full duplex, firewalls, etc.   For the life of me I can't figure this one out.  There should be no difference between one thread with one socket collecting everything and 254 threads (254 sockets) doing it, but there is.   Yes, I'm watching everything with Ethereal and the replies are not there.  One tid-bit: if I change the IP of .70 machine to .1 (so it is the first one to get pinged) then it will send back the reply (but 71 will not).  It seems that once the ARPs start something bad happens (but it does not happen with 254 sockets running).  I need to see what's happening at a lower level in the stack.  Something is going wrong but I don't know what it is.
0
 
Adrien de CroyCommented:
there can be several reasons a host that replies to normal ping won't reply to an ICMP packet you are generating and sending.

The most common problem is an invalid checksum in the ICMP echo packet.  Have you validated this?
0
Get your Conversational Ransomware Defense e‑book

This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.

 
bainbobAuthor Commented:
Yes, the checksum is valid.  The same code generates all of the packets.  So far as the echo coming back is concerned, I only get an echo reply if the host (recient of the echo request) is the first IP that I ping.  If he is not the first IP then he (meaning ARP requests for a non-existant host have been sent first) then he never replies to the echo request.
0
 
ll_jaxnCommented:
You dont have your variables defined in the launcher address space do you?

Are the ping attempts target IPS right?
Are you overloading your TCP Stack with two many requests?
0
 
ll_jaxnCommented:
Why are you diong this again?
http://bb4.com/
0
 
Adrien de CroyCommented:
Hmm

I'm wondering if the raw socket is somehow binding itself to the first IP address you send to.  Which send API are you using?
0
 
bainbobAuthor Commented:
The raw socket is bound to the ip of the nic.  It is connectionless.  It cannot be bound to an external ip.  I'm glad to see that someone still looks at this post - I'm about ready to give up on "experts"...
0
 
Adrien de CroyCommented:
sure, I meant the OS may "bind" it the first time you use it, just like it does for a SOCK_STREAM socket.

So even though you only bound it to your local interface, you never know what the OS is doing underneath.  MS have been (AFAIK) trying to deprecate raw sockets for years, it's possibly a security decision.  Have you tried using a new socket for each one?

Otherwise you'll need to write your own NDIS protocol driver so you can use NdisSend to send your own packets without creating any sockets.
0
 
Computer101Commented:
Forced accept.

Computer101
Community Support Moderator
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 3
  • 3
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now