teed that the underlying NIC HW
isn't doing Large Receive Offload, or that the tracepoint in the stack
is below any stack's attempt to do Generic Receive Offload?
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Fri, 2011-05-27 at 10:39 -0700, Guy Harris wrote:
> On May 27, 2011, at 10:16 AM, Rick Jones wrote:
>
> > Is this new libpcap going to be guaranteed that the underlying NIC HW
> > isn't doing Large Receive Offload, or that the tracepoint in the stack
> > is be
The ifSpeed field of a generic interface counter in sFlow is 64 bits.
The "overlay" definition in print-sflow.c is correct, but the actual
extract for printing is using EXTRACT_32BITS rather than EXTRACT_64BITS,
which leads to an incorrect report for speed.
Signed-off-by: Rick Jones
On Thu, 2011-06-02 at 10:57 -0700, Guy Harris wrote:
> On May 27, 2011, at 5:59 PM, Rick Jones wrote:
>
> > The ifSpeed field of a generic interface counter in sFlow is 64 bits.
> > The "overlay" definition in print-sflow.c is correct, but the actual
>
On 09/07/2011 10:02 AM, Michael Richardson wrote:
Guy and I were discussing adding post-commit hooks to the repos to send
out summaries of activities.
Is there an objection if they go to this list?
Or do people prefer a new list?
I note that the github.com/mcr/{tcpdump,libpcap} is pushed every
On 09/13/2011 07:22 AM, Michael Richardson wrote:
"Rick" == Rick Jones writes:
>> Guy and I were discussing adding post-commit hooks to the repos
>> to send out summaries of activities.
>>
>> Is there an objection if they go to this lis
es
of its fowarding of captures...
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Would this be the number reported by
ifconfig?
If, as the name suggests, those are drops reported by the NIC,
presumably the value you see being emitted by tcpdump would track rather
closely with the stats reported for the interface via ethtool -S
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
rface. 99 times out of 10 the stats reported
by ethtool -S are statistics as measured by the NIC itself.
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
unity?"
happy benchmarking,
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
t tap and be captured, find a
queue/resource past the tap unavailable, get re-queued above the tap,
get captured again when resent" sort of thing.
Where in the Linux stack does the tap used by libpcap 1.1.1 reside?
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
371)
backlog 0b 0p requeues 371
Sure enough:
$ tc -s -d qdisc
qdisc mq 0: dev eth0 root
Sent 2212158799862 bytes 1938268098 pkt (dropped 0, overlimits 0
requeues 4975139)
backlog 0b 0p requeues 4975139
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
x_count, IGB_MIN_TXD);
igb.h:#define IGB_MIN_TXD 80
but is that getting a little close?
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
I
suppose mention this behaviour to the Debian maintainer for tcptrace,
but is there a writeup to be enhanced for tcpdump?
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
but is that getting a little close?
rick jones
Sure !
I only pointed out a possible problem, and not gave a full patch, since
we also need to change the opposite threshold (when we XON the queue at
TX completion)
You can see its not even consistent with the minimum for a single TSO
frame
.
Disabling GRO is done via ethtool -K. LRO too, though go back far
enough and it may need to be done at the module parameter level. I
don't know if UFO (UDP Fragmentation Offload) is both directions or not,
but that too is an ethtool -K thing.
rick jones
-
This is the tcpdump-wor
the transport(s) carrying the
flows perhaps even within a single flow (eg a flow of UDP traffic)
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
s an 802.2 TEST frame) However if I drop "and not multicast"
I will see my broadcast frame.
Given there is also an alias for broadcast that behaviour seems
incorrect - "not multicast" should still show broadcast. Thoughts?
This is with 4.1.1 and libpcap 1.1.1.
rick jones
parately but I
suspect it is still functionally correct if that is simply shoved into
the TCP checksum field.
rick jones
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Is there a version of tcpdump in the works which will decode the
unecrypted portions of an SSL/TLS session? Or do I need to look elsewhere?
thanks,
rick jones
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https
On 12/11/2012 05:58 AM, Wesley Shields wrote:
On Mon, Dec 10, 2012 at 11:38:29PM -0500, Michael Richardson wrote:
"Rick" == Rick Jones writes:
Rick> Is there a version of tcpdump in the works which will decode
Rick> the unecrypted
Rick> portions of an SSL/
But on the end-system
involved in the conversations? Nope. The stateless offloads and their
effect on what one sees via packet capture are here to stay.
rick jones
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
lient?
Answers to at least some, if not all, those questions will go a long way
towards being able to say something about how long it took the ICMP Echo
Reply to travel from the server to the client.
rick jones
___
tcpdump-workers mailing list
tcpdump-wo
it took in this case given it is
clear it didn't take very long at all?
Given the likely symmetry of the path between client and server, were I
pressed for an answer, I would probably start by ass-u-me-ing that the
time from server to client was 1/2 the total round-trip time.
rick jones
IRQ assignments, that probably isn't a good assumption.
thoughts?
rick jones
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
On 10/12/2014 01:00 PM, John Hawkinson wrote:
It seems to me that without more robust support this is just annoying
noise and, at the very least, the Unknown oui printing should be
removed.
Thoughts?
What would removing it do to scripts attempting to parse tcpdump output?
rick jones
On 10/22/2014 10:29 AM, Michael Richardson wrote:
Rick Jones wrote:
>> It seems to me that without more robust support this is just annoying
>> noise and, at the very least, the Unknown oui printing should be
>> removed.
>>
>> Thoughts?
packet capture able to keep-up?
rick jones
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
On 03/11/2015 02:30 AM, srinivasarao...@bel.co.in wrote:
Hai,
How to capture the data at transport layer (not on interface)
Apart from nettl in HP-UX, I've not come across an OS/application which
enables such a thing.
rick jones
every extra byte in a message is another microgram o
pture file. And, for
that matter, just about anything generating logfiles...
happy benchmarking,
rick jones
[Note to moderator: I've updated my subscription to my new email and
cancelled the post that got moderated.]
___
tcpdump-workers ma
It has been a few years since GUESS_TSO was added. Might it be time to
enable it by default?
rick jones
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
How does this look?
On Fri, Apr 13, 2018 at 3:56 PM Michael Richardson wrote:
> Rick Jones wrote:
> > It has been a few years since GUESS_TSO was added. Might it be time
> to
> > enable it by default?
>
> send pull request... update documentation :-)
>
&
My proverbial two cents is that is changing the semantics of an option,
semantics which go back literally decades. New semantics should be
associated with new options.
On Tue, Oct 30, 2018 at 2:48 AM Denis Ovsienko wrote:
> Hello list.
>
> At https://github.com/the-tcpdump-group/tcpdump/pull/70
--- Begin Message ---
If https://en.wikipedia.org/wiki/HP-UX#Version_history is any indication,
there are ~21 months left on HP's (er, sorry, HPE's) own support for HP-UX.
happy benchmarking,
rick jones
On Tue, Mar 12, 2024 at 1:48 PM Denis Ovsienko wrote:
> Hello all.
>
>
--- Begin Message ---
I meant to include an "only" in there :) Wasn't meaning to suggest any
heroic efforts should be made.
happy benchmarking,
rick
On Tue, Mar 12, 2024 at 4:08 PM Guy Harris wrote:
> On Mar 12, 2024, at 2:07 PM, Rick Jones via tcpdump-workers &
101 - 135 of 135 matches
Mail list logo
