truct of my header data (with other
structs nested maybe) and this struct is asociated as DLT_USER0. Or a
something similar?
Thanks in advance
BR Christian
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
with the symbol in dlt.h?
Thanks for your help again
BR Christian
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
--- Begin Message ---
Maybe this should be also mentioned within the libpcap module howto?
https://www.tcpdump.org/libpcap-module-HOWTO.html
BR Christian
Make sure that libpcap.a includes pcap-kpnode.o, by making sure that
pcap-kpnode.c is in the list of source modules to be compiled and
MODULE_C_SRC = @MODULE_C_SRC@ pcap-kpnode.c
And this solved the problem, now I can configure and build tcpdump. Even
with my extensions
Thank you very much.
BR Christian
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers
E='tcpdump'
PACKAGE_STRING='tcpdump 5.0.0-PRE-GIT'
PACKAGE_TARNAME='tcpdump'
PACKAGE_URL=''
PACKAGE_VERSION='5.0.0-PRE-GIT'
PATH_SEPARATOR=':'
PCAP_CONFIG='../libpcap/pcap-config'
PKG_CONFIG=&
--- Begin Message ---
Am 15.08.22 um 20:09 schrieb Guy Harris:
What are the contents of config.log?
Ohhh f**. Ok sorry it's moday afternoon
here it comes:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was crea
--- Begin Message ---
Then I opened the tcpdump.zip archive
(.zip? Not .tar.gz? The current releases from
https://www.tcpdump.org/index.html#latest-releases
are provided in .tar.gz form, as are all the other release in
https://www.tcpdump.org/release/
Gzipped tarballs are pr
a Pine64 board with Armbian 22.05.3 Bullseye
What could be the problem here? I have some changes for tcpdump for
processing my kpnode packages, but I did not apply them for now. Because
the tcpdump from upstream was not able to configure, even without my
changes.
Thanks in advance
BR Chr
--- Begin Message ---
forget to evoke autoconf again, now it's within the library and I have
to do the next step.
Thank you so far
BR Christian
> ___
> tcpdump-workers mailing list
> tcpdump-workers@lists.tcpdump.org
> https://l
of module source files in
> Makefile.in *before* configuring, or you added it to another source file
> list, or you did something else.
>
> Which of those did you do?
This time I did not touch the makefile after invoke configure. I made
the changes to the configure.ac file you suggested, and no editing of
the makefile any more. As I mentioned, the kpnode symbol appear in the
list with a capital U:
U kpnode_findalldevs
U kpnode_create
Thank you
BR Christian
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
binary but there is an object file of my handler file
pcap-kpnode.c. So my changes are not in the library. I use the master
branch sources of last week and gcc version 11.2.0 of Debian testing.
What did I miss to integrate my handlers into pcap library?
Thank you in advance
B
b Guy Harris:
On Jul 28, 2016, at 7:12 AM, Christian
wrote:
I have encountered a problem.
I am capturing Packages with hardware timestamps and nanosecond precision...but
the timestamps are bugged.
sadly I'm not at the place where I captured the data, so the used used command
might b
48 1469090573977637547
49 146909057415410642
50 146909057415422849
760 146909057496979035
761 146909057496991243
770 1469090574135096345
771 1469090574135118217
Thank you in advance for any help in the matter.
Greeting,
Christian
_
The experiments I made today actually suggest that in my case tcpdump
uses the hardware clock for incoming packages and the software/unix
clock for outgoing packages.
I changed the System clock of one Server with date -s and then looked at
the capture of Ping packages.
Incoming packages on the
Yes, the exact same packet.
Am 08.06.2016 um 22:40 schrieb Guy Harris:
On Jun 8, 2016, at 1:29 PM, Christian Rupp
wrote:
The Timestamp when tcpdump grabs the package off of the receiver is 36 seconds(
+/- innaccuracy, here roughly +/- 5-10 µs) after the timestamp when tcpdump
grabs the
nario, given that the software timestamping option and the -j adapter
option both result in a ~ 100-200µs one way delay
Am 08.06.2016 um 22:13 schrieb Guy Harris:
On Jun 8, 2016, at 5:53 AM, Christian
wrote:
Now, my results in itself make sense and would give me the desired results, but
they h
k as the measurement, and on a different link, synchronising the
clocks with phc2sys. Both implementations had the 36s error)
Am 08.06.2016 um 16:24 schrieb Michael Richardson:
{please keep it on the list for archival purposes}
Christian wrote:
> between sender and receiver
&
too.
As a test run I changed the system clock of one of the servers and the
change showed up on the results while using -j adapter_unsynced.
So my question is: What am I doing wrong, and is what I want to do even
possible with tcpdump?
I'm thankfull for any advice.
Greet
Hi Guy,
thanks for your answers.
>
> On Oct 23, 2015, at 7:04 AM, Christian Gieseler
wrote:
>
>> I have a receive thread in my program which shall capture frames
according
>> to a filter. The Host is sending frames with the same multicast
destination
>> mac as
{
memcpy (buffer, pkt_data, pkt_header->len);
ProcessPaket (buffer, pkt_header->len);
}
}
pthread_exit (NULL);
return NULL;
}
Thanks for reading and any hint
Best
From: Christian Bell
Can be squashed with previous patch, if previous is acceptable.
---
configure.in |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/configure.in b/configure.in
index 4a7c629..46f45c7 100644
--- a/configure.in
+++ b/configure.in
@@ -1082,7
ered like to install external packages in non-standard locations.
Nevertheless, I'll proceed with only modifying LIBS= and seeing what
the fallout is. If it turns out to be a hassle, we'll just modify how
we build libpcap.so.
. . christian
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
From: Christian Bell
This patch adds support for our NICs when run in a specialized capture mode.
It is diffed against the current master.
The Myricom Sniffer10G software uses Myri-10G programmable Network Interface
Cards (NICs), a firmware extension, a specialized driver and a user-level
From: Christian Bell
This patch allows libpcap.a and libpcap.so to include object files from a
static library archive instead of just a list of .o files.
I'm only including the Makefile.in part because I just want feedback on whether
this would be acceptable practice. I'm preparin
---
Makefile.in | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Makefile.in b/Makefile.in
index 53801c1..96d5d47 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -126,7 +126,7 @@ TAGFILES = \
$(SRC) $(HDR)
CLEANFILES = $(OBJ) libpcap.* filtertest findallde
All,
I have included a patch for review. This adds zero-copy bpf support
to libpcap. It should be noted that I've tried to incorporate all
the feedback that I recieved after the previous submission.
There was one un-related fix in this patch:
Index: configure.in
===
arris wrote:
> Christian S.J. Peron wrote:
> >I have attached the patch that we have been using. This is a patch for the
> >libpcap code in FreeBSD -CURRENT right now. It appears to work well, but
> >you folks might have some ideas for getting the necessary autoconf magic
> &g
It would be great to
> >have a snap which can do this too. Christian Peron (CC'd) has been
> >responsible for the code.
>
> That means that we *don't* want to take what we have now and release it,
> as we don't currently have any code that supports zero-copy BPF. W
he program still doesn't recognize that this a wlan-interface and
of course I did not get the proper MAC-addresses
:-(
This is very sad. How can anybody sniff a wlan-traffic?
Gruss Christian
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
monitor mode.)
This seems to be something like virtual AP, I don't know exactly the
purpose of that interface and why its created by default. But its the
only interface which I can select with wireshark witout hanging.
Gruss Christian
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
n[0:2] & 0xF1 != 0".
But this is not the problem I think, its still that I don't get valid
MAC-adress.
Gruss Christian
Original-Nachricht
> Datum: Fri, 15 Feb 2008 10:23:48 -0600 (CST)
> Von: alexander medvedev <[EMAIL PROTECTED]>
> An: tcpdump-worke
wifi0-interface, both related to my
atheros-card?
Gruss Christian
Original-Nachricht
> Datum: Fri, 15 Feb 2008 08:49:10 -0600 (CST)
> Von: alexander medvedev <[EMAIL PROTECTED]>
> An: tcpdump-workers@lists.tcpdump.org
> Betreff: Re: [tcpdump-workers] problem whil
eader *) packet;
snprintf(insertvalues,255, "default-s: %s",ether_ntoa_r((struct
ether_addr*) (ethprt->ether_shost), insertbuffer ));
printf("%s\n", insertvalues);
}
But the result is the same. Its still the first four fields of my MAC-address
but the final
ess, but the last two fields are anything nonsence.
A yes, I want to note, that I use Linux not BSD.
Gruss Christian
Original-Nachricht
> Datum: Thu, 14 Feb 2008 10:51:25 -0800
> Von: Guy Harris <[EMAIL PROTECTED]>
> An: tcpdump-workers@lists.tcpdump.org
> B
t of my mac-adress. The first and the
second field are just trash, the last 4 field are really showing my
mac-adresse, but only the first four fields of course!
I also tried this with casting to ethernet-frames but came out with the same
result. What is wrong here? Can anybody help?
local stacks from
seeing the affected packets.
Cheers,
Christian.
--
http://www.cl.cam.ac.uk/~cpk25
http://www.whoop.org
-
This is th
t/doco/libpcapnav/pcapnav-pcapnav.html#PCAPNAV-DUMP-OPEN
Cheers,
Christian.
--
http://www.cl.cam.ac.uk/~cpk25
http://www.whoop.org
-
Th
There's also the possibility of the SE Linux default configuration
shipped with FC4 causing trouble. Try disabling it and see if the error
persists?
Cheers,
Christian.
--
Hi Evan,
if Guy's points aren't a concern for you, you can just use libpcapnav.
It provides pcapnav_get_offset() which does what you want.
http://netdude.sourceforge.net/doco/libpcapnav/index.html
Cheers,
^^
> pkts.push_back(*curr);
>
> Any inputs? Thank you.
> -Thinh
Cheers,
Christian.
--
http://www.cl.cam.ac.uk/~cpk25
have to contain packets
any more), so this should work even better now.
While I think nothing's wrong with a good "toc" structure for the new
format, I think it's at least as important to provide good clues to free
fseek()s to find their way back i
ent experience is limited to a little bit of mingw.
Thanks,
Christian.
--
http://www.cl.cam.ac.uk/~cpk25
http://www.
(print-ascii.c), or how I did it in the
hex/ascii widget in Netdude (look for hex_get_hex_text() and
hex_get_ascii_text()):
http://cvs.sourceforge.net/viewcvs.py/netdude/netdude/src/gtkhex.c?rev=1
On Wed, 2004-06-30 at 12:50, Michael Richardson wrote:
> -BEGIN PGP SIGNED MESSAGE-
>
>
> >>>>> "Christian" == Christian Kreibich <[EMAIL PROTECTED]> writes:
> Christian> proposal that while I personally think an XML capture
> C
back then I suggested in
context of Jefferson's XML proposal that while I personally think an XML
capture format is not the right idea, an XML based tcpdump output would
be great in the long term -- it would certainly eliminate a lot o
ddreses to names --
sounds like you have a resolver problem. Try again using -n or -nn
options.
Best,
Christian.
--
http://www.cl.cam.ac.uk/~cpk25
On Wed, 2004-04-21 at 17:09, Christian Kreibich wrote:
> pretty much harmless -- you'll just lose that incomplete last byte in
That should have been "packet"
eld
back all packets and your output file is empty -- you shouldn't get an
error message on such a file though, as a pcap trace file containing no
packets is perfectly valid.
"bogus savefile header" means that a pcap header in front of a packet in
a trace contains obviously incorrec
, you can
always encode length values in those headers anyway to keep things
flexible in the first place.
I don't like the idea of XML as the lowest common denominator for a
capture format -- as a processing-stage output it sounds great to me.
Regards,
Christian.
--
ink what you're proposing should be provided by an xmlified tcpdump,
but not the capture library.
Regards,
Christian.
--
http://www.cl.cam.ac.uk/~cpk25
le (how to display? discard what you
don't understand? keep it? ...) then I'm not sure if it's worth it.
Just imho.
Best regards,
Christian.
--
http://www.cl.cam.ac.uk
51 matches
Mail list logo
