Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
Guy Harris via tcpdump-workers wrote: > It's complex, too - and I don't know whether anybody's done a CMake > version of that. > Would it make more sense to put the rpcap I-D into either 1) a separate > team and repository or 2) another repository in the pcapng group, so > that it has its own Makefile? That's my preference. One draft per repo. If you like, make those repo(s) submodules of libpcap if one wants a stronger connection between the documents and the code. signature.asc Description: PGP signature ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
Guy Harris via tcpdump-workers wrote: >> >>> 5) Treat rpcap as "remote procedure call for libpcap" and put it under the the-tcpdump-group team, and put pcap under the pcapng team as per the same reason as 4). >> >> Ok. > This would require the rules in the pcapng repository Makefile to be in > the libpcap Makefile.in. > Michael, would that be inconvenient to maintain? Yes, I think it would be a pain, but it could be done. I certainly would not use the complex lib/* makefile if we really wanted to do that. What about cmake side of things? signature.asc Description: PGP signature ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [pcap-ng-format] "Custom" link-layer types for pcap and pcapng
Guy Harris wrote: > A link-layer type value of 0x will be reserved as LINKTYPE_CUSTOM, > with libpcap offering a DLT_CUSTOM. sounds good. > A custom link-layer type has a 32-bit IANA-registered Private Enterprise Number (PEN): > https://en.wikipedia.org/wiki/Private_Enterprise_Number That works, since many already have PENs, and for middle sized and small entities, they will know what it is, and who controls it. For larger entities, this will sadly be meaningless. I think that this is a really good internal-only format. > We could either 1) also say it should have a 32-bit per-vendor > link-layer type number or 2) say that if the vendor plans to use it for > more than one type of link-layer header, they have to arrange that the > link-layer header should begin with information necessary to determine > what the *rest* of the link-layer header is. At first blush, I prefer to let the vendor figure it out... > every non-custom block includes a block type, and every non-custom > option has an option type, but not every *block* in a capture file has > a link-layer header type - a pcap header has a link-layer type that > applies to all packets in the file and a pcapng IDB has a link-layer > type that applies to all packets on that interface; > knowing the link-layer type up front makes it easier to generate BPF > filter code for an interface, if we support these types for live > capture (or if the vendor's private capture mechanism supports it); yeah... > so I'm inclined to go with 1). okay, so how would we be able to generate code for an encapsulation that we don't know about? > In that model: > in pcap files, if the lower 16 bits of the 32-bit link-layer type value > is 0x, the two "Reserved" fields (which were formerly a > rarely-if-ever-used and not-supported-by-libpcap-or-Wireshark time zone > offset and time stamp resolution) MUST contain the PEN and > vendor-specific link-layer type; not a big fan of this, but okay. > in pcapng file, if the link-layer type in an IDB is 0x, the IDB > *MUST* contain a new option, containing the PEN and vendor-specific > link-layer type. good. > Given that it's for *two* capture file formats, these lists are > probably better places for discussion than having two pull requests and > discussing them in comments there. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
Michael Tuexen via tcpdump-workers wrote: >> Guy Harris via tcpdump-workers wrote: >>> Currently, on GitHub, there's a "pcapng" team: >>> https://github.com/pcapng >> >>> with one repository containing the pcapng specification, and a "the-tcpdump-group" team: >> >>> https://github.com/the-tcpdump-group >>> with repositories for libpcap, tcpdump, and the tcpdump.org Web site. >> >>> It makes sense to me to keep those specifications on a site such as >>> GitHub; GitHub comes to mind first because that's where pcapng >>> currently is. >> >>> 1) add them as repositories to the pcapng team; >> >>> 1) has the slight disadvantage that the name for the team suggests it's >>> for pcapng only; it appears that teams can be renamed: >> >> ... >> >>> Were we to rename it, I don't know what would be a good new name. >> >> I'm good with pcapng, because I also have no other suggestion. >> I would like to restart the opsawg work on an IETF specification for >> this. > I would support this. However, last time I tried this, I was not successful. > There were not very interested in defining a file format... > Maybe things have changed, but I don't know. I know that you worked hard, and it didn't happen. It is on my agenda to make this happen, and I'll hope that I can depend upon your help. With IETF107 going virtual, I will see if opsawg has time consider the document again. I will look at reposting it today. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
Guy Harris via tcpdump-workers wrote: > Currently, on GitHub, there's a "pcapng" team: > https://github.com/pcapng > with one repository containing the pcapng specification, and a "the-tcpdump-group" team: > https://github.com/the-tcpdump-group > with repositories for libpcap, tcpdump, and the tcpdump.org Web site. > It makes sense to me to keep those specifications on a site such as > GitHub; GitHub comes to mind first because that's where pcapng > currently is. > 1) add them as repositories to the pcapng team; > 1) has the slight disadvantage that the name for the team suggests it's > for pcapng only; it appears that teams can be renamed: ... > Were we to rename it, I don't know what would be a good new name. I'm good with pcapng, because I also have no other suggestion. I would like to restart the opsawg work on an IETF specification for this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [pcap-ng-format] Proposal for storing decryption secrets in a pcapng block
Guy Harris wrote:
> The second and third option require either the producer, or some
> post-processor, to write a new version of the file putting the secrets
> before the packets that require them. The producer isn't necessarily
> responsible for doing so; one might have tcpdump, or dumpcap (or some
> program using dumpcap, such as TShark or Wireshark) write out a capture
> with no secrets, and then have another program (a utility, or Wireshark
> after having read in the file and then given the secret in question)
> write out a new file with the secrets early enough in the file ("before
> all the packet blocks" is probably the simplest implementation).
I'm in favour of this option, and providing a signal early in the file that
the indicates if that process has occured yet.
> A producer that *does* happen to have the secret available before
> seeing any packets that require the secret *could* write it directly.
Agreed.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [pcap-ng-format] Proposal for storing decryption secrets in a pcapng block
Peter Wu wrote: > Requirements for block placement: > - No requirement. Producers are allowed to write the block anywhere. > Disadvantages for consumers: requires a two-pass scan to collect > secrets before they are used. I prefer this, but I would support having a flag in the block that says that no other blocks exist in the file until at least X-bytes. So, a producer (or something downstream of it), could scan for the blocks, move them to the front, and indicate how far into the file it cover. Naturally, if X >= file size, then the work is done. > - Place secrets before the packet blocks that require them. Consumers > can read and decrypt in one pass. Disadvantage: producers cannot > always guarantee availability of secrets while writing the capture. > - Place a single secret block before the first packet block. Consumers > can read and decrypt in one pass. Disadvantage: requires producers to > post-process (rewrite) the capture file to insert secrets. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
