The -ggdb is helpful to allow you to get debugging symbols in a gdb debugging session. Basically, you can run the process under gdb and follow control flow that way. If you are going to proceed this way, you will probably want to use a pcap file loaded with the packets you want to trace to simplify the process.
The printf approach is applicable in either context but takes much more time.
I'd suggest that you use the gdb method if you have a choice between the two.
Dear L7Sqr, I did this firsr export CFLAGS=-ggdb then I run again ./configure followed by make and make install. I dont see any debugging output is following with the tcpdump output?
Are you running the program from within a gdb session? You should not expecct to see the debugging symbols, they are information for the debugger to better assist you in stepping through code.
Yes I tried and got this. Is this correct method based on my googling? So how to trace from here I am very new to it and try to google n study it sorry for my questions.
gdb tcpdump
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/sbin/tcpdump...done.
(gdb) run
Starting program: /usr/local/sbin/tcpdump
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
Well, as I suggested you will want to read from a pcap file - not an interface. Also, you will want to set a break point at some location you understand already (somewhere in the IP handling code, perhaps). Once you have the breakpoint, run the program. Execution will stop at the breakpoint and you can simply step through - instruction by instruction - to see where the path goes through the code.gdb allows you to print many things while executing code; you probably want at least the file and line number of the current instruction.
I have followed your instruction but look like reading the .pcap file via gdb is having problem. As below.
gdb tcpdump -r test2.pcap
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/sbin/tcpdump...expanding to full symbols...done.
"/home/ub/test2.pcap" is not a core dump: File format not recognized
Other then that I notice I need to set minimum of 2 breakpoint and from the second breakpoint when I start using the step it really trace quite well but I will need more time to grap things from here. Will update you accordingly.
The -r is being interpreted by gdb and not tcpdump. You may want to try:
gdb tcpdump
...
run -r test2.pcap
The run command will execute the loaded program with the command provided.
Yes its working now. Besides setting the 2 breakpoint and going through the step is there any other command which will be useful in my tracing. I notice like what you said its quite complicated but I will try to filter out where I can.
I find list to be a pretty helpful command in general. Other than that you will need to navigate the help menu to adjust to your comfort level. gdb is a powerful tool but it takes time to learn it fluently.
I think I will go with step even though its difficult as list prints out one short 10 line and I get lost there to where its activated? Let me play around and do some learning on my own first.
Dear L7Sqr, We what I did now is capture few single packets and I step them through. The problem is that it reaches back to main fucntion in tcpdump.c But the information is not printed so I dont know where exactly it the information being printed.
I presume that the packets include the contents you are expecting to see?
I'm not sure what you are describing. If you run tcpdump on the captured packets without running under gdb and you see output then you should see the same output when you are single stepping through the debugger. gdb does not filter output - it intermixes the program output with it's own output so it may be that you are just not noticing the lines you are expecting to see.
Do you reach the sections of code you expect to reach when single stepping through the code? You may want to check the location of the last instruction before returning to the top level loop. It will give you a starting point as to where you are while processing the packets.
@L7Sqr yes you are right its prinft during the step so at the end there is no one printf completely showing the results. How to check the location of last instruction should I best add many different breakpoints.
There wont be a 'single print at the end', that is not how gdb works. If you want to use tracer bullets (print statements throughout the code) along with a debugger you need to understand when you expect to see output.
I would set breakpoints at the deepest parts of the code that you understand. If you are familiar with where the parsing of the TCP packet happens but need to know what happens from there you place a breakpoint in the TCP parsing section of the code.
Alternatively, if you know the exact location in the code you wish to examine you place a breakpoint on that specific line. Once control flow reaches that point you get a break in execution in the debugger and can examine the packet.
Dear L7Sqr,You are rite I was expecting for a single print at the end. Yes I am still tring to understand just the TCP packet dissection because there some place some binary and shift operation involved kind of lost there but I am trying my best to learn.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.