[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>; 
<ntar-workers at winpcap.org>
Sent: Tuesday, October 09, 2007 12:43 PM
Subject: Re: Bug in http.cap.ntar file?!?


> Hi List!
>
> This was a ntar related discussion between me and Gianluca about ntar 
> development and inclusion into Wireshark. I'll CC this to the ntar-workers 
> list from now to find a point to sync this discussion into this list. I 
> guess you won't understand much right now, but this hopefully will clarify 
> the next days as I expect more Mails ...
>
> I'm currently implementing an ntar / pcapng implementation for inclusion 
> into Wireshark ...
>
>
> Gianluca send me an example ntar capture file and there's discussion about 
> it, so let the mails flow now .............
>
>
> Gianluca Varenni schrieb:
>> I just checked the NTAR implementation of this. And the value does not 
>> get aligned.
> Which I guess is the bug.
>> The specification doesn't actually say the Block Total Length field 
>> should be 32bit aligned.
> Ack
>> Section 2.1 (General Block Structure) says that the Block Body should be 
>> 32bit aligned (Figure 1). But it doesn't say anything about the Block 
>> Total Length. I can be wrong, but the Block Total Length should not 
>> actually account for the padding bytes at all. Without that, there is no 
>> way to understand if the Block Body contains an alignment or not (the 
>> only way would be to decode the Block Body itself).
>>
>> Does it make sense to you?
> Unsure ;-) There is no ambitious thing I can see here! Section "2.1. 
> General Block Structure" states that a block starts with "Block Type" and 
> ends with the *second* "Block Type Length" - after that block. So this 
> means that the "Block Body" is always 32 bit aligned regardless of the 
> block content and therefore the "Block Total Length" *must be* a multiple 
> of 4.
>
> Or do we speak about the same thing? ;-)

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.

Ciao
GV

>>
>> Having said that, the trace I sent you is wrong in any case, as the 
>> packet block itself includes the padding. I think I found the bug in the 
>> ntar code and fixed it. Attached you can find a new version of the trace 
>> file.
> I'll have a look tomorrow ...
>>
>> PS: I finally have someone finding the bugs in the ntar library by using 
>> a different pcapng implementation :-)
> I thought about the same - so implementing it a second time is at least 
> not a waste of it ;-)))
>
> Regards, ULFL