Wireshark-dev: Re: [Wireshark-dev] Writing NoOp PCAP-NG Records
From: Paul Offord <Paul.Offord@xxxxxxxxxxxx>
Date: Tue, 5 Jul 2016 12:41:10 +0000
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
>
> ______________________________________________________________________
>
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
______________________________________________________________________
- References:
- [Wireshark-dev] Writing NoOp PCAP-NG Records
- From: Paul Offord
- Re: [Wireshark-dev] Writing NoOp PCAP-NG Records
- From: Jasper Bongertz
- [Wireshark-dev] Writing NoOp PCAP-NG Records
- Prev by Date: Re: [Wireshark-dev] Writing NoOp PCAP-NG Records
- Next by Date: Re: [Wireshark-dev] Automated Builds and Ubuntu 16.04 LTS
- Previous by thread: Re: [Wireshark-dev] Writing NoOp PCAP-NG Records
- Next by thread: Re: [Wireshark-dev] Automated Builds and Ubuntu 16.04 LTS
- Index(es):