Re: [tcpdump-workers] question on DLT_ types
On Thu, Mar 25, 2004 at 02:00:44PM -0600, alex medvedev wrote: | hi, | | how do the DLT_ types get assigned? post your request to the list ... first come first serve once its in the code it is assigned | is there some "central authority" that does it? no | or are they arbitrarily assigned and therefore different between | platforms (e.g. AIX with its IFT_ types). new DLT_s should be consistent across platform; some legacy DLTs are afaik in the wild as everybody allocated wildly DLTs and did not report back their usage /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Patch for libpcap pcap_stats_linux
On Wed, Mar 31, 2004 at 10:16:55AM +0200, Alberto Ornaghi wrote: | Hannes Gredler wrote: | >On Fri, Jan 02, 2004 at 09:33:31AM +1100, Erik de Castro Lopo wrote: | > | >| The patch below, adds a static variable to pcap_stats_linux() which | >| holds a running total of the packet statistics so that the behaviour | >| of pcap_stats() on Linux matches the behaviour of FreeBSD. | > | >checked in; | | why this patch was not included in the 0.8.3 release ? | it is in the cvs, modified by guy to handle more than one pcap_t in use, | but is missing in the release tarball... afaik we only committed that to HEAD and not to the 3_8 branch; so it will certainly be in 3_9 or whatever is next; reason for that is that i was not 100% sure if this is a bugfix or a new "feature" (albeit a small one) and i took the conservative approach ... if you want it in 3_8_3 pls incorporate guys' suggestions and re-submit it; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] proposed new pcap format
On Thu, Mar 25, 2004 at 09:25:43AM -0800, Richard Sharpe wrote: | On Fri, 26 Mar 2004, Darren Reed wrote: | | > > okay, divide the 32-bit space into two 16-bit spaces. | > > vendor 0 will be reserved. | > > tcpdump.org will be vendor 1. | > > | > > vendor 0x will be reserved (for the NSA). | > | > Why not make both 32bit ? | > | > I say that because design requirements are different, today, than they | > were 15 years ago. | | I tend to agree with that. 16 bits seems awefully small for a vendor id | these days. i concur - also we have a printer in oui.c that takes 32-bit integers as input /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Proposed new pcap format
On Wed, Apr 14, 2004 at 03:06:09AM -0400, Jefferson Ogata wrote: [ ... ] | I think we should take a hard look at | whether it's really appropriate to define yet another hard binary file | format when XML can provide the same functionality with modest storage | overhead, and has many added benefits. jefferson, we are trying to converge on a sucessor to the current pcap format which is (practiacally) not extensible at all, mostly due to absenence of TLV encoding; so lets not make the mistake and compare apples (a non-extensible binary file format) with oranges (a extensible ascii/mime/xml) one and be reasonable ... proper TLV encoding and decent sizes of the types and values [16/32 bits] are key to extensible long lasting protocols/formats that meet efficiency, storage and bandwidth goals; i really only can speak for routing protocols [which my main expertise] and all the sucessful routing protocols [BGP,IS-IS,LDP,RSVP] are binary encoded albeit with a proper, extensible TLV and subTLV [nesting] orientation; actually distributed systems do live much longer than even simple file formats ... so one might ask if it does work for distributed systems why does it not work for storage ? i certainly do think that and XML _output_ of the binary file [not storage] does makes sense however IMHO that does not mandate to store the data and requiring conversion to a XML tag like structure which may impose performance constraints especially when you are thinking about capturing speeds of oc192c and above; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Proposed new pcap format
On Wed, Apr 14, 2004 at 08:25:25AM +0200, Fulvio Risso wrote: | I agree with Loris. | I know that this flag would be extremely useful, but there are no guarantees | that you're able to get this info from the NIC / NIC driver. | Perhaps, what we should to is to use 2 bits for each flag, where the first | one means "flag is valid", and the second one it is the flag value. | E.g.: | | 1 00 0 . . . . . . | ^^^ ^^^ ^^^^^^ | "incoming" flag packet is"outcoming" flag No meaning | is valid not "incoming" is NOT valid why not assigining simple codepoints for the direction information; i.e. 0 ... invalid/undefined/unsupported etc. 1 ... incoming 2 ... outgoing /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] IGRP
On Wed, Apr 28, 2004 at 10:03:56PM -0400, Michael Richardson wrote:
| -BEGIN PGP SIGNED MESSAGE-
|
|
| Hannes,
| ipproto.c has IPPROTO_IGRP, but ipproto.h doens't define it.
|
| Is this supposed to be protocol=9 ("IGP"), which you have as
| IPPROTO_PIGP, or???
yes, cisco is using proto #9 for IGRP and #88 for EIGRP;
apologies for breaking the build;
/hannes
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] IGRP
On Wed, Apr 28, 2004 at 07:23:31PM -0700, Guy Harris wrote: [ .. ] | The "temporary patch" Michael checked in is, in fact, the correct fix. | | That raises another question, though - "print-ip.c" now treats both | protocol 9 and protocol 88 as IGRP, but the packet formats are, I | think, different - should we *only* treat IPPROTO_PIGP as IGRP, and | handle IPPROTO_EIGRP either not at all or with an "eigrp_print()" | routine? i think the eigrp_print() option is the way to go just discovered that we have no eigrp decoder in tcpdump - i was under the false impression that print_igrp() would handle the eigrp formats as well bummer anyway eigrp (at least the IP flavour) would be IMHO a worthwhile thing to implement (the proto is still around and no signs that it becomes dead0; would somebody on the list hav the courtesy to send me a few eigrp .pcap captures then i'll cook something up; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] text format stability
eddie, i did most of the vflag changes in the last 18 months along with my work on the rsvp,bgp,isis,ospf,lmp,rip,pim,eigrp dissectors; the rationale behind this is that you get brief one-line information that is good enough for troubleshooting and for a detailed information (vv) we switch to multiline output; does this break existing scripts ? most certainly: however we have not yet found out how to progress the software in terms of new protcols and multilayer encapsualation support (gre/l2tp/mpls) and still stay 100% downwards compatible; my take is that until we change tcpdump output to an optional machine-parsable output (could be XML, could be anything else) we cannot solve this issue fundamentally; i had some offline discussion with michael and our current understanding is that we need to progress tcpdump which today just prints frames to a new structure that builds protocol trees; on the frame end we finally render the frame to a format that human|machine prcessors can understand; i.e. decouple protocol dissection from output rendering; it would be interesting to know from the community if such an effort would be seen worthwile; opinions ? /hannes On Wed, Jun 23, 2004 at 01:38:41PM -0700, Eddie Kohler wrote: | Hi all, | | I've noticed, painfully, that recent minor releases of tcpdump have | changed the longstanding format for "tcpdump -v" text output. This | isn't an inherently bad idea, but there are a lot of scripts in the | world that parse tcpdump text output, and that are broken by arbitrary | format changes. (For example, I have regression tests that check for | particular packet characteristics; comparing to tcpdump text output can | be better than pcap files for this purpose.) | | I hope that the tcpdump-workers plan to re-stabilize the tcpdump text | format soon, and that the next release will change a major version | number, to make the format changes more obvious to users. | | Thanks very much, | Eddie Kohler - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] text format stability
On Thu, Jun 24, 2004 at 10:56:09AM -0700, Eddie Kohler wrote: eddie, [ ... ] | Similarly, it seems a mistake to put IP header information (tos, ttl, id, | offset, flags, proto, length) before the addresses. This changes | longstanding tcpdump practice and makes the output *less* readable, since | the addresses are generally more important to humans than this info. We | could argue about whether this header info belonged at the end of each line | (where tcpdump formerly put it), or immediately after the addresses. But | putting it *before* the addresses is too much. i am a believer that networking dissectors should print data in the order they arrive ... header information comes before ip adresses, right ? the IMHO bad bad practise of printing header information (old format) at the end of the packet messed up multiline decoders and any decoder that has to display a hierarchy -> just remember the output mess that the GRE/IP decoder creates and the difficulty for humans to spot IP[n] TTL where N is a level of tunnels; - and there is quite a user base [FW-guys] that are interested in that level of information; | I was also a little put out by the fact that in the last tcpdump release -v | output said "proto 6", and now it says "proto: TCP (6)". There is great | value in picking a format and sticking with it. I am afraid that these | tinkerings will never stop. host-indep. proto name resolution was on the wishlist long time; nevermind, we are pretty much done for the main decoders [MPLS,IP,IP6,Ether,PPP,CHDLC,TCP] i am not yet done with UDP, FR, IPSec etc. | It would seem to me that the best approach here would be to design a new | format that applied *only in those cases where it was required*: | gre/l2tp/mpls tunneling. And of course it doesn't matter how new protocols | are printed, there are no backwards compatibility issues. i strongly have to disagree here: the main problem in the past was that we had no output consistiency across the dissectors ... the recent work aligned the style and readability to a common format which we should stick to ... agreed; maybe it would be also a good idea to publish a output guide to make things uniform right from the beginning when people work on new dissectors; | >my take is that until we change tcpdump output to | >an optional machine-parsable output (could be XML, | >could be anything else) we cannot solve this issue | >fundamentally; | | You cannot *solve* it, but your current course makes life much harder for | the installed base of tcpdump users. apologies if i created discomfort ... we have been on this course for 18 months now and generally the feedback on readability of tcpdump outputs was a positive one; | >i had some offline discussion with michael and our current | >understanding is that we need to progress tcpdump which today just | >prints frames to a new structure that builds protocol trees; | > | >on the frame end we finally render the frame to a format | >that human|machine prcessors can understand; i.e. decouple | >protocol dissection from output rendering; | > | >it would be interesting to know from the community if | >such an effort would be seen worthwile; | > | >opinions ? | | I don't see how this internal restructuring would affect tcpdump users. | | In summary, I hope I can convince you to change "-v" text output back | towards the older format, for the common cases that most tcpdump users care | about. Think of it this way: until very recently, users could run "tcpdump | -v" and get the same output they would expect from Stevens' books. The | wire formats have not changed. Why should tcpdump's output? the stevens book is a good source for learning about ip however not a normative ref. for tcpdump output style; wrt change / why ?: for the above mentioned reasons: old-tcpdump was non-uniform, misordered, non-hierarchy capable and we felt to progress it further rather than keeping it dormant; i may kindly ask to adapt your scripts b/c i do not want to backout the changes made; also i can reassure that the mentioned dissectors are relatively stable i.e. it is unlikely that there will be further changes here; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] text format stability
eddie, On Fri, Jun 25, 2004 at 09:34:47AM -0700, Eddie Kohler wrote: | These changes should not have been implemented globally, without some flag | or option to preserve the old behavior. Such a flag should be added. i had to make a call between polluting the code base further with new flags that may not used consitiently [e.g. q flag is my favourite example] or re-aligning the use of exisiting flags; [personally i only use typically -v -vv -e -x]; i did deliberately take the risk that i may break things IMHO adding functionality and consistiency is worth dropping some downwards compatability; output of structured data to non/structured is condemned to fail anyway; for example my employer was facing the same problem that everytime we changed the UI of our routing SW customers had to adapt their provisioning scripts, which (surprise) caused a lot of discomfort; finally we ended up exposing a machine parsebale interface encompassing XML tags; | My point in writing was to point out that there is a large audience of | tcpdump users who process its output with scripts. There are thousands of | scripts out there that you have broken, not just mine. You haven't heard | from them yet because new tcpdump hasn't seen wide distribution. well 3_8 is out since march ... it is in all major OS distributions and so far we did get only a single ;-) complaint. [i am not saying that your concerns are no valid] i am just saying that we had to horsetrade a bit and some things may fall through the cracks ... | I don't feel that tcpdump output should be frozen forever; some changes are | appropriate. But the changes I've seen have seemed indiscriminate. Again, | why put a comma after the TCP flags? Why reorder the TCP fields relative | to one another? Why change the way 'cksum' is spelled? Why print out the | checksum when it's valid? Why not leave the IP addresses at the beginning | of the line? Abstract reasons, about the physical order, are not good | enough. again consistency ... we use the "cksum 0x1234 (correct)" style in many dissectors; print-vrrp.c print-udp.c print-tcp.c print-isoclns.c print-ip.c print-icmp6.c print-icmp.c printing _all_ elements (checksum, ip ttl, dhcp options) not just som based on content makes actually script marsing much more easy ... many firewall guys expressed concerns that they want to see all the fields [IP ID] for detecting handcrafted packets etc --- a question: can we turn this (valuable) discourse in something productive ? i was thinking for quite a while about a output style-guide for new/existing dissectors; the primary target would be implementers for new dissectors however what i learned from the discussion is that there may be need for a normative spec that scripters can rely on [albeit not 100%] thoughts ? /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] text format stability
On Fri, Jun 25, 2004 at 02:21:24PM -0700, Christian Kreibich wrote: | Hi, | | On Fri, 2004-06-25 at 02:04, Hannes Gredler wrote: | > | > i am a believer that networking dissectors should print data in the order | > they arrive ... header information comes before ip adresses, right ? | > the IMHO bad bad practise of printing header information (old format) | > at the end of the packet messed up multiline decoders and any decoder | | just in case you really go forward with implementing configurable | output, then by all means consider adding an option that allows | disabling multiline output. It's a real pita. | | Otherwise I'm with Eddie on this -- you really don't want to change the | tcpdump textual output without a good reason and a *big* warning sign | after everbody finally got their regexes to do what they wanted :) | | A few months ago this list saw a discussion of the future capture file | format (what's the latest on that btw), and back then I suggested in | context of Jefferson's XML proposal that while I personally think an XML | capture format is not the right idea, an XML based tcpdump output would | be great in the long term -- it would certainly eliminate a lot of | parsing ambiguity. i concur ... nice TLV oriented binary encoding is good for .pcap storage however for further processing an XML output maybe ideal; that way tcpdump also could evolve to a "parsing middleware" fitting a nice niche between full-featured decoders like ethereal; /hannes - 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
darren,
can we have a .pcap sample showing such a frame for
the /tests directory ?
/hannes
On Thu, Jul 01, 2004 at 09:32:26PM +1000, Darren Reed wrote:
| 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.orig Wed 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.
-
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
darren, see questions/responses inline; On Fri, Jul 02, 2004 at 01:28:20AM +1000, Darren Reed wrote: | 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. you can send it to me unicast then i am not going to publish it; -- 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: 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 ? 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; frame 3 0x: ff03 c021 0a5d 0008 5241 249e 8531 looks like a regular PPP frame ... 0xff03 followed by a proto-id frame 4 0x: ff03 0021 4500 0067 616e 802f 0x0010: 0a01 2233 0a11 2233 3001 880b 0047 43e4 0x0020: 005a 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a 0x0030: 5a5a 5a5a 5a5a 5a5a 5a7d 5e5a 5a5a 5a5a 0x0040: 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a 0x0050: 5a5a 5a5a 5a5a 5a5a 5a5a 5a7d 5d5a 5a5a 0x0060: 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a 5a5a} frame 5 0x: ff03 c021 0a5e 0008 5241 249e eb99 same as 4 ... 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 ? except like frame 6 i would formulate the encoding logic like: test for 0xff03 -> call ppp_print() test for 0x21 -> call ip_print() test for 0x57 -> call ip6print() default: -> call ppp_handle() --- could you maybe also provide a pointer to a spec where the escaping routines and or the 0x7e escape hack is described ? wrt the curly bracket at the end of the hexdump -that not a bug this is an artifact of the l2tp dissector and i'll also have a look at that; /hannes - 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
On Thu, Jul 01, 2004 at 09:32:26PM +1000, Darren Reed wrote:
| 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
darren,
thanks for your submission - i have checked in the attached patch;
/hannes
Index: print-ppp.c
===
RCS file: /tcpdump/master/tcpdump/print-ppp.c,v
retrieving revision 1.95
diff -u -r1.95 print-ppp.c
--- print-ppp.c 2 Jul 2004 06:32:47 - 1.95
+++ print-ppp.c 2 Jul 2004 20:15:32 -
@@ -47,6 +47,7 @@
#include
#include
+#include
#include "interface.h"
#include "extract.h"
@@ -370,6 +371,7 @@
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 void ppp_hdlc(const u_char *p, int length);
/* generic Control Protocol (e.g. LCP, IPCP, CCP, etc.) handler */
static void
@@ -1052,10 +1054,81 @@
}
+static void
+ppp_hdlc(const u_char *p, int length)
+{
+ u_char *b, *s, *t, c;
+ int i, proto;
+ const void *se;
+
+ b = (u_int8_t *)malloc(length);
+ if (b == NULL)
+ return;
+
+ /*
+* 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, t = b, i = length; i > 0; i--) {
+ c = *s++;
+ if (c == 0x7d) {
+ if (i > 1) {
+ i--;
+ c = *s++ ^ 0x20;
+ } else
+ continue;
+ }
+ *t++ = c;
+ }
+
+ se = snapend;
+ snapend = t;
+
+/* now lets guess about the payload codepoint format */
+proto = *b; /* start with a one-octet codepoint guess */
+
+switch (proto) {
+case PPP_IP:
+ip_print(b+1, t - b - 1);
+goto cleanup;
+#ifdef INET6
+case PPP_IPV6:
+ip6_print(b+1, t - b - 1);
+goto cleanup;
+#endif
+default: /* no luck - try next guess */
+break;
+}
+
+proto = EXTRACT_16BITS(b); /* next guess - load two octets */
+
+switch (proto) {
+case 0xff03: /* looks like a PPP frame */
+proto = EXTRACT_16BITS(b+2); /* load the PPP proto-id */
+handle_ppp(proto, b+4, t - b - 4);
+break;
+default: /* last guess - proto must be a PPP proto-id */
+handle_ppp(proto, b+2, t - b - 2);
+break;
+}
+
+cleanup:
+snapend = se;
+ free(b);
+return;
+}
+
+
/* PPP */
static void
handle_ppp(u_int proto, const u_char *p, int length)
{
+if ((proto & 0xff00) == 0x7e00) {/* is this an escape code ? */
+ppp_hdlc(p-1, length);
+return;
+}
+
switch (proto) {
case PPP_LCP:
case PPP_IPCP:
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Bug in print-ppp.c
thanks for your submission - checked in; - /hannes On Tue, Jul 13, 2004 at 03:04:43PM +1000, Darren Reed wrote: | 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. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] How tcpdump works?
On Thu, Jul 22, 2004 at 01:03:49PM +0200, C?sar C?rdenas wrote: | Hi: | | In reviewing a file captured from a server I found my IP adress as a source | or as a destination, but there is not combination without my IP adress. | most likely you have a LAN-switch in your network, which means that you only see unicast traffic from/your IP adress and broad/multicast packets; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] New DLT needed for PPP active/passiv filtering
karsten, could you elaborate a bit more on "it creates binary incompatible filters"; in my testbed the linux machine creates 100% correct BPF filters; e.g. --->encaps is LINUX_SLL # tcpdump -i ppp0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes --->lets try the filter code for icmp # tcpdump -i ppp0 -d icmp (000) ldh [14] (001) jeq #0x800 jt 2jf 5 (002) ldb [25] (003) jeq #0x1 jt 4jf 5 (004) ret #96 (005) ret #0 ---> lets match on inbound direction # tcpdump -d -i ppp0 inbound (000) ldh [0] (001) jeq #0x0 jt 2jf 3 (002) ret #96 (003) ret #0 ---> and outbound # tcpdump -d -i ppp0 outbound (000) ldh [0] (001) jeq #0x4 jt 2jf 3 (002) ret #96 (003) ret #0 /hannes On Tue, Aug 17, 2004 at 12:53:54PM +0200, Karsten Keil wrote: | Hi, | | between libpcap version 0.7 and 0.8 the DLT_PPP was cleaned up to not longer | support the faked IN/OUT flag which was needed to compile filter rules | for the PPP activ/passiv filtering. | The cleanup is OK, since the nativ PPP frame do not have any IN/OUT flag, | so for traffic analysers it is confusing to have a faked first byte. | | But for activ/passiv filtering, which is needed to determine for dial on | demand which pakets are allowed to create a new connection or which pakets | hold the current connection open, it is a strong demand to differ between | own (OUT) and incoming traffic (which may contain unwanted pakets, like | port scans or pakets from old lost connections (dynamic IPs maybe | reassingned). | | So I was told some months ago to use cooked mode with DLT_LINUX_SLL, which | used a faked 16 byte ethernet header instead of the 4 byte PPP header. | I implement a solution based on this, but it has big disadventages: | | - it creates binary incompatible filters, it need new core routines for | activ/passiv filter (which replace the 4 byte header with a 16 byte | header) | - waste of resources, the paket handler must extend the headspace from 4 to | 16 byte only for executing the filter | | Because the incompatibility this solutions was rejected by the PPP | maintainers and I think they are right. | | A solution may be to create a new DLT_PPP_INOUT (better names welcome), | which take the first PPP byte, which is not needed for filtering as IN/OUT | Flag (same behavior as libpcap 0.7 DLT_PPP had). | This solution is backward compatible and need no changes in the PPP core | routines. Old ppp binary (libpcap 0.7 based) will still work. | The main DLT_PPP for traffic analyser stuff will remain clean and not | got confused this extra stuff. | | So I need a DLT number assigned for this new DLT_PPP_INOUT. | | -- | Karsten Keil | ISDN development | - | 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] modifying source code
On Tue, Aug 17, 2004 at 03:16:27AM +0100, neha agrawal wrote: | hello! | i am capturing packets using tcpdump. i want | to read the packet header and all.. as tcpdump reads | and put the information in data base.i dont want to | read from output generated by tcpdump.. but read | information of packets as and when tcpdump reads.. and | put them in database.. can u let me know which source | files i need to modify. is there some document | describing flow of the source code of tcpdump.. | thanks | neha neha, as a good start i would encourage you to read through the ethernet [print-ethernet.c] ip [print-ip.c] and ppp [print-ppp.c] printers; it should not be too difficult to hook in a database dumper; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] New DLT needed for PPP active/passiv filtering
karsten, i have checked in support for the new DLT_PPP_WITH_DIRECTION (166) and LINKTYPE_PPP_WITH_DIRECTION (166) also i tweaked libpcap to treat it like PPP plus support of the inbound/outbound tokens; see below testresults ... # ./tcpdump -dr ppp-dlt166.pcap "inbound" reading from file ppp-dlt166.pcap, link-type 166 (000) ldb [0] (001) jeq #0x0 jt 2jf 3 (002) ret #4474 (003) ret #0 # ./tcpdump -dr ppp-dlt166.pcap "outbound" reading from file ppp/ppp-dlt166.pcap, link-type 166 (000) ldb [0] (001) jeq #0x1 jt 2jf 3 (002) ret #4474 (003) ret #0 # ./tcpdump -dr ppp-dlt166.pcap "ip && inbound" reading from file ppp/ppp-dlt166.pcap, link-type 166 (000) ldh [2] (001) jeq #0x21jt 2jf 5 (002) ldb [0] (003) jeq #0x0 jt 4jf 5 (004) ret #4474 (005) ret #0 # ./tcpdump -dr ppp-dlt166.pcap "ip && outbound" reading from file ppp/ppp-dlt166.pcap, link-type 166 (000) ldh [2] (001) jeq #0x21jt 2jf 5 (002) ldb [0] (003) jeq #0x1 jt 4jf 5 (004) ret #4474 (005) ret #0 let me know if this fits your needs; /hannes On Wed, Aug 18, 2004 at 02:23:21PM +0200, Karsten Keil wrote: | It was here in the PPP filter context. The normal 4 byte header looks like: | | FF 03 P1 P2 give a 16 bit protocol ID for identyfy the data | following the haeder, which maybe PPP control data or IP/IPX payload data. | Since the PPP filtering is only called for IP/IPX payload frames, the | constant FF byte was redefined as IN/OUT Flag (1 := OUT, 0:= IN). | Note: The Filter is called after doing all decompression, so its allways | a simple PPP payload data frame (in case of outgoing, it is called before | doing compression or add multilink headers). | | > | > Note also that, for any DLT_PPP packets that *did* have an extra first | > byte in the header, any *other* filter expression wouldn't work, as the | > rest of the code for PPP assumed that it *wasn't* there. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] New DLT needed for PPP active/passiv filtering
karsten, i have checked in support for DLT_PPP_WITH_DIRECTION in tcpdump and the PPP printer - the PPP printer shows now the direction (hidden under the -e flag) /hannes --- karsten, i have checked in support for the new DLT_PPP_WITH_DIRECTION (166) and LINKTYPE_PPP_WITH_DIRECTION (166) also i tweaked libpcap to treat it like PPP plus support of the inbound/outbound tokens; see below testresults ... # ./tcpdump -dr ppp-dlt166.pcap "inbound" reading from file ppp-dlt166.pcap, link-type 166 (000) ldb [0] (001) jeq #0x0 jt 2jf 3 (002) ret #4474 (003) ret #0 # ./tcpdump -dr ppp-dlt166.pcap "outbound" reading from file ppp/ppp-dlt166.pcap, link-type 166 (000) ldb [0] (001) jeq #0x1 jt 2jf 3 (002) ret #4474 (003) ret #0 # ./tcpdump -dr ppp-dlt166.pcap "ip && inbound" reading from file ppp/ppp-dlt166.pcap, link-type 166 (000) ldh [2] (001) jeq #0x21jt 2jf 5 (002) ldb [0] (003) jeq #0x0 jt 4jf 5 (004) ret #4474 (005) ret #0 # ./tcpdump -dr ppp-dlt166.pcap "ip && outbound" reading from file ppp/ppp-dlt166.pcap, link-type 166 (000) ldh [2] (001) jeq #0x21jt 2jf 5 (002) ldb [0] (003) jeq #0x1 jt 4jf 5 (004) ret #4474 (005) ret #0 let me know if this fits your needs; /hannes On Wed, Aug 18, 2004 at 02:23:21PM +0200, Karsten Keil wrote: | It was here in the PPP filter context. The normal 4 byte header looks like: | | FF 03 P1 P2 give a 16 bit protocol ID for identyfy the data | following the haeder, which maybe PPP control data or IP/IPX payload data. | Since the PPP filtering is only called for IP/IPX payload frames, the | constant FF byte was redefined as IN/OUT Flag (1 := OUT, 0:= IN). | Note: The Filter is called after doing all decompression, so its allways | a simple PPP payload data frame (in case of outgoing, it is called before | doing compression or add multilink headers). | | > | > Note also that, for any DLT_PPP packets that *did* have an extra first | > byte in the header, any *other* filter expression wouldn't work, as the | > rest of the code for PPP assumed that it *wasn't* there. - 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] New DLT needed for PPP active/passiv filtering
karsten, could not reprodoce -> anoncvs is working for me; can you try again, pls ? /hannes On Thu, Aug 19, 2004 at 02:56:47AM +0200, Karsten Keil wrote: | On Wed, Aug 18, 2004 at 06:36:22PM +0200, Karsten Keil wrote: | > Hi Hannes, | > | > On Wed, Aug 18, 2004 at 05:27:41PM +0200, Hannes Gredler wrote: | > > karsten, | > > | > > i have checked in support for DLT_PPP_WITH_DIRECTION in | > > tcpdump and the PPP printer - the PPP printer shows now | > > the direction (hidden under the -e flag) | > > | > > /hannes | > > | > | > Thank you very much for this work, it will save me a lot | > of time to implement it myself, since I don't known the libpcap | > good enough. | > I will test it next days and report results here. | > | | Hmm, unfortunatly it seems that anoncvs is still not working | without extra authorisation and also the daily snapshoots are | not actual (last: libpcap-2004.07.22), so I cannot get the | changes. | | -- | Karsten Keil | SuSE Labs | ISDN development | - | 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] New DLT needed for PPP active/passiv filtering
On Thu, Aug 19, 2004 at 02:52:38PM +0200, Karsten Keil wrote: | On Thu, Aug 19, 2004 at 01:27:45PM +0200, Hannes Gredler wrote: | > karsten, | > | > could not reproduce -> anoncvs is working for me; | > can you try again, pls ? | > | | I think because your IP was registered (here was a thread about this | problem in july). correct, michael requires you to have a valid PTR entry ... assume at your employer there must be some workstation with a valid PTR entry ;-) /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] x.9 branch
On Thu, Sep 23, 2004 at 12:23:55PM -0700, Guy Harris wrote: | (blah blah blah the other brain fart was sending it from sonic.net again | blah blah blah duplicate message dissector blah blah blah) | | Michael Richardson wrote: | | > You tell me. | > We didn't do a 0.8.4 yet, but this sounds like significant enough to | >warrant 0.9, but maybe I'm wrong. | | Sorry, brain fart, I didn't notice the ".9". | | If we branch from HEAD, it would definitely be an 0.9/3.9 release. | Libpcap includes significant new functionality, such as support for | sending packets, and there are also significant changes to tcpdump - | and, yes, the radiotap support is a significant change in and of itself, | so it arguably belongs in a 3.9 release rather than a 3.8.4 release. | [changed subject:] any suggestion for a x.9 branch date ? what about 31-oct-04 ? /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Buffer size question
shouldn't we have upper/lower boundary checks for
such a buffer ?
i.e. minbuffer 1.5K
maxbuffer 128K
/hannes
On Thu, Oct 14, 2004 at 02:29:14PM -0400, Ed Maste wrote:
| > I'll download one of the nightly tars and try out the
| > environment variable idea.
|
| Here's my simple patch to allow an environment variable
| PCAP_BUFSIZE to override the default initial buffer size.
|
| --- pcap-bpf.cTue Oct 5 03:23:39 2004
| +++ pcap-bpf.c.newThu Oct 14 14:21:41 2004
| @@ -578,6 +578,7 @@
| u_int v;
| pcap_t *p;
| struct utsname osinfo;
| + char *cp;
|
| #ifdef HAVE_DAG_API
| if (strstr(device, "dag")) {
| @@ -626,6 +627,8 @@
|*/
| if ((ioctl(fd, BIOCGBLEN, (caddr_t)&v) < 0) || v < 32768)
| v = 32768;
| + if ((cp = getenv("PCAP_BUFSIZE")))
| + v = atoi(cp);
| for ( ; v != 0; v >>= 1) {
| /* Ignore the return value - this is because the call fails
|* on BPF systems that don't have kernel malloc. And if
| -
| 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] packet dumping
hi, i am not 100% sure if i do understand your question; if its regarding printing a hexdump of an arbitrary (including ICMP) then you may want to try tcpdump with the -X flag; see the tcpdump man page for details; /hannes On Sat, Jan 01, 2005 at 05:30:03AM -0800, linux lover wrote: | Hi all, | I want to know which program and which statement | in that prints HEX dump of ICMP packet. I want to | write my own sniffer but not getting how to print | packets content and in which format to look like | 4500 003a feac 4000 4006 b7fe c0a8 01c1 | c0a8 0101 0403 05dc 1d83 3d44 1bd2 e615 | 8018 16d0 fe41 0101 080a c3e9 | 894f 5061 7261 6700 | I am doing this on linux as a kernel sniffer module. | Any other help is appreciated. | Thanks in advance. | regards, | linux_lover - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Problem in print-egp.c
checked in 3_8 and HEAD branch - tx, /hannes
On Fri, Jan 07, 2005 at 07:45:32PM +0100, [EMAIL PROTECTED] wrote:
|
| Hi,
| There is a bug in egp_print fonction from print-egp.c
| tcpdump don't print correct egp packet smaller than 32bytes, because their
| size was inferior to egp struct size.
| Here you'll find the patch.
| I have posted it on sourceforge. But i don't know how sf patch submitting
| system works.
| So I send it to this mailing list.
| I hope it's the appropriate place...
| Does the patch will be integrated to the next version of tcpdump?
|
| Nicolas FERRERO
|
|
| diff -urN tcpdump-3.8.3/interface.h tcpdump/interface.h
| --- tcpdump-3.8.3/interface.h 2004-03-17 20:47:48.0 +0100
| +++ tcpdump/interface.h 2004-12-23 03:48:12.796318448 +0100
| @@ -216,7 +216,7 @@
| extern void default_print(const u_char *, u_int);
| extern void default_print_unaligned(const u_char *, u_int);
| extern void dvmrp_print(const u_char *, u_int);
| -extern void egp_print(const u_char *);
| +extern void egp_print(const u_char *, u_int);
| extern u_int enc_if_print(const struct pcap_pkthdr *, const u_char *);
| extern u_int pflog_if_print(const struct pcap_pkthdr *, const u_char *);
| extern u_int arcnet_if_print(const struct pcap_pkthdr *, const u_char *);
| diff -urN tcpdump-3.8.3/print-egp.c tcpdump/print-egp.c
| --- tcpdump-3.8.3/print-egp.c 2003-11-16 09:51:18.0 +0100
| +++ tcpdump/print-egp.c 2004-12-23 04:51:21.991273256 +0100
| @@ -214,7 +214,7 @@
| }
|
| void
| -egp_print(register const u_int8_t *bp)
| +egp_print(register const u_int8_t *bp, register u_int length)
| {
| register const struct egp_packet *egp;
| register int status;
| @@ -222,7 +222,7 @@
| register int type;
|
| egp = (struct egp_packet *)bp;
| - if (!TTEST(*egp)) {
| + if (!TTEST2(*egp, length)) {
| printf("[|egp]");
| return;
| }
| diff -urN tcpdump-3.8.3/print-ip.c tcpdump/print-ip.c
| --- tcpdump-3.8.3/print-ip.c 2004-03-24 10:01:39.0 +0100
| +++ tcpdump/print-ip.c2004-12-23 03:47:18.108632240 +0100
| @@ -551,7 +551,7 @@
| break;
|
| case IPPROTO_EGP:
| - egp_print(cp);
| + egp_print(cp, len);
| break;
|
| case IPPROTO_OSPF:
|
|
|
|
|
| -
| 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] More information about print_egp problem
On Tue, Jan 11, 2005 at 02:53:29AM +0100, [EMAIL PROTECTED] wrote: | Hi, | There is an error in the last message tcpdump print correctly egp paquet | in ascii and hexadecimal, but for egp paquet neighbor reachabily messages | the autonomous system num and the sequence num are not printed. I can see | only an [|egp]. | It's because the size of an egp nrm packet is inferior to the egp | structure size. | | You can find the patch to correct it in the last mail about egp. | Thanks, missed that one - can you pls resubmit - /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] guessing when TSO is present
checked in - thanks for the submission - /hannes On Wed, Jan 19, 2005 at 05:35:13PM -0800, Rick Jones wrote: | A while back I think I posted something asking about what to do about TSO | (large send) and how it generated "IP bad-len 0" output when tracing on a | TSO-enabled sender. | | I had a couple spare cycles, so I decided to just take a WAG at what might | be done, which was to say that if the IP len was zero, just go ahead and | guess that this was a TSO and set the len to the length parm pass-in to | print-ip and hope. [ ... ] | basically, if the IP len is zero, ass-u-me that the segment is TSO and wing | it. | | rick jones - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT_PRISM_HEADER etc. and bpf_error("ethernet addresses supported only on ethernet/FDDI/token ring/802.11/ATM LANE/Fibre Channel")
On Wed, Jan 26, 2005 at 01:44:28PM +0100, Karl Gaissmaier wrote: | Hello, | | the following bpf filters with ethernet addresses like | 'ether host ' or synonym: 'wlan host ' | and others with mac address checks like gateway, multicast, ... | are not handled within gencode.c if you monitor a WLAN device in | monitor mode with PRISM header prependend. | | There are missing CASE statements for DLT_PRISM_HEADER in | the different filter checks and a modified gen_wlanhostop | to shift the packet the prism header length, but using the | same logic as for the DLT_IEEE802_11 link layer. | | The same is true for the other driver specific prepended 802.11 | headers like DLT_IEEE802_11_RADIO and DLT_IEEE802_11_RADIO_AVS. | | It would be nice if someone could spend some time to fix this. | now while you are it, you are welcome to submit a patch ... the "i don't think my code is good enough" excuse will not be accepted as there are enough competent reviewers on the list; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] can't do CVS checkouts/updates anymore
gert, i am not maintaining the cvs server [michael does - so he is the only one who can comment ] - wrt the cdp printer can you send me your print-cdp file and i'll check it in; /hannes On Thu, Feb 03, 2005 at 01:06:21PM +0100, Gert Doering wrote: | Hi, | | since quite a while, I can't do CVS pserver operations anymore (at | least half a year, but since I had no need to actually do anything | to the sources, I never bothered enough to send mail). | | I asked Hannes Gredler privately, he says "works for me", but it | doesn't work for me. I tried 4 different machines (Linux, NetBSD, | SCO, some with IPv4+IPv6, some with only IPv4) but the result is always | the same: | | [EMAIL PROTECTED]:/user/gert$ cvs -d :pserver:[EMAIL PROTECTED]:/tcpdump/master login | Logging in to :pserver:[EMAIL PROTECTED]:2401/tcpdump/master | CVS password: | cvs [login aborted]: end of file from server (consult above messages if any) | | (this is from "miyu.greenie.muc.de", 193.149.48.180, consistent forward | and reverse DNS for IPv4 and IPv6, Linux. Last attempt was done at | 12:05 GMT, just when composing this e-mail - so you might see it in the | server logs) | | Any idea what is causing this? It looks like an over-eager tcp wrapper | is kicking me for some reason. | | I have some new items for print-cdp.c that I'd like to integrate, test, | and then send upstream... | | gert | | -- | USENET is *not* the non-clickable part of WWW! |//www.muc.de/~gert/ | Gert Doering - Munich, Germany [EMAIL PROTECTED] | fax: +49-89-35655025[EMAIL PROTECTED] | - | 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] Welcome to the tcpdump-workers list!
On Fri, Feb 18, 2005 at 03:28:50PM +0400, Ramsurrun Visham wrote: | Hi, | | 1) wanted to ask how to make tcpdump show mac addresses? use the e flag [tcpdump -e ] for displaying link-layer information; | 2) how can I pass the packet that has been captured by tcpdump to iptables? | not sure i understand ... what is the problem you're trying to solve ? /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] ICMP header
On Sun, Feb 27, 2005 at 10:37:34PM +0400, Ramsurrun Visham wrote:
| Hi to all,
|
| I would like to know how do we grab the icmp header from an ethernet frame. I
believe we have to jump pass the ethernet and IP headers..
no - we actually need to parse through the IP header to find out if the header
is variable length [IP options etc.]
have a look at the point where the icmp printer is called in print-ip.c
---
case IPPROTO_ICMP:
/* pass on the MF bit plus the offset to detect
fragments */
icmp_print(cp, len, (const u_char *)ip, (off & 0x3fff));
break;
---
| u_char * handle_IP(u_char *args, const struct pcap_pkthdr* pkthdr, const
u_char* packet)
|
| {
|const struct my_ip* p;
|u_int length = pkthdr->len;
|
|ip = (struct my_ip*)(packet + sizeof(struct ether_header));
|length -= sizeof(struct ether_header);
| }
|
| I tried to check the tcpdump source code but couldn't understand it. I looked
in print_icmp.c and print_ip.c in particular.
|
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Problem with packet on ATM
On Tue, Mar 01, 2005 at 10:19:25AM +0100, Eric Leblond wrote: | Hi, | | I had to dump some RFC2684 atm bridge interfaces for a customer. We | often have some strange messages : | 09:09:43.262575 77:9c:7d:60:8:0 c:3f:b4:8:0:0 4500 401: | 0183 df1d 7111 96fb 527f 2537 d50b | 858f 7325 18ca 016f 36a5 474e 4403 aa2e | 0101 789c 9ba2 c714 e861 e421 e01e daa8 | fedc d6ea ef23 d5bb d353 7f85 fa3d 13f7 | 60f3 730c aa57 353f 25e1 c012 16e4 18e5 | e8c1 | It seems tcpdump looses the link header (2bytes) and that consequently | the whole packet reading is shift. We've found that because we know that | the source mac address is : | 00:00:77:9c:7d:60 | Furthermore, the protocol is 0800 thus explaining the last 2 bytes of | the MAC address. | | Same problem occurs when testing it on an ATM clip interface. | | This is weird but it does only occur on some packets mainly TCP one (as | we can guess from packet content) other are correctly parsed. | | Is this a known problem ? can you send me the binary .pcap file that contains such a frame and i'll have a look - /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Customization of tcpdump for some specific requirements...
On Tue, Apr 05, 2005 at 10:36:59AM -0700, Shyam Kumar wrote: | | [1] Data Representation is handled by tcpdump code only or both by | tcpdump code & libpcap code?? if by data-representation you mean dissecting protocols then this is done by tcpdump; | [2] which *.c & *.h files deals with data representation in tcpdump & | libpcap code ?? pretty much each protocol has its own print-.c file | [3] Can the data representation part be easily segregated from parsing & | filtering mechanism?? not easy doable ... after the tpcdump 3.9 release we will start working on getting the parsing part independent from the display output; the goal is to render the display output based on a generic datastructure in every target format that users are interested (xml etc.) without ever tweaking the parsing code again; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Automatic report from sources (tcpdump libpcap
ack, will do ... - /hannes On Sat, Apr 09, 2005 at 03:18:28AM -0700, Guy Harris wrote: | Automatic cvs log generator /tcpdump/bin/makelog wrote: | | >Description: | >-add support for llc based protocols (iso, etc..) for ethernet | > by checking the proto against the ethermtu and bumping | > the link-layer offset by two. | > | >-add support for vlan and mpls hierarchies by not absolute | > setting offsets but rather incrementing them; | > | > example(s): | > | > mpls 10 && mpls 1024 | >=filters for outerlabel 10 and inner label 1024 | > vlan 100 && vlan 200 | >=filters for vlan 200 encapsulated withing vlan 100 | > vlan 300 && mpls 17 | >=filters for mpls label 17 encapsulated in vlan 300 | >Modified files: | > File: libpcap/gencode.c; Revision: 1.223; | > Date: 2005/04/08 14:40:38; Author: hannes; Lines: (+62 -71) | | You might want to update the tcpdump man page to document that. | - | 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] pcap next gerneration / adding communication
On Fri, Apr 08, 2005 at 05:15:15AM -0700, Bruce M Simpson wrote: | On Fri, Apr 08, 2005 at 11:57:33AM +0200, Pilz Rene wrote: | > I want to add a feature where someone can connect and use a | > network-interface of a remote computer to capture data. As ronnie | > sahlberg has already pointed out in the ethereal list, | > authentication and athoriztion should be one of the topics there. For | > sure the will be several more issues. | i typically use the following command for remote capturing: ssh [EMAIL PROTECTED] "sudo tcpdump -ni eth0 -s 0 -w -" > capture-file.pcap authentication/authorization/confidentiality and transport provided by ssh; does this help ? /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap next gerneration / adding communication
if you want to do live capturing and decode using ethereal/tethereal then you'd simply do: ssh [EMAIL PROTECTED] "sudo tcpdump -ni eth0 -s 0 -w -" | tethereal -nli - /hannes On Sat, Apr 09, 2005 at 05:05:16PM +0200, Pilz Rene wrote: | Thanks for the suggestion. I need it in that way, that I can use it like | local captureable network interface. | This is due the fact, that I need it in a program which uses the | libpcap. In my case is it ethereal. And when | I download the files first, then I have no advantage to the solutions, | which I use now. | | Thanks anyway. | | /rene | | Hannes Gredler wrote: | | >On Fri, Apr 08, 2005 at 05:15:15AM -0700, Bruce M Simpson wrote: | >| On Fri, Apr 08, 2005 at 11:57:33AM +0200, Pilz Rene wrote: | >| > I want to add a feature where someone can connect and use a | >| > network-interface of a remote computer to capture data. As ronnie | >| > sahlberg has already pointed out in the ethereal list, | >| > authentication and athoriztion should be one of the topics there. For | >| > sure the will be several more issues. | >| | > | >i typically use the following command for remote capturing: | > | >ssh [EMAIL PROTECTED] "sudo tcpdump -ni eth0 -s 0 -w -" > | >capture-file.pcap | > | >authentication/authorization/confidentiality and transport provided by ssh; | > | >does this help ? | > | >/hannes | >- | >This is the tcpdump-workers list. | >Visit https://lists.sandelman.ca/ to unsubscribe. | > | > | > | | | -- | Dipl-Ing (FH) MSc. C.E Ren? Pilz | ftw. Telekommunications Research Center Vienna http://www.ftw.at | Tech Gate Vienna, Donaucitystra?e 1, A-1220 Wien | Mobile: +43 664 8269871 Office: +43 1 5052830-13 Fax: +43 1 5052830-99 | | - | 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] compile failed on NetBSD-1.6.2
checked in; - /hannes On Tue, Apr 12, 2005 at 06:38:18AM +0900, TANAKA Shin-ya wrote: | Hi, | while trying to compile libpcap-2005.04.11 on NetBSD-1.6.2, I got this error: | | $ make | gcc -O2 -I. -DHAVE_CONFIG_H -D_U_="__attribute__((unused))" -c ./pcap-bpf.c | ./pcap-bpf.c: In function `pcap_open_live': | ./pcap-bpf.c:732: parse error before `:' | *** Error code 1 | | Stop. | make: stopped in /tmp/aaa/libpcap-2005.04.11 | | | to solve this error, apply the following patch. | | diff -ur libpcap-2005.04.11.orig/pcap-bpf.c libpcap-2005.04.11/pcap-bpf.c | --- libpcap-2005.04.11.orig/pcap-bpf.cSun Feb 27 06:58:05 2005 | +++ libpcap-2005.04.11/pcap-bpf.c Mon Apr 11 22:12:18 2005 | @@ -729,7 +729,7 @@ | #endif | #ifdef PCAP_FDDIPAD | if (v == DLT_FDDI) | - p->fddipad = PCAP_FDDIPAD: | + p->fddipad = PCAP_FDDIPAD; | else | p->fddipad = 0; | #endif | | | | | | --- | 2GB?$B$^$G%a!<%k$d2hA|$J$ICy$aJ|Bj!*$5$i$KFCE5$$$C$Q$$"v | livedoor ?$B%.%,%a!<%i!<%W%i%9 ?$B!Z?7EP>l![ | http://gigamailerplus.livedoor.com/ | | - | 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] (3) tcpdump infinite loop bugs... (2 fixed in cvs it seems, 1 not)
On Sun, Apr 24, 2005 at 04:02:56PM -0400, v9 wrote:
|
| i'm not totally sure this is the right place to send this, but i hope
| so.
it is the right place ...
|
| 3 infinite loop dos bugs... the bgp and ldp one SEEM to be fixed in the
| cvs versions...the isis one isn't.
have checked in fixes into CVS-{HEAD, 3.9, 3.8}
/hannes
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] another infinite loop in tcpdump, RSVP this time (ethereal too)
On Sun, Apr 24, 2005 at 10:11:53PM -0400, v9 wrote: | | sorry i didn't include this one in the original message...noticed it fixed in tcpdump cvs and 3.9 - tx, /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] (3) tcpdump infinite loop bugs... (2 fixed
for software [3.9,cvs] that has not even been released yet ? - /hannes On Mon, Apr 25, 2005 at 05:28:51PM +0200, Romain Francoise wrote: | Can someone request CAN numbers for these? Michael? | | -- | ,''`. | : :' :Romain Francoise <[EMAIL PROTECTED]> | `. `' http://people.debian.org/~rfrancoise/ |`- | - | 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] tcpdump - fragmented?
i am not sure if i understand your question: if your question is "does tcpdump indicate if an IPv4 packet is fragmented ?" then the answer is yes, we do display the offset and more-fragment header flags in verbose (-v) mode; /hannes On Tue, Apr 26, 2005 at 11:01:09AM -, soumya r wrote: | Hello, |Could anyone please tell whether "tcpdump" produces an output of packets in 'fragmented' or 'defragmented' form? | Thanks | Soumya.- | 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] (3) tcpdump infinite loop bugs... (2 fixed
On Mon, Apr 25, 2005 at 07:16:39PM +0200, Romain Francoise wrote: | Hannes Gredler <[EMAIL PROTECTED]> writes: | | > for software [3.9,cvs] that has not even been released yet ? | | All the exploits mention tcpdump 3.8.x as being affected. I didn't run | them to check that it's really the case, though... did you? you're right for 3.8 it makes sense ... i did check meanwhile and both isis and rsvp are affected [just committed the outstanding 3.8 fix for rsvp] /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] (3) tcpdump infinite loop bugs... (2 fixed
On Tue, Apr 26, 2005 at 07:40:42PM +0200, Romain Francoise wrote: | Hannes Gredler <[EMAIL PROTECTED]> writes: | | > you're right for 3.8 it makes sense ... i did check meanwhile and both | > isis and rsvp are affected [just committed the outstanding 3.8 fix for | > rsvp] | | Okay, thanks. I have fixes for isis and rsvp but bgp and ldp are more | problematic, they're said to be fixed in 3.9/CVS but the versions have | diverged so much since 3.8 that I don't really know what's relevant... | Do you plan to merge fixes in the 3.8 branch or should I hack things | myself? i have checked in fixes for ldp/bgp plus testfiles for the 3.8 branch; so all 4 reported exploits are fixed now in the 3.8 branch; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 802.1Q VLAN packets
On Tue, May 10, 2005 at 04:09:36PM +, David Moron wrote: | Hi, | | Where can I find the files related to the VLAN packets. I'm trying to | write a simple program to extract IP packets inside VLAN packets using pcap. for the BPF code generator look into gencode.c / libpcap for the vlan printer in tcpdump look into print-ether.c /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] preperation for 3.9 branch
On Mon, May 16, 2005 at 11:20:20AM -0700, Guy Harris wrote: | Gianluca Varenni wrote: | | >Is there any new plan for the release of libpcap 0.9? | | At this point, I don't have anything additional planned for tcpdump | (other than perhaps grabbing some more capture files from the Ethereal | Web site and from mail to the Ethereal list, and running tcpdump against | those captures and "fuzzed" versions of those captures), but the fuzzed | captured tests I've run all pass now (which doesn't mean there aren't | any more bugs for fuzz testing to find, but it means that some obvious | ones were fixed). i have a support for 4 more juniper specific DLTs on the boilerplate plus support for another BGP SAFI - i'd be gratfule if we could delay the R1 release until end of this week; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 3.9 release
go ahead .. i have committed my stuff - /hannes On Wed, May 25, 2005 at 01:19:02PM -0400, mcr wrote: | -BEGIN PGP SIGNED MESSAGE- | | | Hi, I haven't cut the branch yet. Tonight, I think. | | I have a good excuse --- a child process was spawned, and it doesn't | take well to resource limits yet :-) | | - -- | ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ | ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ | ] http://www.sandelman.ca/mcr/www.xelerance.com/training/ |device driver[ | ]I'm a dad: http://www.sandelman.ca/lrmr/ [ | | | | -BEGIN PGP SIGNATURE- | Version: GnuPG v1.2.2 (GNU/Linux) | Comment: Finger me for keys | | iQCVAwUBQpSzhIqHRg3pndX9AQErrQQAvBGhDcpGVMoH9DoCjeE3PgN+eVhhEKI5 | RVH/GdnYImtTA1RL+MjEvgk49cajuvb62fJwI4XzBGsIVGG9jj6QIubVaGdhAazo | zJfAlGZR/dBFUzo97Kqi/vf3m81BIHo7TyN622C7bYj+EPQfGgjbgk45/3NMyaw3 | N5fcT//7gvs= | =i+lw | -END PGP SIGNATURE- | - | 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] MPLS
On Fri, Jun 10, 2005 at 12:07:44PM +0200, Paolo Lucente wrote: | Hello, | i wish to share (hoping it might be found of interest) a patch i've | written for personal use; it merges fine against the daily tarball of | 09-06-2005 (yesterday). It aims to enhance the actual support for MPLS | label hierarchies in a BPF filter. | | Actually it's not possible, for example, to match a label ignoring the | content of the upper ones. The patch allows to write an expression like | 'mpls 1:10 and mpls 3:1024' which checks whether the 2nd label has | value 10 and the 4th has value 1024 (the top label is meant to be | 0). thats does not seem to be correct - i.e. ./tcpdump -ndr ppp.pcap "mpls && mpls && mpls 10" reading from file ppp.pcap, link-type PPP (PPP) (000) ldh [2] (001) jeq #0x281 jt 2jf 6 (002) ld [12] (003) and #0xf000 (004) jeq #0x186a jt 5jf 6 (005) ret #1500 (006) ret #0 does not compare the MPLS label at position 8 [middle label] and does not compare the MPLS label at potition 4 [top label] but does compare the MPLS label at position 12 [bottom label]; --- there is one minor nit with the current code - in case of stacked MPLS labels it does not verify if the Bottom of Stack bit of the previous label is cleared; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] septel support on libpcap
On Thu, Jun 23, 2005 at 10:39:59PM +0300, gilbert HOYEK wrote: [ ... ] | Note: dissectors for ss7 protocols do not exist in tcpdump , so anyone who | would use it with tcpdump must add these dissectors.Instead they do exsit | in Ethereal. gilbert, call for you to write one ;-) - let me know if you need help; - /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] print GRE over IPv6 packets
On Sat, Jul 02, 2005 at 11:45:56AM +0200, Gert Doering wrote: | Hi, | | I'm working on adding Cisco-compatible GRE over IPv6 tunneling, and | the following patch to tcpdump makes tcpdump dissect Cisco-encapsulated | GRE-over-IPv6 packets. | | The current GRE RFC (rfc2784) neither documents IPv6-over-GRE nor | GRE-over-IPv6, and there are no IETF drafts either - so it's hard to | find a normative reference. | | "It works, though" - and is simple enough to look "obviously correct". | | Hannes, could you check it in, please? | | gert have added it along with support for RSVP over IPv6; - /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] IP header filtering of MPLS packets
sven, you need to specify the keyword "mpls" in order to shift the offsets to match IP addresses; i.e. tcpdump -n -i eth1 -O -vv "mpls && src net 195.113.0.0/16" pls turn off the optimizer [-O flag] as without tcpdump returns the error "tcpdump: expression rejects all packets"; guy, do you have any idea what cause the optimizer to dead-optimize this expression ? /hannes On Fri, Jul 08, 2005 at 12:17:17PM +0200, Sven Ubik wrote: | Hi All, | | I need to monitor a link with MPLS enabled. Is it possible to filter | MPLS packets based on IP header fields? IP header is after MPLS header | and tcpdump correctly recognizes that: | | tcpdump -n -i eth1 -vv ether proto 0x8847 | | 12:01:33.175076 MPLS (label 39, exp 0, [S], ttl 255) | IP (tos 0x0, ttl 60, id 10954, offset 0, flags [DF], length: 1500) | 147.32.127.222.80 > 82.57.120.192.11472: . 4380:5840(1460) ack 1 win 1728 | | but when I add filter for say source IP address, tcpdump fails: | | tcpdump -n -i eth1 -vv ether proto 0x8847 and src net 195.113.0.0/16 | | eth1 not found (did you install the module?), down or already in use. | Using Linux packet capture on eth1 | tcpdump: WARNING: setsockopt: Protocol not available | tcpdump: WARNING: eth1: no IPv4 address assigned | tcpdump: expression rejects all packets | | when I try just to filter source IP addresses without requesting packets | with MPLS headers, it works, but tcpdump returns only packets that did | not have an MPLS header (multicast and a few other special packets of | inter-router communication): | | tcpdump -n -i eth1 -vv src net 195.113.0.0/16 | | 12:13:32.240979 IP 195.113.69.53 > 224.0.0.13: pim v2 Join/Prune | upstream-neighbor=195.113.69.54 groups=1 holdtime=3m30s (group0: 233.10.47.22 join=1 | 194.160.9.2(S) prune=0) | | Thanks. | | Regards, | | Sven Ubik | CESNET - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] IP header filtering of MPLS packets
seven, sorry brain-fart; the optimizer does the right thing; the problem is that the bpf_code generation in conjunction with the keyword "mpls" is broken; i'll have a a look at that; /hannes -- sven, you need to specify the keyword "mpls" in order to shift the offsets to match IP addresses; i.e. tcpdump -n -i eth1 -O -vv "mpls && src net 195.113.0.0/16" pls turn off the optimizer [-O flag] as without tcpdump returns the error "tcpdump: expression rejects all packets"; guy, do you have any idea what cause the optimizer to dead-optimize this expression ? /hannes On Fri, Jul 08, 2005 at 12:17:17PM +0200, Sven Ubik wrote: | Hi All, | | I need to monitor a link with MPLS enabled. Is it possible to filter | MPLS packets based on IP header fields? IP header is after MPLS header | and tcpdump correctly recognizes that: | | tcpdump -n -i eth1 -vv ether proto 0x8847 | | 12:01:33.175076 MPLS (label 39, exp 0, [S], ttl 255) | IP (tos 0x0, ttl 60, id 10954, offset 0, flags [DF], length: 1500) | 147.32.127.222.80 > 82.57.120.192.11472: . 4380:5840(1460) ack 1 win 1728 | | but when I add filter for say source IP address, tcpdump fails: | | tcpdump -n -i eth1 -vv ether proto 0x8847 and src net 195.113.0.0/16 | | eth1 not found (did you install the module?), down or already in use. | Using Linux packet capture on eth1 | tcpdump: WARNING: setsockopt: Protocol not available | tcpdump: WARNING: eth1: no IPv4 address assigned | tcpdump: expression rejects all packets | | when I try just to filter source IP addresses without requesting packets | with MPLS headers, it works, but tcpdump returns only packets that did | not have an MPLS header (multicast and a few other special packets of | inter-router communication): | | tcpdump -n -i eth1 -vv src net 195.113.0.0/16 | | 12:13:32.240979 IP 195.113.69.53 > 224.0.0.13: pim v2 Join/Prune | upstream-neighbor=195.113.69.54 groups=1 holdtime=3m30s (group0: 233.10.47.22 join=1 | 194.160.9.2(S) prune=0) | | Thanks. | | Regards, | | Sven Ubik | CESNET - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] IP header filtering of MPLS packets
sven, i have just checked in a fix for MPLS code generation into libpcap HEAD and 0_9: --- if we have a MPLS label stack deeper > 1 then generate a match for a cleared bottom-of-stack-bit of the previous MPLS shim header rather than just incrementing the offset; if there is a compined expression of MPLS and IP like e.g. "mpls && ip" | "mpls && ip host" | "mpls && ip src net" then poison the linkoffset to make sure that other code generators do not try to match link-layer protos like Q_ARP, Q_RARP etc. introduce a new function gen_null() that matches against the first nibble of the IP header and matches if the bottom-of-stack bit is set; TODO: IPv6 stuff i.e. gen_host6() etc. -- so tcpdump -nvvi eth1 "mpls && src net 195.113.0.0/16" should work now; /hannes On Fri, Jul 08, 2005 at 12:17:17PM +0200, Sven Ubik wrote: | Hi All, | | I need to monitor a link with MPLS enabled. Is it possible to filter | MPLS packets based on IP header fields? IP header is after MPLS header | and tcpdump correctly recognizes that: | | tcpdump -n -i eth1 -vv ether proto 0x8847 | | 12:01:33.175076 MPLS (label 39, exp 0, [S], ttl 255) | IP (tos 0x0, ttl 60, id 10954, offset 0, flags [DF], length: 1500) | 147.32.127.222.80 > 82.57.120.192.11472: . 4380:5840(1460) ack 1 win 1728 | | but when I add filter for say source IP address, tcpdump fails: | | tcpdump -n -i eth1 -vv ether proto 0x8847 and src net 195.113.0.0/16 | | eth1 not found (did you install the module?), down or already in use. | Using Linux packet capture on eth1 | tcpdump: WARNING: setsockopt: Protocol not available | tcpdump: WARNING: eth1: no IPv4 address assigned | tcpdump: expression rejects all packets | | when I try just to filter source IP addresses without requesting packets | with MPLS headers, it works, but tcpdump returns only packets that did | not have an MPLS header (multicast and a few other special packets of | inter-router communication): | | tcpdump -n -i eth1 -vv src net 195.113.0.0/16 | | 12:13:32.240979 IP 195.113.69.53 > 224.0.0.13: pim v2 Join/Prune | upstream-neighbor=195.113.69.54 groups=1 holdtime=3m30s (group0: 233.10.47.22 join=1 | 194.160.9.2(S) prune=0) | | Thanks. | | Regards, | | Sven Ubik | CESNET | - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] print-slow.c
On Tue, Jul 12, 2005 at 11:10:38PM -0700, Loris Degioanni wrote: | Some genius had the idea of adding a new file (print-slow.c) to the | repository few hours before the x.9.2 release, without at least trying | to recompile on all the platforms. Result: tcpdump 3.9.2 doesn't compile | under Windows (even if it used to compile the night before the release). that was me - guilty; | We already checked in a patch, are there plans for a x.9.3 release? If | yes, could people stop to do breaking commits before it's done? you could help me avoiding those things by writing up a document that describes what files you need on windows to be touched / added; i only test on freebsd and linux; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] Updated time-based dumpfile rotation (against 3.9.1)
will, pls could you re-submit your patch as a unified diff against CVS head; /hannes On Tue, Jul 19, 2005 at 10:29:04PM -0700, Will Drewry wrote: | Hi All - | | I've recently rewritten the patch I submitted last November which | allows tcpdump to automagically rotate dump files based on some time | in seconds specified by the -G argument. I rewrote the patch to have | less impact on the tcpdump code in hopes that this patch will be | better received. The patch can be found below: | | https://sourceforge.net/tracker/index.php?func=detail&aid=1066046&group_id=53066&atid=469575 | | Any questions, comments, suggestions, fixes, etc are appreciated! I | would love to see this functionality go upstream some day, and I'm | more than willing to do what's needed to get it into shape. | | Thanks! | will - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] misprinting of GRE tunneled packets on NetBSD Sparc64
On Tue, Jul 26, 2005 at 04:34:16PM +0200, Gert Doering wrote: | Hi, | | I'm sure this is going to be difficult to diagnose - so I need some | help to figure out where to start. | | Setup: | NetBSD -current (3.99.7) on Sparc64. | IPv6-over-GRE-over-IPv4 tunneling | tcpdump HEAD from CVS | system libpcap | | $ ./tcpdump -V | tcpdump version 3.9-PRE-CVS | libpcap version 0.8.3 | | (this is because using libpcap-3.9-PRE-CVS makes tcpdump core dump, for | whatever reason??!) can i have the core file for inspection, pls ? | | Sniffing on the LAN for "host " gives: | | tcpdump: verbose output suppressed, use -v or -vv for full protocol decode | listening on hme0, link-type EN10MB (Ethernet), capture size 65535 bytes | 16:14:04.595494 IP 172.30.1.153 > 193.149.44.208: GREv0, length 60: IP6 2001:608:8003::1 > 2001:608:4::3: ICMP6, echo request, seq 0, length 16 | 16:14:04.700420 IP 193.149.44.208 > 172.30.1.153: GREv0, length 60: IP6 2001:608:4::3 > 2001:608:8003::1: ICMP6, echo reply, seq 0, length 16 | 16:14:05.595419 IP 172.30.1.153 > 193.149.44.208: GREv0, length 60: IP6 2001:608:8003::1 > 2001:608:4::3: ICMP6, echo request, seq 1, length 16 | 16:14:05.746677 IP 193.149.44.208 > 172.30.1.153: GREv0, length 60: IP6 2001:608:4::3 > 2001:608:8003::1: ICMP6, echo reply, seq 1, length 16 | | -> perfect, this is exactly how it should be. | | | Sniffing on the tunnel interface (gre0) gives: | | [EMAIL PROTECTED]:/home/gert/cdp/tcpdump$ SU ./tcpdump -n -s0 -i gre0 | tcpdump: WARNING: gre0: no IPv4 address assigned | tcpdump: verbose output suppressed, use -v or -vv for full protocol decode | listening on gre0, link-type NULL (BSD loopback), capture size 65535 bytes | 16:16:28.835438 IP6 2001:608:8003::1 > 2001:608:4::3: ICMP6, echo request, seq 0, length 16 | 16:16:28.937041 IP6 , wrong link-layer encapsulationbad-hlen 0 | 16:16:29.835377 IP6 2001:608:8003::1 > 2001:608:4::3: ICMP6, echo request, seq 1, length 16 | 16:16:29.947910 IP6 , wrong link-layer encapsulationbad-hlen 0 | | -> which is weird. Outgoing packets are properly decoded, incoming | packets are not properly displayed. | | With "-X", the packets look like this: | | 16:32:36.925380 IP6 2001:608:8003::1 > 2001:608:4::3: ICMP6, echo request, seq 1, length 16 | 0x: 6000 0010 3a40 2001 0608 8003 `.:@ | 0x0010: 0001 2001 0608 0004 | 0x0020: 0003 8000 1c21 ecc8 0001 ...! | 0x0030: 42e6 4984 000e 1e34 B.I4 | 16:32:37.024946 IP6 , wrong link-layer encapsulationbad-hlen 0 | 0x: 6000 0010 3a3d 2001 0608 0004 `.:= | 0x0010: 0003 2001 0608 8003 | 0x0020: 0001 8100 1b21 ecc8 0001 ...! | 0x0030: 42e6 4984 000e 1e34 B.I4 | | (The pinging itself works fine, so the issue is not "corrupted packets" | but more "corrupted signalling kernel->libpcap" or such). | | | What could be causing this effect? How can I narrow this down, and | get it fixed / fix it? can you send me the .pcap of the gre tunnel and i have a look; i am anticipating a kernel issue - typically we get this error message when the kernel tells us that the payload is IPv4 [and in reality is IPv6] - that makes the IPv4 printer bark; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 0.9.4/3.9.4 release?
Michael Richardson wrote: -BEGIN PGP SIGNED MESSAGE- "Guy" == Guy Harris <[EMAIL PROTECTED]> writes: Guy> I've checked in some libpcap fixes for HP-UX and Mike Kershaw's Guy> support for radiotap in Linux, and Hannes has checked in some Guy> changes in both libpcap and tcpdump for additional Juniper Guy> link-layer types. i have not yet done the printers for those (but that should be straightforward) can you give me the weekend to complete those, pls ? Guy> Unless there are some other fixes in the pipeline, or some Guy> tcpdump vulnerabilities not yet fixed, this might be a good Guy> time to do 0.9.4 and 3.9.4 releases (which, unlike 0.9.3 and Guy> 3.9.3, will identify themselves correctly). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] DCCP - print all ACKs
checked into HEAD;
who is going to receive credit/blame for this patch ?
andrea, ian or both ?
tx, /hannes
Ian McDonald wrote:
Hi there folks,
Andrea Bittau picked up we weren't displaying ACKs for close packets
and provided a preliminary patch.
I've gone through the spec and reworked the patch slightly and it now
prints for all relevant packets.
This patch is against latest weekly CVS of tcpdump - 2005.10.03
Can this please be added to tcpdump?
Regards,
Ian
--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand
diff -uprN -X dontdiff tcpdump-2005.10.03/print-dccp.c dccpdump/print-dccp.c
--- tcpdump-2005.10.03/print-dccp.c 2005-09-20 18:25:20.0 +1200
+++ dccpdump/print-dccp.c 2005-11-04 12:06:48.0 +1300
@@ -155,25 +155,32 @@ static u_int64_t dccp_seqno(const struct
return seqno;
}
-static u_int64_t dccp_ack_no(const struct dccp_hdr *dh,
- const struct dccp_hdr_ack_bits *dh_ack)
+static inline unsigned int dccp_basic_hdr_len(const struct dccp_hdr *dh)
{
+ return sizeof(*dh) + (DCCPH_X(dh) ? sizeof(struct dccp_hdr_ext) : 0);
+}
+
+static void dccp_print_ack_no(const u_char *bp)
+{
+ const struct dccp_hdr *dh = (const struct dccp_hdr *)bp;
+ const struct dccp_hdr_ack_bits *dh_ack =
+ (struct dccp_hdr_ack_bits *)(bp + dccp_basic_hdr_len(dh));
+
+ TCHECK2(*dh_ack,4);
u_int32_t ack_high = DCCPH_ACK(dh_ack);
u_int64_t ackno = EXTRACT_24BITS(&ack_high) & 0xFF;
if (DCCPH_X(dh) != 0) {
+ TCHECK2(*dh_ack,8);
u_int32_t ack_low = dh_ack->dccph_ack_nr_low;
ackno &= 0x00; /* clear reserved field */
ackno = (ackno << 32) + EXTRACT_32BITS(&ack_low);
}
- return ackno;
-}
-
-static inline unsigned int dccp_basic_hdr_len(const struct dccp_hdr *dh)
-{
- return sizeof(*dh) + (DCCPH_X(dh) ? sizeof(struct dccp_hdr_ext) : 0);
+ (void)printf("(ack=%" PRIu64 ") ", ackno);
+trunc:
+ return;
}
static inline unsigned int dccp_packet_hdr_len(const u_int8_t type)
@@ -309,9 +316,7 @@ void dccp_print(const u_char *bp, const
struct dccp_hdr_response *dhr =
(struct dccp_hdr_response *)(bp +
dccp_basic_hdr_len(dh));
TCHECK(*dhr);
- (void)printf("response (service=%d, ack=%" PRIu64 ") ",
-dhr->dccph_resp_service,
-dccp_ack_no(dh,&(dhr->dccph_resp_ack)));
+ (void)printf("response (service=%d) ", dhr->dccph_resp_service);
extlen += 12;
break;
}
@@ -319,20 +324,12 @@ void dccp_print(const u_char *bp, const
(void)printf("data ");
break;
case DCCP_PKT_ACK: {
- struct dccp_hdr_ack_bits *dha =
- (struct dccp_hdr_ack_bits *)(bp +
dccp_basic_hdr_len(dh));
- TCHECK(*dha);
- (void)printf("ack (ack=%" PRIu64 ") ",
-dccp_ack_no(dh,dha));
+ (void)printf("ack ");
extlen += 8;
break;
}
case DCCP_PKT_DATAACK: {
- struct dccp_hdr_ack_bits *dha =
- (struct dccp_hdr_ack_bits *)(bp +
dccp_basic_hdr_len(dh));
- TCHECK(*dha);
- (void)printf("dataack (ack=%" PRIu64 ") ",
-dccp_ack_no(dh,dha));
+ (void)printf("dataack ");
extlen += 8;
break;
}
@@ -366,6 +363,10 @@ void dccp_print(const u_char *bp, const
break;
}
+ if ((DCCPH_TYPE(dh) != DCCP_PKT_DATA) &&
+ (DCCPH_TYPE(dh) != DCCP_PKT_REQUEST))
+ dccp_print_ack_no(bp);
+
if (vflag < 2)
return;
-
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] [PATCH] DCCP - print all ACKs
Ian is already on the blamelist (aka CREDITS) - so i just have added Andrea; tx again for your submission; /hannes Ian McDonald wrote: On 04/11/05, Hannes Gredler <[EMAIL PROTECTED]> wrote: checked into HEAD; who is going to receive credit/blame for this patch ? andrea, ian or both ? Both -- Ian McDonald http://wand.net.nz/~iam4 WAND Network Research Group University of Waikato New Zealand - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Paquets smaller than 64 bytes
David Rosal wrote: [ ... ] But what's is very strange is that everytime I make a capture session with tcpdump I get *many* packets of 60 bytes that are not originated in my own machine nor are them sent to it. Here's an example of the output of tcpdump: $ tcpdump -c5 '(host not 193.145.45.234 && len < 64)' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 14:23:12.896879 802.1d config 802c.00:08:21:23:f0:80.800f root 8000.00:07:0d:52:f4:2c pathcost 8 age 2 max 20 hello 2 fdelay 15 14:23:13.207367 arp who-has efpc266.upf.es tell telecom.upf.es 14:23:13.207963 arp who-has efpc148.upf.es tell telecom.upf.es 14:23:14.895948 802.1d config 802c.00:08:21:23:f0:80.800f root 8000.00:07:0d:52:f4:2c pathcost 8 age 2 max 20 hello 2 fdelay 15 14:23:16.895997 802.1d config 802c.00:08:21:23:f0:80.800f root 8000.00:07:0d:52:f4:2c pathcost 8 age 2 max 20 hello 2 fdelay 15 $ Could anyone explain me the reason for that behaviour? the example packets you have provided are all broadcasts which by definition should be seen by all hosts on your local LAN. /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap for PPP raw data problem
libpcap does not do what you want it to do ... however you may want to look at the text2pcap utility that is bundled with ethereal. /hannes BinaryChen(TP/SH) wrote: Hi, I have captured some raw PPP data from serial driver, and I want use libpcap to convert to pcap file format so the ethereal can help me do some analyze. Can anyone provide some sample or hints to me? Thanks a lot. Binary Chen - 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] gettimeofday() on Win32
would'nt it make sense to guard your private gettimeofday() function
with #if defined(_MSC_VER) || defined(_MSC_EXTENSIONS) || defined(__WATCOMC__)
/hannes
Gisle Vanem wrote:
The recent (?) -G option requires gettimeofday() which isn't available
on Win32. Attached is a patch to util.c which adds this function.
--gv
--- tcpdump-2005.12.03/util.cThu Jun 16 00:19:38 2005
+++ util.cSat Dec 03 17:01:05 2005
@@ -526,3 +526,44 @@
else
printf("\\%03o", ch);
}
+
+#ifdef WIN32
+/*
+ * Number of micro-seconds between the beginning of the Windows epoch
+ * (Jan. 1, 1601) and the Unix epoch (Jan. 1, 1970).
+ *
+ * This assumes all Win32 compilers have 64-bit support.
+ */
+#if defined(_MSC_VER) || defined(_MSC_EXTENSIONS) || defined(__WATCOMC__)
+ #define DELTA_EPOCH_IN_USEC 116444736Ui64
+#else
+ #define DELTA_EPOCH_IN_USEC 116444736ULL
+#endif
+
+static u_int64_t filetime_to_unix_epoch (const FILETIME *ft)
+{
+u_int64_t res = (u_int64_t) ft->dwHighDateTime << 32;
+
+res |= ft->dwLowDateTime;
+res /= 10; /* from 100 nano-sec periods to usec */
+res -= DELTA_EPOCH_IN_USEC; /* from Win epoch to Unix epoch */
+return (res);
+}
+
+int gettimeofday (struct timeval *tv, void *tz _U_)
+{
+FILETIME ft;
+u_int64_t tim;
+
+if (!tv) {
+errno = EINVAL;
+return (-1);
+}
+GetSystemTimeAsFileTime (&ft);
+tim = filetime_to_unix_epoch (&ft);
+tv->tv_sec = (long) (tim / 100L);
+tv->tv_usec = (long) (tim % 100L);
+return (0);
+}
+#endif
-
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] gettimeofday() on Win32
pls ignore prev. comment -> brain fart - checked in your patch - /hannes
Gisle Vanem wrote:
The recent (?) -G option requires gettimeofday() which isn't available
on Win32. Attached is a patch to util.c which adds this function.
--gv
--- tcpdump-2005.12.03/util.cThu Jun 16 00:19:38 2005
+++ util.cSat Dec 03 17:01:05 2005
@@ -526,3 +526,44 @@
else
printf("\\%03o", ch);
}
+
+#ifdef WIN32
+/*
+ * Number of micro-seconds between the beginning of the Windows epoch
+ * (Jan. 1, 1601) and the Unix epoch (Jan. 1, 1970).
+ *
+ * This assumes all Win32 compilers have 64-bit support.
+ */
+#if defined(_MSC_VER) || defined(_MSC_EXTENSIONS) || defined(__WATCOMC__)
+ #define DELTA_EPOCH_IN_USEC 116444736Ui64
+#else
+ #define DELTA_EPOCH_IN_USEC 116444736ULL
+#endif
+
+static u_int64_t filetime_to_unix_epoch (const FILETIME *ft)
+{
+u_int64_t res = (u_int64_t) ft->dwHighDateTime << 32;
+
+res |= ft->dwLowDateTime;
+res /= 10; /* from 100 nano-sec periods to usec */
+res -= DELTA_EPOCH_IN_USEC; /* from Win epoch to Unix epoch */
+return (res);
+}
+
+int gettimeofday (struct timeval *tv, void *tz _U_)
+{
+FILETIME ft;
+u_int64_t tim;
+
+if (!tv) {
+errno = EINVAL;
+return (-1);
+}
+GetSystemTimeAsFileTime (&ft);
+tim = filetime_to_unix_epoch (&ft);
+tv->tv_sec = (long) (tim / 100L);
+tv->tv_usec = (long) (tim % 100L);
+return (0);
+}
+#endif
-
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.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
:Re: [tcpdump-workers] libpcap for PPP raw data problem
from the manpage: NAME text2pcap - Generate a capture file from an ASCII hexdump of packets SYNOPSYS text2pcap [ -h ] [ -d ] [ -q ] [ -o hex|oct ] [ -l typenum ] [ -e l3pid ] [ -i proto ] [ -m max-packet ] [ -u srcport,destport ] [ -T srcport,destport ] [ -s srcport,destport,tag ] [ -S srcport,destport,ppi ] [ -t timefmt ] infile outfile DESCRIPTION Text2pcap is a program that reads in an ASCII hex dump and writes the data described into a libpcap-style cap- ture file. text2pcap can read hexdumps with multiple packets in them, and build a capture file of multiple packets. text2pcap is also capable of generating dummy Ethernet, IP and UDP, TCP, or SCTP headers, in order to build fully processable packet dumps from hexdumps of application-level data only. [ ... ] /hannes BinaryChen(TP/SH) wrote: Hi Hannes, Have you used the text2pcap? What function does it provide? In its man page, it support change hexdump result to pcap format, but in ASCII format. I wonder to know what is hexdump'ed? The raw data or ... Thanks a lot. Binary Chen *From:* [EMAIL PROTECTED] ´ú±í Hannes Gredler *Sent:* 2005-12-5 (ÐÇÆÚÒ») 16:07 *To:* tcpdump-workers@lists.tcpdump.org *Subject:* Spam:Re: [tcpdump-workers] libpcap for PPP raw data problem libpcap does not do what you want it to do ... however you may want to look at the text2pcap utility that is bundled with ethereal. /hannes BinaryChen(TP/SH) wrote: > Hi, > > I have captured some raw PPP data from serial driver, and I want use libpcap to convert to pcap file format so the ethereal can help me do some analyze. Can anyone provide some sample or hints to me? > > Thanks a lot. > > Binary Chen > - > 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. - 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] timestamp difference since first packet under
could you provide me a pointer to the openBSD source tree containing the -t modification then i can see if we can check this in; /hannes nero one wrote: Hello. OpenBSD added the -t option which, from what I understand, a very similar output to tethereal's default timestamp "Add -t option (timestamp difference since the first packet)". How can I get the same functionality under linux? I can't find a tarball anywhere that'll give me that. My problem is this. I'm tcpdumping on two systems (A & B) and C on a tapped line. [A]-+-[B] | \ | network tap | [C] without -t (regular output) .. if i'm throwing lots of juice from system A to system to system B so that I can see if [C] is capturing at the exact same time as [B] A) need to set up NTP B) still need to take into account any type of discepancy in miliseconds between system B & C when comparing dumps so for instance .. if B sees the packet at .398348 and C sees it at .398350, does that mean that it took longer to get to B than C? Was the system clock off by a few milimiliseconds maybe? In scenario B) (-t) ... the packets start at point 0. and so the actual latency from start to finish can be easily calculated. anyways. feedback on this would be great thanks :) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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] timestamp difference since first packet under
found the openBSD tcpdump tree meanwhile ... have added the desired functionality to HEAD. would you mind checking out if it fits your needs ? /hannes nero one wrote: Hello. OpenBSD added the -t option which, from what I understand, a very similar output to tethereal's default timestamp "Add -t option (timestamp difference since the first packet)". How can I get the same functionality under linux? I can't find a tarball anywhere that'll give me that. My problem is this. I'm tcpdumping on two systems (A & B) and C on a tapped line. [A]-+-[B] | \ | network tap | [C] without -t (regular output) .. if i'm throwing lots of juice from system A to system to system B so that I can see if [C] is capturing at the exact same time as [B] A) need to set up NTP B) still need to take into account any type of discepancy in miliseconds between system B & C when comparing dumps so for instance .. if B sees the packet at .398348 and C sees it at .398350, does that mean that it took longer to get to B than C? Was the system clock off by a few milimiliseconds maybe? In scenario B) (-t) ... the packets start at point 0. and so the actual latency from start to finish can be easily calculated. anyways. feedback on this would be great thanks :) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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] timestamp difference since first packet under
Guy Harris wrote: Hannes Gredler wrote: found the openBSD tcpdump tree meanwhile ... have added the desired functionality to HEAD. Do we want relative time stamps (-ttt, for secs/usecs since previous packet, and -t, for secs/usecs since first packet) to be printed as HH:MM:SS.UU, or seconds.UU? in the sense of having an indicator wether this is a relative/or absolute timestamp ? The original "-ttt" was, I think, clearly broken, as no decimal point was printed if the delta was less than 1 second, and a space was printed after the decimal point if the delta was >= 1 second, so fixing that is definitely right. OpenBSD prints them as seconds.UU, rather than HH:MM:SS.UU. saw that and i deliberatly decided against it i.e. to print HH:MM:SS.UU as it IMHO makes things easier to read for long-term traces ... /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] timestamp difference since first packet under
nero one wrote: Hannes, Thanks so much for what looks like something promising. Only issue here is that i'm not quite sure what you're talking about when you're saying "added functionality to HEAD". Could you be a bit more explicit or rephrase that perhaps? :) Is HEAD a directory somewhere in the CVS system, or ? HEAD is the head of the CVS tree where we do check in all the fancy and new stuff ;-) if you do an anonmymous CVS checkout and don't specify a branch e.g. tcpdump_3_9 then you'll get the HEAD of the tree ... /hannes Hannes Gredler wrote: found the openBSD tcpdump tree meanwhile ... have added the desired functionality to HEAD. Do we want relative time stamps (-ttt, for secs/usecs since previous packet, and -t, for secs/usecs since first packet) to be printed as HH:MM:SS.UU, or seconds.UU? The original "-ttt" was, I think, clearly broken, as no decimal point was printed if the delta was less than 1 second, and a space was printed after the decimal point if the delta was >= 1 second, so fixing that is definitely right. OpenBSD prints them as seconds.UU, rather than HH:MM:SS.UU. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] timestamp difference since first packet under
I suppose we could get really ambitious and support strftime()-like
formats ("strftime()-like" because, for relative times, you don't have
any date fields, just time fields).
that would be a really nice idea - so we'd have essentially three
distinct -t behaviours
1. print absolute timestamps
2. print relative (prev. packet) timestamps
3. print relative (first packet) timestamps
plus a format code (is there a standard fmt code for usecs ?)
for relative timestamps we'd need to print e.g. the number of months/years
rather than the month/year abbrev itself ...
/hannes
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] testing the list
works fine ... - /hannes Michael Richardson wrote: This is another test of the mailing list. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] error when installling in freeBSD
pls try a "make clean;make" - /hannes PRITHU wrote: Dear all, I was trying to install tcpdump 3.8.3 in freeBSD 5.4, I get the following error - tcpdump.o(.text+0x8f6): In function `main': : undefined reference to `pcap_debug' I have also passsed --enable-yydebug to libpcap's configure script. But it still gives the same error. Any help? Thank You, Pritula Dhungel. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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] error when installling in freeBSD
also .. do you have libpcap installed ? --- pls try a "make clean;make" - /hannes PRITHU wrote: Dear all, I was trying to install tcpdump 3.8.3 in freeBSD 5.4, I get the following error - tcpdump.o(.text+0x8f6): In function `main': : undefined reference to `pcap_debug' I have also passsed --enable-yydebug to libpcap's configure script. But it still gives the same error. Any help? Thank You, Pritula Dhungel. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump -r option
Latha G wrote: Hi all, Thanks for your support till now. I want to clarify few things about the tcpdump -r option I just used tcpdump -w dump.pcap The -r option is used just to read back what we stored using -w option or can we use the dump.pcap file as network and we can apply all options & filters i mean like tcpdump -n -c 1 -r dump.pcap (or) tcpdump -A -r dump.pcap can i apply any filter expression and options on this file... is it ok... since i didn't use any option or filter while capturing it through -w option.. is the output what i get from tcpdump -n -c 1 -r dump.pcap looks same as tcpdump -n -c 1 or any difference is there? there won't be any difference Means what i want to clarify is , Is the behaviour of tcpdump when applied with -r option is same as when it applied on the network directly.. your understanding is correct And one more is, the captured file dump.pcap can i take to any other system and then apply tcpdump , and can i expect the output should be same as that of on my system if both systems are configured with the same timezone, yes. /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] "truncated arp " message while using -s option
Guy Harris wrote: The most recent update to the ARP printing code (which isn't yet in a release) prints "[|ARP]" for all the truncation cases. i took the courtesy of cleaning up the printer recently ... hope i did not break too much ;-) /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] fragmented packets
Luis Del Pino wrote: Hello, i have a question. I am filtering UDP segments by port. In fragmented packets, i only capture the UDP segment and i can't capture the other fragments. My questions are: could the fragments loss? or if a fragment is lost in the network, the UDP segment entirely is it lost?. i'm sorry for my English. UDP port numbers are only contained in the first fragment - and tcpdump does not reassemble fragments that means you will loose all non-zero fragments. /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Missing af.h
af.{c,h} are new files used for AF printing/resolution;
if they would have been committed (blush) they would have been there ...
guy fixed that already ...
/hannes
Gisle Vanem wrote:
This file is needed by print-bgp.c, print-ldp.c and print-rip.c, but
missing
from the tar-ball. Should it be generated by configure? And the FILES list
af.c as well. That's missing too.
BTW. addrtoname.c on Win32 is missing ETHER_ADDR_LEN. A fix:
--- tcpdump-2006.02.25\addrtoname.c Sat Feb 11 21:11:40 2006
+++ addrtoname.cSat Feb 25 17:26:17 2006
@@ -68,6 +68,10 @@
#include "extract.h"
#include "oui.h"
+#ifndef ETHER_ADDR_LEN
+#include "ether.h"
+#endif
+
/*
* hash tables for whatever-to-name translations
*
--gv
-
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] Missing af.h
BTW. addrtoname.c on Win32 is missing ETHER_ADDR_LEN. A fix: --- tcpdump-2006.02.25\addrtoname.c Sat Feb 11 21:11:40 2006 +++ addrtoname.cSat Feb 25 17:26:17 2006 @@ -68,6 +68,10 @@ #include "extract.h" #include "oui.h" +#ifndef ETHER_ADDR_LEN +#include "ether.h" +#endif + tx, committed to head and 3.9 - /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Missing af.h
that was contained in my original file -> fixed; - /hannes Gisle Vanem wrote: "Guy Harris" <[EMAIL PROTECTED]> wrote: No - it, and af.c, should probably be generated from the stuff removed from print-bgp.c. I've checked in versions of af.c and af.h generated that way. netdissect.h isn't atomic; it needs ahead of it (from tcpdump-stdinc.h). Hence: --- tcpdump-2006.02.26\af.c Sat Feb 25 19:42:32 2006 +++ af.cSun Feb 26 16:18:00 2006 @@ -32,6 +32,8 @@ "@(#) $Header: /tcpdump/master/tcpdump/af.c,v 1.1 2006/02/25 20:42:32 guy Exp $ (LBL)"; #endif +#include + #include "netdissect.h" #include "af.h" --gv - 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] tcpdump output format
Latha G wrote: Hi all, I have one question about the output format of tcpdump. How can we know whether the output from the tcpdump is in the correct format? Any file is there to know about the format of the output? there is no central file - very printer controls its own output formay The printing of packets on the standard output is tcpdump's implementation dependent, right? correct - whenever we add/improve a printer the output format is likely to change ;-) Is the the output format will be changed from version to version??? not regularly Then, where can I find the format of the output? ls -l print-*.c like for IP packets the output should be like that. i am afraid there is no such document ... in that way , i want... I got the doubt because.. arp packet once i got is, 13:39:20.680816 arp who-has 172.16.0.136 tell mech_23_28.ac.in and some other time i got is, 13:39:20.680816 arp who-has 172.16.0.136 (Broadcast) tell mech_23_28.ac.in Any small help be appreciated.. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump output format
latha, i fail to understand what your problem is ... what disturbs you with the (broadcast) output i.e. what is wrong with this ? /hannes Latha G wrote: Hi Hanees, Thanks for ur reply... I referred print-arp.c for arp output format..no where i found (Broadcast) is using...but it is appearing on the output...[refer to my first mail] If there is no such information like the output should be printed like this.. then how can we know whether it is a correct output or not.. And one more thing is , Is the tcpdump tested on any platform(OS)? so that i can refer the output on that platform.. My tcpdump version: 3.9.4 On 3/6/06, Hannes Gredler <[EMAIL PROTECTED]> wrote: Latha G wrote: Hi all, I have one question about the output format of tcpdump. How can we know whether the output from the tcpdump is in the correct format? Any file is there to know about the format of the output? there is no central file - very printer controls its own output formay The printing of packets on the standard output is tcpdump's implementation dependent, right? correct - whenever we add/improve a printer the output format is likely to change ;-) Is the the output format will be changed from version to version??? not regularly Then, where can I find the format of the output? ls -l print-*.c like for IP packets the output should be like that. i am afraid there is no such document ... in that way , i want... I got the doubt because.. arp packet once i got is, 13:39:20.680816 arp who-has 172.16.0.136 tell mech_23_28.ac.in and some other time i got is, 13:39:20.680816 arp who-has 172.16.0.136 (Broadcast) tell mech_23_28.ac.in Any small help be appreciated.. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe. -- Thaks & Regards, Latha. - 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] UDP Fragments
luis, see the answer to the same questions answered a few weeks before. bottomline is: tcpdump does not perform fragment reassembly and there is no way to catch the fragments bases on port numbers. /hannes Luis Del Pino wrote: Hi, I'm Luis del Pino, What filter could I use to capture UDP datagrams and its fragments? I have this filter "dst 192.168.0.120 and (udp dst port 10005 or udp dst port 10006 or udp dst port 10007)" but it doesn't capture the fragments. I only want capture its fragments and not capture all IP datagrams. i have thought to use the fields, flag and fragment offset in the IP datagram. Thanks - 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] Checksum
sure - it could be that the data got corrupted by transit nodes; Luis Del Pino wrote: When I capture an UDP datagram from a well-known source, Could the checksum be incorrect? do I have to calculate it? or How Could I ask other entity about it? Thanks - 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] How to set snaplen for tcpdump
a quick look into the man pages usually helps a lot ;-) --- NAME tcpdump - dump traffic on a network SYNOPSIS tcpdump [ -AdDeflLnNOpqRStuUvxX ] [ -c count ] [ -C file_size ] [ -F file ] [ -i interface ] [ -m module ] [ -M secret ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ -W filecount ] [ -E [EMAIL PROTECTED] algo:secret,... ] [ -G rotate_seconds ] [ -y datalinktype ] [ -Z user ] [ expression ] --- [EMAIL PROTECTED] wrote: Hi, Default snaplen value for tcpdump is 96 bytes. I need to change the snaplen value. How to set it. What's the command for that. If any one has any idea, please pass it on. Regards, Santosh The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com- 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] [PATCH] compress savefiles after each rotation
checked in - tx for your submission; - /hannes Sebastien Raveau wrote: Hello everybody, I am submitting this patch for tcpdump that adds the -z flag (to be used in conjunction with -C or -G) which can be used to specify a command tcpdump should execute on each savefile after it's been rotated. For example, running: tcpdump -G 3600 -z bzip2 -w "capture%Y%m%d%H%M%S.pcap" will make tcpdump close its current savefile and open a new one every hour, continue dumping packets in the new savefile while bzip2 compresses (with minimum priority so that this does not disturb the capture) the previous savefile and renames it to something like capture20060312153936.pcap.bz2 This might sound like a crazy idea, but check it, sometimes the size of compressed savefiles is down to 30% of the size of original savefiles! :-) It has been thoroughly tested on Linux and should work on all Unices as I always pay attention to writing code that is compliant with the Single UNIX Specification, but since I don't use Windows, I don't know if this patch might break Windows compatibility or not... Could somebody please check that for me? Kind regards, diff -ur tcpdump-2006.03.12/CREDITS tcpdump/CREDITS --- tcpdump-2006.03.12/CREDITS 2006-02-03 09:32:39.0 +0100 +++ tcpdump/CREDITS 2006-03-12 14:59:10.0 +0100 @@ -123,6 +123,7 @@ Sami Farin <[EMAIL PROTECTED]> Scott Rose <[EMAIL PROTECTED]> Sebastian Krahmer <[EMAIL PROTECTED]> + Sebastien Raveau<[EMAIL PROTECTED]> Sebastien Vincent <[EMAIL PROTECTED]> Seth Webster<[EMAIL PROTECTED]> Shinsuke Suzuki <[EMAIL PROTECTED]> Only in tcpdump: Makefile Only in tcpdump: addrtoname.o Only in tcpdump: af.o Only in tcpdump: checksum.o Only in tcpdump: config.h Only in tcpdump: config.log Only in tcpdump: config.status Only in tcpdump: cpack.o Only in tcpdump: gmpls.o Only in tcpdump: gmt2local.o Only in tcpdump: ipproto.o Only in tcpdump: l2vpn.o Only in tcpdump: machdep.o Only in tcpdump: nlpid.o Only in tcpdump: oui.o Only in tcpdump: parsenfsfh.o Only in tcpdump: pcap_dump_ftell.o Only in tcpdump: print-802_11.o Only in tcpdump: print-ah.o Only in tcpdump: print-aodv.o Only in tcpdump: print-ap1394.o Only in tcpdump: print-arcnet.o Only in tcpdump: print-arp.o Only in tcpdump: print-ascii.o Only in tcpdump: print-atalk.o Only in tcpdump: print-atm.o Only in tcpdump: print-beep.o Only in tcpdump: print-bfd.o Only in tcpdump: print-bgp.o Only in tcpdump: print-bootp.o Only in tcpdump: print-cdp.o Only in tcpdump: print-chdlc.o Only in tcpdump: print-cip.o Only in tcpdump: print-cnfp.o Only in tcpdump: print-dccp.o Only in tcpdump: print-decnet.o Only in tcpdump: print-domain.o Only in tcpdump: print-dvmrp.o Only in tcpdump: print-eap.o Only in tcpdump: print-egp.o Only in tcpdump: print-eigrp.o Only in tcpdump: print-enc.o Only in tcpdump: print-esp.o Only in tcpdump: print-ether.o Only in tcpdump: print-fddi.o Only in tcpdump: print-fr.o Only in tcpdump: print-gre.o Only in tcpdump: print-hsrp.o Only in tcpdump: print-icmp.o Only in tcpdump: print-igmp.o Only in tcpdump: print-igrp.o Only in tcpdump: print-ip.o Only in tcpdump: print-ipcomp.o Only in tcpdump: print-ipfc.o Only in tcpdump: print-ipx.o Only in tcpdump: print-isakmp.o Only in tcpdump: print-isoclns.o Only in tcpdump: print-juniper.o Only in tcpdump: print-krb.o Only in tcpdump: print-l2tp.o Only in tcpdump: print-lane.o Only in tcpdump: print-ldp.o Only in tcpdump: print-llc.o Only in tcpdump: print-lmp.o Only in tcpdump: print-lspping.o Only in tcpdump: print-lwres.o Only in tcpdump: print-mobile.o Only in tcpdump: print-mpcp.o Only in tcpdump: print-mpls.o Only in tcpdump: print-msdp.o Only in tcpdump: print-nfs.o Only in tcpdump: print-ntp.o Only in tcpdump: print-null.o Only in tcpdump: print-ospf.o Only in tcpdump: print-pflog.o Only in tcpdump: print-pgm.o Only in tcpdump: print-pim.o Only in tcpdump: print-ppp.o Only in tcpdump: print-pppoe.o Only in tcpdump: print-pptp.o Only in tcpdump: print-radius.o Only in tcpdump: print-raw.o Only in tcpdump: print-rip.o Only in tcpdump: print-rsvp.o Only in tcpdump: print-rx.o Only in tcpdump: print-sctp.o Only in tcpdump: print-sip.o Only in tcpdump: print-sl.o Only in tcpdump: print-sll.o Only in tcpdump: print-slow.o Only in tcpdump: print-smb.o Only in tcpdump: print-snmp.o Only in tcpdump: print-stp.o Only in tcpdump: print-sunatm.o Only in tcpdump: print-sunrpc.o Only in tcpdump: print-symantec.o Only in tcpdump: print-syslog.o Only in tcpdump: print-tcp.o Only in tcpdump: print-telnet.o Only in tcpdump: print-tftp.o Only in tcpdump: print-timed.o Only in tcpdump: print-token.o Only in tcpdump: print-udp.o Only in tcpdump: print-vjc.o Only in tcpdump: print-vqp.o Only in tcpdump: print-vrrp.o
Re: [tcpdump-workers] A broken filter...
Dan Joumaa wrote: Hello, I am trying to capture all ethernet packets with the source host's first 3 octets being 00, 09, and bf. It was suggested that I used this filter: "ether[0] == 0x00 && ether[1] == 0x09 && ether[2] == 0xbf." When packets are sent that should match, nothing comes through. When I remove the filter, I'm able to receive the packets, along with every other packet. What's wrong with my filter? perhaps the filter is alright and the data is wrong ;-) -> i.e. an idea that come sinto mind is that the packets come in using 802.1Q (VLAN) encaps ... can you provide some more information about your capturing interface ? /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] how to construct tcpdump readable packets
latha, you may want to check the text2pcap utility that comes along with ethereal for learning about conversion to a libpcap readable format. /hannes Latha G wrote: Hi all, Is there any way to construct manually a tcpdump readable packet? As we know the header structres, we can fill those header information and put it in a string(packet).. then how to convert this packet to a raw packet such that it can be read by tcpdump? Thanks in advance. -- Regards, Latha. - 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] Assumptions needed to get the same tcpdump
if your DNS is configured correct on both systems and you don't do any site local private adressing then you should get the identical output on both systems - if you specifiy the -n flag then tcpdump does not attempt to resolve names, you should be fine i.e. identical output irrespective how broken your DNS is. /hannes Latha G wrote: Hi all, Cann't we expect the output of tcpdump on different systems for the same input file to be same? I am not getting the same output, in the sense it was differencing at the hostnames..I suppose the problem might be DNS lookups, one was using and the other one not. Whether the both systems has to be DNS enabled or disabled? Is this assumption is needed to get the same output? Like wise , are there any other assumptions ? or it is impossible to get the same output on different systems? Thanks in advance. -- Regards, Latha. - 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] what is the flag -c mean
the -c flag (c = count) means that capturing is stopped after packets ... /hannes Lan Qing wrote: hello, I'm of tcpdump,and i got the fllowing words while i'm reading the tcpdump man page " Tcpdump will, if not run with the -c flag, continue capturing packets until it is interrupted by a SIGINT signal or a SIGTERM sig-nal ; if run with the -c flag, it will capture packets until it is interrupted by a SIGINT or SIGTERM signal or the specified number of packets have been processed." it says a lot about -c flag,but it seems like -c flag will not work here(it is the same using it or not using it). Can someone explan that for me. thank you for any help. - 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] about struct in_addr
what is the point ? - the storage space is the same ...
Lan Qing wrote:
hello,
I read the fllowing words in the c header file
"
/* Internet address. */
typedef uint32_t in_addr_t;
struct in_addr
{
in_addr_t s_addr;
};"
the struct in_addr have only one variable in it, is there any necessary to
define a struct like that?
why not use "typedef in_addr_t in_addr;" directly?
thank you!
-
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] Filtering based on multiple IP address.
1. Is there is a limit in the length of filter string afaik 256 BPF instructions 2. What will be the performance impact because of having a huge filter string. linear performance impact 3. Will PCAP automatically reduce the the filter string for performance. not for a chain of explicit hostanmes 4. Else, can some one provide with a logic to reduce the filter string (from a lot of host address to a simple net address if possible). you way wnat to have a look what BPF filtercode your expression produces to get an idea about the processing complexity. (simply run tcpdump with the -d flag and you'll see the BPF filtercode as executed by BPF capable kernels). [EMAIL PROTECTED] ~ $ tcpdump -ndi eth0 "ip && src host 192.168.1.1" (000) ldh [12] (001) jeq #0x800 jt 2jf 5 (002) ld [26] (003) jeq #0xc0a80101 jt 4jf 5 (004) ret #96 (005) ret #0 /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] compiling problem
zubin, unless you post qualified information - for example the config.log file i fear nobody's crystal ball on the list is clear enough to provide an answer your question. /hannes [EMAIL PROTECTED] wrote: Hi guys, I havent heard from anyone and I really need solution to this problem. I was able to successfully create makefile. When I tried to run the 'make' command with this option in the makefile #CCOPT = -O2 CCOPT = -g I get this error print-dhcp6.o:./print-dhcp6.c:445: more undefined references to `__ntohs' follow print-dhcp6.o: In function `dhcp6opt_print': ./print-dhcp6.c:465: undefined reference to `__ntohl' ./print-dhcp6.c:469: undefined reference to `__ntohl' ./print-dhcp6.c:489: undefined reference to `__ntohl' ./print-dhcp6.c:551: undefined reference to `__ntohl' ./print-dhcp6.c:563: undefined reference to `__ntohs' ./print-dhcp6.c:573: undefined reference to `__ntohl' ./print-dhcp6.c:574: undefined reference to `__ntohl' ./print-dhcp6.c:575: undefined reference to `__ntohl' ./print-dhcp6.c:596: undefined reference to `__ntohl' ./print-dhcp6.c:598: undefined reference to `__ntohl' I wanted to use -g so later I can use debuuger like gdb, ddd to debug the program. I would really appreciate help on this matter. Thanks for your consideration, zubin This message was sent using IMP, the Internet Messaging Program. - 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] Verbose output of tcpdump on protocols of different
mikhail, what you are suggesting makes sense and you are welcome to submit a patch ;-) /hannes Mikhail Manuylov wrote: Hello, I need to parse output of tcpdump printing contents of snmp packets and insert to database. First time I thought that output can be explained with some regexps, but when I looked into sources I've suddenly changed my mind and have choosed to yacc. Now I'm writing grammar of tcpdump's output in BNF ( because PDML and wireshark is not my choise ). All I need is snmp printing which is done with verbose flag ( -v | vflag ). But I DON'T need verbose printing of low level protocols ( ip, udp ). For optional printing of Ethernet header there exists flag (-e | eflag ), but for ip and udp is not (it depends on vflag). I don't want to write grammar for that output. Of course I can make some local crocks (and I will ), but am I the first person complaining about that behaviour? I think there should be flags for verbose optional output on EACH level of tcp|osi model. But because tcpdump only supports BSD style of cli options, I think config is a good choise there. Just think about it. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [RESEND][PATCH] enable sniff on USB ports onlinux
paolo, checked in. can you make a fresh checkout and verify if everything is working as expected ? tx, /hannes Paolo Abeni wrote: > Hello, > > On Mon, 2006-10-02 at 17:15 -0700, Guy Harris wrote: >> I've added DLT_USB, with a value of 186. > > Must I resent the whole patch with the new DLT, must I send an > incremental patch or something else ?!? > > Thanks, > > Paolo > > > > -- > Email.it, the professional e-mail, gratis per te: http://www.email.it/f > > Sponsor: > Refill s.r.l. - Prodotti per TUTTE le stampanti sul mercato a prezzi sempre > convenienti. Dal 1993, leader nel compatibile di qualità in Italia. > Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5188&d=4-10 > - > 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.
Re: [tcpdump-workers] Sniffing inbound ethernet frames only
[EMAIL PROTECTED] wrote: > Dear tcpdump experts, > > I have a Linux box with two Fast Ethernet interfaces. > In two separate windows on the desktop I want to see > all inbound ethernet frames (from the wire), but not > the ethernet frames coming down the local network stack. > In the left window tcpdump should run to catch all > incoming ethernet frames from interface eth0. > In the right window tcpdump should run to catch all > incoming ethernet frames from interface eth1. > All outgoing ethernet frames must not be displayed. > Both tcpdump processes must run in parallel. > > The keyword inbound cannot be used with link level. > Which tcpdump expression solves the problem? could you aleborate on the last statement ? - the keyword 'inbound' should work fine one a linux box ... /hannes - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Sniffing inbound ethernet frames only
> Hello Hannes, > > on SuSE 10.1 (Kernel 2.6.16.13-4) I get the > following message: > > # tcpdump -i eth1 inbound ether > tcpdump: inbound/outbound not supported on linktype 1 > # tcpdump --version > tcpdump version 3.9.4 > libpcap version 0.9.4 > > Best regards > jojo ok makese sense now - sorry i was confused by junipers DLT for ethernet which contrary to the 'standard' ethernet DLT 1 does support directions ... seems the only choice you have left is to filter on your local MAC adresses to substitute the lack of notion for direction on the ethernet DLT. /hannes - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] tcpv6: removal of duplicate code
checked in and added you to the hall of shame (aka CREDITS file). tx for your submission, /hannes Gerrit Renker wrote: > This is an optional patch which removes duplicated code > from tcp6_cksum: comparison shows that the code of in_cksum > re-appears in that function. > > In addition, it fixes a typo in printing invalid checksums: > * previously: "cksum xDEAD (incorrect (-> xBEEF)" > * now:"cksum xDEAD (incorrect -> xBEEF)" > > > Regards > Gerrit Renker - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH]: [DCCP]: support for variable-length
checked in.
tx for your submission.
/hannes
Gerrit Renker wrote:
> This introduces support for variable-length checksum in
> DCCP, as it is specified in section 9 of RFC 4340.
>
> Previously tcpdump was only able to validate full-coverage
> checksums, this patch verifies checksums in accordance with
> the CsCov header field (sec. 5.3).
>
> The patch has been tested and verified on DCCPv4 and DCCPv6
> connections, checksums were manually validated, and traces
> can be supplied.
>
>
>
> In addition, the patch also
> * removes reduplicated code in dccp6_cksum (which
> just repeated the code of in_cksum)
> * fixes a bug in dccp.h -- the fields of CCVAL and
> CSCOV were swapped (cf. section 5.1 of RFC 4340)
> * fixes a typo in the display of incorrect checksums
> (these were printed as `cksum xDEAD (incorrect (-> xBEEF)',
>it now will print `cksum xDEAD (incorrect -> xBEEF)'
>
> I would like to see this merged as a Linux kernel patch already
> exists for DCCP partial checksum coverage support.
>
> Regards
> Gerrit Renker
>
>
> dccp.h |4 ++--
> print-dccp.c | 34 --
> 2 files changed, 18 insertions(+), 20 deletions(-)
>
>
>
>
> diff --git a/dccp.h b/dccp.h
> index 1afa8c0..8585060 100644
> --- a/dccp.h
> +++ b/dccp.h
> @@ -36,8 +36,8 @@ struct dccp_hdr {
> } dccph_xtrs;
> };
>
> -#define DCCPH_CCVAL(dh) (((dh)->dccph_ccval_cscov) & 0x0F)
> -#define DCCPH_CSCOV(dh) (((dh)->dccph_ccval_cscov >> 4) & 0x0F)
> +#define DCCPH_CCVAL(dh) (((dh)->dccph_ccval_cscov >> 4) & 0xF)
> +#define DCCPH_CSCOV(dh) (((dh)->dccph_ccval_cscov) & 0xF)
>
> #define DCCPH_X(dh) ((dh)->dccph_xtrs.dccph_xtr & 1)
> #define DCCPH_TYPE(dh) (((dh)->dccph_xtrs.dccph_xtr >> 1) & 0xF)
> diff --git a/print-dccp.c b/print-dccp.c
> index e6bfca6..d19c500 100644
> --- a/print-dccp.c
> +++ b/print-dccp.c
> @@ -60,9 +60,20 @@ static const char *dccp_feature_nums[] =
> "check data checksum",
> };
>
> +static inline int dccp_csum_coverage(const struct dccp_hdr* dh, u_int len)
> +{
> + int cov;
> +
> + if (DCCPH_CSCOV(dh) == 0)
> + return len;
> + cov = (dh->dccph_doff + DCCPH_CSCOV(dh) - 1) * sizeof(u_int32_t);
> + return (cov > len)? len : cov;
> +}
> +
> static int dccp_cksum(const struct ip *ip,
> const struct dccp_hdr *dh, u_int len)
> {
> + int cov = dccp_csum_coverage(dh, len);
> union phu {
> struct phdr {
> u_int32_t src;
> @@ -86,15 +97,15 @@ static int dccp_cksum(const struct ip *i
> phu.ph.dst = ip_finddst(ip);
>
> sp = &phu.pa[0];
> - return in_cksum((u_short *)dh, len,
> sp[0]+sp[1]+sp[2]+sp[3]+sp[4]+sp[5]);
> + return in_cksum((u_short *)dh, cov,
> sp[0]+sp[1]+sp[2]+sp[3]+sp[4]+sp[5]);
> }
>
> #ifdef INET6
> static int dccp6_cksum(const struct ip6_hdr *ip6, const struct dccp_hdr *dh,
> u_int len)
> {
> size_t i;
> - const u_int16_t *sp;
> - u_int32_t sum;
> + u_int32_t sum = 0;
> + int cov = dccp_csum_coverage(dh, len);
> union {
> struct {
> struct in6_addr ph_src;
> @@ -113,23 +124,10 @@ static int dccp6_cksum(const struct ip6_
> phu.ph.ph_len = htonl(len);
> phu.ph.ph_nxt = IPPROTO_DCCP;
>
> - sum = 0;
> for (i = 0; i < sizeof(phu.pa) / sizeof(phu.pa[0]); i++)
> sum += phu.pa[i];
>
> - sp = (const u_int16_t *)dh;
> -
> - for (i = 0; i < (len & ~1); i += 2)
> - sum += *sp++;
> -
> - if (len & 1)
> - sum += htons((*(const u_int8_t *)sp) << 8);
> -
> - while (sum > 0x)
> - sum = (sum & 0x) + (sum >> 16);
> - sum = ~sum & 0x;
> -
> - return (sum);
> + return in_cksum((u_short *)dh, cov, sum);
> }
> #endif
>
> @@ -288,7 +286,7 @@ #ifdef INET6
> dccp_sum = EXTRACT_16BITS(&dh->dccph_checksum);
> printf("cksum 0x%04x", dccp_sum);
> if (sum != 0) {
> - (void)printf(" (incorrect (-> 0x%04x),
> ",in_cksum_shouldbe(dccp_sum, sum));
> + (void)printf(" (incorrect -> 0x%04x),
> ",in_cksum_shouldbe(dccp_sum, sum));
> } else
> (void)printf(" (correct), ");
> }
>
>
>
>
> -
> 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.
Re: [tcpdump-workers] about tcpdump trace file!
> Hi, everybody > > > >I am a new comer! Nowadays, I want to analyze the tcpdump ¨Cw file. Does > anyone know some tool or method to do this? > you may want to check libpcap/savefile.c [http://cvs.tcpdump.org/cgi-bin/cvsweb/libpcap/savefile.c?rev=1.147] to get a better understanding about the .pcap file format. /hannes - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Outgoing packets capturing problem
what DLT type and what filter expression are you using ? Nickolay wrote: > Hello. > > I have a problem with outgoing packets capturing. I see only incoming > packets. > Any idea? > > Platform: ARM > kernel: 2.6.16.20. > libpcap: 0.9.5(--with-pcap=linux) > tcpdump: 3.9.5. > > Thanks. > - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] to recognize incoming and outgoing packets
Juan Pedro Muñoz Gea wrote: > Hi all, > > I'm using pcap library to capture live packets. > I want to distinguish incoming and outgoing captured packets > in an interface in promiscuous mode, without examining the payload, but I > don't know the way to do it. > > Using the PF_PACKET sockets family, if we use > the "recvfrom" function and a "struct sockaddr_ll" in the "from" field, we > can use the "struct sockaddr_ll.sll_pkttype" to know > if the captured packet is a PACKET_OUTGOING. > But I don't know if the there is something similar in the pcap library. > > Also, I would like knowing if I might to apply a "FILTER" > for all the incoming packets, and so, I would only receive > the incoming packets. yes that is supported and supposed to work. you may look in the manpage for the keywords "inbound" and "outbound" HTH, /hannes - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
