Re: [tcpdump-workers] Regarding PCAP versions

On Jul 14, 2009, at 9:39 PM, Chandru S wrote: I was able to find the CHANGES file but my only concern is that it gives us the difference between subsequent releases .I need a document which can provide all the changes from my PCAP version to the LATEST.Is there any document in that patter

Re: [tcpdump-workers] [PATCH] Bugfix/improvement for linux mmap ring buffer

On Jul 15, 2009, at 12:40 PM, Dustin Spicuzza wrote: Found this bug while trying to add the buffer statistics API. git formatted patch attached: - Fixed bug where create_ring would fail for particular snaplen and buffer size combinations - Changed ring allocation to retry with 5% less buffer s

Re: [tcpdump-workers] Exposing linux libpcap ring buffer usage information

On Jul 15, 2009, at 12:45 PM, Dustin Spicuzza wrote: I've attached a git patch to add a function, pcap_buffer_stats() to the pcap API. I noticed some other platforms use the handle- >opt.buffer_size variable, but I don't have access to build any of those so I didn't try an implementation o

Re: [tcpdump-workers] Any chance of getting tcpdump 4.0.1/libpcap 1.0.1 out?

On Jul 15, 2009, at 1:12 PM, Gianluca Varenni wrote: There were a couple of commits lately, including some bug fixes to the USB-linux code. The bug fixes I've been doing have just been to the main branch (I seem to remember somebody indicating that we'd probably just jump directly to 4.1

Re: [tcpdump-workers] Request new DLT value for raw fibre channel

On Jul 15, 2009, at 6:41 PM, kahou lei wrote: Just curious, if the FC packet has 4 bytes SOF in front of R_CTL, can I use the same value? No; DLT values must unambiguously specify the link-layer encapsulation, so a different DLT value should be used. - This is the tcpdump-workers list. V

Re: [tcpdump-workers] -i man "Ties are broken by choosing the earliest match."

On Jul 16, 2009, at 9:04 AM, Doru Georgescu wrote: Please explain what this means, -i in manual: "Ties are broken by choosing the earliest match." Ties between what and what? Match, I suppose, is between the tcpdump expression and packets headers. No - that section of the manual refers to sel

Re: [tcpdump-workers] Libpcap

On Jul 16, 2009, at 3:13 AM, Chris Davies wrote: I have a program that uses libpcap to snoop on packets for the purposes of monitoring. It works very well when compiled on a 32 bit Linux machine and run on a 32 bit Linux and when 64 bit Linux machine and run on a 64 bit Linux. However it

Re: [tcpdump-workers] -i man "Ties are broken by choosing the earliest match."

On Jul 16, 2009, at 12:10 PM, Doru Georgescu wrote: Yes, the comments have been definitely disabled, for me. This is what I see there (http://sourceforge.net/tracker/?func=detail&aid=2813234&group_id=53066&atid=469573 ), on a wonderful yellow background: Comments have been closed for this a

Re: [tcpdump-workers] -i man "Ties are broken by choosing the earliest match."

On Jul 16, 2009, at 12:49 PM, Doru Georgescu wrote: Indeed, I was not logged in. I don't know how to apologize. By telling the SourceForge people that their error message is very unhelpful. :-) I.e., given how horribly wrong their error message is, I don't think you have anything for wh

Re: [tcpdump-workers] Request for assignment of DLT value for GSMTAP

On Jul 21, 2009, at 12:38 PM, Harald Welte wrote: I've already sent mail about this in November 2008 The mail I see from you from November 26, 2008 says: Hi! I'm part of a Free Software project working on GSM protocol analysis based on the gnuradio and USRP software. We would like to r

Re: [tcpdump-workers] DLT type requested for OpenSolaris IPNET header

On Jul 14, 2009, at 5:53 PM, Darren Reed wrote: I'd like to request a DLT type for the "ipnet device" on OpenSolaris. A description of the packet header can be found here: http://arc.opensolaris.org/caselog/PSARC/2009/232/commitment.materials/bpf-psarc.txt and the relevant structure name is

Re: [tcpdump-workers] DLT type requested for OpenSolaris IPNET header

On Jul 21, 2009, at 1:35 PM, Guy Harris wrote: struct dl_ipnetinfo { uint8_t dli_version; uint8_t dli_family; uint16_tdli_htype; uint32_tdli_pktlen; uint32_tdli_ifindex; uint32_tdli_grifindex

Re: [tcpdump-workers] select() regression in libpcap-devel?

On Jun 23, 2009, at 7:34 PM, Mike Kershaw wrote: (This now actually hits my error catcher where 100 fd highs in a row with no packets triggers a shutdown of the source, since libpcap-1.0.0 seems to not return errors in pcap_dispatch when a netdev is removed There does not appear to be a way f

Re: [tcpdump-workers] Request new DLT value for raw fibre channel

On Jul 22, 2009, at 11:17 AM, kahou lei wrote: In this case, can you assign me one more value for FC with SOF? The reason is that our module can send out two type of packets: One with SOF, one without SOF. So what are the contents of the 4 bytes of SOF? - This is the tcpdump-workers list. V

Re: [tcpdump-workers] Request new DLT value for raw fibre channel

On Jul 22, 2009, at 12:21 PM, Guy Harris wrote: On Jul 22, 2009, at 11:17 AM, kahou lei wrote: In this case, can you assign me one more value for FC with SOF? The reason is that our module can send out two type of packets: One with SOF, one without SOF. So what are the contents of the

Re: [tcpdump-workers] unable to build current libpcap git

On Jul 22, 2009, at 11:47 PM, Peter Volkov wrote: Patch in attachment fixes the issue but I'm unsure how sane it is. It is the correct fix. Checked in and pushed. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] Request new DLT value for raw fibre channel

On Jul 22, 2009, at 1:36 PM, kahou lei wrote: It is not base on RFC 3643. We are following the standard from http://www.t11.org . You can find the draft in Fibre Channel (FC) -> FC-FS-3 Fibre Channel - Framing and Signaling - 3INCITS Project 1861-D. Basically, we are following Table 4 Vali

Re: [tcpdump-workers] Request new DLT value for raw fibre channel

On Jul 23, 2009, at 12:03 AM, Guy Harris wrote: On Jul 22, 2009, at 1:36 PM, kahou lei wrote: We are currently supporting: SOFi2 - BCB5 ... Also, does, for example, BCB5 mean that the 4 bytes in the SOF are, in order, 0xBC 0xB5 0x55 0x55, so that the first byte of

Re: [tcpdump-workers] Request new DLT value for raw fibre channel

On Jul 23, 2009, at 9:45 AM, kahou lei wrote: We will put EOF as well. The decoding is correct, we have 4 bytes SOF, first byte is 0xBC , second byte is 0xB5 and so on. OK, I've assigned 225 as DLT_FC_2_WITH_FRAME_DELIMS. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/

Re: [tcpdump-workers] select() regression in libpcap-devel?

On Jul 21, 2009, at 11:12 PM, Guy Harris wrote: On Jun 23, 2009, at 7:34 PM, Mike Kershaw wrote: (This now actually hits my error catcher where 100 fd highs in a row with no packets triggers a shutdown of the source, since libpcap-1.0.0 seems to not return errors in pcap_dispatch when a

Re: [tcpdump-workers] select() regression in libpcap-devel?

On Jul 24, 2009, at 12:29 PM, Guy Harris wrote: On Jul 21, 2009, at 11:12 PM, Guy Harris wrote: On Jun 23, 2009, at 7:34 PM, Mike Kershaw wrote: (This now actually hits my error catcher where 100 fd highs in a row with no packets triggers a shutdown of the source, since libpcap-1.0.0

Re: [tcpdump-workers] Dealing with pcap-linux.c

On Jul 26, 2009, at 6:52 PM, Darren Reed wrote: As well as porting BPF to Solaris, I've been working on developing an implementation of PF_PACKET. I went to try this out with libpcap and it failed badly. pcap-linux.c is a combination of PF_PACKET bits plus all of the code required to deal with

Re: [tcpdump-workers] DLT type requested for OpenSolaris IPNET header

On Jul 26, 2009, at 6:48 PM, Darren Reed wrote: On 21/07/09 01:35 PM, Guy Harris wrote: dli_htype - hook type (in, out, local) Presumably there are specific values for those (0, 1, and 2, or whatever). Yes, 0 for inbound, 1 for outbound, 2 for local. So "inbound" mean

Re: [tcpdump-workers] DLT type requested for OpenSolaris IPNET header

On Jul 14, 2009, at 5:53 PM, Darren Reed wrote: I'd like to request that the assigned name is DLT_IPNET. I've assigned 226 to DLT_IPNET. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] Dealing with pcap-linux.c

On Jul 27, 2009, at 11:40 AM, Guy Harris wrote: The code to use PF_PACKET and PF_INET/SOCK_PACKET sockets *does* have to translate the ARPHRD_ values Linux returns to DLT_ values; that's not a lot of code, and is only minimally involved with Linux's ARP implementation - m

Re: [tcpdump-workers] select() regression in libpcap-devel?

On Jul 26, 2009, at 2:23 PM, Guy Harris wrote: And not only that, but my test program reports, on my Fedora 9 system (2.6.27.25-78.2.6.fc9.i686 kernel), that, if I unplug an interface on which I'm capturing: select() reports that the descriptor is readable; there ar

Re: [tcpdump-workers] pcap_activate can cause pcap_geterr to return a blank string

On Aug 7, 2009, at 5:02 PM, Dustin Spicuzza wrote: However, thats another decision that has to be made by the user, so it seems like it would be nice and simple if pcap_geterr just worked no matter what kind of error was returned. Add two lines to pcap_activate to make pcap_geterr work as expec

Re: [tcpdump-workers] BUG: pcap_fopen_offline doesn't work with pcap_next [patch]

On Aug 11, 2009, at 2:26 PM, Dustin Spicuzza wrote: In git, pcap_fopen_offline (and consequently, any of the other savefile opens) doesn't work with pcap_next because the oneshot_op is not set to anything. One can remedy this by using pcap_create_common to create the pcap_t instead of doin

Re: [tcpdump-workers] mmap in libpcap

On Aug 13, 2009, at 7:02 PM, Sashan Govender wrote: Will libpcap 1.0.0 use mmap packets if the linux kernel has CONFIG_PACKET_MMAP enabled? If it was built on the same version of the OS as the one on which it's running, yes; that should be the case, for example, with versions of libpcap

Re: [tcpdump-workers] [PATCH 1/3] Add getnameinfo support to getname and getname6.

What's the advantage to using getnameinfo() rather than gethostbyaddr(). - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [PATCH] Re: [tcpdump-workers] Bug: Counting dropped packets in

On Aug 30, 2009, at 8:26 PM, Stephen Donnelly wrote: The current 'drop' count in libpcap is not intuitive, and frequently arguably undercounts since it does not include 'rx buffer overflow' and similar interface/OS specific packet loss. OTOH, the documentation is quite clear about what it

Re: [PATCH] Re: [tcpdump-workers] Bug: Counting dropped packets in linux

On Aug 28, 2009, at 1:24 PM, Dustin Spicuzza wrote: Dustin Spicuzza wrote: So after reading the libpcap and kernel source, I see that this is actually how its supposed to work. But it *seems* like it would be quite nice if we could grab the interface driver drop statistics as well as drops

Re: [tcpdump-workers] print_llc code question

On Sep 1, 2009, at 6:55 AM, Jean-Louis CHARTON wrote: Maybe the following question is pretty obvious but since I'm not an 802.2/LLC expert, I can't find a response for it. I was reading print_llc.c code and in llc_print() function, I found something that I don't really understand. At lines 247

Re: [tcpdump-workers] Is libpcap pcap_set_buffer_size() == winpcap pcap_setbuff() ?

On Sep 3, 2009, at 9:13 AM, Chris Morgan wrote: A user of Sharppcap is asking if we support pcap_setbuff(). Apparently this is a winpcap specific option. Yes. The problem is that not all platforms atop which libpcap runs can support setting the buffer size after you've opened a network i

Re: [tcpdump-workers] Is libpcap pcap_set_buffer_size() == winpcap

On Sep 3, 2009, at 10:20 AM, Chris Morgan wrote: I'm asking the user if pcap_set_buffer_size() will work for them. If it does we can implement that interface and we'll be able to have the same api that works the same across windows ...with WinPcap 4.1 or later... mac ...with SnowLeopard o

Re: [tcpdump-workers] Libpcap - pcapfindalldevs

On Sep 4, 2009, at 8:45 AM, Johan Mazel wrote: I wrote a short piece of code in C to show the problem. My code is the following one: *#include #include int main(){ struct pcap_if * found_devices; int result; char * errbuf; printf("Scanning\n"); result = pcap_findalldevs(&foun

Re: [tcpdump-workers] a problem in code... please help

On Sep 6, 2009, at 5:46 AM, Drona Nagarajan wrote: the file is saved as sniff.c now on the terminal when i gcc the code i get the problem /tmp/ccGTnIuI.o: In function `main': sniff.c:(.text+0x107): undefined reference to `pcap_lookupdev' sniff.c:(.text+0x160): undefined reference to `pcap

Re: [PATCH] Re: [tcpdump-workers] Bug: Counting dropped packets in

On Aug 31, 2009, at 2:36 PM, Dustin Spicuzza wrote: So... I've changed my patch to populate ps_ifdrop instead, and it should be good to go, without screwing with current applications. Checked in. I suppose the man page should be updated to mention that ps_ifdrop is only supported on a few

Re: [PATCH] Re: [tcpdump-workers] Bug: Counting dropped packets in

On Sep 17, 2009, at 3:24 PM, Dustin Spicuzza wrote: If you call linux_if_drops with a NULL device, then it segfaults when it tries to do strlen(). The only time this happens is if you call pcap_stats() on a pcap handle that is open but not activated (or the activation failed), and thus the de

Re: [tcpdump-workers] Memory-mapped capture and thinking the packet's

On Sep 26, 2009, at 3:09 PM, Eloy Paris wrote: So it seems like the only option I have to fix the regression is to convert the pcap_next() call to pcap_dispatch()/pcap_loop() semantics. I don't think that copying the packet to a safe place as soon as pcap_next() returns is good enough sinc

Re: [tcpdump-workers] Memory-mapped capture and thinking the packet's

On Sep 26, 2009, at 5:55 PM, Guy Harris wrote: On Sep 26, 2009, at 3:09 PM, Eloy Paris wrote: So it seems like the only option I have to fix the regression is to convert the pcap_next() call to pcap_dispatch()/pcap_loop() semantics. I don't think that copying the packet to a safe

Re: [tcpdump-workers] enquire about the tcpdump

On Sep 29, 2009, at 1:15 AM, Shangbo Wang wrote: I downloaded the tcpdump from your website. I want to enquire that the tcpdump can extract the timestamp in nanoseconds. Tcpdump captures network traffic, and reads savefiles containing captured network traffic, using libpcap. Libpcap does *

Re: [tcpdump-workers] installing tcpdump-4.0.0.tar.gz

On Sep 29, 2009, at 10:10 AM, DALVI RAJIV-TRW486 wrote: I have tcpdump-4.0.0.tar.gz from your website. What command should I use to install tcp dump on my linux pc? Most, if not all, major Linux distributions include tcpdump, so you pro

Re: [tcpdump-workers] [PATCH] SocketCAN support for libpcap - draft implementation

(I'm assuming that I can just reply to the third of your three messages.) On Oct 4, 2009, at 5:20 AM, Felix Obenhuber wrote: I've done some hacks in tcpdump and wireshark that react on incomming packets with DLT_CAN2B to visualize the captured frames but I'd like to get pcap lined up clear

Re: [tcpdump-workers] only one flow is been showed

On Oct 5, 2009, at 7:44 AM, Marcio Veloso Antunes wrote: I have a strange problem going on... TCPDump is showing only one traffic flow. What other flows are you expecting to see? To be specific it is only showing the traffic that is incoming to the interface from the network. Do you me

Re: [tcpdump-workers] Anyone has seen this error "can't create rx ring on packet socket 10: 92-Protocol not available"?

On Oct 9, 2009, at 1:53 PM, Tillmann Werner wrote: No, but it sounds like you are using Linux and your kernel's raw socket interface does not support PF_PACKET. Nope. That message comes if a setsockopt(fd, SOL_PACKET, PACKET_RX_RING, ...) fails on a PF_PACKET socket FD - if the kernel

Re: [tcpdump-workers] pcap-bpf and AIX odm related code

On Oct 9, 2009, at 3:22 AM, Jean-Louis CHARTON wrote: BTW, does someone know why the number of BPF devices is limited to 4 (at least on AIX)? Because the people at IBM who maintain AIX's BPF and tcpdump/libpcap don't have a clue? That's certainly the impression I get, from 1) the fact

Re: [tcpdump-workers] pcap-bpf and AIX odm related code

On Oct 8, 2009, at 12:30 PM, Jean-Louis CHARTON wrote: Am I right? Almost certainly - I'm not an AIX expert, but I don't see any reason why you *wouldn't* be right. I've checked in and pushed your changes on the main Git branch. - This is the tcpdump-workers list. Visit https://cod.sandel

Re: [tcpdump-workers] pcap-bpf and AIX odm related code

On Oct 9, 2009, at 7:11 AM, Michael Richardson wrote: I do not know if there are any AIX users left. For me, it's been at least 15 years since I had one with a compiler. (Not counting the VIO LPAR server on IBM pSeries...) I wonder if we can even maintain this branch of pcap at this point? W

Re: [tcpdump-workers] Convert Wireshark Filterstring to winpcap filter

On Oct 8, 2009, at 3:59 AM, wrote: 1.) I'd urgently need help/advice of how the following filter string has to be to be set as winpcap filter-string: I can't find any working string for the protocols. "eth src 00:0e:0C:76:86:5e" is working. Thanks for any reply and help My filter in

Re: [tcpdump-workers] [PATCH] SocketCAN support for libpcap - draft implementation

On Oct 11, 2009, at 2:58 AM, Felix Obenhuber wrote: On Fri, 2009-10-09 at 08:27 -0400, Alexander Dupuy wrote: ... Summing up the discussion till now, I'd like to request a new DLT for SocketCAN that is called DLT_CAN_SOCKETCAN OK, I've assigned 227 to DLT_CAN_SOCKETCAN, and check

Re: [tcpdump-workers] pcap-bpf and AIX odm related code

On Oct 12, 2009, at 12:28 AM, Jean-Louis Charton wrote: However, I've got a little comment: in my fix proposal, in bpf_load() function Ipassed a dummy_err buffer instead of errbuf to the 2 bpf_odmcleanup() calls. This was intentional to avoid squashing errbuf if for some reason bpf_odmclea

Re: [tcpdump-workers] select() regression in libpcap-devel?

On Jun 23, 2009, at 7:34 PM, Mike Kershaw wrote: (This now actually hits my error catcher where 100 fd highs in a row with no packets triggers a shutdown of the source, since libpcap-1.0.0 seems to not return errors in pcap_dispatch when a netdev is removed (ie usb unplugged or driver crash)

Re: [tcpdump-workers] Capture IP Fragments

On Oct 13, 2009, at 9:05 PM, Abhijit Bare wrote: Does tcpdump capture IP fragments by default - when I do not specify any filter at all? Yes, as long as, for example, the network adapter doing the capturing isn't doing its own IP reassembly, tcpdump (and any other application using libp

Re: [tcpdump-workers] libpcap-1.0.0 on AIX 6.1

On Oct 19, 2009, at 7:57 PM, Randal T. Rioux wrote: I get the following error when running ./configure on an IBM pSeries 7029-6C3 (1.2Ghz POWER4): # ./configure checking ... ./configure[6236]: syntax error at line 6659 : `newline or ;' unexpected # Does anybody have any suggestions? Tr

Re: [tcpdump-workers] buffering packets with libpcap 1.0.0

On Oct 23, 2009, at 5:09 PM, Virgil Mihailovici wrote: I have a couple of questions: 1. I am trying to change the size of the ring buffer allocated by pcap, it seems that I have to use pcap_set_buffer_size to do that. The question is, can I call this as a user, You can have your applicat

Re: [tcpdump-workers] buffering packets with libpcap 1.0.0

On Oct 24, 2009, at 8:53 AM, Virgil Mihailovici wrote: Thanks a lot for your reply. I understand the fact that I am going to consume kernel memory to buffer packets, but can I keep the buffer in use and the let the app free it? Like set the status to TP_STATUS_KERNEL when app is done with

Re: [tcpdump-workers] pcap_findalldevs() failing on FreeBSD 7.2

On Sep 24, 2009, at 10:18 PM, Aaron Turner wrote: Actually, none of his interfaces are being returned (nfe0, nfe1 and lo0). I looked in the change log and don't see any mention of any improvements/fixes in pcap_finalldevs() since 0.9.7 so I figured I'd mention it. On FreeBSD releases with ge

Re: [tcpdump-workers] Debugging an issue with pcap_compile/pcap_setfilter

On Oct 29, 2009, at 8:23 AM, Adayadil Thomas wrote: symbol lookup error: /usr/lib/libpcap.so.0.9.4: undefined symbol: lex_cleanup When you built your program, did you link it with the "-ll" option? If not, try rebuilding it, and linking with "-ll", and let us know whether that fixes the p

Re: [tcpdump-workers] libpcap-1.0.0 configure error on HP-UX 11.11 and 11.31

On Nov 5, 2009, at 1:18 PM, Rick Jones wrote: Is this a known problem? Yes, known problem, fixed in the current top-of-Git-tree code. Somehow a bogus AC_CHECK_HEADERS() call, with no arguments, got into configure.in - that "for" statement happens to work with Bash, but not other Bourne

Re: [tcpdump-workers] Libpcap and 32 bits binary compatibility with Linux x86_64

On Nov 6, 2009, at 3:09 AM, Jean-Louis Charton wrote: Is there any known issue running a 32 bits binary program that uses libpcap on a x86_64 Linux system ? Yes, if libpcap is using the memory-mapped interface, and your kernel doesn't support version 2 of that interface: http://

Re: [tcpdump-workers] packets captured with pcap_open_live("any", ...) seem like strange

On Nov 15, 2009, at 11:56 PM, d00fy wrote: hi all, recently I captured packets from ethernet with libpcap, I found out that packets which were caputred with pcap_open_live("any", ...)seem like strange, there are two bytes new at mac header There is no MAC header for packets captured on t

Re: [tcpdump-workers] pcap_setdirection and mmap access

On Nov 18, 2009, at 12:18 AM, Dragos Ilie wrote: Could somebody please confirm if pcap_setdirection() works with Linux memory-mapped access. My preliminary results indicate that it doesn't (libpcap appears to capture all packets irrespective of the direction). https://sourceforge.net

Re: [tcpdump-workers] Typo in man page tcpdump_man.html

On Nov 19, 2009, at 2:47 AM, Francois-Xavier Le Bail wrote: There is a typo on http://www.tcpdump.org/tcpdump_man.html "-b" must be "-r" That's fixed in the top of the main Git branch. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] tcpdump: patches required for OpenSolaris/SXCE

On Nov 25, 2009, at 10:55 AM, Darren Reed wrote: On 11/24/09 18:31, Michael Richardson wrote: Darren, thanks! Please pull from the git tree, and run "./configure; make check" I would appreciate it if you have any pcap files of formats: DOCSIS (DOCSIS) (printing not supported) This seems t

Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE build >= 125

On Nov 24, 2009, at 3:55 PM, Darren Reed wrote: #ifdef HAVE_ZEROCOPY_BPF #include @@ -510,7 +511,8 @@ if (v == DLT_EN10MB) { is_ethernet = 1; for (i = 0; i < bdlp->bfl_len; i++) { - if (bdlp->bfl_list

Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE build >= 125

On Nov 24, 2009, at 3:55 PM, Darren Reed wrote: --- Makefile.in.distMon Oct 27 18:26:13 2008 +++ Makefile.in Wed Oct 21 21:36:27 2009 @@ -44,6 +44,7 @@ # You shouldn't need to edit anything below. # +LD = /usr/bin/ld CC = @CC@ CCOPT = @V_CCOPT@ INCLS = -I. @V_INCLS@ @@ -326,7 +327,7 @@ # l

Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE build >= 125

On Nov 25, 2009, at 11:42 AM, Guy Harris wrote: Can I plug a Cisco cable modem head-end device into an IPNET device and have it put DOCSIS frames inside IPNET layer-1 framing, so that you get packets with *no* IPNET header? I suspect the answer is "no", in which case you shou

Re: [tcpdump-workers] tcpdump: patches required for OpenSolaris/SXCE

On Nov 26, 2009, at 12:26 PM, Michael Richardson wrote: I'll use that to validate the work. To what does "that" refer? I only see one attachment to Darren's message, which is an inline attachment with the patch that undoes the netdissect stuff; I don't see the capture file. - This is t

Re: [tcpdump-workers] tcpdump: patches required for OpenSolaris/SXCE

On Nov 26, 2009, at 12:26 PM, Michael Richardson wrote: "Darren" == Darren Reed writes: Darren> I've attached two files: e1000g0 is an IPNET capture file Darren> from e1000g0 of some ICMP traffic (i.e. ping) tcpdmp.patches Darren> are the changes I needed to make to stop tcpdum

Re: [tcpdump-workers] tcpdump: patches required for OpenSolaris/SXCE

On Nov 26, 2009, at 2:50 PM, Guy Harris wrote: The short-term fix is to make ipnet_if_print() not take a netdissect_options * as its first argument, and have it pass gndo as the netdissect_options * to other routines. I've checked in a change to do that. (That way, we lose as litt

Re: [tcpdump-workers] Compilation on AIX...

On Nov 27, 2009, at 7:31 AM, Jean-Yves LENHOF wrote: To resolve it, I've changed the first line from #!/bin/sh to #!/sysapp/opensource/bin/bash (seems to be a bashism in the configure file) Yes (not an explicit bashism, just a bug that happens to work on bash). Fixed in the main Git branch

Re: [tcpdump-workers] tcpdump: patches required for OpenSolaris/SXCE

On Nov 27, 2009, at 10:24 AM, Michael Richardson wrote: There is a "temporary" global, "gndo", which you can use for now. That's what I did in print-ipnet.c for the short-term fix. Presumably, for the long-term fix, gndo will be static to tcpdump.c. - This is the tcpdump-workers list. Visit

Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE

On Nov 29, 2009, at 11:43 PM, Darren Reed wrote: Doing some further testing of DLT lists, get_dlt_list() needs some further work. On an OpenSolaris host with ethernet and a tunnel created, they're visible here: # dladm show-link LINKCLASS MTUSTATEBRIDGE OVER igb0

Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE

On Nov 30, 2009, at 5:30 AM, Darren Reed wrote: ... I think the output of "tcpdump -L" could do with mentioning the link name. OK, I've checked in a change to do that - and, when built with libpcap 1.0.0 or later, to, for devices that support monitor mode with the libpcap APIs, report wh

Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE

On Dec 1, 2009, at 4:10 PM, Darren Reed wrote: Use of libdladm is going to be required. Required for what? Enumerating capture interfaces? libpcap uses SIOCGLIFCONF to get the list of interfaces. ...if 1) you *don't* have getifaddrs() and 2) you *do* have SIOCGLIFCONF

Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE

On Dec 1, 2009, at 6:18 PM, Darren Reed wrote: Yes, Solaris does have this *but* it returns interfaces used with IPv4. In libpcap, the code does: fd4 = socket(AF_INET, SOCK_GRAM, 0); ... if (ioctl(fd4, SIOCGLIFCONF, (char *)&ifc) < 0) { On Solaris, each network address family has its own as

Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE

On Dec 1, 2009, at 6:37 PM, Guy Harris wrote: Unfortunately, there's no way in pcap_compile() to specify "netmask unknown". Unless a netmask of 255.255.255.255 will never happen (no host part) or a netmask of 0.0.0.0 will never happen (no net part), in which case we co

Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE

On Dec 1, 2009, at 6:37 AM, Sebastien Roy wrote: I would argue that it's a bug on Solaris that libpcap depends on IP-layer information to choose a capture interface (if that is in fact what it does), It depends on whatever mechanisms the OS provides that supply a list of interfaces. If the

Re: [tcpdump-workers] libpcap: patches required for OpenSolaris/SXCE

On Dec 1, 2009, at 7:06 PM, Sebastien Roy wrote: bash-3.2# tcpdump -i bge0 tcpdump: WARNING: SIOCGIFADDR: bge0: No such device or address This means "sorry, if you're expecting -f to work or a filter containing 'ip broadcast' to work, you're going to be disappointed". Why not say exactly th

Re: [tcpdump-workers] Problem with libpcap

On Dec 2, 2009, at 4:57 AM, Noro Hasina wrote: hello! I'm going to install snort2.8 but it depends on libpcap. So I try to install it but it doesn't work this is the error : gcc -O2 -fPIC -I. -DHAVE_CONFIG_H -D_U_="__attribute__((unused))" -c ./pcap-linux.c gcc -O2 -fPIC -I. -DHAVE_CONFIG

Re: [tcpdump-workers] [PATCH] fix `--disable-ipv6' compilation in tcpdump-4.0.0

On Dec 3, 2009, at 3:50 AM, Nikita Izyumtsev wrote: Hello everybody! I have found issue in tcpdump-4.0.0 with --disable-ipv6 compilation. I'm sending patch for tcpdump-4.0.0 There wasn't a patch attached to your message. because I can't (have not much time at the moment) figure out if the

Re: [tcpdump-workers] [PATCH] SocketCAN support for libpcap - draft

On Oct 25, 2009, at 2:55 AM, Felix Obenhuber wrote: On Sun, 2009-10-11 at 19:42 -0400, Alexander Dupuy wrote: In the specific case of the SocketCAN, the fields in question appear to be transmitted on the wire (otherwise there would have been no need for an optional extension to the ID field

Re: [tcpdump-workers] [PATCH] SocketCAN support for libpcap - draft

On Dec 7, 2009, at 12:57 PM, Felix Obenhuber wrote: On Mon, 2009-12-07 at 11:38 -0800, Guy Harris wrote: I think that preserving the byte order makes sense in order to lean against the behavior of the native netdev interface. This is also the way libpcap does with ETH_P_ALL devices. Is

Re: [tcpdump-workers] Libpcap performance under VMWare guest OSes

On Dec 10, 2009, at 4:45 PM, Mark Bednarczyk wrote: > Somehow libpcap, when it taps into this captured traffic, is not able to > handle a fraction of the actual traffic. The code path through libpcap shouldn't change merely because you're running in a VM - it should be the exact same, as long a

Re: [tcpdump-workers] Libpcap performance under VMWare guest OSes

On Dec 10, 2009, at 6:33 PM, Mark Bednarczyk wrote: > The debian packages are: > > ubuntu9-x86:~# dpkg-query --show libpcap0.8 > libpcap0.8 1.0.0-1 I *suspect* that means that it's libpcap 1.0.0, which means that *if* the kernel supports the memory-mapped interface to PF_PACKET sockets, l

Re: [tcpdump-workers] Inefficiency in BPF code for DLT_RAW

On Dec 23, 2009, at 2:01 AM, Darren Reed wrote: > The links that support the IP tunnels are a fixed type, be > it IPv4 or IPv6, and are reported as being DLT_RAW because > there is no real layer 2 header present. ... > In the face of modern processors, this might seem like > micro-optim

Re: [tcpdump-workers] How to tell if application is handling packets too slowly, causing them to be missed?

On Dec 26, 2009, at 9:27 AM, Chris Morgan wrote: > I have a case where it appears that packets are being missed or > dropped. I wonder if this is due to too much processing being done in > the pcap_dispatch() handler in my application in cases where there are > bursts of packets like facebook cha

Re: [tcpdump-workers] How to tell if application is handling packets

On Dec 26, 2009, at 3:13 PM, Chris Morgan wrote: > Ahh, so ps_drop might work for this. > > Users are reporting issues on Windows with the latest winpcap release > but I do a lot of my testing under Linux, Ubuntu 9.10, 2.6.31 x64. I'd > be doing the drop testing under Linux initially. On Linux i

Re: [tcpdump-workers] [PATCH] SocketCAN support for libpcap - draft

On Dec 8, 2009, at 3:03 PM, Felix Obenhuber wrote: > During capture from a can interface the relevant fields (here struct > can_frame.can_id ) have to be passed to callback() in network byte > order. This means to swap on le platforms - for short htonl. > > cf = (struct can_frame*)&handle->buffe

Re: [tcpdump-workers] How to tell if application is handling packets

On Dec 28, 2009, at 2:03 PM, Robert Edmonds wrote: > libpcap0.8 version 0.9.8-5 ... > libpcap0.8 version 1.0.0-6 That sound you just heard was my head exploding. (Then again, I used to work for a company whose OS release, at the time I joined, was called "Sun UNIX 4.2BSD Version 2.0

Re: [tcpdump-workers] Inefficiency in BPF code for DLT_RAW

On Jan 3, 2010, at 6:42 PM, Darren Reed wrote: > On 23/12/09 06:09 PM, Guy Harris wrote: > >> DLT_IPv4 and DLT_IPv6? > > Can I request for DLT numbers to be allocated? > 228 & 229 would appear to be next. OK, DLT_IPV4 is 228 and DLT_IPV6 is 229. I used capital-V;

Re: [tcpdump-workers] Fw: Building 32 bit libpcap on 64 bit OS

On Jan 5, 2010, at 2:49 PM, Bryan W Budak wrote: > When building libpcap on 64 bit OS it is placed in the /usr/lib directory If you build libpcap from our source code, it is installed, by default, in /usr/local/lib, not /usr/lib. You need special configuration options to install in /usr/lib.

Re: [tcpdump-workers] help with libpcap and tcpdump

On Jan 6, 2010, at 11:08 AM, Tiago Duque wrote: > I am trying to develop an application to a small project I have in my > university. > The application only needs to discover other wireless clients, with the > following parameters: > - Name of the client (ID) By "clients" do you mean, for exampl

Re: [tcpdump-workers] [PATCH] minor VPATH build fixes in top-level Makefile

Checked in. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] [PATCH][RFC] Allow linking from custom staticlib.a instead of list of object files

On Jan 7, 2010, at 12:22 PM, Christian Bell wrote: > libpcap.a: $(OBJ) > @rm -f $@ > - ar rc $@ $(OBJ) $(ADDLARCHIVEOBJS) > + if test -n "$(ADDLARCHIVES)"; then \ > + EXTRA_OBJS=`ar t $(ADDLARCHIVES) | tr '\n' ' '`; \ > + ar x $(ADDLARCHIVES); \ > + fi; \ > +

Re: [tcpdump-workers] [PATCH][RFC] Allow linking from custom staticlib.a instead of list of object files

On Jan 8, 2010, at 12:56 PM, Guy Harris wrote: > You might want to call it ARCHIVELIBS, by analogy to LIBS. Another possibility, if the routines are in an installed library, would be to just add that library to LIBS. The shared libpcap will be linked with all the libraries in LIBS,

Re: [tcpdump-workers] nightly build package

On Jan 10, 2010, at 12:06 PM, Michael Richardson wrote: > I was supposed to setup a master/manager program (it was in python, I > think), that will farm out builds for various platforms to a volunteer > pool. I've forgotten the name of this system, but it was the same one > that wireshark uses.

Re: [tcpdump-workers] forces (and sctp) patch

On Jan 10, 2010, at 11:59 AM, Michael Richardson wrote: > With -v, the ip printer now starts a new line before the protocol. > I am wondering if this was a wise change to have made Comments? To quote the man page for the 4.0.0-based tcpdump on OS X Snow Leopard: -g Do not inse

Re: [tcpdump-workers] Libpcap on VMWare

On Jan 12, 2010, at 1:38 AM, Vikram Roopchand wrote: >This is similar in nature to > http://article.gmane.org/gmane.network.tcpdump.devel/4256 posting (which is > unfortunately unsolved). We are using jnetpcap which is a wrapper over > libpcap. Mark Bednarczyk posted the original

<    8   9   10   11   12   13   14   15   16   17   >