--- 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 &
--- 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.
>
>
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
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 :-)
>
&
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
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
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
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 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?
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
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
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
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
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
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/
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
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
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
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.
.
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
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
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.
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.
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.
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.
unity?"
happy benchmarking,
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.
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.
es
of its fowarding of captures...
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
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
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 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
>
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 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
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.
f using 1520 to
end on a 4 byte boundary and so begin on a 4 byte boundary if these
buffers are carved one after the other?
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
lly sure about is when to do everything on one
line and when to split it up...
happy benchmarking,
rick jones
diff --git a/print-sflow.c b/print-sflow.c
index f27370a..82c3706 100644
--- a/print-sflow.c
+++ b/print-sflow.c
@@ -61,6 +61,8 @@ static const char rcsid[] _U_ =
*
*/
+#define IPV6_
On Wed, 2011-04-27 at 15:21 -0400, Michael Richardson wrote:
> Rick, I've committed your pcap file and .out file.
> I edited the out file to remove the dates (-t option), and I suggest you
> want to generate one file for each -v level.
>
> It's pretty important for me to have the .pcap and .out f
;outputPort format==3 %u\n", sample->outputPort);
break;
case 2: sf_log("outputPort multiple %u\n", sample->outputPort); break;
case 1: sf_log("outputPort dropCode %u\n", sample->outputPort); break;
case 0: sf_log("outputPort %u\n", sample->outputPort
On Fri, 2011-04-15 at 10:02 -0700, Guy Harris wrote:
> On Apr 14, 2011, at 2:59 PM, Rick Jones wrote:
>
> > Thanks to some traces sent my way by Gavin McCullagh, and a comparison
> > against the output of inMon's sflowtool, I can confidently say "Yes
> > Virg
lly
look at the enterprise field and make sure it is one we recognize.
Signed-off-by: Rick Jones
diff --git a/print-sflow.c b/print-sflow.c
index c508824..f27370a 100644
--- a/print-sflow.c
+++ b/print-sflow.c
@@ -170,6 +170,13 @@ struct sflow_expanded_flow_raw_t {
u_int8_theader_size[4]
On Thu, 2011-04-14 at 11:35 -0700, Guy Harris wrote:
> On Apr 13, 2011, at 1:02 PM, Rick Jones wrote:
>
> > To enable printing of non-expanded samples I've shuffled a bunch of code
> > around and created a bunch of smaller routines to more easily support
> > prin
e from the 12th. I'm not terribly git-savvy or I could give
the various ids...
Signed-off-by: Rick Jones
rick jones
/*
* Copyright (c) 1998-2007 The TCPDUMP project
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that: (1) source co
On Fri, 2011-04-08 at 17:04 -0700, Rick Jones wrote:
> Either I fumbled trying the patch or something else has gone amis
> because with a freshly cloned tcpdump, and a new set of sflows I get
> output like:
what has happened is I have switched switches and the switch I'm using
is n
figured for some flow samples while I was running
a single instance of netperf through it.
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Mon, 2011-04-04 at 19:06 -0700, Guy Harris wrote:
> On Apr 4, 2011, at 12:15 PM, Rick Jones wrote:
>
> > The former is easy enough - attached is a compressed pcap file with 30
> > captured PDUs which can be used for testing. They are all just counter
> > samples, t
On Mon, 2011-04-04 at 18:49 -0700, Guy Harris wrote:
> On Apr 4, 2011, at 12:15 PM, Rick Jones wrote:
>
> > As for the latter, I don't have some of the pre-reqs installed:
> >
> > raj@tardy:~/tcpdump$ make check
> > uudecode --help || (echo "No u
On Sun, 2011-04-03 at 20:27 +0200, Michael Richardson wrote:
> >>>>> "Rick" == Rick Jones writes:
> Rick> tcpdump 4.1.1, and 4.3.0-PRE-GIT_2011_04_01 prints just one
> Rick> expanded counter sample per captured PDU because it mistakenly
> R
On Fri, 2011-04-01 at 20:11 -0700, Guy Harris wrote:
> On Apr 1, 2011, at 6:03 PM, Rick Jones wrote:
>
> > tcpdump 4.1.1, and 4.3.0-PRE-GIT_2011_04_01 prints just one expanded
> > counter sample per captured PDU because it mistakenly skips forward
> > sflow_sample_len when
. Shifting the adjustment to the "default sample" case where
the sample wasn't printed appears to fix this, though there is still
some question as to whether it should advance by sflow_sample_len or
some adjustment thereof.
Signed-off-by: Rick Jones
raj@tardy:~/tcpdump$ diff print-sfl
. (e.g. you can run a Bonnie++ to see how fast your disk system is.)
And be certain to beat on the filesystem/disc with I/Os of the size that will be
coming from your packet capturing...
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
I see you weren't binding the app explicitly to the
same core, but simply to the same processor, so perhaps the same thing is
happening with your app as with my netserver :)
rick jones
PS - don't forget that some NICs have multiple IRQs... :)
-
This is the tcpdump-worke
uent segments it sees.
Are you printing-out any other characteristics of the TCP segments to act as a
sanity check - say to make sure you are dealing with the correct offsets?
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Guy Harris wrote:
Is there ever any reason *NOT* to use the hardware timestamp if it's available?
Only if it and the host time are not sufficiently in sync and you want to
correlate with other things timestamped with host time.
rick jones
-
This is the tcpdump-workers list.
Visit
how much CPU is left over when the guest(s) are running at
these rates.
rick jones
The following tests are between 3 physical machines on a 10-meg ethernet
network all connected to the same subnet.
System #1: win_32 and ubuntu1_32(dual CPU)
System #2: fedora core 64-bit (quad CPU)
on't do well on libpcap.
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
after the in the
configure script appears to complete on 11.11 and 11.31.
Is this a known problem?
happy benchmarking,
rick jones
cannot recall if he is still subscribed to the list, so please cc on replies
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
h pseudo-random subsets of the traffic? I'd think that if one
wanted to be tracing a gigabit link one would trace to a binary file and
post-process, or have a rather specific filter in place?
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Gert Doering wrote:
Hi,
On Wed, Feb 06, 2008 at 10:09:33AM -0800, Rick Jones wrote:
What is the reason for having optional IPv6 in the first place (besides
OSes that don't provide all necessary header files)? Memory savings?
ISTR there were some "funnies" on some OSes wher
places someone would be likely to
look if a compile failed, IPv6 by default should be fine.
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Michael Krueger wrote:
On Tue, 22 Jan 2008 19:47:24 +0100, Rick Jones <[EMAIL PROTECTED]> wrote:
How many processors do you have, are interrupts from each NIC going
to seperate processors/cores/whatever (show us the output of
/proc/interrupts), and have you bound each tcpdump
Michael Krueger wrote:
On Tue, 22 Jan 2008 19:47:24 +0100, Rick Jones <[EMAIL PROTECTED]> wrote:
How many processors do you have, are interrupts from each NIC going
to seperate processors/cores/whatever (show us the output of
/proc/interrupts), and have you bound each tcpdump
How many processors do you have, are interrupts from each NIC going to
seperate processors/cores/whatever (show us the output of
/proc/interrupts), and have you bound each tcpdump to its corresponding
NICs interrupt CPU?
rick jones
-
This is the tcpdump-workers list.
Visit https
that this limitation is relaxed in 11iv3 (aka
11.31) with the installation of patch PHNE_36857 which was released in
December of 2007. I have no information on that being back-ported to
11iv2 or 11iv1 and would assume it would be based entirely on demand
made known through official channels.
system with CKO (ChecKsum Offload) enabled, you would probably see
incorrect checksums for all outbound traffic.
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
ronnie sahlberg wrote:
On Nov 7, 2007 12:54 PM, Rick Jones <[EMAIL PROTECTED]> wrote:
Harley Stenzel wrote:
On Nov 6, 2007 2:03 PM, Rick Jones <[EMAIL PROTECTED]> wrote:
Any thoughts as to how to deal with false checksum failure reports for outbound
traffic being sniffed on a
Harley Stenzel wrote:
On Nov 6, 2007 2:03 PM, Rick Jones <[EMAIL PROTECTED]> wrote:
Any thoughts as to how to deal with false checksum failure reports for outbound
traffic being sniffed on a system with ChecKsum Offload (CKO)? It seems that
linux has a flag they can set when capturi
necessary to "guess"
based on the source IP matching one of the system's local IPs.
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Bruce M. Simpson wrote:
Rick Jones wrote:
So this is meant to enable receipt of specific multicasts and not
receipt of all multicasts right? Is that a particularly "pcappy" thing?
Correct. I believe it logically belongs with pcap, as it is something
which may well be require
So this is meant to enable receipt of specific multicasts and not receipt of all
multicasts right? Is that a particularly "pcappy" thing?
Anyway, for HP-UX and Solaris, I suspect the receive all multicasts would be a
DL_PROMISC_MULTI rather than the (i suspect) current DL_PROMISC_P
full size snaplen.
Having said that, I suspect that the changes to add a byte count would
be pretty straightforward if you wanted to implement them. The only
question outstanding I would think would be whether that should be a
byte count based on snaplen captured, or the sum of the actual pac
operty of being less likely to break someones
scripts no?
rick jones
Index: print-tcp.c
===
RCS file: /tcpdump/master/tcpdump/print-tcp.c,v
retrieving revision 1.126
diff -u -r1.126 print-tcp.c
--- print-tcp.c 2 Nov 2006 08:56:
[EMAIL PROTECTED] wrote:
Hello friends,
I wish to use hostap (a driver for wireless cards) + libpcap + tcpdump to
bring some extra details of the packets in the user space.
I wish to know that how libpcap reads the packet from the kernel/interfaces.
That varies by platform. Probably best don
[EMAIL PROTECTED] wrote:
Hello friends,
I am a newbie in the group. Please let me know if the clarifications
regarding libpcap should also be posted here or there is some separate
mailing list for it.
Yes, this group is used for questions about libpcap.
rick jones
anyone heard from guy
o enable support for multiple promiscuous streams per interface.
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
g bound in each case?
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
romisc_phys: UNIX error - Device busy
It sounds like some other process has the device open. On HP-UX,
unlike Linux and (iirc) Solaris, only one process may have an
interface open at a time.
It would be more accurate to say that it allows only one promiscuous
mode stream per interface.
rick jone
/print-dhcp6.c:596: undefined reference to `__ntohl'
./print-dhcp6.c:598: undefined reference to `__ntohl'
I wonder if the manpage for ntohl and/or ntohs it shows an include file
that print-dhcp6.c is not including?
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Guy Harris wrote:
On Apr 7, 2006, at 10:08 AM, Rick Jones wrote:
As for checking against the normal MTU, does tcpdump/libpcap have
that information?
Only to the extent that it could infer that from the link-layer type.
(Jumbo frames might make that tricky.)
And since TSO _really_
annot remember if HP
offered TSO on 11.11 or if it was strictly 11.23 and later. Asking the
person who submitted the bug if they have set a VMTU on the interface
being traces would be goodness.
rick jones
On 4/7/06, Guy Harris <[EMAIL PROTECTED]> wrote:
Hannes Gredler wrote:
c
it related to the libpcap and below not keeping-up.
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
r support contract(s) to have an
enhancement request opened against DLPI.
Does your program actually require promiscuous mode to function?
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
sweat :)
What sort of problem are you looking to solve?
For just blasting frames onto the wire, there is the in-kernel pktgen
stuff under linux.
sincerely,
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
And keep in mind that if you are tracing on a system with a NIC doing
ChecKsum Offload the outbound traffic from that system will probably not
have the checksum calculated yet since the NIC will be doing it...
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to
rate is 1% p would
be 0.01 and 1-p would be 0.99). Since all packets have to make it across, if
there are N fragments that means the chances of all of them making it is
(1-p)^N. (1-p)^N gets very small very rapidly as N increases.
rick jones
-
This is the tcpdump-workers list
x threads; so i'll "taste" performance
differences.
_Clusters_?!? That is a rather important detail...
Somehow I seriously doubt that a libpcap application can span nodes in a
computational cluster. At least not the stuff doing the promiscuous mode bits.
rick jones
-
This
o way to do
this:
Do you really have to do the cpu intensive work on those packets in real time?
Why don't you want to use threads to distribute work across the CPUs?
Specifically, on _which_ platform do you want to do this?
rick jones
-
This is the tcpdump-workers list.
V
hey will on AIX as well.
rick jones
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
-
This is the tcpdump-workers list.
Visit https://lists.s
- last time I looked, 10.09 was the latest. Ironic coincidence that
today happens to be the 10th of November - is the machine's date off by a month?
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Guy Harris wrote:
On Nov 9, 2005, at 2:53 PM, Rick Jones wrote:
Shouldn't that have then appeared in the 11/09 "current" tar? I just
grabbed that and it doesn't seem to have been there. Operator error
on my part? Grabbing the wrong tar file or something?
It was che
For fun and excitement :) I tried compiling the 10.09 bits on an IA64 HP-UX
11.23 system. I'm not _entirely_ certain of the lineage of the compiler I'm
using, having gotten it from an internal depot, but it did emit some warnings
that may or may not be meaningful:
the first batch look mostly
Shouldn't that have then appeared in the 11/09 "current" tar? I just
grabbed that and it doesn't seem to have been there. Operator error on
my part? Grabbing the wrong tar file or something?
Part of it might be that there is no 11/09 tar - the last "current" appears to
be 10/09
rick
-
This
Guy Harris wrote:
On Nov 7, 2005, at 1:08 PM, Rick Jones wrote:
The following change bumps a few limits in scanner.l so it will be
processed by the lex which ships with HP-UX. It is based on
libpcap-2005.10.09. While I was here, I went through to make sure
that utilization of these
probably filter on packet size - a bare ACK would just be the TCP, IP and
link-level headers.
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
The following change bumps a few limits in scanner.l so it will be processed by
the lex which ships with HP-UX. It is based on libpcap-2005.10.09. While I was
here, I went through to make sure that utilization of these things was no more
than ~80%:
$ lex -t scanner.l > /dev/null
6056/7600 node
hat has been fixed in a
compiler patch or later version, but I thought I might send-along the patch just
the same.
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
distribute a port of ethereal - I've no idea
though if anything was/could be done at that level to workaround the limitation,
but if there was something done there, the ethereal sources HP modified should
be around - software.hp.com should be a decent starting point to find the
"inter
uity is
being requested in both opens, and possibly if *any* flavor of
promiscuity is being requested in both opens (libpcap requests SAP
promiscuity if it doesn't request physical promiscuity).
Indeed, the dimm recesses of my mind recall such limitations in HP-UX
promiscuous mode su
11.20 aka 11i v1.5 Itanium only
HP-UX 11.22 aka 11i v1.6 Itanium2 (?) only
HP-UX 11.23 aka 11i v2.0 Itanium2 only
HP-UX 11.23 aka 11i v2.0 Update 2 Itanium2 and PA-RISC
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
,
a "pure" BPF interface would give better performance than DLPI. DLPI though may
still give "sufficient" performance.
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
1 - 100 of 135 matches
Mail list logo
