Re: [tcpdump-workers] Devices and adresses in libpcap
Thanks Guy. By the way: Have you had a look at libpcap++? The web page is: http://libpcappp.sourceforge.net/ Your opinion would be specially appreciated. Anyway, thanks for the help. Cheers, ~David 2008/4/12, Guy Harris [EMAIL PROTECTED]: David Rosal wrote: As far as I know, each network interface (for example eth0), can have different adresses, because in pcap_findalldevs(), a pcap_if_t does not hold a single pcap_addr_t but a linked list of all addresses for each interface/device. Yes, it can have multiple addresses, and, yes, pcap_findalldevs() returns all of the ones it can get. But pcap_lookupnet() only returns one address for a given device. Yes, it returns only one address. So the question is: If pcap_lookupnet() only returns one address (and its netmask), does it mean that it discards all the other addresses for that device? Yes, it discards any other addresses for the interface. On UN*X, it returns the IP address and mask you get from an SIOCGIFADDR and SIOCGIFNETMASK ioctl, which is probably the first of the IP addresses; on Windows, it gets the entire set of address/mask pairs and returns only the first one. - 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.
Re: [tcpdump-workers] Devices and adresses in libpcap
2008/4/13, Giovanni Venturi [EMAIL PROTECTED]:
You should add on the website what libpcap++ has in addition to libpcap in
details,
Giovanni
Well, libpcap++ is only a wrapper, and it does not add any new feature to
libpcap, except maybe the abbility to retrieve some attributes of pcap
descriptors that are hidden in libpcap.
In other words: all you can do with libpcap can be done with libpcap++, but
with less lines of code, and in a cleaner and safer way.
Here's a little program that captures the first 10 TCP packets seen on
interface wlan1, and writes them in a savefile called out. With error
checking, of course.
First the C version:
8-
#include pcap.h
static void handler(u_char *user, const struct pcap_pkthdr *header, const
u_char *datap)
{
pcap_dump(user, header, datap);
}
int main()
{
pcap_t* pcap;
pcap_dumper_t* dumper;
struct bpf_program bpf;
char ebuf[PCAP_ERRBUF_SIZE + 1];
if (!(pcap = pcap_open_live(wlan1, 64, 1, 0, ebuf)))
errx(pcap_open_live(): %s, ebuf);
if (pcap_compile(pcap, bpf, tcp, 0, 0) 0)
errx(pcap_compile(): %s, pcap_geterr(pcap));
if (pcap_setfilter(pcap, bpf) 0)
errx(pcap_setfilter(): %s, pcap_geterr(pcap));
pcap_freecode(bpf);
if (!(dumper = pcap_dump_open(pcap, out)))
errx(pcap_dump_open(): %s, pcap_geterr(pcap));
if (pcap_loop(pcap, 10, handler, (u_char *)dumper) 0)
errx(pcap_loop(): %s, pcap_geterr(pcap));
pcap_close(pcap);
pcap_dump_close(dumper);
}
---8
Now the C++ version:
8
#include pcap++.h
#include iostream
using namespace pcappp;
void handler(Pcap pcap, Packet const pkt)
{
pcap.get_dumper().dump(pkt);
}
int main()
{
try {
PcapLive pcap(wlan1);
pcap.set_filter(tcp);
pcap.get_dumper().open(out);
pcap.loop(handler, 10);
}
catch (Exception x) {
std::cerr x.what() std::endl;
}
}
--8
What do you think?
I personally prefer the C++ code, since it is more brief and clear. And the
performance should be almost the same, as critical methods like
Pcap::get_dumper() have been inlined in libpcap++.
BTW: Thanks for your comment. I hace found a bug in Pcap::set_filter() while
writing the above snippets :-P
Cheers,
~David
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Devices and adresses in libpcap
Hello. Let me present myself: I am David Rosal, from Barcelona. I have written a C++ wrapper for libpcap, called libpcap++. I have implemented almost all pcap functions in the library, and now I am trying to implement pcap_lookupnet(). But after reading the pcap man page carefully, there's still something that I don't understand: As far as I know, each network interface (for example eth0), can have different adresses, because in pcap_findalldevs(), a pcap_if_t does not hold a single pcap_addr_t but a linked list of all addresses for each interface/device. But pcap_lookupnet() only returns one address for a given device. So the question is: If pcap_lookupnet() only returns one address (and its netmask), does it mean that it discards all the other addresses for that device? Or does the addresses field of a pcap_if_t hold always only one pcap_addr_t? Well, I hope you'll understand what I am trying to say, despite my poor english. Thanks in advance for any help. And if you want to take a look at the code of libpcap++ please browse the SVN repository as it is under rapid development. Cheers. ~David - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] regarding offset IP packet
[EMAIL PROTECTED] wrote: Hi guys, I am trying to print offset value for IP packet through this code. printf(%d|,ippkt-ip_off); I am not getting the right value, what's missing. ip_off is an u_short, so byte order issues apply. Try this: printf(%d|, ntohs(ippkt-ip_off)); __david - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_loop() not returning after
Richard Hansen wrote: If pcap_breakloop() is called in a signal handler, and the signal in question isn't set up to restart system calls, that should let the loop terminate cleanly. If it's not called in a signal handler, i.e. if there's no signal that was delivered to the process, that won't help. Can I send a signal myself to get it to terminate cleanly? If so, is there a good reference for how to do this? (Sorry, I'm new to C and *nix programming and I don't know much about signals.) The function raise() sends a signal to the own process. Type man raise for more information. __david - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Problems with libpcap and C++
Hello.
I'm writing a packet sniffer in C++ using libpcap-0.9.4.
I've tried to use a class function member as a callback for
pcap_loop(), but the compiler complains that arguments don't
match. The code is something like this (I have simplified it):
8-
class X
{
public:
// This is the callback, defined below
void dumper(u_char *u, const struct pcap_pkthdr *h,
const u_char *p);
};
void X::dumper(u_char *u, const struct pcap_pkthdr *h, const
u_char *p)
{
// stuff...
pcap_dump(blah, blah, blah);
}
int main()
{
X x;
// Open pcap, etc...
pcap_loop(p, -1, x.dumper, 0);
}
-8
And g++ says this:
In function `int main()':
sniffer.cc:645: error: argument of type `void (X::)(u_char*,
const pcap_pkthdr*, const u_char*)' does not match `void
(*)(u_char*, const pcap_pkthdr*, const u_char*)'
This is not a warning but an error, so I cannot compile the program.
Is there any trick to fix this? Am I missing something?
Should I avoid C++ and use C instead (don't say that please...)
Thanks.
__david
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Problems with libpcap and C++
Ury Segal wrote: The buttom of the problem is this: You excpect libpcap to call X::dumper in the context of an instance of class X. (The real first parameter of X::dumper is a variable named this of the type X*.) But the libpcap API is not defining a `void (X::)(u_char*, const pcap_pkthdr*, const u_char*)' Therefore, you cannot pass a non-static member function to libpcap. You can make dumper() a static member. Yes. If I make dumper() a static member of class X, then the compiler accepts it. It works even if I use it whithin a concrete instance of X. I mean the following two ways are accepted: X x; pcap_loop(..., x.dumper, ...); pcap_loop(..., X::dumper, ...); Thanks. __david - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] packet dropping on solaris
Hello. Michele Sciuto wrote: Hello Jonathan, we are working at the same topic on a Linux Debian system. I suggest that you adjust the following kernel parameters in order to improve the number of packets captured (I don't know the equivalence in Solaris...). /proc/sys/net/core/rmem_default 409715100 bytes /proc/sys/net/core/rmem_max409715100 bytes /proc/sys/net/core/netdev_max_backlog30 pkts I found this article very useful: http://datatag.web.cern.ch/datatag/howto/tcp.html It is about How to achieve Gigabit speeds with Linux, but I think Solaris users may find it interesting as well. *David Jonathan Khoo wrote: Hi guys, I am working on a network monitoring system on solaris. Currently I am just working on the packet capturing engine and I seems to experience packet drops. After reading through the archives and goggling, I suspect that the problem may be due to insufficient buffering in the kernel. Is there any suggestions on how I can modify pcap-dlpi.c to increase the kernel buffering? - - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Changing the savefiles produces packet loss
Hello. I've been capturing heavy traffic with tcpdump. No packets are dropped except when the savefiles are rotated. I know that because I use a modified version of tcpdump-3.9.4 that prints statistics every minute. My question is, is it normal to loose packets when closing and opening the savefiles? How could I avoid that? Thanks in advance for any help. *david - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Changing the savefiles produces packet loss
David Rosal wrote: Hello. I've been capturing heavy traffic with tcpdump. No packets are dropped except when the savefiles are rotated. I know that because I use a modified version of tcpdump-3.9.4 that prints statistics every minute. My question is, is it normal to loose packets when closing and opening the savefiles? How could I avoid that? It would help if that would be any way to close the old file asynchronously, but I guess that pcap_dump_close() blocks until the savefile is closed, isn't it? *david - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Paquets smaller than 64 bytes
Gianluca Varenni wrote: The minimum ethernet frame length is 64 bytes *if* you include the FCS. Unfortunately, most of the network cards strip the FCS before the packet reaches the host, so the actual minimum frame length that you see with libpcap is actually 60 bytes. Hope it helps Yes it does. Thanks. But a question arises: If my network card is stripping the FCS (and it seems to do so), may I suppose that this is done for all packets? In other words, it is safe to add 4 bytes to the sizes of *all* captured packets to get the sizes on wire? *david - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Missing libpcap.so
Hello. I'm trying to use an application that needs to be linked dinamically against libpcap, so it needs libpacp.so to be installed. I've downloaded libpcap-0.9.3 and installed it, but it only provides the static library libpcap.a. I've tried also adding --enable-shared to configure but it didn't work. Is there any hack that I can make to get the shared object? Perhaps using an older version of libpcap? Thanks. - David - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Does option -w influence the packet capture?
Hi. I'm using tcpdump-3.7.2 to capture ethernet traffic, and I'm wondering why it captures much less packets when I use option -w. I have done the following test: I've run tcpdump -s0 many times for 10 seconds each time, and the average result is to capture about 100 packets. I've run tcpdump -s0 -w dumpfile many times for 10 seconds each time, and the average result is to capture only 70 or 80 packets. But both tests have been done in the same computer, at the same hour. Is this behaviour expected? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
