arping on windows errors out if have multiple network adapters
Casey R
have the arping 2.0.6 version installed, along with WinPCAP 4.1.2.
This issue occurs on multiple systems, both Windows 7 and XP.
If there is only one network adapter available to Windows (e.g. "Local
Area Connection") arping works great. However we noticed on some
machines arping would not return a response from the destination, even
though a regular ping would return a response (so we knew the
destination device was active). Using WireShark we noticed that *no*
ARP packets were being sent out to the destination, even though
according to the -v -v option, arping was properly sending an arp
packet every second.
Upon further investigation we realized arping was not choosing the
Local Area Connection device as its sending interface and MAC address,
even the the Local Area Connection was the proper network path (and
only one connected). For example one system has a Wireless device.
Even though the Wireless "Media State" read "Media Disconnected" in
ipconfig /all, the arping was sent through the Wireless device's
Interface and MAC Address.
Question one would be why does arping (or underlying WinPCAP) decide
to use the "Media Disconnected" Wireless device when sending an
arping? A regular arp/ping travels through the proper device, the
Local Area Connection.
The next step was to disable the Wireless Device through Windows
Control Panel, so only the Local Area Connection appears in an
ipconfig /all. In this instance arping, or underlying drivers, pops up
a generic Windows Error "arping.exe has encountered a problem...". The
extra info is useless: ModName unknown, Offset of 0x0.
Question two: is there any way to circumvent/fix this exception issue?
An interesting side test was to enable the (Media Disconnected)
Wireless device, and disable the Local Area Connection. In this case
arping returns "no network interface found".
The last test was to force a particular interface. With both the LAN
(Local Area Connection) and Wifi devices enabled, I did the following:
arping -i \Device\NPF_{REFERENCE_TO_LAN_DEVICE} -s LAN_MAC_ADDR -v -v
192.168.10.11
This also provided the same exception as with the WIreless Device
enabled. It seems like whenever there are multiple devices on a
system, and you try and use the "correct" one, an exception results.
So what I have seen is:
-If Wireless device and LAN are both enabled, arping attempts to send
ARP packets out the Wireless device, but Wireless is not connected to
anything so no packets are sent
-If the Wireless device is enabled and LAN is disabled, arping
reports "no network interfaces found"
-If the Wireless device is disabled and LAN is enabled, an unknown
exception occurs
-If both the Wireless device and LAN are enabled, and the LAN
interface and source MAC addr are specified, an exception occurs (same
results as disabling the Wireless device)
-Similarly, if I enable any other connection - like one of my VMWare
network adapaters, arping goes through the VMWare connection even
though LAN is still enabled. (I still have this same issue with the
Wifi device on another machine w/o VMWare installed.)
Does anybody know of a way to:
-Have arping, or underlying WinPCAP, always choose the "appropriate"
network interface among multiple interfaces (similar to how the OS
works)
-Allow explicitly specifying the active LAN interface without
receiving an exception?
Thank you
Thomas Habets
> Question one would be why does arping (or underlying WinPCAP) decide
> to use the "Media Disconnected" Wireless device when sending an
> arping?
The interface selection with this version is just a "give me an
interface" libpcap call:
https://github.com/ThomasHabets/arping/blob/arping-2.x/src/windows.c#L86
To find the correct interface one has to traverse the routing table.
This is done in later versions on Unix (and using a much better way in
the soon-to-be-relased Arping 2.10).
Enough info to do the same thing on Windows should be found here:
http://stackoverflow.com/questions/3069082/porting-getifaddrs-to-win-xp
but I don't have a Windows development environment.
Getting the Windows version up to date shouldn't be too hard. I'd help
out anyone who wants to try.
> The next step was to disable the Wireless Device through Windows
> Control Panel, so only the Local Area Connection appears in an
> ipconfig /all. In this instance arping, or underlying drivers, pops up
> a generic Windows Error "arping.exe has encountered a problem...". The
> extra info is useless: ModName unknown, Offset of 0x0.
> Question two: is there any way to circumvent/fix this exception issue?
Adding more verbosity (-vvvvv) doesn't show any interesting info, such
as it still trying to use that interface?
Anyway I have no idea what could be wrong. The Windows version of
Arping is not maintained. But I'm not anti-Windows, I'd welcome
patches.
> The last test was to force a particular interface. With both the LAN
> (Local Area Connection) and Wifi devices enabled, I did the following:
> arping -i \Device\NPF_{REFERENCE_TO_LAN_DEVICE} -s LAN_MAC_ADDR -v -v
> 192.168.10.11
> This also provided the same exception as with the WIreless Device
> enabled.
You mean *disabled*? That's odd. And no output at all?
I assume that by disabling you mean disable the network card in
network settings? Could you try disabling the wireless card under
Device Manager -> Network adapters?
That could be a workaround if you don't need the other interface.
--
typedef struct me_s {
char name[] = { "Thomas Habets" };
char email[] = { "tho...@habets.pp.se" };
char kernel[] = { "Linux" };
char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt" };
char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" };
char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;
