headers
Ignacio, Domingo Jr Ostria - igndo001 | 1 Jul 2008 06:04
Picon
Picon

inquiry on variable insertion on tcpdump code

Hello everyone,

Good day!

I am using tcpdump in my linux system to sniff and capture tcp packet
headers. 

I  inserted a new variable, srtt, into  the print_tcp.h header file  and
tcp.c source code.
I want  to print/output/capture  the inserted variable srtt into  the
tcp packet headers once I run tcpdump. 
Any idea on how to go about this?

However, once I run tcpdump with all the changes I made (of course,
after configuring and making) and  I got an error:

Bad header length and <bad opt>, header length too short<20.

I tried to increase the snap length to 1514 but I still got the same
errors. What seems to be the problem, anyone? Thanks!
(Command: tcpdump tcp -nvvvs 1514 -i eth0)

Also, I cannot see the inserted srtt variable in the tcpdump trace
files. Any idea on these guys?

 Help would be appreciated.

Cheers, Dom
(Continue reading)

Permalink | Reply | 2 comments |
headers
Luis Martin | 1 Jul 2008 15:24
Picon

Article about libpcap


Hi,

A few months ago I wrote an article about libpcap for a magazine called 
Hakin9. Today I have received permission to distribute the article so 
now it is available for everyone. I have linked it from section 
"Documentation", in tcpdump web site. (I hope that's OK with everyone).

The article is titled "Programming with Libpcap - Sniffing the network 
from our own application". It only covers the basics, but It should be a 
decent introduction to pcap programming. It would be great to hear some 
opinions. Could someone have a look at it?

Thanks. Best regards,

Luis Martin.
Permalink | Reply | 0 comments |
headers
Torsten Krah | 1 Jul 2008 16:15
Picon

tcpdump -E decryption question

Hi, theres no "user" list but i hope i can post here too.
Searching the archives i found this:

http://www.tcpdump.org/lists/workers/2003/09/msg00011.html

192.1.2.23 > 192.1.2.45: ESP(spi=0x12345678,seq=0x1): 192.0.2.1 > 192.0.1.1: 
icmp: echo request (DF) (ipip-proto-4)

This should be the output when tcpdump -E ... is used, however i did not have 
any success yet, decrypting those packets.

I am using 3des with hmac_md5, so the cipher specified is: 3des-cbc-hmac96, 
right?
The "spi" which must be given is the one shown in the esp packet 
above "0x12345678".
The "addr" - i hope here the local tunnel gateway should be addressed, or what 
must addr set to, don't know really wha have to assigned  here - lets use 
192.1.2.23.
Key is my tunnel psk in ascii format for example.

Are these "assumptions" correct or is something wrong already?

tcpdump -t -n -E "0x12345678 <at> 192.1.2.23 3des-cbc-hmac96:mysecretasciikey' -r 
pcapile

This should result in some output like mentioned above, however all i get is 
the "plain" esp output (like without -E option), nothing decrypted behind and 
no error message or something.
So i guess i am not correctly using this option.
Can anyone help me how to make use of the -E parameter?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Guy Harris | 1 Jul 2008 18:58
Picon
Favicon

Re: inquiry on variable insertion on tcpdump code

Ignacio, Domingo Jr Ostria - igndo001 wrote:

> I  inserted a new variable, srtt, into  the print_tcp.h header file  and
> tcp.c source code.

(Presumably you meant "tcp.h header file and print-tcp.c source code".)

If you inserted it into the "struct tcphdr" structure, that's a mistake. 
  That structure *MUST* look like the 20-byte fixed-length portion of 
the TCP header, as specified in RFC 793, as it's used by the print-tcp.c 
code to dissect the TCP header in captured TCP packets.  There's no SRTT 
field in the TCP header, so you can't put an SRTT field into that 
structure (unless the traffic is going between two hosts whose TCP 
implementations have been modified to add such a field to the header - 
but if that's the case, those two hosts will not be able to use TCP to 
communicate with any unmodified hosts, i.e. they won't be able to use 
any TCP-based protocol with any other computers).
Permalink | Reply | 0 comments |
headers
grarpamp | 2 Jul 2008 01:32
Picon

Printing of TCP flags seems incorrect

Hi. Surely it is not possible to have both 'no flags' and
<any_other_flags> present at the same time? The man page has a few
references to the dot, particularly in the 'OUTPUT FORMAT - TCP
Packets' example near 'means no flags'.

#CVS, the most recent commit I have is: 20080624
#tcpdump version 3.9-PRE-CVS_2008_06_30
#libpcap version 0.9-PRE-CVS

./tcpdump_cvs -ns0 -i fxp0 'tcp[tcpflags] != 0' | egrep '\[[CEUAPRSF]+\.]'
... Flags [R.], ... <=== flag and no flag

#tcpdump version 3.9.8
#libpcap version 0.9.8

./tcpdump_398 -ns0 -i fxp0 'tcp[tcpflags] != 0' | egrep -v ': [CEUAPRSF.] '
... <nothing> ...

Also, shouldn't asking to print only ACK packets display the ACK
'A' instead of the 'no flags' '.' in the flag display field? I
printed them with -XX to verify the bitfield.

./tcpdump_cvs -ns0 -i fxp0 'tcp[13] == 16'
./tcpdump_398 -ns0 -i fxp0 'tcp[13] == 16'

I'm compiled against and running on the current FreeBSD RELENG_4.

Note that when using --with-crypto, I have to add -L to find
unresolved libraries. Seems that is also a bug that could be
addressed. I think it's in both CVS and 3.9.8.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Guy Harris | 2 Jul 2008 04:14
Picon
Favicon

Re: Printing of TCP flags seems incorrect


On Jul 1, 2008, at 4:32 PM, grarpamp wrote:

> Hi. Surely it is not possible to have both 'no flags' and
> <any_other_flags> present at the same time? The man page has a few
> references to the dot, particularly in the 'OUTPUT FORMAT - TCP
> Packets' example near 'means no flags'.

The man page apparently needs to be updated, as, in the current code,  
"." means ACK, and "none" means "no flags":

	revision 1.127
	date: 2007-01-29 01:59:42 -0800;  author: hannes;  state: Exp;   
lines: +626 -63$
	change the TCP printer to print new-style order:
	  - seperate fields by comma
	  - use [] for flags and options sets
	  - print a trailing length field

	make use of tok2str() and bitttok2str()
	move port definitions into tcp.h
Permalink | Reply | 5 comments |
headers
grarpamp | 3 Jul 2008 05:01
Picon

Re: Printing of TCP flags seems incorrect

Hi. I think I've found this 'none' printf you speak of. However it
does not appear to be excercised from what I can tell. Not sure
about that.

However as this code is still in flux [unreleased] and possibly
amenable to the influence of sanity, I would like to suggest that
the flags field be kept letter consistant with the bitfield...

If I receive a packet with ALL bits set I'd like to see:

flags: [NCEUAPRSF]

If I receive a packet with NO bits set I'd like to see:

# in order of preference
flags: []     obvious
flags: [.]    may be easier to parse as a none indicator,
               looks like the flags are physically squashed

If I receive a packet with undefined bits set it may make sense to
print:

flags: [undef] no longer a bitfield

Though the utility of printing that case is pretty slim.

# struct tok tcp_flag_values[]
This seems to define what is currently printed. In keeping with rfc
793/3168/3540, it seems they should all use the first character of
the definition. Resulting in: NCEUAPRSF
(Continue reading)

Permalink | Reply | 4 comments |
headers
grarpamp | 3 Jul 2008 07:35
Picon

Re: Printing of TCP flags seems incorrect

Hi. Patch inline. I conformed the naming to the RFC's and maintained
the bitfield order in the man pages. No doubt I missed some parts.
The "Nonce Sum" bit was left out as it is still experimental, not
standards track. Compiles clean and seems to work. Enjoy.

FYI, tcpreplay has problems installing its man page because the
directory for it is not created by the makefile.

========================================
--- libpcap/pcap-filter.4.orig  Thu May 29 21:35:33 2008
+++ libpcap/pcap-filter.4       Thu Jul  3 00:46:37 2008
 <at>  <at>  -768,9 +768,15  <at>  <at> 
 \fBicmp-tstampreply\fP, \fBicmp-ireq\fP, \fBicmp-ireqreply\fP,
 \fBicmp-maskreq\fP, \fBicmp-maskreply\fP.

-The following TCP flags field values are available: \fBtcp-fin\fP,
-\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP,
-\fBtcp-ack\fP, \fBtcp-urg\fP.
+The following TCP flags field values are available:
+\fBtcp-cwr\fP,
+\fBtcp-ece\fP,
+\fBtcp-urg\fP,
+\fBtcp-ack\fP,
+\fBtcp-psh\fP,
+\fBtcp-rst\fP,
+\fBtcp-syn\fP,
+\fBtcp-fin\fP.
 .LP
 Primitives may be combined using:
 .IP
(Continue reading)

Permalink | Reply | 1 comment |
headers
Guy Harris | 3 Jul 2008 18:19
Picon
Favicon

Re: Printing of TCP flags seems incorrect

grarpamp wrote:
> Hi. I think I've found this 'none' printf you speak of.

More precisely it's a "none" argument passed to bittok2str_nosep() plus the

         else {
             /* bummer - lets print the "unknown" message as advised in 
the fmt string if we got one */
             if (fmt == NULL)
                 fmt = "#%d";
             (void)snprintf(buf, sizeof(buf), fmt, v);
             return (buf);
         }

code at the end of bittok2str_internal().

> However it
> does not appear to be excercised from what I can tell. Not sure
> about that.

To quote RFC 793:

Acknowledgment Number:  32 bits

     If the ACK control bit is set this field contains the value of the
     next sequence number the sender of the segment is expecting to
     receive.  Once a connection is established this is always sent.

so, once a connection is established, there should not be any packets 
with no flags set.  The packets used to establish the connection have
(Continue reading)

Permalink | Reply | 1 comment |
headers
Guy Harris | 3 Jul 2008 18:41
Picon
Favicon

Re: Printing of TCP flags seems incorrect

grarpamp wrote:
> Hi. Patch inline. I conformed the naming to the RFC's

I assume by "naming" you are referring not only to the bits used to 
print the flags in tcpdump but also the flag values used in libpcap for 
filters.

Perhaps a name using the "psh" abbreviation used by RFC 793 for the 
"push" flag, namely "tcp-psh", should be *one of* the names allowed for 
that flag, but the name for that flag supported by libpcap going back at 
least as far as libpcap 0.7 and documented in the tcpdump man page going 
back at least as far as tcpdump 3.7, namely "tcp-push", should also be 
allowed, because people might already have filters using "tcp-push".

> FYI, tcpreplay has problems installing its man page because the
> directory for it is not created by the makefile.

FYI, tcpreplay is not distributed or maintained by tcpdump.org, so 
there's nothing tcpdump.org should do about that.  The libpcap makefile 
creates the $(DESTDIR)$(mandir)/man3 directory - and the 
$(DESTDIR)$(mandir)/man4 directory, in the top-of-tree CVS version of 
libpcap - so it creates all the directories in which it installs its man 
page in current releases and its man pages in the top-of-tree CVS 
version, and the tcpdump makefile creates the $(DESTDIR)$(mandir)/man1 
directory, so it creates all the directories in which it installs its 
man page.  If tcpreplay's Makefile doesn't create target directories for 
*its* man pages before trying to install them, that's a tcpreplay bug, 
and is probably best reported at

	http://tcpreplay.synfin.net/trac/newticket
(Continue reading)

Permalink | Reply | 0 comments |

Gmane