ARP(Address resolution protocol) structure mis-aligned

Question

5.00/5 (1 vote)

See more:

I have a structure to represent the ARP (address resolution protocol) but the bytes in memory are misaligned, its a 64 bit capable processor running 32 bit OS.

The structure is 28 byte and is as follows:

ARP structure:

C#

unsigned short hardware;     //could use USHORT but like it this way
unsigned short protocol;
unsigned char Haddr;
unsigned char prot_addr;
unsigned short operation;
unsigned char Sender_MAC[6];
unsigned long int src_addr;
unsigned char Receiver_MAC[6];
unsigned long int dst_addr;

Althought it's 28 bytes (divisible by 4) structure , the compiler adds extra 4 byte padding(is it because of 64 bit capable processor?).
If that is the reason then why isn't the structure I use for Ethernet which is 14 bytes have any padding?

Ethernet structure:

C#

unsigned char srcmac[6];
unsigned char dstmac[6];
unsigned short ip;

In the ARP structure the bytes in memory are fine until Sender_MAC then they all go mental.
Any help would be greatly appreciated.

PS I can provide the wireshark sniff to see all the jumbled data, in case.

Posted 30-Nov-13 5:04am

Morbiddeath

Updated 30-Nov-13 5:08am

v3

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Accepted Answer · 2013-11-30T05:30:00

Solution 1

Data alignment is the simple answer.

A char is a single byte, so it can be aligned on an odd or an even byte boundary - the address of the character can be odd or even.
Generally speaking any datatype which is not byte long needs to be aligned on an even address (or longer depending on the compiler and options).
So when your structure contains:

C#

unsigned short operation;
unsigned char Sender_MAC[6];
unsigned long int src_addr;
unsigned char Receiver_MAC[6];
unsigned long int dst_addr;

then at the very least extra bytes will be added to "pad" the addressing out to a suitable address for the long values - probably a 4 byte address, which will require 2 extra bytes for each (since the earlier data does not "end" in the right place.

If you need to exactly match an external structure, then use the pack[^] pragma to override the default behaviour.

Posted 30-Nov-13 5:30am

OriginalGriff

Comments

Morbiddeath 30-Nov-13 12:28pm

Thanks A LOT OriginalGriff, excellent answer. However I still have one doubt - the structure of ARP starts with an unsigned short so that means the structure starts with even memory address and all the structure data fall into even addresses too(if I'm not mistaken) then why is there a need to pad to a suitable address? (like how the Ethernet structure is).

OriginalGriff 30-Nov-13 12:41pm

Because a long is not two bytes long: it's 4 or 8 depending, so it needs padding to it's natural address alignment.
It makes more sense if you draw it out on squared paper! :laugh:

Morbiddeath 30-Nov-13 12:47pm

I think I got it. All the bytes in the structure need to be structured in 4 byte patterns (on 32 bit) so that is why after Sender_MAC[6] we have 2 byte padding and another 2 byte for Receiver_MAC[6], and possibly more for 64 bit, is that correct?

OriginalGriff 30-Nov-13 13:08pm

Pretty much. The shorts don't - they are only 2 bytes long- but the structure up to the first char array ends on a 8 byte address, so the char [6] needs 2 padding bytes for the following long value.

Morbiddeath 30-Nov-13 13:21pm

Thanks man, I can have a good night sleep finally. ;-P