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
>
> ______________________________________________________________________
>
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
