Dear L7Sqr, With regards to the thread what exactly should be changed to avoid any future problem. So I am not used to using thread in C either. Yes as for my question with regards to tcpdump. I have now managed to solve to find the ether_type. So now for e.g. if the ether_type is TCP so I should explore the print-ip.c codes right? So I am now exploring it and stuck on which one of the function should be called first?

It might be easiest if you use a debugger to trace the execution. I've already described the flow I think you want in an earlier post (describing ip_print and tcp_print). If that is not sufficient you may want to attach to a tcpdump process and read a pcap file with packets of interest to you. This will allow you to follow the exact code path for the packets you wish to analyze.

As for the threads, you will want an individual thread_t for each thread you create. An array would suffice. Something like

pthread_t threads[10];

for (i = 0; i < 10; ++i)
   pthread_create (&thread[i], NULL, ...);

for (i = 0; i < 10; ++i) 
   pthread_join (thread[i], NULL);

I am about to install tcpdump on centos 6.4. Should I do it from the source or using yum install ? What type of debugger will be used. What I am planning is that to put some printf line along the codes and recompile it each time so that I will know the flow better? What is your opinion on this ? I guess for this I should install from source right? About the thread what I notice is that even the pf_ring version have pthread_create and pthread_join but only thing is that is limited to one pthread_t my_thread;? But in this case we are limiting the loop to 10?

I would install from source and, if possible, enable debug (-ggdb) and then use gdb to follow the control flow. You could certainly accomplish the same by introducing printf satatements in the code but it may be less precise than the gdb approach. Choose according to your comfort level.

I limited the loop to 10 for the sake of the example. You could certainly have that be as large or small as you like. Of course, if you are doing it dynamically you will need to consider malloc and free to get the memory.

In general, you can set environment variables to control the build process. For example you should be able to set CFLAGS environment variable (i.e. export CFLAGS=-ggdb) and have it picked up by ./configure

I have followed accordingly and install the libpcap first and saw towards the end this error.

./runlex.sh lex -oscanner.c scanner.l
yacc -d grammar.y
make: yacc: Command not found
make: *** [grammar.c] Error 127
yacc -d grammar.y
make: yacc: Command not found
make: *** [grammar.c] Error 127

Next I run this command first export CFLAGS=-ggdb followed by ./configure. Then at the end it say this error configure: error: see the INSTALL doc for more info. So I start to read the file. But I confuse here "After libpcap has been built (either install it with "make install" or make sure both the libpcap and tcpdump source trees are in the same directory), run ./configure (a shell script). "configure" will
determine your system attributes and generate an appropriate Makefile". from Makefile.in. Now build tcpdump by running "make". Does it mean that I must put my tcpdump source file into the libpcap directory and then run the ./configure? Both of the directory are now in the one bigger directory?

It seems that in order to build libpcap you need to have yacc installed (you might also be able to use bison, I'm not sure). Since tcpdump depends on libpcap you can not build it until you build libpcap first. Try installing the dependencies for libpcap - this includes yacc at a minimum. Once you can build libpcap then move on to building tcpdump.

Alternatively, you might just want to install the libpcap-devel or libpcap-dev package using your system's package manager first (since it will do the dependency satisfaction for you) and then try and build tcpdump.

I have install bison so the libpcap installation was fine. I have also tried installing libpcap-devel then I run the tcpdump ./configure and below is the whole message. Have you come across this problem?

./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking gcc version... 4
checking for inline... inline
checking for __attribute__... yes
checking whether __attribute__((format)) can be applied to function pointers... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking rpc/rpc.h usability... yes
checking rpc/rpc.h presence... yes
checking for rpc/rpc.h... yes
checking rpc/rpcent.h usability... no
checking rpc/rpcent.h presence... no
checking for rpc/rpcent.h... no
checking netdnet/dnetdb.h usability... no
checking netdnet/dnetdb.h presence... no
checking for netdnet/dnetdb.h... no
checking for net/pfvar.h... no
checking for netinet/if_ether.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking Linux kernel version... 2
checking smi.h usability... no
checking smi.h presence... no
checking for smi.h... no
checking for smiInit in -lsmi... no
checking whether to enable the possibly-buggy SMB printer... yes
configure: WARNING: The SMB printer may have exploitable buffer overflows!!!
checking whether to drop root privileges by default... no
checking whether to chroot... no
checking whether to enable ipv6... yes
checking ipv6 stack type... linux-glibc
checking for library containing getaddrinfo... none required
checking getaddrinfo bug... good
checking for getnameinfo... yes
checking for dnet_htoa declaration in netdnet/dnetdb.h... no
checking for addrinfo... yes
checking for NI_MAXSERV... yes
checking for NI_NAMEREQD... yes
checking for sockaddr_storage... yes
checking for vfprintf... yes
checking for strcasecmp... yes
checking for strlcat... no
checking for strlcpy... no
checking for strdup... yes
checking for strsep... yes
checking for fork... yes
checking for vfork... yes
checking for strftime... yes
checking for setlinebuf... yes
checking for alarm... yes
checking for vsnprintf... yes
checking for snprintf... yes
checking return type of signal handlers... void
checking for sigaction... yes
checking for library containing dnet_htoa... no
checking for main in -lrpc... no
checking for library containing getrpcbynumber... none required
checking for library containing gethostbyname... none required
checking for library containing socket... none required
checking for library containing putmsg... none required
checking for local pcap library... ./../libpcap-1.4.0/libpcap.a
checking for pcap-config... ./../libpcap-1.4.0/pcap-config
checking for pcap_loop... no
configure: error: Report this to tcpdump-workers@lists.tcpdump.org, and include the
config.log file in your report.  If you have downloaded libpcap from
tcpdump.org, and built it yourself, please also include the config.log
file from the libpcap source directory, the Makefile from the libpcap
source directory, and the output of the make process for libpcap, as
this could be a problem with the libpcap that was built, and we will
not be able to determine why this is happening, and thus will not be
able to fix it, without that information, as we have not been able to
reproduce this problem ourselves.

Were you successful in installing the development portions of libpcap? You say you tried.

All indicators are that this is a problem with the installation of libpcap. As I do not have access to your system directly I can not debug your specific process.

I'd suggest that you install libpcap development version; ensure that it installed correctly; then try to build tcpdump again. If there are still errors, you may have to file a bug report as is mentioned in that output.

Yes I was successful installating the libpcap-devel and there after no issues. But yet my tcpdump is still having issues. I have already file a bug report with all the relevant files required. Would you like to have a look too maybe I can email you.

I'd prefer to keep the dialog on the forums so anyone else following along can benefit from the solution and others can help if they'd like.

Describe your environment here - OS, versions of software etc.
If I can find some time over the weekend I'll try to set an equivalent env and reproduce the artifacts you see. I may not have the time so no promises.

My environment is Centos 6.4 with basic installation thats all. Anything else I should describe? Hopefully you could find some time and try it out. Thank you.

I'm going to try this in a VM if I can. I'll assume that you are using the most current versions of both libpcap and tcpdump? Can you give me the exact version number of each of the packages you are using? (including bison)

I downloaded both tcpdump and libpcap from its website the version number are tcpdump-4.4.0 and libpcap-1.4.0 and the bison-2.4.1-5.e16.x86_64. Another just to update you I went to the libpcap and run this ./configure | grep error then make | grep error and make | grep error. I did not find any issue. Then I run this command whereis libpcap gave melibpcap: /usr/lib64/libpcap.so /usr/local/lib/libpcap.so /usr/local/lib/libpcap.a . I am confuse I have also run the yum install libpcap-devel how will that be effecting here?

Then I went into the tcpdump I ran this command

./configure | grep error
configure: WARNING: The SMB printer may have exploitable buffer overflows!!!
configure: error: Report this to tcpdump-workers@lists.tcpdump.org, and include the
config.log file in your report.  If you have downloaded libpcap from
tcpdump.org, and built it yourself, please also include the config.log
file from the libpcap source directory, the Makefile from the libpcap
source directory, and the output of the make process for libpcap, as
this could be a problem with the libpcap that was built, and we will
not be able to determine why this is happening, and thus will not be
able to fix it, without that information, as we have not been able to
reproduce this problem ourselves.

Next I ran this command

cat config.log | grep error
conftest.c:12:28: error: ac_nonexistent.h: No such file or directory
conftest.c:12:28: error: ac_nonexistent.h: No such file or directory
conftest.c:57:24: error: rpc/rpcent.h: No such file or directory
conftest.c:24:24: error: rpc/rpcent.h: No such file or directory
conftest.c:57:28: error: netdnet/dnetdb.h: No such file or directory
conftest.c:24:28: error: netdnet/dnetdb.h: No such file or directory
conftest.c:28:23: error: net/pfvar.h: No such file or directory
conftest.c:59:17: error: smi.h: No such file or directory
conftest.c:26:17: error: smi.h: No such file or directory
| /* Override any GCC internal prototype to avoid an error.
conftest.c:29:28: error: netdnet/dnetdb.h: No such file or directory
| /* Override any GCC internal prototype to avoid an error.
| /* Override any GCC internal prototype to avoid an error.
conftest.c:48: error: void value not ignored as it ought to be
| /* Override any GCC internal prototype to avoid an error.
| /* Override any GCC internal prototype to avoid an error.
| /* Override any GCC internal prototype to avoid an error.
configure:5848: error: Report this to tcpdump-workers@lists.tcpdump.org, and include the

It's hard to tell from what you show there. I will try and make some time to set this up over the weekend and look at what I find.

Dear L7Sqr,Thank you for the help and looking forward the results from your side.

Dear L7Sqr, Just to update you I have yet to recieve any updates from the tcpdump guys on the bug.

I could be wrong, but it looks like you are missing some developer libraries/headers required to build tcpdump.

You can probably ignore the ac_nonexistent.h error, I think that is just a test used in the configuration script to see how your build environment deals with non-existent headers. But the other errors definitely indicate that you are missing some headers, so you'll need to find and install the appropriate development packages for them using yum.

I don't use any .rpm based distros ATM, so I don't know the exact names of the packages you'll need.
On Debian based systems the dev package for rpc is called something like libtirpc-dev, netdnet is libdnet-dev and smi is libsmi-dev. You should be able to use yum to find and install the appropriate packages using 'tirpc' (or 'rpc'), 'dnet' and 'smi' as search terms.

And I'm not sure about the location of pfvar.h... I think it's a FreeBSD kernel header file. Which in debian based systems is usually in a package called something like kfreebsd-headers-{version number}.

Again, I don't use a .rpm based system, so I couldn't tell you the exact name of the package you'd need to install, but use yum to search for and install any FreeBSD header packages that are available.

Hopefully that will allow the configure step to succeed for your tcpdump build.

Dear Jason, Great and for the benefit of the rest here are the command for centos yum install libtirpc-devel , yum install libdnet-devel and yum install libsmi-devel. Only thing I could not find is the kfreebsd-headers-? I am not even able to find any .rpm file based on this too.

From taking a quick look at the Fedora package database, I think you might want to consider installing libbsd and libbsd-devel. I have a feeling that they might be the packages you are looking for! :)

Or not.... From looking inside the package, it doesn't contain that header.... Hmmm, not sure what to suggest! :/

Looks like I am stuck here cause I have email the tcpdump guys no reply either. Lets wait if L7Sqr have any solution or idea to this problem either.

Unfortunately, I was not able to dedicate any time to this over the weekend. I'm no closer to a solution at this point.

Is it possible for you to set up an Ubuntu VM and do things that way? With Ubuntu you may have less problems and since you are only really interested in tracing how the code flows you dont need to worry about final platform details.

Dear L7Sqr, Let me download the iso for ubuntu first and then get back to you on that. Thank you for the help.

I've just had another thought about the config errors issue. As pfvar.h is a header for the BSD kernel, I am wondering if this header only applies to the BSD port of tcpdump. So perhaps if the configure script finds pfvar, it will realise that it is a BSD build or something.

Now that you've installed the other missing libraries, does configure succeed despite the error message about pfvar? Or does it completely fail? If it succeeds, you should be able to go ahead and build the program.

Below is how my ./configure output looks like .

 ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking gcc version... 4
checking for inline... inline
checking for __attribute__... yes
checking whether __attribute__((format)) can be applied to function pointers... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking rpc/rpc.h usability... yes
checking rpc/rpc.h presence... yes
checking for rpc/rpc.h... yes
checking rpc/rpcent.h usability... no
checking rpc/rpcent.h presence... no
checking for rpc/rpcent.h... no
checking netdnet/dnetdb.h usability... no
checking netdnet/dnetdb.h presence... no
checking for netdnet/dnetdb.h... no
checking for net/pfvar.h... no
checking for netinet/if_ether.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking Linux kernel version... 2
checking smi.h usability... yes
checking smi.h presence... yes
checking for smi.h... yes
checking for smiInit in -lsmi... yes
checking whether to enable libsmi... yes
checking whether to enable the possibly-buggy SMB printer... yes
configure: WARNING: The SMB printer may have exploitable buffer overflows!!!
checking whether to drop root privileges by default... no
checking whether to chroot... no
checking whether to enable ipv6... yes
checking ipv6 stack type... linux-glibc
checking for library containing getaddrinfo... none required
checking getaddrinfo bug... good
checking for getnameinfo... yes
checking for dnet_htoa declaration in netdnet/dnetdb.h... no
checking for addrinfo... yes
checking for NI_MAXSERV... yes
checking for NI_NAMEREQD... yes
checking for sockaddr_storage... yes
checking for vfprintf... yes
checking for strcasecmp... yes
checking for strlcat... no
checking for strlcpy... no
checking for strdup... yes
checking for strsep... yes
checking for fork... yes
checking for vfork... yes
checking for strftime... yes
checking for setlinebuf... yes
checking for alarm... yes
checking for vsnprintf... yes
checking for snprintf... yes
checking return type of signal handlers... void
checking for sigaction... yes
checking for library containing dnet_htoa... no
checking for main in -lrpc... no
checking for library containing getrpcbynumber... none required
checking for library containing gethostbyname... none required
checking for library containing socket... none required
checking for library containing putmsg... none required
checking for local pcap library... ./../libpcap-1.4.0/libpcap.a
checking for pcap-config... ./../libpcap-1.4.0/pcap-config
checking for pcap_loop... no
configure: error: Report this to tcpdump-workers@lists.tcpdump.org, and include the
config.log file in your report.  If you have downloaded libpcap from
tcpdump.org, and built it yourself, please also include the config.log
file from the libpcap source directory, the Makefile from the libpcap
source directory, and the output of the make process for libpcap, as
this could be a problem with the libpcap that was built, and we will
not be able to determine why this is happening, and thus will not be
able to fix it, without that information, as we have not been able to
reproduce this problem ourselves.

DearL7Sqr, Ok finally I have setup a virtual machine with ubuntu and just did all it works smoothly. So back to my original problem. I want to do tracing now. If say I put printft each time I must make and make install or also need to configure first?

You should just be able to do a make and make install.

I have been working now by inserting the prinft then make and make install. You suggested to put this export CFLAGS=-ggdb . So I should put type this then type ./configure and make and make install. How will this be helpful in the tracing?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.