Re: Writing NoOp PCAP-NG Records

[Paul Offord <Paul.Offord () advance7 com>]

Thanks for responding Jasper.

I had considered reading the etl once for the interface info and then again for the packets but this could take time 
and I want the convertor to be fast.  Also, I've written a working version (with command line params for the interface 
info) and I'm too lazy to rewrite it :-)

I did mean Custom Block, but your option idea is better so I'll go with that.

Best regards...Paul


Sent from Samsung Mobile on O2


-------- Original message --------
From: Jasper Bongertz
Date:05/07/2016 13:28 (GMT+01:00)
To: Paul Offord , Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Writing NoOp PCAP-NG Records

Hi Paul,

I see the problem, but isn't it possible to read the .etl file first to
extract the interface information, write the IDBs and then reread the
file to convert the blocks? Maybe this can even be done in a way
skipping having to read all of the .etl file first, reading from the
back instead (I have no idea how .etl is formatted at this time, so
maybe that's not possible - with pcapng it is easy as you can read
from the back).

If you want to go with your idea of keeping a null segment please
don't add a custom block (I think you mean "custom option", not
"custom block", which would be the equivalent of SHB, IDB, EPB etc.) if
it can be avoided. You could use the opt_endofopt code instead (which
has option code 0 anyway), meaning if you zero the rest of the block
it shouldn't hurt at all.

Cheers,
Jasper

Tuesday, July 5, 2016, 1:08:34 PM, you wrote:

> Hi,
>
>
>
> I am writing a small utility that converts .etl network trace files
> produced by netsh trace into pcapng format.  The interface
> information is right at the end of the ETL file, but I need to
> create  IDBs near the start of the pcapng file.  I don’t want to
> hold a whole converted trace file in memory and I’d prefer not to
> shuffle the data around in the pcapng file.  My plan is:
>
>
>
> ·        Write an “IDB segment” of null bytes where the IDB will go
> – enough to accomodate the maximum anticipated IDB blocks, say 2 KB
>
> ·        Once I get to the interface data in the ETL, seek back to the “IDB Segment”
>
> ·        Write the IDBs
>
> ·        Pad the “IDB segment” with the equivalent of NoOps
>
>
>
> There is no NoOp block type and so I’m thinking of using a Custom Block
>
>
>
> ·        Would using a Custom Block in this way cause problems?
>
> ·        What value should I use for the Private Enterprise Number (PEN)?
>
> ·        Is there a better way of doing this?
>
>
>
> Thanks and regards…Paul
>
>
> ______________________________________________________________________
>
>  This message contains confidential information and is intended
> only for the individual named. If you are not the named addressee
> you should not disseminate, distribute or copy this e-mail. Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
>
>  Any views or opinions expressed are solely those of the author and
> do not necessarily represent those of Advance Seven Ltd. E-mail
> transmission cannot be guaranteed to be secure or error-free as
> information could be intercepted, corrupted, lost, destroyed, arrive
> late or incomplete, or contain viruses. The sender therefore does
> not accept liability for any errors or omissions in the contents of
> this message, which arise as a result of e-mail transmission.
>
>  Advance Seven Ltd. Registered in England & Wales numbered 2373877
> at Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ
>
>
> ______________________________________________________________________
>  This email has been scanned by the Symantec Email Security.cloud service.
>  For more information please visit http://www.symanteccloud.com
>
> ______________________________________________________________________

______________________________________________________________________

This message contains confidential information and is intended only for the individual named. If you are not the named 
addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if 
you have received this e-mail by mistake and delete this e-mail from your system.

Any views or opinions expressed are solely those of the author and do not necessarily represent those of Advance Seven 
Ltd. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, 
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept 
liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.

Advance Seven Ltd. Registered in England & Wales numbered 2373877 at Endeavour House, Coopers End Lane, Stansted, Essex 
CM24 1SJ

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe