Re: [tcpdump-workers] new media support(Intel/Septel)

gilbert HOYEK wrote: hi again , after i made the necessary changes to libpcap api and wrote a pcap-septel.c using the septel library files , i need to know now ,if you dont mind , what changes do i have to make to ethereal so that it will support it . as i think it should be something like captu

Re: [tcpdump-workers] Please help me

On Apr 18, 2005, at 12:00 AM, Tien Quang Huynh wrote: At present, I need to know the structure of libpcap files to write software. Because I need to analyze Ethereal results. If you just want to read a libpcap file, you can do that with libpcap - pcap_open_offline() and pcap_loop() (or pcap_dis

Re: [tcpdump-workers] EAGAIN from pcap_dispatch

ury segal wrote: The code runs on Solaris 8. Sorry for misinforming you before. The code that produces the message is: if ( (packet_from_pcap= pcap_dispatch(pcpaph, 1, _pcap_reader, (u_ch

Re: [tcpdump-workers] EAGAIN from pcap_dispatch

ury segal wrote: Any idea what is wrong with my sample program ? What's wrong with your sample program is that 1) it's using non-blocking I/O and select() with a timeout, and calling "pcap_dispatch()" regardless of "select()" says input is available on the pcap_t or not; 2) it's running

Re: [tcpdump-workers] EAGAIN from pcap_dispatch

ury segal wrote: After fixing the program to save the value of the pcap_dispatch correctly, I found it to be -1. After expanding the if block of FD_ISSET to include the pcap_dispatch call :-) , I don't see this message any more. Yes - but, as I noted, there's a problem with select() on BPF in some

Re: [tcpdump-workers] is there any minumum value for the member "len"

K. Anantha Kiran wrote: When i try to read each packet from "xx.dump" by using pcap_next, i am always finding pcap header having "len" member value as "60" when i read a packet which actually doesnot contain any data (For example ack, fin packets) . What can be the reason for this. As Aaron

Re: [tcpdump-workers] (3) tcpdump infinite loop bugs... (2 fixed

v9 wrote: 3 infinite loop dos bugs... the bgp and ldp one SEEM to be fixed in the cvs versions...the isis one isn't. I've checked in a change that *should* fix the ISIS loop, but I haven't tested it directly. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] libpcap - fragmented?

soumya r wrote: I am a newbie doing packet capturing using 'libpcap'. I want to know whether the output given by pcap is fragmented packets or defragmented packets. Please help. The output will, if you're capturing on a network interface, be the low-level packets from that interface. Packets can

Re: [tcpdump-workers] error compiling 2005-04-26 tcpdump on FreeBSD 5.x

On Apr 26, 2005, at 3:47 PM, Alexander Dupuy wrote: The problem is that __ntohl et al. are already #defined as special asm functions: ... but this is easily fixed: Checked in. Are there any *other* x86 UN*Xes that might have this problem? Another problem is that print-sunrpc.c doesn't com

Re: [tcpdump-workers] tcpdump compilation errors on FreeBSD 5.2

Alexander Dupuy wrote: I sent a report on this previously, but it didn't seem to go through on the list. Perhaps you're not getting stuff on the list delivered; I saw it, and responded. This is with the 2005-04-26 snapshot: One problem occurs because of FreeBSD's #define of __ntohl as an inline

Re: [tcpdump-workers] pcap_dispatch blocks on AIX

Gali Diamant wrote: I expected pcap_dispatch to return since we have set the handle to be non blocking. Instead, it doesn't and blocks waiting. Is this the correct behavior or is that an AIX issue? It doesn't happen on Linux or Solaris. It's probably an AIX issue; perhaps non-blocking mode doesn't

Re: [tcpdump-workers] tcpdump compilation errors on FreeBSD 5.2

On Apr 27, 2005, at 12:22 PM, Guy Harris wrote: Why is this occurring at all? I.e., why are we even including the OS's pmap_prot.h file to *cause* problems? Perhaps, on some UN*Xes, we get that because we include some system RPC header files in print-sunrpc.c. If that's unavoidable

Re: [tcpdump-workers] pcap_dispatch blocks on AIX

On Apr 28, 2005, at 8:21 PM, alexander medvedev wrote: I would like to compile a list of AIX's bpf flaws and lacking features. 1. non-blocking read does not work; 2. 2. It's not documented. 3. It appears that, sometimes, when you read from a BPF device, you get EFAULT for no good reason. (Se

Re: [tcpdump-workers] Question on application identification

Siva Ramagopal wrote: I'm interested in knowing how tcpdump identifies the application or service to which a packet belongs to. Is the /etc/services file used in this operation or is there a list of mappings between well-known ports to their corresponding applications that is used instead? "iden

Re: [tcpdump-workers] Question on application identification

Sivakumar Ramagopal wrote: When it dissects the packets for a particular protocol, it uses its built-in notion of which port numbers are used on which ports. Did you mean notion of which *protocols* are used on which ports? Yes. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/

Re: [tcpdump-workers] streamlined direction patch for libpcap

Pawel Pokrywka wrote: Hello, I need to specify packet direction for my sniffing application, but current libpcap doesn't offer this functionality. I've found a patch[1], which adds ability to set direction of packet capture. The patch works good, but it modifies pcap_pkthdr struct from pcap.h, whic

Re: [tcpdump-workers] tcpdump compilation errors on FreeBSD 5.2

Alexander Dupuy wrote: If that's unavoidable (i.e., if some system header file we're including drags in pmap_prot.h), perhaps we should modify our pmap_prot.h so that it uses different names for what it defines, so we don't get the name collisions that I'm assuming are causing the compile problems

Re: [tcpdump-workers] streamlined direction patch for libpcap

Pawel Pokrywka wrote: For me, only D_IN is required, so I would be happy with this direction only :) I don't know other platforms, but are you sure that there is no way to implement for example D_IN, when there is D_OUT and D_INOUT? Maybe there are other problems, but substracting D_OUT from D_INO

Re: [tcpdump-workers] streamlined direction patch for libpcap

Pawel Pokrywka wrote: Back to pcap_direction() function. I think I better like idea, that pcap_direction() should return error when given direction is not supported on users platform. If there are no better ways, enclosing pcap_direction() body and direction checks in pcap_read_packet() with #ifdef

Re: [tcpdump-workers] streamlined direction patch for libpcap

Pawel Pokrywka wrote: Here comes my latest patch. Checked in, with some changes to handle old-style SOCK_PACKET sockets on Linux (pcap_setdirection() isn't supported there, as the direction isn't available), and to use the standard tab-based indentation. On unsupported capture mechanisms setdire

Re: [tcpdump-workers] streamlined direction patch for libpcap

Which e-mail address should I use in the CREDITS file? I used your GMail address. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] Length Payload and Print the payload content?

On May 4, 2005, at 7:21 AM, Wilmar Sulaiman wrote: I am new to libpcap library, I was wondering how to get the payload length and to print the payload content. I've look the tutorial at http://www.tcpdump.org/pcap.htm. However my concern is they using size of ethernet + ip + tcp, while it is

Re: [tcpdump-workers] Payload not properly displaying...

(Blah blah blah wrong From: address blah blah blah work around duplicate detection blah blah blah.) soumya r wrote: I am doing packet sniffing and i found the "sniffer.c" program of pcap web site extremely helpful. But i have got one problem. I am not able to display the packet payload properly.

Re: [tcpdump-workers] PCAP Timestamp - HWClock or SWClock?

J.O. Leger wrote: Is the timestamp in pcap_pkthdr from the hardware clock or the software clock? The timestamp is from whatever it's from. :-) If you're capturing on an interface on a UN*X or Windows (with WinPcap) machine, the time stamp is from the capture mechanism that libpcap uses. Those ca

Re: [tcpdump-workers] semi-working tcpdump 3.4.0

Per Engelbrecht wrote: Hi all I'm having a peculiar problem with tcpdump (tcpdump version 3.4.0 / libpcap version 0.5) Those are very old versions - the current versions are 3.8.3 and 0.8.3. Are those the versions that came with OpenBSD? tcpdump with 0-2 flags = output. tcpdump with 3-x flags =

Re: [tcpdump-workers] libpcap on knoppix

prabhakaran amith wrote: I have got knoppix installed in my system.the package manager shows that libpcap is already installed .But when i write a program using that i get errors saying pcap.h not found.when i try searching for the file i dont find anything apart from libpcap.s0.8 and libpcap.s0.8.

Re: [tcpdump-workers] semi-working tcpdump 3.4.0

Per Engelbrecht wrote: This is a pre-release snapshot, don't know what stable will be shipped with, but I expect no major changes in forthcoming 3.7 release (may 19). OK, so some issues with it might be the result of stuff the OpenBSD people have done. What happens if you do sudo tcpdump -n

Re: [tcpdump-workers] libpcap on knoppix

prabhakaran amith wrote: are u aware of any site where i can download those(the developer package) Presumably you'd get the developer package from the same place you get other packages for Knoppix. I don't use Knoppix, so I can't offer any more advice than that. - This is the tcpdump-workers lis

Re: [tcpdump-workers] BPF vs DLPI performance

alexander medvedev wrote: Which of the two (BPF or DLPI) will generally give you better performance? Particularly, i am looking to reduce the number of dropped packets. Will DLPI capture even report captured/dropped packet count? On most OSes, one of them won't capture any packets whatsoever, as mo

Re: [tcpdump-workers] PCAP Timestamp - HWClock or SWClock?

J.O. Leger wrote: The application that is using libpcap sometimes displays "unusual" timestamps. "Unusual" in what sense? I believe this is caused by the hardware clock and the software clock being set to different times. To which hardware clock are you referring? Note that, as far as I know, the t

Re: [tcpdump-workers] libpcap

Plantier, Spencer wrote: I get this error when I try to install libpcap. I have downloaded and installed the most current version of flex. configure: error: Your operating system's lex is insufficient to compile libpcap. flex is a lex replacement that has many advantages, including being able t

Re: [tcpdump-workers] libpcap

Sanjay Patnaik (sanpatna) wrote: I downloaded the libpcap-0.8.3.tar.gz and made a build. It created the libpcap.a in the /usr/local/lib direcotry. But there is no libpcap.so.0.8.3. I need the libpcap.so file as it is required by the ethereal installation. How should I do it. *IF* you're using Lin

Re: [tcpdump-workers] pcap buffer length

rupesh gautam wrote: i have to do analysis for packet drop by changing buffer length on fedorais it possible in libpcap to change buffer length... It is possible to *change* libpcap to set the buffer length and where is the code for buffer length There isn't any. You'd have to add it. On L

Re: [tcpdump-workers] buffer size question

rupesh gautam wrote: why changing buffer size is unimplementable on systems with bpf. It's not *completely* unimplementable. It can, however, not be done after the BPF device has been bound to a network interface, which means that it cannot be done after "pcap_open_live()". I don't know why the

Re: [tcpdump-workers] preperation for 3.9 branch

Gianluca Varenni wrote: Is there any new plan for the release of libpcap 0.9? At this point, I don't have anything additional planned for tcpdump (other than perhaps grabbing some more capture files from the Ethereal Web site and from mail to the Ethereal list, and running tcpdump against those

Re: [tcpdump-workers] Windows Named Pipes as capture interfaces

Gcom, Inc. wrote: We are considering adding support in libpcap to use a windows named pipe as a capture interface. The other end of the windows named pipe would present a libpcap file-format stream of data, so relatively little would need to be done in libpcap to make this work. If we were to

Re: [tcpdump-workers] preperation for 3.9 branch

On May 18, 2005, at 4:33 PM, mcr wrote: I will cut a new beta, with a full pullup from HEAD of libpcap on May 23. How is that? Sounds good (although, at this point, the x.9 branches and HEAD are the same for libpcap and tcpdump except for a couple of things in the "tests" directory and the

Re: [tcpdump-workers] Question about committing changes for supporting LMP Service Discovery Extensions

On May 18, 2005, at 4:24 PM, Manu Pathak wrote: I just finished adding support for LMP Service Discovery extensions (defined in the UNI 1.0 spec) to tcpdump and would like to have these changes integrated with the mainline tcpdump code. Could somebody on this list tell me how to go about it (I a

Re: [tcpdump-workers] Question about committing changes for supporting

Manu Pathak wrote: Thanks for the information! The diffs are attached. Regards, OK, checked in. It should be in 3.9. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] packet contents

[EMAIL PROTECTED] wrote: Here is a simple question I had, and just wonder whether you guys run into the same situation or not. When I do a tcpdump like this: ->/usr/sbin/tcpdump -n -s 54 -c 200 -w 54-200.bin which means I need 54 bytes of the packet content. But when I check the file size, I

Re: [tcpdump-workers] 3.9 release

On May 25, 2005, at 10:19 AM, mcr wrote: Hi, I haven't cut the branch yet. Tonight, I think. Cool. I have a good excuse --- a child process was spawned, and it doesn't take well to resource limits yet :-) Congratulations are due, I assume The impression I get is that RLIMIT_CPU isn't

Re: [tcpdump-workers] Multi Threading - load balancing type situation...

Burton Strauss wrote: Near real-time scenario - suppose I need to process packets as quickly as they arrive. The per-packet processing time can exceed the inter-arrival time and so I want to create a bunch of worker threads to process packets in parallel. I.e., you're running on an MP machine

Re: [tcpdump-workers] pcap_dump_file & CO

Loris Degioanni wrote: Trying to understand why the -C tcpdump option doesn't work under Windows, I realized that a file pointer created in a dll can only be used inside that dll. This is a documented Windows limitation. Gak. That sux. Ethereal's capture file library is also done as a dll on

Re: [tcpdump-workers] pcap_dump_file & CO

On Jun 2, 2005, at 11:42 AM, Loris Degioanni wrote: Trying to understand why the -C tcpdump option doesn't work under Windows, I realized that a file pointer created in a dll can only be used inside that dll. This is a documented Windows limitation. So where is this documented? - This is t

Re: [tcpdump-workers] pcap_dump_file & CO

On Jun 2, 2005, at 1:35 PM, mcr wrote: Seems reasonable, but it certainly seems like a Windows.dll silly to me. Yes, but, as per my mail, there are arguably other reasons why pcap_dump_ftell() should exist, namely that applications should have the idea that a "pcap_dumper_t" is just a

Re: [tcpdump-workers] pcap_dump_file & CO

On Jun 2, 2005, at 3:42 PM, Gianluca Varenni wrote: Here is a KB documenting it http://support.microsoft.com/default.aspx?scid=kb;en-us;94248 That's a bit nastier - not only can't a C runtime file handle (the file descriptors returned by the UNIX-like _open() call and used by the UNIX-li

Re: [tcpdump-workers] pcap_dump_file & CO

Loris Degioanni wrote: When were pcap_fopen_offline(), pcap_dump_fopen() and the other FILE related functions introduced? November 2004: https://sourceforge.net/tracker/index.php?func=detail&aid=1051449&group_id=53067&atid=469577 We still don't export them in WinPcap, and I don't s

Re: [tcpdump-workers] pcap_dump_file & CO

On Jun 3, 2005, at 10:40 AM, Guy Harris wrote: As happens all too often, patches that add new APIs don't include a patch to pcap.3. Either that patch did, or I added it, as those routines *are* documented in pcap.3. - This is the tcpdump-workers list. Visit https://lists.sandelm

Re: [tcpdump-workers] pcap_dump_file & CO

On Jun 3, 2005, at 2:29 PM, Loris Degioanni wrote: Consistency of the API across different platforms, taking into consideration that some of them could have serious rerstrictions, is an advantage for everybody, developer's and maintainers. Not only Chris Lightfoot. And has always been the

Re: [tcpdump-workers] pcap_dump_file & CO

Loris Degioanni wrote: I've removed pcap_fopen_offline() and pcap_dump_fopen() from the WinPcap exports and manual. OK - should we #ifdef them out on Win32, so that they're not even compiled into the library? (And then update the man page to say "not available on Windows".) Just a small no

Re: [tcpdump-workers] pcap_dump_file & CO

Mark Pizzolato wrote: In the MS CRTL, a fpos_t is a 64bit integer, while on other platforms it may be a structure of some sort. Does Microsoft explicitly promise that an fpos_t is a 64-bit integer on Windows? (It doesn't matter about UN*X, as ftello() can be used there, and, as I understand

Re: [tcpdump-workers] pcap_dump_file & CO

Loris Degioanni wrote: So no all Unix systems have types.h? Not all UN*X systems necessarily have a types.h that define u_int64_t or uint64_t. What about using something like the bittypes.h in the missing folder of tcpdump? That might be one way. Can the MSVC++ I/O routines handle files

Re: [tcpdump-workers] pcap_dump_file & CO

Fulvio Risso wrote: Personally, I never use CRTDLL.LIB/MSVCRT.LIB, because in this case I'm forced to distribute my application with tons of DLL (MSVC*.DLL), which are far bigger than the application itself. Therefore, I'm always using the standard C library. The difference here, for the benef

Re: [tcpdump-workers] XORP, Win32, libpcap, and MSVCRT.DLL

On Jun 7, 2005, at 3:49 AM, Bruce M Simpson wrote: 1) Compatibility of WinPcap vs libpcap -- it would be nice if we could build both Win32 and UNIX versions from the same libpcap tree, but this is something we can work around at XORP makefile level; Build Win32 and UNIX versions o

Re: [tcpdump-workers] Single packet trouble in libpcap

Robert Lowe wrote: Set the to_ms parameter in your pcap_open_live() call to a short[er] interval. Yes, there's nothing special about a value of -1 for the timeout; the timeout value is, on systems using BPF (such as BSDs), just converted to seconds and microseconds and passed to the BPF devi

Re: [tcpdump-workers] Single packet trouble in libpcap

Sam Pierson wrote: On a hopefully final note, It came back quickly when I passed a 1 in as the to_ms parameter, but is there something I can define so that when it picks a packet off the wire, it reads it _immediately_. Not at present. There's an ioctl needed to enable immediate mode on BPF,

Re: [tcpdump-workers] Bug in print_unknown_data() + fuzz testing

Gerald Combs wrote: We recently added fuzz testing to Ethereal's automated build system. I tried out the script we're using on tcpdump and it turned up a bug in util.c. Yes, I've fixed some bugs that it turned up with my capture menagerie. (Yes, I need to run the fuzz testing with those captu

Re: [tcpdump-workers] Bug in print_unknown_data() + fuzz testing

On Jun 15, 2005, at 10:55 AM, Gerald Combs wrote: It's attached to this message It doesn't appear to have gotten attached. and is also available at http://www.ethereal.com/~gerald/lcp-crash.pcap . OK, got it. I've checked in a fix for the underlying problem, and audited the calls to "p

Re: [tcpdump-workers] Bug in print_unknown_data() + fuzz testing

On Jun 15, 2005, at 6:10 PM, Guy Harris wrote: OK, got it. I've checked in a fix for the underlying problem, and audited the calls to "print_unknown_data()" and checked in other fixes. BTW, whenever you're dealing with TLVs and, especially, TLVs whose data is made

Re: [tcpdump-workers] pcap_loop segfaults

Joshua Blanton wrote: It does appear that printf doesn't set errno, at least on linux and OSX, It probably will set errno if 1) it gets an error writing to the standard output (e.g., if it's redirected to a file, and the file system is full or you're over quota) or 2) it calls "isatty()

Re: [tcpdump-workers] making libpcap-0.9.1 compile on an embedded

Andy Chittenden wrote: Rather than using OS specific #defines, wouldn't it be better to use HAVE_SYS_FILE_H and set that appropriately for MSDOS (and our embedded OS)? One problem with doing that is that pcap.h includes other header files, so if it did that, either 1) HAVE_SYS_FILE_H would

Re: [tcpdump-workers] septel support on libpcap

On Jun 23, 2005, at 12:39 PM, gilbert HOYEK wrote: hi all , i have added two days ago a support for libpcap to be able to capture mtp2 low level protocol ss7 messages over INTEL/Net Structure cards (or Septel cards). ...with Intel's software for those cards on Linux. - This is the tcpdum

Re: [tcpdump-workers] libpcap-2005.06.25/savefile.c

Phil Wood wrote: It works, but I think args 2 and 3 (of 4) to fread are swapped. Unless it forces the kernel to read a character at a time? Line 1048: amt_read = fread((char *)&hdr, 1, sizeof(hdr), fp); That call says "read 'sizeof(hdr)' 1-byte entities, and return the number of 1-byte ent

Re: [tcpdump-workers] [Fwd: bug repourt:libpacp:fad-gifc.c:pcap_findalldevs]

xiaolei zhang wrote: why the original buf_size == 8192 ? We have to pick *some* size. I guess 65536 will probably be big enough on most if not all systems, and probably small enough, but it's ultimately arbitrary. in my system, sizeof(struct ifreq) is 40, if the buf_size is 44, then ioc

Re: [tcpdump-workers] pcap reads over iptables

On Jun 27, 2005, at 12:50 AM, Olivier Godineau wrote: I try to read captured packets on my machine with pcap. with no difficulty, i achieve this. TCPDUMP is able to capture some packets dropped by iptables. But with pcap i'm not successful with. How it is possible to capture iptables dropped pa

Re: [tcpdump-workers] [Fwd: bug repourt:libpacp:fad-gifc.c:pcap_findalldevs]

Guy Harris wrote: This means that, unless I've missed something, the *only* ways to ensure you have the entire list are either to loop, increasing the size of the buffer, until the difference between the buffer size and the number of bytes of interface information returned is less tha

Re: [tcpdump-workers] sniffex.c - libpcap example code proposal

On Jun 29, 2005, at 12:11 PM, Nathan Jennings wrote: There's one issue I've run into: after displaying certain packets (see function print_payload), my xterm/bash shell loses the ability to display newlines (i.e scroll lines). I suppose this is due to the display of a certain sequence of c

Re: [tcpdump-workers] sniffex.c - libpcap example code proposal

On Jun 29, 2005, at 1:20 PM, Guy Harris wrote: Use "isprint()" rather than "isascii()" in "print_payload()". ...and, while you're at it, print the payload in hex, as well as ASCII, to emphasize that there's *no* guarantee that TCP data is text.

Re: [tcpdump-workers] Ether-Type incomplete

On Jun 29, 2005, at 2:50 PM, Borja López wrote: After a search in this list database i've found a case where someone had nearly the same problem (http://www.mail-archive.com/tcpdump-workers@lists.tcpdump.org/ msg00339.html). The cause of the problem is that ether_type is read by processor in

Re: [tcpdump-workers] sniffex.c - libpcap example code proposal

On Jun 29, 2005, at 3:07 PM, Robert Lowe wrote: Seems like that kind of functionality might be a good candidate for inclusion in libpcap itself, no?? There are already functions to dump to a savefile; why not printable output as well?? How much printable output do you want? Should libpcap i

Re: [tcpdump-workers] sniffex.c - libpcap example code proposal

On Jun 29, 2005, at 5:50 PM, 广星 wrote: What I most concern about is how to print the payload in the correct format? For example, there is a HTTP packet, how can I print the HTTP payload according to its real content, such as"HTTP/1.1 206 Partial". Well, the first thing you have to determi

Re: [tcpdump-workers] sniffex.c - libpcap example code proposal

广星 wrote: How can I determine the right format? For example a packet has been identified as an HTTP packet, How can I know what its format is and are there many formats of the content of http? Note that a TCP segment, in a link-layer frame, doesn't necessarily correspond to a single HTTP req

Re: [tcpdump-workers] detecting libpcap 0.9

Florian Weimer wrote: What's the best way to detect libpcap 0.9 and later versions? In my application, I've got a workaround for this Debian bug: That bug is not unique to Debian. Apparently, this bug has been fixed in versions aft

Re: [tcpdump-workers] detecting libpcap 0.9

Florian Weimer wrote: * Guy Harris: note that the *same* executable image can run with *different* libpcap library versions, if it's built with a shared version of libpcap, so a compile-time test can't always give the right answer. Is this really the case? I thought that most dis

Re: [tcpdump-workers] libpcap: cooked socket warning & only beacon

Aki Tran wrote: I'm using libpcap- and jpcap to capture the wireless packets in monitor mode from a linux system (Fedora Core 3). I could only capture beacon frames, not control or data frames. I got this run-time warning: Warning: arptype 801 not supported by libpcap - falling back to cooked

Re: [tcpdump-workers] [Libpcap] Endianess and memory alignment questions

Cyril wrote: 2) Are pcap_next() network layer data aligned in memory ? IE -- Alignment Link layer data -- Gap -- Alignment Network layer data No, they are not. What you get is what's on the network, and if you have a 14

Re: [tcpdump-workers] detecting libpcap 0.9

only OS that comes with libpcap, so having the library version number available only at compile time would be a mistake (at least one OS that ships libpcap as a shared library doesn't even ship it with a version number: Guy-Harris-Computer.local$ ls -l /usr/lib/libpcap*.dylib

Re: [tcpdump-workers] detecting libpcap 0.9

On Jul 5, 2005, at 2:39 PM, dean gaudet wrote: shouldn't that be pcap_direction_t? otherwise i can imagine some namespace collision occuring... Yeah, probably. I've checked in a change to do that - and to rename the D_ values in it to PCAP_D_ as well. - This is the tcpdump-workers list.

Re: [tcpdump-workers] detecting libpcap 0.9

On Jul 5, 2005, at 3:03 PM, Guy Harris wrote: Yeah, probably. I've checked in a change to do that - and to rename the D_ values in it to PCAP_D_ as well. Unfortunately, that happened after the 0.9/3.9 release, so, for better or worse, we're stuck with the old names; I've

Re: [tcpdump-workers] [Libpcap] Endianess and memory alignment

On Jul 5, 2005, at 3:34 PM, Cyril wrote: Yes. The question was stupid. My program computes a data offset (14 for an Ethernet header) and assumes that network layer data follow link layer data However, I set up a BPF filter and BPF man page says : The bh_hdrlen field exists to account

Re: [tcpdump-workers] 3.9.1 -A flag broken

On Jul 5, 2005, at 6:29 PM, Michael Richardson wrote: -BEGIN PGP SIGNED MESSAGE- "dean" == dean gaudet <[EMAIL PROTECTED]> writes: dean> the -A flag prints hex rather than ascii-only... i think the dean> following patch is necessary. dean> case 'A': - ++xfl

Re: [tcpdump-workers] 3.9.1 -A flag broken

On Jul 5, 2005, at 7:30 PM, Michael Richardson wrote: oh, a regression test would have shown this. ...and a cleaner implementation of "-A" - i.e., one with a new routine to print out the packet data as ASCII, rather than one that jams that functionality into a routine that does a hex-an

Re: [tcpdump-workers] 3.9.1 -A flag broken

Guy Harris wrote: Here's a patch that has separate routines for "-A", "-x", and "-X", and that separately tests Aflag, xflag, and Xflag, and gives them all appropriate names. Ok, *here's* the patch. It also changes "-A" not to print th

Re: [tcpdump-workers] 3.9.1 -A flag broken

dean gaudet wrote: heheh cool, you seem to have come to the same conclusions as me... and i've got a regression test at http://arctic.org/~dean/patches/tcpdump-3.9.1-test-print-flags.patch i tried posting this earlier but i exceeded the 40k posting limit. I guess that explains why *neither*

Re: [tcpdump-workers] detecting libpcap 0.9

Romain Francoise wrote: It's not too late to release 0.9.2 with these API changes and encourage people not to use 0.9.1... ...assuming that we do it before some {Linux distribution, flavor of BSD, etc.} puts 0.9.1 into a release that lasts for N months before the next release, with 0.9.2, co

Re: [tcpdump-workers] tcpdump 3.9.1 under Windows

Loris Degioanni wrote: There is an issue compiling 3.9.1 in Windows. The problem is that my last patch to win32\prj\windump.dsp (2005/6/4) was not propagated to the tcpdump_3_9 branch, Most of us checking in changes were checking them into both branches, so we might have missed a change check

Re: [tcpdump-workers] libpcap and signals

Luis Monge wrote: I have a program that makes a live capture using pcap_loop. I also send a signal to that program (at midnight) and I catch that signal. My question is if the code I have inside the signal-catching function can be interrupted by the treatment of more packets (in pcap_loop). "In

Re: [tcpdump-workers] [Libpcap] Endianess and memory alignment

to worry about byte order.) If by "big-endian values" you mean that, for example, 127.0.0.1 would have the value 0x7f01, no, you don't convert that with "ntohl()": Guy-Harris-Computer.local$ tcpdump -d 'ip dst host 127.0.0.1 and icmp[20:4] == 0x7f01&#x

Re: [tcpdump-workers] 3.9.1

Romain Francoise wrote: The CHANGES file in libpcap-0.9.1.tar.gz is... strange: ... Looks like the entry got mangled. The main branch doesn't have the mangled entry for May 27th, and is otherwise identical (other than the RCS header). - This is the tcpdump-workers list. Visit http

Re: [tcpdump-workers] pcap_dump error checking

Mark Ellzey Thomas wrote: Recently I have been wanting for pcap_dump to make me aware of any issues with writing to a file (a full disk). Are there any issues with changing pcap_dump from void to size_t? It changes the ABI of the function, requiring a major version number change to libpcap.

Re: [tcpdump-workers] detecting libpcap 0.9

Michael Richardson wrote: If it happens this week, I'm fine with that. OK, I'll check those changes in again this week. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] tcpdump 3.9.1 under Windows

Speaking of x.9 changes, if we're going to be doing x.9.2 soon to fix various problems, should I also make pcap_fopen_offline(), pcap_file(), pcap_fileno(), pcap_dump_fopen(), and pcap_dump_file() UN*X-only, as per the discussions about the issues with different flavors of MSVC++'s C libraries

Re: [tcpdump-workers] [Libpcap] Endianess and memory alignment

On Jul 7, 2005, at 4:37 PM, Cyril wrote: [iBook] Running what OS? Mac OS X (Mach kernel + Darwin). (...+all the frameworks, apps, Finder, etc. - but those aren't relevant to this particular issue.) Oks. So, BPF/LSF filter assumes that multi-byte values are in network byte order (ie b

Re: [tcpdump-workers] 3.9.1 -A flag broken

Michael Richardson wrote: Now, we need to commit the fix :-) I took that as an indication that I should check in the patch whose URL I sent to the list; I've checked it into the main and x.9 branches. There's also the other issue I mentioned: However, I also noticed that, while "-x" suppres

Re: [tcpdump-workers] about libpcap

On Jul 7, 2005, at 7:45 PM, hong liu wrote: Hello, I am using libpcap library to capture ip data from data link. I am wondering if there is a way to time out reading a packet from data link. For example, if there is no data coming in 1 second, timer times out and process will do other thi

Re: [tcpdump-workers] 3.9.1 -A flag broken

On Jul 5, 2005, at 9:46 PM, dean gaudet wrote: i also think the 3.9 behaviour needs some slight modifications, so i'vemade two changes on top of your patch Guy. Well, on top of one of the versions of my patch; it's not the version that got checked in. (I did the original version at work,

Re: [tcpdump-workers] about libpcap

Cyril wrote: And if the system can't use select() *and* the packet capture mechanism doesn't support a timeout ? The only UN*X systems I know of where select() can't be used are FreeBSD 4.3 and 4.4 (due to BPF deficiencies fixed in 4.5); OS X 10.4[.x] (due to select() not working o

Re: [tcpdump-workers] about libpcap

Matthew Luckie wrote: Can you define the behaviour of 'not work' with BPF on tiger? "Not work" as in "if you select on a BPF device and nothing else, you will only wake up when the select timeout expires; the store buffer getting transferred to the hold buffer won't trigger a wakeup". I us

Re: [tcpdump-workers] about libpcap

Guy Harris wrote: "Not work" as in "if you select on a BPF device and nothing else, you will only wake up when the select timeout expires; the store buffer getting transferred to the hold buffer won't trigger a wakeup". Actually, it might work for select(), alth

Re: [tcpdump-workers] 3.9.1 -A flag broken

On Jul 6, 2005, at 1:56 PM, Guy Harris wrote: So presumably "-X" should suppress the "print_default()" calls in link-layer printers (i.e., the if (!xflag && !qflag) print_default(...); calls). I'll look at doing that, unless somebody objects. I&

<    1   2   3   4   5   6   7   8   9   10   >