[ntar-workers] PacketBlock, PacketsBlock, GoPBlock

[Gianluca Varenni]

----- Original Message ----- 
From: "Alexander Dupuy" <alex.dupuy at counterstorm.com>
To: <ntar-workers at winpcap.org>
Sent: Wednesday, July 06, 2005 6:10 AM
Subject: Re: [ntar-workers] PacketBlock, PacketsBlock, GoPBlock


>>> - I'd make mandatory at least one GoPBlock type, "old-pcap", that would 
>>> correspond to the old 4-word pcap header format (ts_sec, ts_usec, len, 
>>> caplen), followed by the captured data. This will allow fast conversion 
>>> of
>>> old pcap traces to the new format.
>
> Gianluca Varenni replies:
>> Uhm, why adding such backwards compatibility? I don't see a big issue in
>> converting the old pcap format in the new one, converting every single
>> old-pcap header in the pcap-ng blocks (it can be done offline). Instead,
>> having another type of packet block adds unneeded complexity to either to
>> ntar, or to the app sitting on top of it.
>
> One reason to support an old-pcap format compatibility mode might be to 
> support cases where new and old-style captures are accidentally 
> concatenated.  I'm not saying that it should be done, just that such 
> mismatched concatenation will happen, and if it doesn't make things 
> intolerably complicated, it could be useful.

I know that it will probably happen, but I think that (at least for the 
moment) we should "ignore" the problem. I think that adding the support in 
NTAR for detecting/reading mixed mode trace files (i.e. pcap-ng sections 
mixed with old-pcap traces) adds unneeded complexity (I would say "crap") to 
the library. What we can "easily" do is add some detection code in ntar that 
is (usually) able to detect the beginning of an old-pcap trace file (using 
the old-pcap magic numbers) when a section header block was expected.

>
> Incidentally, one of my pet peeves with the existing tcpdump capture 
> format is that there is no consistent convention for file extension for 
> these, I have seen .dmp, .dump, .tcp, .tcpdump, random others, and no 
> extension at all.  If possible, it would be really nice if the ntar 
> library would use a default file extension (perhaps overridable by an 
> application or user) for all files that are generated.  Having some 
> consistency for this would greatly reduce the likelihood of accidental 
> concatenation of new and old trace format files.
>
> At the very very least, there should be a suggested file extension in the 
> NTAR specification.  (I don't really care if it is .ntr or .ntar or 
> something else, as long as everybody uses the same one.)

I agree 100%. I don't know if such information should go in the pcap-ng file 
format draft, or in the ntar documentation (ntar is *one* library that 
supports the pcap-ng format, maybe in the future there will be other 
implementations of the file format).

I usually use .ntar as the extension, but any other one is ok for me.

Have a nice day
GV

>
> @alex
> -- 
> mailto:dupuy at counterstorm.com
> _______________________________________________
> ntar-workers mailing list
> ntar-workers at winpcap.org
> https://www.winpcap.org/mailman/listinfo/ntar-workers