NO.

ARP packet length (excluded the MAC frame header and footer) is exactly 28 bytes long. Not a single bit more. That's what the standard say.

http://tools.ietf.org/rfc/rfc826.txt

 Packet format:
--------------

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.


If you need to work with MAC addresses longer than 48 bits (6 bytes), then the address is stored into the MAC header / trailer. The ARP itself is not containing that address.

Actually you're right, my bad.

Never look at RFCs after one beer and one glass of wine.

On the other hand; it might be needed also to change other bits here and there, like the ar$hln one.

T.

Hi Mike,

it seems that the change you need is slightly more complex, as we need to change also the Serialize and Deserialize functions accordingly. Moreover there is an "hardcoded" list of MAC address types there (basically only Ethernet), as is:
  /* ethernet */
  i.WriteHtonU16 (0x0001);

Can you provide us some more insights about the MAC address you need to handle? Moreover, I'm perfectly fine supporting more MAC address types, but it's hard to support what's not in the code.

T.

Hi Tommaso,

I'd fleshed out the Mac64Address class a bit for the 802.15.4 stuff I'm playing around with.  It fell over when I got as far as ARP, because the actual packet length was longer than GetSerializedSize() was returning.  Making the change I attached made everything work OK.

So it looks like the big question is why the rest of ARP at least seemed to be working for me.

I think the hardware addresses and lengths were getting written and read correctly because they go through the Address object.  The fact that the code was falling over shows that I must have been writing more than 48 bits!

It looks to me that the only problem is the hard coded hardware address type field, where it's far from clear what we should be sending.  Perhaps "IEEE 802 Networks"?

As we ignore this field on reception, you could say it's not really a problem unless we start supporting hardware addresses that don't inherit from Address, and if that was the case we'd have much bigger problems to sort...

I posted this bug because "it was clearly wrong" and thought it might be simpler than trying to get all my 64 bit changes in which are untestable with the current mainline software.

Mike.

15.4, right. I had to imagine this.

we'll fix it as soon as we can, however it does require a slightly more complex change. Nothing dramatic.

T.

Ok, triple checked.

Seems that there is not a different ar$hrd for 802.15.4. Really strange tho.

After all you was right.

+1

fixed in changeset: 156662c93da6