On Wed, Aug 30, 2017 at 1:21 AM, Anders Broman
<anders.broman@xxxxxxxxxxxx> wrote:
>
>
> -----Original Message-----
> From: Wireshark-dev [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Ed Beroset
> Sent: den 29 augusti 2017 21:40
> To: wireshark-dev@xxxxxxxxxxxxx
> Subject: Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
>
> On 08/29/2017 02:35 PM, Richard Sharpe wrote:
>>> On Tue, Aug 29, 2017 at 10:50 AM, Ed Beroset <beroset@xxxxxxxxxxxxxx> wrote:
>>>> On 06/16/2017 01:27 PM, Richard Sharpe wrote:
>>>>
>>>> I've just encountered a need for this as well. Have you made
>>>> progress, Evan? Do you want some help?
>>>
>>> Evan seems to have dropped off the radar. I outlined to Evan an
>>> approach for doing this, so I could send it to Ed instead ...
>>
>>It would be helpful if you could. I've looked at your old patch and I've been looking over the dumpcap.c code and have been making some notes, but it would nice to have >additional input on this, especially since you've already looked at it. Thanks!
FWIW, here are the notes I sent Evan and Ed:
-----------------------
> The patch that I pointed you at is incomplete because it does not
> handle PCAPNG captures being piped at you. In addition I am no longer
> happy with exposing the internals of the struct capture_src like that.
>
> It should be easy to add pcapng support by detecting in
> cap_pipe_open_live that you are dealing with PCAPNG rather than PCAP,
> since you will see that you have an PCAPNG capture because the Section
> Header Block magic (block type) is 32 bits and is different than any
> of the PCAP magic values, and there must be at least one SHB in a
> PCAPNG capture.
>
> Thus you can use that to choose which state machine should be used for
> the subsequent reads.
>
> I think it might be cleaner to extract the current PCAP state machine
> into its own function and create a new one for PCAPNG ... and I will
> have more thoughts later after I have thought about this some more.
More thoughts ...
1. Rename cap_pipe_dispatch to pcap_pipe_dispatch.
2. Create a new pcapng_pipe_dispatch. It only has to deal with two
record types. SHBs and all others. The reason you have to deal with
SHBs specially is that they can change the endianness of the capture
until you see the next SHB. Each block, including the SHB has a length
field as the second 32-bit field and the last 32-bit field. The SHB's
length cannot be interpreted until you figure out the endianness which
is determined from the third 32-bit field. It also contains a total
length for the section.
3. The first SHB has to be dealt with specially since you need to read
the first 32-bits (the MAGIC) to figure out whether or not you are
dealing with PCAP or PCAPNG. After that, SHBs still need to be dealt
with specially, but other blocks are simple to deal with. Read the
first 8 bytes, and if the MAGIC says it is not an SHB, the second
4-byte field tells you how many more bytes to read. Then you can
simply write the lot out. For each non-first SHB, you need to read
another 4 bytes to figure out the endianness field (4-bytes) to
determine how to interpret the second field.
4. Modify pcap_dispatch to call pcap_pipe_dispatch or
pcapng_pipe_dispatch depending on the the type of the capture
determined from reading the very first MAGIC field.
5. cap_pipe_dispatch may look complex because of all those #ifdef's
but that is simply to support Windows as well as Linux. It should be
possible to create pcapng_pipe_dispatch along similar lines as well.
There is probably only two states, or maybe three states, for
pcapng_pipe_dispatch: PCAPNG_STATE_EXPECT_PREAMBLE (for the first 8
bytes), PCAPNG_NG_STATE_READ_DATA for the remaining data in the
record, and PCAPNG_STATE_EXPECT_SHB_ENDIAN for the 4-byte endianness
indicator of an SHB.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)