[tcpdump-workers] Linux evdev capture support (draft patch)

2008-12-09 Thread David Gibson
I've implemented a first cut at adding support to libpcap to capture
from the Linux /dev/input/event* (evdev) devices.  Draft patch is
included below.

However, I've realised there's a problem.  Since it's an internal-only
protocol, the evdev devices return packets which are in native-endian
format.  Obviously that's problematic once the packets go into pcap
files which could be moved to other machines.

As I see it, I have 3 options here:
1. Ask for a second DLT_ value, and use different DLT values
for the capture depending on the endianness of the capturing machine.
2. Covert the packets at capture time to either little or
big-endian (arbitrary choice).
3. Capture and record in native-endian, and rely on programs
reading the pcap file to deduce the endianness from other data.  This
will generally be possible in practice because the 16-bit 'type' field
has no assigned values above 0xff.

I'm inclined towards option (2), but I don't know if there's a
pre-existing libpcap rule of thumb about this sort of thing.

Index: libpcap/Makefile.in
===
--- libpcap.orig/Makefile.in2008-11-22 00:31:34.0 +1100
+++ libpcap/Makefile.in 2008-11-22 00:32:08.0 +1100
@@ -77,7 +77,7 @@ YACC = @V_YACC@
@rm -f $@
$(CC) $(CFLAGS) -c $(srcdir)/$*.c
 
-PSRC = [EMAIL PROTECTED]@.c @USB_SRC@ @BT_SRC@
+PSRC = [EMAIL PROTECTED]@.c @USB_SRC@ @BT_SRC@ @EVDEV_SRC@
 FSRC =  [EMAIL PROTECTED]@.c
 SSRC =  @SSRC@
 CSRC = pcap.c inet.c gencode.c optimize.c nametoaddr.c \
Index: libpcap/configure.in
===
--- libpcap.orig/configure.in   2008-11-22 00:32:01.0 +1100
+++ libpcap/configure.in2008-11-22 00:32:08.0 +1100
@@ -1072,6 +1072,26 @@ if test "x$enable_bluetooth" != "xno" ; 
AC_SUBST(BT_SRC)
 fi
 
+dnl check for Linux evdev sniffing support
+AC_MSG_CHECKING(for Linux evdev sniffing support)
+case "$host_os" in
+linux*)
+   AC_CHECK_HEADER(linux/input.h,
+ [
+   AC_DEFINE(PCAP_SUPPORT_EVDEV, 1, [target host supports evdev 
sniffing])
+   EVDEV_SRC=pcap-evdev-linux.c
+   AC_MSG_RESULT(yes)
+ ],
+ AC_MSG_NOTICE(Need linux/input.h to support evdev sniffing)
+   )
+   ;;
+*)
+   AC_MSG_NOTICE(no Linux evdev sniffing support)
+   ;;
+esac
+AC_SUBST(PCAP_SUPPORT_EVDEV)
+AC_SUBST(EVDEV_SRC)
+
 AC_PROG_INSTALL
 
 AC_CONFIG_HEADER(config.h)
Index: libpcap/pcap-evdev-linux.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ libpcap/pcap-evdev-linux.c  2008-11-22 00:32:08.0 +1100
@@ -0,0 +1,248 @@
+/*
+ * Copyright (C) 2008 David Gibson.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote
+ * products derived from this software without specific prior written
+ * permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Sniffing support for the Linux evdev interface.
+ * By David Gibson <[EMAIL PROTECTED]>
+ *
+ */
+#ifndef lint
+static const char rcsid[] _U_ =
+"@(#) $Header$ (LBL)";
+#endif
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include "pcap-int.h"
+#include "pcap-evdev-linux.h"
+
+#ifdef NEED_STRERROR_H
+#include "strerror.h"
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define EVDEV_IFACE"event"
+#define EVDEV_DEV_DIR  "/dev/input"
+#define EVDEV_KNOWN_VERSION0x01
+
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+#define htols(s) s
+#define htoll(l) l
+#define htol64(ll) ll
+#else
+#define

Re: [tcpdump-workers] Linux evdev capture support (draft patch)

2008-12-09 Thread ronnie sahlberg
On Tue, Dec 9, 2008 at 7:40 PM, David Gibson
<[EMAIL PROTECTED]> wrote:
> I've implemented a first cut at adding support to libpcap to capture
> from the Linux /dev/input/event* (evdev) devices.  Draft patch is
> included below.
>
> However, I've realised there's a problem.  Since it's an internal-only
> protocol, the evdev devices return packets which are in native-endian
> format.  Obviously that's problematic once the packets go into pcap
> files which could be moved to other machines.
>
> As I see it, I have 3 options here:
>1. Ask for a second DLT_ value, and use different DLT values
> for the capture depending on the endianness of the capturing machine.
>2. Covert the packets at capture time to either little or
> big-endian (arbitrary choice).
>3. Capture and record in native-endian, and rely on programs
> reading the pcap file to deduce the endianness from other data.  This
> will generally be possible in practice because the 16-bit 'type' field
> has no assigned values above 0xff.
>
> I'm inclined towards option (2), but I don't know if there's a
> pre-existing libpcap rule of thumb about this sort of thing.
>

I think 3 is a fair choice.
There are several examples of protocols in wireshark already where it
has to resort to heuristics like that in order to determine how to
decode the packets.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.


[tcpdump-workers] pcap_findalldevs_ex() and libpcap

2008-12-09 Thread Abdelrazak Younes

Hello there,

I am slowly learning libcap which I find quite useful, thanks a lot to 
the authors.


I have this piece of code from a Winpcap using program that uses 
pcap_findalldevs_ex(). WinPcap documentation says that 
pcap_findalldevs() is obsolete and one should use pcap_findalldevs_ex() 
instead:


http://www.winpcap.org/docs/docs_41b4/html/group__wpcapfunc.html#g7b128eaeef627b408f6a6e2a2f5eb45d

Problem is that libpcap-1.0.0 doesn't have this function, what's the catch?

Thanks in advance for any hint.
Abdel.

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


Re: [tcpdump-workers] Linux evdev capture support (draft patch)

2008-12-09 Thread David Gibson
On Tue, Dec 09, 2008 at 08:47:18PM +1100, ronnie sahlberg wrote:
> On Tue, Dec 9, 2008 at 7:40 PM, David Gibson
> <[EMAIL PROTECTED]> wrote:
> > I've implemented a first cut at adding support to libpcap to capture
> > from the Linux /dev/input/event* (evdev) devices.  Draft patch is
> > included below.
> >
> > However, I've realised there's a problem.  Since it's an internal-only
> > protocol, the evdev devices return packets which are in native-endian
> > format.  Obviously that's problematic once the packets go into pcap
> > files which could be moved to other machines.
> >
> > As I see it, I have 3 options here:
> >1. Ask for a second DLT_ value, and use different DLT values
> > for the capture depending on the endianness of the capturing machine.
> >2. Covert the packets at capture time to either little or
> > big-endian (arbitrary choice).
> >3. Capture and record in native-endian, and rely on programs
> > reading the pcap file to deduce the endianness from other data.  This
> > will generally be possible in practice because the 16-bit 'type' field
> > has no assigned values above 0xff.
> >
> > I'm inclined towards option (2), but I don't know if there's a
> > pre-existing libpcap rule of thumb about this sort of thing.
> >
> 
> I think 3 is a fair choice.
> There are several examples of protocols in wireshark already where it
> has to resort to heuristics like that in order to determine how to
> decode the packets.

Hrm, I guess.  I'm uneasy about it, since 0 is a valid value for that
field, so you won't always be able to tell from a single packet.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.