Run arp shell command in php ?

<?php
$arpa = shell_exec('arp -a');
$arpa = stristr($arpa, 'Type');
$arpa = preg_replace("/\s+/", " ", $arpa);
$arpat = explode(" ",$arpa);

list($k,$v) = each($arpat);
while (list($k, $v) = each($arpat)) {
$ippp = $v;
list($k, $v) = each($arpat);
$iddd = $v;
list($k, $v) = each($arpat);
$typer = $v;
if ($v && $iddd && ($typer != "invalid")) {
$arpa_new_status[$iddd]['ip'] = $ippp;
}
}
ksort($arpa_new_status);
reset($arpa_new_status);
foreach ($arpa_new_status as $mac => $values) {
$ips_array[] = array("mac" => $mac, "ip" => $values['ip']);
}
print_r($ips_array);
?>

PHP Mac Address Formatting

I have been working on a small php app to perform a network scan and fill a database with the discovered information. The issue is that, depending on what you perform the scan with, the MAC addresses are in a number of different formats. This PHP functions validates a MAC and returns false if its not valid or a variety of formats depending on your needs! If anyone has any thoughts on improving this function feel free to let me know and I will post the updates.

function format_mac($mac, $format='linux'){

	$mac = preg_replace("/[^a-fA-F0-9]/",'',$mac);

	$mac = (str_split($mac,2));
	if(!(count($mac) == 6))
		return false;

	if($format == 'linux' || $format == ':'){
		return $mac[0]. ":" . $mac[1] . ":" . $mac[2]. ":" . $mac[3] . ":" . $mac[4]. ":" . $mac[5];
	}elseif($format == 'windows' || $format == '-'){
		return $mac[0]. "-" . $mac[1] . "-" . $mac[2]. "-" . $mac[3] . "-" . $mac[4]. "-" . $mac[5];
	}elseif($format == 'cisco'){
		return $mac[0] . $mac[1] . ":" . $mac[2] . $mac[3] . ":" . $mac[4] . $mac[5];
	}else{
		return $mac[0]. "$format" . $mac[1] . "$format" . $mac[2]. "$format"
             . $mac[3] . "$format" . $mac[4]. "$format" . $mac[5];
	}	
}

//some usage examples
$rmac = "00:12:23:56:78:90";

echo format_mac($rmac,'cisco');
//0012:2356:7890

echo format_mac($rmac,'-');
//00-12-23-56-78-90

echo format_mac($rmac,'linux');
//00:12:23:56:78:90

echo format_mac($rmac,'?');
//00?12?23?56?78?90

Foundations: What Are NIC, MAC and ARP?

by Corey Nachreiner, WatchGuard Network Security Analyst, and Scott Pinzon, LiveSecurity Content Editor

“Avast! Belay the port jib, and scupper the mains’l on the poop deck!”

This means something important to pirates. (Possibly.) It also illustrates how every industry has its own jargon, rich in technical meaning to insiders, but often impenetrable to outsiders. And the first time you hear a network geek tell you, “Of course the device can’t be found, because its MAC address isn’t in the ARP table,” well, you just wanna keelhaul that bilge rat on the lee side of a mizzenmast.

A more effective and less violent response would be to learn these important terms. Devices on a network don’t immediately become aware of the existence and location of other devices on the same network. If you’ve ever wondered how they discover one another, then you’re ready to enter the not-really-that-mysterious world of NIC, MAC, and ARP (pronounced as words, not as spelled-out letters). Full speed ahead, matey!

Two addresses in one

To explain NIC, MAC, and ARP, we’ll start with one computer: yours. We’ll call this desktop system Redbeard, one of several computers on a LAN.

You’re probably aware that Redbeard has an Internet Protocol (IP) address. (If this concept is new to you, first read Foundations: Understanding IP Addresses and Binary.) An IP address acts like a mailing address to help other computers deliver network traffic to Redbeard. But IP addresses also present complications. Some addresses are static, meaning, more or less permanent. But other IP addresses are dynamic, meaning, assigned on the fly from (and returned to) a range of IP addresses (for example, 192.168.0.1 – 192.168.0.254). Dynamic IP addressing is part of what enables you to take your laptop somewhere new, connect to the Internet, and receive IP traffic. When you do so, somewhere a DHCP server has dynamically allocated a temporary IP address to your laptop.

So with machines coming and going on networks, and IP addresses ever changing, how do other computers on your network find Redbeard? The secret (well, not really a secret; just a fact that veteran administrators know so well, they forgot to tell you) is this: every networked device actually has two addresses. One is the IP address, which might or might not change. The other is the MAC address, which typically does not change.

MAC is just my NIC name

When you connect a computer to your Ethernet LAN, do you know what you’re plugging the Ethernet cable into? From the outside, it looks like you’re plugging it into a metal case, but you’re not. Inside the case is a Network Interface Card (NIC). A NIC is a special hardware card within any networked device (computer, printer, router, etc.) that handles all the technical aspects of sending and receiving data packets over a computer network.

Like your mailing address at home, your computer’s NIC has a unique address. This addressmust be unique in all the world. Otherwise, network traffic couldn’t find its way to the right computer.

The distinctive address that identifies a NIC is called the Media Access Control (MAC) address. A MAC address is a unique character string, and since it identifies a specific physical device — one individual NIC — the MAC address, by convention, never changes for the life of the NIC. Two NICs never have the same MAC address (unless some manufacturer screws up royally [which has happened]). Because your NIC’s MAC address is permanent, it’s often referred to as the “real,” or physical, address of a computer.

A MAC address is formatted as a six-byte, hexadecimal number, like this:

00:90:7F:12:DE:7F

In hexadecimal notation, it takes merely two characters to represent a byte. Each byte in a MAC address is separated by either a colon (:) or a hyphen (-).

You don’t get to assign MAC addresses the way you do IP addresses. Instead, manufacturers pre-program a chip on each NIC with its exclusive MAC address. The IEEE Standards Association assigns each NIC manufacturer a special three-byte code, called an Organizationally Unique Identifier (OUI, which you should not confuse with the men’s magazine of the same name — trust us), which identifies that particular manufacturer. The first half (three bytes) of any MAC address expresses this manufacturer code. For example, taking the OUI in the MAC address shown above, you can look up 00:90:7F on IEEE’s OUI registry and find that 00:90:7F indicates a NIC from WatchGuard.

The second half of a MAC address differentiates one NIC from another. The NIC manufacturers ensure that the MAC address for each NIC they ship ends with a unique three-byte number. This is feasible because a three-byte hexadecimal address offers over sixteen million possible variations.

The yin and yang of MAC and IP

MAC addresses seem pretty cool, right? But you have no control over what MAC addresses will be in the devices you purchase, and you normally can’t alter them, so it’s impossible to organize anything by MAC address. MAC addresses are not routable, either; in other words, Internet protocols will not accept a MAC address as a destination (for one thing, it’s two bytes longer than an IP address). The MAC concept doesn’t scale. So you only utilize MAC addresses locally, not across a router.

IP addresses, on the other hand, scale extremely well. On your private network, you can slice ’em into ranges that make sense to you (known as subnetworking, or subnetting). You can decide at a whim what IP address any device or group of devices should have.

So what we have is yin and yang. The malleable IP address gives your network some flexible manageability. The never-changing MAC provides a specific, reliable address for a physical device.

Or you could say, we have the long and the short of it. IP addresses route a packet across the whole global Internet, while MAC addresses help the packet make the small, local hop between hardware devices. Sophisticated networking is possible because each of your networked devices has both a MAC and an IP address.

Network Roll Call: ARP

We began by wondering, “How do devices on a local network become aware of one another?” NICs and MACs are important pieces of the answer, but your network must learn to pair a MAC address with the IP address for the same machine. It does so using a technique called Address Resolution Protocol (ARP, pronounced like a pirate with the hiccups).

Think of ARP as network roll call. Remember the first day of fourth grade? At the beginning of class, the teacher called from a list of names, expecting you to reply when she called yours. She did this to associate your name with your face. Every kid heard every name, but answered only to his or her own name. ARP uses a similar technique to associate an IP address to the MAC address.

Let’s assign Redbeard the IP address, 192.168.39.101, and suppose its NIC has the MAC address, 00:A0:24:30:2E:13. And suppose you need to send a file to Larry in Accounting — or more literally, to his computer, Beancounter. When Redbeard attempts to send Beancounter a file, Redbeard first obtains Beancounter’s IP address. Upon seeing that the IP address is local (on the same subnetwork), Redbeard knows he is capable of sending the file to its destination, if he learns the “real” (MAC) address associated with that IP address. To learn the MAC address, Redbeard does what your teacher did on the first day of school. He calls out to the entire local network asking that the computer with the IP in question reply “Here!” with a MAC address.

Let’s say that Beancounter has the IP, 192.168.39.148. To find the MAC address for Beancounter, Redbeard would send the following (simplified) ARP request:

From: (Redbeard’s MAC address)	To: (Broadcast address)	Packet Content
00:A0:24:30:2E:13	FF:FF:FF:FF:FF:FF	Who has 192.168.39.148? Tell 192.168.39.101.

Notice the special address in the “To” field above. That special address (all Fs) is the MACbroadcast address. Anything sent to that address goes to every computer on Redbeard’s LAN segment. All those computers receive the message, but ignore it, because it doesn’t pertain to them — with the exception of Beancounter. Because Beancounter is 192.168.39.148, it replies with its MAC address, like this:

From: (Beancounter’s MAC address)	To: (Redbeard’s MAC address)	Packet Content
00:A0:24:30:4C:23	00:A0:24:30:2E:13	I have 192.168.39.148

Now Redbeard has “resolved” the IP address 192.168.39.148 to its MAC address, 00:A0:24:30:4C:23. Redbeard can send files directly to the correct piece of hardware that accepts network traffic on behalf of Beancounter (Beancounter’s NIC). Bonus: Beancounter also remembers Redbeard’s IP address and MAC address, because they were part of Redbeard’s initial ARP request.

This entire process we’ve just described is what geeks mean when they say “it’s ARPing for a MAC address.”

I’ve got your number

Having successfully ARPed, Redbeard stashes the newly-learned MAC/IP pair in an ARP cache. The ARP cache is a small segment of memory your computer reserves to temporarily store a table of MAC addresses and their associated IP addresses. Your computer keeps this table for efficiency so that it doesn’t have to keep broadcasting ARP requests to computers it has already queried. If Redbeard needs to send something else to Beancounter soon, Redbeard will obtain Beancounter’s MAC address from Redbeard’s own on-board treasure trove, the ARP cache.

However, the ARP cache sometimes becomes a problem. Every device on your LAN maintains its own ARP cache. Routers, in particular, do not update their ARP cache as frequently as computers. When you replace an old device on your network, the local router might not find the new device because it’s relying on data in the ARP cache that is now outdated. (This is a common issue when routers cannot find a newly installed Firebox.) That’s why you should flush your router’s ARP cache when installing a new device for the first time (your router’s manual should tell you how).

Pirates pronounce it, “ARrrrrrrrP!”

You’ll rarely have to deal with ARP and MAC during day-to-day operations. Mostly, they work behind the scenes and require very little administrative attention. However, sometimes you encounter problems where understanding MAC addresses and the ARP protocol becomes helpful in troubleshooting network issues. One form of hacker attack even involves feeding bad data to ARP tables, a practice known as ARP poisoning. So a little investment in learning about NIC, MAC, and ARP may prevent your network from careening into Davey Jones’ Locker — plus, your mastery of jargon will impress your fellow hearties sailing the Internet’s bounding main.

References:

RFC 826: An Ethernet Address Resolution Protocol
Overview of ARP
Talk Like a Pirate Day
Pirate Jargon Definitions

The ARP scanner – Linux Man Page

Synopsis

arp-scan [options] [hosts…]

Target hosts must be specified on the command line unless the –file option is given, in which case the targets are read from the specified file instead, or the –localnet option is used, in which case the targets are generated from the network interface IP address and netmask.

You will need to be root, or arp-scan must be SUID root, in order to run arp-scan, because the functions that it uses to read and write packets require root privilege.

The target hosts can be specified as IP addresses or hostnames. You can also specify the target as IPnetwork/bits (e.g. 192.168.1.0/24) to specify all hosts in the given network (network and broadcast addresses included), IPstart-IPend (e.g. 192.168.1.3-192.168.1.27) to specify all hosts in the inclusive range, or IPnetwork:NetMask (e.g. 192.168.1.0:255.255.255.0) to specify all hosts in the given network and mask.

Description

arp-scan sends ARP packets to hosts on the local network and displays any responses that are received. The network interface to use can be specified with the –interface option. If this option is not present, arp-scan will search the system interface list for the lowest numbered, configured up interface (excluding loopback). By default, the ARP packets are sent to the Ethernet broadcast address, ff:ff:ff:ff:ff:ff, but that can be changed with the –destaddr option.

The target hosts to scan may be specified in one of three ways: by specifying the targets on the command line; by specifying a file containing the targets with the –file option; or by specifying the –localnet option which causes all possible hosts on the network attached to the interface (as defined by the interface address and mask) to be scanned. For hosts specified on the command line, or with the –file For hosts specified on the command line, or with the –file option, you can use either IP addresses or hostnames. You can also use network specifications IPnetwork/bits, IPstart-IPend, or IPnetwork:NetMask.

The list of target hosts is stored in memory. Each host in this list uses 28 bytes of memory, so scanning a Class-B network (65,536 hosts) requires about 1.75MB of memory for the list, and scanning a Class-A (16,777,216 hosts) requires about 448MB.

arp-scan supports Ethernet and 802.11 wireless networks. It could also support token ring and FDDI, but they have not been tested. It does not support serial links such as PPP or SLIP, because ARP is not supported on them.

The ARP protocol is a layer-2 (datalink layer) protocol that is used to determine a host’s layer-2 address given its layer-3 (network layer) address. ARP was designed to work with any layer-2 and layer-3 address format, but the most common use is to map IP addresses to Ethernet hardware addresses, and this is what arp-scan supports. ARP only operates on the local network, and cannot be routed. Although the ARP protocol makes use of IP addresses, it is not an IP-based protocol and arp-scan can be used on an interface that is not configured for IP.

ARP is only used by IPv4 hosts. IPv6 uses NDP (neighbour discovery protocol) instead, which is a different protocol and is not supported by arp-scan.

One ARP packet is sent for each for each target host, with the target protocol address (the ar$tpa field) set to the IP address of this host. If a host does not respond, then the ARP packet will be re-sent once more. The maximum number of retries can be changed with the –retry option. Reducing the number of retries will reduce the scanning time at the possible risk of missing some results due to packet loss.

You can specify the bandwidth that arp-scan will use for the outgoing ARP packets with the –bandwidth option. By default, it uses a bandwidth of 256000 bits per second. Increasing the bandwidth will reduce the scanning time, but setting the bandwidth too high may result in an ARP storm which can disrupt network operation. Also, setting the bandwidth too high can send packets faster than the network interface can transmit them, which will eventually fill the kernel’s transmit buffer resulting in the error message: No buffer space available. Another way to specify the outgoing ARP packet rate is with the –interval option, which is an alternative way to modify the same underlying parameter.

The time taken to perform a single-pass scan (i.e. with –retry=1) is given by:

time = n*i + t + o

Where n is the number of hosts in the list, i is the time interval between packets (specified with –interval, or calculated from –bandwidth), t is the timeout value (specified with –timeout) and o is the overhead time taken to load the targets into the list and read the MAC/Vendor mapping files. For small lists of hosts, the timeout value will dominate, but for large lists the packet interval is the most important value.

With 65,536 hosts, the default bandwidth of 256,000 bits/second (which results in a packet interval of 2ms), the default timeout of 100ms, and a single pass ( –retry=1), and assuming an overhead of 1 second, the scan would take 65536*0.002 + 0.1 + 1 = 132.172 seconds, or about 2 minutes 12 seconds.

Any part of the outgoing ARP packet may be modified through the use of the various –arpXXX options. The use of some of these options may make the outgoing ARP packet non RFC compliant. Different operating systems handle the various non standard ARP packets in different ways, and this may be used to fingerprint these systems. See arp-fingerprint(1) for information about a script which uses these options to fingerprint the target operating system.

The table below summarises the options that change the outgoing ARP packet. In this table, the Field column gives the ARP packet field name from RFC 826, Bits specifies the number of bits in the field, Option shows the arp-scan option to modify this field, and Notes gives the default value and any other notes.

Outgoing ARP Packet Options

Field Bits Option Notes

ar$hrd 16 –arphrd Default is 1 (ARPHRD_ETHER)

ar$pro 16 –arppro Default is 0x0800

ar$hln 8 –arphln Default is 6 (ETH_ALEN)

ar$pln 8 –arppln Default is 4 (IPv4)

ar$op 16 –arpop Default is 1 (ARPOP_REQUEST)

ar$sha 48 –arpsha Default is interface h/w address

ar$spa 32 –arpspa Default is interface IP address

ar$tha 48 –arptha Default is zero (00:00:00:00:00:00)

ar$tpa 32 None Set to the target host IP address

The most commonly used outgoing ARP packet option is –arpspa, which sets the source IP address in the ARP packet. This option allows the outgoing ARP packet to use a different source IP address from the outgoing interface address. With this option it is possible to use arp-scan on an interface with no IP address configured, which can be useful if you want to ensure that the testing host does not interact with the network being tested.

It is also possible to change the values in the Ethernet frame header that proceeds the ARP packet in the outgoing packets. The table below summarises the options that change values in the Ethernet frame header.

Outgoing Ethernet Frame Options

Field Bits Option Notes

Dest Address 48 –destaddr Default is ff:ff:ff:ff:ff:ff

Source Address 48 –srcaddr Default is interface address

Protocol Type 16 –prototype Default is 0x0806

The most commonly used outgoing Ethernet frame option is –destaddr, which sets the destination Ethernet address for the ARP packet. –prototype is not often used, because it will cause the packet to be interpreted as a different Ethernet protocol.

Any ARP responses that are received are displayed in the following format:

<IP Address>

<Hardware Address>

<Vendor Details>

Where IP Address is the IP address of the responding target, Hardware Address is its Ethernet hardware address (also known as the MAC address) and Vendor Details are the vendor details, decoded from the hardware address. The output fields are separated by a single tab character.

The responses are displayed in the order that they are received, which is not always the same order as the requests were sent because some hosts may respond faster than others.

The vendor decoding uses the files ieee-oui.txt, ieee-iab.txt and mac-vendor.txt which are supplied with arp-scan. The ieee-oui.txt and ieee-iab.txt files are generated from the OUI and IAB data on the IEEE website at http://standards.ieee.org/regauth/oui/ieee-oui.txt and http://standards.ieee.org/regauth/oui/iab.txt. The Perl scripts get-oui and get-iab, which are included in the arp-scan package, can be used to update these files with the latest data from the IEEE website. The mac-vendor.txt file contains other MAC to Vendor mappings that are not covered by the IEEE OUI and IAB files.

Almost all hosts that support IP will respond to arp-scan if they receive an ARP packet with the target protocol address (ar$tpa) set to their IP address. This includes firewalls and other hosts with IP filtering that drop all IP traffic from the testing system. For this reason, arp-scan is a useful tool to quickly determine all the active IP hosts on a given Ethernet network segment.

Options

–help or -h

Display this usage message and exit.

–file=<fn> or -f <fn>

Read hostnames or addresses from the specified file instead of from the command line. One name or IP address per line. Use “-” for standard input.

–localnet or -l

Generate addresses from network interface configuration Use the network interface IP address and network mask to generate the list of target host addresses. The list will include the network and broadcast addresses, so an interface address of 10.0.0.1 with netmask 255.255.255.0 would generate 256 target hosts from 10.0.0.0 to 10.0.0.255 inclusive. If you use this option, you cannot specify the –file option or specify any target hosts on the command line. The interface specifications are taken from the interface that arp-scan will use, which can be changed with the –interface option.

–retry=<n> or -r <n>

Set total number of attempts per host to <n>, default=3.

–timeout=<n> or -t <n>

Set initial per host timeout to <n> ms, default=500. This timeout is for the first packet sent to each host. subsequent timeouts are multiplied by the backoff factor which is set with –backoff.

–interval=<n> or -i <n>

Set minimum packet interval to <n> ms. This controls the outgoing bandwidth usage by limiting the rate at which packets can be sent. The packet interval will be no smaller than this number. If you want to use up to a given bandwidth, then it is easier to use the –bandwidth option instead. The interval specified is in milliseconds by default, or in microseconds if “u” is appended to the value.

–bandwidth=<n> or -B <n>

Set desired outbound bandwidth to <n>, default=256000. The value is in bits per second by default. If you append “K” to the value, then the units are kilobits per sec; and if you append “M” to the value, the units are megabits per second. The “K” and “M” suffixes represent the decimal, not binary, multiples. So 64K is 64000, not 65536. You cannot specify both –interval and –bandwidth because they are just different ways to change the same parameter.

–backoff=<b> or -b <b>

Set timeout backoff factor to <b>, default=1.50. The per-host timeout is multiplied by this factor after each timeout. So, if the number of retrys is 3, the initial per-host timeout is 500ms and the backoff factor is 1.5, then the first timeout will be 500ms, the second 750ms and the third 1125ms.

–verbose or -v

Display verbose progress messages. Use more than once for greater effect: 1 – Show when hosts are removed from the list and other useful information; 2 – Show each packet sent and received; 3 – Display the host list before scanning starts.

–version or -V

Display program version and exit.

–random or -R

Randomise the host list. This option randomises the order of the hosts in the host list, so the ARP packets are sent to the hosts in a random order. It uses the Knuth shuffle algorithm.

–numeric or -N

IP addresses only, no hostnames. With this option, all hosts must be specified as IP addresses. Hostnames are not permitted.

–snap=<s> or -n <s>

Set the pcap snap length to <s>. Default=64. This specifies the frame capture length. This length includes the data-link header. The default is normally sufficient.

–interface=<i> or -I <i>

Use network interface <i>. If this option is not specified, arp-scan will search the system interface list for the lowest numbered, configured up interface (excluding loopback). The interface specified must support ARP.

–quiet or -q

Only display minimal output. If this option is specified, then only the minimum information is displayed. With this option, the OUI file is not used.

–ignoredups or -g

Don’t display duplicate packets. By default, duplicate packets are displayed and are flagged with “(DUP: n)”.

–ouifile=<o> or -O <o>

Use OUI file <o>, default=/usr/local/share/arp-scan/ieee-oui.txt This file provides the Ethernet OUI to vendor string mapping.

–iabfile=<i> or -F <i>

Use IAB file <i>, default=/usr/local/share/arp-scan/ieee-iab.txt This file provides the IEEE Ethernet IAB to vendor string mapping.

–macfile=<m> or -m <m>

Use MAC/Vendor file <m>, default=/usr/local/share/arp-scan/mac-vendor.txt This file provides the custom Ethernet MAC to vendor string mapping.

–srcaddr=<m> or -S <m>

Set the source Ethernet MAC address to <m>. This sets the 48-bit hardware address in the Ethernet frame header for outgoing ARP packets. It does not change the hardware address in the ARP packet, see –arpsha for details on how to change that address. The default is the Ethernet address of the outgoing interface.

–destaddr=<m> or -T <m>

Send the packets to Ethernet MAC address <m> This sets the 48-bit destination address in the Ethernet frame header. The default is the broadcast address ff:ff:ff:ff:ff:ff. Most operating systems will also respond if the ARP request is sent to their MAC address, or to a multicast address that they are listening on. The address can be specified either in the format 01:23:45:67:89:ab, or as 01-23-45-67-89-ab. The alphabetic hex characters may be upper or lower case.

–arpsha=<m> or -u <m>

Use <m> as the ARP source Ethernet address This sets the 48-bit ar$sha field in the ARP packet It does not change the hardware address in the frame header, see –srcaddr for details on how to change that address. The default is the Ethernet address of the outgoing interface.

–arptha=<m> or -w <m>

Use <m> as the ARP target Ethernet address This sets the 48-bit ar$tha field in the ARP packet The default is zero, because this field is not used for ARP request packets.

–prototype=<p> or -y <p>

Set the Ethernet protocol type to <p>, default=0x0806. This sets the 16-bit protocol type field in the Ethernet frame header. Setting this to a non-default value will result in the packet being ignored by the target, or send to the wrong protocol stack. This option is probably not useful, and is only present for completeness.

–arphrd=<o> or -H <o>

Use <o> for the ARP hardware type, default=1. This sets the 16-bit ar$hrd field in the ARP packet. The normal value is 1 (ARPHRD_ETHER). Most, but not all, operating systems will also respond to 6 (ARPHRD_IEEE802). A few systems respond to any value.

–arppro=<o> or -p <o>

Use <o> for the ARP protocol type, default=0x0800. This sets the 16-bit ar$pro field in the ARP packet. Most operating systems only respond to 0x0800 (IPv4) but some will respond to other values as well.

–arphln=<l> or -a <l>

Set the hardware address length to <l>, default=6. This sets the 8-bit ar$hln field in the ARP packet. It sets the claimed length of the hardware address in the ARP packet. Setting it to any value other than the default will make the packet non RFC compliant. Some operating systems may still respond to it though. Note that the actual lengths of the ar$sha and ar$tha fields in the ARP packet are not changed by this option; it only changes the ar$hln field.

–arppln=<l> or -P <l>

Set the protocol address length to <l>, default=4. This sets the 8-bit ar$pln field in the ARP packet. It sets the claimed length of the protocol address in the ARP packet. Setting it to any value other than the default will make the packet non RFC compliant. Some operating systems may still respond to it though. Note that the actual lengths of the ar$spa and ar$tpa fields in the ARP packet are not changed by this option; it only changes the ar$pln field.

–arpop=<o> or -o <o>

Use <o> for the ARP operation, default=1. This sets the 16-bit ar$op field in the ARP packet. Most operating systems will only respond to the value 1 (ARPOP_REQUEST). However, some systems will respond to other values as well.

–arpspa=<s> or -s <s>

Use <s> as the source IP address. The address should be specified in dotted quad format; or the string “dest”, which sets the source address to be the same as the target host address. This sets the 32-bit ar$spa field in the ARP packet. Some operating systems check this, and will only respond if the source address is within the network of the receiving interface. Others don’t care, and will respond to any source address. By default, the outgoing interface address is used.

–padding=<p> or -A <p>

Specify padding after packet data. Set the padding data to hex value <p>. This data is appended to the end of the ARP packet, after the data. Most, if not all, operating systems will ignore any Padding. The default is no padding, although the Ethernet driver on the sending system may pad the packet to the minimum Ethernet frame length.

–llc or -L

Use RFC 1042 LLC framing with SNAP. This option causes the outgoing ARP packets to use IEEE 802.2 framing with a SNAP header as described in RFC 1042. The default is to use Ethernet-II framing. arp-scan will decode and display received ARP packets in either Ethernet-II or IEEE 802.2 formats irrespective of this option.

–vlan=<v> or -Q <v>

Use 802.1Q tagging with VLAN id <v>. This option causes the outgoing ARP packets to use 802.1Q VLAN tagging with a VLAN ID of <v>, which should be in the range 0 to 4095 inclusive. arp-scan will always decode and display received ARP packets in 802.1Q format irrespective of this option.

–pcapsavefile=<p> or -W <p>

Write received packets to pcap savefile <p>. This option causes received ARP responses to be written to a pcap savefile with the specified name. This savefile can be analyzed with programs that understand the pcap file format, such as “tcpdump” and “wireshark”.

Files

/usr/local/share/arp-scan/ieee-oui.txt

List of IEEE OUI (Organizationally Unique Identifier) to vendor mappings.

/usr/local/share/arp-scan/ieee-iab.txt

List of IEEE IAB (Individual Address Block) to vendor mappings.

/usr/local/share/arp-scan/mac-vendor.txt

List of other Ethernet MAC to vendor mappings.

Examples

The example below shows arp-scan being used to scan the network 192.168.0.0/24 using the network interface eth0.

$ arp-scan --interface=eth0 192.168.0.0/24
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.4 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1     00:c0:9f:09:b8:db       QUANTA COMPUTER, INC.
192.168.0.3     00:02:b3:bb:66:98       Intel Corporation
192.168.0.5     00:02:a5:90:c3:e6       Compaq Computer Corporation
192.168.0.6     00:c0:9f:0b:91:d1       QUANTA COMPUTER, INC.
192.168.0.12    00:02:b3:46:0d:4c       Intel Corporation
192.168.0.13    00:02:a5:de:c2:17       Compaq Computer Corporation
192.168.0.87    00:0b:db:b2:fa:60       Dell ESG PCBA Test
192.168.0.90    00:02:b3:06:d7:9b       Intel Corporation
192.168.0.105   00:13:72:09:ad:76       Dell Inc.
192.168.0.153   00:10:db:26:4d:52       Juniper Networks, Inc.
192.168.0.191   00:01:e6:57:8b:68       Hewlett-Packard Company
192.168.0.251   00:04:27:6a:5d:a1       Cisco Systems, Inc.
192.168.0.196   00:30:c1:5e:58:7d       HEWLETT-PACKARD
13 packets received by filter, 0 packets dropped by kernel
Ending arp-scan: 256 hosts scanned in 3.386 seconds (75.61 hosts/sec).  13
responded

This next example shows arp-scan being used to scan the local network after configuring the network interface with DHCP using pump.

# pump
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:D0:B7:0B:DD:C7
          inet addr:10.0.84.178  Bcast:10.0.84.183  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:46335 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1542776 errors:0 dropped:0 overruns:0 carrier:0
          collisions:1644 txqueuelen:1000
          RX bytes:6184146 (5.8 MiB)  TX bytes:348887835 (332.7 MiB)
# arp-scan --localnet
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.4 with 8 hosts (http://www.nta-monitor.com/tools/arp-scan/)
10.0.84.179     00:02:b3:63:c7:57       Intel Corporation
10.0.84.177     00:d0:41:08:be:e8       AMIGO TECHNOLOGY CO., LTD.
10.0.84.180     00:02:b3:bd:82:9b       Intel Corporation
10.0.84.181     00:02:b3:1f:73:da       Intel Corporation
4 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.4: 8 hosts scanned in 0.820 seconds (9.76 hosts/sec).  4 responded

Linux / Unix Command: arp

NAME

arp – manipulate the system ARP cache

SYNOPSIS

arp [-evn] [-H type] [-i if] -a [hostname]

arp [-v] [-i if] -d hostname [pub]

arp [-v] [-H type] [-i if] -s hostname hw_addr [temp]

arp [-v] [-H type] [-i if] -s hostname hw_addr [netmask nm] pub

arp [-v] [-H type] [-i if] -Ds hostname ifa [netmask nm] pub

arp [-vnD] [-H type] [-i if] -f [filename]

DESCRIPTION

Arp manipulates the kernel’s ARP cache in various ways. The primary options are clearing an address mapping entry and manually setting up one. For debugging purposes, the arp program also allows a complete dump of the ARP cache.

OPTIONS

-v, –verbose

Tell the user what is going on by being verbose.

-n, –numeric

shows numerical addresses instead of trying to determine symbolic host, port or user names.

-H type, –hw-type type, -t type

When setting or reading the ARP cache, this optional parameter tells arp which class of entries it should check for. The default value of this parameter is ether (i.e. hardware code 0x01 for IEEE 802.3 10Mbps Ethernet). Other values might include network technologies such as ARCnet (arcnet) , PROnet (pronet) , AX.25 (ax25) and NET/ROM (netrom).

-a [hostname], –display [hostname]

Shows the entries of the specified hosts. If the hostname parameter is not used, all entries will be displayed. The entries will be displayed in alternate (BSD) style.

-d hostname, –delete hostname

Remove any entry for the specified host. This can be used if the indicated host is brought down, for example.

-D, –use-device

Use the interface ifa‘s hardware address.

-e

Shows the entries in default (Linux) style.

-i If, –device If

Select an interface. When dumping the ARP cache only entries matching the specified interface will be printed. When setting a permanent or temp ARP entry this interface will be associated with the entry; if this option is not used, the kernel will guess based on the routing table. For pub entries the specified interface is the interface on which ARP requests will be answered.
NOTE: This has to be different from the interface to which the IP datagrams will be routed.

-s hostname hw_addr, –set hostname

Manually create an ARP address mapping entry for host hostname with hardware address set to hw_addr class, but for most classes one can assume that the usual presentation can be used. For the Ethernet class, this is 6 bytes in hexadecimal, separated by colons. When adding proxy arp entries (that is those with the publish flag set a netmask may be specified to proxy arp for entire subnets. This is not good practice, but is supported by older kernels because it can be useful. If the temp flag is not supplied entries will be permanent stored into the ARP cache.
NOTE: As of kernel 2.2.0 it is no longer possible to set an ARP entry for an entire subnet. Linux instead does automagic proxy arp when a route exists and it is forwarding. See arp(7) for details.

-f filename, –file filename

Similar to the -s option, only this time the address info is taken from file filename set up. The name of the data file is very often /etc/ethers, but this is not official. If no filename is specified /etc/ethers is used as default.The format of the file is simple; it only contains ASCII text lines with a hostname, and a hardware address separated by whitespace. Additionally the pub, temp and netmask flags can be used.

In all places where a hostname is expected, one can also enter an IP address in dotted-decimal notation. As a special case for compatibility the order of the hostname and the hardware address can be exchanged.

Each complete entry in the ARP cache will be marked with the C flag. Permanent entries are marked with M and published entries have the P flag. 

UDP Makes a Difference ( UDP vs.TCP )

Everybody doing some sockets programming is quite familiar with TCP. Most do know UDP and think it’s an inferior protocol, as it does not ensure that the data bytes sent will arrive at the other site. Thus, UDP imposes less network overhead than TCP and gives the programmer more freedom and more labor by forcing him to deal with the security of the data transport himself.

Let’s first take a look at some TCP details. Before any data can be exchanged with TCP, a “socket” needs to be opened. By this a point-to-point connection is established that provides a bidirectional data path between the partners. While establishing a socket needs a client and a server site (the server offering potential sockets, the client using one of them), once the initialization done, the data transport is done identically in both directions and the two ways are completely independent. Delphi users sometimes are not aware of this, as Indy implements the receiving interface differently with IdTCPClient and IdTCPServer and thus, using Indy, having the client answer to a dialog initiated from the server site is a bit tricky (see article Screen Thief).

Regarding the data transport, we need to be aware, that TCP works on data streams, and not on data blocks. The secure TCP frame transport and the packet structure of the underlying IP protocol is completely hidden. The transport mechanism even will split and concatenate blocks on the fly, trying to create as big IP packets as possible, to reduce the overhead, and using one IP packet for each TCP frame to facilitate the correction of lost packets.

While with Indy you usually use functions like TIdTCPClient.Write or TIdTCPClient.WriteBuffer that send a “block” of data, you can’t be sure that the receiver will get this data in the same block structure. It can get it in more than one block or it can get a block that contains this data preceded or followed by other data. So the software needs to implement a scheme that finds the start of the logical data blocks that are to be handled. In most cases this is easy, as you can be sure that no byte is lost as long as the socket lives, and thus the structure of the data is intact and can be decoded without any afterthought. Anyway, for a socket connection that stays established for a long time, it’s a good idea to use some kind of unique signature to mark the start of each block. Of course, if the signature might be part of the data to be transferred, some tranparentizing scheme needs to be implemented.

UDP? UDP!

In contrast, UDP works on data blocks. A data block can be up to 64 K bytes. A UDP block is considered transferred, if all IP packets, it consists of, are received. If one of them is lost, the complete UDP block is discarded.

Using Indy, you need to set the buffer size of the UDP components according to the longest block you want to use. The default size is 8 K. But even if setting the buffer size to 64K, I was not able to transfer bigger blocks than 16K. I suppose this is a limitation of the Windows version I used.

Regarding the UDP standard definition, there is no such thing like a socket that defines a connection between two sites, but each block transport defines it’s own target. Thus the definition of client and server is different from how it is used with TCP. A UDP server just provides a port where any device on the net can send UDP data blocks to. There are UDP senders and UDP receivers. Indy obfuscates this by defining TIdUDPClient and TIdUDPServer components that both can write UDP blocks, while supposedly only TIdUDPServer can provide a port, network devices can write to. Moreover TIdUDPClient has Host and Port properties that define the target, but nothing prevents them from being changed for each packet before sending it. I was not able to use TidUDPServer to send a data block to a dedicated address, while the Broadcast property is set. So TIdUDPClient and TIdUDPServer components are active in the example program and the “server” is used only for reading while the “client” is only used for writing.

A consequence of the UDP transport algorithm is, that you can do UDP broadcasts: messages that go to all UDP receivers on the network that opened a port to receive them. (Beware that most routers block broadcasts, and thus their reach is limited to an appropriate network segment.)

Regarding the data structure, UDP preserves the data block limits during the transport. That is why TIdUDPServer provides an event that allows dedicated access to each block received. Each block can come from a different network device, so the event provides the “Binding” that holds the correct specification of the sender of this data block (even if more blocks already arrived before the user program was able to start handling this event)

Example Chat program (with source) shows how UDP can be used to find partners with unknown IP addresses.

Wake-On-Lan (WOL) is not working when machine is in hibernate or in standby mode.

Problem

Wake-On-Lan (WOL) seems to be not working when a machine is hibernated, in standby or in sleep mode. Customer noticed that their computers fail to startup when Wake-On-LAN task is run after computers go into hibernation. However, Wake-On-LAN works when the computers are shutdown completely.

Environment

Notification Server 6.0.6074 SP3
Windows XP

Cause

In order for WOL to work when computer goes on Standby & Hibernation mode, NIC card Power Management configuration is required. By Default Windows turn this feature off to save power.
See Microsoft KB article “How to disable power management for a network adapter when you deploy Windows XP” (http://support.microsoft.com/kb/837058)

Solution

You will need to allow the computer to turn on rather than turn off this device to save power.
Use the information provided on Microsoft KB article “How to disable power management for a network adapter when you deploy Windows XP” (http://support.microsoft.com/kb/837058)Basically to use Registry Editor to disable the “Allow the computer to turn off this device to save power” network adapter setting for a single computer, follow these steps:1. Click Start, click Run, type regedit in the Open box, and then click OK.
2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\DeviceNumber

Note: DeviceNumber is the network adapter number. If a single network adapter is installed on the computer, the DeviceNumber is 0001.

3. Click PnPCapabilities.
4. On the Edit menu, click Modify.
5. In the Value data box, type 38, and then click OK.

Note By default, a value of 20 indicates that power management of the network adapter is enabled. A value of 38 will prevent Windows XP from turning off the network adapter or let the network adapter wake the computer from standby.

6. On the File menu, click Exit.

Access Your Computer Anytime and Save Energy with Wake-on-LAN

You want access to your home computer wherever you are, whatever you’re doing, whether that’s via a remote desktop connection, SSH, FTP, web interface, or any other remote access you’ve set up. The catch is, you don’t like throwing money away to an always-on system. Luckily you can have your digital cake and eat it, too, and today I’ll show you how to boot and shut down your system remotely so that it’s ready for you when you need it and it’s not wasting energy when you don’t.

The cornerstone of this setup is a feature available to almost all newer computers known as Wake-on-LAN (or WOL), which—as the name suggests—turns on your PC through your local network. Wake-on-LAN is a breeze to set up and use on your local network, and with a little legwork you can set it up so you can wake your computer away from your home network, as well.

First I’ll show you how to enable Wake-on-LAN on your computer, starting with enabling the feature in the BIOS and finishing by choosing the correct system settings. Then I’ll show you several methods you can use to wake your computer using this feature, from waking your computer through your browser to different applications made specifically for this purpose.

NOTE: Wake-on-LAN only works with wired network connections.

Set Up Wake-on-LAN in Your BIOS and Operating System

The Wake-on-LAN feature can work in a couple of ways. First, it can boot your system from a completely shutdown state. Second, Wake-on-LAN can restore your system from a hibernated (Windows) or sleeping state (Mac). If you’re working in Windows, you may need to tweak your BIOS (the firmware your computer’s motherboard runs before it boots your operating system) before you start using Wake-on-LAN. Once your BIOS is set, you need to find and adjust a few system settings to allow you to wake up your computer using the Wake-on-LAN feature.

Enable Wake-on-LAN in Your BIOS

To access your BIOS, restart your computer and press and hold the Delete key (or whatever key your BIOS prompts you to hold) to enter the BIOS setup. Once you’re in the BIOS, head to the Power management section and look for a Wake-on-LAN setting. If you find one, go ahead and make sure it’s enabled, then save and exit your BIOS and start up your computer. Not all BIOS will have a straight-up Wake-on-LAN option, and on some boards you may have to enable a “Power On By PCI Devices” setting. It varies from board to board, so a little trial and error may be in order.

Now you’re ready to enable WOL in your operating system.

Continue………………………….

 

 

continue……part3 "Access Your Computer Anytime and Save Energy with Wake-on-LAN"

Wake Your Computer from Anywhere with Your Web Browser

The easiest way to issue a Wake-on-LAN command from outside your local network is through your web browser, and the absolutely simplest way to do that is through your router.

If you’ve followed either of our methods for turning your cheap-o $60 router into a super-charged $600 router with either Tomato, DD-WRT, or even HyperWRT (which we haven’t covered), then you’ve got all the tools you need to turn on your computer from anywhere with an internet connection. Since I’m currently running Tomato, I’ll show you how to work it there, but if your router supports Wake-on-LAN, it shouldn’t vary much.

First point your browser to the Tomato admin interface and give it your username and password to get started. If you’re working outside of your local network, you’ll need to either know your external IP address or have set up a free domain with DynDNS. Once you’re in, click Tools -> WOL in the sidebar. All of your available devices are listed, and all you have to do to issue a Wake-on-LAN command is click on it. Simple, right?

If you don’t have a router that can handle WOL, you can still wake your computer from your browser using services like Wake On Lan from DSL Reports. In order to issue the Wake-on-LAN command from outside your network through a service like this, you’ll first need to set up port forwarding for UDP port 9 to the computer you want to wake up on your local network (here’s how that works).

Now you just need to know your external IP address or have assigned a domain name to your home computer, and the MAC address of the computer you want to wake. To find a computer’s MAC address in Windows, type ipconfig/all at the command prompt and find the series of 12 letters and numbers next to Physical Address. On a Mac, run the Network Utility application and write down the address next to Hardware Address. Give the webapp your IP address and the MAC address of the PC you want to wake up and voilà—the Wake-on-LAN command should be issued and your computer should start up or wake up straight away.

Wake Your Computer with Freeware

If you don’t have a router supported by the Tomato or DD-WRT firmware, there are still other simple tools made to send wake-up commands to your computer. For Windows, one good looking option is called Magic Packet Sender. It can save your WOL profiles so sending that command is quick and simple.

Mac users should check out WakeOnLan, which offers both a regular app and a Dashboard widget. It scans your local network and grabs all of the local devices so it’s easy to find one and wake it up.

What To Do Now that Your Computer is On

We’ve covered tons of remote access possibilities here at Lifehacker, and here are a few of my favorites that you may want to use now that you’ve started up your computer:

• Remote Control Your Computer with VNC
• Access or Upload Files with your Home FTP Server
• Access Your Home Web Server
• SSH into Your Home Computer
• Remote Control Your BitTorrent Downloads with uTorrent or Transmission

Remotely Shut Down Your Computer

When you’re finished accessing your home computer, you still may want to shut it down to save energy when you’re finished with it. Fact is, now that you’ve got remote access, there are lots of different ways you can go about shutting down your computer remotely. If you’re connected via SSH, you can shut down your computer from the command line. Likewise, you can easily shut down your computer graphically from a remote desktop or VNC connection the same way you would shut it down locally. If you feel like getting a bit more creative, here’s how to shut down Windows with a text message.

continue…"Access Your Computer Anytime and Save Energy with Wake-on-LAN"

Enable Wake-on-LAN in Windows

To enable Wake-on-LAN in Windows, right-click My Computer (or Computer in Vista), select Properties, then click on Device Manager (in XP that’s in the Hardware tab). Find your network card in the hardware list, right-click it and click Properties again. First go to the Power Management tab and tick the checkbox next to Allow this device to wake the computer.

Now head to the Advanced tab, which is full of options for your network adapter. We’re concerned with two options here. The first is the Wake From Shutdown entry near the end of the list. Scroll down to it and change the value to On. The next setting I tweaked was Wake-Up Capabilities (right below Wake From Shutdown), setting the value to Magic Packet. Hit OK and everything should be set. You’re ready to use the Wake-on-LAN feature using one of the methods described below.

I also had to update the drivers for my network adapter through the Device Manager for it to work, so for good measure you might want to do the same (right-click your network card and select Update drivers and let it download the latest from the internet).

Enable Wake-on-LAN in OS X

To enable Wake-on-LAN for you Mac, open the Energy Saver Preference pane, click Options, and then tick the Wake for Ethernet network administrator access checkbox. That’s all there is to it.

Methods and Applications for Waking Your Computer with WOL

Now that you’ve enabled Wake-on-LAN in both your BIOS (if necessary) and your operating system, how do we go about actually waking up your computer? There are actually a number of methods for doing so, from issuing the wake command using your router to apps made specifically for this process. I’ll highlight a few of these methods below.