On Fri, Mar 08, 2002 at 05:23:39PM +0100, andreas.sikkema@xxxxxxxxxxx wrote:
> I don't know packet-arp well enough, but I changed in
> all calls to col_add_fstr() which add the string
> "(%s is at %s)" (or variations there of) from sha_str
> and spa_str to tha_str and tpa_str.
No, that's not the right answer.
To quote RFC 826 "An Ethernet Address Resolution Protocol":
Packet Reception:
-----------------
When an address resolution packet is received, the receiving
Ethernet module gives the packet to the Address Resolution module
which goes through an algorithm similar to the following.
Negative conditionals indicate an end of processing and a
discarding of the packet.
?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
[optionally check the hardware length ar$hln]
?Do I speak the protocol in ar$pro?
Yes:
[optionally check the protocol length ar$pln]
Merge_flag := false
If the pair <protocol type, sender protocol address> is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
?Am I the target protocol address?
Yes:
If Merge_flag is false, add the triplet <protocol type,
sender protocol address, sender hardware address> to
the translation table.
?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
Yes:
Swap hardware and protocol fields, putting the local
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hardware and protocol addresses in the sender fields.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Set the ar$op field to ares_op$REPLY
Send the packet to the (new) target hardware address on
the same hardware on which the request was received.
and
The target protocol address is necessary in the request form of
the packet so that a machine can determine whether or not to
enter the sender information in a table or to send a reply. It
is not necessarily needed in the reply form if one assumes a
reply is only provoked by a request. It is included for
completeness, network monitoring, and to simplify the suggested
processing algorithm described above (which does not look at the
opcode until AFTER putting the sender information in a table).
The target hardware address is included for completeness and
network monitoring. It has no meaning in the request form, since
it is this number that the machine is requesting. Its meaning in
the reply form is the address of the machine making the request.
In some implementations (which do not get to look at the 14.byte
ethernet header, for example) this may save some register
shuffling or stack space by sending this field to the hardware
driver as the hardware destination address of the packet.
So on an ARP reply, the "XXX is at YYY" information comes from the
sender fields, not the hardware fields, at least for replies coming from
the machine in question.
For reverse ARP, RFC 903 says:
The ar$sha, ar$spa, $ar$tha, and ar$tpa fields of the RARP packet are
interpreted as follows:
When the opcode is 3 ('request reverse'):
ar$sha is the hardware address of the sender of the packet.
ar$spa is undefined.
ar$tha is the 'target' hardware address.
In the case where the sender wishes to determine his own
protocol address, this, like ar$sha, will be the hardware
address of the sender.
ar$tpa is undefined.
When the opcode is 4 ('reply reverse'):
ar$sha is the hardware address of the responder (the sender of the
reply packet).
ar$spa is the protocol address of the responder (see the note
below).
ar$tha is the hardware address of the target, and should be the
same as that which was given in the request.
ar$tpa is the protocol address of the target, that is, the desired
address.
So for reverse ARP, using the target addresses in the "XXX is at YYY" is
correct - but not for forward ARP.
