On Fri, Mar 15, 2013 at 06:37:25PM -0700, Guy Harris wrote: > > On Mar 15, 2013, at 2:45 PM, Michael Richardson <m...@sandelman.ca> wrote: > > > > >>>>>> "wen" == wen lui <esolvepol...@gmail.com> writes: > > wen> I used libpcap function pcap_next() to capture some tcp packets > > wen> I checked the bytes of the captured packets and notice that the > > wen> ethernet and ip header of packets are distorted, in a mess with > > wen> a lot 0's but the TCP header is fine > > > > wen> what are potential reasons for this? > > > > if you capture on Linux with the cooked mode interface. > > That probably won't happen if you're capturing on an Ethernet device, > but it *will* happen if you capture on the "any" device. > > However, yes, *NO* program using libpcap/WinPcap should simply > *assume* it's getting Ethernet packets; if it's looking at the > packets, not just blindly writing them to a file without examining the > contents, then, if it doesn't need to handle 802.11 and PPP and so on, > just Ethernet, it should at least call pcap_datalink() and fail if the > return value isn't DLT_EN10MB. (If it's writing them to a pcap file, > pcap_dump_open() will call pcap_datalink() for you, to put the right > link-layer header type in the file header.) > > (Should we change libpcap so that if pcap_datalink() isn't called at > least once before calling pcap_next(), pcap_next_ex(), > pcap_dispatch(), or pcap_loop(), it prints a message to the standard > error saying "you're probably assuming all the world is Ethernet, > aren't you?" and calls abort(). :-))
As I'm not sure if you're serious or not I decided to look into this to satisfy my own curiosity. In case you are serious: https://github.com/wxsBSD/libpcap/commit/70cbe36e2bd12498ca1622349ecb1716a874c376 If you are serious and want this I'll submit a pull request. -- WXS _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers