[tcpdump-workers] Intro Lesson Plan/Tutorial
--- Begin Message --- I have posted a tutorial designed for my introductory cybersecurity class at my high school. Any observations and suggestions are welcome. https://github.com/nplotnick/cyber/blob/master/TCPDump%20Tutorial.pdf -- Neil Plotnick Everett High School 100 Elm Street Everett MA 02149 [image: paesmt_logo.JPG (367×259)] --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
--- Begin Message --- On Mar 22, 2020, at 10:29 AM, Guy Harris via tcpdump-workers wrote: > 5) ... and put pcap under the pcapng team as per the same reason as 4). Done. It's pointed to by https://github.com/pcapng/pcapng and the XML source is at https://github.com/pcapng/pcapng/blob/master/draft-gharris-opsawg-pcap.xml Feel free to comment, add additional authors, etc.. (Note that its purpose is to document the *existing* format, rather than be a source of proposed changes.)--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
--- Begin Message --- On Mar 26, 2020, at 7:10 PM, Guy Harris via tcpdump-workers wrote: > (Note that its purpose is to document the *existing* format, rather than be a > source of proposed changes.) ...proposed changes to the format. I am, however, planning on proposing a mechanism for vendor-specific "custom" link-layer types, inspired by the pcapng "custom" block types and option types, for use in both pcap and pcapng. That'll be in a separate message. As with pcapng block types and options, anything of *general* use that a vendor would like multiple programs to be able to handle should probably be proposed as a part of the standard, with a register link-layer type/block number/option number.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] "Custom" link-layer types for pcap and pcapng
--- Begin Message --- Here's the proposal for "custom" link-layer types I threatened^Wpromised in my earlier email. A link-layer type value of 0x will be reserved as LINKTYPE_CUSTOM, with libpcap offering a DLT_CUSTOM. A custom link-layer type has a 32-bit IANA-registered Private Enterprise Number (PEN): https://en.wikipedia.org/wiki/Private_Enterprise_Number https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers as is used for custom pcapng blocks and options. 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. 2) is more along the lines of the way custom block and options work. However: 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); so I'm inclined to go with 1). 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; 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. 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.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
