Data link level type code

["Toeung, Chanthy" <chanthy.toeung () ca kontron com>]

Hi all,

I need a specific DLT_ value for IPMB protocol. Does anyone know who should i write the email too? 

I used to write to tcpdump-workers () tcpdump org, but it seems like this email doesn't exist anymore.

Thank for your help

-----Original Message-----
From: tcpdump-workers-owner () lists tcpdump org
[mailto:tcpdump-workers-owner () lists tcpdump org]On Behalf Of Saikiran
Madugula
Sent: Friday, August 10, 2007 3:10 PM
To: tcpdump-workers () lists tcpdump org
Subject: Re: [tcpdump-workers] libpcap: Memory-loeaks SIGSEGV


Hello TJ,

The link to libpcap-valgrind.tar.bz2 does not seem to work, can you 
please check it ?

Thanks,
Saikiran.


TJ wrote:
> I've been working on analysing an issue with a cluster of Proliant
> servers running Debian 2.6.18 64-bit with 4GB RAM on Xeon 3000 CPUs in a
> data-centre.
> As part of the diagnosis I have written a tool to check incoming
> packets.
>
> I've used the latest libpcap (0.9.7) built from source.
>
> The tool is being developed on a 32-bit system where it runs ok. On the
> 64-bit servers a SIGSEGV is caused inside libpcap. We've found it
> happens with the 'standard' Debian 0.9.5 build of libpcap too.
>
> In trying to find the cause of the SIGSEGV we've done a lot of testing,
> including creating a simple test app that uses the same calls to libpcap
> functions as in the code that SIGSEGVs. Strangely we can't get the
> libcap test app to SIGSEGV although the code is a copy-paste from the
> diagnostic app.
>
> There seems to be an issue when calls are made to pcap_* functions that
> pass local (stack) pointers, but as it doesn't always cause SIGSEGV so
> we're not convinced that is pertinent.
>
> The gdb SIGSEGV analysis is further down this email.
>
> We ran the libpcap test app through valgrind. In summary, valgrind is
> reporting:
>
> 64-bit libpcap 0.9.5:
>
> LEAK SUMMARY:
> ==9388==    definitely lost: 40 bytes in 1 blocks.
> ==9388==    indirectly lost: 939 bytes in 36 blocks.
> ==9388==      possibly lost: 0 bytes in 0 blocks.
> ==9388==    still reachable: 8 bytes in 1 blocks.
> ==9388==         suppressed: 0 bytes in 0 blocks. 
>
> 32-bit libpcap 0.9.7:
>
> ==7910== LEAK SUMMARY:
> ==7910==    definitely lost: 20 bytes in 1 blocks.
> ==7910==    indirectly lost: 555 bytes in 29 blocks.
> ==7910==      possibly lost: 0 bytes in 0 blocks.
> ==7910==    still reachable: 4 bytes in 1 blocks.
> ==7910==         suppressed: 0 bytes in 0 blocks. 
>
> I'm not sure if these leaks and losses are related to the SIGSEGV but
> they certainly ought to be cleared up.
>
> I've created an archive with the test-libpcap source-code and results of
> the valgrind test runs with expanded analysis of the leaks and linked to
> it below (to save on distributing attachments).
>
> http://intuitivenipple.net/paketeer/libpcap-valgrind.tar.bz2
>
>
> TJ.
>
>
> ----- 64 bit gdb of SIGSEGV ---------
>
> gdb) run
> Starting program: /root/packeteer/packeteer -i eth0 -p dst\ host\
> 10.33.4.102\ and\ tcp\ port\ 80
> [Thread debugging using libthread_db enabled]
> [New Thread 47255043014096 (LWP 28755)]
>  
> Packeteer © 2007 TJ http://intuitivenipple.net
> Licensed on the terms of GPL version 3
>  
> Monitoring interface: eth0
> pcap filter: dst host 10.33.4.102 and tcp port 80
> device eth0
> pcap: initialising eth0 with rule "dst host 10.33.4.102 and tcp port 80"
> pcap_lookupnet() done
> pcap_openlive() done
> pcap_freealldevs() done
> pcap_compile(527690, 7fff3ee3a540, "dst host 10.33.4.102 and tcp port
> 80", 0, 0)
>  
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 47255043014096 (LWP 28755)]
> 0x00002afa6bc786b6 in _dl_rtld_di_serinfo ()
> from /lib64/ld-linux-x86-64.so.2
>  
> (gdb) bt
> #0  0x00002afa6bc786b6 in _dl_rtld_di_serinfo ()
>    from /lib64/ld-linux-x86-64.so.2
> #1  0x00002afa6bc783a2 in _dl_rtld_di_serinfo ()
>    from /lib64/ld-linux-x86-64.so.2
> #2  0x0000000000405ed3 in pcap_compile ()
> #3  0x0000000000402884 in pcap_init ()
> #4  0x00000000004022dc in main ()
>
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.