Re: [tcpdump-workers] [PATCH]: [DCCP]: support for variable-length checksums

2006-10-30 Thread Ian McDonald

On 10/31/06, Gerrit Renker [EMAIL PROTECTED] wrote:

This introduces support for variable-length checksum in
DCCP, as it is specified in section 9 of RFC 4340.

Previously tcpdump was only able to validate full-coverage
checksums, this patch verifies checksums in accordance with
the CsCov header field (sec. 5.3).

The patch has been tested and verified on DCCPv4 and DCCPv6
connections, checksums were manually validated, and traces
can be supplied.



In addition, the patch also
* removes reduplicated code in dccp6_cksum (which
  just repeated the code of in_cksum)
* fixes a bug in dccp.h -- the fields of CCVAL and
  CSCOV were swapped (cf. section 5.1 of RFC 4340)
* fixes a typo in the display of incorrect checksums
  (these were printed as `cksum xDEAD (incorrect (-  xBEEF)',
   it now will print  `cksum xDEAD (incorrect - xBEEF)'

I would like to see this merged as a Linux kernel patch already
exists for DCCP partial checksum coverage support.


I would agree with this going ahead and in particular I remember the
CCVAL bug and then forgetting to fix it...

--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.


Re: [tcpdump-workers] HTTP support in libpcap

2006-10-29 Thread Ian McDonald

On 10/29/06, Guy Harris [EMAIL PROTECTED] wrote:

abakash wrote:

 I am new to libpcap and just want to know whether libpcap has got any
 http support in it i.e. whether I can extract http header information
 from any packet.

You can, if you choose, write code to extract HTTP header information
from any TCP segment captured by libpcap that contains HTTP header
information and that was captured with a snapshot length long enough
to contain the header information in question.

Libpcap, however, won't do it for you; you will have to do it yourself.
-

libtrace from our research group might be able to help:
http://research.wand.net.nz/software/libtrace.php

--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.


Re: [tcpdump-workers] regarding arp and rarp

2006-06-26 Thread Ian McDonald

On 6/27/06, Richard Hansen [EMAIL PROTECTED] wrote:

Guy Harris [EMAIL PROTECTED] wrote:
 On Jun 26, 2006, at 12:03 PM, [EMAIL PROTECTED] wrote:

  I am trying to disect ARP/RARP packet.
  Basically I am looking for this information: Operation code,
 Sender HW address, Sender Protocol address, Destination HW address
 and Destination Protocol address.
  Is there a direct way using pcap to get that information.

 You can use libpcap to get the raw contents of packets,
 including ARP/
 RARP packets.

 You can't use libpcap to dissect ARP/RARP packets - or any
 other type
 of packets; it doesn't include any code to dissect packets.  You
 either have to write your own code to dissect them, or use some
 existing code to dissect them (for example, you could copy the code
 in tcpdump and modify it as necessary).

Although I haven't tried it out, libnet (http://www.packetfactory.net/libnet/) 
looks like it can dissect ARP (along with a bunch of other protocols).

Hope this helps,
Richard


-

As does libtrace:
http://research.wand.net.nz/software/libtrace.php

--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


Re: [tcpdump-workers] accessing IP packet header

2006-06-15 Thread Ian McDonald

On 6/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Hi guys,
  I wanted to access IP packet and then subsequently UDP/TCP/ICMP/IGMP
packet information. Are there any explicit function which I can call
to get information like version, IHL, source port, destination port,
etc. to get that information for each IP type of packet.

  Thanks in advance to everyone,
  zubin


Hi there,

I think libtrace from our research lab might be exactly what you want.
Have a look at:
http://research.wand.net.nz/software/libtrace.php

Regards,

Ian
--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


Re: [tcpdump-workers] Strange behavior of pcap filter

2006-04-06 Thread Ian McDonald
On 4/7/06, J S [EMAIL PROTECTED] wrote:
 Hello,

 I am developing an active monitoring system, which implements pcap filter.

 The requirement is to send probes with a high monitoring rate e.g. 40 msec
 and the probe packets have data of 12 bytes. For each packet sent by the
 sender the recipient sends a reply packet.


 I have noticed a strange behavior of the captured packets.


 I initially started with 10 probe packets sent by the sender with an
 interval of 40 msec between each of them. I used pcap_loop method with a cnt
 of -1. to loop for ever . The pcap filter deployed at each end is supposed
 to  capture 20 packets ( 10 from src to dst and 10 from dst to src and  I am
 only capturing data packets). However I noticed that the number of packets
 captured  are quite less (varied from 13 to 17) . but the total size of the
 pay load i.e. the sum of the payload for all packets is always 240 (12 x 20
 =240).  For some of the packets the size of the payload is 24, or even 48.

 When I increased the monitoring rate the payload size even changed to 108
 bytes and the no of packets changed to 10. However in all cases the total
 pay load size of all the packets was exact 240. I know there was no packet
 lost , as I can see them through sockets. I think the number of packets
 captured equaled to 20 when I changed the rate to 1 sec.

I presume you are using TCP/IP here. TCP/IP combines small packets to
make more efficient use of the network. If you use the TCP_NODELAY
socket option it won't do this.

 Is there any way I can capture packets efficiently with rate as  high as 40
 msec?

This should be no problem at all
--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


Re: [tcpdump-workers] 3.9.4 assumes IPv6 enabled

2005-11-10 Thread Ian McDonald
On 11/11/05, Albert Chin [EMAIL PROTECTED] wrote:
 From print-isoclns.c:
   static int
   isis_print_extd_ip_reach (const u_int8_t *tptr, const char *ident, 
 u_int16_t afi) {
   char ident_buffer[20];
   u_int8_t prefix[sizeof(struct in6_addr)]; /* shared copy buffer for 
 IPv4 and IPv6 prefixes */

 The prefix definition isn't wrapped in an #ifdef INET6. Ditto for this
 line in the same file:
   memset(prefix, 0, sizeof(struct in6_addr));  /* clear the copy 
 buffer */

I would say this code (without looking further) does the buffering for
both IPv4 and IPv6 (there is a comment saying that!).

It uses the in6_addr structure because that would be bigger than IPv4
so could hold both. Saves having two different parts of code doing
basically the same thing. There would probably be a cast when it is
used if being used by IPv4.

Ian
--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


[tcpdump-workers] [PATCH] DCCP - print all ACKs

2005-11-03 Thread Ian McDonald
Hi there folks,

Andrea Bittau picked up we weren't displaying ACKs for close packets
and provided a preliminary patch.

I've gone through the spec and reworked the patch slightly and it now
prints for all relevant packets.

This patch is against latest weekly CVS of tcpdump - 2005.10.03

Can this please be added to tcpdump?

Regards,

Ian
--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand
diff -uprN -X dontdiff tcpdump-2005.10.03/print-dccp.c dccpdump/print-dccp.c
--- tcpdump-2005.10.03/print-dccp.c	2005-09-20 18:25:20.0 +1200
+++ dccpdump/print-dccp.c	2005-11-04 12:06:48.0 +1300
@@ -155,25 +155,32 @@ static u_int64_t dccp_seqno(const struct
 	return seqno;
 }
 
-static u_int64_t dccp_ack_no(const struct dccp_hdr *dh,
-		const struct dccp_hdr_ack_bits *dh_ack)
+static inline unsigned int dccp_basic_hdr_len(const struct dccp_hdr *dh)
 {
+	return sizeof(*dh) + (DCCPH_X(dh) ? sizeof(struct dccp_hdr_ext) : 0);
+}
+
+static void dccp_print_ack_no(const u_char *bp)
+{
+	const struct dccp_hdr *dh = (const struct dccp_hdr *)bp;
+	const struct dccp_hdr_ack_bits *dh_ack =
+		(struct dccp_hdr_ack_bits *)(bp + dccp_basic_hdr_len(dh));
+
+	TCHECK2(*dh_ack,4);
 	u_int32_t ack_high = DCCPH_ACK(dh_ack);
 	u_int64_t ackno = EXTRACT_24BITS(ack_high)  0xFF;
 
 	if (DCCPH_X(dh) != 0) {
+		TCHECK2(*dh_ack,8);
 		u_int32_t ack_low = dh_ack-dccph_ack_nr_low;
 		
 		ackno = 0x00;  /* clear reserved field */
 		ackno = (ackno  32) + EXTRACT_32BITS(ack_low);
 	}
 
-	return ackno;
-}
-
-static inline unsigned int dccp_basic_hdr_len(const struct dccp_hdr *dh)
-{
-	return sizeof(*dh) + (DCCPH_X(dh) ? sizeof(struct dccp_hdr_ext) : 0);
+	(void)printf((ack=% PRIu64 ) , ackno);
+trunc:
+	return;
 }
 
 static inline unsigned int dccp_packet_hdr_len(const u_int8_t type)
@@ -309,9 +316,7 @@ void dccp_print(const u_char *bp, const 
 		struct dccp_hdr_response *dhr =
 			(struct dccp_hdr_response *)(bp + dccp_basic_hdr_len(dh));
 		TCHECK(*dhr);
-		(void)printf(response (service=%d, ack=% PRIu64 ) ,
-			 dhr-dccph_resp_service,
-			 dccp_ack_no(dh,(dhr-dccph_resp_ack)));
+		(void)printf(response (service=%d) , dhr-dccph_resp_service);
 		extlen += 12;
 		break;
 	}
@@ -319,20 +324,12 @@ void dccp_print(const u_char *bp, const 
 		(void)printf(data );
 		break;
 	case DCCP_PKT_ACK: {
-		struct dccp_hdr_ack_bits *dha =
-			(struct dccp_hdr_ack_bits *)(bp + dccp_basic_hdr_len(dh));
-		TCHECK(*dha);
-		(void)printf(ack (ack=% PRIu64 ) ,
-			 dccp_ack_no(dh,dha));
+		(void)printf(ack );
 		extlen += 8;
 		break;
 	}
 	case DCCP_PKT_DATAACK: {
-		struct dccp_hdr_ack_bits *dha =
-			(struct dccp_hdr_ack_bits *)(bp + dccp_basic_hdr_len(dh));
-		TCHECK(*dha);
-		(void)printf(dataack (ack=% PRIu64 ) ,
-			 dccp_ack_no(dh,dha));
+		(void)printf(dataack );
 		extlen += 8;
 		break;
 	}
@@ -366,6 +363,10 @@ void dccp_print(const u_char *bp, const 
 		break;
 	}
 
+	if ((DCCPH_TYPE(dh) != DCCP_PKT_DATA)  
+			(DCCPH_TYPE(dh) != DCCP_PKT_REQUEST))
+		dccp_print_ack_no(bp);
+
 	if (vflag  2)
 		return;
 
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


Re: [tcpdump-workers] [PATCH] DCCP support - revised

2005-09-20 Thread Ian McDonald
On 20/09/05, Guy Harris [EMAIL PROTECTED] wrote:
 Ian McDonald wrote:
 
  Please find attached a slightly revised patch to tidyup a bug with
  seqno/ackno processing.
 
 Checked into the main and x.9 branches.  I got rid of the dh_end
 variable, and added RCS IDs.
 
 I gave you and Arnaldo credit in the CREDITS file; should I put
 Yoshifumi Nishida in there as well?
 -
Thanks for putting this in - please credit Nishida-san as well.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


[tcpdump-workers] [PATCH] DCCP support - revised

2005-09-13 Thread Ian McDonald
Guy,

Please find attached a slightly revised patch to tidyup a bug with
seqno/ackno processing.

Regards,

Ian

On 06/09/05, Ian McDonald [EMAIL PROTECTED] wrote:
 Guy,
 
 Comments inline.
 
  dh_end still isn't being used, as per my original comment:
 
   In addition, there are no TCHECK(), TCHECK2(), TTEST(), or TTEST2()
   calls, and the dh_end variable isn't used, so no check appears to be
   done to prevent the print routine from running past the end of the
   captured data in the packet.
 
  It might not need to be used - if there are a sufficient set of
  TCHECK/TTEST-family calls, checking against the captured data length is
  being done, and if all checks for the end of the packet (rather than the
  end of the captured data length) are done by checking against len, it
  presumably wouldn't need to be - but if it's not used, it shouldn't exist.
 
 I am checking explicitly at each set with the TCHECK/TTEST macros. I
 have tested this with deliberately short packets and my old code
 segfaulted and the new one doesn't. I haven't used dh_end because I
 check each one before use. I believe this to be robust now - I spent
 quite a few hours testing this after your orginal comments :-)
 
 
  Also:
 
  1) FILES needs to be modified to include dccp.h and print-dccp.c;
 
 Done
 
  2) INSTALL should be, too;
 
 Done
 
  3) I've attached a patch to clean up some compiler warnings on OS X
  10.3.9 (which probably show up on at least some other platforms).
 
 
 I've put these in place and also more picked up by using -Wall on gcc
 (which I should have done in the first place).
 
 I've also put in one warning picked up by Matthew Luckie and at his
 suggestion also removed register keyword against variables and I'll
 let the compiler work it out.
 
 Please find attached new patch.
 
 Regards,
 
 Ian
 
 

diff -urN tcpdump-2005.08.22/dccp.h dccpdump/dccp.h
--- tcpdump-2005.08.22/dccp.h   1970-01-01 12:00:00.0 +1200
+++ dccpdump/dccp.h 2005-09-14 14:18:54.0 +1200
@@ -0,0 +1,135 @@
+#ifndef __DCCP_HDR__
+#define __DCCP_HDR__
+/*
+ * Copyright (C) Arnaldo Carvalho de Melo 2004
+ * Copyright (C) Ian McDonald 2005 [EMAIL PROTECTED]
+ * Copyright (C) Yoshifumi Nishida 2005
+ *
+ * This software may be distributed either under the terms of the
+ * BSD-style license that accompanies tcpdump or the GNU GPL version 2
+ */
+
+/**
+ * struct dccp_hdr - generic part of DCCP packet header
+ *
+ * @dccph_sport - Relevant port on the endpoint that sent this packet
+ * @dccph_dport - Relevant port on the other endpoint
+ * @dccph_doff - Data Offset from the start of the DCCP header, in 32-bit words
+ * @dccph_ccval - Used by the HC-Sender CCID
+ * @dccph_cscov - Parts of the packet that are covered by the Checksum field
+ * @dccph_checksum - Internet checksum, depends on dccph_cscov
+ * @dccph_x - 0 = 24 bit sequence number, 1 = 48
+ * @dccph_type - packet type, see DCCP_PKT_ prefixed macros
+ * @dccph_seq - sequence number high or low order 24 bits, depends on dccph_x
+ */
+struct dccp_hdr {
+   u_int16_t   dccph_sport,
+   dccph_dport;
+   u_int8_tdccph_doff;
+   u_int8_tdccph_ccval_cscov;
+   u_int16_t   dccph_checksum;
+   union {
+   u_int8_tdccph_xtr;
+   u_int32_t   dccph_seq;
+   }   dccph_xtrs;
+};
+
+#define DCCPH_CCVAL(dh)(((dh)-dccph_ccval_cscov)  0x0F)
+#define DCCPH_CSCOV(dh)(((dh)-dccph_ccval_cscov  4)  0x0F)
+
+#define DCCPH_X(dh)((dh)-dccph_xtrs.dccph_xtr  1)
+#define DCCPH_TYPE(dh) (((dh)-dccph_xtrs.dccph_xtr  1)  0xF)
+#define DCCPH_SEQ(dh)   (((dh)-dccph_xtrs.dccph_seq)  8)
+
+/**
+ * struct dccp_hdr_ext - the low bits of a 48 bit seq packet
+ *
+ * @dccph_seq_low - low 24 bits of a 48 bit seq packet
+ */
+struct dccp_hdr_ext {
+   u_int32_t   dccph_seq_low;
+};
+
+/**
+ * struct dccp_hdr_request - Conection initiation request header
+ *
+ * @dccph_req_service - Service to which the client app wants to connect
+ */
+struct dccp_hdr_request {
+   u_int32_t   dccph_req_service;
+};
+
+/**
+ * struct dccp_hdr_ack_bits - acknowledgment bits common to most packets
+ *
+ * @dccph_resp_ack_nr_high - 48 bit ack number high order bits, contains GSR
+ * @dccph_resp_ack_nr_low - 48 bit ack number low order bits, contains GSR
+ */
+struct dccp_hdr_ack_bits {
+   u_int32_t   dccph_ra;
+   u_int32_t   dccph_ack_nr_low;
+};
+
+#define DCCPH_ACK(dh_ack)   ((dh_ack)-dccph_ra  8)
+
+/**
+ * struct dccp_hdr_response - Conection initiation response header
+ *
+ * @dccph_resp_ack_nr_high - 48 bit ack number high order bits, contains GSR
+ * @dccph_resp_ack_nr_low - 48 bit ack number low order bits, contains GSR
+ * @dccph_resp_service - Echoes the Service Code on a received DCCP-Request
+ */
+struct dccp_hdr_response {
+   struct dccp_hdr_ack_bitsdccph_resp_ack;
+   u_int32_t   dccph_resp_service

Re: [tcpdump-workers] [PATCH] DCCP support

2005-09-05 Thread Ian McDonald
Guy,

Comments inline.

 dh_end still isn't being used, as per my original comment:
 
  In addition, there are no TCHECK(), TCHECK2(), TTEST(), or TTEST2()
  calls, and the dh_end variable isn't used, so no check appears to be
  done to prevent the print routine from running past the end of the
  captured data in the packet.
 
 It might not need to be used - if there are a sufficient set of
 TCHECK/TTEST-family calls, checking against the captured data length is
 being done, and if all checks for the end of the packet (rather than the
 end of the captured data length) are done by checking against len, it
 presumably wouldn't need to be - but if it's not used, it shouldn't exist.

I am checking explicitly at each set with the TCHECK/TTEST macros. I
have tested this with deliberately short packets and my old code
segfaulted and the new one doesn't. I haven't used dh_end because I
check each one before use. I believe this to be robust now - I spent
quite a few hours testing this after your orginal comments :-)

 
 Also:
 
 1) FILES needs to be modified to include dccp.h and print-dccp.c;

Done
 
 2) INSTALL should be, too;

Done
 
 3) I've attached a patch to clean up some compiler warnings on OS X
 10.3.9 (which probably show up on at least some other platforms).
 

I've put these in place and also more picked up by using -Wall on gcc
(which I should have done in the first place).

I've also put in one warning picked up by Matthew Luckie and at his
suggestion also removed register keyword against variables and I'll
let the compiler work it out.

Please find attached new patch.

Regards,

Ian
diff -urN tcpdump-2005.08.22/dccp.h dccpdump/dccp.h
--- tcpdump-2005.08.22/dccp.h	1970-01-01 12:00:00.0 +1200
+++ dccpdump/dccp.h	2005-09-06 10:24:24.276683776 +1200
@@ -0,0 +1,136 @@
+#ifndef __DCCP_HDR__
+#define __DCCP_HDR__
+/*
+ * Copyright (C) Arnaldo Carvalho de Melo 2004
+ * Copyright (C) Ian McDonald 2005 [EMAIL PROTECTED]
+ * Copyright (C) Yoshifumi Nishida 2005
+ *
+ * This software may be distributed either under the terms of the
+ * BSD-style license that accompanies tcpdump or the GNU GPL version 2
+ */
+
+/**
+ * struct dccp_hdr - generic part of DCCP packet header
+ *
+ * @dccph_sport - Relevant port on the endpoint that sent this packet
+ * @dccph_dport - Relevant port on the other endpoint
+ * @dccph_doff - Data Offset from the start of the DCCP header, in 32-bit words
+ * @dccph_ccval - Used by the HC-Sender CCID
+ * @dccph_cscov - Parts of the packet that are covered by the Checksum field
+ * @dccph_checksum - Internet checksum, depends on dccph_cscov
+ * @dccph_x - 0 = 24 bit sequence number, 1 = 48
+ * @dccph_type - packet type, see DCCP_PKT_ prefixed macros
+ * @dccph_seq - sequence number high or low order 24 bits, depends on dccph_x
+ */
+struct dccp_hdr {
+	u_int16_t	dccph_sport,
+			dccph_dport;
+	u_int8_t	dccph_doff;
+	u_int8_t	dccph_ccval_cscov;
+	u_int16_t	dccph_checksum;
+	union {
+	u_int8_t	dccph_xtr;
+	u_int32_t	dccph_seq;
+	}		dccph_xtrs;
+};
+
+#define DCCPH_CCVAL(dh)	(((dh)-dccph_ccval_cscov)  0x0F)
+#define DCCPH_CSCOV(dh)	(((dh)-dccph_ccval_cscov  4)  0x0F)
+
+#define DCCPH_X(dh)	((dh)-dccph_xtrs.dccph_xtr  1)
+#define DCCPH_TYPE(dh)	(((dh)-dccph_xtrs.dccph_xtr  1)  0xF)
+
+#define DCCPH_SEQ(dh)	(((dh)-dccph_xtrs.dccph_seq  8)  0x0FFF)
+
+/**
+ * struct dccp_hdr_ext - the low bits of a 48 bit seq packet
+ *
+ * @dccph_seq_low - low 24 bits of a 48 bit seq packet
+ */
+struct dccp_hdr_ext {
+	u_int32_t	dccph_seq_low;
+};
+
+/**
+ * struct dccp_hdr_request - Conection initiation request header
+ *
+ * @dccph_req_service - Service to which the client app wants to connect
+ */
+struct dccp_hdr_request {
+	u_int32_t	dccph_req_service;
+};
+
+/**
+ * struct dccp_hdr_ack_bits - acknowledgment bits common to most packets
+ *
+ * @dccph_resp_ack_nr_high - 48 bit ack number high order bits, contains GSR
+ * @dccph_resp_ack_nr_low - 48 bit ack number low order bits, contains GSR
+ */
+struct dccp_hdr_ack_bits {
+	u_int32_t	dccph_ra;
+	u_int32_t	dccph_ack_nr_low;
+};
+
+#define DCCPH_ACK(dh_ack)	(((dh_ack)-dccph_ra  8)  0x0FFF)
+
+/**
+ * struct dccp_hdr_response - Conection initiation response header
+ *
+ * @dccph_resp_ack_nr_high - 48 bit ack number high order bits, contains GSR
+ * @dccph_resp_ack_nr_low - 48 bit ack number low order bits, contains GSR
+ * @dccph_resp_service - Echoes the Service Code on a received DCCP-Request
+ */
+struct dccp_hdr_response {
+	struct dccp_hdr_ack_bits	dccph_resp_ack;
+	u_int32_t			dccph_resp_service;
+};
+
+static inline struct dccp_hdr_data *dccp_hdr_data(struct dccp_hdr *hdrg)
+{
+	const int ext = DCCPH_X(hdrg) ? sizeof(struct dccp_hdr_ext) : 0;
+
+	return (struct dccp_hdr_data *)(((u_char *)hdrg) + sizeof(hdrg) + ext);
+}
+
+/**
+ * struct dccp_hdr_reset - Unconditionally shut down a connection
+ *
+ * @dccph_reset_service - Echoes the Service Code on a received DCCP-Request
+ */
+struct dccp_hdr_reset {
+	struct

Re: [tcpdump-workers] [PATCH] DCCP support

2005-09-04 Thread Ian McDonald
Hi there,

Please find attached a reworked patch which I believe addresses all of
Guy's original  concerns and also adds options processing and other
enhancements.

It has been tested on 32 and 64 bit, little and big endian but hasn't
been tested on Darwin - I have however done what was asked.

Can you please accept this into the tcpdump program or advise what
else needs to be done?

More information on DCCP can be obtained at http://wlug.org.nz/DCCP

Regards,

Ian

On 03/08/05, Guy Harris [EMAIL PROTECTED] wrote:
 Ian McDonald wrote:
 
  +#define __LITTLE_ENDIAN_BITFIELD
  +
  +/**
  + * struct dccp_hdr - generic part of DCCP packet header
  + *
  + * @dccph_sport - Relevant port on the endpoint that sent this packet
  + * @dccph_dport - Relevant port on the other endpoint
  + * @dccph_doff - Data Offset from the start of the DCCP header, in 32-bit 
  words
  + * @dccph_ccval - Used by the HC-Sender CCID
  + * @dccph_cscov - Parts of the packet that are covered by the Checksum 
  field
  + * @dccph_checksum - Internet checksum, depends on dccph_cscov
  + * @dccph_x - 0 = 24 bit sequence number, 1 = 48
  + * @dccph_type - packet type, see DCCP_PKT_ prefixed macros
  + * @dccph_seq - sequence number high or low order 24 bits, depends on 
  dccph_x
  + */
  +struct dccp_hdr {
  + u_int16_t   dccph_sport,
  + dccph_dport;
  + u_int8_tdccph_doff;
  +#if defined(__LITTLE_ENDIAN_BITFIELD)
  + u_int8_tdccph_cscov:4,
  + dccph_ccval:4;
  +#elif defined(__BIG_ENDIAN_BITFIELD)
  + u_int8_tdccph_ccval:4,
  + dccph_cscov:4;
  +#else
  +#error  Adjust your asm/byteorder.h defines
  +#endif
 
 The fact that __LITTLE_ENDIAN_BITFIELD is predefined means that the code
 assumes that bitfields are stored in an order such that in
 
 u_int8_tdccph_cscov:4,
 dccph_ccval:4;
 
 the low-order 4 bits of the byte are dccph_cscov and the high-order 4
 bits are dccph_ccval.
 
 The C language doesn't specify the order of bitfields in the bits of a
 structure, so that won't work.
 
 If I remove that #define, I get the errors
 
 dccp.h:35:2: #error Adjust your asm/byteorder.h defines
 dccp.h:49:2: #error Adjust your asm/byteorder.h defines
 dccp.h:114: error: structure has no member named `dccph_x'
 print-dccp.c:57:2: #error Adjust your asm/byteorder.h defines
 
 Unfortunately, the suggestion made by the errors doesn't help:
 
 Guy-Harris-Computer.local$ ls -l /usr/include/asm/byteorder.h
 ls: /usr/include/asm/byteorder.h: No such file or directory
 Guy-Harris-Computer.local$ ls -ld /usr/include/asm
 ls: /usr/include/asm: No such file or directory
 
 because:
 
 Guy-Harris-Computer.local$ uname -sr
 Darwin 7.9.0
 
 this ain't Linux.
 
 Try, instead:
 
 u_int8_tdccph_ccval_cscov;
 
 ...
 
 #define DCCPH_CCVAL(dh) (((dh)-dccph_ccval_cscov)  0x0F)
 #define DCCPH_CSCOV(dh) (((dh)-dccph_ccval_cscov  4)  0x0F)
 
 And, for the Res, Type, X, and Sequence number fields, I'd declare the
 first 4 bytes as a u_int32_t, extract it with EXTRACT_32BITS(), and
 define macros that take a 32-bit value and extract the Res, Type, X, and
 Sequence Number fields from it.  I'd do something similar with the Ack
 sequence numbers.
 
 In addition, zero-length arrays such as
 
 u_int32_t   dccph_options[0];
 
 are not supported by all C compilers people use to compile tcpdump;
 either make it an array of 1 element (and subtract sizeof(u_int32_t)
 from anything based on the size of the structure), or leave that field
 out (and, if code is written that looks at options, add the length of
 the header to a pointer to the start of the packet and use that pointer
 as a pointer to the options), and do similar things in other places
 where there are zero-length arrays.
 
 (Also, remove the include of assert.h; the assert macro isn't used.)
 
 In addition, there are no TCHECK(), TCHECK2(), TTEST(), or TTEST2()
 calls, and the dh_end variable isn't used, so no check appears to be
 done to prevent the print routine from running past the end of the
 captured data in the packet.
diff -urN tcpdump-2005.08.22/dccp.h dccpdump/dccp.h
--- tcpdump-2005.08.22/dccp.h	1970-01-01 12:00:00.0 +1200
+++ dccpdump/dccp.h	2005-09-05 11:49:48.0 +1200
@@ -0,0 +1,136 @@
+#ifndef __DCCP_HDR__
+#define __DCCP_HDR__
+/*
+ * Copyright (C) Arnaldo Carvalho de Melo 2004
+ * Copyright (C) Ian McDonald 2005 [EMAIL PROTECTED]
+ * Copyright (C) Yoshifumi Nishida 2005
+ *
+ * This software may be distributed either under the terms of the
+ * BSD-style license that accompanies tcpdump or the GNU GPL version 2
+ */
+
+/**
+ * struct dccp_hdr - generic part of DCCP packet header
+ *
+ * @dccph_sport - Relevant port on the endpoint that sent this packet
+ * @dccph_dport - Relevant port on the other endpoint

Re: [tcpdump-workers] [PATCH] DCCP support

2005-08-03 Thread Ian McDonald
Guy, 

Comments in line.

On 03/08/05, Guy Harris [EMAIL PROTECTED] wrote:
 
 The fact that __LITTLE_ENDIAN_BITFIELD is predefined means that the code
 assumes that bitfields are stored in an order such that in
 
 u_int8_tdccph_cscov:4,
 dccph_ccval:4;
 
Will investigate further..


 In addition, zero-length arrays such as
 
 u_int32_t   dccph_options[0];
 
 are not supported by all C compilers people use to compile tcpdump;

Point noted

 (Also, remove the include of assert.h; the assert macro isn't used.)
 
Point noted

 In addition, there are no TCHECK(), TCHECK2(), TTEST(), or TTEST2()
 calls, and the dh_end variable isn't used, so no check appears to be
 done to prevent the print routine from running past the end of the
 captured data in the packet.

Will check what these do.

I appreciate all the feedback. I have received further protocol
support from Nishida-san of Sony Japan so will look to incorporate
your comments and his changes before resubmitting.

Regards,

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


[tcpdump-workers] [PATCH] DCCP support

2005-08-02 Thread Ian McDonald
Hi there,

I am submitting a patch to add support that I have worked on and
Arnaldo Carvalho de Melo has worked on. This patch has been written
against the nightly build of July 31, 2005.

I looked at the instructions for submitting patches and it said to use
SourceForge but nobody has submitted there for a while by the looks so
I am submitting to the list. Please advise if I should send elsewhere.

This is the first stage of DCCP packet analysis. I would like to add
support for CCID and option processing but I want to do the release
early, release often thing.

More details about DCCP can be obtained from here:
http://www.icir.org/kohler/dcp/
or here:
http://wand.cs.waikato.ac.nz/~iam4/dccp/index.html

Regards,

Ian
diff -uprN tcpdump-2005.07.31/dccp.h newdump/dccp.h
--- tcpdump-2005.07.31/dccp.h	1970-01-01 12:00:00.0 +1200
+++ newdump/dccp.h	2005-08-02 11:49:51.0 +1200
@@ -0,0 +1,186 @@
+#ifndef __DCCP_HDR__
+#define __DCCP_HDR__
+/*
+ * Copyright (C) Arnaldo Carvalho de Melo 2004
+ * Copyright (C) Ian McDonald 2005
+ *
+ * This software may be distributed either under the terms of the
+ * BSD-style license that accompanies tcpdump or the GNU GPL version 2
+ */
+
+#define __LITTLE_ENDIAN_BITFIELD
+
+/**
+ * struct dccp_hdr - generic part of DCCP packet header
+ *
+ * @dccph_sport - Relevant port on the endpoint that sent this packet
+ * @dccph_dport - Relevant port on the other endpoint
+ * @dccph_doff - Data Offset from the start of the DCCP header, in 32-bit words
+ * @dccph_ccval - Used by the HC-Sender CCID
+ * @dccph_cscov - Parts of the packet that are covered by the Checksum field
+ * @dccph_checksum - Internet checksum, depends on dccph_cscov
+ * @dccph_x - 0 = 24 bit sequence number, 1 = 48
+ * @dccph_type - packet type, see DCCP_PKT_ prefixed macros
+ * @dccph_seq - sequence number high or low order 24 bits, depends on dccph_x
+ */
+struct dccp_hdr {
+	u_int16_t	dccph_sport,
+			dccph_dport;
+	u_int8_t	dccph_doff;
+#if defined(__LITTLE_ENDIAN_BITFIELD)
+	u_int8_t	dccph_cscov:4,
+			dccph_ccval:4;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+	u_int8_t	dccph_ccval:4,
+			dccph_cscov:4;
+#else
+#error  Adjust your asm/byteorder.h defines
+#endif
+	u_int16_t	dccph_checksum;
+#if defined(__LITTLE_ENDIAN_BITFIELD)
+	u_int32_t	dccph_x:1,
+			dccph_type:4,
+			dccph_reserved:3,
+			dccph_seq:24;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+	u_int32_t	dccph_reserved:3,
+			dccph_type:4,
+			dccph_x:1,
+			dccph_seq:24;
+#else
+#error  Adjust your asm/byteorder.h defines
+#endif
+	u_int32_t	dccph_options[0];
+};
+
+/**
+ * struct dccp_hdr_ext - the low bits of a 48 bit seq packet
+ *
+ * @dccph_seq_low - low 24 bits of a 48 bit seq packet
+ */
+struct dccp_hdr_ext {
+	u_int32_t	dccph_seq_low;
+	u_int32_t	dccph_options[0];
+};
+
+/**
+ * struct dccp_hdr_request - Conection initiation request header
+ *
+ * @dccph_req_service - Service to which the client app wants to connect
+ * @dccph_req_options - list of options (must be a multiple of 32 bits
+ */
+struct dccp_hdr_request {
+	u_int32_t	dccph_req_service;
+	u_int32_t	dccph_req_options[0];
+};
+
+/**
+ * struct dccp_hdr_ack_bits - acknowledgment bits common to most packets
+ *
+ * @dccph_resp_ack_nr_high - 48 bit ack number high order bits, contains GSR
+ * @dccph_resp_ack_nr_low - 48 bit ack number low order bits, contains GSR
+ */
+struct dccp_hdr_ack_bits {
+	u_int32_t	dccph_reserved1:8,
+			dccph_ack_nr_high:24;
+	u_int32_t	dccph_ack_nr_low;
+	u_int32_t	dccph_options[0];
+};
+
+/**
+ * struct dccp_hdr_response - Conection initiation response header
+ *
+ * @dccph_resp_ack_nr_high - 48 bit ack number high order bits, contains GSR
+ * @dccph_resp_ack_nr_low - 48 bit ack number low order bits, contains GSR
+ * @dccph_resp_service - Echoes the Service Code on a received DCCP-Request
+ * @dccph_resp_options - list of options (must be a multiple of 32 bits
+ */
+struct dccp_hdr_response {
+	struct dccp_hdr_ack_bits	dccph_resp_ack;
+	u_int32_t			dccph_resp_service;
+	u_int32_t			dccph_resp_options[0];
+};
+
+/**
+ * struct dccp_hdr_data - DataAck and Ack packets
+ *
+ * @dccph_data_options - list of options (must be a multiple of 32 bits
+ */
+struct dccp_hdr_data {
+	struct dccp_hdr_ack_bits	dccph_data_ack;
+	u_int32_t			dccph_data_options[0];
+};
+
+static inline struct dccp_hdr_data *dccp_hdr_data(struct dccp_hdr *hdrg)
+{
+	const int ext = hdrg-dccph_x ? sizeof(struct dccp_hdr_ext) : 0;
+
+	return (struct dccp_hdr_data *)(((u_char *)hdrg) + sizeof(hdrg) + ext);
+}
+
+#define dccp_hdr_ack(hdrg) dccp_hdr_data(hdrg)
+
+/**
+ * struct dccp_hdr_close - Conection CloseReq and Close packets
+ *
+ * @dccph_close_options - list of options (must be a multiple of 32 bits
+ */
+struct dccp_hdr_close {
+	struct dccp_hdr_ack_bits	dccph_close_ack;
+	u_int32_t			dccph_close_options[0];
+};
+
+/**
+ * struct dccp_hdr_reset - Unconditionally shut down a connection
+ *
+ * @dccph_reset_service - Echoes the Service Code on a received DCCP-Request