[tcpdump-workers] Books on pcap library

2004-12-09 Thread aman Reddy
Hi All, Does anyone know any books on pcap and implementation of each and every function in the library. please provide some free links avaiable in the internet for the tutorial in capturing packet using pcap library. Aman. - Do you Yahoo!?

Re: [tcpdump-workers] some problem in the source code

2004-12-09 Thread aman Reddy
Hi Robert, So nice of u for replying. As I am novice to this field, please can u guide me where I can get the information related to write extra logic in my program to deal with each possible link layer. Please give me the starting step. with regards, Aman.

Re: [tcpdump-workers] some problem in the source code

2004-12-09 Thread aman Reddy
Hi Peter, But one thing I didn`t understand is If I keep any as the first argument to the pcap_open_live() then it will capture packets coming from the devices like etho or eth1 which are ethernet type. U mean if I capture packet using eth0 interface then I will get ethernet link layer

[tcpdump-workers] request for new type

2004-12-09 Thread Dumas Hwang
Hi! I would like to request two new link layer types for Generic Framing Procedure (DLT_GFP_T and DLT_GFP_F). Thank you. Regards, Dumas Hwang - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] some problem in the source code

2004-12-09 Thread Peter Sandford
Hi again, Any will return a header of type DLT_LINUX_SLL. It's defined here: (From the man page) --- DLT_LINUX_SLL Linux cooked capture encapsulation; the link layer header contains, in order: a 2-byte packet type, in network byte order, which is one

Re: [tcpdump-workers] request for new type

2004-12-09 Thread Guy Harris
Dumas Hwang wrote: I would like to request two new link layer types for Generic Framing Procedure (DLT_GFP_T and DLT_GFP_F). Thank you. OK, DLT_GPF_T is 170 and DLT_GPF_F is 171. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.

[tcpdump-workers] nanosecond timestamp

2004-12-09 Thread Dumas Hwang
Hi! I would like to get nanosecond resolution on Solaris in libpcap. What's the best way to go about it? I suppose it's not a good idea to change struct timeval ts in pkthdr to timespec. Should I add a new struct and request a new magic number? I would think many people need

[tcpdump-workers] Usage of pcap_open_live argument to_ms

2004-12-09 Thread Robert Lowe
Hi! Regarding the to_ms argument to pcap_open_live, the pcap manpage says: -- to_ms specifies the read timeout in milliseconds. The read timeout is used to arrange that the read not necessarily return immediately when a packet is seen, but that it wait for some amount of time to allow more packets

Re: [tcpdump-workers] nanosecond timestamp

2004-12-09 Thread Guy Harris
On Dec 9, 2004, at 12:48 PM, Dumas Hwang wrote: I would like to get nanosecond resolution on Solaris in libpcap. What's the best way to go about it? I suppose it's not a good idea to change struct timeval ts in pkthdr to timespec. That would be an amazingly bad idea (and it was an

Re: [tcpdump-workers] nanosecond timestamp

2004-12-09 Thread Guy Harris
On Dec 9, 2004, at 12:48 PM, Dumas Hwang wrote: I would like to get nanosecond resolution on Solaris in libpcap. BTW, where are you getting the nanosecond-resolution time stamps in Solaris? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] Usage of pcap_open_live argument to_ms

2004-12-09 Thread Guy Harris
On Dec 9, 2004, at 1:09 PM, Robert Lowe wrote: to_ms specifies the read timeout in milliseconds. The read timeout is used to arrange that the read not necessarily return immediately when a packet is seen, but that it wait for some amount of time to allow more packets to arrive and to read multiple

Re: [tcpdump-workers] nanosecond timestamp

2004-12-09 Thread rick jones
BTW, where are you getting the nanosecond-resolution time stamps in Solaris? gethrtime there is such a thing in some of the other OSes as well - netperf will use it for -DHISTOGRAM because it typically is lower overhead. however, my recollection of the manpages is that it is only good for

Re: [tcpdump-workers] nanosecond timestamp

2004-12-09 Thread Darren Reed
In some email I received from rick jones, sie wrote: BTW, where are you getting the nanosecond-resolution time stamps in Solaris? gethrtime there is such a thing in some of the other OSes as well - netperf will use it for -DHISTOGRAM because it typically is lower overhead. however,

Re: [tcpdump-workers] nanosecond timestamp

2004-12-09 Thread Guy Harris
On Dec 9, 2004, at 2:08 PM, Darren Reed wrote: In some email I received from Guy Harris, sie wrote: BTW, where are you getting the nanosecond-resolution time stamps in Solaris? gethrtime That says what the high-resolution time counter's value is now, not what the value was when bufmod saw the

Re: [tcpdump-workers] nanosecond timestamp

2004-12-09 Thread Darren Reed
In some email I received from Guy Harris, sie wrote: On Dec 9, 2004, at 2:08 PM, Darren Reed wrote: In some email I received from Guy Harris, sie wrote: BTW, where are you getting the nanosecond-resolution time stamps in Solaris? gethrtime That says what the high-resolution time

Re: [tcpdump-workers] Usage of pcap_open_live argument to_ms

2004-12-09 Thread Robert Lowe
Guy Harris wrote: On Dec 9, 2004, at 1:09 PM, Robert Lowe wrote: to_ms specifies the read timeout in milliseconds. The read timeout is used to arrange that the read not necessarily return immediately when a packet is seen, but that it wait for some amount of time to allow more packets to arrive

Re: [tcpdump-workers] nanosecond timestamp

2004-12-09 Thread Guy Harris
On Dec 9, 2004, at 3:23 PM, Darren Reed wrote: So what am I trying to say here? Unless you have hardware timestamps in captured packets, one software timestamp is as good as the next in a well written application. ...or as bad as the next. If you want absolute time stamps, nanosecond resolution

Re: [tcpdump-workers] nanosecond timestamp

2004-12-09 Thread Alexander Dupuy
...the time stamps you get out of libpcap might have nanosecond *precision* but they might not have nanosecond *accuracy*) - So what am I trying to say here? Unless you have hardware timestamps in captured packets, one software timestamp is as good as the next in a well written application. If