Re: [tcpdump-workers] proposed new pcap format
On Apr 5, 2004, at 10:39 PM, Ryan Mooney wrote: What about adding the concept of arbitrary meta-packets that can sit anywhere in the capture stream. These could be used to encode comments, and other meta-data. In Michael Richardson's proposal, a capture file is a sequence of records, each of which contains one or more type/length/value items. A record need not contain a PCAP_DATACAPTURE item; if it doesn't contain one, it'd be meta-data without a packet, and if it does contain one, it's a packet, possibly with additional meta-data. In Loris Degioanni and Fulvio Risso's proposal, a capture file is a sequence of records, each of which is a type/length/value item. Some of the record types include a sequence of type/length/value options within them. Both of those schemes support the concept of arbitrary meta-data that can appear anywhere in the capture stream, encoding comments and other meta data... This concept could also be used for other internal meta-data for example capture information like direction, interface info, etc...). There would have to be a way to tag future as part of a meta-data stream (to handle multiple interfaces, etc..). ...and handle multiple interfaces, as well as meta-data associated with packets and not associated with packets... This could be done in a way to preserve the ability to cat multiple files together ...and support the ability to concatenate multiple capture files with cat. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
On Tue, Mar 23, 2004 at 04:56:43PM -0800, Mark Pizzolato wrote: I wonder where the sendto() stuff is really necessary. The simple send() worked for us on RH 7.3-Fedora Core1 on Intel. And RH 6.2 on Sparc, and numerous other linux environments. We've never gotten a complaint send() appears to work with a 2.2[.x] kernel, at least, and would probably work on 2.4[.x] and 2.6[.x] as well, as the socket is bound. I don't have a 2.0[.x]-kernel system on which to test it. I've checked in a change to just use send(). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bpf/pcap performance
On Apr 12, 2004, at 5:07 PM, Guy Harris wrote: ...which would require that pcap_pkthdr be changed to begin with a struct pcap_timeval. If it's OK to, on platforms where, for example, ts_sec is 64 bits, break binary compatibility with applications dynamically linked with libpcap, we could do that - but, if not, we need both structures. Make that ...where, for example, 'tv_sec' is 64 bits - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bpf/pcap performance
(Noise inserted in the hopes that that the mailing list software doesn't think that this is a duplicate of my previous message, which I sent from my sonic.net address and which thus didn't get through, and thus prevent it from getting to the list.) On Wed, Apr 14, 2004 at 12:30:45PM +1000, Darren Reed wrote: Looking more closely at the non-blocking side of things, there seems to be no use of either p-nonblock or p-timeout apart from in pcap_setnonblock() ? p-nonblock is there for the benefit of, among other things, pcap-linux.c if, as, and when it implements mmaped-capture support - Ok, well: fgrep 'nonblock' *.c pcap-win32.c: return (p-nonblock); pcap-win32.c: p-nonblock = (newtimeout == -1); pcap.c: * We don't look at p-nonblock, in case somebody tweaked the FD What happened to linux ? It hasn't had the mmaped capture support implemented yet in the tcpdump.org CVS. I might add that ethereal could really benefit from something like this (perhaps). It currently behaves very poorly when it comes to dealing with large capture files (large might be as small as 100MB or even less.) Unless this is just a problem isolated to using it on windows ? And yes, when you're capturing gigabytes per day, this is a small amount :) There are plenty of other per-packet-read-in CPU-time-chewers in Ethereal; once those are changed, perhaps the time spent copying the data around will show up. Something like map the file from disk and just build an internal index, rather than try read the entire file in (which is what it appears to do.) Yes, it does, indeed, read the entire file, because it needs to dissect every packet in order to 1) create the summary list items for those packets and 2) construct all the state that might be necessary to dissect many of the packets. I think the current design (pcap_dispatch(), etc) is what's led to strange API hooks like pcap_breakloop() appearing, when I think a better design could have side stepped the need for them O:-) Well, pcap_breakloop() also works around the workaround :-) for the don't choke when we get ptraced problem, i.e. that the implementation on some platforms treats EINTR not as an indication that it should quit but as an indication that it should try reading again. read(2) can also return EINTR if a signal is received, depending on how signal handling was setup by the application. e.g. SIGHUP. Yes, that's what I was referring to - if you've set up signal handling to interrupt system calls, then after a signal handler returns, EINTR will be returned, but the read loop will go back and read more data rather than returning. I don't know whether an EINTR gets delivered if you're debugging a libpcap-based application, but, if that *is* a problem and that workaround *is* necessary, some scheme is needed to let a signal handler cause the read loop to terminate. For example, ^C'ing tcpdump, having it break out of the pcap_dispatch() loop and exiting back out so that it can do a pcap_dump_flush() and exit cleanly, without any data lost to internal buffers, right ? Yes, that's the idea. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap filter for 802.11
On Apr 16, 2004, at 3:01 AM, Chen Hsia Lee wrote: I have just started using libpcap and am still unfamiliar with it. What is the filter expression to pick up only wireless 802.11 packets? If you're capturing on an 802.11 interface, by definition all the packets you will get are wireless 802.11 packets. If you're capturing on some other type of interface, by definition *none* of the packets you will get are wireless 802.11 packets. As such, there's no filter expression to pick up only wireless 802.11 packets - if you want that, capture on an 802.11 interface. Do you mean, for example, what is the filter expression to pick up only 802.11 *management* packets? If so, then you have to construct a filter that looks at the 802.11 header to figure out the packet type; there's no built-in filter expression for that. See the 802.11 spec, and the tcpdump man page section on filter expressions; you'd use one of the expr relop expr True if the relation holds, where relop is one of , , =, =, =, !=, and expr is an arithmetic expression com- posed of integer constants (expressed in standard C syn- tax), the normal binary operators [+, -, *, /, , |], a length operator, and special packet data accessors. 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 or ip6, and indicates the protocol layer for the index operation. (ether, fddi, wlan, tr, ppp, slip and link all refer to the link layer.) Note that tcp, udp and other upper-layer proto- col types only apply to IPv4, not IPv6 (this will be fixed in the future). The byte offset, relative 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. For example, `ether[0] 1 != 0' catches all multicast traffic. The expression `ip[0] 0xf != 5' catches all IP packets with options. The expression `ip[6:2] 0x1fff = 0' catches only unfragmented datagrams and frag zero of fragmented datagrams. This check is implicitly applied to the tcp and udp index operations. For instance, tcp[0] always means the first byte of the TCP header, and never means the first byte of an intervening fragment. Some offsets and field values may be expressed as names rather than as numeric values. The following protocol header field offsets are available: icmptype (ICMP type field), icmpcode (ICMP code field), and tcpflags (TCP flags field). The following ICMP type field values are available: icmp- echoreply, icmp-unreach, icmp-sourcequench, icmp-redi- rect, icmp-echo, icmp-routeradvert, icmp-routersolicit, icmp-timxceed, icmp-paramprob, icmp-tstamp, icmp-tstam- preply, icmp-ireq, icmp-ireqreply, icmp-maskreq, icmp- maskreply. The following TCP flags field values are available: tcp- fin, tcp-syn, tcp-rst, tcp-push, tcp-ack, tcp-urg. Primitives may be combined using: A parenthesized group of primitives and operators (paren- theses are special to the Shell and must be escaped). Negation (`!' or `not'). Concatenation (`' or `and'). Alternation (`||' or `or'). Negation has highest precedence. Alternation and concatenation have equal precedence and associate left to right. Note that explicit and tokens, not juxtaposition, are now required for concatenation. expressions to test that; you'd test the link-layer header, so proto would be link or wlan (they mean the same thing). Also, what is the option for tcpdump to print the 802.11 header? -e, as is the case with all link-layer headers. Which field is used to determine that a packet is an 802.11 packet? See above - there
Re: [tcpdump-workers] Proposed new pcap format
On Tue, Apr 20, 2004 at 06:16:48PM -0700, Michael Richardson wrote: Darren btw, is it at all easily possible to get the 802.3 checksum Darren into captured data ? On some OSes you ask for that. Not on BSD AFAIK, yes, with PF_PACKET on Linux. Some BSDs give it to you, at least for some interfaces, with no way of not getting it (OS X with the Apple 10/100/1000 interfaces, and I think at least some NetBSD drivers do). How do you ask for it on Linux? (Or are they like those BSDs in that regard?) And with GbE encoding, ECC memory and parity protected L3 cache buses, the PCI bus *is* the least reliable interface in a typical PC. I believe that people who do TCP checksum offload have experienced this problem already. Everything old is new again. We had a similar problem with an EISA-bus network device at Network Appliance ages ago - we didn't turn UDP checksumming on by default, and that problem caused us to do so, and the checksum caught the problem. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] IPv6 dependency
On Apr 29, 2004, at 4:05 PM, Michael Richardson wrote: Okay, it has been years since I was on a v6-crippled system, so I didn't know that we weren't OS independant. Can we extract some in6_addr code from one of the BSDs and include that if we need it? That might work - one concern would be a collision on OSes that *do* define it, but we could either 1) check in the configure script whether it's defined by the OS and define it ourselves if not or 2) have our own structure for v6 addresses (that's what Ethereal does). 1) is a bit easier, and doesn't involve a large pile of changes to the code, so I'd be inclined to go that route if we can. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_stats
On Fri, May 21, 2004 at 02:06:57AM -0700, Guy Harris wrote: The DLPI code should *probably* add the dropped-packet count to the packets-received count, so as to reduce the differences between statistics (although it doesn't eliminate them - the right long-term fix is probably to introduce a new API that returns a set of tagged statistics values, so that if a given statistic can't be gotten from the packet capture mechanism it's not supplied by the API, so applications know what information they're getting). I've checked into the main and 0.8 branches of the libpcap CVS tree a change to do that. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] single packet capture time w/pcap vs. recvfrom()
On May 23, 2004, at 6:37 PM, Brandon Stafford wrote: I'm writing a server that captures UDP packets and, after some manipulation, sends the data out the serial port. Right now, I'm using recvfrom(), but it takes 20 ms to execute for each packet captured. I know that tcpdump can capture packets much faster than 20 ms/packet on the same computer, so I know recvfrom() is running into trouble, probably because of bad checksums on the packets. Is it a good idea to rewrite the server using pcap, It depends on the purpose of the server. If a received packet has a bad IP header or UDP checksum, it should get discarded at the IP or UDP layer, so that your application would *never* see it, not just see it after 20ms. If something out there causes the sender of the packet to retransmit it because it received no acknowledgments (because it was discarded by the IP or UDP layer, and thus not presented to a layer that would acknowledge it), with that happening after 20ms, then, if you use libpcap to read the packets, you'll see the initial bad packet *and* the retransmission. If that's what you want - i.e., if the server is supposed to log all the UDP packets in question, even if they have a checksum error - then it should use libpcap. However, if, in a case where a packet is retransmitted due to an error such as that, the server is supposed to log only the *valid* packet, then it's not clear using libpcap would provide any advantages. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] savefile.c patch
On May 26, 2004, at 1:55 AM, Gisle Vanem wrote:
I feel it's high time we cleanup some of the sources. I'd start
with savefile.c. Currently it doesn't work for offline data from stdin.
--gv
--- libpcap-2004.05.20/savefile.c Tue Mar 23 21:18:08 2004
+++ savefile.c Wed Mar 24 16:29:06 2004
@@ -52,6 +52,12 @@
#define TCPDUMP_MAGIC 0xa1b2c3d4
#define PATCHED_TCPDUMP_MAGIC 0xa1b2cd34
+#if defined(WIN32) || defined(MSDOS)
+#define SETMODE(file,mode) setmode(file,mode)
+#else
+#define SETMODE(file,mode) ((void)0)
+#endif
+
Perhaps it should just define SETMODE() as nothing - that would cause
SETMODE(file, mode);
to expand to
;
which, as a null statement, should be a valid statement.
Also, is setmode() sufficient with all the compilers that could be
used to compile libpcap/WinPcap on Windows (MSVC++, MinGW, etc.), or is
_setmode() needed with some compilers? (The code currently uses
_setmode().)
-#ifndef WIN32
- fp = fopen(fname, r);
-#else
fp = fopen(fname, rb);
-#endif
Presumably there are no interesting UN*X platforms left that wouldn't
ignore the b (Ethereal's library for reading capture files
unconditionally uses rb), so that should be OK.
- if(fp)
+ if(fp fp != stdin)
fclose(fp);
+ if (fp == stdin)
+ SETMODE (fileno(stdin),O_TEXT);
Why not just
if (fp) {
if (fp == stdin)
SETMODE(fileno(stdin), O_TEXT);
else
fclose(fp);
}
@@ -973,6 +981,7 @@
pcap_dump_open(pcap_t *p, const char *fname)
{
FILE *f;
+ pcap_dumper_t *pd;
int linktype;
linktype = dlt_to_linktype(p-linktype);
@@ -985,26 +994,23 @@
if (fname[0] == '-' fname[1] == '\0') {
f = stdout;
-#ifdef WIN32
- _setmode(_fileno(f), _O_BINARY);
-#endif
+ SETMODE(fileno(f), O_BINARY);
} else {
-#ifndef WIN32
- f = fopen(fname, w);
-#else
f = fopen(fname, wb);
-#endif
- if (f == NULL) {
+ setbuf(f, NULL);/* XXX - why? */
+ }
I'm not sure why we're setting the output unbuffered on Windows; even
if there's a legitimate reason to do so, I don't see any reason to do
so on UN*X - we really don't want to have the standard I/O library
routines make a separate write() call for every fwrite() etc. call
to the file.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] savefile.c patch
On May 27, 2004, at 5:22 AM, Gisle Vanem wrote: Since pcap_dump_close() doesn't have a pcap_t argument, where should the oldmode come from? Can we have two module globals; oldmode_stdin, oldmode_stdout, assuming stdin/stdout won't be opened for capture more than once? If it's opened for capture or dumping more than once in sequence, that's not an issue; if it's opened for capture or dumping more than once in parallel, that's not going to work anyway. As such, the two globals would probably be the best idea. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] How to extract the source name field data of
On May 27, 2004, at 11:56 PM, Jun-ichiro itojun Hagino wrote: Yes I am doing live capturing, but all what I interested about is the 16 byte Source Name field (Name to Add). I want to include the tcpdump command in my perl program so that I can make further processing on the data of that field. i would suggest you write a program using libpcap.a, rather than try to play with tcpdump output. Or that he modify an existing program using libpcap, namely tcpdump, to understand more NBF command types (such as ADD_NAME_QUERY, which his packet appears to be), and then send us the patches so we can add that to a future release. The code is in netbeui_print() in print-smb.c; the smb_fdata() routine isn't documented, but it should be possible to figure out how the format strings work (the items in square brackets describe how to format the current field in the packet). The NBF packet formats are at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BK8P7001/ CCONTENTS tcpdump has to be run with -vv to get it to print the details of NBF packets. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcab and libpcap differences?
On Mon, May 31, 2004 at 03:45:04PM +0800, Bassam A. Al-Khaffaf wrote: As introduction for me to learn the network programming, anyone can tell me what is the difference between the pcap and libpcap? THe letters l, i, and b. :-) The name of the library is libpcap; sometimes people might just call it pcap, but they're just two names for the same thing. People might also refer to the capture file format produced by, and read by, libpcap as libpcap or pcap format; again, they're the same file format. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Are all traces captured by dag card in tcpdump
On Jun 4, 2004, at 1:09 PM, ice ice wrote: here is more information about tcpdump's output: % tcpdump -c 5 -n tcp -r 20020814-09-0-anon.pcap.gz 11:00:00.58 69.245.49.10.2082 143.173.237.247.1214: . 2133229289:2133230749(1460) ack 6821225 win 17188 (DF) 11:00:00.69 236.179.225.218.47302 241.46.188.127.www: . ack 3266262189 win 17520 nop,nop,timestamp[|tcp] (DF) 11:00:00.83 3.3.241.136.10646 252.224.52.109.1469: P 1396830536:1396830556(20) ack 446314422 win 9660 (DF) 11:00:00.97 3.3.241.136.10646 252.224.52.109.1469: . 4294965916:0(1380) ack 1 win 9660 (DF) 11:00:00.000102 3.3.241.136.10646 252.224.52.109.1469: . 4294964825:4294965916(1091) ack 1 win 9660 (DF) these output seems ok to me, so can I assume that the tcpdump can recognize the trace correctly? It appears so. I.e., it probably really *is* a Cisco HDLC capture. If so, that means the 48 byte is a correct number? It means that the snapshot length being equal to the payload length of an ATM cell does not imply that the capture is an ATM capture; I have no idea why the snapshot length was 48, though - perhaps that's what the DAG card supplied. It does *NOT* mean that every packet is 48 bytes long, however. So I guess I can just cast the following 40 bytes into what ever (TCP/UDP...) header it indicates. What following 40 bytes? The packets will have: 1) a 4-byte link-layer header; 2) some number of bytes of payload. The total number of bytes, *including* the 4-byte link-layer header, is the caplen value from the pcap_pkthdr supplied to the callback routine for pcap_dispatch() or pcap_loop() or pcap_next() or pcap_next_ex() (pcap_next_ex() is available only in libpcap 0.8 and later). If that value is 4, then the number of bytes of payload is that value minus 4. If the last two bytes of the 4-byte link-layer header, when treated as a big-endian number (i.e., don't just fetch it as a 2-byte integer - you'll get the wrong value on a little-endian machine, and note that x86-based PC's are little-endian machines) is equal to 0x0800, then the payload begins with an IP header. As the snapshot length is 24, the snapshot length will preserve the fixed-length portion of the IP header, but note that if there are IP options, the header could be larger than 20 bytes. Note also that there might be something *other* than the snapshot length that caused the entire header not to be present, so you should really check the caplen value. If it's present in the header (i.e., caplen is large enough to say it's there), use the protocol number field from the IP header to determine what type of header the IP payload begins with. Use the header length field of the IP header to determine where the IP payload begins; do *NOT* assume that the IP header is 20 bytes long. (If the header length is *less* than 20 bytes long, that's an error; you should check for that.) Also, note that the IP header has a total length field. The length of the IP payload is that value minus the IP header length - but if that value is greater than caplen minus (4 + IP header length), use caplen minus (4 + IP header length) instead. btw, to my understanding that I can not change tcpdump's output format, You can't do it without changing tcpdump - but you might want to use tcpdump as the basis for your program, as all the stuff I describe above, including handling multiple types of link-layer header, is already done by tcpdump, so you don't have to reinvent the wheel (or reinvent the flat tire by just crudely casting the packet data to an IP+TCP headeer or something such as that). I am currently reading the source code of tcpdump and try to figure out the way to parse through the packets. I am wondering whether there is some simple sample programs I can read or use in analyzing the pacekts? There's a limit to how simple a correct program can be; a correct program has to worry about the stuff I described above - there might be simple sample programs out there, but they might do something incorrect such as assuming the packet starts with a 14-byte Ethernet header (true only if the link-layer type of the capture is DLT_EN10MB), or that after the link-layer header is a 20-byte IP header (true only if the link-layer header says it's an IPv4 packet *AND* the IP header length is 20 bytes) or that after the IP header is a 20-byte TCP header (true only if the IP header says it's a TCP packet *AND* there are no TCP options). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Linktype needed
Martin Angler said: my name is Martin Angler and I am developing a BACnet MS/TP - enabled netdevice-driver under GNU/Debian Linux. Now I've seen, that there is no linktype that specifies BACnet MS/TP. So I wanted to ask whether you could define/implement a corresponding linktype. I infer from some stuff I've seen that BACnet MS/TP is a link-layer protocol atop which the higher-level BACnet protocols can run (just as they can run atop UDP and 802.2). Will your driver supply raw packets with a header specified by the BACnet specification (the ISO standard appears to cost over 350 CHF, so I haven't bought it), or will it supply some form of cooked software that might not be what other BACnet MS/TP capture mechanisms might supply? If the former, the linktype should probably be called DLT_BACNET_MS_TP or something such as that; if the latter, the name should probably have something in it to indicate what type of header it is (see, for example, DLT_ARCNET, which should perhaps have been DLT_ARCNET_BSD, and DLT_ARCNET_LINUX, or DLT_APPLE_IP_OVER_IEEE1394, which is not raw Firewire but has a synthetic header). Other people that worked on an MS/TP dissector (www.abmlinux.de) already tried to contact you, but without success. I don't think I've seen that on tcpdump-workers. Do they have their own driver and, if so, does it supply the same link-layer header (if not, it'd need a separate DLT_ value)? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Unexpected primitive ack DL_UNITDATA_IND
On Jun 9, 2004, at 1:58 PM, Rick Jones wrote: On the surface I wouldn't think so - simply attaching to a PPA I don't think means traffic could arrive - however, if one has attached, and then binds to a SAP, then traffic could indeed start arriving. (Il-informed guesstimation, and hopefully I'm recalling the correct distinction between attach and bind) Well, we *are* doing an info request after binding, so perhaps it might happen then. I'm not sure why we're doing that; it dates back to libpcap 0.4. Do you know of any reason why the dl_mac_type from an info request before binding to a SAP might be different from the dl_mac_type from a request after binding to a SAP? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap range no worky on ppc? (e.g. udp[2:2] = 137 udp[2:2] = 139)
On Thu, Jun 17, 2004 at 03:19:40PM +1000, Ben Low wrote: I attempted to use the following expression to filter netbios stuff: udp[2:2] = 137 udp[2:2] = 139 However this expression only captures port 137 packets on my two Power PC machines: - linux 2.4.18 ppc (debian) tcpdump version 3.8.3 / libpcap version 0.8.3 - OS X 10.3.4 PowerBook (fink) tcpdump version 3.8-cvs / libpcap version 0.8 It works as expected on an x86 linux box (tcpdump version 3.6.3 / libpcap version 0.6). Is this a pcap 0.8, or PPC (endianness?) problem? It's a pcap 0.8 problem: https://sourceforge.net/tracker/index.php?func=detailaid=940212group_id=53067atid=469577 There's no UDP port 139 NetBIOS-over-TCP stuff, so if you want NBT traffic, try udp port 137 or udp port 138 or tcp port 139 which shouldn't have a problem with that optimizer bug - and, for completeness, try udp port 137 or udp port 138 or tcp port 139 or tcp port 445 to catch CIFS-over-TCP (without the NBT layer). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] TCPDUMP filter for multicast
(I'm on tcpdump-workers, so there's no need to send mail to me *and* tcpdump-workers; if you have a question, it's better to ask tcpdump-workers than to ask only me.) On Sat, Jun 19, 2004 at 10:07:17PM -0400, Ernest L. Williams Jr. wrote: Could you tell me a tcpdump filter that only gives multicast? 'ether[0] 1 != 0' gives both multicasts and broadcasts; I only want multicasts. How about multicast and not broadcast - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap problems
On Jun 22, 2004, at 8:45 AM, Bowser Jason S Contr AFRL/IFTA wrote: I am writing some software that forks multiple process on a unix macine(IRIX) however when i have each child start the pcap_loop when i get to the 4th child and beyond i get the following error pcap_open_live snoop bind: Cant assign requested address However if i comment out the pcap_loop line the i dont get that error. I am opening the device (ef0) using promiscous mode if that helps I.e., you have four processes doing a pcap_open_live() on ef0 in promiscuous mode? You might want to ask SGI about this - perhaps there's a limit on the number of snoop sockets that can be bound to a particular network interface, although I have no idea why such a limit would show up only if you have a read in progress on the sockets. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Web page needs updating
On Jun 22, 2004, at 8:48 AM, Eddie Kohler wrote: The www.tcpdump.org section on mailing lists needs updating -- sending mail to '[EMAIL PROTECTED]' results in an error; it looks like the address has changed to '[EMAIL PROTECTED]'. I've checked in a change to replace @tcpdump.org with @lists.tcpdump.org - that'll presumably get propagated to the Web site at some point. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] text format stability
On Jun 25, 2004, at 2:21 PM, Christian Kreibich wrote: an XML based tcpdump output would be great in the long term -- it would certainly eliminate a lot of parsing ambiguity. Yes - the problem with the traditional UNIX the output of one program should be usable as input to another program idea is that this often means that the output of the program is made less friendly to people reading it, in a well-intentioned attempt to make it more parseable by another program, *but*, as the developer didn't want the otuptu of the program to be completely *unreadable* by humans, it's also not in a form that's all that convenient for scripts to parse, so you end up with something that attempts to serve more than one master and doesn't serve either all that well. XML output isn't particularly pleasant for humans to read, but there's a lot of software out there that can presumably consume it fairly easily; tcpdump could offer a choice of XML output (which wouldn't be designed with much care for ease of reading by humans, but would be relatively straightforward for a program to parse) or human-oriented output (which could change its format over time if that makes it more readable by humans, and wouldn't have to be particularly easy to parse in a script). Along those lines, Tethereal currently offers the ability to output either one-line summary information, a detailed multi-line parse, *or* PDML XML-based dissection for packets. See http://analyzer.polito.it/30alpha/docs/dissectors/PDMLSpec.htm for the PDML specification. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Corrupt files
On Jun 25, 2004, at 4:34 PM, Xavier Brouckaert wrote: Could it happen because there are several applications using libpcap at the same time ? Not if they're writing to different files. There's no data that would be shared by all libpcap-using processes on a given machine. If multiple applications, or multiple threads in a given application, are writing to the same file, yes, it could easily happen. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] 3-clause vs. 4-clause BSD license for {libp,WinP}cap and {tcpd,WinD}ump
On Jun 28, 2004, at 1:21 PM, [EMAIL PROTECTED] wrote: We would like to include WinPcap and WinDump on the Windows Toolbox compilation of software but your licencing restrictions present a problem. The clause we have difficulty with in particular is this: all advertising materials mentioning features or use of this software display the following acknowledgement: This product includes software developed by the Politecnico di Torino, and its contributors. Furthermore, as WinPcap is based on libpcap and WinDump is based on tcpdump, the licenses for libpcap and tcpdump are also involved - and those licenses also have the 4-clause Berkeley license, complete with the must display the following acknowledgment third clause (or, as the Free Software Foundation's software license page calls it, the obnoxious BSD advertising clause). The copyright notice says the software in question is copyright by the Regents of the University of California, and within the past few years they changed the license on the BSD software to remove the third clause. However, I don't know if that applies to the parts of libpcap and tcpdump developed at Lawrence Berkeley Laboratories, or only to BSD itself. In addition, some code in libpcap and tcpdump might have the copyright owned by others, but still have clause 3 in it; if so, we'd have to ask those contributors whether they'd be willing to remove that clause. I don't insist that any of the code *I've* written for libpcap and tcpdump have clause 3 in it, but I can't speak for all the contributors. I *suspect* that most, and probably all, of the contributors whose code is under the 4-clause license wouldn't object to removing clause 3, but I don't know whether it's proper (or even legal) to just remove that clause without asking them. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] linux pcap blocking and cpu utilization
On Jun 28, 2004, at 12:10 PM, four wrote: Here is the situation: I am trying to build a simple bridging program. If I use pcap_set_nonblock() the function call returns fine, but the program ends up using 100% cpu utilization, presumably because it is simply looping and returning with no packets caught. So the other way is to just have the call wait for a certain packet count. No, the other way is to have *a* call wait until packets arrive. On most UN*X platforms, the calls that can be used to do that are named select() and poll(). In libpcap 0.8 and later, the pcap_get_selectable_fd() call will return a descriptor on which you can do a select() or poll() - unless, on the platform on which you're running, you *can't* do a select() or poll() to wait for packets to arrive, in which case it returns -1. The cases where it returns -1 are: 1) FreeBSD 4.3 and 4.4, where the workaround for the fact that select() and poll() don't work correctly on BPF devices doesn't work, either; 2) Linux and BSD, when capturing on a DAG card from Endace, because the drivers for DAG cards unfortunately don't support select() or poll(). If you're capturing on regular interfaces, select() and poll() should work just fine on the PF_PACKET sockets used for normal capturing. Prior to libpcap 0.8, there is no pcap_get_selectable_fd() call - but, if you're not going to run on BSD or capture on DAG cards, you can just use pcap_fileno(). (Ideally, you should, if you want to ensure portability, use autoconf to test whether pcap_get_selectable_fd() exists and, if it doesn't supply a substitute version that returns -1 on FreeBSD 4.3 and 4.4 and the result of pcap_fileno() otherwise, and use pcap_get_selectable_fd() in your program.) But this doesn't work either because if no packets are coming one way down the wire, but we have recieved some in the other direction, the (singly threaded) program will block on the one direction. So I want to make a simple program that listens and forwards on two interfaces... what is the proper way to implement this on linux so that it doesn't use all the CPU and doesn't require multiple threads? Open both interfaces, use pcap_get_selectable_fd() (or pcap_fileno() if pcap_get_selectable_fd() isn't available, as per the above), and, in the main loop, select() or poll() on both FDs and process input if the select() or poll() call says it's readable. (If the program is to run on BSD, put both pcap_t's into non-blocking mode, supply the timeout used in the pcap_open_live() call as the timeout for select() or poll(), and read from the descriptor regardless of whether it's marked as readable or not; that's the workaround for select() and poll() not working correctly on BPF devices. As noted, that workaround probably doesn't work on FreeBSD 4.3 and 4.4, but it works on earlier releases, and select() and poll() should, I think, work correctly on BPF devices in 4.5 or later. On other BSDs, I think that, depending on the BSD and the release, either the workaround will work or won't be necessary - meaning that select() and poll() will work correctly, even if you *do* use the workaround - or both.) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap and Super User mode
On Jun 30, 2004, at 10:00 AM, Jefferson Ogata wrote: More specifically, you can use libpcap as any user. On most systems, you have to be root, however, to monitor traffic on a network interface. I.e., you can use libpcap to read a capture file as any user (if that user has permission to read the capture file in question), but you might have to have privileges of some sort (see the tcpdump man page for what we believe to be the current set of privileges required on various platforms) to do live captures. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] text format stability
On Jun 30, 2004, at 12:58 PM, Michael Richardson wrote: How widespread is PDML? Tethereal and Ethereal can generate it; I presume the intent is to have Analyzer 3.0 generate it as well, given that it was invented by the Politecnico di Torino folks. (I don't see anything immediately obvious on the Analyzer site saying it can generate PDML or PSML.) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] text format stability
On Thu, Jul 01, 2004 at 07:34:44AM +0200, Fulvio Risso wrote: Ethereal is able to prodice PDML output (altough it uses a slightly modified dialectn of PDML). What are the modifications? (Note that one problem is that PDML's field names come from the NetPDL specification for the protocol - this means that either 1) a different NetPDL spec for the protocol or 2) a dissector not using NetPDL - for example, created before NetPDL existed might result in different field names.) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] PCAP - IP Fragments
On Jul 1, 2004, at 2:50 AM, [EMAIL PROTECTED] wrote: tcpdump doesn't have any specific facility to handle fragmented packets, as far as I know (it cannot reassemble the fragments). That capability could be added (Ethereal supports it), although, if provided, it should be an option (as reassembly would consume extra memory - it's an option in Ethereal). However, that wouldn't help in the packet filtering; neither tcpdump nor Ethereal nor any other program using libpcap/WinPcap to capture traffic can arrange, with a capture filter, to capture all fragments of traffic between two particular transport-layer endpoints, because BPF isn't stateful and can't remember that, if it sees the first fragment of a fragmented IP datagram, it should capture all other fragments between those two IP addresses with the same IP ID. I.e., tcpdump *doesn't* handle that (and neither does Ethereal). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] jump to a packet flag
On Jul 1, 2004, at 12:18 PM, alex medvedev wrote: this, however, does not work well with relative seq numbers in tcp packets [maybe smth else too?]. Anything that maintains and uses state information between packets wouldn't work. However, what could be done would be something that still runs the dissection code on the packet but that suppresses printing; currently, that's not easy to do, as the dissectors just call printf(), but if, as is being considered, we construct a data structure in the dissector and then print information from that data structure (either in a human-readable form or in some XML or otherwise standardized form to be passed to other programs or scripts), we might just be able to omit the last step. That's more expensive than just ignoring the first N-1 packets with -j N, but stuff requiring state continues to work. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] patch for print-ppp.c
On Jul 5, 2004, at 3:13 AM, Darren Reed wrote: Looks better if its compressed PPP data :) Checked in, with compressed PPP data - and with another change to use ppptype2str[] in the default case. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] core dump with PPP messages 1 byte long.
On Jul 5, 2004, at 4:51 AM, Darren Reed wrote: If ppp_hdlc() is called with length 2, bad things happen. Should it be called *at all* from handle_ppp()? Or, if this is really just HDLC-over-L2TP, in which case it should be called directly from t http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-pwe3-hdlc-03.txt (which is for L2TP version 3, but perhaps there were similar, perhaps private, ways of negotiating the transport of HDLC rather than PPP over L2TP in V2; http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tp-base-14.txt says The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism for tunneling Layer 2 (L2) circuits across a packet-oriented data network (e.g., over IP). L2TP, as originally defined in RFC 2661, is a standard method for tunneling Point to Point Protocol (PPP) [RFC1661] sessions. L2TP has since been adopted for tunneling a number of other L2 protocols. so perhaps HDLC was one of the L2 protocols in question, with PPP running atop it in this case) should it be called from l2tp_print(), which would check for stuff that looked like HDLC rather than PPP and directly call ppp_hdlc()? Or is that heuristic insufficient - in the example you gave, you indicate that the packet might be an empty PPP_VJNC packet rather than an HDLC-over-L2TP packet? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] LLC protocol, ethereal and pcap libraries get along togheter?
On Jul 7, 2004, at 10:44 AM, Claudio Lavecchia wrote: Writing a packet dissector based on pcap libraries on Linux and using it to sniff traffic going through a WLAN (dell truemobile 1150 with orinoco driver) card I noticed a really strange behaviour. The card is set in promiscous mode, and I used Ethereal to dump the sniffed packets in a user-friendly way to further investigate what was going on. What I observe is that the card sniffs packet that follow either the 802.3 (RFC 1042) encapsulation or the ethernet (RFC 894) encapsulation, In Ethereal, do these look like Ethernet packets (6-byte destination address, 6-byte source address, 2-byte type/length field) or do they look like 802.11 packets (2-byte frame control field with a type and flags byte, 2-byte duration field, 6-byte destination addres, 6-byte source address, etc.)? If they look like 802.11 packets, the ones using Ethernet encapsulation might be sent by some bridges that forward Ethernet packets inside 802.11 packets. The standard encapsulation for 802.11 is the RFC 1042 encapsulation, with an 802.2 header. If they look like Ethernet packets, that's because the card or the driver is converting 802.11 packets into fake Ethernet packets, and they might map packets not using SNAP with an OUI of 0 into RFC 1042-style packets. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Bad TCP header len question
On Thu, Jul 08, 2004 at 11:38:33AM +0200, rmkml wrote: Possible add detect tcp header len pb in tcpdump ? I've added those checks to the x.8 and main branches in the tcpdump CVS tree. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] error-message IP11 truncated-ip in last tcpdump/libpcap
On Jul 13, 2004, at 7:56 AM, Klaus Schrod wrote: Again our situation: Two computers connected to the net, one (lion) with a fixed ip address and one (styx) with pppoe. We established an ipsec tunnel between them successfully. tcpdump showed an error in the ESP traffic between styx and lion. But the error messages changed depending on the computer which sent the first packet after the ipsec tunnel is initiated. The errors appear only on styx, the pppoe side of the connection. tcpdump on lion shows the correct (and expacted) ESP traffic. On what type of interface are you capturing on lion? A regular Ethernet interface? If the first package (in my case a ping) came from lion the error message of tcpdump was IP7 bad-hlen 12. In one case I saw also a IP3 bad-hlen 8 message. There is no truncated-ip message in this case. Ethereal's seeing similar problems. The traffic from 217.234.111.121 to 62.225.140.214 has, as the protocol layers: Linux cooked capture IP ESP whereas the traffic from 62.225.140.214 to 217.234.111.121 has Linux cooked capture IP with a protocol type of IP-inside-IP IP (with a bogus version number of 3 and a bogus header length of 8) It *might* be that the traffic from 217.234.111.121 to 62.225.140.214 (which I infer is sent from styx to lion, as the Linux cooked capture header shows it as sent by us) is being shown as the ESP packets that are going on the wire, whereas the traffic from 62.225.140.214 to 217.234.111.121 is having the tunnel ESP headers stripped off, the tunnel IP header changed to say IP inside IP, and the payload *NOT* being decrypted. I.e., I suspect this is probably a problem with the way the Linux kernel is supplying packets to user-mode code such as libpcap. Googling for ipsec linux IPIP ESP tcpdump truncated found http://www.uwsg.iu.edu/hypermail/linux/kernel/0401.0/1410.html and http://braindamage.alal.com/archives/linux-kernel/20030922/7627.html which looks as if they might be similar problems. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] error-message IP11 truncated-ip in last tcpdump/libpcap
On Jul 13, 2004, at 11:51 AM, Guy Harris wrote: whereas the traffic from 62.225.140.214 to 217.234.111.121 has Linux cooked capture IP with a protocol type of IP-inside-IP IP (with a bogus version number of 3 and a bogus header length of 8) The second capture is similar - and in both cases, the packets with a problem have a bad IP header checksum. The packets are being received by the host doing the capturing, so that's presumably not a result of checksum offloading. I suspect that the Linux networking stack is helpfully rewriting the headers to have IPIP rather than ESP as the protocol, and not changing the checksum (it'd be interesting to see whether changing the protocol field back to 0x32 makes the checksum correct), as I'd suggested in my previous message. It might be that the Linux IPsec implementation is doing that. Several pieces of Linux networking code appear to have the annoying habit of updating skbuffs in place without somehow arranging to do a copy-on-write if the traffic is being handed to a PF_PACKET socket, so that tcpdump and Ethereal and other packet capture applications don't see packets as they were received by the machine, they see them as modified in-place by the networking stack. I think that's been seen for the Token Ring, AppleTalk, and NFS code (there are workarounds in Ethereal for Token Ring and AppleTalk; there is, as I remember, no workaround even *possible* for NFS); IPsec might be another offender here. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] windump options 4 writing in a *.txt file
On Jul 13, 2004, at 12:44 PM, César Cárdenas wrote: It is possible to write raw packets in a *.txt file? That depends on what you mean by raw packets. Packet data is binary, so that wouldn't go into a .txt file. The packet data can be dumped in hex and/or ASCII, and that could be put into a text file. I've already tried with: windump -w test.txt windump -w test.txt windump -w test The -w flag writes raw packets, which are in a form that is not text. It can be read by tcpdump/WinDump, Ethereal, Analyzer, and a number of other applications that read the libpcap capture file format. If what you want is the textual dissection of the packet, such as would be printed if you ran tcpdump/WinDump with no command-line options, you could do windump test.txt If you want the hex or ASCII dump of the raw packet data as text, you could try the -x and -A flags. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Changing filter condition dynamically works fine on Windows but fails on LINUX
On Jul 19, 2004, at 6:57 AM, Alex Narinsky wrote: I need to change the filter condition dynamically. So I have another thread that changes filter expression. This code works fine on Windows changing the filter condition. On LINUX if I change a filter condition no packages come anymore through pcap_next. There might be a bug in the version of libpcap on that version of whatever Linux distribution you're running. What version of what distribution of Linux (*distribution* version, not *kernel* version) are you using, and what version of libpcap does it have? As that's not on Windows, this should probably be discussed on tcpdump-workers, so I'm sending it there and setting the Reply-To: header appropriately. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] convert back to expression
On Jul 20, 2004, at 1:32 AM, Li Ruzhen wrote: hi, whether i can use libpcap to optimize some complicate expressions and then conver the optimized result back to the expression format? If by expressions you mean filter expressions, no, you can't - there's no code that takes a BPF program (which is the output of the compiler, including the optimizer) and turns it back into a filter expression. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Errors in gencode.c building on HP-UX 11.11.
On Jul 20, 2004, at 10:40 AM, [EMAIL PROTECTED] wrote: gcc -O2 -I. -DHAVE_CONFIG_H -D_U_=__attribute__((unused)) -c ./gencode.c In file included from gencode.c:73: pf.h:66: syntax error before sa_family_t Which version of libpcap is this? 0.8.3? And what are the contents of the config.h and config.log files? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Building IPv6 code in tcpdump on systems without native IPv6 support
I have some changes to support that. The main change is to add a union h6addr to tcpdump-stdinc.h, along with defintions of IN6_IS_ADDR_UNSPECIFIED, AF_INET6, and NI_MAXHOST if they're not defined. Some side-effects of this: 1) it defines DEFAULT_SNAPLEN as 96 unconditionally, rather than, as is done now, as 68 if INET6 isn't defined and as 96 if it is defined; 2) bgp_update_print() can't decode the unfeasible routes, as it doesn't know whether this is for a v4 or v6 route (currently, if INET6 isn't defined, it assumes a v4 route, but if it is defined, it doesn't try to decode them). The first seems OK to me, although some might find it a surprise. You can always use -s 68 if you want 68 bytes. I'm not sure what the right thing to do about the second side-effect is. Have a command-line option to control how to decode them? (Note that if v6 routes are printed by a v4-only build of current tcpdump, it'll decode them incorrectly.) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Building tcpdump 3.8.3 undex Solaris 2.9
On Tue, Jul 20, 2004 at 03:25:03PM -0400, Michael Richardson wrote: Guy == Guy Harris [EMAIL PROTECTED] writes: Guy Michael, should we put out a libpcap 0.8.4/tcpdump 3.8.4 Guy release with the fixes that have been added since then? I guess. Are there other things that should be slipped in? Well, what's currently in the x.8 branch for libpcap, past 0.8.3, are: 1) some WinPcap fixes; 2) a fix for systems lacking snprintf(); 3) some fixes for systems using DLPI (Solaris and HP-UX); 4) a fix for IRIX (or maybe it's UNICOS); 5) a fix for what might have been a compile error similar to the one the person saw on HP-UX; and, for tcpdump, past 3.8.3, are: 1) a fix for the inet_aton configure problem; 2) a fix that might be the one the person saw on HP-UX; 3) some ICMPv6 and DHCPv6 updates; 4) some other fixes (option-processing fixes in IPv4, pflog updates, PPP crash fix, header length sanity checks in TCP, etc.). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Tcpdump time discrepancy (vs ethereal/tcptrace)
On Jul 22, 2004, at 1:47 PM, Aaron Mitchell wrote: I've noticed a peculiar behavior. Given the same hand-crafted dump file (with an intended time of 5:36 on Jan 1, 1970), tcpdump reports a time of 6:36 for default output, and a time of 10:36 when run with the - option (supposedly same time with date info prepended). Both ethereal and tcptrace report the predicted time of 5:36. Funny, Ethereal says 2:36 here. Perhaps my being in California and you presumably being in Ohio has something to do with that. :-) Mac OS X 10.3.4's tcpdump says 3:36, and says 10:36 with -. Current CVS top-of-tree tcpdump says 3:36 in both cases, as does current CVS x.8 tcpdump; the problem with - is a bug fixed after the version used in OS X 10.3.4 (3.8.3) was released. The 2:36 vs. 3:36 problem is due to tcpdump, for some reason, converting times by getting the offset from UTC at the time the capture starts, and using that. That works fine if you're running a live capture (*and* that capture doesn't span a standard - summer time change...), but doesn't work as well if you're reading from a capture file made at a time when the local offset from UTC was different from what it is now. In most of the US and Canada, it's currently Daylight Savings Time, but it wasn't DST there in January 1, 1970, hence the problem. I assume the rationale for the time conversion being done that way is that it's faster than using localtime() (and/or perhaps a desire to have it use the same offset throughout the capture, if there are any post-processing scripts that parse the times and do arithmetic on them - but those scripts should be using -tt, which gives you raw seconds and microseconds) and that the speedup made something work well that wouldn't work well if localtime() were used. If that's still valid, we should probably have it set thiszone to gmt2local(time stamp of first packet) after reading, but before processing, the first packet, so the offset from UTC is appropriate to the time of the first packet, not to the time when tcpdump called time() in gmt2local(). If that's *not* still valid, we should just use localtime() and be done with it. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap on AIX 5.2
On Jul 29, 2004, at 1:11 PM, Lowrie, Tom wrote: Adding -lcfg along with -lodm solves my problem. Thanks for the push in the right direction. Next step will be to figure how to compile the libpcap source so that these libraries are included. The standard libpcap build procedure in the main CVS branch supports shared libraries only on: platforms using the GNU linker; Mac OS X; because it hasn't been libtoolized, and the 0.8 and earlier build procedures don't support it at all. This means that, unless building a library with ar produces a shared library on AIX (which it might do), you only get an archive library. I don't know whether an archive library on AIX can be linked with other libraries, and don't know whether building a shared library in AIX and linking it with other libraries means you can link an application with that library and automatically get it linked with the libraries with which that library was linked (that works in, as I remember, the SunOS 4.x shared library mechanism, and thus it might also work with the SVR4 shared library mechanism, derived from the SunOS 4.x one, and used in Linux and the ELF-based BSDs as well). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Better dumping of packets with bad TCP checksums?
On Jul 30, 2004, at 10:14 AM, Greg Weiss wrote: Is there a way to command-line filter tcpdump so that only packets with bad TCP checksums are dumped? No. The BPF filtering mechanism can't handle it, as there's no way for it to compute a checksum, and the filtering mechanism is BPF-based. A separate mechanism could probably be added in tcpdump - note that it won't work if you use a snapshot length shorter than the full length of the packet (because the checksum can't be computed unless you have all the data) or if the TCP segment is fragmented at the IP layer, and it wouldn't do anything useful for packets sent by the machine running tcpdump (and, in fact, might have to forego checking those packets if the interface on which they're being sent does TCP checksum offloading). In order to support a short snapshot length, there'd have to be OS kernel changes to do the check in the kernel *and* supply the results of the check to libpcap (e.g. a BPF instruction to do a checksum check), or, if checksum checking were done, the snapshot length used when getting packets from the kernel would have to be something large enough to get the entire packet, and the packet would have to be cut off in userland. Is there a particular tool/approach anyone would recommend for flagging/logging the existence of incoming corrupted TCP/IP packets? An intrusion detection system, if sufficiently user-configurable, might support that. (It'd have to look at all the incoming TCP packets to do that.) P.S. Sentence 2 in the man page should refer to the -r flag, not the -b flag, right? In tcpdump 3.7.2 and later, it *does* refer to the -r flag; it referred to -b in 3.7.1, but 3.7.2 fixes a problem in the ISAKMP parser for which there's a security advisory. The current version is 3.8.3; hopefully no current version of any OS is shipping 3.7.1. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] advice for heavy traffic capturing
On Mon, Aug 09, 2004 at 01:08:49AM +1000, Darren Reed wrote: In some email I received from Fulvio Risso, sie wrote: Darren, could you please give us some numbers? If you take a look at this paper: F. Risso, L. Degioanni An architecture for high performance network analysis http://ieeexplore.ieee.org/iel5/7446/20240/00935450.pdf?tp=arnumber=935450; isnumber=20240arSt=686ared=693arAuthor=Risso%2C+F.%3B+Degioanni%2C+L.%3B I don't have an IEEE login. Feel free to email it to me. Several papers - including, it appears, that one - are available from links on http://winpcap.polito.it/docs/default.htm - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 'tcpdump -s0' payload length limit?
On Aug 25, 2004, at 11:05 AM, David Front wrote: 11:33:55.601653 IP lxfs5623.cern.ch.32962 lcgmon002d.cern.ch.12509: UDP, length: 1637 UDP, length: 1637 means that the *UDP* packet length is 1637 bytes. That doesn't mean that the *Ethernet* packet is 1637 bytes, as you note later: IP message may consist of a few Ethernet messages. A 1637-byte UDP message will be put inside a single IP message - but if you send that over Ethernet, it will be split into two fragments, each one in a separate Ethernet message. Tcpdump doesn't reassemble fragmented IP datagrams, so it'll only print the data in the first fragment. Please update me if there is a way to work around the problem, or if this is a tcpdump problem. It's a tcpdump problem (having nothing to do with truncating Ethernet packets - the Ethernet packet packet really *is* that short), but there is a workaround - use a network analyzer that *does* reassemble fragmented IP datagrams. Ethereal and Tethereal will reassemble fragmented IP datagrams, if configured to do so. Note, however, that the reassembly is *NOT* done at the low-layer capture level, so a capture filter of port 12509 will only capture the first fragment of a fragmented datagram, and Ethereal and Tethereal will *NOT* be able to reassemble the packet. You would have to specify a filter that looks only at the IP headers, such as a filter that checks for UDP, or that checks for UDP traffic between two particular hosts, in order to capture *all* the fragments. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 'tcpdump -s0' payload length limit?
On Aug 25, 2004, at 11:09 AM, Guy Harris wrote: Note, however, that the reassembly is *NOT* done at the low-layer capture level, so a capture filter of port 12509 will only capture the first fragment of a fragmented datagram, and Ethereal and Tethereal will *NOT* be able to reassemble the packet. You would have to specify a filter that looks only at the IP headers, such as a filter that checks for UDP, or that checks for UDP traffic between two particular hosts, in order to capture *all* the fragments. Or you could use a filter that captures traffic to/from port 12509 *or* that has a non-zero fragment offset, so it captures port 12509 traffic *and* all fragments other than first/only fragments. That might capture fragments that you don't need, but that's the best you can do. Constructing such a filter is left as an exercise to the reader. Such a filter, used with tcpdump, would get the subsequent fragments; tcpdump wouldn't reassemble them, but it'd at least print them, which might be enough. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] undesired promiscuous mode toggling
On Aug 26, 2004, at 3:43 PM, Chris Reining wrote: I am running into an interesting promiscuous mode issue on Redhat Enterprise WS 3, kernel version 2.4.21, libpcap version 0.7.2 and tcpdump 3.7.2. The issue is unanticipated toggling of promisc state. I am running Snort version 2.1.2 which itself sets promisc first on the interface in question and may be a catalyst for the issue or a red herring. So, in a default state we have the interface in PROMISC as set by Snort. I am using 'ip link show eth0' as ifconfig does not show the PROMISC flag yet: *Which* PROMISC flag? I think Linux has both a flag you can set with ifconfig and an internal PROMISC flag. Libpcap, when built on a system on which PF_PACKET isn't defined even if you include all of sys/socket.h, sys/ioctl.h, net/if.h, netinet/in.h, linux/if_ether.h, and net/if_arp.h (it's probably defined by sys/socket.h) *or* on which PACKET_HOST isn't defined if you include all of them *and* linux/if_packet.h, or when run on a socket without PF_PACKET sockets but with PF_INET/SOCK_PACKET sockets, will use the flag you can set with ifconfig, as it assumes that the newer mechanism for setting the flag doesn't exist. 2.2 and later kernels should, I think, not have PF_INET/SOCK_PACKET sockets if they don't have PF_PACKET sockets, so that's probably not the problem. Systems with 2.2 and later kernels *probably* have headers that'll cause PF_PACKET and PACKET_HOST to be defined. With PF_PACKET sockets, the mechanism libpcap uses to turn promiscuous mode on and off is setsockopt() calls at level SOL_PACKET, using the PACKET_ADD_MEMBERSHIP option to set the mode to PACKET_MR_PROMISC or PACKET_MR_ALLMULTI. I don't know what the semantics of that are. (I'd have to look at the Linux kernel source once again.) It might be that the interface is put into promiscuous mode if at least one socket with PACKET_MR_PROMISC is open, or it might be that it just remembers the *last* request. Now, if Snort and tcpdump are running with the same version of libpcap, they use the same mechanism, so it shouldn't matter whether you're running two Snorts, two tcpdumps, or a tcpdump and a Snort. If they're running with different versions of libpcap, they *might* be using different mechanisms. WS 3 is probably new enough that libpcap will be using the new mechanism. If the interface is already in promisc mode, as Snort has set it, why is tcpdump turning that off? Probably a kernel bug (or a wacky, but deliberate, notion of how PACKET_ADD_MEMBERSHIP should work). Why when running multiple, and the same, tcpdumps does the promisc flag get flipped back and forth in relation to how many tcpdumps are running? See answer to previous question. Overall, shouldn't tcpdump (without -p) check if the interface is in promisc mode already (as Snort has set it or another tcpdump) and if so, not toggle that setting? Tcpdump should call pcap_open_live() with the the promisc flag being 1 if it's run without -p and 0 if it's run with -p. That's all it should do with the promiscuous flag. Any stuff done to the interface's promiscuous flag should be done by *libpcap*, not tcpdump; otherwise, you have 1) crufty code in tcpdump and 2) applications *other* than tcpdump possibly exhibiting the same behavior. However, this might ultimately be a bug in the kernel networking code. Unfortunately, I can not reproduce this behavior all the time. In some cases running 'tcpdump -i eth0 -nn' on an already promisc interface does not toggle promisc off. That is the behavior that I am familier with and expect. Any insight much appreciated. I'd suggest 1) using the standard tcpdump that comes with WS 3 (which you might already be doing); 2) reporting this as a bug to Red Hat. Either 1) the kernel has a bug in the way PACKET_ADD_MEMBERSHIP is implemented, in which case it should get fixed or 2) libpcap isn't using PACKET_ADD_MEMBERSHIP correctly, in which case *it* should be fixed (and if RH fixes it, they should send us the fixes so they can go into a future release of libpcap). (Oh, and they should update the packet(7) man page to make it clearer how that stuff is supposed to work.) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Bug Fix in tcpdump 3.8.3
On Sep 3, 2004, at 3:48 AM, Sebastien Vincent wrote: So I made changes into ./tcpdump.c and it now works fine. Checked in. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] compilation status of current (2004-09-13) on HP-UX 11.11
On Sep 13, 2004, at 4:24 PM, Rick Jones wrote: For other nefarious porpoises I downloaded libpcap and tcpudmp currents on 2004-09-13 and did straight-up ./configure;make on HP-UX 11.11 (aka 11i v1) using the HP compiler. This system did not have the TOUR installed to get IPv6 functionality. The libpcap compiled cleanly. Just a couple warnings IIRC, and nothing that looked earthshattering. The compilation of tcpdump was clean. This is a big step from the last time I tried. The linking of tcpdump was not clean: ... /usr/ccs/bin/ld: Duplicate symbol pcap_list_datalinks in files datalinks.o and ./../libpcap/libpcap.a(pcap.o) /usr/ccs/bin/ld: Duplicate symbol pcap_datalink_val_to_name in files dlnames.o and ./../libpcap/libpcap.a(pcap.o) /usr/ccs/bin/ld: Duplicate symbol pcap_datalink_name_to_val in files dlnames.o and ./../libpcap/libpcap.a(pcap.o) /usr/ccs/bin/ld: Duplicate symbol pcap_datalink_val_to_description in files dlnames.o and ./../libpcap/libpcap.a(pcap.o) It appears that the configure script did not correctly determine that the libpcap with which to link tcpdump already had the functions in question, so it set up the Makefile to build tcpdump's fallback implementations of them. Could you send us the config.log file from the tcpdump directory? PS - I'm looking for worked examples of reconstructing a TCP stream (separate each way is fine/preferred) from a tcpdump format (binary) trace. Well, there's the Ethereal code for Follow TCP Stream, but it drags in a lot of the Ethereal framework. You might look at tcpflow: http://www.circlemud.org/~jelson/software/tcpflow/ - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] performance considerations
Shaun wrote: Or get a DAG card? Not sure if they support FreeBSD though. http://www.endace.com/faq.htm#linux Q: Do you support any other operating systems than Linux? Do you support BSD or Solaris? A: Linux is the primary platform for the DAG product range, with robust support. A device driver and toolset is currently under development for FreeBSD, with a common user API. We have no plans to support other operating systems at this time. The Endace people have contributed DAG support to libpcap for both Linux and FreeBSD. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] compilation status of current (2004-09-13)
On Sep 14, 2004, at 10:33 AM, Rick Jones wrote: well, with the link in place, i did the make dist clean then the configure then the make and did get the duplicate symbols. so, here is the config.log ... configure:8312: checking for local pcap library configure:8420: result: ./../libpcap/libpcap.a configure:8445: checking for pcap_list_datalinks configure:8495: cc -o conftest -g -L/usr/local/lib conftest.c ./../libpcap/libpcap.a -lnsl 5 /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (conftest.o) was detected. The linked output may not run on a PA 1.x system. configure:8498: $? = 0 configure:8501: test -s conftest configure:8504: $? = 0 configure:8515: result: yes OK, so it thinks libpcap has pcap_list_datalinks()... configure:9005: checking if sockaddr struct has sa_len member configure:9029: cc -c -g conftest.c 5 cc: configure, line 9061: error 1588: sa_len undefined. cc: configure, line 9061: error 1531: Invalid member of struct or union. cc: configure, line 9061: error 1594: The sizeof operator cannot be applied to types with unknown size. configure:9032: $? = 1 configure: failed program was: | #line 9010 configure | /* confdefs.h. */ ... | #define HAVE_PCAP_LIST_DATALINKS 1 ...and it even defines HAVE_PCAP_LIST_DATALINKS as 1, meaning it *knows* it thinks that... ## - ## ## Output variables. ## ## - ## ... LIBOBJS=' strlcat$U.o strlcpy$U.o strsep$U.o' LIBS='-lcrypto ./../libpcap/libpcap.a -lnsl ' LOCALSRC='print-smb.c smbutil.c ' LTLIBOBJS=' strlcat$U.lo strlcpy$U.lo strsep$U.lo' ...and it even doesn't seem to think that it needs to use datalinks.o (which contains an implementation of pcap_list_datalinks() to use if libpcap doesn't have it). However, if it's getting a duplicate definition of pcap_list_datalinks(), it's apparently linking with it anyway. What is LIBOBJS defined as in the top-level Makefile? If it's defined as anything that includes datalinks.o, try doing a make distclean, re-running configure, and trying again. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] compilation status of current (2004-09-13)
On Sep 14, 2004, at 4:38 PM, Rick Jones wrote: no datalinks.o: LOCALSRC = print-smb.c smbutil.c GENSRC = version.c LIBOBJS = strlcat$U.o strlcpy$U.o strsep$U.o But you got duplicate symbol errors? What's the output of make? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] possible pcap-bpf.c uname usage bug
On Sep 15, 2004, at 12:37 AM, Matthew Luckie wrote: There is code in pcap-bpf.c to set the selectable fd to -1 if it is detected the OS is FreeBSD 4.3 or 4.4 I don't think the check actually successfully detects 4.3 or 4.4, as the osinfo.release parameter will have something like 4.3-RELEASE or 4.4-STABLE in it. Below is a patch to libpcap-2004.09.14 Checked into the main and 0.8 branches. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Trace conversion.
On Sep 17, 2004, at 3:20 PM, Paul Berube wrote: One question, though. I see h.m.s:ms, a.b.c.d.x:, and I'm wondering what the 'x' is? By the frequent occurences of 80, I'm guessing these are port numbers, but I'd like to be sure :) Yes. this won't work with icmp though... That's fine, I'm only interested in IP traffic. Presumably you mean IP traffic other than ICMP traffic, as ICMP traffic *is* IP traffic. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] final radiotap patch for tcpdump
(Blah blah blah work around duplicate message detector blah blah blah someday I'll figure out if I can configure Thunderbird to know that all tcpdump-workers mail should come from my alum.mit.edu address blah blah blah.) David Young wrote: Here is support for radiotap, an extensible radio capture header for 802.11, in its (hopefully) final form. I made the diffs from the CVS HEAD. The main difference from previous radiotap patches (such as those that appear in FreeBSD) is that it fixes some alignment problems. Any objections to my committing this to cvs.tcpdump.org? Looks good to me, at least for the top-of-tree (where we require that the platform support 64-bit integers, and where we define u_int64_t to be an unsigned 64-bit integer type). (I still hold out the hope that tcpdump can someday provide some alignment guarantee---radiotap is designed so that if the radiotap header is on a natural 64-bit boundary, then every field is on its natural boundary. One problem is that we currently don't require that tcpdump 3.x be linked with libpcap 0.x - adding an alignment guarantee to libpcap would require that tcpdump know whether the libpcap with which it's linked makes that guarantee. Also, in radiotap v2, I would like to capture in the native byte-order, but I haven't figured out how to interpret saved-packet files of different endianness.) pcap_is_swapped(p) returns true if the capture file you've opened was captured on a machine with a different byte order, based on the byte order of the magic number - if that matches the byte order of the radiotap values, that'd be sufficient. (It always returns false for live captures.) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] final radiotap patch for tcpdump
(blah blah blah duplicate posts blah blah blah thunderbird blah blah blah multiple accounts blah blah blah) Guy Harris wrote: Looks good to me, at least for the top-of-tree (where we require that the platform support 64-bit integers, and where we define u_int64_t to be an unsigned 64-bit integer type). Is the cpack.c stuff useful, or potentially useful, for anything other than the radiotap stuff? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Wrong tcp sequence numbers???
Claudio Lavecchia wrote: 3. How do you calculate size_ip? int size_ip = sizeof(struct sniff_ip); Do any of the packets have IP options? If so, then that's *not* the size of the IP header. You should get the IP header length from the header length/version field from the IP header (and should check that this field has a value = 5, meaning 20 bytes, as that's the minimum IP header length). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] Add ioctl to disable bpf timestamping
Matthew Luckie wrote: The motivation for this patch was to obtain something resembling the timestamp closest to when a packet I generated and transmitted hit the wire, to infer a more accurate RTT with an associated response packet. That's certainly a worthy goal, but the patch might not help much there - if you're getting time stamps for packets being transmitted by the machine running the BPF-based application, the time stamps you'll get are the time when the packet gets wrapped around by BPF in the driver, but there's more time spent in the CPU handing the packet to the network adapter and possibly time spent in the network adapter, especially if it has to wait for others to finish transmitting, or deal with collisions, on Ethernet, wait to get the token on a token-based network, etc.. It also wouldn't help get time stamps closer to the *received* time stamp, as it'd include time between the time when the last octet of the packet was received and when the driver handed it to BPF. On the other hand, one could perhaps argue that those times *should* be counted in RTT, if you're trying to measure application RTT rather than low-level link-layer RTT There is an argument to be made for generating the timestamp just the once after it actually passes a filter, I.e., so you don't spend CPU time generating the time stamp for packets that'll be discarded? That might be worthwhile, given that I think people have found that getting time stamps *can* be a bottleneck when capturing lots of traffic, so it might be a bottleneck if you're receiving a lot of traffic and discarding most of that traffic. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] x.9 branch
On Sep 24, 2004, at 6:02 AM, Hannes Gredler wrote: any suggestion for a x.9 branch date ? what about 31-oct-04 ? Speaking of x.9 branch, should the VERSION files in libpcap and tcpdump change to 0.9-PRE-CVS and 3.9-PRE-CVS, respectively? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Newbie user question: Getting packets from
(blah blah blah wrong from address blah blah blah duplicate message dissector blah blah blah time to see whether I can configure Thunderbird to automatically set the from address for tcpdump-workers messages blah blah blah) KEVIN ZEMBOWER wrote: www:~# tcpdump src host centernet.jhuccp.org and ip proto \\tcp or \\udp The tcpdump man page says: Primitives may be combined using: A parenthesized group of primitives and operators (paren- theses are special to the Shell and must be escaped). Negation (`!' or `not'). Concatenation (`' or `and'). Alternation (`||' or `or'). Negation has highest precedence. Alternation and concatenation have equal precedence and associate left to right. Note that explicit and tokens, not juxtaposition, are now required for concatenation. That perhaps doesn't state it as clearly as it could, but it means that and has higher precedence than or, which means that src host centernet.jhuccp.org and ip proto \\tcp or \\udp means (src host centernet.jhuccp.org and ip proto \\tcp) or \\udp which means that it matches packets that are either TCP packets from host centernet.jhuccp.org or UDP packets which means you'll see UDP packets regardless of whether they're from host centernet.jhuccp.org or not - which is why you're seeing those DNS packets. Try src host centernet.jhuccp.org and (ip proto \\tcp or \\udp) instead. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Newbie user question: Getting packets from
KEVIN ZEMBOWER wrote: As you can see, I'm still getting packets from ns1.jhmi.edu on the DNS port. What does the command tcpdump -d src host centernet.jhuccp.org and \( ip proto \\tcp or \\udp \) print? If it helps, I'm using bash 2.05 on a Debian woody (stable, 3.0) distro running kernal 2.4.18. The bash and kernel versions probably aren't the most important version numbers - the libpcap version is. What does tcpdump -h print? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Fw: new file format
Sorry I didn't get around to this until now, but
On Jul 30, 2004, at 1:09 PM, Gianluca Varenni wrote:
There is another issue related to these block types.
Fulvio's proposal:
a shb (even corrupted by the ftp transfer) can begin with the following
strings:
\r\n\r\x1A - 1 reserved block type
\r\n\n\r- 1 reserved block type
\n\r\x1a\?? - 256 reserved block types
\x1a\r\n\r - 1 reserver block type
\x1a\r\r\n - 1 reserved block type
\x1a\n\r\?? - 256 reserved block types
As a consequence we have 516 reserved block types (and we need at
least 6
checks to test if a block has one of these 516 special types). With 6
check
we are able to see if the block is a proper section (and its byte
order), a
ftp transfer error, or a normal block.
Gianluca's proposal:
a shb (even corrupted by the ftp transfer) can begin with the following
strings:
\r\n\n\r - 1 reserved block type
\n\n\r\?? - 256 reserved block types
\r\r\n\r(\n\r) - 1 reserved block type
I'm not sure what all the possible forms of damage can be; the most
common forms would be Un*x - Windows, which would *probably* turn
\r\n\n\r into \n\n\r?? for W-U and into \r\r\n\r for U-W, although
weirdness might happen if the last \r happened to be followed by \n,
and I don't know what particular Un*x FTP clients would do if they saw
\r\n or what particular Windows clients would do if they saw \n not
preceded by \r.
Other less-likely damage would be those with pre-OS X Mac OS clients
(which would think \r is the line ending) or other OSes, but those
don't support libpcap/WinPcap or tcpdump/WinDump or Ethereal or... as
far as I know, so I'm not sure they're worth worrying about.
As an SHB has to have a byte-order magic number in it, it's probably
likely that some other block type would not be mistaken for an SHB. If
non-private-use block types other than the SHB block type are assigned
starting at 0, they'll probably be small integers for a long time, so
none of the mangled SHB block types are, I suspect, likely to match
them; private-use block types have the high-order bit set, and if
they're also made 0x8000|{small integer}, that'll probably be safe
as well.
It might be interesting to try the most popular Windows, Un*x, and
written for OS X (as opposed to written for Un*x so they happen to
work on OS X) FTP clients - or, at least, the ones we have access to -
to see how they mangle things; trying HTTP clients might be interesting
as well. I'm not sure it's worth the effort, though.
As a consequence we have 258 reserved block types (and we need at
least 3
checks to test if a block has one of these 258 special types).
If the block type is \r\n\n\r we need at most two other tests to
look for
the byte order.
Two? I.e., checking for 0x1A2B3C4D and 0x4D3c2B1A at an offset of 8
from the block type?
If the block type is \n\n\r\?? or \r\r\n\r we need some tests (I
do not
know how many of them) to look for the byte order in the file and find
if
it's an invalid block or a ftp tranfer error.
In
http://www.tcpdump.org/lists/workers/2004/07/msg00128.html
I calculated that the byte offset of the byte-order magic would
probably be between 2 and 14 bytes from the beginning of the block
(i.e., from the start of the block type), so that'd be 13*2 or 26
tests.
Any final decision for this issue??
I'd vote for Gianluca's proposal. Anybody else?
Are there any other outstanding issues in the file format?
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Buffer size question
On Oct 18, 2004, at 3:04 PM, Alexander Dupuy wrote: Guy Harris writes: Unfortunately, given that, on systems with BPF, you cannot change the buffer size after a BPF device has been bound to a network interface, pcap_setbuff() is unimplementable on those systems, so it's not a candidate for libpcap. I didn't realize it was possible to set the buffer size with BPF; but indeed it is, and I see that it will even support sending up multiple packets from the kernel (on my FreeBSD 5.2 box at least), making the buffer size of some actual significance. Odd that the requirement that the BIOCSBLEN ioctl be performed before BIOCSETIF isn't documented anywhere, but I'll take your word for it (and even if this restriction were eliminated, other systems might have it). It's documented in the 4.4-Lite bpf(4) man page at http://www.freebsd.org/cgi/man.cgi? query=bpfapropos=0sektion=0manpath=4.4BSD+Lite2format=html where it says BIOCSBLEN (u_int) Sets the buffer length for reads on bpf files. The buffer must be set before the file is attached to an interface with BIOCSETIF. The various BSDs probably say the same thing (OS X definitely does). Some mechanism to supply that information at open time, whether it's an additional argument (which I think is the right long-term answer), a change to libpcap so that it doesn't reduce the buffer size below the default (which libpcap 0.8 already does), or an environment-variable I agree that an additional argument is the right long-term answer, but it does introduce API compatibility issues. Well, yes, to the extent that a new API would be introduced, and programs that need to work with older versions of libpcap can't use that new API. Including such an argument at the time the new API is introduced obviously doesn't introduce compatibility issues for that API. :-) (I'm actually thinking of an attribute/value list for various open options in the API, so that additional arguments can be introduced as desired without requiring API changes.) The functions we added are: int pcap_getbufsize(pcap_t *p, char *errbuf); int pcap_setbufsize(pcap_t *p, int bufsize, char *errbuf); both functions return -1, with error buffer filled in (if non-NULL) on error pcap_getbufsize returns buffer size on success pcap_setbufsize returns 0 on success Although we haven't implemented it, this can be generalized to accept a NULL pcap_t *p to get/set the default used for newly pcap_open()d handles, thereby allowing the BPF case to be supported as well. That's probably OK as a medium-term fix. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] help needed for sniffer in c++
akshar SNIFFER wrote: I am writing a sniffer in C++ , Then this is a question that belongs in the tcpdump-workers list, not the ethereal-dev list, so I'm redirecting it there. I have included the pcap.h header file .While compiling i get the following error / In file included from test.cpp:2: /usr/include/net/bpf.h:408: error: previous declaration of `u_int bpf_filter(bpf_insn*, u_char*, unsigned int, unsigned int)' with C++ linkage /usr/include/pcap.h:201: error: conflicts with new declaration with C linkage What OS are you building this on, and what version of libpcap does it have installed? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Problem compiling tcpdump-3.8.3
Gerard Beekmans wrote: tcpdump.o(.text+0x947): In function `main': : undefined reference to `pcap_debug' collect2: ld returned 1 exit status What does nm -o ../libpcap-0.8.3/libpcap.a | egrep pcap_dump print, and... Configure did check for, and found, pcap_debug: checking whether pcap_debug is defined by libpcap... yes ...what's the contents of the config.log file in the tcpdump source directory? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap and select problem
On Oct 25, 2004, at 1:27 PM, Ying Li wrote: Sometimes select() times out way too fast, like 0.0001 seconds while my timevar is set to 0.001 sec. Times out in the sense that retval is 0? On what OS are you doing this? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Can I excude a protocol?
Pete Wilson wrote: I'm a new user of tcpdump, so please forgive these few amateur questions. 1. I need to look at SNMP traffic, so I issue: node2:/root#tcpdump udp host node1 or node2 or node3 tcpdump: 'udp' modifier applied to host UDP doesn't know about hosts - that's IP's responsibility. UDP only knows about ports. If you want to see all traffic to or from particular hosts, use ip host node1 or node2 or node3. If you want to see all *UDP* traffic to and from particular hosts, use (ip host node1 or node2 or node3) and udp. If you want to see all UDP traffic to and from particular hosts *on a particular UDP port*, use (ip host node1 or node2 or node3) and udp port N. If you want, for example, UDP traffic to or from port 161, do (ip host node1 or node2 or node3) and udp port 161 - but, in that case, you can probably say udp port snmp rather than udp port 161. If you want traffic to or from two particular ports, use (ip host node1 or node2 or node3) and (udp port port1 or port2) - which can probably be udp port snmp or udp port snmptrap if you want ports 161 and 162. 2. I want to exclude certain protocols, like TCP. Is there any way to do it? I note that host takes logical operations. Anything like that for proto? (ip host node1 or node2 or node3) and not tcp although do you want to exclude TCP or exclude everything but UDP (or exclude everything but port-161 and port-162 UDP traffic)? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] dealing with collisions, dropped packets
Matt Van Mater wrote: Recently I've been investigating why tcpdump on my IDS shows quite a few packets as being dropped. Probably because it's receiving so many packets that it can't keep up. Drops, as reported by tcpdump, are drops due to the buffer in the packet capture mechanism overflowing due to tcpdump not being able to read packets fast enough. 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, It doesn't. It wouldn't even know about them unless the packet capture mechanism libpcap uses supplies that in a form libpcap can use in pcap_stats() (which I'm not sure is the case on any OS), and, even then, it doesn't report the ps_ifdrop statistic. If you want to know how many collisions an interface sees, you'd probably have to use some other program that gets a collision count from the network adapter. I also don't know whether it'd report collisions other than those from packets being sent on the adapter. Is there a way to get more fine grained statistics on why packets are dropped, That depends on the OS - there might be a command, or GUI tool, to get those statistics from the driver. and would collisions coming in off a hub be shown as dropped? They wouldn't be reported as dropped by tcpdump. Tcpdump would report only drops due to the buffer in the packet capture mechanism overflowing due to tcpdump not being able to read packets fast enough. As for other programs to report packet statistics, I don't know. A collision coming in off a hub is presumably a packet being transmitted by another machine on the network that gets stomped on by some third machine transmitting; I don't know whether an adapter would recognize and report that as a collision other than some other type of packet error, and don't know how they'd be reported. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Can I excude a protocol?
On Oct 31, 2004, at 6:15 PM, Pete Wilson wrote: although do you want to exclude TCP or exclude everything but UDP (or exclude everything but port-161 and port-162 UDP traffic)? Well, since you ask :-) Yes, sure. Then that's where the If you want to see all UDP traffic to and from particular hosts *on a particular UDP port*, use (ip host node1 or node2 or node3) and udp port N. If you want, for example, UDP traffic to or from port 161, do (ip host node1 or node2 or node3) and udp port 161 - but, in that case, you can probably say udp port snmp rather than udp port 161. If you want traffic to or from two particular ports, use (ip host node1 or node2 or node3) and (udp port port1 or port2) - which can probably be udp port snmp or udp port snmptrap if you want ports 161 and 162. from my earlier message would be used - that'd show only UDP port-161 and port-162 traffic (i.e., only putative SNMP traffic, although there could, I guess, be SNMP traffic on non-standard ports, or non-SNMP traffic on the official SNMP ports). If you want to exclude everything but UDP (which would give you non-SNMP traffic), that's where the If you want to see all *UDP* traffic to and from particular hosts, use (ip host node1 or node2 or node3) and udp. from my earlier message would be used. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Question about promiscuous mode
(Blah blah blah oops I did it again blah blah blah avoid duplicate message detection blah blah blah.) Kathy Chen wrote: I want to know in what situations the machine's network is set to promiscuous mode. It's put into promiscuous mode if an application requests that the interface be put into promiscuous mode. For example, I know when I execute tcpdump on my machine, it's set to be in promiscuous mode. Only if you run tcpdump without the -p flag; the default is promiscuous mode, but -p causes tcpdump not to put the interface into promiscuous mode. Any other cases? Ethereal and Tethereal will also put the interface into promiscuous mode by default; you'd have to use -p as a command-line argument to Tethereal (or Ethereal, if you start the capture from the command line), or turn off the promiscuous mode option in the Ethereal GUI, not to run in promiscuous mode. Some other applications, such as snoop on Solaris (and possibly some other OSes), or Analyzer (on Windows), or other network analyzers, might put the interface into promiscuous mode as well. And is it correct that without tcpcump, the network is not in promiscuous mode? No. Another program might put the interface into promiscuous mode. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Radius
On Nov 16, 2004, at 1:08 PM, jesk wrote: in some auth-replies iam missing some attributes but instead of them i can see at the end of a tcpdump line the following: [|radius] what does this exactly mean? It probably means that either 1) the RADIUS packet didn't fit in a single link-layer packet (and was thus fragmented at the IP layer) or 2) the RADIUS packet didn't fit within the snapshot length used for the capture. The default snapshot length for tcpdump is 68 for versions of tcpdump that don't support IPv6 and 96 for versions of tcpdump that do support IPv6, so, unless you specify a larger snapshot length with the -s flag, RADIUS packets that don't fit within 68 or 96 bytes (depending on whether the version of tcpdump you're using was built with IPv6 support or not) will get an |radius report. In modern versions of tcpdump, -s 0 requests a snapshot length of 65535, which should be sufficient to handle all link layers supported by tcpdump. In older versions, you'd have to do -s 65535. (Don't try to use the MTU of the network - using 0 or 65535 is easier, and more likely to be large enough; for example, note that -s 1500 is *NOT* large enough for Ethernet, as the snapshot length includes the link-layer header, so it'd have to be -s 1514.) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Sniffing ranges of ips
Alexander Dupuy wrote: Note also that there is a bug in the libpcap BPF optimizer (as of 0.8.3) that breaks the hack described above, Try it with the top-of-tree CVS version; I've made some optimizer fixes that will, I think, fix this. However, the libpcap 0.7 optimizer not only generates correct BPF, but it is shorter than any of the above, entirely eliminating the use of the index register: (000) ldh [12] (001) jeq #0x800 jt 2jf 6 (002) ld [26] (003) jge #0x1020304 jt 4jf 6 (004) jgt #0x1020506 jt 6jf 5 (005) ret #96 (006) ret #0 I'm not sure whether that's a case of the code generator not generating code that uses the X register there, or a missing optimization - I have a change that should put that optimization back. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Promiscuous mode and BPF filters?
On Dec 1, 2004, at 7:53 AM, Claudio Lavecchia wrote: I have two laptops (say A and B) that have 802.11 wireless cards. I am developing some application that essentially perform sniffing functions using wireless cards in promiscuous mode. To test my code, I need those two laptops not to see each other (-- I do not want the wireless card of laptop A, which is operating in promiscuous mode to process packets coming from laptop B) and I want to test my appliction having my laptops on my desk, hence I need a way to hide the two laptops from each others. I want to apply some kind of filters to laptops A and B, and I want the filtering to happen BEFORE the packets reach the promiscuous mode filter. What do you mean by the promiscuous mode filter? Promiscuous mode is a hardware mode on LAN adapters (including WLAN adapters), in which the adapter doesn't filter out packets that it sees but that are sent to a unicast address other than one of the adapter's unicast addresses or, on adapters that can be configured with a list of multicast addresses, sent to a multicast address other than one of those multicast addresses. That filter is in the hardware or firmware of the adapter, so you're not going to be able to do the filtering before that. Quickly borwsing the web I found BPF (BSD Packet Filter). Can that be the solution to my problem? BPF is used to refer to two things: 1) the raw packet capture mechanism on various BSDs (including OS X) and AIX; 2) the packet filtering mechanism used by that raw packet capture mechanism *and* in the Linux socket filter mechanism and in Digital/Tru64 UNIX's raw packet capture mechanism *and* in the WinPcap driver *and* in libpcap when reading from a savefile or capturing on a platform whose raw packet capture mechanism doesn't support that filtering mechanism. BPF, in the first sense, won't be the solution to your problem, as that's not the raw packet capture mechanism on Linux. On the platform where it *is* the raw packet capture mechanism, it's not really the solution, either, it's just a requirement for capturing packets at all. In the second sense, it's the filter mechanism used by pcap_compile() and pcap_setfilter() in libpcap. It *could* be the solution *if* you're willing to modify your application slightly so that if it doesn't use pcap_compile() and pcap_setfilter(), i.e. it doesn't do any packet filtering, it temporarily sets a filter, while you're testing it, to reject packets from laptop B; if it *does* use pcap_compile() and pcap_setfilter(), i.e. it already does packet filtering, it *adds* to the filter an expression to reject all the traffic from laptop B, i.e. instead of filtering with an expression X, you filter with (not wlan src BB:BB:BB:BB:BB:BB) and (X), where BB:BB:BB:BB:BB:BB is the source MAC address of laptop B's 802.11 card. It will not be the solution if you expect it to be able to filter out packets transparently to libpcap - there's only one filter per packet capture handle, and libpcap uses that for its filtering. (That also applies if you're not using libpcap, but are directly opening a PF_PACKET socket - the only difference in that case is that your application contains code that duplicates what libpcap does, and that code has the same limitations as libpcap, as the limitation of one filter per handle is an OS limitation.) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] loopback interface and byte order
On Dec 1, 2004, at 3:31 PM, Robert Lowe wrote:
In testing a small app using libpcap, I noticed differences in
behaviour when
using the loopback interface vs. using a hardware interface. In
particular,
it seems the packets coming in over the loopback interface are still
in host
byte order (little endian, in this case).
Packets aren't in any byte order; particular fields in the packet might
be in a particular byte order.
In the link-layer header used with BSD-style loopback interfaces, the
4-byte packet type is, in most BSDs, in host byte order - it's
obviously known that the machines on both side of the connection have
the same byte order :-) - but, at least in newer versions of OpenBSD,
it's in network byte order.
On Linux, the link-layer header is a fake Ethernet header, and the type
field *should* be in network byte order (big-endian).
The IP, ICMP, TCP, and UDP header fields should be in network byte
order.
On what OS are you doing this?
Is that typical, or just an
OS-dependent artifact? In trying to find the answer, I came across a
function
in the pcap library, pcap_datalink(). If I really wanted my app to
work using
the loopback interface, I assume I would use this function to
determine whether
or not to invoke byte order altering functions.
If you really want your app to work on anything other than Ethernet
interfaces, you would use that function to determine what to do with
the link-layer header.
If it returns DLT_EN10MB, it's Ethernet (don't worry about the 10MB,
that's a historical artifact from the days when there was the
experimental 3Mb/s Ethernet and the standard 10Mb/s Ethernet, and they
had different link-layer headers; all Ethernets 10Mb and up have the
same header, and use DLT_EN10MB).
If it returns DLT_NULL, it's BSD-style loopback, with a link-layer
header containing a 4-byte AF_ value in *host* byte order.
If it returns DLT_LOOP, it's BSD-style loopback, with a link-layer
header containing a 4-byte AF_ value in *network* byte order.
Beware - the AF_ value is the value for the OS on which the capture is
being done, and AF_INET6 has different values on {Net,Open}BSD,
FreeBSD, and OS X! If you want to handle save files as well as live
captures, make sure you check for all the AF_INET6 values.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] loopback interface and byte order
Robert Lowe wrote: Well, I was reporting this from memory. Let me back up a bit. When I first looked at pcap, I went through Tim Carsten's tutorial, referenced from the tcpdump.org website. Using that code (sniffer.c) on Linux with a downed eth0 i/f (forcing the dev to any) results in very weird ip src/dst addrs and ports that look partly like byte swapped information, and partly like wrong offsets. For example, source might look like 253.103.127.0:1 and dest like 0.1.127.0:32792. Is sniffer.c calling pcap_datalink(), checking for DLT_LINUX_SLL, and processing a link-layer header that looks like what's described in recent versions of the libpcap man page? I suspect it's not, which means it won't properly handle captures on the any device - the link-layer header you get in that case doesn't look like an Ethernet link-layer header, and isn't 14 bytes long, so if your program is assuming a 14-byte link-layer header, it will *not* work correctly - what it's reporting as the source and destination IP addresses are other parts of the packet. I.e., to quote my previous message: If you really want your app to work on anything other than Ethernet interfaces, you would use that function to determine what to do with the link-layer header. where that function is pcap_datalink(). Yes, that could be a bit messy, but you're stuck with it. See tcpdump for an example of how to handle this. This leads me to another question. I've seen recommendations to roll your own structs for IP/TCP headers, hinting that there might be slight differences in the definitions between platforms. Is this really true? Yes. For example, if I remember correctly, not all platforms' struct ip represent the header length and version field in the same way - some have bitfields and some have a single field for the header length and version and macros to extract the header length and version from it. That's why tcpdump has its own headers. I decided to use the definitions in the provided header files, and when I tested with my app, it showed correct behaviour in both cases (off the wire and loopback). But, if portability is an issue, what is the recommended course of action? Use your own definitions for all packet data structures. On what OS are you doing this? Linux, FC2 (2.6.5-1.358) and FC3 (can't retrieve right now), in particular. But, I'd like this app to build and run on BSD-derived systems and Solaris. Then you'd better use pcap_datalink() to determine the link-layer header - and you'd better not depend on the any device working, as that's Linux-specific, and you'd better not depend on being able to capture on the loopback device, because Solaris doesn't support that. If you really want your app to work on anything other than Ethernet interfaces, you would use that function to determine what to do with the link-layer header. ... Thank you for the information! I don't think I'll bother trying this now, Then you'd better not expect your program to work on anything other than a device that produces Ethernet headers - which means it won't work on the any device. Note also that the any device doesn't use DLT_LOOP or DLT_NULL headers, so you won't need to handle them if you're capturing on the any device - but you will need to handle them if you're going to capture on loopback devices on BSD-derived systems. but I certainly will at some point. Only when you do that stuff will it work on the any device. Note that your program should print an error message if pcap_datalink() returns a DLT_ value that it can't handle. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] what does tcpdump record files' header D4 C3 B2 A1 02 00 04 00 00 00 00 00 00 00 00 00 means
On Dec 2, 2004, at 6:25 PM, ~{Ir;*AV~} wrote:
what does the 10 bytes mean~{#?~}
The file header is 24 bytes long, not 10 bytes long.
The first 4 bytes are a 4-byte magic number, with a value that's
either 0xa1b2c3d4 or 0xd4c3b2a1. If it's 0xa1b2c3d4, all the other
fields in the file header, and the per-packet headers, are in the same
byte order as the machine reading the file, otherwise they're in the
opposite order and need to be byte swapped.
The next 2 bytes are a 2-byte major version number, which is the
version number of the file format, *not* the version number of any of
the software that wrote the file. The next 2 bytes after that are a
2-byte minor version number.
A file with a header that begins with D4 C3 B2 A1 02 00 04 00 00 00 00
00 00 00 00 00 was written on a little-endian machine; the version
number is 2.4 (major version 2, minor version 4).
The next 4 bytes after the minor version number are a 4-byte number
that is, in theory, the difference between UTC and local time on the
machine that did the capture, but, in practice, it's always zero.
The next 4 bytes after that are a 4-byte number that is, in theory, the
accuracy of the time stamps in the file, but, in practice, it's always
zero.
The next 4 bytes after that are a 4-byte number that is the snapshot
length of the capture - with tcpdump, that's the value specified with
-s (it defaults to 68 or 96), which specifies the length to which
packets will be truncated. It might be a large value - for example,
recent versions of tcpdump will use 65535 if you use -s 0 to capture
the entire packet.
The next 4 bytes after that are a 4-byte number that indicates the type
of link-layer header that the packets in the capture have. See recent
versions of the libpcap man page for a list of those types (those are
the DLT_ names), and see the bpf.h header in libpcap prior to 0.8 or
pcap-bpf.h in 0.8 and later for the values for those types.
Note that we will be introducing a new capture file format, so, if
you're writing your own code to read libpcap files, you will have to
change that code at some point, or it won't be able to read the newer
capture files. Libpcap will be changed to read them, so, if you use
libpcap to read the files, you won't have to change your code.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] what does tcpdump record files' header D4
wrote: Can u tell me something about your new capture file format? See http://www.tcpdump.org/pcap/pcap.html - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Listening on multiple devices in promiscous mode
On Dec 6, 2004, at 2:07 AM, Peter Sandford wrote: I need to capture from 2 interfaces on a machine in promiscuous mode. This is because we are routing a copy of 2 load balanced streams onto a box for monitoring. I'm aware it isn't possible (?) to listen on any with a pcap_open_live in promiscuous as the flag is ignored, The problem is that the any device, on Linux, is implemented by capturing on a socket that's not bound to any interface; this means that it can't be used to set promiscuous mode, as the Linux kernel doesn't, as far as I know, turn promiscuous mode on for all interfaces if you try to set promiscuous mode on an unbound socket. but is there a way of listening on a set of interfaces in promiscuous mode? Open multiple pcap_t's, get the file descriptors for them (use pcap_get_selectable_fd() if your libpcap has it, pcap_fileno() otherwise), and do a select() or poll() on them for reading. If a descriptor is marked as ready to read, do a pcap_dispatch() on the corresponding pcap_t. Note that this should work on most non-Linux UN*Xes as well. To make this run on BSDs, you should put the descriptors in non-blocking mode (use pcap_setnonblock() if your libpcap has it, otherwise set non-blocking mode on the descriptor returned by pcap_fileno() - if it has pcap_get_selectable_fd(), it has pcap_setnonblock()), set the timeout in the select() or poll() to the shortest timeout used in pcap_open_live() for any of the pcap_t's, and read from all of the pcap_t's when select() returns. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT_ request
marc hermstein wrote: I would like to request a DLT_ number for usage with raw GPRS LLC frames (DLT_GPRS_LLC). On a mobile, this is an output format that some loggers use. Having it defined as a possible link-layer type would allow me to have the GPRS_LLC dissector in ethereal register with that encapsulation type in pcap_to_wtap_map[] and call the GPRS_LLC dissector directly for my logs. DLT_GPRS_LLC is 169. I've added it to the top-of-tree CVS pcap-bpf.h (as well as to the Wiretap library in Ethereal). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT_ request
On Dec 6, 2004, at 9:16 AM, marc hermstein wrote: I would like to request a DLT_ number for usage with raw GPRS LLC frames (DLT_GPRS_LLC). On a mobile, this is an output format that some loggers use. Loggers in what sense? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT_ request
marc hermstein wrote: When developing a handset, some manufacturers dump debugging data from the protocol stack out the serial port on the bottom of the handset. This is what I meant by a logger. So you'll be writing, or have written, a piece of code that reads from the serial port and writes to a libpcap file? Or is there already software that logs the debugging data in another format (in which case you might be able to modify Ethereal's Wiretap library to read those files)? It might be interesting to add to libpcap a module to do live captures on a serial port. There will probably be other types of capturing people would want to do on serial ports, so there might eventually be a generic serial port capture module supporting multiple DLT_ types. There might have to be a way to specify the baud rate, bits per character, parity, etc. - the current pcap_open_live() API can't do that, but I'm thinking of a future open API that'd take an attribute/value list of options (so that it could, for example, have options to support monitor mode and setting the channel for 802.11), so that the option list could be extended without API changes (there might also be a way to find out what devices offer what options, so that applications such as Ethereal could offer GUI options). However, some or all of the serial port settings might be implied by the protocol, in which case they wouldn't have to be specified. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] request for new type
Dumas Hwang wrote: I would like to request two new link layer types for Generic Framing Procedure (DLT_GFP_T and DLT_GFP_F). Thank you. OK, DLT_GPF_T is 170 and DLT_GPF_F is 171. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
On Dec 9, 2004, at 12:48 PM, Dumas Hwang wrote: I would like to get nanosecond resolution on Solaris in libpcap. What's the best way to go about it? I suppose it's not a good idea to change struct timeval ts in pkthdr to timespec. That would be an amazingly bad idea (and it was an amazingly bad idea when IBM did it; they then proceeded to make it worse when they also used SNMP interface types rather than the we started with ARP types but then just added new types DLT_ values, so that not only are the time stamps different from what a program expecting a libpcap file would expect, the *link-layer type values in the file header* are different - Ethereal has some hacks to try to guess whether the file is an AIX file or not, and if we're willing to give up the ability to read pre-libpcap-0.4 PPP captures, libpcap could adopt those hacks, too). Should I add a new struct and request a new magic number? I would think many people need nanosecond resolution (if not picosecond). That's probably a reasonable short-term answer, if you need this soon. I wouldn't do much of anything more in the new format, though, because the right long term answer is http://www.tcpdump.org/pcap/pcap.html which supports a number of new things, including the ability to specify the accuracy of time stamps. It'd be nice to add the ability to *read* that format to libpcap 0.9, but still have it write the old format, so that when we add the ability to *write* that format, there will be at least some versions of libpcap that will be able to handle new-format captures with only one interface. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
On Dec 9, 2004, at 12:48 PM, Dumas Hwang wrote: I would like to get nanosecond resolution on Solaris in libpcap. BTW, where are you getting the nanosecond-resolution time stamps in Solaris? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Usage of pcap_open_live argument to_ms
On Dec 9, 2004, at 1:09 PM, Robert Lowe wrote: to_ms specifies the read timeout in milliseconds. The read timeout is used to arrange that the read not necessarily return immediately when a packet is seen, but that it wait for some amount of time to allow more packets to arrive and to read multiple packets from the OS kernel in one operation. Not all platforms support a read timeout; on platforms that don't, the read timeout is ignored. A zero value for to_ms, on platforms that support a read timeout, will cause a read to wait forever to allow enough packets to arrive, with no timeout. -- How does one tune this value? It's a tradeoff between latency and packet drops. Having a too-large value increases latency - if you have a timeout of, for example, 10 seconds, then if you get one packet a second on the network, you might not see that packet until 10 seconds after it arrives. Having a too-small value could mean that, with sufficiently heavy traffic, you'll be more likely to lose packets. Does using a zero value on platforms that support a read timeout have performance implications? Probably not much of one, but it has severe latency implications, i.e. the latency becomes, at worst, infinite, i.e. if you only get one packet ever on a network, you'll *never* see it - you'll only see packets once the buffer fills up. What does enough packets mean exactly? What it means depends on, at minimum, the OS and the size of the packets and the size of the buffer. I.e., we use the vague phrase enough packets intentionally - it's not predictable. Are packets queued for the callback routine -- I'm using pcap_loop(). Queued where? On all current systems with a timeout and buffering, packets are buffered in the OS kernel until either 1) the buffer fills up or 2) the timer expires at which point, if there's a read in progress on the device (which pcap_loop(), pcap_dispatch(), pcap_next(), and pcap_next_ex() will do), the read will complete and return whatever packets there are in the buffer. Those routines will return packets from the batch that were read in; until all packets in that batch are returned and the next packet is requested, the next read on the device won't be started. Also does pcap_loop() set errno if it terminates abnormally? Possibly, possibly not. If you want to report the error from an abnormal termination of pcap_loop(), use pcap_perror() or pcap_geterr(). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
On Dec 9, 2004, at 2:08 PM, Darren Reed wrote: In some email I received from Guy Harris, sie wrote: BTW, where are you getting the nanosecond-resolution time stamps in Solaris? gethrtime That says what the high-resolution time counter's value is now, not what the value was when bufmod saw the packet (which raises another issue, namely that the time stamps you get out of libpcap might have nanosecond *precision* but they might not have nanosecond *accuracy*) - or are the packets in question not being captured by libpcap, so that you can use gethrtime() to time stamp packets reasonably close to the time t which they arrived? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nanosecond timestamp
On Dec 9, 2004, at 3:23 PM, Darren Reed wrote: So what am I trying to say here? Unless you have hardware timestamps in captured packets, one software timestamp is as good as the next in a well written application. ...or as bad as the next. If you want absolute time stamps, nanosecond resolution with anything other than hardware timestamps is probably overkill - *microsecond* resolution is probably overkill. If you want relative time stamps, the higher resolution is useful with software time stamps only to the extent that the jitter in the delay between packet arrival and time stamping is enough less than the resolution that you're not measuring noise with those extra bits of resolution (unless one goal is to measure the times when the packet made it through the networking software, but, in that case, you really *do* want the bufmod time stamp, except that it doesn't exactly reflect the time when the packet was seen by, say, the IP layer). So, yes, one software time stamp is as good - or as bad - as the next, but in that case I suspect that the boring old microsecond time stamp from bufmod is as good as any nanosecond-precision time stamp you might synthesize. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT_LINUX_SLL
aman Reddy wrote: I would like to know what is the length of the DLT_LINUX_SLL link layer header and please also explain to me the different fields in it. man pcap, with modern versions of libpcap, describes the link-layer headers; it describes DLT_LINUX_SLL in some detail, and gives the lengths of the fields in its header - the length of the header is the sum of the lengths of the fields in the headeer. But how to know from where the packet is originated that the source address of the packet. To quote the libpcap man page: DLT_LINUX_SLL Linux cooked capture encapsulation; the link layer header contains, in order: ... a 2-byte field, in network byte order, containing the length of the link layer address of the sender of the packet (which could be 0); See the man page for the complete listing of fields in the header, from which you can determine what the offset is of that field. Note that it's a *link-layer* source address; it is *NOT*, for example, the IP source address of an IP packet. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] support of sctp in filters
Ariel Burbaickij wrote: The second one, I.e., the answer to the question originally asked is no, there are no plans to add support for SCTP to capture filters, because libpcap filters already supports SCTP, and the real question should've been are there any plans to support printing SCTP in tcpdump? I guess the fact that there is protocol descriminator can be found in IP header is somehow almost common knowledge, isn't it. Yes, and print-ip.c recognizes a protocol discriminator value of 132 as being SCTP and calls sctp_print(). You need to specify -vv to get it to print very much; are you really saying are there any plans to support printing more information about the SCTP packet without specifying -vv? If somebody wants to contribute that, something that avoids using newlines - unless -vv is specified, the output of tcpdump should be limited to one line per packet - would be useful, e.g. something just listing the chunk types and other parameters, without dumping the chunk data. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 10:02 AM, Paul Thomas wrote: The configure script reports: checking ifaddrs.h usability... yes checking ifaddrs.h presence... no checking for ifaddrs.h... no What can I do about this? (The file does not exist.) Ask QNX; at least according to this page: http://www.qnx.com/developers/docs/momentics_nc_docs/neutrino/lib_ref/ g/getifaddrs.html getifaddrs() behaves like the getifaddrs() on some UN*Xes, and requires that you include ifaddrs.h, so presumably, at least in Neutrino, it exists. Now, that's Neutrino, not QNX4, and the page at http://www.qnx.com/developers/qnx4/index.html indicates that Neutrino is later than QNX4, so perhaps that documentation doesn't apply. Perhaps you have to install some package to get the ifaddrs.h include file. Note that libpcap includes no explicit QNX support. If somebody has QNX support, it would be Greatly Appreciated Indeed if they'd contribute it, so that we can make it part of the distribution, and make any changes to it that are required by libpcap changes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 12:15 PM, Paul Thomas wrote: From the TCP/IP Library Reference / System Library Functions Manual If that's the QNX4 documentation, then... SYNOPSIS #include sys/types.h #include sys/socket.h #include ifaddrs.h ...I would infer that QNX4 - or its development kit, if that's where header files come from, or wherever header files for whichever library getifaddrs() is in come from - is *supposed* to have ifaddrs.h as one of the header files, so you should ask QNX what the problem is. The getifaddrs() function first appeared in BSDI BSD/OS. The function is supplied on OpenBSD since OpenBSD 2.7. H So now I must scarf this file from an OpenBSD distro so that I can continue and build libpcap 0.8.3 for QNX 4.25 ?? No, you should scarf it from wherever QNX put it (assuming they didn't forget to include it, in which case you should ask QNX-the-company where you should get it from in order to fix the problem). I suspect The function is supplied on OpenBSD since OpenBSD 2.7. really means we took the OpenBSD man page and used that as our man page, and forgot to fix the HISTORY section not to somewhat-irrelevantly mention OpenBSD. (Whether they took the *implementation* from OpenBSD or not is another matter.) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 1:23 PM, Paul Thomas wrote: Is the getifaddrs() you're using part of QNX4, or is it from some add-on library, e.g. taking the eCos implementation and porting it to QNX4? getifaddrs() is not part of QNX4. There is no connection whatsoever. It is utilized in the libpcap file, 'fad-getad.c'. This source file is called out explicity in libpcap 0.8.3's configure-generated Makefile as: FSRC = fad-getad.c Then either 1) your system somehow has a getifaddrs() or 2) the test for getifaddrs() somehow succeeded without it being present. We'd have to see the config.log file from your system to see how that happened. I checked in a change to 1) use the stub version of pcap_findalldevs() on platforms on which we don't support packet capture and 2) have the configure script fail on platforms with getifaddrs() but no usable ifaddrs.h. Change 1) will probably make the current CVS version configure, at least, on QNX4, unless, somehow, the configure script manages to find a packet capture mechanism it supports. I am absolutely dumb-founded that the maintainers of libpcap would have this code, and thereby _assume_ that the supporting file(s) would already exist on the developer's computer! The configure script does *NOT* assume that getifaddrs() exists on the developer's computer. Until my recent checkin, however, it *did* assume that if getifaddrs() existed in any of whatever libraries the AC_CHECK_FUNC() autoconf macro tested, ifaddrs.h would exist on the developer's computer, because in all systems we'd seen, getifaddrs() was explicitly documented as using ifaddrs.h. It now checks whether it exists, and fails if it doesn't, because that either means that 1) getifaddrs() is a system API and, when the system was installed, not all of the header files necessary for development were installed; 2) getifaddrs() is in a third-party library and, when that library was installed, not all of the header files necessary for development were installed; 3) ifaddrs.h was installed, but the configure script needs to search in some additional directory for it - which means it would need to set up the Makefile to search in that directory as well; 4) whoever provided the implementation of getifaddrs() made it incompatibly use a header file other than ifaddrs.h; 5) the getifaddrs() is not a BSD-style getifaddrs(); and in all of those cases either the user needs to figure out what needs to be done and do it (in cases 1) and 2)) or we need to figure out, with information supplied by the user, what needs to be done and do it (in cases 3), 4), and 5)). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 3:40 PM, Paul Thomas wrote:
There is a wcc option, -we (treat all warnings as errors) described
as
follows.
By default, the compiler continues to create an object file when
there are
warnings produced. This option can be used to treat all warnings as
errors,
thereby preventing the compiler from creating an object file if there
are
warnings found within a module.
'cc' provides for -f{option} which allows us to pass -f option to
wcc.
So, cc -f we should do the trick?
Unfortunately, it'll turn *all* warnings into errors; the only warnings
I want turned into errors are the warnings for undefined references, as
there might be other warnings that are harmless *and* difficult if not
impossible to eliminate in a configure script.
That's probably a warning from the linker - i.e., it's presumably
produced after the object files have been created. Is there an option
to get the linker to fail with undefined refeerences?
And is the linker part of the Watcom C compiler?
Also, if there is a way of getting the linker to fail with undefined
references, so that we could, in theory, have the configure script use
an option to make it do so:
What compilers are used with QNX? There's probably a GCC port; is
there any significant non-GCC compiler other than Watcom?
Is there a
host_os=???
line in the config.log file, and what's the ??? value? I.e., what does
host_os get set to on QNX?
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 2:47 PM, Paul Thomas wrote: Here is the relevant output, from config.log: Is there earlier checking for getifaddr output in config.log? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 3:10 PM, Paul Thomas wrote: configure:3849: checking for getifaddrs configure:3899: cc -o conftest -g -O2 conftest.c 5 Warning(1028): getifaddrs_ is an undefined reference That's only a warning? Is there a way to force cc on QNX4 to *fail* if some symbol isn't found? If so, autoconf's AC_CHECK_FUNC macro should use that; perhaps there's a way for us to force it to do so in the configuration file. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 4:30 PM, Paul Thomas wrote: But, the behavior do not create executable if undefined symbols are present is not the same as having the linker fail, is it? What autoconf wants is to have an attempt to compile and link a program that refers to a particular symbol cause, on a system that doesn't have that symbol in the libraries being used, the linker to exit with a non-zero exit status; that's the sense in which the linker needs to fail in order for autoconf to work. Also, if there is a way of getting the linker to fail with undefined references, so that we could, in theory, have the configure script use an option to make it do so: This is problematic. Unfortunately, I do not know how, and the documentation does not make it obvious that this can be done for the linker. Oh, well - I guess that means that autoconf won't work on QNX (or QNX4, at least - it won't work on any of the QNX versions where the Watcom linker is being used). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 4:44 PM, Guy Harris wrote: Oh, well - I guess that means that autoconf won't work on QNX (or QNX4, at least - it won't work on any of the QNX versions where the Watcom linker is being used). Or, more precisely, I guess that means that autoconf-generated configure scripts that use AC_CHECK_FUNC won't work on QNX Unfortunately, that includes scripts that test whether a particular function is available on the current platform, and the configuration script for libpcap is such a script. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [WinPcap-users] error in net/mask windump specification
Alex Narinsky wrote: From the Cisco tutorial (http://www.cisco.com/warp/public/701/3.html) the net mask combination 172.16.50.1 255.255.255.0 is valid. However, when I apply this combination to windump - windump net 172.16.50.1 mask 255.255.255.0 I am getting the error: windump: non-network bits set in 172.16.50.1 mask 255.255.255.0 Why windump rejects this net/mask? Because WinPcap does. By the way tcpdump works in the same way. Because libpcap does. (See gen_mcode().) I *presume* the idea is to warn people if they get the network address or netmask wrong, so that one of the bits in the network address is part of the host part rather than the network part. Perhaps that's an excessively cautious check, and should be removed, and it should just strip off the host-part bits in the network address when generating the code. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] newbie question
durung_lulus wrote: I want to make simple sniffer, but having question in mind, Could we loose any packet that we try to grab with pcap_loop/pcap_dispatch? Yes. And if we do, what are the causes? It'd be caused by the sniffer not being able to read packets fast enough that whatever buffer the OS uses in the capture mechanism doesn't fill up so that packets don't arrive when there's no room left in the buffer. The application should try to do as little processing as it can; however, there's also OS and libpcap code involved. Making the buffer larger might help, although, unfortunately, there's currently no API in libpcap for doing that (the problem is that, on systems using BPF such as the BSDs, you can't set the buffer size once the BPF device is bound to a network interface, and that happens when you open with pcap_open_live(), so the API would have to be a new API for opening devices - we'll probably have such an API in the future). On some platforms you could probably write platform-dependent code to increase the buffer size - for example, on Linux you could try increasing the socket buffer size using the file descriptor returned by pcap_fileno() (on Linux, capturing is done with a socket). If you don't need the entire packet - if, for example, you're only inteested in protocol information up to the TCP layer - you could set a snapshot length long enough to capture only the link-layer header and the headers you're interested in, so that less data is buffered and less data is copied; on most platforms, that'd make it less likely that you'd lose packets. If you don't need all the packets on the network on which you're capturing - if, for example, you're only interested in HTTP traffic - you could use a packet filter to limit which packets are captured; on many platforms, that'd make it less likely that you'd lose packets. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
