Re: IHL vs shift 6 vs accurate location in upper layers

Thanks very very much
I am getting it now. Kept reading what you stated -- this was a lie in
fact and the truth follows
I was stuck on multiplying by 4.....8 bits in a byte I should still be
dividing to get bytes not multiplying
then ad nauseum I think I hit what you explicitly put :) units of 32 bits ...
32/1*1/8=4 everyone of these words is 4 bytes so whatever number of
words I have I multiply by 4, like you said
then 2^2 left shift.... like you said right 2 -> shift 6 :)
thanks much again!



thanks MUCH again

On Mon, May 21, 2018 at 6:22 PM, Andy Furniss <[email protected]> wrote:
> jsl6uy js16uy wrote:
>>
>> Hello all hope all is well
>>
>> I looked around and have tried to get this sorted on multiple
>> occasions, but just can't get it
>> how does dividing by 64/2^6, ~ shift 6, ultimately get you to
>> something like the proper location for a src port in layer 4?
>> I get, after reading again and again and looking at ip packet header
>> diagrams, offset at 0 and the mask used to extract the IHL from the
>> 16bit word.
>> But then comes 'ol shift 6 ... right-shifting by 6 eliminates the
>> offset of the field and at the same time converts the value into byte
>> unit ....and I am lost again
>> IHL # 32 bit words I guess dividing by 64 bits will get you bytes
>> multiples 8 and then I have nothing
>>
>> googling around verified binary math and this is dividing by 64, but
>> that's where it ends, anything else is people just using it. I figure
>> I must be missing the deal.
>> Would like to understand it to fully use
>
>
> If you read the first 16 bits and mask to leave just IHL then you get
> (assuming normal IHL = 5)
>
> 0000 0101 0000 0000 this is not 5 (101 in binary) to get 5 you would
> need to right shift by 8 = 0000 0000 0000 0101.
>
> Your examples want IHL in bytes (octets) and since IHL is in units of
> 32 bits you need to multiply by 4 to get bytes.
>
> left shift by 2 is x4 so instead of right shift 8, right shift 6 gives
> the IHL x4 = bytes
>
> 0000 0000 0001 0100 = 20.
>
> Either way you know the header length and for tcp or udp the next 16
> bits will be the source port.