}
#endif
! #ifdef DL_HP_PPA_REQ
/*
* Under HP-UX 10 and HP-UX 11, we can ask for the ppa
*/
rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email
"Hi there, here is a packet" in DLPI speak. It looks like the stream is sending
one of those up to the application when libpcap isn't expecting it.
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Guy Harris wrote:
On Jun 9, 2004, at 1:27 PM, Rick Jones wrote:
Does it always happen or just sometimes? A DL_UNITDATA_IND is
basically saying "Hi there, here is a packet" in DLPI speak. It looks
like the stream is sending one of those up to the application when
libpcap isn'
Guy Harris wrote:
On Jun 9, 2004, at 1:58 PM, Rick Jones wrote:
On the surface I wouldn't think so - simply attaching to a PPA I don't
think means traffic could arrive - however, if one has attached, and
then binds to a SAP, then traffic could indeed start arriving.
(Il-informed gue
both
tcpdump _and_ the semantics of promiscuous mode on platforms.
based on what I think I know about large send support on at least one
NIC, this may also happen on other OSes.
rick jones
Wisdom teeth are impacted, people are affected by the effects of events
-
This is the tcpdump-workers
well, I don't know about the gencode stuff, but building
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
xit code 1
which appears to have something to do with ipv6 stuff:
} else if (IP_V(ip) == 6) {
ip6 = (struct ip6_hdr *)ip;
MD5_Update(&ctx, (char *)&ip6->ip6_src, sizeof(ip6->ip6_src));
MD5_Update(&ctx, (char *)&ip6->ip6_dst, sizeof(ip6->ip6_dst));
len32 = htonl(ntohs(ip6->ip6_plen));
now, there is an ip6_hdr in ip6.h. However, the inclusion of ip6.h is
conditional on INET6:
#ifdef INET6
#include "ip6.h"
#endif
but none of that IPv6 stuff where the error hits is conditional on INET6.
Without a TOUR installed, HP-UX 11.11 knows little to nothing about IPv6.
I'm not quite sure what to do to fix that code - if I should make it ifdef INET6
and return -1 as if it was an unknown IP version, or what.
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
I need to see what, if anything, still needs to be done in my attempt to
get rid of the INET6 definition in tcpdump (so that the code is there
regardless of whether the OS itself knows about IPv6), and get that
checked in.
That might fix the problem.
FWIW, while I was looking at ip6.h, it _appeare
Guy Harris wrote:
I've checked that in (with the code inside "#ifdef bogus"/"#endif"
removed rather than #ifdeffed out), along with some changes that might
get rid of the compiler warnings - are there still warnings with version
1.106?
just the inline and yylex stuff, which IIRC have been there
After I compiled the July 21 libpcap, I decided to compile the July 21 tcpdump
stuff. The print-tcp.c stuff is still fubar (I wasn't expecting any change
there) but I went ahead and did a bit of cleanup for other files.
First was print-esp.c - it was warning in three places about an integer bei
As promised, I grabbed *current* and compiled libpcap with +DD64. It appears to
have been OK. I went to compile tcpdump, but tcpdump-current.tar.gz unpacks to
2004-07-21, not 22. I simplisticly took that to mean it didn't update bits from
before.
On a lark, I added a "+M0" to turn-on migrati
; as long as "localhost" pointed to 127.0.0.1, but perhaps
some creative use of the route command could get 127.0.0.1 traffic
routed to a machine local IP address and then if Solaris has something
akin to the ip_loopback_bypass (check ndd /dev/ip \? output...
hth,
rick jones
PS - anyone
pens if one unplumbs lo0: and assigns 127.0.0.1 to a "real"
interface (say as an alias) I have no idea...of course without the loopback
bypass it may still not get you where you want to go.
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
t indeed get into the way. however, if it
does, and you've make your loop driver sufficiently portable, you could
just bring it over to HP-UX and set ip_loopback_bypass :)
rick jones
Wisdom teeth are impacted, people are affected by the effects of events
-
This is the tcpdump-workers li
see all link-level broadcast traffic -
basically, any traffic that the NIC would have passed along to the
driver. That can give you packets that you might not have initially
expected.
rick jones
there is no rest for the wicked, yet the virtuous have no pillows
-
This is the tcpdump-workers list
datalink_val_to_description" in
files dlnames.o and ./../libpcap/libpcap.a(pcap.o)
/usr/ccs/bin/ld: Found 4 duplicate symbol(s)
*** Error exit code 1
Stop.
sincerely,
rick jones
PS - I'm looking for worked examples of reconstructing a TCP stream
(separate each way is fine/preferred) from a tcp
code for "Follow TCP Stream", but it drags
in a lot of the Ethereal framework.
You might look at tcpflow:
http://www.circlemud.org/~jelson/software/tcpflow/
thanks. the end goal is to look at NFS over TCP traffic where the
traffic may have nfs messages split across segments, several in a
Guy Harris wrote:
On Sep 13, 2004, at 7:24 PM, rick jones wrote:
thanks. the end goal is to look at NFS over TCP traffic where the
traffic may have nfs messages split across segments, several in a
segment, that sort of thing.
If "look at" implies "dissect as NFS", Etherea
.o strlcpy$U.o strsep$U.o
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Guy Harris wrote:
On Sep 14, 2004, at 4:38 PM, Rick Jones wrote:
no datalinks.o:
LOCALSRC = print-smb.c smbutil.c
GENSRC = version.c
LIBOBJS = strlcat$U.o strlcpy$U.o strsep$U.o
But you got duplicate symbol errors?
What's the output of "make"?
since that will be somewhat large
an inbound..
of course, that is just a guess.
rick jones
there is no rest for the wicked, yet the virtuous have no pillows
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
x);
where "sig" is "char sig[TCP_SIGLEN]" but MD5_Final seems to want an
"unsigned char *"
In other words, variations on the familiar char versus unsigned char
theme :)
A quick "./tcpdump -c 10" on the compilation system appears to have been
happy.
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
For "fun" I went ahead and compiled the 2004-09-15 versions of libpcap
and tcpdump as 64-bit binaries under HP-UX 11
(CFLAGS="+DD64"./configure;make) and it seems to be well. I suppose I
could try with all warnings enabled - say the word and I'll give it a shot.
relative time, not clock time. perhaps that is "ok" here but it will
be a semantic (right term?) difference from gettimeofday().
rick jones
higher resolution timestamps would be nice.
there is no rest for the wicked, yet the virtuous have no pillows
-
This is the tcpdump-workers list.
V
Perhaps, the man page says:
The gethrtime() function returns the current high-resolution
real time. Time is expressed as nanoseconds since some arbi-
trary time in the past; it is not correlated in any way to
the time of day, and thus is not subject to resetting or
dr
s of stuff (iirc) wants four-byte, but I'm not sure about 8
rick jones
one must constantly strive to eschew the tendency to overly utilize
polysyllabic verbiage in interpersonal communications lest the intent of
said communications becomes obfuscated by the preponderance of
preposterous p
?
For that matter, which OS?
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
atisfied symbol "EXTRACT_64BITS" in file print-nfs.o
It looks like there are indeed two definitions for EXTRACT_LE_64BITS in
extract.h, with one being condtional, and the other being unconditional, so when
the conditions are met, one gets two definitions. Interestingly enough, and
perhaps t
ave another type issue here:
cc -O -DHAVE_CONFIG_H -I./../libpcap -I/usr/local/include
-I/usr//include -I./missing -D_U_="" -I. -I./../libpcap -I/usr/local/include
-I/usr//include -I./missing -c ./print-tcp.c
cc: "print-tcp.c", line 800: warning 604: P
Rick Jones wrote:
Hi -
I downloaded the 2005.01.14 bits and went to compile them on HP-UX 11iv1
(11.11) and HP-UX 11iv2u2 (11.23 pi - PA and IPF, but in this case on IPF).
On 11iv2u2 for libpcap, folks will see a warning from the compiler about
a redeclaration of IFF_PRIORITY. This _appears_
{
+ /* we guess that it is a TSO send */
+ len = length;
+ }
+ #else
(void)printf("bad-len %u", len);
return;
+ #endif /* GUESS_TSO */
}
/*
basically, if the IP len is zero, ass-u-me that the segment is TSO and wing it.
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Rick Jones wrote:
A while back I think I posted something asking about what to do about
TSO (large send) and how it generated "IP bad-len 0" output when
tracing on a TSO-enabled sender.
I've had acouple folks ask "What's TSO?" so...
TSO == TCP Segmentation
Hi -
I was looking to "leverage" the getadrinfo.c et al stuff from the missing/
subdir in tcpdump, but I'm at a loss to see how it becomes conditional on there
not being a getaddrinfo et al already. is it some magic in the configure.in
that I just didn't grok?
rick jones
-
t overriding 22 with a different SAP value
still works.
I'll bet it is rather like how so many applications blythly took
"listen(socket,5)" from examples and documentation, only this time, there is an
opportunity to conflict.
rick jones
-
This is the tcpdump-workers list.
Visit
9.10 release on the Moto68K-based
workstations) and has been off support from HP for many many years now. Heck,
10.20 has been off HP support for some time now as well.
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.
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.
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
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
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.
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
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.
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
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
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
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
- 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.
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
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
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
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
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
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.
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.
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.
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
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_
/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.
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
g bound in each case?
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
o enable support for multiple promiscuous streams per interface.
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
[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
[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
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:
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
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
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
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.
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
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
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.
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.
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
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
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.
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
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.
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.
on't do well on libpcap.
rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
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)
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
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.
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
. (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.
. 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
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
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 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 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
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 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
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 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
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 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
;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 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
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_
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.
1 - 100 of 135 matches
Mail list logo
