Re: 'bogus savefile header'

[Aaron Turner <synfinatic () gmail com>]

So building the latest tcpdump from git and it won't link against the
latest libpcap from git:

ld: warning: in /usr/local/lib/libpcap.dylib, file was built for
unsupported file format which is not the architecture being linked
(i386)

running file against the actual file (libpcap.dylib is a symlink) returns:

/usr/local/lib/libpcap.1.2-PRE-GIT.dylib: Mach-O 64-bit dynamically
linked shared library x86_64

Just ran ./configure && make && make install for both and verified
that tcpdump is linking against the git version of libpcap.  I don't
see any special CFLAGS or configure args for the current
libpcap/tcpdump MacPorts builds (1.1.1/4.1.1) so maybe something
changed?

libpcap is building with: -arch x86_64 -arch i386

I tried:

CFLAGS="-arch x86_64 -arch i386" ./configure

for tcpdump, but still no worky.

ideas?

On Mon, Aug 23, 2010 at 1:44 PM, Aaron Turner <synfinatic () gmail com> wrote:
> On Mon, Aug 23, 2010 at 12:08 PM, Guy Harris <guy () alum mit edu> wrote:
> > On Aug 22, 2010, at 4:15 PM, Aaron Turner wrote:
> >
> > > Long story short, tcpreplay allows users to replay traffic in "verbose
> > > mode" which basically involves forking tcpdump and writing each packet
> > > over a socketpair().  This has worked for quite a while (years now)
> > > but recently I've realized something broke along the way and I'm at a
> > > loss to as why.
> >
> > What changed between when it worked and when it broke?  tcpreplay, libpcap, tcpdump, some of the above, all of the 
> > above?
>
> Since I don't have a unit test case for this, I can't say what has
> changed exactly (guess what I'm doing tonight :).  Looking at my svn
> history, my code has been pretty stable for quite a long time (over a
> year).   I know I've upgraded libpcap a number of times since I last
> executed this code so that's my best guess right now without debugging
> more then I have so far.
>
> > > Basically, when I write my first packet over the socket to tcpdump, i
> > > get the error:
> > >
> > > tcpdump: pcap_loop: bogus savefile header
> > >
> > > I believe I've tracked that down to sf-pcap.c in libpcap, which
> > > indicates that the caplen > 65535.  Seems straight forward, until I
> > > start debugging and see the pcap_t struct I'm using for
> > > pcap_dump_fopen()
> >
> > That's for the side of the socket pair to which tcpreplay is writing, I presume.
>
> Correct.
>
> > > has snapshot set to 65535:
> >
> > That just means you're claiming that the max packet size is 65535; you could then write a packet with a caplen > 
> > 65535 with pcap_dump().  Doing so would be considered impolite, but it's not impossible....
>
> Not the case here, standard ethernet, no jumbo frames- first frame is
> 93 bytes.  Problem seems to happen with any pcap file which contains
> packets.
>
> Anyways, I'm going to build libpcap with gcc -g and see what is being
> sent across the socket... maybe that will explain things.
>
>
> --
> Aaron Turner
> http://synfin.net/         Twitter: @synfinatic
> http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
> Those who would give up essential Liberty, to purchase a little temporary
> Safety, deserve neither Liberty nor Safety.
>     -- Benjamin Franklin
> "carpe diem quam minimum credula postero"



-- 
Aaron Turner
http://synfin.net/         Twitter: @synfinatic
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
    -- Benjamin Franklin
"carpe diem quam minimum credula postero"
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.