Re: [tcpdump-workers] Bug in tcpdump -tt timestamps
> The final 3 digits of the timestamp are bogus and always the same > throughout the run. Since the timestamps are stored in microsecond > precision, shouldn't the last 3 digits be 0's? Which OS are you on? Tried this on FreeBSD 8-STABLE, both 32 and 64 bit. Only 6 digits are printed, not 9 - and thus your problem cannot be reproduced. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] 10Gig Frames not searchable?
> I'm experiencing a problem with tcpdump, and I hope you guys can point > me in a good direction. > > Here's the short version: Running "tcpdump -r 10Gig.pcap host 1.1.1.1" > returns zero frames. Running the same thing without the filter shows tcp > packets from that IP. You may have VLAN tagged packets. try "tcpdump -e -r ..." to see any Ethernet details, including possible VLAN tags. Steinar Haug, Nethelp consulting, sth...@nethelp.no - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] VLAN BPF filter
> I want to filter packets having VLAN id 7 or VLAN ID 10. Those are not Q-n-Q > VLAN ID. So what should be perfect BPF syntax for it. > > > > When I tried using below syntax, it results only those packets having VALN ID > as 7 and src host 10.21.22.2. > > ""( ( vlan 7 and src host 10.21.22.2 ) or ( vlan 10 and dst host 10.21.22.3) > )"" This is expected, because each "vlan" term adds another 2-byte offset to the rest of the expression. You need to do this manually, e.g. tcpdump -ni em1 '(ether[12:2]==0x8100) and (ether[14:2]&4095==7 or ether[14:2]&4095==10)' Steinar Haug, Nethelp consulting, sth...@nethelp.no - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Sequence Numbers
> Do newer version of tcpdump no longer show TCP sequence numbers without the > -vv > flag? Or is this some kind of FreeBSD bug? Known problem, nothing to do with FreeBSD. See the thread "forces (and sctp) patch starting at 10. Jan 2010 at http://news.gmane.org/gmane.network.tcpdump.devel Not fixed in any released version of tcpdump as far as I can see. Highly irritating. Steinar Haug, Nethelp consulting, sth...@nethelp.no > > > FreeBSD 7.2 (tcpdump 3.9.7): > > 07:06:47.765297 IP x.x.x.x.58894 > 209.87.252.181.443: P 285:344(59) ack 1589 > win 16695 > 07:06:47.827029 IP 209.87.252.181.443 > x.x.x.x.58894: P 1589:1648(59) ack > 344 > win 33580 > 07:06:47.861615 IP x.x.x.x.58894 > 209.87.252.181.443: P 344:1117(773) ack > 1648 > win 16680 > 07:06:48.114280 IP 209.87.252.181.443 > x.x.x.x.58894: . ack 1117 win 33580 > > > FreeBSD 8.x (tcpdump 4.0.0): > > 07:10:17.303178 IP x.x.x.x.4433 > 209.85.225.105.80: Flags [.], ack 1391, win > 64512, length 0 > 07:10:17.307536 IP 209.85.225.105.80 > x.x.x.x.4433: Flags [.], ack 621, win > 9648, length 1390 > 07:10:17.308729 IP x.x.x.x.4433 > 209.85.225.105.80: Flags [.], ack 1391, win > 64512, length 0 > 07:10:17.340326 IP 209.85.225.105.80 > x.x.x.x.4433: Flags [.], ack 621, win > 9648, length 1390 > 07:10:17.340330 IP 209.85.225.105.80 > x.x.x.x.4433: Flags [.], ack 621, win > 9648, length 1390 > 07:10:17.341588 IP x.x.x.x.4433 > 209.85.225.105.80: Flags [.], ack 4171, win > 64512, length 0 > > > To me the 3.9.7 output is much more useful. > > -Steve > > > > - > This is the tcpdump-workers list. > Visit https://cod.sandelman.ca/ to unsubscribe. > - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] DHCPv6 improvements for readability
Having started to play with DHCPv6, I found the tcpdump printout of DHCPv6 options, http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2 could be improved. Below are my suggested improvements, relative to tcpdump-4.1.1. The change to the "NTP-server" option is just for constistency with the rest. The "DNS-search-list" could also be called "Domain search list" as it is in the IANA documentation. Steinar Haug, Nethelp consulting, sth...@nethelp.no -- --- print-dhcp6.c.orig 2010-03-12 02:56:44.0 +0100 +++ print-dhcp6.c 2010-11-10 18:38:09.0 +0100 @@ -229,15 +229,15 @@ case DH6OPT_SIP_SERVER_A: return "SIP-servers-address"; case DH6OPT_DNS: - return "DNS"; + return "DNS-server"; case DH6OPT_DNSNAME: - return "DNS-name"; + return "DNS-search-list"; case DH6OPT_IA_PD: return "IA_PD"; case DH6OPT_IA_PD_PREFIX: return "IA_PD-prefix"; case DH6OPT_NTP_SERVERS: - return "NTP-Server"; + return "NTP-server"; case DH6OPT_LIFETIME: return "lifetime"; case DH6OPT_NIS_SERVERS: - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] BPF filter for tcp syn for ipv6
> > I want to filter TCp syn packet which is coming using IPv6 addresses. I am > > not able to find the bpf filter for that can somebody help me to find the > > right BPF filter > > > > > > I have already tried" tcp[tcpflags] & (tcp-syn) != 0" which doesn't work > > for IPv6 traffic. > > > > What does "doesn't work for IPv6 traffic" mean? The "tcp[...]" expression doesn't work for IPv6. This is documented in the pcap-filter man page: expr relop expr True if the relation holds, where relop is one of >, <, >=, <=, =, !=, and expr is an arithmetic expression composed of integer constants (expressed in standard C syntax), the normal binary operators [+, -, *, /, &, |, <<, >>], a length operator, and special packet data accessors. Note that all comparisons are unsigned, so that, for example, 0x8000 and 0x are > 0. To access data inside the packet, use the following syntax: proto [ expr : size ] Proto is one of ether, fddi, tr, wlan, ppp, slip, link, ip, arp, rarp, tcp, udp, icmp, ip6 or radio, and indicates the protocol layer for the index operation. (ether, fddi, wlan, tr, ppp, slip and link all refer to the link layer. radio refers to the "radio header" added to some 802.11 captures.) Note that tcp, --->>> udp and other upper-layer protocol types only apply to IPv4, not IPv6 (this will be fixed in the future). The byte offset, rela- tive to the indicated protocol layer, is given by expr. Size is optional and indicates the number of bytes in the field of interest; it can be either one, two, or four, and defaults to one. The length operator, indicated by the keyword len, gives the length of the packet. Steinar Haug, Nethelp consulting, sth...@nethelp.no - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] forces (and sctp) patch
> Darren> I'm curious about what the motivation is for splitting the > Darren> timestamp and packet data onto separate lines is. > > I think it just kinda happened. > I would have to go back and look at who did what... I think that it > does not occur in IP/TCP, but it does in IP/SCTP. Here's my problem. TCP example from tcpdump 3.9.8 (no -v option): 14:11:02.591440 IP 193.75.4.2.57376 > 193.75.110.78.519: P 82:556(474) ack 21 win 8326 14:11:02.711436 IP 193.75.4.2.57376 > 193.75.110.78.519: . ack 121 win 8326 Same TCP example for tcpdump 4.0.0 (no -v option): 14:11:02.591440 IP 193.75.4.2.57376 > 193.75.110.78.519: Flags [P.], ack 21, win 8326, options [nop,nop,TS val 170368184 ecr 3051255673], length 474 14:11:02.711436 IP 193.75.4.2.57376 > 193.75.110.78.519: Flags [.], ack 121, win 8326, options [nop,nop,TS val 170368304 ecr 3051257051], length 0 Note that the info about TCP sequence numbers is gone. We can get the sequence numbers with the -v option: 14:11:02.591440 IP (tos 0x0, ttl 61, id 56912, offset 0, flags [DF], proto TCP (6), length 526) 193.75.4.2.57376 > 193.75.110.78.519: Flags [P.], cksum 0xc12f (correct), ack 21, win 8326, options [nop,nop,TS val 170368184 ecr 3051255673], length 474 14:11:02.711436 IP (tos 0x0, ttl 61, id 56916, offset 0, flags [DF], proto TCP (6), length 52) 193.75.4.2.57376 > 193.75.110.78.519: Flags [.], cksum 0x19ff (correct), ack 121, win 8326, options [nop,nop,TS val 170368304 ecr 3051257051], length 0 but that also gives us the multi-line format. My claim is that the 3.9.8 format is much preferable (gives me more relevant info) in the face of no -v option. Steinar Haug, Nethelp consulting, sth...@nethelp.no - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] forces (and sctp) patch
> Well, it gets in the way of all types of things, for example: > > tcpdump-v -i foo.cap | egrep pattern | wc -l > > I think the behaviour should be the reverse of the -g in Mac OS X > and that is it should be necessary to use some new command line > option to force tcpdump to insert new lines between things. 100% agreed. I think changing the default behavior like that was a bad idea, and should be reversed. Steinar Haug, Nethelp consulting, sth...@nethelp.no - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] vlan [xx] filter not filtering any packets
> I've spent some time playing with tcpdump and pcap with regard > to vlans. Using libpcap 1.0.0 + tcpdump 4.0.0, I can able to > correctly dump packets including (reconstructed) vlan headers. > But it seems that using the vlan filter keyword does not work. Can't answer for Linux, but VLAN filtering definitely works on FreeBSD. Steinar Haug, Nethelp consulting, sth...@nethelp.no - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Capturing without having superuser rights
> > As I'm developping on libpcap to provide a metrology plateform, I was > > wondering if there is a manner to enable a specific user (or a specific > > group) to capture from a network interfaces (even in promiscuous mode), > > without using sudo. > > I'm trying to do this with udev, but I'm not shure it can works. > > > > Does anybody have an idea ? > > Depends on the platform you are on. On FreeBSD all you need is read write > permission to the /dev/bpf* devices. And for *capturing* you really only need read permission. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump3.9.8 slow performance with filter in
> Thanks alot Alex, that's exactly the problem since the university uses VLAN > based on packet tags. > Actually I'm using pcap to do some packet payload processing on FreeBSD. It > seems right now that > if I use the filter "ip or (vlan and ip)", the packet returned from pcap > contains the VLAN tag. I wonder > if there's a way to let the OS to strip off the tag before deliverying? Yes, you can configure a VLAN interface on FreeBSD, and the OS will strip the VLAN tag before delivering it to tcpdump. *But* you cannot sniff promiscuously on a VLAN interface - which means you'll only get traffic addressed directly to the host. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump3.9.8 slow performance with filter in
> I'm currently doing packet capturing on a FreeBSD 7.0 system. I was actually > running my own pcap based > program but found the performance was very bad when I added a simple filter > as "ip". So I tested tcpdump > on the same machine. It turned out that the performance of tcpdump without a > filter expression is reasonably > well, but turned to unacceptable when applying an "ip" filter. Please define "unacceptable". > I guess it > must have something to do with the libpcap0.9.8.. Below is some result I > got. The version on the machine is tcpdump3.9.8 with libpcap0.9.8 > > 1. tcpdump without filter: > # tcpdump -i em1 -s 1500 -w dump.dat > 433145 packets captured > 448830 packets received by filter > 0 packets dropped by kernel > > 2. tcpdump with filter: > # tcpdump -i em1 -s 1500 -w dump.dat ip > 3984 packets captured > 1091656 packets received by filter > 0 packets dropped by kernel The statistics show 0 packets dropped. What is your problem here - are you saying that there are *more* IP packets (in the 1091656 packets received by the filter) than the 3984 packets captured? I run tcpdump on various FreeBSD 7 systems myself with no apparent problems. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Should we enable IPv6 support by default?
> It's 2008. Should we enable IPv6 support by default in libpcap and > tcpdump (as long as the OS supports IPv6 to a sufficient extent that we > can compile the support in), and let users do "--disable-ipv6" if, for > whatever reason, they don't want it? Yes please. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Tools for stripping parts of a pcap file?
> Well, you can open your pcap file with Wireshark (ethereal), select > the packets you want using the filter and saving them using the > standard "save as" option. > > Is it enough or you need something more "scriptable" that can be done > from the command-line? Command line would be preferred. But I'm also wondering if maybe what I wanted to do here was misunderstood. I don't want to simply pick all the GRE packets and save those in pcap format. I want to pick the GRE packets and save them *without* the outer IP + GRE header, in pcap format. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Tools for stripping parts of a pcap file?
Does anybody know of a good tool for stripping parts of the packets in a pcap file? Say I have a pcap file containing GRE encapsulated info, and I want to strip the outer IP + GRE headers and leave the rest, writing out the result to another (valid) pcap file - which should of course be readable by tcpdump and other libpcap-based tools. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Minor patch to print some Cisco protocol info
Very minor patch to print basic info about a few more Cisco LAN
protocols. See documentation of the PID values at for instance
http://www.cisco.com/en/US/products/hw/switches/ps700/products_white_paper09186a00801b49a4.shtml#pre4
Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
--
--- llc.h.orig Thu Dec 1 18:45:45 2005
+++ llc.h Mon Feb 5 10:52:31 2007
@@ -102,6 +102,9 @@
* PIDs for use with OUI_CISCO.
*/
#definePID_CISCO_CDP 0x2000 /* Cisco Discovery Protocol */
+#definePID_CISCO_VTP 0x2003 /* Cisco VLAN Trunk Protocol */
+#definePID_CISCO_DTP 0x2004 /* Cisco Dynamic Trunk Protocol
*/
/*
* PIDs for use with OUI_RFC2684.
--- print-llc.c.origTue Jan 17 18:43:55 2006
+++ print-llc.c Mon Feb 5 10:54:12 2007
@@ -103,6 +103,9 @@
static const struct tok cisco_values[] = {
{ PID_CISCO_CDP, "CDP" },
+ { PID_CISCO_VTP, "VTP" },
+ { PID_CISCO_DTP, "DTP" },
{ 0, NULL }
};
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Test
The original message was received at Tue, 18 Jul 2006 09:46:25 +0100 from [27.102.129.216] - The following addresses had permanent fatal errors - tcpdump-workers@lists.tcpdump.org - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Delivery reports about your e-mail
The original message was received at Fri, 9 Dec 2005 09:37:22 +0500 from nethelp.no [190.38.169.16] - The following addresses had permanent fatal errors - - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Minor patch to print-radius.c
As far as I can see, print_vendor_attr() in print-radius.c doesn't
account for the fact that the length field includes itself (1 byte)
and type (1 byte), thus attempting to print 2 bytes too much when
printing the ASCII text form of the Value field. Example:
Vendor Specific Attribute (26), length: 31, Value: Vendor: Unisphere
Networks (4874)
--> Vendor Attribute: 24, Length: 25, Value: pppoe 00:13:49:1b:ba:4f..
0x: 130a 1819 7070 706f 6520 3030 3a31
0x0010: 333a 3439 3a31 623a 6261 3a34 66
Below is a very small patch which corrects this. I'd like somebody
else to verify it since I only have tcpdump files with Unisphere (now
Juniper) vendor specific attributes available at the moment.
With the patch, the example above becomes
Vendor Specific Attribute (26), length: 31, Value: Vendor: Unisphere
Networks (4874)
--> Vendor Attribute: 24, Length: 25, Value: pppoe 00:13:49:1b:ba:4f
0x: 130a 1819 7070 706f 6520 3030 3a31
0x0010: 333a 3439 3a31 623a 6261 3a34 66
Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
--
--- print-radius.c.orig Wed Jul 21 23:45:47 2004
+++ print-radius.c Sun Sep 25 15:48:16 2005
@@ -520,7 +520,7 @@
printf("\n\tVendor Attribute: %u, Length: %u, Value: ",
vendor_type,
vendor_length);
-for (idx = 0; idx < vendor_length ; idx++, data++)
+for (idx = 0; idx < vendor_length-2 ; idx++, data++)
printf("%c",(*data < 32 || *data > 128) ? '.' : *data );
length-=vendor_length;
}
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] dealing with collisions, dropped packets
> >A collision on half duplex media (such as a hub) is a *normal* and > >*expected* occurence, and does *not* cause a packet to be dropped. > > >Note that this does not apply to "late collisions" which are quite > >different - late collisions are signs of *error* (for instance a > >duplex mismatch). > > Sorry I did not make myself clear. I know very well that collisions on hubs > are normal. What I wasn't sure of was if tcpdump was seeing the first > transmission of a packet, and then dropping the second copy of the packet > when it is recent by the originating host so as not to skew statistics or > something. Um, I'm still not sure if you understand. A normal collision is detected during the first 512 bits of the packet. There is no retransmission of the whole packet in case of collision (and thus no second copy of the packet). One packet is sent, one packet is received. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] dealing with collisions, dropped packets
> Recently I've been investigating why tcpdump on my IDS shows quite a few > packets as being dropped. I think this is because my traffic to the IDS is > fed through a hub where I know there are many collisions (there may be too > many packets per second for the little soho 10/100 hub to handle). I'm not > sure how tcpdump handles collisions, and so I don't know if this is even a > problem or not. I sense some fundamental misunderstandings here. Basically: A collision on half duplex media (such as a hub) is a *normal* and *expected* occurence, and does *not* cause a packet to be dropped. Note that this does not apply to "late collisions" which are quite different - late collisions are signs of *error* (for instance a duplex mismatch). > Is there a way to get more fine grained statistics on why packets are > dropped, and would collisions coming in off a hub be shown as dropped? I'm > seeing a traffic feed of roughly 4000-5000 packets per second and about 1000 > collisions per minute, so I don't think that the rate of traffic is the > cause of my problem. 1000 collisions per minute with 4000-5000 pps is a very *low* collision rate. > If the dropped packets being displayed are just the collisions from the hub > then it's no big deal, but if it's something else I'd like to try and fix it > of course. I expect your dropped packets are due to something else. But you should definitely check for late collisions. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] PCAP - IP Fragments
> > You could write a BPF expression to match a particular packet id#. > > > > How should I do this? I don`t know a specific packet id. What I would have > to do is to compare each packet id with the ones received earlier and I must > store it to compare with ones received later. With that whole packets must > be stored over a longer period. > This is not possible!? How does tcpdump handle this? There is no silver bullet here. If you receive fragments out of order and your application wants to handle these, your application or something else *must* store the fragments: - At least until the first packet (with the port numbers) arrive, if you only want to correlate the fragment with the first packet. - Until all fragments have arrived, if you want to reassemble the packet. tcpdump doesn't have any specific facility to handle fragmented packets, as far as I know (it cannot reassemble the fragments). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap and Super User mode
> Is it possible to write a program using libpcap that doesnt need to be run in super > user mode, and if there is how would that be done. Everything that i have seen that > uses libpcap has to be in su mode At least on BSD based systems, it depends on readability of the /dev/bpf* devices and not on super user mode. Normally /dev/bpf* is only readable by root, but you can change this. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] text format stability
> Despite all my whining, it is great that tcpdump is being worked on again, and I > appreciate the effort that you've put into it. I just wish there was an option > that would preserve the old behavior. (Or, even better, an option that would > *give* the new behavior.) I think a lot of people would appreciate this. I'm afraid I have to disagree. I've had some surprises myself from the new formats, but I think tcpdump is definitely moving in the right direction. I would rather have tcpdump with new functionality and some changes in the print format, than no new functionality at all. The converse of this, of course, is that you always have the opportunity to use an old version of tcpdump, which prints in the format you want! Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Various diffs for more complete LDP decoding
Below are patches to perform significantly more complete LDP decoding.
Synposis:
- Minor diff to print-tcp.c (actually call the LDP decoder)
- Minor diff to print-bgp.c (unstaticize routines used by print-ldp.c)
- Major diff to print-ldp.c
Hannes: I'd be happy to decode even more if you can get me some LDP
traces which utilize more of the LDP functionality.
Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
--- print-bgp.c.origMon May 17 14:10:05 2004
+++ print-bgp.c Thu May 27 17:49:19 2004
@@ -460,7 +460,7 @@
{ 0, NULL},
};
-static int
+int
decode_prefix4(const u_char *pptr, char *buf, u_int buflen)
{
struct in_addr addr;
@@ -688,7 +688,7 @@
}
#ifdef INET6
-static int
+int
decode_prefix6(const u_char *pd, char *buf, u_int buflen)
{
struct in6_addr addr;
--- print-tcp.c.origMon Apr 26 08:17:31 2004
+++ print-tcp.c Thu May 27 19:56:11 2004
@@ -650,8 +650,9 @@
} else if (sport == MSDP_PORT || dport == MSDP_PORT) {
msdp_print(bp, length);
}
-else if (sport == LDP_PORT || dport == LDP_PORT)
-printf(": LDP, length: %u", length);
+else if (length > 0 && (sport == LDP_PORT || dport == LDP_PORT)) {
+ldp_print(bp, length);
+ }
}
return;
bad:
--- print-ldp.c.origSun Nov 16 10:36:27 2003
+++ print-ldp.c Thu May 27 19:32:41 2004
@@ -11,6 +11,7 @@
* FOR A PARTICULAR PURPOSE.
*
* Original code by Hannes Gredler ([EMAIL PROTECTED])
+ * and Steinar Haug ([EMAIL PROTECTED])
*/
#ifndef lint
@@ -142,6 +143,7 @@
#defineLDP_TLV_COMMON_SESSION 0x0500
#defineLDP_TLV_ATM_SESSION_PARM 0x0501
#defineLDP_TLV_FR_SESSION_PARM 0x0502
+#define LDP_TLV_FT_SESSION 0x0503
#defineLDP_TLV_LABEL_REQUEST_MSG_ID 0x0600
static const struct tok ldp_tlv_values[] = {
@@ -163,10 +165,56 @@
{ LDP_TLV_COMMON_SESSION,"Common Session Parameters" },
{ LDP_TLV_ATM_SESSION_PARM, "ATM Session Parameters" },
{ LDP_TLV_FR_SESSION_PARM, "Frame-Relay Session Parameters" },
+{ LDP_TLV_FT_SESSION,"Fault-Tolerant Session Parameters" },
{ LDP_TLV_LABEL_REQUEST_MSG_ID, "Label Request Message ID" },
{ 0, NULL}
};
+#define LDP_FEC_WILDCARD 0x01
+#define LDP_FEC_PREFIX 0x02
+#define LDP_FEC_HOSTADDRESS0x03
+/* From draft-martini-l2circuit-trans-mpls-13.txt */
+#define LDP_FEC_MARTINI_VC 0x80
+
+static const struct tok ldp_fec_values[] = {
+{ LDP_FEC_WILDCARD,"Wildcard" },
+{ LDP_FEC_PREFIX, "Prefix" },
+{ LDP_FEC_HOSTADDRESS, "Host address" },
+{ LDP_FEC_MARTINI_VC, "Martini VC" },
+{ 0, NULL}
+};
+
+/* From draft-martini-l2circuit-trans-mpls-13.txt */
+#define LDP_MARTINI_VCTYPE_FR_DLCI 0x0001
+#define LDP_MARTINI_VCTYPE_ATM_AAL50x0002
+#define LDP_MARTINI_VCTYPE_ATM_CELL0x0003
+#define LDP_MARTINI_VCTYPE_ETH_VLAN0x0004
+#define LDP_MARTINI_VCTYPE_ETHERNET0x0005
+#define LDP_MARTINI_VCTYPE_HDLC0x0006
+#define LDP_MARTINI_VCTYPE_PPP 0x0007
+#define LDP_MARTINI_VCTYPE_CEM 0x0008
+#define LDP_MARTINI_VCTYPE_ATM_VCC 0x0009
+#define LDP_MARTINI_VCTYPE_ATM_VPC 0x000A
+
+/* Overlaps print-bgp.c bgp_l2vpn_encaps_values */
+static const struct tok ldp_vctype_values[] = {
+{ LDP_MARTINI_VCTYPE_FR_DLCI, "Frame Relay DLCI" },
+{ LDP_MARTINI_VCTYPE_ATM_AAL5, "ATM AAL5 VCC transport" },
+{ LDP_MARTINI_VCTYPE_ATM_CELL, "ATM transparent cell transport" },
+{ LDP_MARTINI_VCTYPE_ETH_VLAN, "Ethernet VLAN" },
+{ LDP_MARTINI_VCTYPE_ETHERNET, "Ethernet" },
+{ LDP_MARTINI_VCTYPE_HDLC, "HDLC" },
+{ LDP_MARTINI_VCTYPE_PPP, "PPP" },
+{ LDP_MARTINI_VCTYPE_CEM, "SONET/SDH Circuit Emulation Service" },
+{ LDP_MARTINI_VCTYPE_ATM_VCC, "ATM VCC cell transport" },
+{ LDP_MARTINI_VCTYPE_ATM_VPC, "ATM VPC cell transport" },
+{ 0, NULL}
+};
+
+/* RFC1700 address family numbers, same definition in print-bgp.c */
+#define AFNUM_INET 1
+#define AFNUM_INET62
+
#define FALSE 0
#define TRUE 1
@@ -198,7 +246,11 @@
};
const struct ldp_tlv_header *ldp_tlv_header;
-u_short tlv_type,tlv_len,tlv_tlen;
+u_short tlv_type,tlv_len,tlv_tlen,af,ft_flags;
+u_char fec_type,prelen;
+u_int ui;
+char buf[100];
+int i;
ldp_tlv_header = (const struct ldp_tlv_header *)tptr;
tlv_len=EXTRACT_16BITS(ldp_tlv_header->length);
@@ -238,23 +290,121 @@
printf("\n\t Sequence Number: %u", EXTRACT_32BITS(tptr));
break;
+case LDP_TLV_ADDRESS_LIST:
+ af = EXTRACT_16BITS(tptr);
+ tptr+=2;
+ printf("\n\t Adress Family: ");
+ if (af == AFNUM_INET) {
+ printf("IPv4, addresses:");
+ for (i=0; i<(tlv_tlen-2)/4; i++) {
+
[tcpdump-workers] Minor error in print-ipx.c
gcc, at least on my FreeBSD 4.9 box, doesn't like an active statement
before the first declaration (compiling tcpdump-2004.05.20):
./print-ipx.c: In function `ipx_print':
./print-ipx.c:60: syntax error before `const'
I fixed it as shown below.
Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
--- print-ipx.c.origSat May 1 12:06:55 2004
+++ print-ipx.c Wed May 26 12:18:29 2004
@@ -54,10 +54,10 @@
void
ipx_print(const u_char *p, u_int length)
{
+ const struct ipxHdr *ipx = (const struct ipxHdr *)p;
+
if (!eflag)
printf("IPX ");
-
- const struct ipxHdr *ipx = (const struct ipxHdr *)p;
TCHECK(ipx->srcSkt);
(void)printf("%s.%04x > ",
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Size limit on the filter string to libpcap?
> Is there a limit on how big the string can be for specifying the filter to > pcap in pcap_compile. My filter needs to exclude a bunch of ip addresses > (eg: tcpdump host not 1.1.1.1 and host not 2.2.2.2 ...upto 50 addresses) There are definitely limits for the operating systems which do in-kernel filtering (FreeBSD in my case) - specifically, there is a limit to how many instructions the kernel will accept for the BPF interpreter. FreeBSD as of 4.9 has: /sys/net/bpf.h: #define BPF_MAXINSNS 512 I recently tested a bit and for a filter with 200 (src addr, dst port) pairs I had to increase the number of instructions to 2048. I seem to remember that 50 addresses (or in my case, 50 pairs) was no problem. > If no such limit (other than reasonable buffer size and sanity checks) is > it safe and efficient to add that many (50) IP addresses to the filter? Safe provided you can get the kernel to accept a sufficiently large filter. Efficient? Maybe - if you need to compare with 50 addresses I believe it will do a sequential comparison with address 1, address 2, etc. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] PCAP performance
> > > Now I have noticed that about every 3 minutes and 15 seconds the Program > > > uses 100 % of the CPU. > > > After about 45 sec the program works normal again and uses only 10% of > > the > > > CPU time. > > > The program is running on a 300 MHz Celeron with 128 MB RAM under > > Slackware > > > 8.1. > > > > If you're running it from a terminal window, try typing the quit > > character at it (control-backslash, unless you or the Slackware folks or > > Linux distributions in general change it from the traditional UN*X > > default) when it's running at 100%; that should cause it to dump core. > > Then use gdb to see what the program was doing at that time. > > > I have tried it, but it didn`t help me very much. The program was in a > normal state in which it processed a packet. > I realized now that just before my program uses all CPU time the system > starts to use the CPU more. > The System uses about 30 % of the CPU and then my program starts to burn CPU > power. > I think there is something happening in the kernel... ? Yes, I think you definitely need to look at your kernel. I tried an experiment somewhat similar to yours: - 366 MHz Celeron, FreeBSD 4.9-STABLE, 384 MByte memory. tcpdump 3.7.2 and libpcap 0.7, which is what comes with FreeBSD 4.9-STABLE. - Long filter, 200 (src addr, dst port) pairs which would all have to be evaluated for every packet. - Sending full sized (1500 byte) packets with hping2, 100 pps. - Receiving the full 1500 bytes and writing them to file with tcpdump: tcpdump -nps 1500 -w tcpdump.hping -F /tmp/filter - Logging the processor utilization with vmstat (vmstat 5). On this system, which performance-wise is similar to yours, this tcpdump session used between 1 and 2 percent CPU time, according to vmstat. The difference between a short filter (1 src addr, dst port pair) and a long filter was not noticeable. No hint of any problems after a specific time. I had the hping2 session running for 10 minutes (60.000 packets) and it all ran smoothly the whole time. Note that I had to recompile the kernel and change BPF_MAXINSNS to 2048 in order to use such a large (200 pairs) filter. My conclusion is that neither libpcap nor tcpdump by themselves are responsible for the high CPU time you are seeing. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] PCAP performance
> I have written a packet sniffer under C++ using libpcap. > Now I have noticed that about every 3 minutes and 15 seconds the Program > uses 100 % of the CPU. > After about 45 sec the program works normal again and uses only 10% of the > CPU time. Sure sounds like a problem with your program - as far as I know there is nothing in libpcap which would cause this. > The program is running on a 300 MHz Celeron with 128 MB RAM under Slackware > 8.1. > I also tried it under a 1600 Athlon XP with 512 MB RAM under SuSeE 8.2. > There was the same behaviour, except that it only used 80% of the CPU and it was > back normal faster. > I use libpcap 0.8.1 and pcap_dispatch, which is called in a while statement > of a pthread, with 1 as parameter for number of packets to capture. > I first thought that I made a mistake in the call-back function, but I > replaced my code with return and it did the same thing. > I tested the program with hping2 and sent a packet every 10 ms. The used > filter is quite long and consists of about 150 pairs of IP-Addresses and Ports. A packet every 10 ms is only 100 pps - this should be no problem at all. If I test tcpdump on a FreeBSD/Pentium 700 MHz machine with 100 pps, I see less than 1% load from running tcpdump. I recommend that you test tcpdump on your system with the same filter as your C++ program and see what happens. If you do "tcpdump -nw /dev/null" you have removed all DNS lookups and all writing to the terminal, and should be left with the load from tcpdump/libpcap itself. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
