Re: [tcpdump-workers] [GitHub] darrenlim sent you a message

[Michael Richardson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> "GitHub" == GitHub   writes:
GitHub> darrenlim wants you to pull from darrenlim/libpcap at
GitHub> undefined

GitHub> Body: Hello, Please consider pulling in the changes I've
GitHub> committed. In summary, I've modified the configure.in script
GitHub> (and regenerated configure) to add the dagutil.o object file
GitHub> from the Endace DAG libraries into the libpcap archive. A
GitHub> dependency has been introduced whereby the dagapi.o object
GitHub> depends on functions in the dagutil.o as of DAG software
GitHub> release 3.4.1. Static builds against libpcap.a were breaking
GitHub> without the fix. This change is backwards compatible with
GitHub> older versions of the DAG libraries.

GitHub> Please let me know if more information is required or if
GitHub> I've gone about submitting changes the right way as I'm
GitHub> still trying to wrap my head around the concept of git :)
GitHub> Thanks!

GitHub> Regards, Darren (darren@endace.com)

GitHub> http://github.com/darrenlim/libpcap/undefined

I pulled from your branch. As I understand it, if "dagutils.o" is found
(I'm unclear where it comes from), then it gets rolled into the
resulting libpcap.a file.  The search for dagutils occurs by looking for
header files.  

When I first read things, I thought perhaps you were introducing a
dagutil.o into the libpcap archive, but that's not the case -- you are
just including it if installed.  This might be a concern if libpcap was
under the GPL, but should not be an issue as it's under BSD license.

- -- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBSrJ0bYCLcPvd0N1lAQLCjwf+LtuM3SXiktQY2wV42djpxbYNLFxjfCT0
OuMBNEy2ljnQf9iKcnoSGsiZewP+UTaPRvpYMKrJkUlxtWZoKZzFqM9lZac9wnmd
PtSFzC0yX6B6pFPAf51CX3iPamkBeNxN7V4MfP9BIJO51ZM0jtN7S24Nq/h5DbAq
XUGIYez5jMtA6+N41tVDMBmeU8Y8I1scTVHc6RS0dRYOiMonyDZlWKKbjsf+Cqc0
tgy3qZMlh+aDYPjsi8Op4YOpax+yrG1XLZ7hTN3oDim4PpivbXEqn/9WjtRez8dz
W1CbScLtgjCT3K0MYJal8B4Tsr9vcUIm62dK0hE9P44C0Fy75yKssw==
=IVbd
-END PGP SIGNATURE-
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [PATCH] Re: [tcpdump-workers] Bug: Counting dropped packets in

[Dustin Spicuzza]

Guy Harris wrote:
> 
> On Aug 31, 2009, at 2:36 PM, Dustin Spicuzza wrote:
> 
>> So... I've changed my patch to populate ps_ifdrop instead, and it should
>> be good to go, without screwing with current applications.
> 
> Checked in.
> 

Thanks! Except I found a small problem that I introduced...

If you call linux_if_drops with a NULL device, then it segfaults when it
tries to do strlen(). The only time this happens is if you call
pcap_stats() on a pcap handle that is open but not activated (or the
activation failed), and thus the device is NULL.

Not sure if this is something you want to fix, or if this is in the land
of undefined behavior that the user shouldn't do. :)

Dustin


-- 
Innovation is just a problem away



signature.asc
Description: OpenPGP digital signature