sting "tcp[tcpflags]" grammar, and adding the tcp-ae
flag.
https://github.com/the-tcpdump-group/libpcap/pull/1210
Richard Scheffenegger
--- End Message ---
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe s
r to make some progress, I suggest to split off the part of the patch,
which allows access to all 12 TCP header flags, and submit that separately;
This could be committed together with the adjacent change to libpcap (the
parser decoding the literal "tcp[tcpflags]" string to provide
all on this with the tcpdump
project approximately 2 years ago, when updating the tooling was an area of
very active development
Richard Scheffenegger
-Original Message-
From: Michael Richardson
Scheffenegger, Richard wrote:
> Tcpdump - any every tool afterwards - has b
all on this with the tcpdump
project approximately 2 years ago, when updating the tooling was an area of
very active development
Richard Scheffenegger
-Original Message-
From: Michael Richardson
Scheffenegger, Richard wrote:
> Tcpdump - any every tool afterwards - has b
--- Begin Message ---
And some initial discussions which aren't yet reflected on the mailing list:
-Original Message-
From: Scheffenegger, Richard
Sent: Freitag, 18. August 2023 14:01
To: Francois-Xavier Le Bail ;
tcpdump-workers@lists.tcpdump.org
Cc: Denis Ovsienko ; Guy Harris ;
iffs?commit_id=ecefcf880121961c03d2ec05ad378c82e951e0a2
Richard Scheffenegger
--- End Message ---
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)sli
ncpu
hw.model: Intel(R) Celeron(R) CPU G1620 @ 2.70GHz
hw.machine: amd64
hw.ncpu: 2
# uname -v
FreeBSD 11.2-STABLE #9: etc
# tcpdump --version
tcpdump version 4.9.2
libpcap version 1.9.0
OpenSSL 1.0.2o-freebsd 27 Mar 2018
--
richard Richard
On Mon, 16 Jun 2014 13:11:22 +0200
Romain Francoise wrote:
> richard lucassen writes:
>
> > Is this a bug or has this been changed?
>
> Are you using Debian or a derivative like Ubuntu? The tcpdump package
> used to have a patch to reverse the meaning of the -e flag, b
or has this been changed?
R.
--
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.
+------
Hi, I am having problems capturing some packets using tcpdump.
At the application level I am sending and receiving packets but tcpdump
does not capture any data.
There are no packets dropped by the kernel
I have tried reducing the packet data captured (-s option) to different
labels without any cha
There are two simple cases to rule out:
1. The capture was taken using a Napatech or Endace card, which uses its own
clock which may or may not be in sync with the host clock.
2. There's an unexpected local timezone on the machine used to read and
display the packet capture. Is your client
Like many people here, i've used tcpdump (or libpcap) to write data acquisition
gadgets that then report up to some higher tier.
If you wanted to build one without doing all the messy libpcap and socket
calls, you could chain tcpdump, a little awk, and nc (netcat) together. It
wouldn't be inc
itely use such a feature.
Richard
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
a post Guy Harris made --
really changed the way I develop filters.
Sincerely,
Richard
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Guy Harris wrote:
Richard Stearn wrote:
Adding DLT_AX25_KISS is the obvious way to go with the exception that
Linux
identifies AX.25 in KISS packets as DLT_AX25 (protocol 3).
"Identifies" in what sense?
As in returns 3 as an identifier of the protocol type.
I don't
Guy Harris wrote:
Richard Stearn wrote:
What the implementors of AX.25 on Linux have done is to hand an KISS
packet rather than a pure AX.25 packet to the protocol stack. This
probably was to accomodate the existing base of hardware where packets
were delivered to the system via an async
Guy Harris wrote:
Richard Stearn wrote:
+ case DLT_AX25:
+ /*
+ * Currently, only raw "link[N:M]" filtering is supported.
+ */
+ off_linktype = -1;/* variable, min 15, max 71 steps of 7 */
+ off_nl = -1;/* variable, min 16, ma
Greetings
The definition of DLT_AX25 already exists (protocol 3).
The attached patch adds recognition for the Amateur Radio AX.25 protocol
to libpcap.
This is an updated patch to my previous request.
--
Regards
Richard
*** reference/libpcap-0.9.5/gencode.c 2006-09-13 08:36
.
Longer term I would hope to add address matching but this may be
non-trivial so I would like to get basic capture in place.
--
Regards
Richard
*** reference/libpcap-0.9.5/gencode.c 2006-09-13 08:36:19.0 +0100
--- modified/libpcap-0.9.5/gencode.c2006-12-05 23:35:00.0
re/flowgrep/
?
Sincerely,
Richard
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Level: pcaplib novice
OS: Linux 2.6.20
I've been running a pcaplib app that reads continually from a network switch
port and processes a well-defined application protocol. Let's say the
network interface it reads from is 'eth0'.
I need to augment this app to handle the failover to a differ
s,
> that won't help.
Can I send a signal myself to get it to terminate cleanly? If so, is there a
good reference for how to do this? (Sorry, I'm new to C and *nix programming
and I don't know much about signals.)
Thanks,
Richard
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
7;t tried it out, libnet (http://www.packetfactory.net/libnet/)
looks like it can dissect ARP (along with a bunch of other protocols).
Hope this helps,
Richard
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
other packet arrives. Is this
expected or proper behavior? How can I tell Linux to return from that
readfrom() call that it's blocking on?
Thank you!
Richard
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Ack. I didn't even think to be suspicious of the compiler.
When I turned the gcc compiler optimization for libpcap from
-O2 to -O0 (optimization off), the tcpdump started working
fine. I further narrowed it down to the -fstrict-aliasing
optimization. So I can settle on optimzations set to:
-O2 -fn
Was it assumed that if JT(x) is true, then so should JF(x)?
Is it legal to assume this? Should JF(x) always be true if
JT(x) is true?
I would appreciate any advice you might have.
-Richard Stefanich
Professional Computing Resources
Kentwood MI
[EMAIL PROTECTED]
--
-
This
Guy Harris wrote:
Richard Stearn wrote:
A cursory look at the print-ax25 from that patch indicates that some
of the support is missing, e.g. ARP printing for ax25 is not in the
current tcpdump.org tcpdump. So somewhere between tcpdump 3.4 & 3.9
the ax.25 support was taken out.
That pres
Guy
Thank you for the quick reply.
Guy Harris wrote:
Richard Stearn wrote:
Has there been any development effort in the past on any of the
above protocols?
The only thing I was able to find from a quick Google was a patch at
http://www.tux.org/pub/net/ip-routing/lbl-tools
development effort in the past on any of the
above protocols?
Would the changes needed to support these protocols be accepted?
--
Regards
Richard
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
- Original Message -
From: "Guy Harris" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, July 12, 2005 3:15 AM
Subject: Re: [tcpdump-workers] FreeBSD 5.4 & PCAP: blocked read() on
pcap_lookupnet()
> Richard Huddleston wrote:
>
> > (gdb) where
> > #0 0x2
FreeBSD 5.4
"Stock" pcaplib
I'm blocking on a read() invoked by pcap_lookupnet():
Program received signal SIGINT, Interrupt.
0x280ee6fb in read () from /lib/libc.so.5
(gdb) where
#0 0x280ee6fb in read () from /lib/libc.so.5
#1 0x28090c57 in pcap_lookupnet () from /usr/lib/libpcap.so.3
#2 0x280
- Original Message -
From: "Guy Harris" <[EMAIL PROTECTED]>
To:
Sent: Monday, July 11, 2005 1:49 PM
Subject: Re: [tcpdump-workers] FreeBSD 5.4 & BIOCSRTIMEOUT &
pcap_open_live()
> Richard Huddleston wrote:
> > Freshly installed FreeBSD 5.4. New user o
Freshly installed FreeBSD 5.4. New user of FreeBSD.
pcap_open_live() fails with a
BIOCSRTIMEOUT: Invalid argument
pcap_open_live( device, BUFSIZ, 1, -1, errbuf )
The 'to_ms' argument is the obvious candidate, since when I change it to a
non-negative value pcap_open_live() initializes fine
> proposing an Internet Draft that defines a standard network trace format.
I definitely think that this is the right thing to do. I am happy to help
review etc the documents ...
Regards
-
Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http:/
On Fri, 2 Apr 2004, Guy Harris wrote:
>
> On Mar 25, 2004, at 9:31 AM, Richard Sharpe wrote:
>
> > One of the items I would like support for in a new format is comments.
> > That is, the ability to add textual comments to frames. These comments
> > would be i
35 matches
Mail list logo
