Re: [tcpdump-workers] timestamp in Packet Data

[Sanjay Sundaresan]

Is the approximation because of the fact that NIC card generarates interrupt
only after some number of packets arrive ?. Does device polling affect time
stamp ? At what stage of capture time stamping is done ?

On Sat, Jul 9, 2011 at 6:59 PM, Alokat  wrote:

> On 07/09/11 21:56, Guy Harris wrote:
> > On Jul 9, 2011, at 4:41 PM, Alokat wrote:
> >
> >> I'm wondering what is in the pcap_data (pcap file format) and what is
> not?
> >> Especially the timestamp ... is it just in the packet_header or in the
> >> packet_data too?
> > A pcap file starts with a header.  Following the header are zero or more
> packet records.  A packet record has a header, which includes the packet
> time stamp, followed by packet data, which is just the raw data as supplied
> to libpcap/WinPcap by whatever mechanism it uses.  That mechanism supplies
> the packet time stamp for inclusion in the header, so there is no reason to
> expect that it will also be in the packet data, especially given that no
> link layers would include that time stamp (it's not in an Ethernet header,
> for example), so the time stamp is just in the packet header, not the packet
> data.
> >
> > The time stamp is an approximation of the time when the packet was
> received by the machine that captured it.-
> > This is the tcpdump-workers list.
> > Visit https://cod.sandelman.ca/ to unsubscribe.
> Okay,
>
> Thanks for your answer ...
>
> Regards,
> alokat
> -
> 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.

[tcpdump-workers] autoconf and patches

[Michael Richardson]

Just a general  comment about patches:
  - try not to include "configure" in your patch. From a developer
point of view, this is a generated file, and any patch it generally
big and irrelevant, and just confuses people reading your patch
for actual information.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] rpcap support?

[Michael Richardson]

> "Joerg" == Joerg Mayer  writes:
Joerg> for the equipment to come back to do a real test...  The
Joerg> patch can be downloaded from:
Joerg> http://www-agrw.informatik.uni-kl.de/home/jmayer/rpcap.v2.patch

Joerg> I'd really like to receive some feedback on this.

Up until somewhat recently, pcap methods were basically decided at
compile time based upon the OS that one was on.  There was little in the
way of decisions in the code as to what was going to go on.

We now have half-dozen methods on Linux (if you include pfring, etc.),
I think two or three on Solaris, and now every system will grow the
"remote" method.

Can we make it a bit more oop-ish with a few more pointer to functions
in pcap_t rather than if(p->rmt_clientside) everywhere?

It's also time for pcapng, which is supposed to be file format only.
It would be nice if the wire protocol for remote pcap was in fact remote
pcapng.  

The question is now:
  is reading remote pcapng a job of *PCAP* (the library that acquires
  packets from the network interface) 

  or a job of pcapng (the library that reads/writes files to "storage")?

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] pcap_data vs payload

[Alokat]

On 07/10/11 00:53, Guy Harris wrote:
> On Jul 9, 2011, at 7:50 PM, Alokat wrote:
>
>> Just for sure:
>>
>> *Ethernet packet*
>>
>> means a layer 2 (OSI / ISO model) packet right?
> Yes.
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
Thanks for the answer,

just one more question.
If I just wanna get the data without the layer 2 stuff can I use
something like this:

payload = (u_char *)(packet + size_ip + size_tcp);

I do only need the data from layers 3 - 7.

Regards,
alokat

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

Re: [tcpdump-workers] pcap_data vs payload

[Luis MartinGarcia.]

On 07/10/2011 05:10 PM, Alokat wrote:
> On 07/10/11 00:53, Guy Harris wrote:
>> On Jul 9, 2011, at 7:50 PM, Alokat wrote:
>>
>>> Just for sure:
>>>
>>> *Ethernet packet*
>>>
>>> means a layer 2 (OSI / ISO model) packet right?
>> Yes.
>> -
>> This is the tcpdump-workers list.
>> Visit https://cod.sandelman.ca/ to unsubscribe.
> Thanks for the answer,
>
> just one more question.
> If I just wanna get the data without the layer 2 stuff can I use
> something like this:
>
> payload = (u_char *)(packet + size_ip + size_tcp);
>
> I do only need the data from layers 3 - 7.

No, that is not correct. You need to determine which link layer protocol
is being used (the DLT). If it is an Ethernet network, you can strip the
ethernet header doing:

payload=packet + 14

where 14 is the length of the Ethernet header. If you are not on an
ethernet network, you have to replace that 14 with the appropriate
length of the link headers.

Regards,

Luis.

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

Re: [tcpdump-workers] autoconf and patches

[Jakub Zawadzki]

On Sat, Jul 09, 2011 at 10:37:55PM -0400, Michael Richardson wrote:
> Just a general  comment about patches:
>   - try not to include "configure" in your patch. From a developer
> point of view, this is a generated file, and any patch it generally
> big and irrelevant, and just confuses people reading your patch
> for actual information.

So maybe it should be added to .gitignore?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] autoconf and patches

[Guy Harris]

On Jul 10, 2011, at 9:16 AM, Jakub Zawadzki wrote:

> On Sat, Jul 09, 2011 at 10:37:55PM -0400, Michael Richardson wrote:
>> Just a general  comment about patches:
>>  - try not to include "configure" in your patch. From a developer
>>point of view, this is a generated file, and any patch it generally
>>big and irrelevant, and just confuses people reading your patch
>>for actual information.
> 
> So maybe it should be added to .gitignore?

...or removed from Git?  Wireshark doesn't put the automake-generated or 
autoconf-generated files into SVN; this means that if you're building from SVN, 
you need to run a script to generate those files, and that the process of 
building a release source tarball needs to generate the files before making the 
tarball, but it means that patches are less likely to include changes to the 
generated files, and that people who check in a change to configure.in or 
aclocal.m4 don't need to remember to regenerate the configure script (I've 
forgotten to do that on occasion).

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

Re: [tcpdump-workers] rpcap support?

[Jakub Zawadzki]

Hi,

On Sat, Jul 09, 2011 at 02:36:50PM +0200, Joerg Mayer wrote:
> I've created a patch that actually manages to build into an rpm on my
> opensuse system. Wireshark HEAD also detects rpcap support when buiding with
> cmake. Now all I have to do is wait for the equipment to come back to
> do a real test...
> The patch can be downloaded from:
> http://www-agrw.informatik.uni-kl.de/home/jmayer/rpcap.v2.patch
> 
> I'd really like to receive some feedback on this.

This patch is missing all new files like: pcap-remote.[ch],
sockutils.[ch] or pcap/remote-ext.h

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

[tcpdump-workers] tcpdump and BPF filters

[Geoffrey Sisson]

Is there any way to use BPF filters directly from tcpdump, i.e., supply
tcpdump with a filter in BPF psuedo-machine format?  I had a cursory
look at the code and couldn't find any obvious way to do this.  What I'd
like to be able to do is supply a BPF filter in bpf_insn struct format, e.g.:

# cat filter.txt
0x28 0 0 12
0x15 0 8 0x0800
0x30 0 0 23
0x15 0 6 17
0x28 0 0 20
0x45 4 0 0x1fff
0xb1 0 0 14
0x48 0 0 16
0x15 0 1 123
0x06 0 0 0x
0x06 0 0 0

# tcpdump -n -s 0 -F filter.txt

(It would be even better to be able to use McCanne and Jacobsons's
assembler syntax -- like what's returned by bpf_image() in libpcap --
but I realize this would probably involve writing another compiler.)

Apologies if this has been asked before.

Geoff


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

Re: [tcpdump-workers] tcpdump and BPF filters

[Guy Harris]

On Jul 10, 2011, at 11:07 AM, Geoffrey Sisson wrote:

> Is there any way to use BPF filters directly from tcpdump, i.e., supply
> tcpdump with a filter in BPF psuedo-machine format?

No, there isn't.

What are you trying to do?  If it's a type of test that the filter language 
doesn't support, the filter language should perhaps be extended to support it.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] tcpdump and BPF filters

[Geoffrey Sisson]

Guy Harris  wrote:

> What are you trying to do?  If it's a type of test that the filter
> language doesn't support, the filter language should perhaps be extended
> to support it.

It's for walking through some variable-length fields, and involves
iteratively using values in the packet as offsets for successive loads.

. . .
BPF_STMT(BPF_LD + BPF_B + BPF_IND, 0),
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 0, 34, 0),
BPF_STMT(BPF_ALU + BPF_ADD + BPF_X, 0),
BPF_STMT(BPF_ALU + BPF_ADD + BPF_K, 1),
BPF_STMT(BPF_MISC + BPF_TAX, 0),
BPF_STMT(BPF_LD + BPF_B + BPF_IND, 0),
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 0, 20, 0),
BPF_STMT(BPF_ALU + BPF_ADD + BPF_X, 0),
BPF_STMT(BPF_ALU + BPF_ADD + BPF_K, 1),
BPF_STMT(BPF_MISC + BPF_TAX, 0),
BPF_STMT(BPF_LD + BPF_B + BPF_IND, 0),
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 0, 15, 0),
. . .

I don't think the filter language supports it, and my initial sense
is that it would be hard to extend it to do this.

Geoff


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

Re: [tcpdump-workers] tcpdump and BPF filters

[Guy Harris]

On Jul 10, 2011, at 12:11 PM, Geoffrey Sisson wrote:

> It's for walking through some variable-length fields, and involves
> iteratively using values in the packet as offsets for successive loads.

...

> I don't think the filter language supports it,

The filter language is generally fairly high-level, but it does have the  
  expressions, and each  is [:], so you 
can use the result of an expression as the offset in another expression.

> and my initial sense is that it would be hard to extend it to do this.

There are definitely places where the code generated for expressions uses 
values in the packet as offsets; even if you ignore the variable-length IP 
header, there is, for example, the variable-length 802.11 header, as well as 
the variable-length radio metadata headers that can precede the 802.11 header.

What sort of variable-length fields are you processing?-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] rpcap support?

[Guy Harris]

On Jul 9, 2011, at 7:43 PM, Michael Richardson wrote:

> Up until somewhat recently, pcap methods were basically decided at
> compile time based upon the OS that one was on.  There was little in the
> way of decisions in the code as to what was going to go on.
> 
> We now have half-dozen methods on Linux (if you include pfring, etc.),
> I think two or three on Solaris, and now every system will grow the
> "remote" method.
> 
> Can we make it a bit more oop-ish with a few more pointer to functions
> in pcap_t rather than if(p->rmt_clientside) everywhere?

Yes, that's how it should be done, especially given that we should not restrict 
ourselves to rpcap - one possible remote capture protocol is "run tcpdump over 
ssh", for example.

In addition, it should use the new pcap_create()/pcap_{modify various 
parameters}/pcap_activate() model, so that setting things such as credentials 
is done between pcap_create() and pcap_activate() (although in some cases you 
might not know what authentication information is needed until you try 
authenticating - consider ssh-based protocols, for example).

I'm working on a version of the remote capture stuff that works that way.

> It's also time for pcapng, which is supposed to be file format only.
> It would be nice if the wire protocol for remote pcap was in fact remote
> pcapng.
> 
> The question is now:
>  is reading remote pcapng a job of *PCAP* (the library that acquires
>  packets from the network interface) 
> 
>  or a job of pcapng (the library that reads/writes files to "storage")?

For historical reasons, the pcap library also supports reading from and writing 
to savefiles.  If we split them, with a new library supporting reading from and 
writing to savefiles, the new library should transparently support reading from 
pcap files as well as pcap-ng files (just as the pcap library now supports 
transparently reading from some pcap-ng files as well as from pcap files), and 
perhaps from other file formats as well (Sniffer formats, Microsoft Network 
Monitor, etc.; I have some code I did a long time ago to do that, although if 
we have a new library with a more pcap-ng-oriented API, it'd have to be changed 
to handle that).  It should perhaps support writing, at minimum, pcap (when 
possible) as well as pcap-ng, and perhaps some other formats as well.

(Unlike Wireshark's wiretap library, this library needs to support reading from 
pipes, so it might be restricted to capture file formats that have magic 
numbers early in the file.)

I'd say that the same APIs should be used for capturing from local and remote 
interfaces, so programs can take "en0" or "eth0" or "fxp0" or whatever as 
arguments to capture from a local device or "rpcap://example.com/en0" (at least 
until example.com has to replace their Xserves :-)) or 
"tcpdump+ssh://example.com/eth0" or... as arguments to capture from a remote 
device.

In addition, the capture APIs should probably expand to support stuff useful 
for pcap-ng; that will also add other capabilities, e.g. a pcap_stats() 
replacement that returns something like an Interface Statistics Block could 
omit statistics that aren't supported by the platform (rather than sticking 
bogus values into a fixed structure) and could add new statistics, and a 
pcap_findalldevs() replacement that returns, for each interface, something like 
an Interface Description Block could supply the link-layer address and other 
attributes not currently provided.

So perhaps there should still be one library for live capture (local and 
remote) and savefile reading and writing.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] tcpdump and BPF filters

[Geoffrey Sisson]

Guy Harris  wrote:

> What sort of variable-length fields are you processing?-

Labels in the wire representation of a domain name.

>From RFC 1035:

   Domain names in messages are expressed in terms of a sequence
   of labels.  Each label is represented as a one octet length field
   followed by that number of octets.  Since every domain name ends with
   the null label of the root, a domain name is terminated by a length
   byte of zero.

> The filter language is generally fairly high-level, but it does
> have theexpressions, and each  is
> [:], so you can use the result of an expression as
> the offset in another expression.
>
> There are definitely places where the code generated for expressions
> uses values in the packet as offsets; even if you ignore the
> variable-length IP header, there is, for example, the variable-length
> 802.11 header, as well as the variable-length radio metadata headers
> that can precede the 802.11 header.

The catch is that domain names comprise a variable number of
variable-length fields.  Examples of valid sequences:

   +---+---+---+---+---+---+---+---+---+---+---+---+---+
   |007| t | c | p | d | u | m | p |003| o | r | g |000|
   +---+---+---+---+---+---+---+---+---+---+---+---+---+

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |003| w | w | w |003| f | o | o |002| c | o |002| u | k |000|
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   +---+---+---+---+---+
   |003| e | d | u |000|
   +---+---+---+---+---+

   +---+
   |000|
   +---+

   (XXX = numeric field length, X = ASCII data)

It's not as simple as finding the first octet with a value of zero,
as this is a valid sequence:

   +---+---+---+---+---+---+---+---+---+
   |003| f |000| o |003| b |000| r |000|= f\000o.b\000r.
   +---+---+---+---+---+---+---+---+---+

Geoff

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