[tcpdump-workers] Support building libpcap on Unix'ish OS's with remote pcap support
Hello,
the attached patch is an attempt to get remote pcap working on macOS (and other
Unix'ish operating systems).
I then rebuild Wireshark and managed to configure a remote capture session.
Unfortunately
I don't have an AP or other testdevice available right now. I *may* find a
chance and time
on Friday to test this with an Extremenetworks AP.
What this patch does:
- Move remote-ext.h to pcap/remote-ext.h (plus necessary autotools changes):
Inside pcap/ is a more consistent place to put it.
- Fix a small typo in a comment in remote-ext.h
- Add the necessary autotools changes for --enable-rpcap to compile and link.
With that said: When I open the rpcap dialog in Wireshark, I get an error
message
but Wireshark continues without crashing:
(process:93925): GLib-CRITICAL **: guint g_hash_table_size(GHashTable *):
assertion `hash_table != NULL' failed
But that is most likely a Wireshark issue.
While I'm at it: Does anyone know of a working rpcap server on Unix?
Please consider adding this patch (or maybe something inspired by it :-)
If not, please let me know what is missing to get rpcap support on Unix.
Thanks
Jörg
--
Joerg Mayer
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
>From 839e665b9f7240ac26a3dcbaebeae8dc0ed8c774 Mon Sep 17 00:00:00 2001
From: Joerg Mayer
Date: Fri, 28 Oct 2016 10:12:20 +0200
Subject: [PATCH] Support building with rpcap (--enable-rpcap)
Signed-off-by: Joerg Mayer
---
Makefile.in | 5 +++--
config.h.in | 3 +++
configure | 19 +++
configure.ac | 11 +++
pcap/pcap.h | 2 +-
remote-ext.h => pcap/remote-ext.h | 2 +-
6 files changed, 38 insertions(+), 4 deletions(-)
rename remote-ext.h => pcap/remote-ext.h (99%)
diff --git a/Makefile.in b/Makefile.in
index 7044f04..eba68dd 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -79,7 +79,8 @@ YACC = @YACC@
@rm -f $@
$(CC) $(FULL_CFLAGS) -c $(srcdir)/$*.c
-PSRC = pcap-@V_PCAP@.c @USB_SRC@ @BT_SRC@ @BT_MONITOR_SRC@ @NETFILTER_SRC@
@DBUS_SRC@
+PSRC = pcap-@V_PCAP@.c @USB_SRC@ @BT_SRC@ @BT_MONITOR_SRC@ @NETFILTER_SRC@ \
+ @DBUS_SRC@ @RPCAP_SRC@
FSRC = @V_FINDALLDEVS@
SSRC = @SSRC@
CSRC = pcap.c inet.c gencode.c optimize.c nametoaddr.c \
@@ -106,6 +107,7 @@ PUBHDR = \
pcap/namedb.h \
pcap/nflog.h \
pcap/pcap.h \
+ pcap/remote-ext.h \
pcap/sll.h \
pcap/vlan.h \
pcap/usb.h
@@ -345,7 +347,6 @@ EXTRA_DIST = \
pcap-usb-linux.c \
pcap-usb-linux.h \
pcap-win32.c \
- remote-ext.h \
sockutils.c \
sockutils.h \
scanner.l \
diff --git a/config.h.in b/config.h.in
index 7f6115d..b02873e 100644
--- a/config.h.in
+++ b/config.h.in
@@ -127,6 +127,9 @@
/* define if net/pfvar.h defines PF_NAT through PF_NORDR */
#undef HAVE_PF_NAT_THROUGH_PF_NORDR
+/* enable remote capture protocol support */
+#undef HAVE_REMOTE
+
/* define if you have the Septel API */
#undef HAVE_SEPTEL_API
diff --git a/configure b/configure
index 7af37bc..4842b6d 100755
--- a/configure
+++ b/configure
@@ -623,6 +623,7 @@ ac_subst_vars='LTLIBOBJS
INSTALL_DATA
INSTALL_SCRIPT
INSTALL_PROGRAM
+RPCAP_SRC
PCAP_SUPPORT_PACKET_RING
DBUS_SRC
PCAP_SUPPORT_DBUS
@@ -752,6 +753,7 @@ enable_usb
enable_bluetooth
enable_dbus
enable_packet_ring
+enable_rpcap
'
ac_precious_vars='build_alias
host_alias
@@ -1392,6 +1394,7 @@ Optional Features:
--enable-dbus enable D-Bus capture support [default=yes, if
support available]
--enable-packet-ringenable Linux packet ring support [default=yes]
+ --enable-rpcap enable remote capture protocol support [default=no]
Optional Packages:
--with-PACKAGE[=ARG]use PACKAGE [ARG=yes]
@@ -8956,6 +8959,22 @@ $as_echo "#define PCAP_SUPPORT_PACKET_RING 1"
>>confdefs.h
fi
+# Check whether --enable-rpcap was given.
+if test "${enable_rpcap+set}" = set; then :
+ enableval=$enable_rpcap;
+else
+ enable_rpcap=no
+fi
+
+
+if test "x$enable_rpcap" != "xno" ; then
+
+$as_echo "#define HAVE_REMOTE 1" >>confdefs.h
+
+ RPCAP_SRC="pcap-new.c pcap-rpcap.c sockutils.c"
+
+fi
+
# Find a good install program. We prefer a C program (faster),
# so one script is as good as another. But avoid the broken or
# incompatible versions:
diff --git a/configure.ac b/configure.ac
index a2b31d4..6f5fd5d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1817,6 +1817,17 @@ if test "x$enable_packet_ring" != "xno" ; then
AC_SUBST(PCAP_SUPPORT_PACKET_RING)
fi
+dnl Support remote capture
+AC_ARG_ENABLE([rpcap],
+[AC_HELP_STRING([--enable-rpcap],[enable remote capture protocol support
@<:@default=no@:>@])],
+,enable_rpcap=no)
+
+if test "x$enable_rpcap" != "xno" ; then
+ AC_DEF
Re: [tcpdump-workers] Support building libpcap on Unix'ish OS's with remote pcap support
Hello, after waiting for the message to time out in moderation, subscribing, waiting some more, I should have reread the message instead of just bouncing it... The patch itself is still valid, I just made a bit of progress on the Wireshark side, so please ignore that part (current status: see next mail). Ciao Jörg On Tue, Feb 14, 2017 at 01:37:51AM +0100, Joerg Mayer wrote: > the attached patch is an attempt to get remote pcap working on macOS (and > other > Unix'ish operating systems). ... > With that said: When I open the rpcap dialog in Wireshark, I get an error > message > but Wireshark continues without crashing: > (process:93925): GLib-CRITICAL **: guint g_hash_table_size(GHashTable *): > assertion `hash_table != NULL' failed > But that is most likely a Wireshark issue. -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] rpcap support on non-windows
Hello, I'm trying to get libpcap working on macOS. With the previously sent patch I am able to build libpcap with rpcap support. dumpcap (from Wireshark) compiles and links fine with the new version and it does a bit of rpcap communication with my rpcap server (an AP) and after that it segfaults. Compiling and linking (both dumpcap and libpcap) with asan gave me the output below (after some rpcap traffic on the network). Trying to understand the problem it looks like accessing struct pcap_md (the rpcap specific stuff) is broken on non-win32 platforms (or at least on bpf platforms). The intended memory layout seems to be: struct pcap_t (containing a pointer to priv if it exits) priv: struct pcap_ struct pcap_md (if compiling with HAVE_REMOTE) The current implementation seems to a) only allocate the memory for pcap_md on win (pcap_create_interface() in pcap-win32.c), thus causing an out of bounds access on other platforms. b) the access to pcap_md is calculated as priv + sizeof(struct pcap_win) on all platforms which gets redeclared in pcap-new.c and pcap-rpcap.c for just this purpose. This looks wrong to me but I'm not sure. Anyone willing to look into this? Thanks Jörg jmayer@newegg:~/worktmp/wireshark$ dumpcap -r -i 'rpcap://10.122.4.11/wifi0' Capturing on 'rpcap://10.122.4.11/wifi0' = ==45693==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6160b158 at pc 0x00010886d3d5 bp 0x7fff57442bf0 sp 0x7fff57442be8 WRITE of size 4 at 0x6160b158 thread T0 #0 0x10886d3d4 in pcap_opensource_remote pcap-rpcap.c:833 #1 0x10886b4db in pcap_open pcap-new.c:934 #2 0x1087ccad7 in open_capture_device capture-pcap-util.c:1322 #3 0x1087b87aa in main dumpcap.c:2196 #4 0x7fffd7e02254 in start (libdyld.dylib+0x5254) 0x6160b158 is located 40 bytes to the left of 528-byte region [0x6160b180,0x6160b390) allocated by thread T0 here: #0 0x108be0157 in wrap_calloc (libclang_rt.asan_osx_dynamic.dylib+0x4b157) #1 0x7fffd7512e6b in allocateBuckets(unsigned int) (libobjc.A.dylib+0x8e6b) #2 0x7fffd7512dfa in cache_t::reallocate(unsigned int, unsigned int) (libobjc.A.dylib+0x8dfa) #3 0x7fffd7512626 in cache_fill (libobjc.A.dylib+0x8626) #4 0x7fffd7511c3d in lookUpImpOrForward (libobjc.A.dylib+0x7c3d) #5 0x7fffd75115d3 in _objc_msgSend_uncached (libobjc.A.dylib+0x75d3) #6 0x7fffc289b94c in CFArraySortValues (CoreFoundation+0x7894c) #7 0x7fffc947df9d in _SCNetworkInterfaceCopyAllWithPreferences (SystemConfiguration+0xaf9d) #8 0x1087c9c1a in if_info_new capture-pcap-util.c:158 #9 0x1087caa9e in get_interface_list_findalldevs capture-pcap-util.c:531 #10 0x1087b2375 in capture_opts_add_iface_opt capture_opts.c:591 #11 0x1087b0566 in capture_opts_add_opt capture_opts.c:794 #12 0x1087b6acc in main dumpcap.c:4153 #13 0x7fffd7e02254 in start (libdyld.dylib+0x5254) SUMMARY: AddressSanitizer: heap-buffer-overflow pcap-rpcap.c:833 in pcap_opensource_remote Shadow bytes around the buggy address: 0x1c2c15d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c2c15e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c2c15f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c2c1600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c2c1610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x1c2c1620: fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa fa 0x1c2c1630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c2c1640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c2c1650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c2c1660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c2c1670: 00 00 fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==45693==ABORTING Abort trap: 6 -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
