On Thu, Jul 03, 2014 at 11:52:03AM -0400, Michael Richardson wrote: > > Guy Harris <g...@alum.mit.edu> wrote: > > The current libpcap support uses the existing APIs, which can't expose > > the full capabilities of pcap-ng; it requires all interfaces in the > > pcap-ng file to have the same link-layer header type and snapshot > > length, and all sections of the pcap-ng file to have the same byte > > order. (Then again, Wireshark requires all sections of the pcap-ng > > file to be the same section :-); it currently supports only one > > section. This needs to be fixed as well.) > > Yes, this is a good point. I don't think we can go there until we start > using pcapng by default, and start considering pcap as read-only. > > Also, I think that we will need to have a set of pcapng utilities. > I was trying to run "netdude" which lets you pick/chose/edit pcap files, > but the version of gtk that is requires is now obsolete... so I wound up > trying to hex editing my pcap file to remove the unwanted packet, then I used > tcpslice when I failed to get that right. > > (I realize that pcapng files have the goal that concatenation is simple) > > > OS X Mountain Lion has changes to libpcap and tcpdump that allow > > tcpdump to write pcap-ng files (-P specifies "write pcap-ng"); sadly, > > those changes are under the APSL, patent clauses included, so I'm loath > > to incorporate them into our libpcap and tcpdump. > > Interesting, I didn't know Apple did that. > Who did that work, I'm curious? And why?
FWIW, https://www.opensource.apple.com/source/libpcap/libpcap-42/libpcap/pcapng.c > > >> PCAPNG is magic 0x1A2BC3D4. > >> PCAP is magic 0xa1b23c4d. > >> I would have liked if PCAPNG had used the same magic, and actually just > >> bumped the PCAP_VERSION_MAJOR... > > > I.e., if the major version number of the file is 3, the rest of the > > file header would look more like a pcap-ng Section Header Block, with > > the magic number being the block type? > > Yes, that's I would have preferred. > > >> Did anyone tell the /bin/file people about the PCAPNG magic number? > > > Yes: > > Good. > > >> Anyway, I'm thinking that there should be another tcpdump 4.x release > >> that writes to pcap format by default, but has an option to force > output > >> format to pcapng, and then a 5.x release that defaults to writing > >> pcapng. > > > Yes; the new libpcap would have a new API that can read pcap and > > pcap-ng files and expose the full capabilities of pcap-ng, and another > > new API that can write pcap-ng files (and perhaps also pcap files; that > > would let us fix some infelicities in the current pcap writing API, > > such as not being able to get a write error indication or a close error > > indication), and tcpdump would, if those APIs are available in libpcap, > > use the new APIs to read files and would offer a -P flag to write > > pcap-ng files. (The existing APIs would remain, for the benefit of > > programs not yet changed to use the new APIs.) > > I think that we should be able to make the existing APIs wrappers around > new function? > > Are there specific things in a new API that would make wireshark happier? > feel free to start a new thread ;-) > > > Tcpdump 5.x would do the same, but write pcap-ng files by default; I'm > > not sure whether we should then make -P specify "write pcap" or add a > > new option for that. > > I'd like it to be -P pcap or -P pcapng (or -P pcap3 ). > I'd also like tcpdump 5 to come with a new (alternate) main() where we > get to start again on all the single letter options and go for long options. > > -- > ] 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 > [ Cheers, Michal > > _______________________________________________ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
