;process an incoming ARP request packet
if packet[enetpacketType0] == $08 &&
packet[enetpacketType1] == $06 then
if packet[arp_hwtype+1] == $01 &&_
packet[arp_prtype] == $08 &&_
packet[arp_prtype+1] == $00 &&_
packet[arp_hwlen] == $06 &&_
packet[arp_prlen] == $04 &&_
packet[arp_tipaddr] == ipaddrc &&_
packet[arp_tipaddr+1] == ipaddrc &&_
packet[arp_tipaddr+2] == ipaddrc &&_
packet[arp_tipaddr+3] == ipaddrc then
select case packet[arp_op+1]
for i8 = 0 to 5
remotemacaddrc[i8] = packet[arp_shaddr+i8]
The ARP Ethernet packet type of $0806 tugs on our
fishing line as the bait is being taken. An incoming IP
packet would have $0800 in the Ethernet packet type field.
The hwtype or hardware address type field’s $01 denotes
a 10 MB Ethernet. Recall that ARP does indeed use IP
components. So, the protocol type field is filled with
$0800, which denotes the IP protocol.
A MAC address is made up of six bytes. This is
conveyed in the arp_hwlen field with a value of $06. The
arp_prlen array entry tells us that the IP address consists of
four octets. Octet is Internet document speak for byte. It is
possible to only filter on the Ethernet packet type and the
IP address to determine that we have hooked an incoming
ARP message. However, to be safe, I decided to verify
every field I thought that I should to make sure the
incoming message was indeed an ARP and that the
captured ARP message was directed to the hardware
running this ported PICBASIC PRO firmware.
The arp_op array entry is the operation that is
being requested. A $01 in the operation field
represents an incoming ARP request that we must
reply to. If our Ethernet MINI generated an ARP
request, we would look for the operation field to
contain $02 and the returned ARP message to
contain the MAC address of the replying host.
You can immediately see what happens when
an incoming ARP message contains the in-question
MAC address. We simply stuff the contents of the
arp_shaddr (sourcehardwareaddress) array fields
into the remotemacaddrc array fields for later use. If
you’re wondering about the “c” in remotemacaddrc, that’s
a holdover from the port from C. I use “c” to denote byte
variables and “i” to identify integer variables when there are
a bunch of them all mixed up under my care.
We really need to respond to an incoming ARP
request before we can do anything useful with the
Ethernet MINI. So, branch to the arp_reply subroutine in
the Ethernet MINI driver PICBASIC PRO source code.
The arp_reply subroutine is simply building an ARP
reply packet in the PIC18F67J60’s internal transmit buffer
memory. Recall that we have already hacked out transmit
and receive buffer areas within the PIC18F67J60’s 8K of
packet buffer SRAM.
Once the transmit buffer write pointers
(EWRPTH/EWRPTL) are initialized and the mandatory
control byte is placed into the PIC18F67J60’s transmit
buffer, we use the source MAC address we gleaned from
the incoming ARP message to use as a return hardware
address. The addition of our MAC address as the sender
(source) in the initial address fields (DLC Header) of the
packet will not fulfill our reply obligation. The MAC address
the requesting host is looking for is contained within the
body of the ARP message. The best way to illustrate
the inner workings of the PICBASIC PRO ARP code is with
Figure 1 is a screen capture taken from a Network
General Sniffer Portable Ethernet sniff session. The sniff
session participants are a laptop and an Ethernet MINI.
Note the PC’s MAC address (Source = Station
001B3807CFC7) is contained within the DLC Header area
and the body of the ARP packet. The reason for this is that
networks aren’t always simple, router-less two-node dances.
The Internet is built around routers and routers need
addresses to be able to forward packets around the
Internet. Thus, the DLC Header addresses are used by
the routers (and host nodes for that matter) for addressing
information as a router isn’t programmed to dig deep into
packets to retrieve address information.
We’ve already talked about most everything contained
■ FIGURE 1. The Network General Sniffer products
are top notch. I rely on the Network General Sniffer
when developing embedded Ethernet firmware as I
can easily verify my checksum code and see all of
the fields of an Ethernet packet I am interested in. This
is also a great way to show Nuts& Volts readers the
innards of Ethernet packets.
September 2007 89