[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 05.04.2004 - 06.04.2004 GMT
CVS log entries from 05.04.2004 (Mon) 09:05:57 - 06.04.2004 (Tue) 09:05:45 GMT = Summary by authors = Author: guy File: libpcap/missing/snprintf.c; Revisions: 1.1 File: libpcap/snprintf.c; Revisions: 1.2, 1.1.2.1 File: libpcap/INSTALL.txt; Revisions: 1.10, 1.7.2.3 File: tcpdump/print-eap.c; Revisions: 1.2 File: libpcap/FILES; Revisions: 1.31, 1.26.2.4 Author: mcr File: htdocs/pcap/pcap.txt; Revisions: 1.1 File: libpcap/doc/pcap.xml; Revisions: 1.1 File: libpcap/doc/pcap.txt; Revisions: 1.1 File: libpcap/doc/pcap.html; Revisions: 1.1 File: htdocs/pcap/pcap.html; Revisions: 1.1 = Combined list of identical log entries = Description: documentation for proposed pcap format Modified files: File: libpcap/doc/pcap.html; Revision: 1.1; Date: 2004/04/05 20:26:58; Author: mcr; File: libpcap/doc/pcap.txt; Revision: 1.1; Date: 2004/04/05 20:26:58; Author: mcr; File: libpcap/doc/pcap.xml; Revision: 1.1; Date: 2004/04/05 20:26:58; Author: mcr; File: htdocs/pcap/pcap.html; Revision: 1.1; Date: 2004/04/05 20:27:23; Author: mcr; File: htdocs/pcap/pcap.txt; Revision: 1.1; Date: 2004/04/05 20:27:24; Author: mcr; --- Description: Move snprintf.c to the missing directory, as that's where Makefile.in expects it to be (tcpdump puts snprintf.c and the like into a missing subdirectory). Modified files: File: libpcap/FILES; Revision: 1.31; Date: 2004/04/05 22:43:50; Author: guy; Lines: (+1 -1) File: libpcap/FILES; Revision: 1.26.2.4; Date: 2004/04/05 22:48:26; Author: guy; Lines: (+1 -1) File: libpcap/INSTALL.txt; Revision: 1.10; Date: 2004/04/05 22:43:50; Author: guy; Lines: (+2 -2) File: libpcap/INSTALL.txt; Revision: 1.7.2.3; Date: 2004/04/05 22:48:26; Author: guy; Lines: (+2 -2) File: libpcap/snprintf.c; Revision: 1.2; Date: 2004/04/05 22:43:50; Author: guy; Lines: (+2 -2) File: libpcap/snprintf.c; Revision: 1.1.2.1; Date: 2004/04/05 22:48:26; Author: guy; Lines: (+2 -2) File: libpcap/missing/snprintf.c; Revision: 1.1; Date: 2004/04/05 22:43:51; Author: guy; = Log entries = Description: Squelch a compiler warning. Modified files: File: tcpdump/print-eap.c; Revision: 1.2; Date: 2004/04/05 22:35:36; Author: guy; Lines: (+2 -2) = Summary of modified files = File: htdocs/pcap/pcap.html Revisions: 1.1 Authors: mcr --- File: htdocs/pcap/pcap.txt Revisions: 1.1 Authors: mcr --- File: libpcap/FILES Revisions: 1.31, 1.26.2.4 Authors: guy (+1 -1), guy (+1 -1) --- File: libpcap/INSTALL.txt Revisions: 1.10, 1.7.2.3 Authors: guy (+2 -2), guy (+2 -2) --- File: libpcap/doc/pcap.html Revisions: 1.1 Authors: mcr --- File: libpcap/doc/pcap.txt Revisions: 1.1 Authors: mcr --- File: libpcap/doc/pcap.xml Revisions: 1.1 Authors: mcr --- File: libpcap/missing/snprintf.c Revisions: 1.1 Authors: guy --- File: libpcap/snprintf.c Revisions: 1.2, 1.1.2.1 Authors: guy (+2 -2), guy (+2 -2) --- File: tcpdump/print-eap.c Revisions: 1.2 Authors: guy (+2 -2) -- Automatic cron job from /tcpdump/bin/makelog - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] proposed new pcap format
On Apr 5, 2004, at 10:39 PM, Ryan Mooney wrote: What about adding the concept of arbitrary meta-packets that can sit anywhere in the capture stream. These could be used to encode comments, and other meta-data. In Michael Richardson's proposal, a capture file is a sequence of records, each of which contains one or more type/length/value items. A record need not contain a PCAP_DATACAPTURE item; if it doesn't contain one, it'd be meta-data without a packet, and if it does contain one, it's a packet, possibly with additional meta-data. In Loris Degioanni and Fulvio Risso's proposal, a capture file is a sequence of records, each of which is a type/length/value item. Some of the record types include a sequence of type/length/value options within them. Both of those schemes support the concept of arbitrary meta-data that can appear anywhere in the capture stream, encoding comments and other meta data... This concept could also be used for other internal meta-data for example capture information like direction, interface info, etc...). There would have to be a way to tag future as part of a meta-data stream (to handle multiple interfaces, etc..). ...and handle multiple interfaces, as well as meta-data associated with packets and not associated with packets... This could be done in a way to preserve the ability to cat multiple files together ...and support the ability to concatenate multiple capture files with cat. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
