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
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
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
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
_
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
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
, 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.
--
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
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"
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
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
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
(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
ent experience is limited to a little bit of mingw.
Thanks,
Christian.
--
http://www.cl.cam.ac.uk/~cpk25
http://www.
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
^^
> pkts.push_back(*curr);
>
> Any inputs? Thank you.
> -Thinh
Cheers,
Christian.
--
http://www.cl.cam.ac.uk/~cpk25
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,
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.
--
t/doco/libpcapnav/pcapnav-pcapnav.html#PCAPNAV-DUMP-OPEN
Cheers,
Christian.
--
http://www.cl.cam.ac.uk/~cpk25
http://www.whoop.org
-
Th
local stacks from
seeing the affected packets.
Cheers,
Christian.
--
http://www.cl.cam.ac.uk/~cpk25
http://www.whoop.org
-
This is th
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?
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
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
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
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
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.
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.
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
===
---
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
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
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
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
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
{
memcpy (buffer, pkt_data, pkt_header->len);
ProcessPaket (buffer, pkt_header->len);
}
}
pthread_exit (NULL);
return NULL;
}
Thanks for reading and any hint
Best
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
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
&
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
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
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
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
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
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
--- 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
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 ---
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
--- 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
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=&
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
--- 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
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
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
51 matches
Mail list logo
