Re: [tcpdump-workers] pcap_dispatch on linux 2.6 with libpcap 1.1.1

On Aug 23, 2010, at 3:54 PM, Jim Lloyd wrote: > What is the relationship between the socket receive buffer and the > mmap buffer? Does the mmap buffer replace the socket receive buffer, Yes. > I currently have my primary testing > machine configured with > > net.core.rmem_default = 4194304 > n

Re: [tcpdump-workers] tcpdump not giving details

On Sep 25, 2010, at 6:44 AM, Nigel Kent wrote: > Why does tcpdump not give my more details? Each time it only comes as - > 16:22:26.128541 [|ether] > > # ./tcpdump -vv not port 22 > tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 > bytes > 16:22:26.128541 [|ether]

Re: [tcpdump-workers] TCPDUMP RPM

On Oct 4, 2010, at 5:40 PM, Branca Beiruth wrote: > I have been used SuSE Linux Server and I need TcpDump. > Can you help me? http://software.opensuse.org/113/en Type "tcpdump" into the search box, select whatever version of SuSE SLE you have from the version list (what version are you

Re: [tcpdump-workers] How to read a big pcap file?

On Oct 19, 2010, at 5:52 AM, Subhasis Mohapatra (submohap) wrote: > I have designed a tool using libpcap,but its not reading big pcaps. What does "big" mean here? Larger than 2GB, larger than 4GB, or larger than some other value? What happens if your tool tries to read a big pcap file? What

Re: [tcpdump-workers] How to read a big pcap file?

On Oct 20, 2010, at 2:01 AM, Subhasis Mohapatra (submohap) wrote: > Thanks for the information, > I was using an older version of libpcap. > > My pcap file is greater then 4GB and in Linux platform. Then you'll probably need libpcap 1.0.0 or later. > It was giving an error like "Unable to read

Re: [tcpdump-workers] DLT_DBUS

On Oct 31, 2010, at 12:29 AM, Martin Vidner wrote: > please allocate a new network type for libpcap dump files, as > described in > http://wiki.wireshark.org/Development/LibpcapFileFormat#Global_Header > . > It is for dumping traffic on D-Bus, http://en.wikipedia.org/wiki/D-Bus > , and the packe

Re: [tcpdump-workers] sniffing HTTP traffic to load-balancer on a

On Nov 1, 2010, at 9:42 PM, Jim Lloyd wrote: > You want some kind of port > mirroring And http://wiki.wireshark.org/SwitchReference for information and links to manuals about doing port mirroring - or whatever the switch vendor calls it - o

Re: [tcpdump-workers] sniffing HTTP traffic to load-balancer on a dedicated machine

On Nov 1, 2010, at 8:57 PM, Andrej van der Zee wrote: > Hi, > > I am looking for a solution that sniffs all HTTP traffic to the > load-balancer in a multi-tier web application, but WITHOUT starting > tcpdump on the load-balancer itself. Does the load balancer support some form of "mirror port"?

Re: [tcpdump-workers] sniffing HTTP traffic to load-balancer on a

On Nov 2, 2010, at 12:05 AM, Andrej van der Zee wrote: > The idea is to sniff all incoming/outgoing traffic on the WAN side of > the load-balancer, Is the "WAN side" implemented as: some form of WAN (a T{n} or E{n} serial line, or an OC{n} or STM{n} optical link) going directly into th

Re: [tcpdump-workers] MIME type for libpcap (tcpdump -w)

On Nov 2, 2010, at 6:01 PM, Glen Turner wrote: > I was a bit surprised when I clicked on a libpcap packet capture that it did > not automatically launch "wireshark -r". I have searched the archive of this > mailing list looking for a MIME type and found no consensus. > > I seek consensus for t

Re: [tcpdump-workers] MIME type for libpcap (tcpdump -w)

t two MIME type registrations: http://dev.w3.org/SVG/profiles/1.1F2/publish/mimereg.html http://www.w3.org/TR/2009/WD-MathML3-20090924/appendixb.html do include UTI codes, as well as Windows clipboard names.) > * Object Identifier(s) or OID(s) > (See RFC1494) > [] ...

Re: [tcpdump-workers] tcpdump and timestamps

On Nov 9, 2010, at 1:15 AM, Andrej van der Zee wrote: > Today I received a tcpdump file from a client with timestamps that did > not correspond to the system clock. If I remember correctly, tcpdump > does not store complete timestamps but only a delta compared to the > first timestamp. No. Each

Re: [tcpdump-workers] MIME type for libpcap (tcpdump -w)

nd can be viewed in the > file pcap-common.c of the libpcap code. The data link types > LINKTYPE_USER0 to LINKTYPE_USER15 are reserved for local use and thus > captures containing those data link types are intentionally not > interoperable. Hopefully they won't get upset if, in a fut

Re: [tcpdump-workers] MIME type for libpcap (tcpdump -w)

On Nov 9, 2010, at 5:00 PM, Glen Turner wrote: > 9. Applications which use this media type > See RFC 4288, section 4.5 > [ > Libpcap, a C library to capture network packets for POSIX-like systems. > > Net::Pcap, Jpcap, python-libpcap, Ruby/Pcap are respectively Perl, Java, > Python and Ruby bind

Re: [tcpdump-workers] Does libpcap/tcpdump support "SKF_AD_QUEUE" instruction ?

On Nov 11, 2010, at 6:55 PM, Jon Zhou wrote: > Does libpcap/tcpdump support "SKF_AD_QUEUE" instruction and BPF filter? I presume you mean "does libpcap support generating the SKF_AD_QUEUE special packet offset in BPF filter programs?" If so, the answer is "no"; there's probably no reason why

Re: [tcpdump-workers] DHCPv6 improvements for readability

On Nov 10, 2010, at 10:40 AM, sth...@nethelp.no wrote: > Having started to play with DHCPv6, I found the tcpdump printout of > DHCPv6 options, > > http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2 > > could be improved. Below are my suggested improvem

Re: [tcpdump-workers] Possible memory leak

On Nov 10, 2010, at 4:40 AM, Flavio Truzzi wrote: > Hi, I'm getting a memory leak in the following code, I made it to iterate > through multiple files, I don't know where it leaks... https://sourceforge.net/tracker/?func=detail&aid=2987111&group_id=53067&atid=469579 Not fixed in any re

Re: [tcpdump-workers] libl 1.1 or 2.0 works with libpcap 1.1.1?

On Nov 9, 2010, at 4:20 PM, Mark Ashley wrote: > I notice libnl has incremented to 2.0 a few weeks ago and the API is > reportedly different. > > http://www.infradead.org/~tgr/libnl/ > > Has anyone verfied that libnl 2.0 works with libpcap 1.1.1? I've verified that it *doesn't*, and have check

Re: [tcpdump-workers] DLT_DBUS

On Nov 15, 2010, at 8:23 AM, Martin Vidner wrote: > Hello? Are there some concerns that I should address? Just too busy? Just been busy. I've assigned 231 as DLT_DBUS/LINKTYPE_DBUS, and checked the changes into the trunk and 1.1 branches and pushed them.- This is the tcpdump-workers list. Visi

Re: [tcpdump-workers] Error when installing.

On Nov 15, 2010, at 5:08 AM, try fatur wrote: > Hi there. I have something serious problem. I am installing Snort ver 2.9, > there's wrote must have libcap library. I've download from tcpdump, then i > install daq ver 03. The problem is coming, when i type command "./configure" > in the daq di

Re: [tcpdump-workers] please help me...

On Nov 15, 2010, at 7:16 PM, alfian ilarizky wrote: > please help me... (it is for my final assignment) > > i want to capture bluetooth packet data using wireshark.. > but i cannot... > > please help me... > my OS is windows 7 ultimate x86 Wireshark depends on libpcap/WinPcap to capture networ

Re: [tcpdump-workers] fragmented ip packets

On Nov 23, 2010, at 12:51 AM, Ankith Agarwal wrote: > I am trying to filter all the SIP packets using pcap filter on ports of > 5060 and 5061. But, some of the SIP packets are fragmented in the IP layer > because of their size (greater than MTU). I wanted to know whether the > pcap_loop api give

Re: [tcpdump-workers] fragmented ip packets

On Nov 23, 2010, at 8:44 AM, Ankith Agarwal wrote: > Thank you for your valuable suggestions. I have tried out this filter > expression---"ip[6]&0x02 == 1 and (sip related port numbers)". But, if a > fragmented SIP packet is encountered, will this filter return the first > fragments as sip or the

Re: [tcpdump-workers] Problem with usb support

On Nov 24, 2010, at 5:49 AM, Michael Szalay wrote: > is it possible to configure libpcap.1.1.1 without usb support? > I do not need it and I have the following error: I don't have that error, at least not on: Ubuntu 9.10, 2.6.31-22-generic kernel; Fedora 9, 2.6.27.25-78.2.56.fc

Re: [tcpdump-workers] Problem with usb support

On Nov 25, 2010, at 4:59 AM, Michael Szalay wrote: > OS is SLES10, Kernel 2.6.16.60-0.21. Thanks. I've checked into the trunk and the 1.1 branche a change that should fix this; could you try those versions?- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] large packets parsing using TcpDump

On Nov 29, 2010, at 10:24 PM, Mali Shternhell wrote: > I'm using TcpDump in order to capture snmp request-response messages. > > When the response packet is larger than 1468 TcpDump fail to capture the > packet What do you mean by "fail to capture the packet"? If you mean that the packet isn

Re: [tcpdump-workers] Problem with usb support

On Nov 28, 2010, at 10:18 PM, Michael Szalay wrote: > thanks. I checked that out, now I have no warnings in ./configure, but the > following error > in make > > gcc -O2 -fpic -I. -DHAVE_CONFIG_H -D_U_="__attribute__((unused))" -g -O2 -c > ./pcap-linux.c > gcc -O2 -fpic -I. -DHAVE_CONFIG_H

Re: [tcpdump-workers] what is the best value for PCAP_FRAMES?

On Dec 1, 2010, at 1:19 AM, Jon Zhou wrote: > The bigger PCAP_FRAMES or a smaller value will get a better performance? > > I.e. > > PCAP_FRAMES=max tcpdump -I eth0 -w /dev/null > > Or > > PCAP_FRAMES=4096 tcpdump . As distributed by tcpdump.org, neither libpcap nor tcpdump pay any attent

Re: [tcpdump-workers] large packets parsing using TcpDump

On Nov 30, 2010, at 10:35 PM, Mali Shternhell wrote: > Hi, Thanks for the response. > my question is why tcpdump doesn't parse the large snmp response packet > as it does for the typical response packet. Because the SNMP printer routine that parses an ASN.1 BER item will quit if the length of t

Re: [tcpdump-workers] Problem with usb support

On Nov 30, 2010, at 10:28 PM, Michael Szalay wrote: > Thanks, now I have another error: > > ./runlex.sh flex -Ppcap_ -oscanner.c scanner.l > bison -y -p pcap_ -d grammar.y > NONE:0: /usr/bin/m4: ERROR: EOF in string > bison: subsidiary program `/usr/bin/m4' failed (exit status 1) > make: *** [gr

Re: [tcpdump-workers] Git with problems?

On Dec 1, 2010, at 10:19 AM, Flavio Truzzi wrote: > Hi I have an application that filter packets, using an old version it works > fine, when using the git version > > The main problem is that when I apply filters with "dst" it works fine, but > with "src" nothing. Does the same thing happen

Re: [tcpdump-workers] Libpcap And snap_len

On Dec 11, 2010, at 4:35 AM, Vikram Roopchand wrote: > We have been using Libpcap 1.1.1 heavily On what operating system are you using it? The code used for capturing is very different on different OSes. > and noticed > something of the following nature. It seems that during

Re: [tcpdump-workers] pcap_compile() causes a segmentation fault on Ubuntu

On Dec 14, 2010, at 1:05 AM, Selçuk Cevher wrote: > If you need to see the sources for listAllDevices() and openNetworkDevice() > as well, I can post them. I definitely need to see the source code for openNetworkDevice(). Presumably its first argument is a reference to a pcap_t *, but, if it

Re: [tcpdump-workers] build a raw packet

On Dec 15, 2010, at 3:01 PM, Gabe Black wrote: > I had looked at libnet prior to posting, however the first hit on google that > led to its documentation > http://libnet.sourceforge.net/libnet.html#Alphabetic%20List%20of%20Functions > did not seem like it would be helpful; nothing on packet co

Re: [tcpdump-workers] pcap_lib_version problem while installing DAQ

On Dec 27, 2010, at 10:26 PM, Appaji_Peruri wrote: > I am having a problem while installing DAQ which is used by snort . DAQ > package is searching for the function pcap_lib_version and returning the > following error . > > checking for pcap_lib_version... checking for pcap_lib_version in -lpc

Re: [tcpdump-workers] pcap_lib_version problem while installing DAQ

On Dec 28, 2010, at 11:03 AM, Guy Harris wrote: > Are you doing this on some Linux distribution? If so, what distribution is > it, and what version of that distribution is this? > > If not, what operating system are you doing this on, and what version of that > operati

Re: [tcpdump-workers] Request for new DLT number

On Dec 28, 2010, at 8:23 PM, Gianluca Varenni wrote: > This is what PPI does. > > http://www.cacetech.com/documents/PPI%20Header%20format%201.0.10.pdf That document misspells "linktype" as "dlt". :-) DLT_ values are platform-dependent; there is no guarantee that DLT_xxx will have the same va

Re: [tcpdump-workers] libpcap OSX problems

On Dec 29, 2010, at 7:59 PM, Mathew Rowley wrote: > I have been debugging why libpcap is unable to sniff packets in pcaprub (of > metasploit) and have found a few things. Maybe some of you can enlighten me. > > 1. With this sample source - if the timeout variable is 0 in pcap_open_live, > cap

Re: [tcpdump-workers] Obtaining MAC on OSX using AF_LINK

On Dec 30, 2010, at 5:00 PM, Mathew Rowley wrote: > I am trying to understand how to get the MAC address when a pcap_addr family > is of type AF_LINK. ...on OS X, which is relevant here. AF_LINK is a BSDism, and only OSes that inherit AF_LINK from whatever flavor of BSD introduced it support

Re: [tcpdump-workers] Obtaining MAC on OSX using AF_LINK

On Jan 2, 2011, at 2:33 PM, Guy Harris wrote: >> It seems that the pacap_addr.sa_data should be of type (struct sockaddr_dl*) > > Yes. As per later in my message, that's actually "No"; I missed the "sa_data" part. *addr* should be cast to something of ty

Re: [tcpdump-workers] At which level does packet capture take place ?

On Jan 5, 2011, at 7:59 AM, Rajagopal Aravindan wrote: > I have always wondered as to at which level packet capture works. > Is it this way ... > > 1. For packets that are sent out, a copy of every packet, given to the > device driver by the protocol layer, would be captured by the pcap libr

Re: [tcpdump-workers] libpcap pcap_stats() integer wrap in struct pcap_stat u_int

On Jan 6, 2011, at 4:38 PM, Brandon Enright wrote: > I haven't yet looked at the implementation of pcap_stats() or > pcap_stats_ex() but is it possible to make pcap_stats_ex() available on > Unix (specifically recent x86_64 Linux kernels)? In principle, yes. pcap_stats_ex() does, however, have

Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector

On Jan 10, 2011, at 6:16 AM, Schemmel, Hans-Christoph wrote: > I´ve written a dissector (MUX27010) for wireshark and I want to commit it to > the project. Therefore I need a new DLT value for this dissector/protocol > because the protocol doesn´t base upon another data link layer protocol. > Wh

Re: [tcpdump-workers] Linux system headers 2.6.36 and pcap/bpf.h

On Jan 11, 2011, at 11:47 PM, Tim Sammut wrote: > Is this a known issue, It was not known to me until now. > or is there a more correct workaround? None that I know of. I'm looking at a change that should fix this without breaking any reasonable code, although I'm sure somebody will have fig

Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector

On Jan 12, 2011, at 4:59 AM, Schemmel, Hans-Christoph wrote: > A packet begins with a flag (octet 0xF9, section 5.2.1.1), followed by address > and control field. Is this DLT value only for the Basic Option, or is it also used for the Advanced Option? If it's also for the Advanced Option:

Re: [tcpdump-workers] new interface card for wireshark

On Jan 17, 2011, at 8:11 AM, Jens Grimmer wrote: > Hi wireshark community, (Actually, this list is more like "the tcpdump and libpcap community", but, not surprisingly, there's some overlap between the two communities.) > I would like to ask for a new encapsulation type for libpcap files > (W

Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector

On Jan 17, 2011, at 5:52 AM, Schemmel, Hans-Christoph wrote: > Concerning dissecting: The communication between GSM modem and the host is > captured with an USB Tracer. The tracer uses a proprietary format for the > trace > files, but the data of these files can be exported, e.g. as csv file. I´

Re: [tcpdump-workers] Obtaining interface IP address and MAC address with libpcap

On Jan 24, 2011, at 3:49 AM, roy hills wrote: > Does libpcap allow me to get the interface IP address Yes - use pcap_findalldevs() and look for the interface in question; note, however, that you really mean "the interface's IP addresses", plural, as an interface could have more than one IPv4 a

Re: [tcpdump-workers] Obtaining interface IP address and MAC address

On Jan 24, 2011, at 5:56 PM, Darren Reed wrote: > Why should it need to? > > The interfaces used to do both of the above are almost universal now: > SIOCGIFADDR and SIOCGIFHWADDR. So I can do those ioctls on Windows? Google says, for what it's worth: Your search - SIOCGIFADDR site:ms

Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector

On Jan 20, 2011, at 3:05 AM, Schemmel, Hans-Christoph wrote: > The format of the additional header is: > > | Header_Size | Msg_ID | Freq_ID | Start_Pos | End_Pos | Flag | ... | > Msg_ID | > Freq_ID | Start_Pos | End_Pos | Flag | Direction | MUX_Frame > > Header_Size (1 Octet): Total length

Re: [tcpdump-workers] new hardware integration to libpcap/wireshark

On Jan 24, 2011, at 5:03 AM, Jens Grimmer wrote: > I will submit the patches with my enhancements as soon as possible. Yes, its > right, our packet data begins with a pseudo-header. For sure I will provide > you with a documentation for the pseudo-header. Would a mailed PDF-document > be OK fo

Re: [tcpdump-workers] Fwd: ./configure failure, .log attached

On Jan 26, 2011, at 3:09 PM, Cameron Elliott wrote: > ./configure told me to send my ./configure failure to the list. > (because it failed) > I hope that is correct. Yes. > If you understand why it is failing, please explain to me. It's failing because one of the checks it's doing is assuming

Re: [tcpdump-workers] Possible to use libpcap without root privileges?

On Jan 31, 2011, at 5:42 AM, marku...@bredband.net wrote: > Is it possible to use libpcap without root privileges? $ man pcap ... Reading packets from a network interface may require that you have spe- cial privileges: Under SunOS 3.x or 4.x with NIT or BPF:

Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector

On Jan 26, 2011, at 2:30 AM, Schemmel, Hans-Christoph wrote: > The size of the header depends on the number of PPP packets in the payload of > the MUX frame. The Header_Size indicates whether Msg_ID, Freq_ID, Start_Pos, > End_Pos, and Flag are present. > For example: > The header of a frame witho

Re: [tcpdump-workers] Fwd: ./configure failure, .log attached

On Jan 27, 2011, at 11:11 AM, Guy Harris wrote: > It's failing because one of the checks it's doing is assuming that an OS with > IPv6 support has a header file, but your version of Ubuntu - > and possibly other Linux distributions - don't. > > The Single UNI

Re: [tcpdump-workers] Linux system headers 2.6.36 and pcap/bpf.h

On Jan 12, 2011, at 1:30 PM, Guy Harris wrote: > I'm looking at a change that should fix this without breaking any reasonable > code, although I'm sure somebody will have figured out how to do some pattern > of includes that won't work. I've checked that change i

Re: [tcpdump-workers] [PATCH] vlan: Fix Linux VLAN accel compile test under GCC 4.4

On Jan 31, 2011, at 5:40 AM, Jesper Dangaard Brouer wrote: > VLAN acceleration support is broken, when using GCC compiler >= 4.4 > (tested with gcc version 4.4.5 (Debian 4.4.5-4)), due to the configure > script. > > GCC 4.4 does not indirectly include the type of u_int, which the > configure cod

Re: [tcpdump-workers] A puzzled maintainer with questions regarding DLT_ values

On Jan 19, 2011, at 1:02 AM, M.Baris Demiray wrote: > First of all, we're developing radio communication software, > particularly STANAG 5066. Alongside the serial interface for the modem > interface our implementation also has a socket interface for testing > purposes. > > Now we have the need

Re: [tcpdump-workers] A puzzled maintainer with questions regarding DLT_ values

On Feb 3, 2011, at 8:47 AM, M.Baris Demiray wrote: > Hello again, > > I have solved almost all the problems that I mentioned below and now I > am sure that I should ask for a new DLT value for STANAG 5066 [1] MAC > (Medium Access Control Sublayer) PDUs. Currently I am able to dissect > these PDU

Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector

On Feb 3, 2011, at 2:05 AM, Schemmel, Hans-Christoph wrote: > I´ve mixed up some field sizes in my previous mail. Msg_ID and Freq_ID have a > size of 2 octects, not 1 octect like the other fields, sorry. So the optional > part has a size of 7 octects. But your conclusion is correct: The Header_Si

Re: [tcpdump-workers] pcap_next_ex calls pcap_oneshot instead of p->oneshot_callback

On Feb 4, 2011, at 5:00 AM, Tobias C Rittweiler wrote: > In the latest release as well as git HEAD, pcap_next_ex > calls pcap_oneshot (the default callback) instead of > p->oneshot_callback like pcap_next does. > > This means that packets change underneath one application > when using Linux and

Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector

On Feb 4, 2011, at 1:59 AM, Schemmel, Hans-Christoph wrote: > The parts that don´t correspond to a PPP packet are AT commands or responses > (like "ATI", "AT+CSQ" or "+CSQ: 18,99"). This content is interpreted and > displayed as raw text in the Wireshark subtree for the payload/information of >

Re: [tcpdump-workers] A puzzled maintainer with questions regarding

On Feb 4, 2011, at 12:25 AM, M.Baris Demiray wrote: > In fact this is not what STANAG 5066 Annex H "Implementation Guide and > Notes" section suggests. According to this section and the tests held > by DRA (Defence Research Agency), > > 1) The throughput is not strongly sensitive to frame size >

Re: [tcpdump-workers] The network is cut with tcpdump.

On Feb 3, 2011, at 10:36 AM, Masahiro Kamikubo wrote: > When the tcpdump command was executed hereafter, the network was cut. "Cut" meaning that you lost network connection on the network interface on which you were capturing network traffic? If so, that might be a problem with... > The envir

Re: [tcpdump-workers] HUGE packet-drop

On Jan 31, 2011, at 10:56 AM, Jesper Dangaard Brouer wrote: > M. V. yahoo.com> writes: > >> so, i dont know what else to do, seems like nothing works for me :-S >> 1) does anyone have any other suggestions that may help? >> 2) about MMAP support in Debian kernel: i installed Debian5.0.3 from >

Re: [tcpdump-workers] Best OS / Distribution for gigabit capture?

On Feb 5, 2011, at 11:20 PM, M. V. wrote: > as i mentioned in my previous mail, (with the title: "HUGE packet-drop") i'm > having problem trying to dump gigabit traffic on harddisk with tcpdump on > Debian5.0. i tried almost everything but got no success. Did you try to check whether the memor

Re: [tcpdump-workers] HUGE packet-drop

On Feb 6, 2011, at 10:07 PM, Luca Bruno wrote: > I can't speak for Lenny, but it looks like Squeeze (which was released > a couple of days ago) has both: > * http://packages.debian.org/squeeze/libpcap0.8 Ah, so Squeeze has the libpcap 1.1.1 version of libpcap 0.8. :-) (Yes, it makes no sense to

Re: [tcpdump-workers] A puzzled maintainer with questions regarding

On Feb 6, 2011, at 10:17 PM, M.Baris Demiray wrote: > Unfortunately no, there is not. As in SIS Layer dissector this is also > a part of a standard which is available only to NATO member states Hey, I'm a citizen of a NATO member state :-) > and that therefore we access through an account.

Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector

On Feb 4, 2011, at 1:59 AM, Schemmel, Hans-Christoph wrote: > Guy Harris alum.mit.edu> writes: > >> >> OK, so it's: >> >> Header_Size: 1 octet >> >> A sequence of zero or more instances of: >> >>

Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector

On Feb 14, 2011, at 6:26 AM, Schemmel, Hans-Christoph wrote: > Yes, Start_Pos and End_Pos are relative to the beginning of the MUX_Frame, > but a > PPP chunk does not start directly at the beginning of a MUX_Frame > (Start_Pos=0). > The PPP frame starts after the header fields of the MUX_Frame.

Re: [tcpdump-workers] Problem with libpcap installation

On Feb 16, 2011, at 7:28 AM, client server wrote: > I have been trying to configure libpcap-1.0.0 and libpcap-1.1.1 in cygwin > under WindowsXP but I am getting an error "checking for ANSI ioctl > definitions... no" in both.:( The libpcap configure script doesn't support building on Windows -

Re: [tcpdump-workers] request for a DLT value for wireshark DVB-CI dissector

On Feb 13, 2011, at 3:14 PM, Martin Kaiser wrote: > I'm working on a wireshark dissector for DVB-CI (Common Interface). The > dissector analyzes the communication between a PC-Card module and a DVB > receiver. It's not based on any other data link layer protocol. > > I defined the pcap packet da

Re: [tcpdump-workers] request for a DLT value for wireshark DVB-CI

On Feb 26, 2011, at 12:37 PM, Martin Kaiser wrote: > I hope this makes things clearer. I'll put this additional info on the > website within tomorrow. Yes, it does, thanks. Should I just cite that page as a reference in the comment I put into pcap/bpf.h for the DLT value?- This is the tcpdump-

Re: [tcpdump-workers] request for a DLT value for wireshark DVB-CI

On Feb 27, 2011, at 10:39 AM, Guy Harris wrote: > Yes, it does, thanks. Should I just cite that page as a reference in the > comment I put into pcap/bpf.h for the DLT value?- And I *especially* thank you for giving such a detailed specification! Detailed specifications such a

Re: [tcpdump-workers] request for a DLT value for wireshark DVB-CI

On Feb 27, 2011, at 10:55 AM, Martin Kaiser wrote: > yes, please refer to that page. I'll keep it up to date. We've been putting an email address for the person requesting the link-layer type value; which address should we use for you?- This is the tcpdump-workers list. Visit https://cod.sandel

Re: [tcpdump-workers] request for a DLT value for wireshark DVB-CI

OK, I've assigned 235 as LINKTYPE_DVB_CI and DLT_DVB_CI. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] inject & read from the same interface

On Mar 2, 2011, at 2:49 AM, Tobias C Rittweiler wrote: > Is this expected behavior? The only thing I'd expect in this case is whatever the particular mechanism atop which libpcap runs on a particular OS does; that may well differ from OS to OS. > I'm also interested what in pcap-linux.c makes

Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector

On Mar 2, 2011, at 7:49 AM, Schemmel, Hans-Christoph wrote: > I just want to ask if you´ve already assigned a DLT value for the dissector? Not yet - I've been somewhat busy the past week and a half, and I have to condense all the e-mail on this thread into a complete and precise description of

Re: [tcpdump-workers] mmap

On Mar 3, 2011, at 10:21 PM, 吴仁科 wrote: > Does the latest libpcap release use mmap functionality? libpcap 1.1.x supports the memory-mapped capture mechanisms for regular network adapters on both Linux and FreeBSD, as well as the memory-mapped capture mechanism for USB on Linux. - This is the

Re: [tcpdump-workers] [Fwd: the error about transplanting the libpcap]

On Mar 3, 2011, at 10:35 PM, 林荣文 wrote: > when libpcap is transplanted on the embeded system, there are some error > occoured. What happens if you try to compile the C source file I've attached in the cross-compilation environment? Try compiling it with arm-hismall-linux-gcc -c testf

Re: [tcpdump-workers] Request for new DLT value for Wireshark

On Mar 3, 2011, at 9:01 AM, Schemmel, Hans-Christoph wrote: > this is the detailed description of the data format. > > LINKTYPE_MUX27010 OK, I've assigned 236 as LINKTYPE_MUX27010 and DLT_MUX27010. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] typos in man pages

On Mar 7, 2011, at 4:32 AM, Miroslav Lichvar wrote: > here is a patch fixing some typos. Thanks. Checked into the trunk and 1.1 branch. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] tcpdump + pf_ring capture: bogus savefile header

On Mar 8, 2011, at 1:15 AM, M. V. wrote: > now, when i use tcpdump which is compiled with libpcap-pf_ring to capture > traffic, Is that standard tcpdump, or Luca's modified tcpdump (which is part of the PF_RING stuff)? If it's the standard tcpdump, what happens if you pass it the argument "-s

Re: [tcpdump-workers] A puzzled maintainer with questions regarding

On Feb 17, 2011, at 11:41 PM, M.Baris Demiray wrote: >> Do they begin with the 16-bit synchronization sequence, or is that stripped >> off, so that they begin with the header field? Do data PDUs include the CRC >> at the end, or is that stripped off? > > 16-bit synchronization sequence is sen

[tcpdump-workers] New page, giving link-layer header type values and descriptions, added to www.tcpdump.org

http://www.tcpdump.org/linktypes.html contains a description of all the existing link-layer header types for which there is either 1) an official standard; 2) a reasonably complete description; 3) a tcpdump or Wireshark dissector from which I could construct a

Re: [tcpdump-workers] A puzzled maintainer with questions regarding

On Mar 14, 2011, at 5:14 AM, M.Baris Demiray wrote: > Indeed, may be you could also add (along with the link to the old > unclassified version) that new versions of STANAG 5066 haven't > introduced any alterations to D_PDU headers and the last edition, > Edition 3, is totally backward compatible

Re: [tcpdump-workers] New page, giving link-layer header type values

On Mar 15, 2011, at 4:51 PM, Sam Roberts wrote: > On Sun, Mar 13, 2011 at 2:41 PM, Guy Harris wrote: >>http://www.tcpdump.org/linktypes.html >> >> contains a description of all the existing link-layer header types for which >> there is either > > Not

Re: [tcpdump-workers] New page, giving link-layer header type values

On Mar 15, 2011, at 5:58 PM, Sam Roberts wrote: > It sounds like you think there are two variants of 802.15.4, one with > an FCS, and one without. No, I don't think that. Perhaps I need to rename the page, and change the language in it to make this even clearer. I originally said "link-layer

Re: [tcpdump-workers] New page, giving link-layer header type values

On Mar 15, 2011, at 8:27 PM, Sam Roberts wrote: > Why would anyone want to deduce this? In wireshark, both dlt values > will map to the same dissector, They *shouldn't* map to the same dissector. They should map to *different* dissector routines, which call a common routine, passing an "FCS pr

Re: [tcpdump-workers] New page, giving link-layer header type values

On Mar 15, 2011, at 10:12 PM, Sam Roberts wrote: > I've got the pdf at work, but from memory, its basically something like: > > ctrl, 1 byte > ... optional fields (present if bit set in control, each control bit > maps to presense or absence of an optional header field) > length field (not op

Re: [tcpdump-workers] A possible bug in libpcap segfault + malloc + pcap_open_live + reproducible + libpcap0.[78] + Ubuntu karmic

On Mar 22, 2011, at 12:28 AM, harish badrinath wrote: > Each filter component is listed in a single line and the program would > read the entire file and compress all the arguments to one single > filter to be passed onto to pcap_compile. ...and null-terminate it, right? - This is the tcpdump-w

Re: [tcpdump-workers] A possible bug in libpcap segfault + malloc +

On Mar 22, 2011, at 10:28 PM, harish badrinath wrote: > From Line 43 in attachment2, > pkmain (buffer=0x8053ca0 "Ports=80,25,11 Protcols=ALL,TCP Deny > Ports=22,88 Deny Protocols=ICMP,UDP GAR BAG . .."), this is right > before things fail. So where's the code that reads the file and builds the C

Re: [tcpdump-workers] [PATCH 1/2] Fix: pcap-linux.c: create_ring(): calibrate req.tp_frame_size as in tpacket_rcv() (almost).

On Mar 22, 2011, at 8:47 PM, julm+tcpd...@savines.alpes.fr.eu.org wrote: > From: Julien Moutinho > > Symptom is a capture where caplen < len <= snaplen. > For instance to reproduce: > % sudo tcpdump -U -w /tmp/lo.pcap -s 128 -i lo -n ip & > tcpdump: listening on lo, link-type EN10MB

Re: [tcpdump-workers] Directly accessing packet buffer

On Mar 28, 2011, at 11:18 PM, Rayne wrote: > I would like to be able to directly access the buffer where packets are > stored when they're received. After some googling, I think perhaps libpcap > with mmap would be the solution. Does libpcap 1.0 and above support mmap? Libpcap 1.0 and above su

Re: [tcpdump-workers] I've a question about capture result, please help.

On Mar 31, 2011, at 11:18 PM, Sake Blok wrote: > Different systems use different snaplengths by default. And different versions of tcpdump have different default snaplengths - 4.1.0 and later versions have a default of 65535, but earlier versions have a default of 68 if built without IPv6 supp

Re: [tcpdump-workers] [PATCH] print-sflow.c - actually print more than one extended counter sample

On Apr 1, 2011, at 6:03 PM, Rick Jones wrote: > tcpdump 4.1.1, and 4.3.0-PRE-GIT_2011_04_01 prints just one expanded > counter sample per captured PDU because it mistakenly skips forward > sflow_sample_len when it has already adjusted tprt and tlen while it was > printing the sample contents. Thi

Re: [tcpdump-workers] pcap_findalldevs, pcap_addr doesn't have AF_INET entries on OSX

On Apr 2, 2011, at 7:40 PM, Bob wrote: > Hello, I just noticed that no AF_INET address is returned when getting an > interface list (from pcap_findalldevs) on OSX even when an IPv4 address is > assigned to that interface. An AF_INET6 address is however returned. Is this > the expect behavior?

Re: [tcpdump-workers] pcap_findalldevs, pcap_addr doesn't have AF_INET entries on OSX

On Apr 3, 2011, at 4:24 PM, Bob wrote: > Yes, I'm checking the whole linked list. I get an AF_LINK and AF_INET6 per > interface but no AF_NET. Works great on Ubuntu. Probably something simple > I'll keep debugging. The program I was running was the findalldevstest program, the source to which

Re: [tcpdump-workers] live capture Ethernet gives me zero-packets

On Apr 3, 2011, at 11:38 PM, Andrej van der Zee wrote: > I am trying to get started with a live capture using libpcap. Somehow I > cannot get the contents of a packet. It seems that all bytes are zeroed. > Here is the source code: ... > void callback(u_char * user, const struct pcap_pkt

Re: [tcpdump-workers] [PATCH] print-sflow.c - actually print more

On Apr 4, 2011, at 12:15 PM, Rick Jones wrote: > As for the latter, I don't have some of the pre-reqs installed: > > raj@tardy:~/tcpdump$ make check > uudecode --help || (echo "No uudecode program found, not running tests"; > echo "apt-get/rpm install sharutils?"; exit 1) > /bin/sh: uudecode: no

<    10   11   12   13   14   15   16   17   18   19   >