[tcpdump-workers] libpcap lint
libpcap has a lot of lint. In gencode.c, some patterns stand out: 1) Lots of unreachable break statements after return statements; why not drop the break statements? 2) Assignment of negative constant to unsigned type, usually assignments of the type off_linktype = -1; where off_linktype is a u_int. It looks to me like UINT_MAX is intended. Am I missing something? I suggest #define OFF_UNDEFINED UINT_MAX . . . off_linktype = OFF_UNDEFINED; 3) Zillions of lint messages could be suppressed if bpf_error() and abort() calls were followed by /*NOTREACHED*/ I will send a patch that gets rid of the lint. 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] preperation for 3.9 branch
On Wed, Apr 06, 2005 at 08:03:08PM -0700, Guy Harris wrote: Michael Richardson wrote: I would like to plan a 3.9 branch and release for April. I would propose branching on April 10, with the release around April 25. How does that sound? It sounds reasonable. (It turns out I might be able to get gencode.c to handle radiotap - *all* filter expressions other than the link[M:N] ones will need to skip the radiotap header, so the fancy optimization I was looking at is probably a waste of time. Radiotap is designed to be a variable-length header. When you say that gencode will handle it, you mean that it will skip based on the length field to the end of the radiotap header? If so, that sounds great! Speaking of radio headers for 802.11 and link[M:N], I'm not sure a filter that tests those is necessarily useful - should the link[M:N] filters just test the 802.11 header and payload, and skip radio headers for the Prism, AVS, and radiotap headers? That way the same link[M:N] filter can test the same 802.11 header fields regardless of whether there's no radio header or one of the various radio headers.) I think that link[M:N] filters should skip the radio header, but I think that users will want to test both radio headers and link-level headers. For example, I may want to filter based on Rx antenna, or else set a threshold Rx signal strength above (or below) which packets are filtered. 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
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] RFC: 802.11 capture patch
On Fri, Mar 24, 2006 at 10:06:25PM -0600, David Young wrote:
This patch adds support for the extended rates 802.11 Information Element
(IE), changes a couple of u_char fields to u_int8_t, makes struct rates_t
store 15 rates (sort of arbitrary, that), and displays both truncated
SSIDs and rate sets. Please review. I hope to check it in, soon.
I almost completely rewrote the IE parser, parse_elements(). The old
one was unnecessarily complicated. It also looked to me like it might
be susceptible to buffer overruns.
Oops. Here is the patch.
Dave
--
David Young OJC Technologies
[EMAIL PROTECTED] Urbana, IL * (217) 278-3933
? .ieee802_11.h.swp
Index: ieee802_11.h
===
RCS file: /cvsroot/src/dist/tcpdump/ieee802_11.h,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 ieee802_11.h
--- ieee802_11.h27 Sep 2004 17:06:46 - 1.1.1.2
+++ ieee802_11.h25 Mar 2006 03:50:02 -
@@ -127,13 +127,13 @@ struct mgmt_header_t {
struct ssid_t {
u_int8_telement_id;
u_int8_tlength;
- u_char ssid[33]; /* 32 + 1 for null */
+ u_int8_tssid[33]; /* 32 + 1 for null */
};
struct rates_t {
u_int8_telement_id;
u_int8_tlength;
- u_int8_trate[8];
+ u_int8_trate[15];
};
struct challenge_t {
@@ -198,7 +198,7 @@ struct tim_t {
/* reserved19 */
/* reserved16 */
/* reserved16 */
-
+#defineE_XRATES50
struct mgmt_body_t {
u_int8_ttimestamp[8];
@@ -206,14 +206,18 @@ struct mgmt_body_t {
u_int16_t listen_interval;
u_int16_t status_code;
u_int16_t aid;
- u_char ap[6];
+ u_int8_tap[6];
u_int16_t reason_code;
u_int16_t auth_alg;
u_int16_t auth_trans_seq_num;
struct challenge_t challenge;
u_int16_t capability_info;
struct ssid_t ssid;
+ u_int8_tssidlen;
struct rates_t rates;
+ u_int8_trateslen;
+ struct rates_t xrates;
+ u_int8_txrateslen;
struct ds_t ds;
struct cf_t cf;
struct fh_t fh;
Index: print-802_11.c
===
RCS file: /cvsroot/src/dist/tcpdump/print-802_11.c,v
retrieving revision 1.9
diff -u -p -r1.9 print-802_11.c
--- print-802_11.c 26 Feb 2006 03:04:28 - 1.9
+++ print-802_11.c 25 Mar 2006 03:50:02 -
@@ -55,18 +55,12 @@ __RCSID($NetBSD: print-802_11.c,v 1.9 2
#define PRINT_RATE(_sep, _r, _suf) \
printf(%s%2.1f%s, _sep, (.5 * ((_r) 0x7f)), _suf)
-#define PRINT_RATES(p) \
-do { \
- int z; \
- const char *sep = [; \
- for (z = 0; z p.rates.length ; z++) { \
- PRINT_RATE(sep, p.rates.rate[z], \
- (p.rates.rate[z] 0x80 ? * : )); \
- sep = ; \
- } \
- if (p.rates.length != 0) \
- printf( Mbit]); \
-} while (0)
+
+#definearraycount(__a) (sizeof(__a)/sizeof((__a)[0]))
+
+#ifndef offsetof
+#define offsetof(type, member) ((size_t)(((type *)0)-member))
+#endif
static const char *auth_alg_text[]={Open System,Shared Key,EAP};
static const char *subtype_text[]={
@@ -144,89 +138,66 @@ wep_print(const u_char *p)
static int
parse_elements(struct mgmt_body_t *pbody, const u_char *p, int offset)
{
+ uint8_t id, len;
+ int truncated;
+ size_t maxlen;
+ uint8_t *lenp;
+ void *ptr;
+
for (;;) {
- if (!TTEST2(*(p + offset), 1))
- return 1;
- switch (*(p + offset)) {
+ if (!TTEST2(p[offset], 2))
+ break;
+ id = p[offset];
+ len = p[offset + 1];
+ lenp = NULL;
+ switch (id) {
case E_SSID:
- if (!TTEST2(*(p + offset), 2))
- return 0;
- memcpy(pbody-ssid, p + offset, 2);
- offset += 2;
- if (pbody-ssid.length = 0)
- break;
- if (!TTEST2(*(p + offset), pbody-ssid.length))
- return 0;
- memcpy(pbody-ssid.ssid, p + offset,
- pbody-ssid.length);
- offset += pbody-ssid.length;
- pbody-ssid.ssid[pbody-ssid.length] = '\0';
+ lenp = pbody-ssidlen;
+ ptr = pbody-ssid;
+ maxlen = sizeof(pbody-ssid);
break;
case E_CHALLENGE:
- if (!TTEST2(*(p + offset), 2))
- return 0
Re: [tcpdump-workers] where does PCAP timestamp before or after the MAC scheduler?
On Thu, Mar 30, 2006 at 12:17:47PM +0200, Debrei Gabor wrote: Hello! We want to compare 802.11 MAC schedulers performance, to decide how much the Media Access takes. Many 802.11 MACs put a microsecond timestamp on received frames. Some wireless drivers in *BSD will load that timestamp into the radiotap capture header. In principle (maybe in fact), Linux can do the same. Sadly, 802.11 MACs do not stamp transmitted frames. That would be very useful! Dave We want to know where/when does PCAP put the timestamp (from not so accurate kernel time) on to the packets. I already know, it does when the kernel sees the packet. The question is: Is it after or before the MAC scheduler? I mean, does it in TR or RX buffers or at higher protocol layers take place? (If it takes place in the buffers the use of HW monitoring devices the only way of measuring? ) Thanks, I am looking forwad to Your answers. Gabor _ Digit?lis f?nyk?pez?g?pek rendk?v?li csomagaj?nlatokkal, fot?kidolgoz?s m?r 25,- Ft-t?l FotoMarket, m?r 5 ?ve az ?n fot?szolg?lat?ban! www.fotomarket.hu - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe. -- 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] radiotap on linux
On Wed, Jun 14, 2006 at 11:56:24AM -0500, Matthew Belcher wrote: Are you running it with -s0 (or some larger-than-default capture size)? A full RT header can be bigger than the 32 or 64 or whatever the default # of bytes is for tcpdump to process. Thanks for your suggestion. I tried it with -s0 to see if that would help. Here's what I get now: (none):~# tcpdump -i wifi0 -L Data link types (use option -y to set): IEEE802_11 (802.11) (none):~# tcpdump -vv -i wifi0 -s0 -x tcpdump: listening on wifi0, link-type IEEE802_11 (802.11), capture size 65535 bytes 11:41:33.240612 unknown IEEE802.11 frame type (3)More Data More Fragments Pwr Mgmt Retry Strictly Ordered WEP Encrypted 65535us (header) unknown IEEE802.11 frame type (3)unknown 802.11 frame type (3) 0x: 0002 6f21 e671 0806 0321 o!.q...! 0x0010: 0800 0604 0001 0002 6f21 e671 c0a8 0164 o!.q...d 0x0020: c0a8 0165 As you can see that doesn't seem to have helped. Are the radiotap packets in Linux formatted differently than in BSD? If so, does tcpdump only accept BSD formatted radiotap packets? I'm trying to figure out whether this functionality needs to be added or whether it is already there and I'm just not setting things up right. Are you sure this is a radiotap capture? Where it says link-type IEEE802_11, it should say link-type IEEE802_11_RADIO. Perhaps the driver is really creating a radiotap capture, but it uses the wrong DLT? Radiotap headers had better not be formatted differently in Linux, or else Linux is not compliant with the radiotap spec. 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] how to make the sniffer quicker?
On Wed, Jan 17, 2007 at 10:39:55AM -, David Lopez wrote: Hi I'm developing a position system for my PhD. This system is based on Round Trip Time measurements. I'm getting the timestamp of the packets using Tethereal and the Mactime in the Prism Monitor Header My problem is: the sniffer is too slow. How fast is your computer? Do you use a Prism radio? A host has to read packets from the Prism II/2.5 radios using programmed I/O, which is slow. When I'm flooding the receiver with pings, using the linux command ping -f, if I send X in one second I cannot get this number of packets in the sniffer, I always get less, around the 10%. At what rate does the sniffer receive packets? Could it be that ping -f produces packets faster than the radio can transmit them? That is, the packets may be dropped on the sender side. Dave -- David Young OJC Technologies [EMAIL PROTECTED] Urbana, IL * (217) 278-3933 - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Hardware timestamp ?
On Thu, Feb 26, 2009 at 06:49:45PM -0600, Pierre Karampournis wrote: Hi, I am currently working in a university lab and I need to capture packets with a nanosecond precision timestamp using the Pcap format. Pierre, If you tell us what you are trying to accomplish with nanosecond timestamps, we might be able to help you better. :-) Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933 - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 802.11 + radio headers question...
On Tue, Apr 14, 2009 at 11:54:50AM -0400, Eddie Harari wrote: so when i sniff a packet from my monitor mode intel chipset based wifi card , how do i know which radio info is preceding the 802.11 header ? The DLT that you have set determines the radio header. For example, DLT_IEEE802_11_RADIO requests a radio header in radiotap format. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933 - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] enquire about the tcpdump
On Tue, Sep 29, 2009 at 10:15:03AM +0200, Shangbo Wang wrote: Hello, I downloaded the tcpdump from your website. I want to enquire that the tcpdump can extract the timestamp in nanoseconds. I need this time parameters to realize the ranging functionality Are you measuring the range over the air (i.e., on WLAN) or over wire? How many hops from station to station? Do you need to get an instant range fix, or can you integrate for a while? Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933 - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
