Re: [tcpdump-workers] Request for DLT for Linux Kernel Messages

2013-12-30 Thread Michal Labedzki
On 30 December 2013 00:20, Guy Harris  wrote:
> ...and the packet format is just a line containing text, so that the packet 
> data is just N bytes of text (presumably without an NL at the end), with a 
> bunch of comma-separated fields giving priority/sequence number/time 
> stamp/text?  Where are the fields documented?


Documentation is provided by Linux Kernel:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/ABI/testing/dev-kmsg?id=refs/tags/v3.12

> priority/sequence number/time stamp/text?

And "text" can be dissected too, because there can be more then one
line, first line seems to be always "human readable text", next are
similar (the same) as "udev" events (SUBSYSTEM=*; DEVICE=*)
My idea is:
libpcap goal: capture kernel logs, it is important context info
Wireshark goal: filterable kernel logs, for example timestamp delta
0.4s and character device with major < 196.
-- 

Pozdrawiam / Best regards
-
Michał Łabędzki, Software Engineer
Tieto Corporation

Product Development Services

http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal Labedzki
location: Swobodna 1 Street, 50-088 Wrocław, Poland
room: 5.01 (desk next to 5.08)
---
Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorised use, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the message and deleting it from your computer. Thank You.
---
Please consider the environment before printing this e-mail.
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON:
812023656. Kapitał zakładowy: 4 271500 PLN
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] Failing tcpdump 4.5.1 testsuite

2013-12-30 Thread Petar

On 12/12/2013 11:02 PM, Romain Francoise wrote:

Michael Richardson  writes:


True... I'm not sure that we have, up until now, considered this a
problem.

I don't think we've ever had this problem; at least I always update
tcpdump first in Debian (just in case) and this is the first time this
happens.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Should simple C endianess test be done before decoding nflog TVL length?
Is this considered as the solution?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] tcpdump configure error with pcap_loop... no

2013-12-30 Thread Denis Ovsienko
23.12.2013, 21:48, "Evgheni Antropov" :

>  Hello I have try to compile tcpdump-4.5.1.tar.gz with libpcap-1.5.2.tar.gz
>   and receive following error:
>
>  checking for pcap-config... /usr/local/bin/pcap-config
>  checking for pcap_loop... no
>  configure: error: Report this to tcpdump-workers@lists.tcpdump.org, and
>  include the
>  config.log file in your report.  If you have downloaded libpcap from
>  tcpdump.org, and built it yourself, please also include the config.log
>  file from the libpcap source directory, the Makefile from the libpcap
>  source directory, and the output of the make process for libpcap, as
>  this could be a problem with the libpcap that was built, and we will
>  not be able to determine why this is happening, and thus will not be
>  able to fix it, without that information, as we have not been able to
>  reproduce this problem ourselves.

List,

last week I ran into this issue once but could not reproduce afterwards. My 
guess is this error is specific to non-straightforward builds of libpcap and/or 
leftovers across multiple build attempts.

It happened once as follows (please note Sabotage uses musl instead of glibc 
and libnetlink-tiny instead of libnetlink):

# (at a Linux host)
wget 
http://ftp.barfooze.de/pub/sabotage/sabotage-0.9.14-i386-66f57ca1-core.img.xz
unxz sabotage-0.9.14-i386-66f57ca1-core.img.xz
VBoxManage convertfromraw sabotage-0.9.14-i386-66f57ca1-core.img 
sabotage-0.9.14-i386-66f57ca1-core.vdi
VirtualBox & # add a new x86_64 VM using the .vdi disk image and powered it on

# (inside VM as root)
adduser tcpdump
passwd tcpdump

# (inside VM as tcpdump)
git clone git://github.com/the-tcpdump-group/libpcap.git
git clone git://github.com/the-tcpdump-group/tcpdump.git

Then I tried to compile libpcap without and with ("butch install autoconf" as 
root) autoconf, without and with .devel, without and with the following hacks:

-
diff --git a/Makefile.in b/Makefile.in
index 31f3bdb..58f93d7 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -744,4 +744,4 @@ releasetar:
   rm -rf $$name
 
 depend:$(GENSRC) $(GENHDR) bpf_filter.c
-   $(MKDEP) -c $(CC) -m $(DEPENDENCY_CFLAG) $(DEFS) $(INCLS) $(SRC)
+   $(MKDEP) -c $(CC) -m $(CFLAGS) $(DEPENDENCY_CFLAG) $(DEFS) $(INCLS) 
$(SRC)
diff --git a/configure b/configure
index be87668..31a2dcc 100755
--- a/configure
+++ b/configure
@@ -5619,7 +5619,7 @@ if test "x$ac_cv_lib_nl_nl_socket_alloc" = xyes; then :
#
# Yes, we have libnl 2.x.
#
-   LIBS="-lnl-genl -lnl $LIBS"
+   LIBS="-lnl $LIBS"
 
 $as_echo "#define HAVE_LIBNL 1" >>confdefs.h
 
diff --git a/configure.in b/configure.in
index 2cae646..b53fb15 100644
--- a/configure.in
+++ b/configure.in
@@ -473,7 +473,7 @@ linux)
#
# Yes, we have libnl 2.x.
#
-   LIBS="-lnl-genl -lnl $LIBS"
+   LIBS="-lnl $LIBS"
AC_DEFINE(HAVE_LIBNL,1,[if libnl exists])
AC_DEFINE(HAVE_LIBNL_2_x,1,[if libnl exists and 
is version 2.x])
AC_DEFINE(HAVE_LIBNL_NLE,1,[libnl has 
NLE_FAILURE])
-

The configure call evolved over time and became the following:

CFLAGS=`-I/usr/include/libnl-tiny` \
LDFLAGS=`pkg-config --libs-only-L libnl-tiny` \
LIBS=`pkg-config --libs-only-l libnl-tiny` \
./configure

Eventually libpcap built OK (may be on 10th attempt), I ran ./configure in 
../tcpdump and observed the "Report this to tcpdump-workers@lists.tcpdump.org" 
boilerplate. A few more  "make clean all" passes in libpcap directory later I 
checked again on the tcpdump side and the issue had vanished.

-- 
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers