Re: [tcpdump-workers] proposed new pcap format
In some email I received from Christian Kreibich, sie wrote: > [I've tried to get this to the list about four times now and it always > came back with a different reason -- I hope this one will make it to > the new list. Thanks.] What's the _real_ list address? The web page still has: [EMAIL PROTECTED] Some of my emails seem to go missing rather to the list :-/ There's also [EMAIL PROTECTED] [EMAIL PROTECTED] Do I bombard all three? > On Wed, 2004-03-24 at 03:31, Jefferson Ogata wrote: > > Michael Richardson wrote: > > > This is what I would propose as revision. > > > Note that the pcap1_packet_header is present on every packet. One can > > > merge pcap files together with "cat" if one likes. > > > > That's a nice feature, and one we should try to maintain if possible. > > There's another thing I'd like to point out: the new scheme, in its > current state, doesn't provide the snaplen value that the old > pcap_file_header provides. I think a *lot* of applications use that > value to allocate a buffer to store packet data before starting to read > packets. > > I think I'd like to see a somewhat stricter layout than Michael's scheme > suggests right now, i.e., put file-wide metadata at the beginning of the > file, in a fashion equally extensible as the current per-packet > structure, and after that, allow only a kind of pcap1_packet_header that > (among possibly others) contains precisely one pcap1_info_packet. > > I agree that the ability to cat together trace files would be nice. > However if that's the only benefit, while otherwise every > packet-iterating application becomes a whole lot more complicated > because it must find a way to deal with pure metadata without any packet > data at random points in the file (how to display? discard what you > don't understand? keep it? ...) then I'm not sure if it's worth it. I'll repeat a comment I made elsewhere and that is currently, in an application I'm working on, we join captured data from multiple NICs with the same DLT type in the same file. Other parameters, such as the snaplen may differ, per capture instance. I should add that a nice C++ interface would be good too O:-) Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Proposed new pcap format
In some email I received from Ronnie Sahlberg, sie wrote: > Oh, I forgot. > > Another useful thing to have is an option for the packet block where one > would store > a reasonably collission-safe 8-byte hash of the packet data. > > This would make it much easier to compare two different capture files to see > where packets are missing etc. I'll agree that this, as part of the per-packet header, would be a useful addition to the pcap format. No need for chained hashing, just per-record. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Proposed new pcap format
In some email I received from Guy Harris, sie wrote: > On Sat, Apr 10, 2004 at 04:39:41AM +1000, Darren Reed wrote: > > I'll agree that this, as part of the per-packet header, would be a useful > > addition to the pcap format. No need for chained hashing, just per-record. > > Part of the packet block header, or an option in the packet block? I'd > vote for the latter. Yes, I think the latter too. You could easily have different checksum functions eligable for use here. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Proposed new pcap format
In some email I received from Loris Degioanni, sie wrote: [ Charset ISO-8859-1 unsupported, converting... ] > Ok, I'm going to add a 8-byte hash option for the packet block. Can anybody > suggest the hashing algorithm? You obviously sent this before reading another email I sent on this. Today, some people might want MD-5, others SHA-1 and in the future, there may be other hashing algorithms that are better to use. And there are times when we might want it off (algorithm 0, for example.) As such, I believe this option should be a (type,value) pair, if we can agree that the hash value in the option header is a hash over the entire record returned by the kernel (with the value of the hash set to 0.) And yes, the kernel computes the hash. Darren > > In some email I received from Ronnie Sahlberg, sie wrote: > > > Oh, I forgot. > > > > > > Another useful thing to have is an option for the packet block where one > > > would store > > > a reasonably collission-safe 8-byte hash of the packet data. > > > > > > This would make it much easier to compare two different capture files to > see > > > where packets are missing etc. > > > > I'll agree that this, as part of the per-packet header, would be a useful > > addition to the pcap format. No need for chained hashing, just > per-record. > > > > Darren > > - > > - > This is the tcpdump-workers list. > Visit https://lists.sandelman.ca/ to unsubscribe. > > . > - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Creeping GCC'sims in tcpdump
In some email I received from Brian Ginsbach, sie wrote: > The following in netdissect.h seems like a bad thing to do. > > #define ND_PRINT(fmt, args...) (*ndo->ndo_printf)(ndo, fmt, ##args) > > Not all compilers/preprocessors support variable argument macros > like GCC. Compiling tcpdump shouldn't require GCC or a C99 compiler. > This macro is only used once in print-eap.c. Its use should > be nipped in the bud. I agree that in something such as tcpdump, gcc-isms should be heavily discouraged, however, I'm not sure about the C99 compiler bit. In time, using C99isms will be like using C89isms (or ANSI C.) For many of us, the only C99 compiler we have access to is going to be gcc, and whilst we can equate requiring C99 to requiring gcc, they're not quite the same. Hmmm, so, what am I trying to say ? C99 is coming on 5 years old and continuing to object to it will grow old in time... install a modern O/S and install a modern development suite. Cheers, Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bpf/pcap performance
In some email I received from Guy Harris, sie wrote: > > On Apr 12, 2004, at 2:25 AM, Darren Reed wrote: > > > In some email I received from Guy Harris, sie wrote: > >> On Sun, Apr 11, 2004 at 03:15:30AM +1000, Darren Reed wrote: > >>> And there's also BPF_MAXBUFFERSIZE. I see pcap_getbuff() as being > >>> essential to getting code to work without trial and error by passing > >>> different sizes to read() to find out what the right size to read > >>> is, if you're not setting the size yourself. > >> > >> But if you're using libpcap, you're not passing anything to read(), > >> you're letting libpcap do that. > > > > Not necessarily. > > > > The interface exposed by libpcap is not conducive to good use by > > C++ applications - main culprit here is pcap_dispatch() but none > > of the others really help. Unless all your classes are static > > classes (which kind of defeats the purpose, in my book.) > > > > So whilst pcap is good for discovering interfaces and setting up the > > sniffing, I've been forced to use pcap_fileno() and read(2) in order > > to get the application design I want. Using pcap_next() is too slow > > on BSDs where you can get multiple packets per read > > So that presumably also applies to "pcap_next_ex()" - which was > introduced on a platform (Win32/WinPcap) where you can get multiple > packets per read. The problem with pcap_next_ex() is the man page description: "reads the next packet and returns a success/failure indication" This is the first problem. I don't really know what it does, so how can I use it properly ? btw, on examining the code for pcap more, I find a disturbing name problem: pcap.h (the external interface) documents pcap_pkthdr as the structure used in the dump files, except if you look in savefile.c, it uses pcap_sf_pkthdr instead. To me, this is around the wrong way, at best. I understand what is trying to be done here and that is to make sure the saved file always has the same format regardless of what is coming in to the pcap_dump() function. But in my opinion, pcap_dump() should be using pcap_pkthdr to store things going out (not pcap_sf_pkthdr - do away with this structure). > > (on Linux, it is fine.) > > but is "read()" fine on Linux? :-) Ok, the Linux code continues to use the pcap(3) API :) > I.e., if you're using "read()", you're already not portable, unless you > are, in effect, re-implementing the dispatch loop for all platforms. > If your code knows what platform it's using, it could also know to do > the BIOCGBLEN ioctl. In this case, the code is only targetted at the BSD platforms, so we're not concerned about it not working on Solaris, AIX, etc. > > Also, I don't believe that the interfaces provided by pcap provide for > > a slimmed down read execution path. > > What different interfaces would you suggest? Some of these are light enough weight that they may be inline functions or even just #defines. I'm thinking on my feet here, so please don't expect this to be a perfect API set. I suppose what I might like to see is: int pcap_read(pcap_t *) - returns -1 for failure else the number of bytes newly stored. Reads as much data as is available into a contiguous buffer. pcap(3) is responsible for ensuring that it is able to properly do this. char *pcap_databuffer(pcap_t *) Returns a pointer to the current read buffer where data from pcap_read() is held. If pcap_read() has not been called or has returned 0/-1, then it should return NULL. int pcap_datalength(pcap_t *) Returns the number of bytes available in the current read buffer. If pcap_read() has not been called, return 0. struct pcap_pkthdr *pcap_nextrecord(pcap_t *) Successive calls iterate through the buffer of data read, returning a pointer to the start of the pcap packet header and the packet immediately following it. When the data buffer has been exhausted, return NULL. If pcap_read() has not been called or has returned -1/0, then return NULL. int pcap_setreadbuffer(pcap_t *, const char *buffer, const int size) Provide an external source for pcap to use for reading data into. "size" must be at least the same as what BIOCGBLEN will return. I haven't specified, here, whether or not successive pcap_read()'s overwrite or append to the buffer. The implementation may choose, for example, to allocate a contiguous buffer of 2*BIOCGBLEN but only ever return upto BIOCGBLEN bytes as valid, allowing successive calls to pcap_read() to work until a complete buffer of bytes has been read. I added pcap_setreadbuffer() because an application may be doing its own buffer/memory management and
Re: [tcpdump-workers] Proposed new pcap format
In some email I received from Michael Richardson, sie wrote: -- Start of PGP signed section. > > >>>>> "Darren" == Darren Reed <[EMAIL PROTECTED]> writes: > Darren> Today, some people might want MD-5, others SHA-1 and in the > Darren> future, there may be other hashing algorithms that are > Darren> better to use. And there are times when we might want it > Darren> off (algorithm 0, for example.) > > okay, meta-data. > I think that one might want to emit the meta-data header, but not fill > it in in some cases, and calculate the hash later on, poking it in. > > Darren> As such, I believe this option should be a (type,value) > Darren> pair, if we can agree that the hash value in the option > Darren> header is a hash over the entire record returned by the > Darren> kernel (with the value of the hash set to 0.) And yes, the > Darren> kernel computes the hash. > > Huh? really. You want the hash over the entire packet, or just the > part that was received by pcap? > > I wondered about that part. This makes the hash very interesting. > But, the kernel boundary is abstracted from the point of view of the > the pcap file format. What I'd like to see hashed, by the kernel, is the data it provides to the user application. Depending on the purpose, this has better trustworthiness, I feel. libpcap may decide to throw away that hash and include its own in the dump file. I'm not suggesting this just for a quick comparison point of view (as are some others) but from a data reliability perspective. If you have a multithreaded application interacting with libpcap, it would be nice if the pcap data that you considered sensiive could be hashed by the provider (the kernel), as is the case with other data streams in life. Hmmm, having said that, I think a hash coming from the kernel would need to cover two pieces of data: the timestamp and the portion of the packet being returned. Now whether this hash/checksum is cryptographically strong (SHA-1) or weak (32bit xor, say) should be up to me to decide on where I choose to draw the line in the sand for performance. > So, it we are including anything other than the packet data, we need > to define things. > > I can see some people wanting a hash over the layer-3 only, with > mutable fields set to zero (a la IPsec AH), such that they can compare > captures from different points. Is this your desire? No, I don't think anyone here is looking for that. What has been expressed as desirable is the means to do fast comparisons on packets (4/8 bytes vs 40+) and data integrity. And some other comments: > a) how strong do we need to make this? > 8-byte implies it won't be CRC32. A longer CRC? MD4? MD5? SHA1? I think it needs to support variable possibilities. Maybe even 2s complement checksum, XOR, CRC32, MD4, MD5, SHA1, etc. > b) how much performance can we afford? > (clearly, it could be left as 0 and filled in later on) Surely, if you can select from a number of different hashes then this is a choice for the user to make. > c) do we include this in every packet header? Or as an extra > meta-attribute? Every packet. Cheers, Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bpf/pcap performance
In some email I received from Guy Harris, sie wrote:
>
> On Apr 12, 2004, at 4:43 PM, Darren Reed wrote:
>
> > The problem with pcap_next_ex() is the man page description:
> > "reads the next packet and returns a success/failure indication"
>
> Well, it says more than that - it indicates what the values of the
> success/failure indication mean, and says what is supplied through
> "*pkt_header" and "*pkt_data" on success.
Sorry, this is my fault. I was reading the roff directly and only
thought there was one line to it. Reading it with nroff made a big
difference :-)
Ok, now that I read it, I find it tries to do too much (in my
opinion.) The part that makes it go off and read more data is
of questionable value ?
If it wasn't for that part of its behaviour, it does what I want
out of a pcap_nextrecord(). That said, I think pcap_next_ex()
is complex enough now and shouldn't be furher extended. So this
kind of makes the application design able to go in two paths:
foo() { ... }
while (pcap_dispatch(..., foo, ..))
;
or
while (pcap_next_ex(...) >= 0)
foo(...)
Well, there are a few others, too, but they're all centered around
looping on some pcap function call.
As for non-blocking more...
How exactly is pcap_next_ex() meant to work in non-blocking mode ?
Or should it be added to the list of functions that don't work with
it in the man page description of pcap_setnonblock() ? If I've
called pcap_read() as a result of the return of select/poll, then
it is inappropriate for pcap_next_ex() to decide to call pcap_read()
again, when it has run out of data.
Looking more closely at the non-blocking side of things, there seems
to be no use of either p->nonblock or p->timeout apart from in
pcap_setnonblock() ? Maybe pcap_next_ex() should also return -2
if "p->cc == 0" prior to calling p->read_op if nonblock is true ?
In an application using non-blocking I/O, I might want to do
something like this:
pcap_setnonblock(p)
while (1)
select()
if (FD_ISSET(pcap_fileno(p))
pcap_readdata()
...process data...
I suppose this part after FD_ISSET() could be just this using the
current libpcap interface:
pcap_dispatch(...-1...)
...except that now I'm back to the problem of passing a function
pointer in with C++.
Another thought that came to me on "how it might work", going back
to the quick API that I wrote up, if I could open a pcap file and
mmap it in, I might then be able to say I have a single large
buffer here; iterate over all of the records for me.
I think the current design (pcap_dispatch(), etc) is what's led
to strange API hooks like pcap_breakloop() appearing, when I think
a better design could have side stepped the need for them O:-)
> > btw, on examining the code for pcap more, I find a disturbing
> > name problem: pcap.h (the external interface) documents pcap_pkthdr
> > as the structure used in the dump files,
>
> OK, I'll fix the header to note that it's what's supplied to or by
> API's and say nothing about it being what's actually stored in dump
> files.
>
> > except if you look in savefile.c, it uses pcap_sf_pkthdr instead.
>
> I.e., it stores a "pcap_sf_pkthdr", which is what it *should* do.
>
> > To me, this is around
> > the wrong way, at best. I understand what is trying to be done
> > here and that is to make sure the saved file always has the same
> > format regardless of what is coming in to the pcap_dump() function.
>
> or what is supplied by "pcap_{dispatch,loop,next,next_ex}()", i.e.
> regardless of what the sizes of the members of a "struct timeval" are.
>
> > But in my opinion, pcap_dump() should be using pcap_pkthdr to store
> > things going out
>
> which would require that "pcap_pkthdr" be changed to begin with a
> "struct pcap_timeval". If it's OK to, on platforms where, for example,
> "ts_sec" is 64 bits, break binary compatibility with applications
> dynamically linked with libpcap, we could do that - but, if not, we
> need both structures.
Sorry, maybe my point came across wrong.
There's pcap.h with pcap_pkthdr and pcap-int.h with pcap_sf_pkthdr.
At present, applications are meant to include pcap.h and use pcap_pkthdr.
What should happen is that internally, pcap_int_pkthdr should be used
by libpcap and pcap_pkthdr should be used in pcap_dump() and when reading
pcap dump files.
But that would only make sense if the pcap file format was actually
considered to be a public interface. Is it? If not, I'd really like
you to consider making it a public interface.- which I think is the
other, large, ongoing email conversation here is about.
It just dawned on
Re: [tcpdump-workers] Proposed new pcap format
In some email I received from Loris Degioanni, sie wrote: > > Today, some people might want MD-5, others SHA-1 and in the future, > > there may be other hashing algorithms that are better to use. And > > there are times when we might want it off (algorithm 0, for example.) > > > > As such, I believe this option should be a (type,value) pair, if we > > can agree that the hash value in the option header is a hash over the > > entire record returned by the kernel (with the value of the hash set > > to 0.) And yes, the kernel computes the hash. > > I agree, but since we a are trying to define a standard, we probably want to > define a default hashing method. The main reason is that I don't think we'll > be able to include in libpcap (and possibly the capture drivers) the support > for 6 or 7 different methods, so maybe we could choose one. On the contrary, it's a trivial matter, really, to add more. Is there a "default" hashing method for SSL ? Or IPSec ? Or S/MIME ? No. In each case the specification defines support for a number of different hashes, of varying strengths and the choice is left to the end user to decide on what they wish to use. I don't see why libpcap should be any different. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Proposed new pcap format
In some email I received from Michael Richardson, sie wrote:
> {Darren, you are sending to tcpdump-workers-owner, from the SMTP
> envelope. I think my MTA is canonicalizing something in a way I don't
> want it to. It isn't the lists' fault}
Thanks, fixed my alias.
> >>>>> "Darren" == Darren Reed <[EMAIL PROTECTED]> writes:
> >> Are we worrying about corruption of the packets between the
> >> kernel and the userspace application? Or what? Yes, the PCI bus
> >> is now among the more error-prone (relatively speaking) parts of
> >> the system. So, unless the hash is computing my the MAC/PHY, I
> >> don't see a point in this.
>
> Darren> I suppose, ideally, the kernel would digitally sign the
> Darren> captured packet.
>
> Prooving what? that you aren't being lied to? By whom?
> What is the thread model for this? What does having the kernel digital
> sign stuff gain you? Who would lie to you in such a way that they
> couldn't also have the kernel lie to you?
It's not about lieing so much as data integrity within the
computer/application and being able to trust that to a very
high level.
> Darren> The question I want to be able to answer is: "how do I know
> Darren> what's in the program's capture buffer represents what was
> Darren> received by the computer from the network with any degree of
> Darren> reliability?"
>
> Reliability implies bit-errors somewhere, not malicious attacks.
Or programming errors :) But malicious attack is not a concern.
Darren
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Proposed new pcap format
In some email I received from Jefferson Ogata, sie wrote: > Darren Reed wrote: > > In some email I received from Michael Richardson, sie wrote: > >> Prooving what? that you aren't being lied to? By whom? > >> What is the thread model for this? What does having the kernel digital > >>sign stuff gain you? Who would lie to you in such a way that they > >>couldn't also have the kernel lie to you? > > > > It's not about lieing so much as data integrity within the > > computer/application and being able to trust that to a very > > high level. > > Darren, > > I'm still trying to understand an attack or failure scenario where > having the kernel MD5 the packet is any more reliable than having > userland do it. Can you describe such a scenario? I have less faith in a multithreaded program not stamping on data between it being read from the kernel and md5'ing it. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Is pcap thread-safe?
In some email I received from Andreas Rieke, sie wrote: > Hi there, > > is pcap really thread-safe, especially under linux? Did anybody really > try to run it on multiple interfaces, one per thread? The only part that wasn't thread safe (last time I checked) was pcap_compile(). And yes, I've used pcap_dispatch() in a multi-threaded linux app successfully. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Automatic report from sources (tcpdump libpcap
Firstly, still hitting "reply" puts this in the To line:
To: [EMAIL PROTECTED]
In some email I received from Automatic cvs log generator /tcpdump/bin/makelog, sie
wrote:
> CVS log entries from 22.04.2004 (Thu) 09:05:47 - 23.04.2004 (Fri) 09:06:03 GMT
> =
> Summary by authors
> =
> Author: guy
> File: tcpdump/configure.in; Revisions: 1.175, 1.175
> File: tcpdump/configure; Revisions: 1.175, 1.175
> File: libpcap/pcap-dlpi.c; Revisions: 1.102, 1.91.2.6
>
> =
> Combined list of identical log entries
> =
> Description:
> On non-HP-UX systems, if we fail to open "/dev/{if}" or "/dev/{if}N"
> because neither of them exist, just report that there was no DLPI device
> found for "{if}N", so people don't think that they need to fix libpcap
> (or the program using it) to look somewhere else for the device - the
> problem is probably that they're trying to capture on a loopback device
> and the lack of any DLPI device is just a symptom of the fact that the
> loopback device, at least on Solaris, appears not to support DLPI and
> thus isn't supported by libpcap
> Modified files:
On Solaris, the loopback interface is not a real interface. It's a
fake stub in the interface list for user convienience - there are no
STREAMS queues, etc. You cannot use IPFilter on the loopback interface
under Solaris, for example. The IP stack has in it embedded checks for
loopback stuff and it's all internally hard wired.
Darren
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] single packet capture time w/pcap vs. recvfrom()
In some email I received from Brandon Stafford, sie wrote: [ Charset windows-1252 unsupported, converting... ] > Hello, > > I'm writing a server that captures UDP packets and, after some > manipulation, sends the data out the serial port. Right now, I'm using > recvfrom(), but it takes 20 ms to execute for each packet captured. I > know that tcpdump can capture packets much faster than 20 ms/packet on > the same computer, so I know recvfrom() is running into trouble, probably > because of bad checksums on the packets. What you're looking at is unlikely a recvfrom() problem but rather one of scheduling the process - and similarly just as unlikely to disappear because you use pcap vs a real socket. To say that it is would imply that a process could not deal with more than 50 UDP packets per second ... something I find hard to believe of any modern computer. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] PCAP - IP Fragments
In some email I received from Hans Klute, sie wrote: [ Charset ISO-8859-1 unsupported, converting... ] > Hi! > > I just realized a bug/feature of pcap that I didn?t think of. > I wrote a sniffer based on pcap. This sniffer can handle fragmented IP > packets. Now I realized that if you set up a filter with a UDP or TCP port, > you will not get the additional fragments, because in these packets there > are no UDP/TCP headers present from which you can get a port number. So I > want to ask if it is possible to modify pcap behaviour and where to start. > You can tell that a packet should be passed up if the ID in the IP header > matches, the problem of course is if a fragment arrives before the first > packet. I would prefer a modification in pcap, instead of the sniffer, > regarding performance. > > Any suggestions? You could write a BPF expression to match a particular packet id#. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Patch to print out IP data in PPP HDLC packets
I've been using this patch to print IP packets inside PPP HDLC
frames found in raw 1xRTT traffic. I've been able to find few
details on the actual PPP header format apart from what "0x7eff"
means and observing traffic for 0x7e21. The end result is extra
output of the form "{ PPP HDLC IP 1.2.3.4 > 2.3.4.5: GREv1call 0}"
It may not be particularly efficient because it malloc's a new
buffer for each packet (rather than using a static buffer) but
better that than limit the program's capabilities w.r.t recursive
decoding was what I decided.
Darren
*** print-ppp.c.origWed Mar 24 14:30:06 2004
--- print-ppp.c Thu Jul 1 21:01:59 2004
***
*** 370,375
--- 370,376
static int print_ccp_config_options (const u_char *p, int);
static int print_bacp_config_options (const u_char *p, int);
static void handle_ppp (u_int proto, const u_char *p, int length);
+ static int ppp_hdlc(const u_int proto, const u_char *p, int length);
/* generic Control Protocol (e.g. LCP, IPCP, CCP, etc.) handler */
static void
***
*** 1052,1057
--- 1053,1109
}
+ static int
+ ppp_hdlc(const u_int proto, const u_char *p, int length)
+ {
+ u_char *b, *s, *t, c;
+ int i, l, offset;
+ const void *se;
+
+ switch (proto & 0xff)
+ {
+ case 0xff :
+ if (p[0] != 3 || p[1] != 0 || p[2] != 0x21)
+ return -1;
+ offset = 3;
+ break;
+ case 0x21 :
+ offset = 0;
+ break;
+ default :
+ return -1;
+ }
+
+ b = (u_char *)malloc(length);
+ if (b == NULL)
+ return -1;
+
+ /*
+* Unescape all the data into a temporary, private, buffer.
+* Do this so that we dont overwrite the original packet
+* contents.
+*/
+ for (s = (u_char *)p + offset, t = b, i = length; i > 0; i--) {
+ c = *s++;
+ if (c == 0x7d) {
+ if (i > 1) {
+ i--;
+ c = *s++ ^ 0x20;
+ } else
+ continue;
+ }
+ *t++ = c;
+ }
+
+ printf("PPP-HDLC ");
+ se = snapend;
+ snapend = t;
+ ip_print(b, t - b);
+ snapend = se;
+ free(b);
+ }
+
+
/* PPP */
static void
handle_ppp(u_int proto, const u_char *p, int length)
***
*** 1097,1105
mpls_print(p, length);
break;
default:
! printf("unknown PPP protocol (0x%04x)", proto);
! print_unknown_data(p,"\n\t",length);
! break;
}
}
--- 1149,1159
mpls_print(p, length);
break;
default:
! if (((proto >> 8) != 0x7e) || (ppp_hdlc(proto, p, length) == -1)) {
! printf("unknown PPP protocol (0x%04x)}", proto);
! print_unknown_data(p,"\n\t",length);
! }
! break;
}
}
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Patch to print out IP data in PPP HDLC packets
In some email I received from Hannes Gredler, sie wrote:
> darren,
>
> can we have a .pcap sample showing such a frame for
> the /tests directory ?
I've semi-hand constructed this file because of privacy
concerns about the real data.
I've also included a new version of the patch (moved the
unescaping of HDLC data before looking at bytes after the
leading 0x7e.)
The output for me is like this (non-verbose):
17:38:55.122210 IP 10.0.17.34.1701 > 10.1.34.51.1701: l2tp:[LP](2/1) {PPP-HDLC IP
10.17.34.51 > 10.17.51.68: GREv1call 54429 seq 1515870810 ack 1515870810
gre-ppp-payload}
17:38:55.122210 IP 10.1.17.34.1701 > 10.17.34.51.1701: l2tp:[L](24722/10922) {unknown
PPP protocol (0x7ec0)}
0x: 217d 295d 7d20 7d28 6089 ca54 ffaa}
17:38:55.122210 IP 10.17.34.51.1701 > 10.1.17.34.1701: l2tp:[LP](2/4) {unknown PPP
protocol (0x7eff)}
0x: 03c0 210a 5d00 0852 4124 9e85 317e}
17:38:55.122210 IP 10.1.17.34.1701 > 10.17.34.51.1701: l2tp:[L](24735/12328)
{PPP-HDLC IP 10.1.34.51 > 10.17.34.51: GREv1call 17380 seq 90 gre-ppp-payload}
17:38:55.122210 IP 10.17.34.51.1701 > 10.1.17.34.1701: l2tp:[LP](2/4) {unknown PPP
protocol (0x7eff)}
0x: 03c0 210a 5e00 0852 4124 9eeb 997e}
17:38:55.122210 IP 10.1.17.34.1701 > 10.17.34.51.1701: l2tp:[L](24551/3750) {unknown
PPP protocol (0x7eff)}
0x: 7d23 c021 7d21 267d 207d 347d 227d 267d
0x0010: 207d 207d 207d 207d 257d 2665 f1b2 377d
0x0020: 277d 227d 287d 223c 6b7e}
Looks like a bug in print_unknown_data ^^^ generating that }.
Or maybe not...If you remove the } I added after the (0x7e..),
it doesn't seem that out of place.
Darren
hdlc.pcap
Description: Binary data
*** print-ppp.c.origWed Mar 24 14:30:06 2004
--- print-ppp.c Thu Jul 1 21:01:59 2004
***
*** 370,375
--- 370,376
static int print_ccp_config_options (const u_char *p, int);
static int print_bacp_config_options (const u_char *p, int);
static void handle_ppp (u_int proto, const u_char *p, int length);
+ static int ppp_hdlc(const u_int proto, const u_char *p, int length);
/* generic Control Protocol (e.g. LCP, IPCP, CCP, etc.) handler */
static void
***
*** 1052,1057
--- 1053,1109
}
+ static int
+ ppp_hdlc(const u_int proto, const u_char *p, int length)
+ {
+ u_char *b, *s, *t, c;
+ int i, l, offset;
+ const void *se;
+
+ switch (proto & 0xff)
+ {
+ case 0xff :
+ if (p[0] != 3 || p[1] != 0 || p[2] != 0x21)
+ return -1;
+ offset = 3;
+ break;
+ case 0x21 :
+ offset = 0;
+ break;
+ default :
+ return -1;
+ }
+
+ b = (u_char *)malloc(length);
+ if (b == NULL)
+ return -1;
+
+ /*
+* Unescape all the data into a temporary, private, buffer.
+* Do this so that we dont overwrite the original packet
+* contents.
+*/
+ for (s = (u_char *)p + offset, t = b, i = length; i > 0; i--) {
+ c = *s++;
+ if (c == 0x7d) {
+ if (i > 1) {
+ i--;
+ c = *s++ ^ 0x20;
+ } else
+ continue;
+ }
+ *t++ = c;
+ }
+
+ printf("PPP-HDLC ");
+ se = snapend;
+ snapend = t;
+ ip_print(b, t - b);
+ snapend = se;
+ free(b);
+ }
+
+
/* PPP */
static void
handle_ppp(u_int proto, const u_char *p, int length)
***
*** 1097,1105
mpls_print(p, length);
break;
default:
! printf("unknown PPP protocol (0x%04x)", proto);
! print_unknown_data(p,"\n\t",length);
! break;
}
}
--- 1149,1159
mpls_print(p, length);
break;
default:
! if (((proto >> 8) != 0x7e) || (ppp_hdlc(proto, p, length) == -1)) {
! printf("unknown PPP protocol (0x%04x)", proto);
! print_unknown_data(p,"\n\t",length);
! }
! break;
}
}
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] print-gre.c INET6
In some email I received from alex medvedev, sie wrote: > hi, > > i think print-gre.c needs a #ifdef INET6 around > > case ETHERTYPE_IPV6: > ip6_print(bp, len); > break; > > otherwise tcpdump does not build if compiled without ipv6 support. > but who does that anyway? :) I bumped into it yesterday trying to compile tcpdump on RedHat 9.0. Yes, the patch (for #ifdef INET6-#endif) is required so long as there is a "#define INET6" in config.h. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] jump to a packet flag
In some email I received from alex medvedev, sie wrote: > hallo, > > any interest in having a -j flag in tcpdump? > > the flag would simply jump over the specified number of packets. > it may be useful when reading dumps with -r flag. > it may also be useful in conjuction with -c flag to isolate certain > interval from a dump. > > a callback function called spin() could added that would be invoked when a > -j flag is specified. > something like this: I think you're better off over-using the '-c' command line option. e.g. tcpdump -c 100 print the first 100 packets tcpdump -c 100: print packets from 100 onwards tcpdump -c 100:200 print packets from 100 to 200 tcpdump -c 10:20,40:50 or tcpdump -c 10:20 -c 40:50 print packets 10-20 and 40-50 but what would you want this to do: tcpdump -c 1,3,5,7,9,11,13,15,17 should that automatically "fill out" to be: tcpdump -c 1:1,3:3,5:5,7:7,9:9,11:11,13:13,15:15,17:17 or something else ? Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Patch to print out IP data in PPP HDLC packets
In some email I received from Hannes Gredler, sie wrote: > i have some questions wrt to the format based on the .pcap > file that you supplied; > > the 1st byte 0x7e seems to introduce a HDLC frame; > > after that i can see 4 different frame formats: Yes. I thought it might be useful to provide a set of the different frames I observed so you have a better grounding for testing, etc. > frame 1 0x: 2145 6edc 5a00 006a 2f52 080a 1122 > 0x0010: 330a 1133 4430 8188 0b00 4ad4 9d5a 5a5a > 0x0020: 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a > 0x0030: 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a > 0x0040: 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a > 0x0050: 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a > 0x0060: 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a 5a7d 5d7d > 0x0070: 5d > > this seems to be some sort of shortcut IP frame ... 21 being > codepoint for IPv4; should be use then 0x57 for IPv6 ? I don't know. Maybe? I've only coded printing of what I could see & understand. > frame 2 0x: c021 7d29 5d7d 207d 2860 89ca 54ff > > this looks like a LCP frame , correct ? so the second > format is a fully blown PPP proto-id; "don't know". I wasn't sure if the HDLC PPP should have LCP in it or not. I suppose it makes sense for it to do so. I couldn't find anything explicitly mentioning that frame format so I punted on it. > frame 6 0x: ff7d 23c0 217d 2126 7d20 7d34 7d22 7d26 > 0x0010: 7d20 7d20 7d20 7d20 7d25 7d26 65f1 b237 > 0x0020: 7d27 7d22 7d28 7d22 3c6b > > ok this one i have some problems with ... 0xc021 looks like LCP > again but what is 0xff7d23 ? The 7d23 is 03 encoded with bit-stuffing (see RFC 1662 as Guy pointed out.) Just one comment on the code - why not eliminate the "goto cleanup" by including the default case code inside the default switch ? As you know, goto's are evil ;) Maybe nested switch's are too :) Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] patch for print-gre.c and IPv6
hope the white space is ok, it's a cut-n-paste. *** print-gre.c.origSun Jun 13 02:32:56 2004 --- print-gre.c Sun Jul 4 03:30:00 2004 *** *** 195,203 --- 195,205 case ETHERTYPE_IP: ip_print(bp, len); break; + #ifdef INET6 case ETHERTYPE_IPV6: ip6_print(bp, len); break; + #endif case ETHERTYPE_MPLS: mpls_print(bp, len); break; - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] tcpdump-current.tar.gz
Seems frozen on 2004.06.28 ? Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Patch to print out IP data in PPP HDLC packets
> Normally a NIC or interface providing access to an HDLC link/network would
> perform de-bytestuffing internally before the packets ever get to libpcap.
> Obviously de-bytestuffing a packet twice can corrupt data. Do we really
> want to have de-bytestuffing code in libpcap?
This isn't in libpcap, it's tcpdump.
> Surely at minimum it should be off by default and selectable as an option
> perhaps, if necessary?
No.
The frame format here is something like this:
ethernet{ip{l2tp{hdlc{ppp{ip{gre{ppp{...
I'm sniffing at the ethernet level, and I want to see inside as many
headers as I can with tcpdump, so that means de-bitstuffing the HDLC.
Darren
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] patch for print-ppp.c
Rather than just hexdump the PPP data and say "unknown PPP proto (0x00fb)",
I thought it might be better to print out a nicer message...
--- print-ppp.c.orig2004-07-05 18:30:38.0 +1000
+++ print-ppp.c 2004-07-05 18:30:47.0 +1000
@@ -1170,6 +1170,9 @@
case PPP_MPLS_MCAST:
mpls_print(p, length);
break;
+ case PPP_COMP:
+ printf("compressed data");
+ break;
default:
printf("unknown PPP protocol (0x%04x)", proto);
print_unknown_data(p,"\n\t",length);
Darren
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] patch for print-ppp.c
> Rather than just hexdump the PPP data and say "unknown PPP proto (0x00fb)",
> I thought it might be better to print out a nicer message...
>
> --- print-ppp.c.orig2004-07-05 18:30:38.0 +1000
> +++ print-ppp.c 2004-07-05 18:30:47.0 +1000
> @@ -1170,6 +1170,9 @@
> case PPP_MPLS_MCAST:
> mpls_print(p, length);
> break;
> + case PPP_COMP:
> + printf("compressed data");
> + break;
Looks better if its "compressed PPP data" :)
Darren
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] core dump with PPP messages 1 byte long.
If ppp_hdlc() is called with length < 2, bad things happen.
Notably, if length == 1, handle_ppp() will be called with "length < 0".
At this point, things get ugly and print_unknown_data() tries to print
way too much data.
If ppp_hdlc() is being called with "p - 1", shouldn't the next parameter
be "length + 1" ?
Reading the code some more, it would appear that handle_ppp() needs to
be safe if "length == 0" ('nice case' from ppp_hdlc_if_print() where
caplen >=4 for PPP_ADDRESS).
Hmmm, in ppp_hdlc_if_print(), the use of length seems to be all wrong
where "caplen < len" (caplen is totally ignored.) Surely there must
be at least something like "if (length > caplen) length = caplen;"
in there somewhere ?
Hmmm, ppp_hdlc() should check for 'snapend[-1] == 0x7e' and truncate by
one byte if true (something like "if (*(t -1) == 0x7e) t--;" would be
the go ?)
But seriously, either handle_ppp() or ppp_hdlc() need to do some length
checking to prevent mishap. Maybe both ?
btw, there's a type inconsistency between the declaration of '*b'
and its 1st use in ppp_hdlc() - declared "u_char *" but assigned
a "u_int8_t *". That's just nit picking :)
The particular frame that caught this problem was similar to:
00112233 44550011 22334455 0800
4527 bec5 fb11 0a00 0c00
06a506a5 0013
4002000b 60d12695
7e2f7e
It would appear that this is an empty PPP_VJNC packet.
Darren
Ths stack trace looks like this:
#0 0x08050958 in hex_print_with_offset (ident=0x80be1b8 "\n\t", cp=0x81d5000 , length=4294967295, oset=2048)
at print-ascii.c:151
#1 0x080509d7 in hex_print (ident=0x0, cp=0x5 ,
length=136138752) at print-ascii.c:167
#2 0x08095257 in print_unknown_data (cp=0x81d4802 "", ident=0x80be1b8 "\n\t", len=-1)
at util.c:211
#3 0x0807bb60 in handle_ppp (proto=12035, p=0x81d4802 "", length=-1) at
print-ppp.c:1178
#4 0x0807b8f5 in ppp_hdlc (p=0x819997d "/~", length=1) at print-ppp.c:1112
#5 0x0807b93d in handle_ppp (proto=32303, p=0x819997e "~", length=1) at
print-ppp.c:1128
#6 0x0807bcde in ppp_print (p=0x819997e "~", length=1) at print-ppp.c:1226
#7 0x0806c2f1 in l2tp_print (dat=0x8199974 "@\002", length=11) at print-l2tp.c:701
#8 0x080915de in udp_print (bp=0x819996c "\006¥\006¥", length=11, bp2=0x8199958 "E",
fragmented=0) at print-udp.c:631
#9 0x08063031 in ip_print (bp=0x8199958 "E", length=46) at print-ip.c:539
#10 0x0805dfee in ether_encap_print (ether_type=2048, p=0x8199958 "E", length=46,
caplen=46, extracted_ether_type=0xb2f0) at print-ether.c:189
#11 0x0805de11 in ether_print (p=0x8199958 "E", length=46, caplen=46) at
print-ether.c:142
#12 0x0805de7f in ether_if_print (h=0xb360, p=0x819994a "") at print-ether.c:162
#13 0x08094b65 in print_packet (user=0xb530 "bÞ\005\b", h=0xb360, sp=0x819994a
"") at tcpdump.c:1188
#14 0x080a77a1 in pcap_offline_read (p=0x8199768, cnt=-1, callback=0x8094b1a
, user=0xb530 "bÞ\005\b") at savefile.c:941
#15 0x0809b70d in pcap_loop (p=0x8199768, cnt=-1, callback=0x8094b1a ,
user=0xb530 "bÞ\005\b") at pcap.c:96
#16 0x08094731 in main (argc=3, argv=0xb5a4) at tcpdump.c:997
#17 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] core dump with PPP messages 1 byte long.
I believe the sessions I am seeing start out with a conversation like this:
IP 1.1.1.1.1701 > 2.2.2.2.1701: l2tp:[TLS](24460/0)Ns=23236,Nr=646 *MSGTYPE(HELLO)
IP 2.2.2.2.1701 > 1.1.1.1.1701: l2tp:[TLS](4/0)Ns=646,Nr=23237 ZLB
IP 1.1.1.1.1701 > 2.2.2.2.1701: l2tp:[TLS](24460/0)Ns=23237,Nr=646 *MSGTYPE(HELLO)
IP 2.2.2.2.1701 > 1.1.1.1.1701: l2tp:[TLS](4/0)Ns=646,Nr=23238 ZLB
IP 1.1.1.1.1701 > 2.2.2.2.1701: l2tp:[TLS](24460/0)Ns=23238,Nr=646 *MSGTYPE(ICRQ)
*ASSND_SESS_ID(3) *CALL_SER_NUM(4) *CALLING_NUMBER(000) *SUB_ADDRESS(ABCD)
*VENDOR0c7f:ATTR0067() *VENDOR0c7f:ATTR0065()
IP 2.2.2.2.1701 > 1.1.1.1.1701: l2tp:[TLS](4/0)Ns=646,Nr=23239 ZLB
IP 2.2.2.2.1701 > 1.1.1.1.1701: l2tp:[TLS](4/3)Ns=646,Nr=23239 *MSGTYPE(ICRP)
*ASSND_SESS_ID(3222)
IP 1.1.1.1.1701 > 2.2.2.2.1701: l2tp:[TLS](24460/3222)Ns=23239,Nr=647 *MSGTYPE(ICCN)
*TX_CONN_SPEED(156000) *FRAMING_TYPE(A)
*VENDOR0c7f:ATTR0066(00) RX_CONN_SPEED(156000)
IP 2.2.2.2.1701 > 1.1.1.1.1701: l2tp:[LP](4/3) {LCP, Conf-Request (0x01), id 190,
Magic-Num (5) 0x1fecaee1, MRU (1) 1500, ACCM (2) 0x, Auth-Prot (3) CHAP, MD5,
length 28}
IP 2.2.2.2.1701 > 1.1.1.1.1701: l2tp:[TLS](4/0)Ns=647,Nr=23240 ZLB
IP 1.1.1.1.1701 > 2.2.2.2.1701: l2tp:[TLS](24460/0)Ns=23240,Nr=647 ZLB
IP 1.1.1.1.1701 > 2.2.2.2.1701: l2tp:[L](24460/3222) {LCP, Conf-Request (0x01), id 6,
ACCM (2) 0x, Magic-Num (5) 0x65f355dd, PFC (7), ACFC (8), length 23}
(sorry about all the 0's and IP#'s but...)
The closest thing I can find that comes close to what I'm looking at is:
http://www.ericsson.com/about/publications/review/2001_02/files/2001025.pdf
> > If ppp_hdlc() is called with length < 2, bad things happen.
>
> Should it be called *at all* from "handle_ppp()"?
The reason I've described it as L2TP/PPP with HDLC encoding inside that
is that when I look at the files with ethereal, I see
+Frame
+Ethernet II
+Internet Protocol
+User Datagram Protocol
+Layer 2 Tunneling Protocol
+Point-to-Point Protocol
Data (x bytes)
Ethereal already understands GTP/GPRS (the other protocols I'm looking at.)
But all of the real CDMA/1xRTT stuff is ITU defined (= $$ to obtain.)
> Or is that heuristic insufficient - in the example you gave, you
> indicate that the packet might be an empty PPP_VJNC packet rather than
> an HDLC-over-L2TP packet?
The example that caused the crash is what I would interpret to be an
empty PPP_VJNC packet encoded with HDLC sent over L2TP.
Darren
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] core dump with PPP messages 1 byte long.
> On Wed, Jul 07, 2004 at 04:21:39PM +1000, Darren Reed wrote: > > IP 1.1.1.1.1701 > 2.2.2.2.1701: l2tp:[TLS](24460/3222)Ns=23239,Nr=647 > >*MSGTYPE(ICCN) *TX_CONN_SPEED(156000) *FRAMING_TYPE(A) > >*VENDOR0c7f:ATTR0066(00) RX_CONN_SPEED(156000) > > I'm not sure what the "framing type" in an L2TP session signifies - does > it signify what framing is used for the PPP traffic once it leaves the > L2TP tunnel, or does it (for some not-entirely obvious reason) signify > what framing is used *inside* the tunnel? I don't know any more than you here. > RFC 2661 says [...] > which sounds as if you're *not* supposed to send PPP frames over the > wire in RFC 1662 byte-stuffed form. I'm inclined to agree with you here and the comments about CDMA2000. > > But all of the real CDMA/1xRTT stuff is ITU defined (= $$ to obtain.) > > What about > > http://www.3gpp2.org/Public_html/specs/index.cfm Thanks, I'll have a look. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Bug in print-ppp.c
I've come across a packet that causes me to get a stack trace something like this: #0 0x in ?? () #1 0x0807a0bd in handle_ctrl_proto (proto=32855, pptr=0x8195c82 "\001", length=14) at print-ppp.c:450 #2 0x0807be24 in handle_ppp (proto=32855, p=0x8195c82 "\001", length=14) at print-ppp.c:1143 #3 0x0807c072 in ppp_print (p=0x8195c82 "\001", length=14) at print-ppp.c:1229 #4 0x0805fd22 in gre_print_1 (bp=0x8195c80 "\200W\001", length=28) at print-gre.c:305 #5 0x0805f757 in gre_print (bp=0x8195c74 "0\001\210\v", length=28) at print-gre.c:108 #6 0x080634c2 in ip_print (bp=0x8195c60 "E", length=48) at print-ip.c:606 #7 0x08060307 in gtpv1u_print (bp=0x8195c60 "E", length=48) at print-gtp.c:323 #8 0x080919d6 in udp_print (bp=0x8195c4c "\bh\bh", length=60, bp2=0x8195c38 "E", fragmented=0) at print-udp.c:635 #9 0x080633b9 in ip_print (bp=0x8195c38 "E", length=88) at print-ip.c:539 #10 0x0805e062 in ether_encap_print (ether_type=2048, p=0x8195c38 "E", length=88, caplen=88, extracted_ether_type=0xb2d0) at print-ether.c:189 #11 0x0805de85 in ether_print (p=0x8195c38 "E", length=88, caplen=88) at print-ether.c:142 #12 0x0805def3 in ether_if_print (h=0xb340, p=0x8195c2a "") at print-ether.c:162 #13 0x08094fc9 in print_packet (user=0xb520 "ÖÞ\005\b", h=0xb340, sp=0x8195c2a "") at tcpdump.c:1188 #14 0x080a389a in pcap_offline_read () #15 0x0809b486 in pcap_loop () #16 0x08094b55 in main (argc=5, argv=0xb594) at tcpdump.c:997 #17 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Somewhere around like 445, print-ppp.c has: default: /* * This should never happen, but we set * "pfunc" to squelch uninitialized * variable warnings from compilers. */ pfunc = NULL; break; } Adding a printout after the closing }, I see this for one packet: pfunc (nil) tptr 0x8195c86 len 14 x 10 proto 0x8057 ptr 0x8195c82 length 14 We've come here from handle_ppp() which calls handl_ctrl_proto() for PPP_IPV6CP. This patch (modulo white space) solves this problem for now. *** print-ppp.c 8 Jul 2004 11:10:37 - 1.2 --- print-ppp.c 13 Jul 2004 05:01:15 - *** *** 447,452 --- 447,454 pfunc = NULL; break; } + if (pfunc == NULL) + break; if ((j = (*pfunc)(tptr, len)) == 0) break; x -= j; Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] UDP-lite (rfc 3828)
A new RFC (3828) documents a slightly modified UDP protocol,
#136, called "UDP-Lite". For the true geeks, 136 is 10001000
and UDP (17) is 00010001 :)
The main difference is the length field bcomes a checksum length
field with valid values 0,[8,65535]. This indicates the amount
of data in the 'UDP' portion of the packet to checksum. A value
of 0 indicates "all", 8 is just the UDP header, and so on.
Values for this field in the interval [1,7] are not valid.
I expect that the same port assignments for UDP will exist for
UDP-lite and given this, it might be appropriate to also use
uporttable[] (addrtoname.c) for udplite as well as udp ?
I've roughed up some patches below to account for IPPROTO_UDPLITE,
but the real problem is no real packets to test it on :-o The
patches overload print-udp.c, which seems like a better idea than
creating print-udplite.c given the extreme similariies but if
someone wants to disagree, I won't stop you.
Darren
Index: interface.h
===
diff -c -u -r1.1.1.1 interface.h
--- interface.h 8 Jul 2004 11:07:12 - 1.1.1.1
+++ interface.h 14 Jul 2004 06:16:50 -
@@ -252,7 +252,7 @@
extern void tcp_print(const u_char *, u_int, const u_char *, int);
extern void tftp_print(const u_char *, u_int);
extern void timed_print(const u_char *);
-extern void udp_print(const u_char *, u_int, const u_char *, int);
+extern void udp_print(const u_char *, u_int, const u_char *, int, int);
extern void wb_print(const void *, u_int);
extern int ah_print(register const u_char *);
extern void isakmp_print(const u_char *, u_int, const u_char *);
Index: ipproto.h
===
diff -c -u -r1.1.1.1 ipproto.h
--- ipproto.h 8 Jul 2004 11:07:12 - 1.1.1.1
+++ ipproto.h 14 Jul 2004 06:13:34 -
@@ -136,3 +136,6 @@
#ifndef IPPROTO_MOBILITY
#define IPPROTO_MOBILITY 135
#endif
+#ifndef IPPROTO_UDPLITE
+#define IPPROTO_UDPLITE136 /* Lightweight User Datagram
Protocol (RFC 3828) */
+#endif
Index: netdissect.h
===
diff -c -u -r1.1.1.1 netdissect.h
--- netdissect.h8 Jul 2004 11:07:12 - 1.1.1.1
+++ netdissect.h14 Jul 2004 06:16:55 -
@@ -363,7 +363,7 @@
extern void tftp_print(netdissect_options *,const u_char *, u_int);
extern void timed_print(netdissect_options *,const u_char *, u_int);
extern void udp_print(netdissect_options *,const u_char *, u_int,
- const u_char *, int);
+ const u_char *, int, int);
extern void wb_print(netdissect_options *,const void *, u_int);
extern int ah_print(netdissect_options *,register const u_char *,
register const u_char *);
Index: print-ip.c
===
diff -c -u -r1.1.1.1 print-ip.c
--- print-ip.c 8 Jul 2004 11:07:12 - 1.1.1.1
+++ print-ip.c 14 Jul 2004 06:06:53 -
@@ -536,7 +536,8 @@
break;
case IPPROTO_UDP:
- udp_print(cp, len, (const u_char *)ip, (off &~ 0x6000));
+ case IPPROTO_UDPLITE:
+ udp_print(cp, len, (const u_char *)ip, (off &~ 0x6000), nh);
break;
case IPPROTO_ICMP:
Index: print-udp.c
===
diff -c -u -r1.2 print-udp.c
--- print-udp.c 8 Jul 2004 11:10:37 - 1.2
+++ print-udp.c 14 Jul 2004 07:46:43 -
@@ -107,20 +107,22 @@
#define RTCP_PT_APP204
static void
-vat_print(const void *hdr, register const struct udphdr *up)
+vat_print(const void *hdr, register const struct udphdr *up, int protocol)
{
/* vat/vt audio */
u_int ts = *(u_int16_t *)hdr;
if ((ts & 0xf060) != 0) {
/* probably vt */
- (void)printf("udp/vt %u %d / %d",
+ (void)printf("udp%s/vt %u %d / %d",
+ (protocol == IPPROTO_UDPLITE) ? "lite" : "",
(u_int32_t)(EXTRACT_16BITS(&up->uh_ulen) - sizeof(*up)),
ts & 0x3ff, ts >> 10);
} else {
/* probably vat */
u_int32_t i0 = EXTRACT_32BITS(&((u_int *)hdr)[0]);
u_int32_t i1 = EXTRACT_32BITS(&((u_int *)hdr)[1]);
- printf("udp/vat %u c%d %u%s",
+ printf("udp%s/vat %u c%d %u%s",
+ (protocol == IPPROTO_UDPLITE) ? "lite" : "",
(u_int32_t)(EXTRACT_16BITS(&up->uh_ulen) - sizeof(*up) - 8),
i0 & 0x,
i1, i0 & 0x80? "*" : "");
@@ -133,7 +135,7 @@
}
static void
-rtp_print(const void *hdr, u_int len, register const struct udphdr *up)
+rtp_print(const void *hdr, u_int len, register const struct udphdr *up, const int
[tcpdump-workers] Making the filter language more expandable
One of the big problems I have with tcpdump and libpcap, today, is the limitations in the filter language. As a quick example, while it understands IP header bits and port numbers, I can't do 'tcpdump gre_v 1' in the same way I can do 'tcpdump port 2', etc. Taking it out to what I'd like to see (define new protocols as keywords and byte offsets in some text file) is unquestionably not a simple task and is not something I'd like to see delay a release labelled 1.0. Has anyone else done any work on something like this or given it any more, in depth, thought than I have to date ? Cheers, Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Building IPv6 code in tcpdump on systems without
In some email I received from Guy Harris, sie wrote: > I have some changes to support that. > > The main change is to add a "union h6addr" to "tcpdump-stdinc.h", along > with defintions of IN6_IS_ADDR_UNSPECIFIED, AF_INET6, and NI_MAXHOST if > they're not defined. > > Some side-effects of this: > > 1) it defines DEFAULT_SNAPLEN as 96 unconditionally, rather > than, as is done now, as 68 if INET6 isn't defined and as 96 > if it is defined; > > The first seems OK to me, although some might find it a surprise. You > can always use "-s 68" if you want 68 bytes. I agree with this. 96..plus pcap header size of 16 is 112. Do you want to push it out to 112, so with the pcap header size, brings it up to 128 bytes (normal length), fitting in evenly to most buffer sizes? Oh wait, that's the "max" pcapture size so ignore that :) Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Building IPv6 code in tcpdump on systems without
In some email I received from John Hawkinson, sie wrote: > Guy Harris <[EMAIL PROTECTED]> wrote on Tue, 20 Jul 2004 > at 23:21:17 -0700 in <[EMAIL PROTECTED]>: > > > 1) it defines DEFAULT_SNAPLEN as 96 unconditionally, rather > >than, as is done now, as 68 if INET6 isn't defined and as 96 > >if it is defined; > > > > The first seems OK to me, although some might find it a surprise. You > > can always use "-s 68" if you want 68 bytes. > > Won't this have unfortunate effects on performance (and possibly storage, > but that's less concerning) for some people in borderline situations? Why don't you measure it and tell us all exactly how bad the degradation is ? Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Bug in print-ppp.c
> This looks like Debian bug #255179, I fixed it differently by not trying > to analyze IPV6CP, a comment in print-ppp.c says that it's not supported > (yet). > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=255179&archive=yes > > Corresponding fix currently in the Debian package (notice how the IPV6CP > case is outside #ifdef INET6, too): While this does solve the problem for IPV6CP, there are now other ways for the code to reach this point - i.e other protocols - and just applying this check would leave tcpdump vulnerable to crashing if it encountered one of those. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] advice for heavy traffic capturing
In some email I received from Motonori Shindo, sie wrote: > Hi, > > I'm involved in a project to do some network traffic analysis. One of > the goals of this project is to identify an equipment that is > supposedly dropping packets. My idea to achieve this goal is to > capture traffic by tcpdump at both sides of equipment in question and > compare them to determine whether it is actually dropping packets (I > probably need to do some programming here). First thing, you need to get yourself a network tap. Something like this: http://www.netoptics.com/products/product_family_details.asp?cid=1&pid=60&Section=products&menuitem=1 That might not be the exact item you need, but it should put you on the right path. This will cost you money. These devices are the only real way to go if you want to have a hope of capturing full duplex data without loss. > My concern is how fast > tcpdump can keep up with without any packet loss. This is not a tcpdump problem, so much as it is a choice of hardware and operating system. If you can find out what buffering the various cards have to go into the monitoring station, try and use (buy) the one with the most. Next, use BSD-something. Forget about Linux/Windows/Darwin. Linux 2.6 seems to be much worse than 2.4 ever was. > The traffic that I > have to monitor is around 150Mbps at a peak time. At that point, you may get upto 150Mpbs out without loss. However, you may have to build your own libpcap/tcpdump where you increase the BPF buffer size upto 1MB or so if it doesn't get set that high to start with. Similarly, to give yourself a good chance, you want to be using hardware with high internal bandwidth (533Mhz FSB, etc.) If you can, PCI-X or 64bit or 66MHz PCI. > I'd like to know which > component is likely the most contributing factor to get higher > performance. In testing upto 100Mbps, it was the NIC. With 100BaseT NICs, the best was the Intel Pro 100S. After that, the next bottle neck (with GigE cards) was PCI. 33MHz, 32bit PCI is just on 1Gbps. I've been able to capture at between 900Mbps-1Gbps with multiple NICs. Going to 66MHz and 64bit gets you 4Gbps. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] advice for heavy traffic capturing
In some email I received from Fulvio Risso, sie wrote:
> Darren, could you please give us some numbers?
> If you take a look at this paper:
>
> F. Risso, L. Degioanni
> An architecture for high performance network analysis
>
> http://ieeexplore.ieee.org/iel5/7446/20240/00935450.pdf?tp=&arnumber=935450&;
> isnumber=20240&arSt=686&ared=693&arAuthor=Risso%2C+F.%3B+Degioanni%2C+L.%3B
I don't have an IEEE login. Feel free to email it to me.
> and this:
>
> L. Deri
> Improving Passive Packet Capture:Beyond Device Polling
> http://luca.ntop.org/Ring.pdf
I tried the patches, for Linux, out from this paper and they hung the
machine. I didn't have time to play so I moved on. This could very
well be to do with the problem of 'N' versions of the Linux kernel and
the one I tried was not the exact same one as the people who did the
development. I don't know and I don't care - it didn't work for me.
> it seems that Windows is the most performing OS (without any ad-hoc patch).
Maybe it is more to do with drivers and NICs or maybe not. I was able to
get similar performance out of FreeBSD and NetBSD (on the same hardware),
without any tweaks. Maybe {Free,Net}BSD have better drivers for Intel
hardware than Linux ? *shrug*
> Do you have anything (possible published somewhere) supporting what you're
> saying?
No...I was going to do something like that but it requires permission from
the people I'm doing the work for to do so.
But, to give you an idea of the sort of problems we saw with Linux, moving
from RedHat 9 (kernel 2.4) to Fedora (kernel 2.6), we saw an increase in
packet loss of 10x (one order of magnitude) from as low as 1Mbps all the
way up. When we saw that we realised that it was time to starting planning
to move away from Linux.
Darren
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] advice for heavy traffic capturing
In some email I received from Guy Harris, sie wrote: > Also, speaking of capture speed and memory-mapped devices, there was a > freebsd-hackers thread discussing a netgraph module providing > memory-mapped access to captured packets: I did some similar work for bpf & mmap with NetBSD. See: http://mail-index.netbsd.org/tech-net/2004/05/02/0001.html and http://mail-index.netbsd.org/tech-net/2004/05/21/0001.html Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] advice for heavy traffic capturing
[ Charset ISO-8859-1 unsupported, converting... ] > http://netgroup.polito.it/fulvio.risso/pubs/iscc01-wpcap.pdf When was it published? There is no date... Winpcap appears, by design, to be the same as BPF. If you reduced the number of buffers in the ring used with NPF to 2 buffers, I suspect it would be the same as BPF ? And because there is no date, I can say that references to the buffer size being 32Kbytes in recent BSD kernels is wrong. Recent BSD kernels use 1MB or 2MB buffers, by default. Although it then contradicts itself later by saying there are larger buffers but that pcap tunes it down to 32K(page 2 vs page 3.) > Hardware counts, but... we have been really careful to optimize the whole > path from the NIC card to the application. > See another article on this topic (it covers only Win32): > >L. Degioanni, M. Baldi, F. Risso, G. Varenni >Profiling and Optimization of Software-based Network Analysis > Applications >http://netgroup.polito.it/fulvio.risso/pubs/sbac03-winpcap.pdf No date on the paper, here, either. > Particularly, Figure 9 shows how much work has been done to reduce the > processing overhead. Interestingly, there are a few large areas for improvement: timestamp (1800 -> 270), Tap processing (830->560) and filtering (585 -> 109). > And yes, NIC drivers and OS overheads are very important... but these are > the components that cannot be changed by normal users. I think that's what you're seeing with the 3Com GigE NIC for 100BT receiving. Do you know what size the buffers on the card are ? The Intel 100 ProS have 128K for receieve, as I recall, the same as the 1000MX card. There wasn't much between these two, that I was able to observe, except that the 100ProS was slightly better. My biggest problem here is that you've expended effort to tune and make NPF fast (which is fine) and compare it with existing BPF, almost to say that BPF is bad. I suppose this is what researchers do, but I think it is unfair on BPF. IMHO, you should have tested with the same buffer size for both, even if it meant hacking on libpcap. In the NetBSD emails, I think I ponder making changes to the buffering so that it is more ring-buffer like (similar to what exists within NPF if I understand the diagram right.) Is the JIT code easily ported to other platforms ? Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] advice for heavy traffic capturing
Hi Fulvio, > Fulvio Risso, Loris Degioanni, An Architecture for High Performance Network > Analysis, Proceedings of the 6th IEEE Symposium on Computers and > Communications (ISCC 2001), pg. 686-693, Hammamet, Tunisia, July 2001. Is there any way you can get this (and the other date info.) into those PDFs ? It really helps put them in perspective. > > Winpcap appears, by design, to be the same as BPF. If you reduced the > > number of buffers in the ring used with NPF to 2 buffers, I suspect it > > would be the same as BPF ? > > No, there are two different architectural choices. > The ring does not have buffers; it has just space for packets; space > occupancy is exactly the size of the packet. Ah, so you're using the buffers that the data is read into, off the NIC, to put into the ring ? Or to put in BSD terms, the ring is made up of mbuf pointers ? You would have to be careful to not hold on to the buffers for too long (or too many of them) or else surely you would run out ? That would make direct access to the buffers from user space (using mmap or similar) more involved. > > Interestingly, there are a few large areas for improvement: timestamp > > (1800 -> 270), Tap processing (830->560) and filtering (585 -> 109). > > ... and NIC drivers and Operating system overhead which, as you can see, > account for more or less 50% of the total overhead. Yup. > > The Intel 100 ProS have 128K for receieve, as I recall, the same as > > the 1000MX card. There wasn't much between these two, that I was able > > to observe, except that the 100ProS was slightly better. > > The amount of memory you have on the NIC is not very significant. > I cannot give you numbers right now, but this is not the parameter that > changes your life. Why not ? Well I suppose your results (if the 3com really does only have 16 or 32k of buffer) would support this. But maybe buffering is more important for BPF where you have the interrupt masked out for longer while the data is copied ? > = > A valuable result of this study is the quantitative conclusion that, > contrary to common belief, filtering and buffering are not the most critical > factors in determining packet capture performance. Optimization of these two > components, that received most attention so far, is shown to bring little > improvement to the overall packet capture cost, particularly in case of > short packets (or when small snapshot length are needed). The profiling done > on a real system shows that the most important bottlenecks lie in hidden > places, like device driver, interaction between application and OS, > interaction between OS and hardware. > = Hmmm, the testing I did would disagree with that, or at least so far as to say that there is a "sweet spot" for buffer sizes and data rates (at least with BPF.) The hardware does make some difference - one of our other test cards was a Netgear (FA-311?) and it was shit. My recollection was that with the data sample we were using, with 1MB captures enabled for BPF, at full speed, most reads were between 64k and 256k, at a time. There were other changes to BPF, unrelated to what you've changed, that reduced packet loss from X% to 0%. I copied these, this year, from FreeBSD to NetBSD but I don't recall their vintage on FreeBSD. > And, I would like to say, you need a global picture of where the bottleneck > are before doing optimizations. Oh, sure. And one of those limiting factors is PCI. > For instance, we're now working to decrease the 50% of the time spend by > each packet in the operating systems. You're still working with Windows ? > > In the NetBSD emails, I think I ponder making changes to the buffering > > so that it is more ring-buffer like (similar to what exists within NPF > > if I understand the diagram right.) > > Eh, what you're saying is good but... the double buffering in the BPF has an > advantage: it is much simpler, and if you're not interested in memory > occupancy, it is a very good choice. Yes. > We didn't realize it in 2001; now, we can see less black and white in the > choice between a double buffer and a ring buffer... What have you found that makes you say this ? The simplicity in cpu cycle cost ? > > Is the JIT code easily ported to other platforms ? > > Yes, as far as the platform is Intel ;-) That's fine with me :) Do you have a URL for this ? Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] advice for heavy traffic capturing
In some email I received from Loris Degioanni, sie wrote: > Other things: > - modern network cards don't almost do buffering. The memory inside the > board is usually few KB, and its purpose is providing the space for a packet > or two. The actual buffering is done in the RAM of the PC. What determines > the card performance is PHY efficiency and PCI bandwidth usage. Ok, so what do you have to say about NICs that have 128k buffers vs the small buffers on other cards? Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] advice for heavy traffic capturing
Hi Fulvio, > > What have you found that makes you say this ? > > The simplicity in cpu cycle cost ? > > 1. simplicity > 2. swappable buffers are very helpful if you plan to make statistics, not > only packet capture. > For instance, let's think about a system (like a NetFlow probe or something > like that) that collects statistics, then it returns data to the user every > N minutes. If you have two buffers you can put statistics in the first one, > while you can read data from the second one, and swap buffers every N > minutes. > If you have a ring buffer and your application wants to read data, you have > to stop collecting stats, lock the ring, copy its content in another buffer, > unlock the ring, read data from the second buffer, and restart computing > statistics. Is it really that hard with a ring ? At least on Unix I think the way to go would be to just make sure that the input side of the ring processing (transferring packets from NICs) was not able to overtake the reading by the user process. Then, with successive calls to uiomove(), data is copied from the ring out to the user process. That is if the number of buffers in the ring is static. Or did you try doing this with Windows and found other problems? Like the copy to user space is so expensive that it is quicker to copy into a new kernel buffer, unlock the ring, and then copy to userspace? btw, do you have any comments on how stable WinPCap2p3 is/was? We had some systems running this but found Windows 2000 to be extremely unreliable (systems would lockup and require a hard reset at least once every 2 weeks.) Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] advice for heavy traffic capturing
Hi Fulvio, > Yes, it is harder. > For instance, let's imagine you collected statistics based on the IP source > address (e.g. byte count). You need something like a 10MB buffer (uhmmm, > probably much more) to store data. > Now, let's imagine you want to plot a snapshot of your stats every minute. > If you have a ring buffer, you should lock the entire buffer in order to > copy its content and make it available to the application. You have to make > sure that no other threads are going to update data in the meanwhile, > otherwise your statistics are broken (they refers to different time > intervals). > With a swappable buffer, you can avoid this problem by simply swapping the > buffers. Do both buffers need to be the implemented same ? Why not keep the ring buffer for packet capture and use buffer swapping for statistics ? I imagine this is what you've done Or even have them as separate (but linked) devices ? Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] localhost on Solaris
> Hi ! > > I understand there is no solution to sniffing > for local traffic on Solaris since the > kernel always used the loopback interface for > that. > > I suggest to write a STREAMS module to sit on top > of the loopback driver. > > Does anyone know if the loopback driver is a > STREAMS driver ? (Say, Solaris 8 and on?) > > Any comments or advice on this ? There is no loopback driver: $ modinfo | grep -i loop | wc 0 0 0 $ echo /dev/lo* /dev/lockstat /dev/log /dev/logindmux That is the root of the problem. The loopback interface and loopback traffic handling in Solaris, is hard coded inside of IP. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] Add ioctl to disable bpf timestamping
In some email I received from Guy Harris, sie wrote: > On Sep 8, 2004, at 2:26 AM, Bruce M Simpson wrote: > > > Here's a patch against 5.3 to add a per-instance switch which allows > > the user to specify if captured packets should be timestamped (and, > > if so, whether microtime() or the faster but less accurate > > getmicrotime() call should be used). > > This is probably a pointless optimization, as you probably relatively > rarely have multiple BPF devices bound to the same interface receiving > the bulk of the packets (as opposed to some daemon with a filter that > passes only the packets it's interested in), but would there be any > advantage to having "bpf_tap()" and "bpf_mtap()" fetch the time stamp > and pass that to "catchpacket()", so that in the case where there *is* > more than one tap, the time stamp is only fetched once? That makes sense and allows you to correllate packet time stamps from a daemon collecting packets with those you see in tcpdump output when you run that in parallel to make sure things are moving. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
In some email I received from Guy Harris, sie wrote: > > On Dec 9, 2004, at 12:48 PM, Dumas Hwang wrote: > > > I would like to get nanosecond resolution on Solaris in > > libpcap. > > BTW, where are you getting the nanosecond-resolution time stamps in > Solaris? gethrtime - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
In some email I received from rick jones, sie wrote: > >> BTW, where are you getting the nanosecond-resolution time stamps in > >> Solaris? > > > > gethrtime > > there is such a thing in some of the other OSes as well - netperf will > use it for -DHISTOGRAM because it typically is lower overhead. > > however, my recollection of the manpages is that it is only good for > relative time, not clock time. perhaps that is "ok" here but it will > be a semantic (right term?) difference from gettimeofday(). 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 drifting by way of adjtime(2) or settimeofday(3C). The hi- res timer is ideally suited to performance measurement tasks, where cheap, accurate interval timing is required. So something like "getimeofday(&foo, NULL); foohr = gethrtime()" would approximately equate foohr with foo, such that you could use the change in gethrtime() values returned to calculate the current time with more accuracy than just gettimeofday() ? Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
In some email I received from Guy Harris, sie wrote: > > On Dec 9, 2004, at 2:08 PM, Darren Reed wrote: > > > In some email I received from Guy Harris, sie wrote: > >> BTW, where are you getting the nanosecond-resolution time stamps in > >> Solaris? > > > > gethrtime > > That says what the high-resolution time counter's value is now, not > what the value was when bufmod saw the packet (which raises another > issue, namely that the time stamps you get out of libpcap might have > nanosecond *precision* but they might not have nanosecond *accuracy*) - > or are the packets in question not being captured by libpcap, so that > you can use "gethrtime()" to time stamp packets reasonably close to the > time t which they arrived? I think that whether it is bufmod or a program that generates a time stamp, it is still a software timestamp and sometime after the actual packet "arrived". So what am I trying to say here? Unless you have hardware timestamps in captured packets, one software timestamp is as good as the next in a well written application. Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Extra DLT types required for opensolaris DLPI DL types...
Hi,
I'm trying to work out how to correctly map the DLPI data link
types that are used to each of the relevant DLT's that are
supplied in bpf.h. Some of them are easy, some are repeats,
some not so...
I'm not completely sure if I should assume DLT_NULL for the
likes of IPv4/6 tunnels or pretend that the outer IP header
is the "link header" and thus in need of a DLT_IPV4/DLT_IPV6.
So I'd like to request that a DLT types be given for each
unique type that's included below and currently mapped to "0".
I believe that the list of names I need a value for is:
DLT_TPB
DLT_TPR
DLT_METRO
DLT_CHAR
DLT_CTCA
DLT_FC
DLT_X25
DLT_ISDN
DLT_100VGTP
DLT_IB
DLT_MPFRAME
DLT_ASYNC
DLPT_IPX25
DLT_IPV4
DLT_IPV6
Darren
{ DL_CSMACD,DLT_EN10MB }, /* IEEE 802.3 CSMA/CD network */
{ DL_TPB, 0 },/* IEEE 802.4 Token Passing Bus */
{ DL_TPR, 0 },/* IEEE 802.5 Token Passing Ring */
{ DL_METRO, 0 },/* IEEE 802.6 Metro Net */
{ DL_ETHER, DLT_EN10MB }, /* Ethernet Bus */
{ DL_HDLC, DLT_HDLC }, /* ISO HDLC protocol support */
{ DL_CHAR, 0 },/* Character Synchronous protocol */
{ DL_CTCA, 0 },/* IBM Channel-to-Channel Adapter */
{ DL_FDDI, DLT_FDDI }, /* Fiber Distributed data
interface */
{ DL_FC,0 },/* Fibre Channel interface */
{ DL_ATM, DLT_SUNATM }, /* ATM */
{ DL_IPATM, DLT_ATM_CLIP }, /* ATM Classical IP interface */
{ DL_X25, 0 },/* X.25 LAPB interface */
{ DL_ISDN, 0 },/* ISDN interface */
{ DL_HIPPI, DLT_HIPPI },/* HIPPI interface */
{ DL_100VG, DLT_EN10MB }, /* 100 Based VG Ethernet */
{ DL_100VGTP, 0 },/* 100 Based VG Token Ring */
{ DL_ETH_CSMA, DLT_EN10MB }, /* ISO 8802/3 and Ethernet */
{ DL_100BT, DLT_EN10MB }, /* 100 Base T */
{ DL_IB,0 },/* Infiniband */
{ DL_FRAME, DLT_FRELAY }, /* Frame Relay LAPF */
{ DL_MPFRAME, 0 },/* Multi-protocol over Frame
Relay */
{ DL_ASYNC, 0 },/* Character Asynchronous
Protocol */
{ DL_IPX25, 0 },/* X.25 Classical IP interface */
{ DL_LOOP, DLT_NULL }, /* software loopback */
{ DL_OTHER, 0 },/* Any other medium not listed
above */
{ DL_IPV4, 0 },/* IPv4 Tunnel Link */
{ DL_IPV6, 0 },/* IPv6 Tunnel Link */
{ SUNW_DL_VNI, 0 },/* Virtual network interface */
{ DL_WIFI, DLT_IEEE802_11 }, /* IEEE 802.11 */
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Extra DLT types required for opensolaris DLPI DL
On 26/03/09 05:23 PM, Guy Harris wrote:
On Mar 26, 2009, at 11:58 AM, Darren Reed wrote:
I'm trying to work out how to correctly map the DLPI data link
types that are used to each of the relevant DLT's that are
supplied in bpf.h. Some of them are easy, some are repeats,
some not so...
...and some DL_ values appear to have been reserved for future use
"just in case" but don't appear to refer to a network type particular
enough to have a link-layer header, so, as a DLT_ value refers to a
*particular* link-layer header type, they can't, by themselves, be
mapped to a DLT_ value.
I'm not completely sure if I should assume DLT_NULL for the
likes of IPv4/6 tunnels or pretend that the outer IP header
is the "link header" and thus in need of a DLT_IPV4/DLT_IPV6.
So I'd like to request that a DLT types be given for each
unique type that's included below and currently mapped to "0".
...and that doesn't already have an appropriate DLT_ value.
However, as indicated, DLT_ values refer to a particular link-layer
header type - it is an Extremely Bad Thing to require some weird
heuristic to determine how to dissect a packet even if you know the
DLT_ value, and I don't want to increase the number of Extremely Bad
Things that tcpdump/Wireshark/etc. have to do for that - so, for some
of those DL_ types, it might not be possible to add a new DLT_ value
for them, and, for some others, an indication of the precise
link-layer header format for them would be necessary.
Note also that not all of the DL_ values correspond to packets we're
likely to see these days; DLPI was invented back in the late 80's,
before some networking types died out.
{ DL_TPB, 0 },/* IEEE 802.4 Token Passing Bus */
I suppose we could add a DLT_IEEE802_4 value, although, in practice, I
don't know whether there are any 802.4 token buses around.
I suspect that this is going to be the case for a lot of these esoteric
types. In part, my sending this email is to find out what other people
know of these protocol(s) and if they are still used or not.
{ DL_METRO, 0 },/* IEEE 802.6 Metro Net */
I suppose we could add a DLT_IEEE802_6 value, but I don't know whether
anybody offers SMDS service any more.
I wonder the same about many of the link types I included...
{ DL_HDLC, DLT_HDLC }, /* ISO HDLC protocol support */
"HDLC" is a catch-all term for various types of networking, usually
meaning that
1) the packets are framed using HDLC framing (with bit-stuffing
and byte-stuffing)
and
2) the packets have an HDLC-style header with an addresse followed
by an HDLC control field.
I don't see a DLT_HDLC in the top-of-tree pcap/bpf.h.
Hmmm, I took that from NetBSD's
It would seem like someone forgot to feed that back :-(
So someone has been bad, their definition for it is:
#define DLT_HDLC16/* HDLC framing */
{ DL_HIPPI, DLT_HIPPI },/* HIPPI interface */
I don't see any DLT_HIPPI in the top-of-tree pcap/bpf.h.
From NetBSD:
#define DLT_HIPPI15/* HIPPI */
{ DL_IB,0 },/* Infiniband */
To what particular sort of packets does that refer?
The driver that introduces IP over IB uses DL_IB here:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/mac/plugins/mac_ib.c
And the header definition(s) for the packets are here:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/ib/clients/ibd/ibd.h
{ DL_IPV4, 0 },/* IPv4 Tunnel Link */
What does the link-layer header on those packets look like? Are they
just raw IPv4 packets with no link-layer header? If so, that's DLT_RAW.
{ DL_IPV6, 0 },/* IPv6 Tunnel Link */
What does the link-layer header on those packets look like? Are they
just raw IPv4 packets with no link-layer header? If so, that's
DLT_RAW. (The IP version number can be used to distinguish between
IPv4 and IPv6.)
These are IPv4/6 in IPv4/6.
And it sounds like DLT_RAW is what to use here - ok.
{ DL_WIFI, DLT_IEEE802_11 }, /* IEEE 802.11 */
Presumably the packet begins with an 802.11 header, with no radio
information. If it has radio information - preferably using the
radiotap header! - it'd be the DLT_ value appropriate for the radio
information.
So according to:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/mac/plugins/mac_wifi.c
it's the 802.11 header, without radio information - or at least there is
nothing there that looks remotely like it is dealing with radio bits.
Darren
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Extra DLT types required for opensolaris DLPI DL
On 27/03/09 03:01 AM, Guy Harris wrote:
On Mar 26, 2009, at 6:47 PM, Darren Reed wrote:
On 26/03/09 05:23 PM, Guy Harris wrote:
On Mar 26, 2009, at 11:58 AM, Darren Reed wrote:
{ DL_HDLC, DLT_HDLC }, /* ISO HDLC protocol support */
"HDLC" is a catch-all term for various types of networking, usually
meaning that
1) the packets are framed using HDLC framing (with bit-stuffing
and byte-stuffing)
and
2) the packets have an HDLC-style header with an addresse
followed by an HDLC control field.
I don't see a DLT_HDLC in the top-of-tree pcap/bpf.h.
Hmmm, I took that from NetBSD's
It would seem like someone forgot to feed that back :-(
So someone has been bad, their definition for it is:
#define DLT_HDLC16/* HDLC framing */
From a quick look at the only driver I found under sys/dev/ic that
uses it, DLT_HDLC appears to mean "Cisco HDLC", which uses HDLC
framing but not an HDLC header; instead, it has a 1-byte address field
(0x8f for multicast and 0x0f for unicast), followed by a reserved by
and a 2-byte Ethernet type (no HDLC control field).
Whether that's what DL_HDLC is used for in any system whose link-layer
interfaces are based on DLPI is another matter. This page:
https://www.opensolaris.org/jive/thread.jspa?threadID=60345&tstart=105
appears to suggest that they might be using it for Cisco HDLC (the
0x8f), although this page:
http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.aixlink25/doc/x25usrgd/DL_INFO_ACK.htm
seems to suggest that IBM uses it for X.25 (LAPB being HDLC-derived,
with a real HDLC control field).
Oh, do I serve my masters present or masters future? Confusion!
Seriously, for my purposes, it is "Cisco HDLC".
For the purposes of my table, I'd like to map the mediums that have
passed (or are passing) from active use to "unsupported" and call it
DLT_UNSUP (0x). On one level this is strange, because it isn't a
DLT type, but it is a useful programming tool.
{ DL_HIPPI, DLT_HIPPI },/* HIPPI interface */
I don't see any DLT_HIPPI in the top-of-tree pcap/bpf.h.
From NetBSD:
#define DLT_HIPPI15/* HIPPI */
From a quick look at sys/net/if_hippi.h and sys/net/if_hippisubr.c,
the header appears to be:
...
If there are interfaces using DL_HIPPI, and they supply the same
link-layer header, a DLT_HIPPI would make sense. Unfortunately, 15 is
in the Badlands of DLT_ values, where various OSes have used the same
numerical value for different purposes, so we'd probably end up
assigning a new value in the range starting with 100 (which is the
range we're maintaining).
If you can give it a new number, I can see to it that the change gets
into NetBSD. I can't see a whole lot of people screaming if it does
change ;)
{ DL_IB,0 },/* Infiniband */
To what particular sort of packets does that refer?
The driver that introduces IP over IB uses DL_IB here:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/mac/plugins/mac_ib.c
And the header definition(s) for the packets are here:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/ib/clients/ibd/ibd.h
The Wireshark dissector for Infiniband appears to assume the packet
starts with a Local Route Header, followed by a Global Route Header,
followed by a Base Transport Header; if that's what the driver hands
that up, then you might want to experiment with a private
DLT_INFINIBAND value (pick one of the DLT_USERn values), have
wiretap/libpcap.c map that value to a WTAP_ENCAP_USERn value, and then
wire up that WTAP_ENCAP_USERn to the Infiniband dissector. If that
works, then we should assign a DLT_INFINIBAND value, otherwise we'll
need to find out what's different and assign that to
DLT_INFINIBAND_SOLARIS or something such as that.
Ok, that's going to take some experimentation and I'll have to get back
to you on that as I don't have any Infiniband machines handy.
Additionally, I'm considering creating a new datalink type for loopback
packets on OpenSolaris. The contents would be something like:
version (16 bits: 1)
protocol family (16 bits: AF_INET, AF_INET6)
capture point (32bits enum: local, in, out)
interface index (32bits)
group interface index (32bits)
source zone (32 or 64bits?)
destination zone (32 or 64bits?)
I'm guessing that this should be called DLT_LOOP_SOLARIS.
Darren
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Extra DLT types required for opensolaris DLPI DL
On 27/03/09 11:27 AM, Guy Harris wrote: On Mar 27, 2009, at 10:58 AM, Darren Reed wrote: Seriously, for my purposes, it is "Cisco HDLC". So it should be mapped to DLT_C_HDLC. For the purposes of my table, I'd like to map the mediums that have passed (or are passing) from active use to "unsupported" and call it DLT_UNSUP (0x). On one level this is strange, because it isn't a DLT type, but it is a useful programming tool. So what's the table being used for? libpcap has a switch statement (in the top of the tree, it's in pcap_process_mactype() in dlpisubs.c), as it needs to know more than just the DLT_ value for particular link-layer types (and it maps DL_TPR to DLT_IEEE802). The devices in Solaris all use the DLPI types from . I'm working on providing a native BPF for Solaris and I need to translate those DL_ types to DLT_ things. I'll have a look at the dlpisubs.c file... While I'm here, additionally I'm looking at making PF_PACKET work and using pcap-linux.c as a guide, it isn't clear what or where a relevant header file should be called (yay linux mess!) Any thoughts on what you see making the most sense there? If you're wondering "why both", imho, one is designed to program with and one is designed for packet capture. Additionally, I'm considering creating a new datalink type for loopback packets on OpenSolaris. The contents would be something like: version (16 bits: 1) protocol family (16 bits: AF_INET, AF_INET6) capture point (32bits enum: local, in, out) interface index (32bits) group interface index (32bits) source zone (32 or 64bits?) destination zone (32 or 64bits?) I'm guessing that this should be called DLT_LOOP_SOLARIS. That would probably be the right name. Shall I assign it (once you've decided how big the source and destination zones are, or whether there are two flavors, one with 32 bits and one with 64 bits)? Yes, thanks. It's 32bits. zoneid_t is an "id_t", which is an int on LP64 and long otherwise, according to my . Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Extra DLT types required for opensolaris DLPI DL
On 27/03/09 05:03 PM, Guy Harris wrote: On Mar 27, 2009, at 1:45 PM, Darren Reed wrote: On 27/03/09 11:27 AM, Guy Harris wrote: On Mar 27, 2009, at 10:58 AM, Darren Reed wrote: Seriously, for my purposes, it is "Cisco HDLC". So it should be mapped to DLT_C_HDLC. For the purposes of my table, I'd like to map the mediums that have passed (or are passing) from active use to "unsupported" and call it DLT_UNSUP (0x). On one level this is strange, because it isn't a DLT type, but it is a useful programming tool. So what's the table being used for? libpcap has a switch statement (in the top of the tree, it's in pcap_process_mactype() in dlpisubs.c), as it needs to know more than just the DLT_ value for particular link-layer types (and it maps DL_TPR to DLT_IEEE802). The devices in Solaris all use the DLPI types from . I'm working on providing a native BPF for Solaris and I need to translate those DL_ types to DLT_ things. "BPF" can refer to two different things - the low-level packet capture/transmit mechanism accessed by opening a BPF device and reading from, writing to, and doing ioctls on, and the filter language (and engines) that are used in systems with BPF, as well as in Linux, WinPcap, and some other places (I think FreeBSD has a BPF netgraph node). I presume you're referring to the former, as the latter - a bpfmod streams module as an alternative to pfmod - wouldn't require translating DL_ types to DLT_ types (the filter itself knows nothing about link-layer header types; the filter compiler in libpcap does, but libpcap can and does already map DL_ types to DLT_ types). (If so, you will have a single cloning /dev/bpf device, rather than the old "keep trying /dev/bpfN devices until you don't get EBUSY" hack, right?) Solaris doesn't support cloning for character devices (at present), so I'm forced to do /dev/bpfN. There will be no STREAMS involved in this, it'll plug in directly to the mac layer. The eventual goal is to support mmap and BPF JIT compiling. While I'm here, additionally I'm looking at making PF_PACKET work and using pcap-linux.c as a guide, it isn't clear what or where a relevant header file should be called (yay linux mess!) Any thoughts on what you see making the most sense there? The packet(7) man page: http://linux.die.net/man/7/packet says the header file for PF_PACKET sockets is I'll have to look at this man page... Yes, thanks. It's 32bits. zoneid_t is an "id_t", which is an int on LP64 and long otherwise, according to my . So that'd be version (16 bits: 1) protocol family (16 bits: AF_INET, AF_INET6) capture point (32bits enum: local, in, out) interface index (32bits) group interface index (32bits) source zone (32 bits) destination zone (32 bits) (and, obviously, Solaris AF_ values; everybody probably got their AF_INET from 4.2BSD, so they're all the same, but just about everybody seems to have their own unique value for AF_INET6). If you've settled on that, I'll assign DLT_LOOP_SOLARIS. It looks good to me. If we decide to change it or throw it out, I'll let you know. Cheers, Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Extra DLT types required for opensolaris DLPI DL
On 27/03/09 07:01 PM, Sebastien Roy wrote: Hi Darren, On Fri, 2009-03-27 at 10:58 -0700, Darren Reed wrote: Additionally, I'm considering creating a new datalink type for loopback packets on OpenSolaris. The contents would be something like: version (16 bits: 1) protocol family (16 bits: AF_INET, AF_INET6) capture point (32bits enum: local, in, out) interface index (32bits) group interface index (32bits) source zone (32 or 64bits?) destination zone (32 or 64bits?) I'm guessing that this should be called DLT_LOOP_SOLARIS. There is already a datalink type associated with loopback (/dev/lo0), DL_IPNET, and the header is described in the lo0(7D) man page. It's versioned, so it would be technically possible to evolve it to include more information. The only hitch is that DL_IPNET devices behave like DLT_RAW by default. The DL_IOC_IPNET_INFO ioctl enables the inclusion of the "ipnet" header. The thinking here was that with a tiny modification to libpcap, existing applications that understand DLT_RAW could read packets off of DL_IPNET devices. The downside is that we now can't really have libpcap turn on DL_IOC_IPNET_INFO if such applications assume that these devices are DLT_RAW. Perhaps it would be simpler if we got rid of DL_IOC_IPNET_INFO and had DL_IPNET devices always include the header. Since the Solaris-specific snoop application is the only thing that currently uses the ioctl, it's a change that could be manageable. This is something we'd need to discuss with the OpenSolaris networking community first, though. I'm not intending to change anything with respect to DLPI, so DL_IOC_IPNET_INFO is not of any concern to me. DL_IPNET doesn't exist outside of the Solaris source code base, so it seems to me to still be a private thing, which is fine. What I am considering is: - moving libpcap on Solaris to use /dev/bpf rather than libdlpi - extending the libpcap parser to grok keywords that related to things in the "loopback" header - publishing the extra datalink type via BPF so you can select them with tcpdump, like you do with 802.11 on BSD to get radio frames, not ethernet frames - with respect to all of the above, it may be beneficial to keep DL_IPNET as a private header type for libdlpi to use when opening /dev/ipnet things, the further away I can stay from snoop the better. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Extra DLT types required for opensolaris DLPI DL
On 27/03/09 07:42 PM, Guy Harris wrote: ... 2) returning some new DLT_ value. The only thing that would break would be applications that don't understand that new DLT_ value, but that happens with *any* new DLT_ value. Alternatively, libpcap could have DL_IPNET devices offer *two* new link-layer types, defaulting to DLT_RAW, but also offering the new DLT_ value, and if the application requests the new DLT_ value, libpcap would do the ioctl. That mechanism was originally put into libpcap to support a BSD mechanism for selecting different DLT_ values and link-layer headers for different BPF devices referring to the same underlying network interface, presumably so that 802.11 devices could supply 802.11 headers without breaking applications that didn't know about them (by defaulting to DLT_EN10MB). I've used tcpdump in this fashion on BSD :) So I was already quite aware of this and counting on it :) Perhaps it would be simpler if we got rid of DL_IOC_IPNET_INFO and had DL_IPNET devices always include the header. I'd prefer the simplest solution; getting rid of DL_IOC_IPNET_INFO is the simplest, with hiding it in libpcap and offering only the new DLT_ being the next-simplest. Offering a choice either means 1) requiring users to request the link-layer type they want, which is probably not going to be the default choice for loopback devices or 2) having the application know about those types of devices and know that the new DLT_ is to be preferred to DLT_RAW if it's available. Because of how it must be implemented, it would seem to me that the first DLT_ found will always be the hardware one, which is what you would see without the funny loopback variation(s), on all devices except lo0, so no surprises there. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Extra DLT types required for opensolaris DLPI DL
On 29/03/09 11:11 PM, Guy Harris wrote: On Mar 29, 2009, at 10:59 PM, Darren Reed wrote: What I am considering is: And what Sebastien is suggesting is, I think: using the DL_IPNET link-layer header for loopback devices, as documented in the loopback device man page, in your Solaris BPF, rather than inventing a new header; implementing that by having BPF turn on DL_IOC_IPNET_INFO for DL_IPNET devices. Which isn't how BPF selects which link layer type to use for packet capture. But it isn't really a concern: there's never been a way to intercept loopback packets for Solaris, so there is no history to play nice to. I suppose the only question really is if "lo0" should also have a DLT_NULL in addition to DLT_something_else, and have DLT_NULL be the default like it is elsewhere. (Sebastien, is that man page available to people *not* working at Sun? For that matter, are binary builds of the current state of Solaris 11/OpenSolaris available to people not working at Sun, to, for example, install on VMware virtual machines?) If you download the latest Solaris Express Community Edition, you will find it. The latest DVD image to install can be grabbed here: https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/viewproductdetail-start?productref=sol-express_b110-seg-x86-sp-...@cds-cds_smi If you want OpenSolaris, then you can get that here via bittorrent: http://dlc.sun.com/torrents/info/osol-0811.iso.torrent More info here: http://www.opensolaris.org/os/downloads/ Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Extra DLT types required for opensolaris DLPI DL
Sebastien Roy wrote: ... It might also be simplest for BPF to hook into the ipnet driver anyway, as the driver implements all kinds of heuristics to ensure that the observer doesn't see packets that shouldn't be seen (as related to zones). Some code sharing would be beneficial, and the header could be part of that sharing. In any case, I think this is getting into implementation, and probably putting the cart before the horse. That is the intention... +/- some tweaks to the implementation ;) - with respect to all of the above, it may be beneficial to keep DL_IPNET as a private header type for libdlpi to use when opening /dev/ipnet things, the further away I can stay from snoop the better. Let's keep snoop out of it, since I think it's unrelated to this discussion. It just happens to be something that groks DL_IPNET. DL_IPNET isn't a private thing, it's quite Public, in fact, the goal was to add support for it in libpcap and eventually have applications like tcpdump and Ethereal parse the resulting headers. Ok, well that didn't happen... Anyway, even though DL_IPNET is assigned in , that number space is quite separate from that what is used by BPF - that is what started this thread. There needs to be a mapping of DL_IPNET to something that ships with libpcap for use by BPF. At this point my suggestion is for that something to be DLT_LOOP_SOLARIS. As an example, DL_ETHER from needs to be mapped to DLT_EN10MB for . Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Question regarding libpcap filters and sflow,
What you might be able to do is construct a filter that only matches Ipv4 packets that have an ipid field that is 0 in base 4. i.e. this tcpdump 'ip[2:4] & 3 = 0' should get you approximately 25% of the packets. On 6/04/09 04:11 PM, Diego Valverde wrote: Hi, I am using linux on my device. I do not want to have to copy all the packets from kernel space to user space for performance reasons. I am not very familiar with the memory-mapped access capture mechanism. Would this avoid the performance hit of context switch memory spaces? Can you point me to some resources on that particular capture mechanism? Thanks -D On Mon, Apr 6, 2009 at 4:53 PM, Guy Harris wrote: On Apr 6, 2009, at 2:52 PM, Diego Valverde wrote: Is there a way to specify 1 out of every N packets sampling using an existing filter combination? No. The filtering mechanism was created in order to filter based on packet content, and that's all it supports checking. if not where should I look into the code in order to extend the filtering functionally for my particular needs? Nowhere - as indicated, the filtering mechanism checks only packet contents. I'm assuming the embedded device is running an operating system such as Linux, so that packets have to be copied from kernel space to user space (unless libpcap is using the memory-mapped access mechanism on Linux or FreeBSD) to be delivered to libpcap. If you don't care whether packets not being sampled are copied from kernel space to user space (or if you're running on a version of Linux or FreeBSD with a memory-mapped capture interface), you could just do the sampling in the code that reads from libpcap. If you do care, you'll have to implement the filtering in the kernel. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] libpcap changes required for BPF on Solaris
Guy, The URL below contains the necessary changes for BPF on Solaris to "just work". To summarise, Solaris needs a few extra includes and for BPF to be checked before DLPI. http://www.opensolaris.org/os/community/networking/files/libpcap.diff.gz Cheers, Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap changes required for BPF on Solaris
On 13/04/09 10:58 AM, Guy Harris wrote:
On Apr 10, 2009, at 8:23 PM, Darren Reed wrote:
The URL below contains the necessary changes for BPF on Solaris to
"just work". To summarise, Solaris needs a few extra includes
@ -37,6 +37,12 @@ static const char rcsid[] _U_ =
#include
#include
#include
+#ifdef HAVE_SYS_FCNTL_H
+#include
+#endif
+#ifdef HAVE_SYS_IOCCOM_H
+#include
+#endif
#ifdef HAVE_ZEROCOPY_BPF
#include
I presume fcntl.h is being included to define O_RDONLY and O_RDWR and
to declare open(). If so, is there a reason not to include ,
which I think is the "standard" path, rather than including ?
Using will work too.
Why is needed? If Solaris-with-BPF defines the ioctls
in , then should include -
speaking as its creator, back in the SunOS 4.0 days, I can say that
was never intended to be included directly, but was
intended to be included by other files that defined ioctls. (And,
yes, the fact that doesn't include on
various flavors of BSD is, indeed, a bug; I'll file bugs on whatever
OSes don't have it include . You should not have to
include before including .)
Ok, I'll make that change.
and for BPF to be checked before DLPI.
http://www.opensolaris.org/os/community/networking/files/libpcap.diff.gz
There are some other changes:
@@ -725,6 +730,7 @@ pcap_read_bpf(pcap_t *p, int cnt, pcap_handler
callback, u_char *user)
#ifdef PCAP_FDDIPAD
register int pad;
#endif
+struct bpf_hdr *bhp;
#ifdef HAVE_ZEROCOPY_BPF
int i;
#endif
@@ -827,7 +833,7 @@ pcap_read_bpf(pcap_t *p, int cnt, pcap_handler
callback, u_char *user)
/*
* Loop through each packet.
*/
-#define bhp ((struct bpf_hdr *)bp)
+#define bhpe ((struct bpf_hdr *)bp)
ep = bp + cc;
#ifdef PCAP_FDDIPAD
pad = p->fddipad;
@@ -856,6 +862,7 @@ pcap_read_bpf(pcap_t *p, int cnt, pcap_handler
callback, u_char *user)
}
}
+bhp = (struct bpf_hdr *)bp;
caplen = bhp->bh_caplen;
hdrlen = bhp->bh_hdrlen;
datap = bp + hdrlen;
What are those changes for? ("bhpe" is never used.)
This looks like testing code that wasn't exorcised.
Darren
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap changes required for BPF on Solaris
There's another change that I think should be made that I'd like to discuss and that's the change from using "test -r" to "test -a" or "test -c". With the device as rwx--, "test -r" will fail for doing "configure" as non-root. I don't consider that to be ideal. At least I like to build software as non-root and then run or install it as root. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] DLT type requested for OpenSolaris IPNET header
I'd like to request a DLT type for the "ipnet device" on OpenSolaris. A description of the packet header can be found here: http://arc.opensolaris.org/caselog/PSARC/2009/232/commitment.materials/bpf-psarc.txt and the relevant structure name is "dl_ipnetinfo". This structure will be prepended to IP packets that are received when the DLT is set to DLT_IPNET. I'd like to request that the assigned name is DLT_IPNET. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap changes required for BPF on Solaris
On 18/04/09 01:07 PM, Guy Harris wrote: On Apr 10, 2009, at 8:23 PM, Darren Reed wrote: The URL below contains the necessary changes for BPF on Solaris to "just work". To summarise, Solaris needs a few extra includes and for BPF to be checked before DLPI. http://www.opensolaris.org/os/community/networking/files/libpcap.diff.gz I've checked in some of those changes. I replaced the include in pcap-bpf.c with an include of , as that's what you're supposed to include for open(). The ones that didn't involve extra includes or configure script changes weren't checked in; were they necessary? To close the loop on this... The current libpcap, checked out with git, builds cleanly and correctly for BPF enabled Solaris. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT type requested for OpenSolaris IPNET header
On 21/07/09 02:40 PM, Guy Harris wrote:
On Jul 21, 2009, at 1:35 PM, Guy Harris wrote:
struct dl_ipnetinfo {
uint8_tdli_version;
uint8_tdli_family;
uint16_tdli_htype;
uint32_tdli_pktlen;
uint32_tdli_ifindex;
uint32_tdli_grifindex;
uint32_tdli_zsrc;
uint32_tdli_zdst;
};
What byte order are the 2-byte and 4-byte integers in? Host,
big-endian, or little-endian?
It's all big endian.
Darren
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT type requested for OpenSolaris IPNET header
On 21/07/09 01:35 PM, Guy Harris wrote:
On Jul 14, 2009, at 5:53 PM, Darren Reed wrote:
I'd like to request a DLT type for the "ipnet device" on OpenSolaris.
A description of the packet header can be found here:
http://arc.opensolaris.org/caselog/PSARC/2009/232/commitment.materials/bpf-psarc.txt
and the relevant structure name is "dl_ipnetinfo".
To quote the document:
struct dl_ipnetinfo {
uint8_tdli_version;
uint8_tdli_family;
uint16_tdli_htype;
uint32_tdli_pktlen;
uint32_tdli_ifindex;
uint32_tdli_grifindex;
uint32_tdli_zsrc;
uint32_tdli_zdst;
};
typedef struct dl_ipnetinfo dl_ipnetinfo_t;
dli_version - version number (2)
dli_family- protocol family (AF_INET, AF_INET6, etc)
Presumably those are Solaris values for the protocol family; could you
enumerate the possible numerical values for the protocol family? AF_
values can differ from platform to platform; everybody probably picked
up the same value for AF_INET from BSD, but AF_INET6 came after that
point, and it has different values on different platforms.
Indeed.
On Solaris, AF_INET is 2 and AF_INET6 is 26.
dli_htype - hook type (in, out, local)
Presumably there are specific values for those (0, 1, and 2, or whatever).
Yes, 0 for inbound, 1 for outbound, 2 for local.
dli_pktlen- length of the packet excluding this header
dli_ifindex - interface index number
dli_grifindex - group interface index number (for IPMP interfaces)
Are those standard interface index numbers? (Many OSes seem to have a
standard notion of interface numbers - does that come from SNMP?)
They are... but Solaris has many different indexes, at present...
There's an interface index number at the link level and a different
one at the IP layer. Although they may be the same, there is no
guarantee that it will be this way.
And yes, I believe that SNMP may be to blame :)
dli_zsrc - zone identifier for the source of the packet
dli_zdst - zone identifier for the destination of the packet
Presumably those identifiers are just numbers.
Correct.
However, there are two that do have meaning:
0 - global zone
-1/0x - no zone (e.g. packet receive from the wire)
In the changes I've made in libpcap locally (I can send diffs or post
them on a web page if you would like), I've :
- used "dli_htype" as the means for generating a filter for inbound
and outbound packets (gencode.c);
- in pcap-bpf.c, made changes to allow DLT_IPNET to be returned
as a DLT type, in addition to any other type present.
From the global zone:
# tcpdump -L
Data link types (use option -y to set):
DOCSIS (DOCSIS) (printing not supported)
IPNET (Solaris IPNET)
EN10MB (Ethernet)
From a zone that shares its IP instance with the global zone:
# zlogin shared tcpdump -L
Data link types (use option -y to set):
IPNET (Solaris IPNET)
From a zone that has an exclusive IP instance:
# zlogin exclusive tcpdump -L
Data link types (use option -y to set):
DOCSIS (DOCSIS) (printing not supported)
IPNET (Solaris IPNET)
EN10MB (Ethernet)
Also, on Solaris, /dev/bpf is a symbolic link to a character device
file over in /devices somewhere. A small change to configure.in to
do "test -r /dev/bpf -o -h /dev/bpf" was required to get libpcap to
correctly auto-configure cloning BPF device support.
Darren
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Dealing with pcap-linux.c
As well as porting BPF to Solaris, I've been working on developing an implementation of PF_PACKET. I went to try this out with libpcap and it failed badly. pcap-linux.c is a combination of PF_PACKET bits plus all of the code required to deal with Linux's ARP implementation. Is there any interest in seeing pcap-linux.c split up into pcap-packet.c and arp-linux.c? Or some other division? Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Dealing with pcap-linux.c
On 27/07/09 12:48 PM, Guy Harris wrote: On Jul 27, 2009, at 11:40 AM, Guy Harris wrote: The code to use PF_PACKET and PF_INET/SOCK_PACKET sockets *does* have to translate the ARPHRD_ values Linux returns to DLT_ values; that's not a lot of code, and is only minimally involved with Linux's ARP implementation - many of the ARPHRD_ values are not, in fact, ARP hardware types, as not all network types supported by Linux *have* ARP hardware types. ...and if your intent with the PF_PACKET implementation is to provide source compatibility for applications written for Linux's PF_PACKET, including PF_PACKET/SOCK_RAW, you'll have to implement the SIOCGIFHWADDR ioctl, complete with the sa_family field in the address being a Linux ARPHRD_ type (you could choose your own values for ones that don't correspond to ARP hardware types, but you probably wouldn't want to in most cases), so libpcap could and probably should use the same code as it does on Linux for dealing with them. Hmm! Nothing like a new name space to use because we don't have enough already that cover the same thing. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT type requested for OpenSolaris IPNET header
On 27/07/09 11:47 AM, Guy Harris wrote: On Jul 26, 2009, at 6:48 PM, Darren Reed wrote: On 21/07/09 01:35 PM, Guy Harris wrote: dli_htype - hook type (in, out, local) Presumably there are specific values for those (0, 1, and 2, or whatever). Yes, 0 for inbound, 1 for outbound, 2 for local. So "inbound" means that the packet arrived from another machine on the network, Correct. "outbound" means the packet was sent to another machine on the network, and Correct. "local" means the packet came from another zone? (Into which category do packets sent to, for example, 127.0.0.1 on the same zone fall?) "local" is machine local. Between zones, using shared IP instances, or loopback traffic. Both types of "traffic" share the same datapath. "local" packets are seen after the "inbound" filter is applied to traffic being "received" by loopback/zone. So whereas it was not possible to sniff the loopback traffic on Solaris before, it now will be. I suppose now that I think about it, there are two "input" types - input and "local". Is that likely to be a problem for directional filtering? I would have to think more about what instructions that should generate. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT type requested for OpenSolaris IPNET header
On 27/07/09 12:03 PM, Guy Harris wrote: On Jul 14, 2009, at 5:53 PM, Darren Reed wrote: I'd like to request that the assigned name is DLT_IPNET. I've assigned 226 to DLT_IPNET. Thanks, Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] website offline?
I'm seeing this Not Found The requested URL / was not found on this server. Apache/2.2.9 (Debian) Server at www.tcpdump.org Port 80 - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] BPF now integrated into SunOS 5
After around 17 years of being out in the cold, BPF is now integrated into the SunOS kernel. At long last it is no longer necessary to use binary patches on a SunOS kernel or do the filtering in userland. BPF can be found in Solaris Express Community Edition build 125 onwards and in upcoming releases of OpenSolaris. It will take a little bit longer to update the version of libpcap that Sun ships, as part of SFW, to start using BPF. From my testing, the libpcap that is distributed via tcpdump.org will automatically discover and use the BPF module. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE build >= 125
To compile libpcap on OpenSolaris (or Solaris Express Community Edition)
build 125 and later to use the native BPF with both IPNET and traditional
MAC (ethernet, etc) packet sniffing, the attached patches are required.
The attached patches represent what's in our internal build tree for
libpcap.
Changes are also required for tcpdump, but I'll send those in a separate
email.
Darren
--- Makefile.in.distMon Oct 27 18:26:13 2008
+++ Makefile.in Wed Oct 21 21:36:27 2009
@@ -44,6 +44,7 @@
# You shouldn't need to edit anything below.
#
+LD = /usr/bin/ld
CC = @CC@
CCOPT = @V_CCOPT@
INCLS = -I. @V_INCLS@
@@ -326,7 +327,7 @@
#
libpcap.so: $(OBJ)
@rm -f $@
- $(CC) -shared -Wl,-soname,$...@.1 -o $...@.`cat $(srcdir)/VERSION`
$(OBJ) $(DAGLIBS)
+ $(LD) -shared -Wl,-soname,$...@.1 -o $...@.`cat $(srcdir)/VERSION`
$(OBJ) $(DAGLIBS)
#
# The following rule succeeds, but the result is untested.
--- pcap/bpf.h Fri Oct 10 19:42:44 2008
+++ pcap/bpf.h.new Tue Sep 15 21:06:40 2009
@@ -821,8 +821,17 @@
*/
#define DLT_IEEE802_15_4_NONASK_PHY215
+#defineDLT_IPNET 226 /* Assigned by tcpdump.org */
+#defineDLT_IPOIB 162 /* Private until we know what
it is */
/*
+ * IPNET
+ */
+#defineIPNET_OUTBOUND 1
+#defineIPNET_INBOUND 2
+
+
+/*
* DLT and savefile link type values are split into a class and
* a member of that class. A class value of 0 indicates a regular
* DLT_/LINKTYPE_ value.
--- configure.in.dist Tue Sep 25 19:09:46 2007
+++ configure.inFri Jul 17 13:08:17 2009
@@ -187,7 +187,7 @@
AC_MSG_CHECKING(packet capture type)
if test ! -z "$with_pcap" ; then
V_PCAP="$withval"
-elif test -r /dev/bpf ; then
+elif test -r /dev/bpf -o -h /dev/bpf ; then
#
# Cloning BPF device.
#
*** gencode.c.dist Fri Oct 10 19:42:44 2008
--- gencode.c Tue Sep 15 20:59:00 2009
***
*** 200,205
--- 200,206
static inline struct block *gen_true(void);
static inline struct block *gen_false(void);
static struct block *gen_ether_linktype(int);
+ static struct block *gen_ipnet_linktype(int);
static struct block *gen_linux_sll_linktype(int);
static struct slist *gen_load_prism_llprefixlen(void);
static struct slist *gen_load_avs_llprefixlen(void);
***
*** 1497,1502
--- 1498,1510
off_nl = -1;
off_nl_nosnap = -1;
return;
+
+ case DLT_IPNET:
+ off_linktype = 1;
+ off_macpl = 24; /* ipnet header length */
+ off_nl = 0;
+ off_nl_nosnap = -1;
+ return;
}
bpf_error("unknown data link type %d", linktype);
/* NOTREACHED */
***
*** 1931,1936
--- 1939,1971
}
/*
+ * "proto" is an Ethernet type value and for IPNET, if it is not IPv4
+ * or IPv6 then we have an error.
+ */
+ static struct block *
+ gen_ipnet_linktype(proto)
+ register int proto;
+ {
+ struct block *b0, *b1;
+
+ switch (proto) {
+ case ETHERTYPE_IP:
+ return gen_cmp(OR_LINK, off_linktype, BPF_B,
+ (bpf_int32)AF_INET);
+ /* NOTREACHED */
+
+ case ETHERTYPE_IPV6:
+ return gen_cmp(OR_LINK, off_linktype, BPF_B,
+ (bpf_int32)AF_INET6);
+ /* NOTREACHED */
+ default :
+ break;
+ }
+
+ return gen_false();
+ }
+
+ /*
* Generate code to match a particular packet type.
*
* "proto" is an Ethernet type value, if > ETHERMTU, or an LLC SAP
***
*** 3327,3332
--- 3362,3370
*/
return gen_mcmp(OR_LINK, 0, BPF_W, 0x4d474300, 0xff00); /*
compare the magic number */
+ case DLT_IPNET:
+ return gen_ipnet_linktype(proto);
+
case DLT_LINUX_IRDA:
bpf_error("IrDA link-layer type filtering not implemented");
***
*** 7250,7255
--- 7288,7305
dir);
break;
+ #ifdef DL_IPNET
+ case DLT_IPNET:
+ if (dir) {
+ /* match outgoing packets */
+ b0 = gen_cmp(OR_LINK, 2, BPF_H, IPNET_OUTBOUND);
+ } else {
+ /* match incoming packets */
+ b0 = gen_cmp(OR_LINK, 2, BPF_H, IPNET_INBOUND);
+ }
+ break;
+ #endif
+
case DLT_LINUX_SLL:
if (dir) {
/*
--- pcap.c.dist Fri Oct 10 19:42:44 2008
+++ pcap.c Tue Sep 15 21:09:24 2009
@@ -623,6 +623,7 @@
DLT_CHOICE(DLT_BLUETOOTH_HCI_H4_WITH_PHDR, "Bluetooth HCI UART
transport layer plus pseudo-header"),
DLT_CHOICE(DLT_AX25_KISS, "AX.25 with KISS header"),
DLT_CHOICE(DLT_IEEE802_15_4_NONASK_PHY, "IEEE 802.15.4 wit
[tcpdump-workers] tcpdump: patches required for OpenSolaris/SXCE build >= 125
The patches attached to this email are required to get a fully working
tcpdump
on OpenSolaris, or Solaris Express Community Edition, build 125 and later.
The attached patch introduces support for printing out the IPNET headers
used
for packet capture inside of zones that share their networking with the
global
zone and for packets "transmitted" between zones.
tcpdump 4.0.0 will ship with builds 129 and later of OpenSolaris/SXCE and
when run as root with the '-L' option, should behave as below to
indicate that
the system is fully functional:
# tcpdump -L
Data link types (use option -y to set):
DOCSIS (DOCSIS) (printing not supported)
IPNET (Solaris IPNET)
EN10MB (Ethernet)
Cheers,
Darren
--- Makefile.in.distSun Aug 31 19:44:11 2008
+++ Makefile.in Wed Sep 16 10:37:48 2009
@@ -77,7 +77,7 @@
print-eap.c print-eigrp.c\
print-esp.c print-ether.c print-fddi.c print-fr.c \
print-gre.c print-hsrp.c print-icmp.c print-igmp.c \
- print-igrp.c print-ip.c print-ipcomp.c print-ipfc.c \
+ print-igrp.c print-ip.c print-ipcomp.c print-ipfc.c print-ipnet.c \
print-ipx.c print-isoclns.c print-juniper.c print-krb.c \
print-l2tp.c print-lane.c print-ldp.c print-lldp.c print-llc.c \
print-lmp.c print-lspping.c print-lwapp.c \
--- interface.h.origSun Aug 31 19:44:14 2008
+++ interface.h Fri Jul 31 18:37:02 2009
@@ -332,7 +332,11 @@
extern void sip_print(const u_char *, u_int);
extern void syslog_print(const u_char *, u_int);
extern u_int bt_if_print(const struct pcap_pkthdr *, const u_char *);
+extern void ipnet_print(const u_char *, u_int, u_int);
+extern u_int ipnet_if_print(const struct pcap_pkthdr *, const u_char *);
+extern int ipnet_encap_print(u_short, const u_char *, u_int, u_int);
+
#ifdef INET6
extern void ip6_print(const u_char *, u_int);
extern void ip6_opt_print(const u_char *, int);
diff -Nu ipnet.h ipnet.h
--- ipnet.h 1969-12-31 16:00:00.0 -0800
+++ ipnet.h 2009-07-22 14:59:11.821073000 -0700
@@ -0,0 +1,13 @@
+typedef struct ipnet_hdr {
+ uint8_t iph_version;
+ uint8_t iph_family;
+ uint16_tiph_htype;
+ uint32_tiph_pktlen;
+ uint32_tiph_ifindex;
+ uint32_tiph_grifindex;
+ uint32_tiph_zsrc;
+ uint32_tiph_zdst;
+} ipnet_hdr_t;
+
+#defineIPH_AF_INET 2 /* Matches Solaris's AF_INET */
+#defineIPH_AF_INET626 /* Matches Solaris's AF_INET6 */
diff -Nu print-ipnet.c print-ipnet.c
--- print-ipnet.c 1969-12-31 16:00:00.0 -0800
+++ print-ipnet.c 2009-07-22 14:59:13.613693000 -0700
@@ -0,0 +1,132 @@
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include
+
+#include
+#include
+
+#include "interface.h"
+#include "addrtoname.h"
+#include "ipnet.h"
+
+#ifdef DLT_IPNET
+
+int ipnet_encap_print(u_short, const u_char *, u_int, u_int);
+
+const struct tok ipnet_values[] = {
+ { IPH_AF_INET, "IPv4" },
+ { IPH_AF_INET6, "IPv6" },
+ { 0,NULL }
+};
+
+static inline void
+ipnet_hdr_print(register const u_char *bp, u_int length)
+{
+ const ipnet_hdr_t *hdr;
+ hdr = (const ipnet_hdr_t *)bp;
+
+ (void)printf("%d > %d", hdr->iph_zsrc, hdr->iph_zdst);
+
+ if (!qflag) {
+ (void)printf(", family %s (%d)",
+tok2str(ipnet_values, "Unknown",
+hdr->iph_family),
+ hdr->iph_family);
+} else {
+ (void)printf(", %s",
+tok2str(ipnet_values,
+"Unknown Ethertype (0x%04x)",
+hdr->iph_family));
+}
+
+ (void)printf(", length %u: ", length);
+}
+
+void
+ipnet_print(const u_char *p, u_int length, u_int caplen)
+{
+ ipnet_hdr_t *hdr;
+
+ if (caplen < sizeof(ipnet_hdr_t)) {
+ printf("[|ipnet]");
+ return;
+ }
+
+ if (eflag)
+ ipnet_hdr_print(p, length);
+
+ length -= sizeof(ipnet_hdr_t);
+ caplen -= sizeof(ipnet_hdr_t);
+ hdr = (ipnet_hdr_t *)p;
+ p += sizeof(ipnet_hdr_t);
+
+ if (ipnet_encap_print(hdr->iph_family, p, length, caplen) == 0) {
+ if (!eflag)
+ ipnet_hdr_print((u_char *)hdr,
+ length + sizeof(ipnet_hdr_t));
+
+ if (!suppress_default_print)
+ default_print(p, caplen);
+ }
+}
+
+/*
+ * This is the top level routine of the printer. 'p' points
+ * to the ether header of the packet, 'h->ts' is the timestamp,
+ * 'h->len' is the length of the packet off the wire, and 'h->caplen'
+ * is the number of bytes actually captured.
+ */
+u_int
+ipnet_if_print(const struct pcap_pkthdr *h, const u_char *p)
+{
+ ipnet_print(p, h->len, h->cap
Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE
On 11/24/09 18:41, Michael Richardson wrote: I applied the patches. The Makefile.in patch has changed, I think the command is now derived by configure. Also the DLT_CHOICE macro was already there, I think maybe Guy did that, but the rest was not. Pushed into libpcap, passed tcpdump make check. Please run that on Solaris and confirm. The configure for libpcap needs to be regenerated with autoconf. Otherwise, it works fine. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump: patches required for OpenSolaris/SXCE
On 11/24/09 18:31, Michael Richardson wrote:
Darren, thanks!
Please pull from the git tree, and run "./configure; make check"
I would appreciate it if you have any pcap files of formats:
DOCSIS (DOCSIS) (printing not supported)
This seems to be an inherent part of libpcap?
BPF on Solaris doesn't report that, pcap adds it...
See pcap-bpf.c:get_dlt_list()
IPNET (Solaris IPNET)
(I realize that the DOCSIS won't print. But, I care that it does not
crash)
Ideally, you'll place the files into tests/ and add a new test case.
I updated print-ipnet.c to use netdissect_options as well.
I've attached two files:
e1000g0 is an IPNET capture file from e1000g0 of some ICMP traffic (i.e.
ping)
tcpdmp.patches are the changes I needed to make to stop tcpdump core
dumping when reading that file.
Cheers,
Darren
diff --git a/netdissect.h b/netdissect.h
index ecd0824..aa02793 100644
--- a/netdissect.h
+++ b/netdissect.h
@@ -437,9 +437,9 @@ extern void lwres_print(netdissect_options *,const u_char
*, u_int);
extern void pptp_print(netdissect_options *,const u_char *, u_int);
#endif
-extern void ipnet_print(netdissect_options *,const u_char *, u_int, u_int);
-extern u_int ipnet_if_print(netdissect_options *,const struct pcap_pkthdr *,
const u_char *);
-extern int ipnet_encap_print(netdissect_options *,u_short, const u_char *,
u_int, u_int);
+extern void ipnet_print(const u_char *, u_int, u_int);
+extern u_int ipnet_if_print(const struct pcap_pkthdr *, const u_char *);
+extern int ipnet_encap_print(u_short, const u_char *, u_int, u_int);
#if 0
#ifdef INET6
diff --git a/print-ipnet.c b/print-ipnet.c
index d60d981..044f23b 100644
--- a/print-ipnet.c
+++ b/print-ipnet.c
@@ -7,13 +7,13 @@
#include
#include
-#include "netdissect.h"
+#include "interface.h"
#include "addrtoname.h"
#include "ipnet.h"
#ifdef DLT_IPNET
-int ipnet_encap_print(netdissect_options *,u_short, const u_char *, u_int,
u_int);
+int ipnet_encap_print(u_short, const u_char *, u_int, u_int);
const struct tok ipnet_values[] = {
{ IPH_AF_INET, "IPv4" },
@@ -22,53 +22,53 @@ const struct tok ipnet_values[] = {
};
static inline void
-ipnet_hdr_print(struct netdissect_options *ndo, const u_char *bp, u_int length)
+ipnet_hdr_print(const u_char *bp, u_int length)
{
const ipnet_hdr_t *hdr;
hdr = (const ipnet_hdr_t *)bp;
- ND_PRINT((ndo, "%d > %d", hdr->iph_zsrc, hdr->iph_zdst));
+ (void)printf("%d > %d", hdr->iph_zsrc, hdr->iph_zdst);
- if (!ndo->ndo_qflag) {
- ND_PRINT((ndo,", family %s (%d)",
+ if (!qflag) {
+ (void)printf(", family %s (%d)",
tok2str(ipnet_values, "Unknown",
hdr->iph_family),
- hdr->iph_family));
+ hdr->iph_family);
} else {
- ND_PRINT((ndo,", %s",
+ (void)printf(", %s",
tok2str(ipnet_values,
"Unknown Ethertype (0x%04x)",
- hdr->iph_family)));
+ hdr->iph_family));
}
- ND_PRINT((ndo, ", length %u: ", length));
+ (void)printf(", length %u: ", length);
}
void
-ipnet_print(struct netdissect_options *ndo, const u_char *p, u_int length,
u_int caplen)
+ipnet_print(const u_char *p, u_int length, u_int caplen)
{
ipnet_hdr_t *hdr;
if (caplen < sizeof(ipnet_hdr_t)) {
- ND_PRINT((ndo, "[|ipnet]"));
+ (void)printf("[|ipnet]");
return;
}
- if (ndo->ndo_eflag)
- ipnet_hdr_print(ndo, p, length);
+ if (eflag)
+ ipnet_hdr_print(p, length);
length -= sizeof(ipnet_hdr_t);
caplen -= sizeof(ipnet_hdr_t);
hdr = (ipnet_hdr_t *)p;
p += sizeof(ipnet_hdr_t);
- if (ipnet_encap_print(ndo, hdr->iph_family, p, length, caplen) == 0) {
- if (!ndo->ndo_eflag)
- ipnet_hdr_print(ndo, (u_char *)hdr,
+ if (ipnet_encap_print(hdr->iph_family, p, length, caplen) == 0) {
+ if (!eflag)
+ ipnet_hdr_print((u_char *)hdr,
length + sizeof(ipnet_hdr_t));
- if (!ndo->ndo_suppress_default_print)
- ndo->ndo_default_print(ndo, p, caplen);
+ if (!gndo->ndo_suppress_default_print)
+ gndo->ndo_default_print(gndo, p, caplen);
}
}
@@ -79,9 +79,9 @@ ipnet_print(struct netdissect_options *ndo, const u_char *p,
u_int length, u_int
* is the number of bytes actually captured.
*/
u_int
-ipnet_if_print(struct netdissect_options *ndo, const struct pcap_pkthdr *h,
const u_char *p)
+ipnet_if_print(const struct pcap_pkthdr *h, const u_char *p)
{
- ipnet_print(ndo, p, h->len, h->caplen);
+ ipnet_print(p, h->len
Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE
Guy Harris wrote:
On Nov 24, 2009, at 3:55 PM, Darren Reed wrote:
--- Makefile.in.distMon Oct 27 18:26:13 2008
+++ Makefile.inWed Oct 21 21:36:27 2009
@@ -44,6 +44,7 @@
# You shouldn't need to edit anything below.
#
+LD = /usr/bin/ld
CC = @CC@
CCOPT = @V_CCOPT@
INCLS = -I. @V_INCLS@
@@ -326,7 +327,7 @@
#
libpcap.so: $(OBJ)
@rm -f $@
-$(CC) -shared -Wl,-soname,$...@.1 -o $...@.`cat $(srcdir)/VERSION`
$(OBJ) $(DAGLIBS)
+$(LD) -shared -Wl,-soname,$...@.1 -o $...@.`cat $(srcdir)/VERSION`
$(OBJ) $(DAGLIBS)
This doesn't apply any more. Please look at the top-of-tree Git
version of libpcap, rather than 1.0.0; the command used to build a
shared library is set in the AC_LBL_C_INIT macro in aclocal.m4.
Hmmm, ok... I'll wait and see what the next release of libpcap has.
#
# The following rule succeeds, but the result is untested.
--- pcap/bpf.hFri Oct 10 19:42:44 2008
+++ pcap/bpf.h.newTue Sep 15 21:06:40 2009
@@ -821,8 +821,17 @@
*/
#define DLT_IEEE802_15_4_NONASK_PHY215
+#defineDLT_IPNET226/* Assigned by tcpdump.org */
This is already set in the top-of-tree Git pcap/bpf.h.
My diffs were against 1.0.0.
I'll look forward to a new release :)
+#defineDLT_IPOIB162/* Private until we know what it
is */
162 is DLT_USER15, so we shouldn't advertise it as being any
particular link-layer type - and DLT_IPOIB isn't used by any of the
post-patch code, so it doesn't need to be defined.
I'll remove both of those from the top-of-tree version.
I understand, that's fine.
Getting access to IB boxes has proven harder than I thought, but when
I do I should be able to provide details about what the header format is.
/*
+ * IPNET
+ */
+#defineIPNET_OUTBOUND1
+#defineIPNET_INBOUND2
Perhaps this belongs in a pcap/ipnet.h header, instead.
Seems sensible.
--- configure.in.distTue Sep 25 19:09:46 2007
+++ configure.inFri Jul 17 13:08:17 2009
@@ -187,7 +187,7 @@
AC_MSG_CHECKING(packet capture type)
if test ! -z "$with_pcap" ; then
V_PCAP="$withval"
-elif test -r /dev/bpf ; then
+elif test -r /dev/bpf -o -h /dev/bpf ; then
#
# Cloning BPF device.
#
The test(1) man page on OS X says of "-h":
-h file True if file exists and is a symbolic link. This
operator
is retained for compatibility with previous
versions of
this program. Do not rely on its existence; use -L
instead.
...
-L file True if file exists and is a symbolic link.
Is there a flag to test that tests for a symlink and that's guaranteed
to work on all UN*Xes - or, at least, all sufficiently modern UN*Xes?
Solaris supports both with the same comment as you have above for "-L".
Which is more correct? I've no idea.
If someone has access toe which ever X/Open or Unix specification is
the most recent, maybe consult with that?
***
*** 7250,7255
--- 7288,7305
dir);
break;
+ #ifdef DL_IPNET
+ case DLT_IPNET:
+ if (dir) {
+ /* match outgoing packets */
+ b0 = gen_cmp(OR_LINK, 2, BPF_H, IPNET_OUTBOUND);
+ } else {
+ /* match incoming packets */
+ b0 = gen_cmp(OR_LINK, 2, BPF_H, IPNET_INBOUND);
+ }
+ break;
+ #endif
+
Why the #ifdef protection? It's not as if the code won't compile if
DLT_IPNET isn't defined, and elsewhere the code just assumes DLT_IPNET
is defined (which it is, in the top-of-tree version).
Presumably this was dictacted by which other section of code I did
a copy-paste-modify from, so there would be no specific reason for
the #ifdef.
Darren
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE
Guy Harris wrote: On Nov 25, 2009, at 11:42 AM, Guy Harris wrote: Can I plug a Cisco cable modem head-end device into an IPNET device and have it put DOCSIS frames inside IPNET layer-1 framing, so that you get packets with *no* IPNET header? I suspect the answer is "no", in which case you should not set is_ethernet for DLT_IPNET. OK, that was a bit confusing - the check was only being done for devices that offered DLT_EN10MB as their primary DLT. The check should stay in - but only be done if DLT_IPNET is defined, otherwise it won't compile (pcap-bpf.c includes the native OS's net/bpf.h, not pcap's pcap/bpf.h, so it's not guaranteed to be defined. I've added an #ifdef for that (and a comment explaining why we're treating DLT_IPNET specially). DLT_IPNET can be the only device type reported (for local zones with no network interfaces assigned to them exclusively) or it can be a supplement to whichever physical medium is present (e.g. ethernet.) In normal operation, the physical layer will be ethernet and the link layer header is lost by the time it reaches ipnet for packet capture. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE
Doing some further testing of DLT lists, get_dlt_list() needs some further work. On an OpenSolaris host with ethernet and a tunnel created, they're visible here: # dladm show-link LINKCLASS MTUSTATEBRIDGE OVER igb0phys 1500 up -- -- e1000g0 phys 1500 up -- -- e1000g1 phys 1500 up -- -- igb1phys 1500 up -- -- vnic0 vnic 1500 up -- e1000g0 tun0iptun 65515 down -- -- # tcpdump -L -i e1000g0 Data link types (use option -y to set): DOCSIS (DOCSIS) (printing not supported) IPNET (Solaris IPNET) EN10MB (Ethernet) # tcpdump -L -i tun0 Data link types (use option -y to set): IPNET (Solaris IPNET) RAW (Raw IP) ... but .. # tcpdump -L Data link types (use option -y to set): IPNET (Solaris IPNET) RAW (Raw IP) # ifconfig tun0 unplumb # tcpdump -L Data link types (use option -y to set): DOCSIS (DOCSIS) (printing not supported) IPNET (Solaris IPNET) EN10MB (Ethernet) When there is no network interface specified with -i, what I expect from "tcpdump -L" is for tcpdump to list all of the DLTs that are available for selection with -y. I suspect that tcpdump is choosing "tun0" for the output of "tcpdump -L" rather than going through all of the network interfaces and building a comprehensive list. I think the easy way out for this would be to change the header message to be: Data link types (use option -y to set) for %s: and then use something like "pcap_get_linkname()", but there doesn't appear to be an equivalent of that? Or even a "pcap_get_dev()" and then use pcap_datalink_val_to_name. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE
Guy Harris wrote: On Nov 29, 2009, at 11:43 PM, Darren Reed wrote: ... When there is no network interface specified with -i, what I expect from "tcpdump -L" is for tcpdump to list all of the DLTs that are available for selection with -y. What you *should* expect is all the DLTs *that are available for the default interface*. "All of the DLTs that are available for selection with -y" is meaningless without specifying an interface - you can't select an DLT until you've first selected an interface, and if you don't select an interface, the first interface available in the "tcpdump -D" list is chosen by default. And that is what it does. In that case, I think the output of "tcudmp -L" is just confusing. When I run tcpdump without specifying an interface with -i, it does print out the network interface name: # tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 96 bytes ... I think the output of "tcpdump -L" could do with mentioning the link name. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE
Sebastien Roy wrote:
On Tue, 2009-12-01 at 00:47 -0800, Guy Harris wrote:
On Nov 30, 2009, at 5:30 AM, Darren Reed wrote:
# dladm show-link
LINKCLASS MTUSTATEBRIDGE OVER
igb0phys 1500 up -- --
e1000g0 phys 1500 up -- --
e1000g1 phys 1500 up -- --
igb1phys 1500 up -- --
vnic0 vnic 1500 up -- e1000g0
tun0iptun 65515 down -- --
unless dladm's notion of "down" is different from ifconfig's notion of
"down", the latter probably being what libpcap sees when it decides
whether to report devices as available or not.
Yes, it is different. On Solaris, ifconfig reports IP interface status
(where down and up are administrative settings of the IP interface), and
dladm reports the running state of the datalink, which is a dynamic
state that depends on external factors (akin to the RUNNING flag at the
IP layer).
I would argue that it's a bug on Solaris that libpcap depends on
IP-layer information to choose a capture interface (if that is in fact
what it does), as capturing at the link-layer is orthogonal to whether
IP is used at all over the datalink. On Solaris, datalinks can exist
without IP interfaces at all, so the interface selection logic should
not use IP-layer APIs, but link-layer APIs.
Use of libdladm is going to be required.
The WARNING there seems spurious, and the use of SIOCGIFADDR
questionable. Why should tcpdump care about the IP addresses assigned
to bge0 when observing at the link-layer? FWIW, it appears to select a
default interface just fine, so it would appear to not use the SIOCG*
socket ioctls for interface selection:
bash-3.2# ./tcpdump
tcpdump: WARNING: SIOCGIFADDR: bge0: No such device or address
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
...
Maybe Darren has fixed these uses of SIOCGIFADDR and fixed the WARNING,
but if not, I'd argue that it's a bug.
Not yet.
libpcap uses SIOCGLIFCONF to get the list of interfaces. As you've
mentioned,
for Splaris, this only returns interface names on which IP has been plumb'd.
Looking at tcpdump, pcap_lookupnet() should only be called from tcpdump.c
if fflag is true because the returned values of localnet and netmask are
ignored
by init_addrtoname if fflag is not true. Patch below.
This should prevent the warning message above from being displayed except
when someone does "tcpdump -f -i bge0" and bge0 has not been plumb'd.
In that case, I'd regard the failure of pcap_lookupnet() as a fatal
error, rather
than just a warning message to print out because the "-f" command line
feature
will not be able to work.
Darren
diff --git a/tcpdump.c b/tcpdump.c
index 25feb7a..82183a3 100644
--- a/tcpdump.c
+++ b/tcpdump.c
@@ -525,6 +525,8 @@ main(int argc, char **argv)
gndo->ndo_warning=ndo_warning;
gndo->ndo_snaplen = DEFAULT_SNAPLEN;
+ localnet = 0;
+ netmask = 0;
cnt = -1;
device = NULL;
infile = NULL;
@@ -949,8 +951,6 @@ main(int argc, char **argv)
RFileName, dlt_name,
pcap_datalink_val_to_description(dlt));
}
- localnet = 0;
- netmask = 0;
if (fflag != 0)
error("-f and -r options are incompatible");
} else {
@@ -1078,10 +1078,8 @@ main(int argc, char **argv)
warning("snaplen raised from %d to %d", snaplen, i);
snaplen = i;
}
- if (pcap_lookupnet(device, &localnet, &netmask, ebuf) < 0) {
- localnet = 0;
- netmask = 0;
- warning("%s", ebuf);
+ if (fflag && pcap_lookupnet(device, &localnet, &netmask,
ebuf) <
+ error("%s", ebuf);
}
}
if (infile)
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE
Guy Harris wrote:
On Dec 1, 2009, at 4:10 PM, Darren Reed wrote:
Use of libdladm is going to be required.
Required for what? Enumerating capture interfaces?
On Solaris, yes. This is a [Open]Solaris problem because libdladm is
not yet in a state suitable for use by tcpdump.
libpcap uses SIOCGLIFCONF to get the list of interfaces.
...if
1) you *don't* have getifaddrs()
Solaris does not appear to.
and
2) you *do* have SIOCGLIFCONF
Yes, Solaris does have this *but* it returns interfaces used with IPv4.
In libpcap, the code does:
fd4 = socket(AF_INET, SOCK_GRAM, 0);
...
if (ioctl(fd4, SIOCGLIFCONF, (char *)&ifc) < 0) {
On Solaris, each network address family has its own association with
a network interface. Thus doing SIOCGLIFCONF for an AF_INET
socket can produce different results to SIOCGLIFCONF for an
AF_INET6 socket. And both AF_INET and AF_INET6 sockets
can produce a different list to the datalinks that are visible with
"dladm show-phys".
Additional fad-*.c modules can be added (on Windows, for example, it
uses fad-win32.c - yes, even on Win64 :-)).
What would the appropriate APIs be on (various versions of) Solaris
for enumerating interfaces and, if available, getting network addresses?
At present, SIOCGLIFCONF is the only option and the [Open]Solaris
networking folks need to come up with a new interface for libpcap to
use here. I suspect it will be a union of SIOCGLIFCONF plus something
else because of IPNET.
Looking at tcpdump, pcap_lookupnet() should only be called from
tcpdump.c
if fflag is true because the returned values of localnet and netmask
are ignored
by init_addrtoname if fflag is not true.
localnet is unused if fflag is false; however, netmask is used by
pcap_compile() for the "ip broadcast" filter even if fflag is false.
I was afraid of something like that.
Oh well.
I think I would still advocate that pcap_lookupnet() should be fatal if
"-f" is present, though :)
Darren
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump: patches required for OpenSolaris/SXCE
In some further development, I've updated print-ipnet.c
to output which hook was used to record the packet.
The output has been modified to look like this:
$ ./tcpdump -c 3 -en -r ~/a
reading from file /home/dr146992/a, link-type IPNET (Solaris ipnet)
20:52:54.829738 0 > -1, hook observe-out (1) family IPv4 (2), length
152: 10.0.0.1.47974 > 10.0.0.3.1023: UDP, length 100
20:52:54.831924 -1 > 0, hook observe-in (0) family IPv4 (2), length 84:
10.0.0.3.32774 > 10.0.0.1.47974: UDP, length 32
20:52:54.831930 -1 > 0, hook observe-in (0) family IPv4 (2), length 84:
10.0.0.3.32774 > 10.0.0.1.47974: UDP, length 32
Previously this field was not printed out at all.
Darren
diff --git a/ipnet.h b/ipnet.h
index ae69284..abe4f60 100644
--- a/ipnet.h
+++ b/ipnet.h
@@ -9,5 +9,9 @@ typedef struct ipnet_hdr {
uint32_t iph_zdst;
} ipnet_hdr_t;
-#define IPH_AF_INET 2 /* Matches Solaris's AF_INET */
-#define IPH_AF_INET6 26 /* Matches Solaris's AF_INET6 */
+#define IPH_AF_INET 2 /* Matches Solaris's AF_INET */
+#define IPH_AF_INET6 26 /* Matches Solaris's AF_INET6 */
+
+#define IPOBS_H_INBOUND 0
+#define IPOBS_H_OUTBOUND 1
+#define IPOBS_H_LOCAL 2
diff --git a/print-ipnet.c b/print-ipnet.c
index 3a5b5a1..fdfd790 100644
--- a/print-ipnet.c
+++ b/print-ipnet.c
@@ -14,12 +14,19 @@
#ifdef DLT_IPNET
-const struct tok ipnet_values[] = {
+const struct tok ipnet_families[] = {
{ IPH_AF_INET, "IPv4" },
{ IPH_AF_INET6, "IPv6" },
{ 0, NULL }
};
+const struct tok ipnet_hooks[] = {
+ { IPOBS_H_INBOUND, "observe-in" },
+ { IPOBS_H_OUTBOUND, "observe-out" },
+ { IPOBS_H_LOCAL, "observe-local" },
+ { 0, NULL }
+};
+
static inline void
ipnet_hdr_print(struct netdissect_options *ndo, const u_char *bp, u_int length)
{
@@ -29,13 +36,16 @@ ipnet_hdr_print(struct netdissect_options *ndo, const u_char *bp, u_int length)
ND_PRINT((ndo, "%d > %d", hdr->iph_zsrc, hdr->iph_zdst));
if (!ndo->ndo_qflag) {
- ND_PRINT((ndo,", family %s (%d)",
- tok2str(ipnet_values, "Unknown",
- hdr->iph_family),
- hdr->iph_family));
+ ND_PRINT((ndo, ", hook %s (%d) family %s (%d)",
+ tok2str(ipnet_hooks, "Unknown",
+ ntohs(hdr->iph_htype)),
+ ntohs(hdr->iph_htype),
+ tok2str(ipnet_families, "Unknown",
+ hdr->iph_family),
+ hdr->iph_family));
} else {
ND_PRINT((ndo,", %s",
- tok2str(ipnet_values,
+ tok2str(ipnet_families,
"Unknown Ethertype (0x%04x)",
hdr->iph_family)));
}
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap performance under VMWare guest OSes
Mark Bednarczyk wrote: Hello, We are running into some performance issues with libpcap when running under VMWare products such as VMWworkstation or VMServer. These are guest OSes (running as a VM process on a host operating system.) Does the performance change if you compare capturing packets with the network interface in promiscuous mode vs not in promiscuous mode? Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Inefficiency in BPF code for DLT_RAW
Looking at the BPF code that gets generated for links such as the IP tunnels in Solaris, there appears to be an inefficiency in the opcodes generated. Let me explain. The links that support the IP tunnels are a fixed type, be it IPv4 or IPv6, and are reported as being DLT_RAW because there is no real layer 2 header present. This works fine for the opcodes generated but there's a slight problem: if I do "tcp or udp" (for example), the opcodes output handle both IPv4 and IPv6. The root of this appears to be in functions such as gen_proto_abbrev(), where opcodes to match for the protocol are output against both IPv4 and IPv6, with no way to select one or the other or both. The inefficiency pops up in two ways: 1) a check for which IP protocol is added when none is needed; 2) the BPF program is longer than it needs to be, possibly double the size it should be. In the face of modern processors, this might seem like micro-optimisation but I see it more as a precision error: it is not possible to precisely tell libpcap (and thus the BPF compiler) that a link only sees one protocol and therefore does not need to handle both protocol cases. Thoughts? Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Inefficiency in BPF code for DLT_RAW
On 23/12/09 06:09 PM, Guy Harris wrote: On Dec 23, 2009, at 2:01 AM, Darren Reed wrote: The links that support the IP tunnels are a fixed type, be it IPv4 or IPv6, and are reported as being DLT_RAW because there is no real layer 2 header present. ... In the face of modern processors, this might seem like micro-optimisation but I see it more as a precision error: it is not possible to precisely tell libpcap (and thus the BPF compiler) that a link only sees one protocol and therefore does not need to handle both protocol cases. Thoughts? DLT_IPv4 and DLT_IPv6? Works for me. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Inefficiency in BPF code for DLT_RAW
On 23/12/09 06:09 PM, Guy Harris wrote: On Dec 23, 2009, at 2:01 AM, Darren Reed wrote: The links that support the IP tunnels are a fixed type, be it IPv4 or IPv6, and are reported as being DLT_RAW because there is no real layer 2 header present. ... In the face of modern processors, this might seem like micro-optimisation but I see it more as a precision error: it is not possible to precisely tell libpcap (and thus the BPF compiler) that a link only sees one protocol and therefore does not need to handle both protocol cases. Thoughts? DLT_IPv4 and DLT_IPv6? Can I request for DLT numbers to be allocated? 228 & 229 would appear to be next. Thanks, Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] forces (and sctp) patch
On 11/01/2010 1:29 AM, Michael Richardson wrote: ... I was initially concerned about the output with -v, as it is multiline, and I think that without -v, one packet should occupy one line. This makes postprocessing easier, and certainly makes grep easier. Maybe we need another option, "--human"... With -v, the ip printer now starts a new line before the protocol. I am wondering if this was a wise change to have made Comments? Well, it gets in the way of all types of things, for example: tcpdump-v -i foo.cap | egrep pattern | wc -l I think the behaviour should be the reverse of the -g in Mac OS X and that is it should be necessary to use some new command line option to force tcpdump to insert new lines between things. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] New libpcap API
Since you're looking for one-liners... On 15/01/2010 9:47 PM, Mark Bednarczyk wrote: bpf_filter- ??? Applies the BPF program (filter) to a packet and returns if the packet should be captured or not. bpf_validate - ??? Verifies that a BPF program is valid and safe to run by checking the opcodes provided. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] forces (and sctp) patch
On 12/01/2010 6:57 PM, Michael Richardson wrote: "sthaug" == sthaug writes: >> Well, it gets in the way of all types of things, for example: >> >> tcpdump-v -i foo.cap | egrep pattern | wc -l >> >> I think the behaviour should be the reverse of the -g in Mac OS X >> and that is it should be necessary to use some new command line >> option to force tcpdump to insert new lines between things. sthaug> 100% agreed. I think changing the default behavior like that sthaug> was a bad idea, and should be reversed. There are three questions then: 1) do we do this now? 2) do we make any accomodation for the situation in between? 3) are there some volunteers to help? This kind of change to the defaul behaviour warrants bumping the version number from 4.x to 5.x because this is a significant change in the output of tcpdump and the output of tcpdump is a documented interface that is consumed by many. I'm curious about what the motivation is for splitting the timestamp and packet data onto separate lines is. I'm confused about your questions... are you saying "do we reverse it back to the old format now?" If so, yes... but shouldn't (3) then be a simple matter of applying the delta you committed to change the behaviour, in reverse? And I'm not sure I understand (2) at all... Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] forces (and sctp) patch
On 18/01/2010 9:27 PM, Michael Richardson wrote: "Darren" == Darren Reed writes: Darren> This kind of change to the defaul behaviour warrants bumping Darren> the version number from 4.x to 5.x because this is a Darren> significant change in the output of Yes, this is why I ask, "now?" Darren> I'm curious about what the motivation is for splitting the Darren> timestamp and packet data onto separate lines is. I think it just kinda happened. I would have to go back and look at who did what... I think that it does not occur in IP/TCP, but it does in IP/SCTP. As far as tcpdump 4.x goes, I'd consider that a bug in IP/SCTP printing. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Release schedule?
A question that I'm sure that everyone who's responsible for bringing libpcap and tcpdump into a distro would like to know is, what are the plans for the release schedule of libpcap and tcpdump, if there are any? Does a release of libpcap mean that there will be a new one for tcpdump? And/or vice versa? Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Release schedule?
Michael Richardson wrote: "Darren" == Darren Reed writes: Darren> A question that I'm sure that everyone who's responsible for Darren> bringing libpcap and tcpdump into a distro would like to Darren> know is, what are the plans for the release schedule of Darren> libpcap and tcpdump, if there are any? Darren> Does a release of libpcap mean that there will be a new one Darren> for tcpdump? And/or vice versa? We were planning a release for earlier this month, and the question of newline behaviour came up. I gave it an extra week to let people catch up and express an opinion. At this point, I think we have decided to release 4.1 as-is. Does tcpdump 4.1 imply libpcap 1.1 or 1.0.1 will also be made available? Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Release schedule?
Michael Richardson wrote: "Darren" == Darren Reed writes: Darren> A question that I'm sure that everyone who's responsible for Darren> bringing libpcap and tcpdump into a distro would like to Darren> know is, what are the plans for the release schedule of Darren> libpcap and tcpdump, if there are any? Darren> Does a release of libpcap mean that there will be a new one Darren> for tcpdump? And/or vice versa? We were planning a release for earlier this month, and the question of newline behaviour came up. I gave it an extra week to let people catch up and express an opinion. Can you summarise on what has changed here? When I compare verbose and non-verbose output of 4.0 vs current, there is no change. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Release schedule?
Michael Richardson wrote: "Darren" == Darren Reed writes: >> We were planning a release for earlier this month, and the >> question of newline behaviour came up. I gave it an extra week >> to let people catch up and express an opinion. >> >> At this point, I think we have decided to release 4.1 as-is. >> Darren> Does tcpdump 4.1 imply libpcap 1.1 or 1.0.1 will also be Darren> made available? I don't think I have a good reason for libpcap 1.0.1 vs 1.1, and Ken prep'ed for 1.1, so that's what I think it will be. Do you have another argument? I'm not fussed either way, I just didn't know if it would be 1.1 or 1.0.1 when I wrote the email, so I included both. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] BPF filter for tcp syn for ipv6
Ritesh Rekhi wrote: Hi all, I want to filter TCp syn packet which is coming using IPv6 addresses. I am not able to find the bpf filter for that can somebody help me to find the right BPF filter I have already tried" tcp[tcpflags] & (tcp-syn) != 0" which doesn't work for IPv6 traffic. What does "doesn't work for IPv6 traffic" mean? No packets? You continue to get all packets? Which platform? Linux? BSD? Solaris? Daren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Release schedule?
Is there a target date for the delivery of tcpdump 4.1 and libpcap 1.1? Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Release schedule?
On 19/02/10 10:56 AM, Michael Richardson wrote: "Darren" == Darren Reed writes: Darren> Is there a target date for the delivery of tcpdump 4.1 and Darren> libpcap 1.1? Ken is working on it as I type, I think. There's still no sign of a new release on www.tcpdump.org... Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Release schedule?
Michael Richardson wrote: "Darren" == Darren Reed writes: Darren> There's still no sign of a new release on www.tcpdump.org... http://www.tcpdump.org/beta/ I will sign "4.0.1rc3" as "4.1" on Monday evening. I don't know if this is user error or not, but both of the rc3 files I downloaded from the beta directory needed to be gunzip'd twice. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] When will a packet filter be ignored/unused?
On 16/03/10 04:40 PM, Jim Lloyd wrote: I have a working application using libpcap that doesn't always filter as I expect. The application is designed to sniff http traffic, so the filter can be as simple as "tcp port 80". However, we allow sniffing multiple http servers running on different ports, so it is common to use a filter like "tcp and (port 80 or port 8080)". Because of this, when sniffing a single port, the filter we use will look like "tcp and (port 80)". This filter seems to work correctly "most" of the time, but in varying situations we start to see packets where neither the source port or the destination port matches the specified port. Until today, I only noticed this for relatively high volume packet sniffing (say 250mbps). But now I am seeing it on one of our machines with a relatively modest volume of traffic (about 18mbps). I imagine it might be driver specific, and now I see that the ethernet interfaces on the servers I have available for testing have a more diverse set of drivers than I was aware. Using ethtool and checking a few different interfaces, I see drivers bnx2, tg3, and forcedeth. I seem to be having problems with bnx2. Is this a known issue? No error code is returned when we compile and install the filter. Is there any way to determine if a filter is being ignored? You might want to verify that libpcap is generating the correct byte codes with tcpdump with something like this: tcpdump -d 'tcp and (port 80)' (000) ldh [12] (001) jeq #0x86dd jt 2jf 8 # ipv6? (002) ldb [20] # yes... (003) jeq #0x6 jt 4jf 19 # tcp? (004) ldh [54] # yes... (005) jeq #0x50jt 18 jf 6 # port 80? (006) ldh [56] # no... (007) jeq #0x50jt 18 jf 19 # port 80? (008) jeq #0x800 jt 9jf 19 # ipv4? (009) ldb [23] # yes... (010) jeq #0x6 jt 11 jf 19 # tcp? (011) ldh [20] # yes... (012) jset #0x1fff jt 19 jf 13 # compute start of tcp (013) ldxb 4*([14]&0xf) (014) ldh [x + 14] (015) jeq #0x50jt 18 jf 16 # port 80? (016) ldh [x + 16] # no... (017) jeq #0x50jt 18 jf 19 # port 80? (018) ret #96# yes.. (019) ret #0 If the byte code verifies correctly then you might want to do a full packet header dump of those that get to you and aren't meant to - maybe there is something different about them... - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Release schedule?
On 03/31/10 11:39, Michael Richardson wrote: "Guy" == Guy Harris writes: Guy> On Mar 30, 2010, at 1:55 PM, Wesley Shields wrote: >> The links on http://www.tcpdump.org are broken. Guy> The tarballs are libpcap-1.1.tar.gz and tcpdump-4.1.tar.gz, Guy> rather than libpcap-1.1.0.tar.gz and tcpdump-4.1.0.tar.gz. Are Guy> we now calling the major releases 1.x and 4.x rather than 1.x.0 Guy> and 4.x.0, or are we continuing the convention of ". Oops, see what happens when the non-regular guy does the release. I'll fix them! And now that the .tar.gz files are "1.1.0" and "4.1.0", the directories inside are still "1.1" and "4.1." A fix for this would be nice. Thanks, Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Display of packet direction and interface name
the current libpcap record format has no way to record this information. you might like to play around with pcap-ng. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
