[Guy Harris <gharris@xxxxxxxxxxxx>]

On Tue, Oct 10, 2000 at 08:13:32AM -0400, Shawn Starr wrote:
> Line: 0020: on the decoding of arps shows incorrect information
> Target hardware address: 00:00:00:00:00
> 
> is always 12 0's?
> 
> Isn't this supposed to be the destination of the MAC address of machine
> its trying to reach?

No, because an ARP request is trying to *FIND* the MAC address of a
machine with a given IP (or other protocol) address, so the MAC address
of the machine it's trying to reach can't be put into the packet (unless
it puts the address it got when it last tried ARPing for that IP
address, said address presumably having timed out).

To quote RFC 826, " An Ethernet Address Resolution Protocol" (with some
paragraph breaks inserted; perhaps Dave Plummer's <Return> or <Enter>
key wasn't working...) - note the stuff I've emphasized by underlining
it with "^^^":

	To communicate mappings from <protocol, address> pairs to 48.bit
	Ethernet addresses, a packet format that embodies the Address
	Resolution protocol is needed.  The format of the packet follows.

	    Ethernet transmission layer (not necessarily accessible to
		 the user):
		48.bit: Ethernet address of destination
		48.bit: Ethernet address of sender
		16.bit: Protocol type = ether_type$ADDRESS_RESOLUTION
	    Ethernet packet data:
		16.bit: (ar$hrd) Hardware address space (e.g., Ethernet,
				 Packet Radio Net.)
		16.bit: (ar$pro) Protocol address space.  For Ethernet
				 hardware, this is from the set of type
				 fields ether_typ$<protocol>.
		 8.bit: (ar$hln) byte length of each hardware address
		 8.bit: (ar$pln) byte length of each protocol address
		16.bit: (ar$op)  opcode (ares_op$REQUEST | ares_op$REPLY)
		nbytes: (ar$sha) Hardware address of sender of this
				 packet, n from the ar$hln field.
		mbytes: (ar$spa) Protocol address of sender of this
				 packet, m from the ar$pln field.
		nbytes: (ar$tha) Hardware address of target of this
				 packet (if known).
					 ^^^^^^^^
		mbytes: (ar$tpa) Protocol address of target.


			...



	As a packet is sent down through the network layers, routing
	determines the protocol address of the next hop for the packet
	and on which piece of hardware it expects to find the station
	with the immediate target protocol address.  In the case of the
	10Mbit Ethernet, address resolution is needed and some lower
	layer (probably the hardware driver) must consult the Address
	Resolution module (perhaps implemented in the Ethernet support
	module) to convert the <protocol type, target protocol address>
	pair to a 48.bit Ethernet address.

	The Address Resolution module tries to find this pair in a
	table.  If it finds the pair, it gives the corresponding 48.bit
	Ethernet address back to the caller (hardware driver) which then
	transmits the packet.  If it does not, it probably informs the
	caller that it is throwing the packet away (on the assumption
	the packet will be retransmitted by a higher network layer), and
	generates an Ethernet packet with a type field of
	ether_type$ADDRESS_RESOLUTION.

	The Address Resolution module then sets the ar$hrd field to
	ares_hrd$Ethernet, ar$pro to the protocol type that is being
	resolved, ar$hln to 6 (the number of bytes in a 48.bit Ethernet
	address), ar$pln to the length of an address in that protocol,
	ar$op to ares_op$REQUEST, ar$sha with the 48.bit ethernet
	address of itself, ar$spa with the protocol address of itself,
	and ar$tpa with the protocol address of the machine that is
	trying to be accessed.  It does not set ar$tha to anything in
				^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	particular, because it is this value that it is trying to
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	determine.
	^^^^^^^^^

> I have attach 2 PNG images comparing this with another scanner and they
> look very different on the decoding.

That's because they're different packets.

The "Windows scanner" (NetXRay or Sniffer, right?) is dissecting a
packet from 08:00:3e:1a:a4:bc, with the IP address 24.19.144.1, asking
for the Ethernet address of 24.19.144.229.

Ethereal is dissecting a packet from 08:00:3e:17:1c:d6, with the IP
address 24.68.101.1, asking for the Ethernet address of 24.68.101.161.

It appears that whatever software the machine at
24.19.144.1/08:00:3e:1a:a4:bc is running put 18:13:90:01:00:00 into the
target hardware address field - that's what NetXRay/Sniffer/whatever
shows in its hex dump windows, which means that's what was in the packet
as seen by the machine running NetXRay/Sniffer/whatever.  (It also
appears either that NetXRay/Sniffer/whatever is confused, or the bytes
highlighted in gray aren't the bytes of the field selected in the
protocol tree window, as it's highlighting 10 bytes, but a MAC address
has only 6 bytes.)

It appears that whatever software the machine at
24.68.101.1/08:00:3e:17:1c:d6 is running put zeroes into the target
hardware address field - that's what Ethereal shows in its hex dump
window, which means that's what was in the packet as seen by the machine
running Ethereal.