[ntar-workers] Re: Bug in http.cap.ntar file?!?

[Gianluca Varenni]

----- Original Message ----- 
From: "Ulf Lamping" <ulf.lamping at web.de>
To: "Gianluca Varenni" <gianluca.varenni at cacetech.com>
Cc: <ntar-workers at winpcap.org>
Sent: Tuesday, October 09, 2007 1:37 PM
Subject: Re: Bug in http.cap.ntar file?!?


> Gianluca Varenni schrieb:
>> The block body is always 32 bit aligned (i.e. if it's not aligned, 
>> alignment bytes are to be added), *but* the block total length (both the 
>> instances of the field, at the beginning and at the end of the block 
>> itself) indicate the effective block length. This is how I interpreted 
>> the spec when I implemented ntar (since this is how other "length" fields 
>> work in other places of the spec when padding is required). Maybe I was 
>> wrong. I just tried to be consistent.
>>
> ?!?
>
> To mention the spec: "Block Total Length: total size of this block, in 
> bytes. For instance, the length of a block that does not have body is 12 
> bytes."
>
> This implies that a block starts with BTL and ends after another BTL - 
> regardless what's between these two.
>
> So if the block header / footer is 12 byte and the block body can only be 
> a multiple of 4 - does it make *any sense* that the BTL will not be a 
> multiple of 4 ?!?
>

It doesn't make a lot of sense *because* the BTL includes the 
headers/footers, and the padding is somewhere in between them.

I really don't know. I'm just trying to point out that the document is not 
consistent/too specific at all as far as alignments are concerned. For 
example, the simple packet block doesn't have any requirement on the 
alignment. If you use that block, and you write a 65bytes packet, the block 
body is 65 + 4(packet len field) = 69 bytes. There will be 3 bytes of 
alignment. Who "owns" those alignment bytes? I know this sounds extremely 
silly.
My point is just that if you read up to the end of paragraph 2.1, you (or 
better I) have this doubt: should the packet body be aligned to 32bits by 
adding some padding bytes at the end (independently from the specific), or 
instead each block should define its own alignment requirements (and for 
example the packet block puts the padding bytes between the packet data and 
the options)?

Have a nice day
GV


> Regards, ULFL
>