GithubHelp home page GithubHelp logo

node-arping's People

Contributors

cetfor avatar dresende avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar

Forkers

halleyassist stfnhmplr eyecuvision

node-arping's Issues

How do I specify device to use

@dresende
I have multiple interfaces defined on my server. One of them is used as prod interface and others might be used for internal communication. So how do I specify what device to be used in the library?

For instance, on terminal I use

# arping 192.168.122.3 -I prod
ARPING 192.168.122.3 from 192.168.122.2 prod
Unicast reply from 192.168.122.3 [52:54:00:6C:AE:66]  0.873ms
Unicast reply from 192.168.122.3 [52:54:00:6C:AE:66]  1.807ms
Unicast reply from 192.168.122.3 [52:54:00:6C:AE:66]  1.920ms
Unicast reply from 192.168.122.3 [52:54:00:6C:AE:66]  0.920ms

where in prod is the name of the interface

let me know if anything needs clarification

edit: After reading the code, I figured out that I need to use library like

arp.ping("192.168.122.3", {spa: "192.168.122.2"}, (err, info) => console.log(err, info))

OR

arp.ping("192.168.122.3", {sha: "52:54:00:93:e4:27"}, (err, info) => console.log(err, info))

but I always get error:

    at Timeout.setTimeout [as _onTimeout] (/opt/hive/services/hive-fabric/node_modules/arping/index.js:181:8)
    at ontimeout (timers.js:436:11)
    at tryOnTimeout (timers.js:300:5)
    at listOnTimeout (timers.js:263:5)
    at Timer.processTimers (timers.js:223:10) undefined

Intermittent Segmentation Fault on ARP Ping

Occasionally ARP pings result in a Segmentation fault: 11.

Consider this example script that sends an ARP ping to my router:

const arp = require("arping");

arp.ping("192.168.10.1", (err, info) => {
  if (err) throw err;
  console.log("%s responded in %s secs", info.tha, info.elapsed);
});

Generally this returns as expected.

totes:arp john$ node app.js
60:73:5c:98:72:f3 responded in 0.002274009 secs

But sometimes a native module appears to crash.

totes:arp john$ node app.js
60:73:5c:98:72:f3 responded in 0.001657804 secs
Segmentation fault: 11

I've used raw-socket and pcap2 extensively in projects and I've never seen this issue. I suspected the problem is certainly occurring one of these native modules - but I was wondering if there was something we could do in node-arping to avoid this issue.

I attempted to track this down using the debugger in Visual Studio Code, but try as I might, I cannot get the Segfault to occur under the debugger! So I'm thinking this may be related to a race condition that's not ocuring with the overhead of the debugger in the loop.

To help track this down, I'm used the Node.js segfault-handler module. Then run this script:

const arp = require("arping");
const SegfaultHandler = require("segfault-handler");
SegfaultHandler.registerHandler("crash.log");

arp.ping("192.168.10.1", (err, info) => {
  if (err) throw err;
  console.log("%s responded in %s secs", info.tha, info.elapsed);
});

This is the same script as I ran earlier, just with segfault-handler wired up. Here's the output:

totes:arp john$ node app.js
60:73:5c:98:72:f3 responded in 0.001684102 secs
PID 12154 received SIGSEGV for address: 0x0
0   segfault-handler.node               0x00000001027b2408 _ZL16segfault_handleriP9__siginfoPv + 312
1   libsystem_platform.dylib            0x00007fff65bc9f5a _sigtramp + 26
2   ???                                 0x0000000000000002 0x0 + 2
3   pcap_binding.node                   0x00000001027a8073 _ZN3Nan3impL23FunctionCallbackWrapperERKN2v820FunctionCallbackInfoINS1_5ValueEEE + 136
4   node                                0x000000010018ada2 _ZN2v88internal25FunctionCallbackArguments4CallEPFvRKNS_20FunctionCallbackInfoINS_5ValueEEEE + 466
5   node                                0x00000001001eb500 _ZN2v88internal12_GLOBAL__N_119HandleApiCallHelperILb0EEENS0_11MaybeHandleINS0_6ObjectEEEPNS0_7IsolateENS0_6HandleINS0_10HeapObjectEEESA_NS8_INS0_20FunctionTemplateInfoEEENS8_IS4_EENS0_16BuiltinArgumentsE + 816
6   node                                0x00000001001eab40 _ZN2v88internalL26Builtin_Impl_HandleApiCallENS0_16BuiltinArgumentsEPNS0_7IsolateE + 288
7   ???                                 0x000007f8328042fd 0x0 + 8762580550397
8   ???                                 0x000007f8328bd1d6 0x0 + 8762581307862
Segmentation fault: 11

Multiple crashes result in very similar traces. So the best guess from here, is that the issue is occurring in pcap_binding.node which is part of the pcap2 module.

The mangled name _ZN3Nan3impL23FunctionCallbackWrapperERKN2v820FunctionCallbackInfoINS1_5ValueEEE corresponds to Nan::imp::FunctionCallbackWrapper. Checking this out in Binary Ninja shows an issue with a dynamic call call r15 which the r15 register holds an invalid value -- apparently 0x0. r15 is set in the Nan::imp::FunctionCallbackWrapper from the return value of v8::External::Value -- in the depths of the V8 engine.

I'll add some links to screens shots soon and continue debugging this issue. My hope is that we may be able to avoid a clear problem in pcap2 by making a change in this module.

Nan::imp::FunctionCallbackWrapper see insn @ 0x2070
https://imgur.com/a/pWLcqki

Target Hardware Address is incorrect

Hello @dresende, thanks for the very cool module!

I was just checking it out and noticed that the ping method returns packet.payload.payload.target_ha which is the MAC of the system running the ARP ping, not the MAC of the responding system, which is packet.payload.payload.sender_ha.

For example, no matter which IP I scan 192.168.10.1, 192.168.10.20, etc. this module will always return 8c:85:90:58:97:84 responded in X.XXX secs. 8c:85:90:58:97:84 is the MAC address for my MacBook's network interface.

If I switch target_ha to sender_ha on the following line, everything works as expected.

node-arping/index.js

Line 165 in 1035634

tha : packet.payload.payload.target_ha.toString()

I submitted a PR for this.

Pinging a host that isn't on the network results in an unhandled TypeError exception

This module works as expected when scanning IPs that are known to be listening on the network. When you scan an IP that is not on the network, the module crashes with a TypeError in pcap2 session.js:124 (in pcap2 v3.0.4).

Consider the following script

const arp = require("arping");

function arpPing(ip) {
  arp.ping(ip, (err, info) => {
    if (err) throw err;
    console.log("%s - %s", ip, info.tha);
  });
}

We can very quickly scan live hosts on the network in succession.

arpPing("192.168.10.1");
arpPing("192.168.10.20");
arpPing("192.168.10.21");
arpPing("192.168.10.254");

192.168.10.1 - 60:73:5c:98:72:f3
192.168.10.20 - 00:0f:ff:58:1e:39
192.168.10.21 - 00:0f:ff:17:29:7a
192.168.10.254 - 00:0a:dd:03:4f:5a

But if we try to scan just a single host that isn't listening this happens.

arpPing("192.168.10.2");

/Users/john/Desktop/scratch/arp/node_modules/pcap2/lib/session.js:124
    return this.session.inject(data);
                        ^

TypeError: First argument must be a buffer
    at LiveSession.Session.inject (/Users/john/Desktop/scratch/arp/node_modules/pcap2/lib/session.js:124:25)
    at try_ping (/Users/john/Desktop/scratch/arp/node_modules/arping/index.js:172:10)
    at done (/Users/john/Desktop/scratch/arp/node_modules/arping/index.js:144:11)
    at Timeout.setTimeout [as _onTimeout] (/Users/john/Desktop/scratch/arp/node_modules/arping/index.js:179:3)
    at ontimeout (timers.js:466:11)
    at tryOnTimeout (timers.js:304:5)
    at Timer.listOnTimeout (timers.js:267:5)

I'm looking into this issue. I'll submit a PR for it once I track it down but I probably won't get to it until next week.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.