Re: [tcpdump-workers] radio header 802.11

2005-11-03 Thread Guy Harris

Mike Kershaw wrote:

Radio level data is only available in monitor mode.


On Linux, at least.  From a quick look at the wi driver and 802.11 
framework in NetBSD, you should be able to get radio data and 802.11 
headers in non-promiscuous, promiscuous, and monitor mode; the 802.11 
headers should be available for any device whose driver that uses the 
802.11 framework, and at least some other drivers should also support 
radio data.  The other free-software BSDs probably work similarly.


See

http://wiki.ethereal.com/CaptureSetup/WLAN

for what I was able to infer from looking at the free-software BSDs.


Sniffing an 80211 card in promisc mode has undefined results.  At best
it will act like sniffing a shared media network, you'll get 802.3
format ethernet frames of the data frames on the network.  At worst,
it'll be like sniffing a card not in promisc mode at all, you'll see
only your own data.


Except on Windows, where, at worst, you might see only your own 
*received* data, and not even see the data you're sending.



Many drivers/firmware don't appear to intelligently understand promisc
mode, so you're likely to get the worst-case most of the time.


What are the drivers and cards that have problems with promiscuous mode?


A quick grep through the new 80211 layer


Is that for Linux or BSD?  If it's for Linux, where's the new layer?
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


Re: [tcpdump-workers] radio header 802.11

2005-11-03 Thread David Young
On Thu, Nov 03, 2005 at 12:30:51AM -0800, Guy Harris wrote:
 Mike Kershaw wrote:
 Radio level data is only available in monitor mode.
 
 On Linux, at least.  From a quick look at the wi driver and 802.11 
 framework in NetBSD, you should be able to get radio data and 802.11 
 headers in non-promiscuous, promiscuous, and monitor mode; the 802.11 
 headers should be available for any device whose driver that uses the 
 802.11 framework, and at least some other drivers should also support 
 radio data.  The other free-software BSDs probably work similarly.

In NetBSD, I know for certain that ath, atw, rtw, and wi provide radio
headers in all modes.  I believe atu, ipw, iwi, and ral do, too.

Dave

-- 
David Young OJC Technologies
[EMAIL PROTECTED]  Urbana, IL * (217) 278-3933
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


Re: [tcpdump-workers] radio header 802.11

2005-11-03 Thread Mike Kershaw
 Many drivers/firmware don't appear to intelligently understand promisc
 mode, so you're likely to get the worst-case most of the time.
 
 What are the drivers and cards that have problems with promiscuous mode?

If I recall, centrino definitely, I'll have to go through my logs and
see what others people have complained about and test them directly.

 A quick grep through the new 80211 layer
 
 Is that for Linux or BSD?  If it's for Linux, where's the new layer?

Linux.  Partially in kernel, partially in netdev chain, and partially
independent for the IEEE80211.sourceforge.net project which is run by
the IBM team doing the centrino drivers.

And theres a competing complete layer.

It's sort of a mess.

-m

-- 
Mike Kershaw/Dragorn [EMAIL PROTECTED]
GPG Fingerprint: 3546 89DF 3C9D ED80 3381  A661 D7B2 8822 738B BDB1

!*''# Waka waka bang splat tick tick hash
[EMAIL PROTECTED]  Caret at back-tick dollar dollar dash,
!*'$_   Bang splat tick dollar under-score,
%*#4  Percent splat waka waka number four,
)../   Ampersand right-paren dot dot slash,
|{~~SYSTEM HALTED   Vertical-bar curly-bracket tilde tilde CRASH.



pgpdpStdvVLrB.pgp
Description: PGP signature


[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 - print all ACKs

2005-11-03 Thread Hannes Gredler

checked into HEAD;

who is going to receive credit/blame for this patch ?

andrea, ian or both ?

tx, /hannes

Ian McDonald wrote:

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.

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


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

2005-11-03 Thread Hannes Gredler

Ian is already on the blamelist (aka CREDITS) - so i just have added Andrea;

tx again for your submission;

/hannes

Ian McDonald wrote:

On 04/11/05, Hannes Gredler [EMAIL PROTECTED] wrote:


checked into HEAD;

who is going to receive credit/blame for this patch ?

andrea, ian or both ?



Both

--
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.