On Dec 4, 2014, at 10:13 AM, Thomas Habets wrote:
> Actual behaviour:
> $ sudo sh -c "LD_PRELOAD=$HOME/opt/buggypcap/lib/libpcap.so ./arping 10.0.0.1"
> ARPING 10.0.0.1
> 60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=0 time=52.633 msec
> 60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=1 ti
On Dec 5, 2014, at 3:15 AM, Thomas Habets wrote:
> On 4 December 2014 at 20:01, Guy Harris wrote:
>> If your program needs to have packets delivered as soon as they arrive, it
>> should, if the version of libpcap with which it's being built has the
>> pca
On Dec 6, 2014, at 6:51 AM, Loganaden Velvindron wrote:
> Support for FreeBSD capsicum doesn't work on FreeBSD 10.1, due to
> cap_rights_init which returns a struct, instead of an int.
Did its return value change in FreeBSD 10? (Presumably it didn't change
between 10 and 10.1.)
> I think th
On Dec 6, 2014, at 9:19 PM, Loganaden Velvindron wrote:
> Here's the config.log output:
>
> configure:4540: checking for cap_rights_init
> configure:4540: cc -o conftest -g -O2 conftest.c >&5
> /tmp/conftest-942ee0.o: In function `main':
> /root/tcpdump/tcpdump-4.6.2/conftest.c:66: undefined
On Dec 6, 2014, at 11:44 PM, Loganaden Velvindron wrote:
> On Sat, Dec 06, 2014 at 11:41:51PM -0800, Guy Harris wrote:
>>
>> On Dec 6, 2014, at 9:19 PM, Loganaden Velvindron wrote:
>>
>>> Here's the config.log output:
>>>
>>> configure:
On Dec 17, 2014, at 12:04 PM, Steve Karg wrote:
> For a few years I have been using DLT_USER0 147 (user defined) for capturing
> and saving a serial protocol used by Wattstopper Digital Lighting Management
> products (see website) and dissecting via Wireshark and Lua. I'm planning on
> adding
On Dec 17, 2014, at 2:11 PM, Xiufeng Xie wrote:
> Currently I need to capture ipv6 packets on Android phone. On my PC,
> tcpdump works well with ipv6 traffic, so I also want to try it on the
> phone.
>
> However, when I cross-compile tcpdump for ARM platform with ipv6 enabled,
> it is forced
On Dec 7, 2014, at 12:17 AM, Loganaden Velvindron wrote:
> Here's the diff:
>
> index d0e90dd..1620bbb 100644
> --- a/configure.in
> +++ b/configure.in
> @@ -207,8 +207,10 @@ AC_ARG_WITH(sandbox-capsicum,
> #
> # All of them must be available in order to enable capsicum sandboxing.
> #
> +# NOT
On Dec 18, 2014, at 1:42 PM, Michael Richardson wrote:
> Guy Harris wrote:
>> I would vote for assuming that there aren't many buggy implementations
>> these days, especially when cross-compiling (which would probably be
>> for a Linux or *BSD target, current versi
On Dec 19, 2014, at 8:36 PM, Loganaden Velvindron wrote:
> I was looking into the github repo, but couldn't find the change.
I didn't check it into the github repo, I checked it into the bpf.tcpdump.org
repo. It should eventually get propagated to the github repo.
> Do you have the git commi
On Jan 8, 2015, at 2:21 PM, Denis Ovsienko wrote:
> This is intended not to make things difficult for innovation, but to assist
> the people from future who might be trying to debug relevant code much later.
...and to make it easier to implement dissection for the protocols (i.e., you
can rea
On Jan 8, 2015, at 3:35 PM, Steve Karg wrote:
> The Packet Delay field contains an integer value that is the
> number of milliseconds since the previous packet.
Presumably, in pcap or pcap-ng files with valid packet time stamps, this is
redundant.
> The Preamble 1 and Preamble 2 fields should
With TPACKET_V3 support, Linux users are discovering what those of us using
BSD-flavored OSes have known for quite a while:
http://askubuntu.com/questions/570885/can-tcpdump-on-ubuntu-14-04-show-packets-in-real-time
Tcpdump uses a timeout of 1 second when opening a capture device; this
On Jan 9, 2015, at 2:09 AM, Michal Sekletar wrote:
> Can't we use new default timeout value (lower) if we detect TPACKET_V3,
The first sentence of my original mail was "With TPACKET_V3 support, Linux
users are discovering what those of us using BSD-flavored OSes have known for
quite a while:"
On Jan 9, 2015, at 8:08 AM, Steve Karg wrote:
> Hello Guy,
>
>>> The Family/Address/IR field contains 3-bits of family code, 2-bits of
>>> address mode, 2-bits of IR (infrared) routing, and 1-bit unused.
>>> The 8 Legrand NITOO families are 000=CAD Filaire, 001=TopDog, 010=CAD RF,
>>> 011=CAD P
On Jan 9, 2015, at 4:11 PM, Steve Karg wrote:
>> I.e., following the Family/Address/IR field, other families might not have
>> the Sequence ID, Source and Destination MAC addresses, Opcode, and Payload
>> Length followed by Payload?
>
> Yes, that is correct.
OK, so we should, for now, indica
On Jan 13, 2015, at 6:05 PM, "Paul \"LeoNerd\" Evans"
wrote:
> I want an HTTP(S) client to write a dump file of the cleartext it is
> sending/receiving, so I can analyse it later. I'm feeling like maybe a
> pcap or pcapng file is good for that, so wireshark et.al. can be
> applied. Ideally it w
On Jan 14, 2015, at 12:10 PM, Michael Tuexen
wrote:
>> On 14 Jan 2015, at 18:19, Denis Ovsienko wrote:
>>
>>> Eventually, we'll be using this format to debug multi-path TCP, in which
>>> case
>>> the IP addresses (and maybe even the IP4/IP6-ness of it) might change.
>>
>> Also there exist
On Jan 9, 2015, at 8:08 AM, Steve Karg wrote:
> Yes, the Family codes are dependent on the hardware. The WattStopper
> DLM hardware uses a USB interface:
> http://www.wattstopper.com/products/digital-lighting-management/configuration-tools/dlm-computer-interface-tools-and-software.aspx
> and al
On Jan 23, 2015, at 12:25 PM, Gerhard Mourani wrote:
> I’m using ntopng which rely on libpcap for the filtering expression. Below is
> what I think to be valide to use into my ntopng configuration file but seem
> to not working at all.
>
> --packet-filter "ip and not proto ipv6 and not ether
On Jan 23, 2015, at 1:23 PM, Gerhard Mourani wrote:
> Yes, it is what I want but seem that ntopng doesn’t take it in consideration
> because I can still view packet sent to or from 192.168.2.10!
> Therfore, I’m presuming that maybe some () or other characters are missing in
> my filtering.
No
On Jan 23, 2015, at 5:44 PM, Gerhard Mourani wrote:
> On mine I get:
The same code.
If you're seeing packets to or from 192.168.2.10, is there some form of
tunneling involved, so that the outermost IP addresses, which the filter
checks, aren't 192.168.2.10, but some innermore IP addresses ar
On Jan 23, 2015, at 6:19 PM, Gerhard Mourani wrote:
> All packets received come from sFlow protocol activated on remote switches (3
> switches on the LAN). Even if I change IP 192.168.2.10 for 192.168.2.209
> which is the one used by the machine where the program run in other to
> exclude sta
On Jan 27, 2015, at 1:58 AM, PEUGNEZ Baptiste wrote:
> I do computer security studies and I wanted to test Coverity, a source code
> analysis tool. If you're interested, I corrected a problem in /pcap-linux.c/
> file: uninitialized variable (/req.tp_frame_size/).
>
> You will find above the G
On Jan 27, 2015, at 4:09 PM, Denis Ovsienko wrote:
> some time ago I did troubleshooting on a Linux PC and that involved running
> tcpdump with the "not tcp" filter on a few network interfaces to put a number
> of background TCP connections out of scope (I was interested how other
> protocols
On Jan 27, 2015, at 4:28 PM, Denis Ovsienko wrote:
>
>> I.e., "tcpdump -i eth0 not tcp" prints *only* TCP packets?
>
> Yes, exactly. Just checked once again.
>
>> Just out of curiosity, what does "tcpdump -i eth0 -d not tcp" print?
>
> root@homepc:~# tcpdump -pni eth0 -d not tcp
> (000) ldh
On Jan 27, 2015, at 4:46 PM, Jesse Gross wrote:
> I'm working on implementing support for Geneve in libpcap, which is
> documented here:
> http://tools.ietf.org/html/draft-gross-geneve-02
>
> Geneve is a tunneling protocol than can encapsulate many different
> things - normally this would be Et
On Jan 9, 2015, at 8:30 AM, Michael Richardson wrote:
> Guy Harris wrote:
>> The longer timeout can reduce capturing overhead, and if you're
>> capturing a high volume of traffic to a file, it's probably the right
>> timeout to have. If, however, you
On Feb 18, 2015, at 10:18 AM, Wesley Shields wrote:
> I've got a patch for this at
> https://github.com/wxsBSD/tcpdump/commit/84998745a29a0ffb3a680c29692c15426a1ce960.
I've checked into the trunk a change to check for pcap_dump_ftell() failing
(which it should *always* have done; had it done
On Mar 22, 2015, at 11:45 PM, "H R, Shashikumar" wrote:
> I am Shashikumar H R currently pursuing M.Tech in Siddaganga Institute of
> technology, Tumkur.
> Currently I' m doing a project in which the packets are captured in pcap-ng
> format. I am using libpcap library(version-1.6.2) to captur
On Mar 28, 2015, at 5:46 PM, Jesse Johnson wrote:
> I am dissecting pcap packets generated by airodump-ng using libpcap and I
> seem to be offset on the access of the Ethernet fram.
You're assuming here that you *have* Ethernet frames. "airo" refers to "the
air", as in "over the air", as in
On Mar 28, 2015, at 9:16 PM, Jesse Johnson wrote:
> Can you recommend a text that explains layer 2 networking a little more
> succinct than the IEEE standards?
Unfortunately, no; I've always used the standard when working on code to
dissect 802.11 frames.
_
Somebody got confused by tcpdump on OS X Yosemite defaulting to capturing on
all devices simultaneously, meaning that it got PKTAP metadata headers:
http://www.tcpdump.org/linktypes/LINKTYPE_PKTAP.html
and asked about this on SuperUser because the "tcpdump -x" and "tcpdump -xx"
output w
On Apr 7, 2015, at 5:28 AM, "H R, Shashikumar" wrote:
> While through list vulnerability , It is mentioned that libpcap suffers the
> from attack mentioned in below link .
>
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-4174
No, it is not mentioned there. What that link says
On May 21, 2015, at 11:16 AM, Michael Richardson wrote:
> I have no problem with having lts- branches created for distros, and I'd
> rather do that than have "old stable". I'd rather call them something like:
> wheezy-4.7
> or centos7-4.7
So, if both Chocolate Coated Spinach Linux "O
On Jun 3, 2015, at 6:16 AM, Kiran Mathews wrote:
> I am sending this mail to ask some questions regarding pcap.Im doing some
> research on synchronisation in wifi. I am trying to synchronise of two
> devices by communicating through wifi.
> So for this, i use pcap lib for sending and receving th
On Jun 4, 2015, at 12:37 AM, Michal Sekletar wrote:
> Can't you just pcap_open more interfaces and for each pcap_t* you get call
> pcap_fileno which will return back file descriptor for that capture. Then you
> can use select/epoll to multiplex on those descriptors.
Or, in newer versions of l
On Jun 10, 2015, at 4:31 PM, Mindaugas Rasiukevicius wrote:
> Darren Reed wrote:
>> Extending BPF
>> =
>>
>> Introduction
>>
>> BPF was originally designed to provide very fast packet matching
>> capabilities for IPv4 but as a result of its generic nature, is
>> capabl
On Jun 10, 2015, at 4:35 AM, Darren Reed wrote:
> On 10/06/2015 5:42 AM, Michael Richardson wrote:
>> re: https://github.com/the-tcpdump-group/tcpdump/pull/464 Guy writes:
>>> We have the -C option, giving a file size in megabytes (real megabytes,
>>> i.e. 1,000,000 bytes, not 1,048,576 bytes);
On Jul 10, 2015, at 7:53 AM, Hei Chan wrote:
> I am using libpcap 1.4.0 to read in pcap.
> And my application crashed at pcap_next() when it read the first packet from
> my pcap file:(gdb) bt#0 0x7715a044 in pcap_next () from
> /usr/lib64/libpcap.so.1
>
> I used wireshark to open the
On Jul 10, 2015, at 7:53 AM, Hei Chan wrote:
> I am using libpcap 1.4.0 to read in pcap.
> And my application crashed at pcap_next() when it read the first packet from
> my pcap file:(gdb) bt#0 0x7715a044 in pcap_next () from
> /usr/lib64/libpcap.so.1
What does "disassemble pcap_next
On Jul 10, 2015, at 10:41 AM, Hei Chan wrote:
> Thanks for your quick reply.
>
> Here is my code:
> pcap_t* m_pPcap;
> char *packet;
> struct pcap_pkthdr header;
>
> m_pPcap = pcap_open_offline(pcapFile, errbuf);
> if (pcapF
On Aug 22, 2015, at 12:48 PM, barcaroller wrote:
> I've been running performance tests against pcap_next_ex() and pcap_dump().
> I've placed micro-second timers around both functions
So those are presumably real-time timers rather than CPU timers.
> and sent millions of packets to my test pr
On Aug 22, 2015, at 6:03 PM, barcaroller wrote:
> Using the Boost timer functions. I could be wrong but I think they are based
> on gettimeofday().
So probably real-time.
That means that, *if* there are other processes on the machine, some of the
time *could* be due to other processes havin
On Aug 22, 2015, at 8:06 PM, barcaroller wrote:
> It has puzzled me too. Keep in mind that I am making millions of these pcap
> calls; only one of them could be taking 2 seconds.
Then the average might be more interesting than the maximum.
> I actually read the packets from a pcap file (not
Currently, we don't use any Flexisms in scanner.l, we *do* use
%a 18400
%o 21500
%e 7600
%k 4550
%p 27600
%n 2000
to try to boost some of lex's table sizes to handle it, and we make an effort
in the configure file to find regular lex and see if it'
On Oct 8, 2015, at 11:33 AM, Michael Richardson wrote:
> wrote:
>> Using pcap_major_version() and pcap_minor_version()) in tcpdump when
>> reading a file, I found:
>
>> Most pcap file have major.minor: 2.4 (current PCAP_VERSION_MAJOR and
>> PCAP_VERSION_MINOR),
>
>> a few have: 1.0 (ahcp.pcap
On Oct 11, 2015, at 5:00 PM, liu wen wrote:
> int pcapfd;
> pcap_t *pcap_handle;
> struct event pcap_ev;
>
> pcap_handle = create_pcap("eth0", NONBLOCKING);
> pcapfd = pcap_get_selectable_fd(pcap_handle);
> if(pcapfd<0){
> perror("pcap_get_selectable_fd() failed!\n");
> exit(1);
> }
>
> if (s
On Oct 11, 2015, at 5:00 PM, liu wen wrote:
> then I run the program on host A and send packets from host B, meanwhile I
> use a tcpdump to capture packets on A (tcpdump -i eth0 port 8000 )
> the tcpdump can capture the packet, but in the program, pcap_dispatch()
> returns 0 when it is called
On Oct 23, 2015, at 7:04 AM, Christian Gieseler
wrote:
> I have a receive thread in my program which shall capture frames according
> to a filter. The Host is sending frames with the same multicast destination
> mac as I want to receive them with the filter.
> Filtering in general works fine. I
On Nov 1, 2015, at 7:18 AM, Denis Ovsienko wrote:
> Thank you for fixing this, my Internet link went down shortly after I started
> to look into the failure report.
Annoyingly, Xcode 7.1's clang didn't catch the format string/argument mismatch
on my machine; apparently, if you have a function
On Nov 10, 2015, at 5:05 PM, Michael Richardson wrote:
> I reviewed draft-tuexen-opsawg-pcapng, while it hasn't had an -01, some work
> has been occuring in the github copy, and so the effort isn't dead, just not
> as visible.
The official version of the spec is, indeed draft-tuexen-opsawg-pcap
On Nov 12, 2015, at 8:26 AM, Michael Richardson wrote:
> Guy Harris wrote:
>
>> I don't see what the problem is with different block types having
>> different option name spaces. Common code to handle options in all
>> block types wouldn't be that useful
On Nov 9, 2015, at 12:29 PM, Martin Kaiser wrote:
> I would like to request a DLT for ISO14443.
>
> ISO14443 is a set of standards defining the communication protocols
> between a contactless smartcard and a card reader. There are some
> commercially available log tools for capturing such traff
On Nov 19, 2015, at 3:29 PM, liu wen wrote:
> I want to statically compile a C project in a laptop(fedora), using command
> line like:
>
> gcc -o myprogram -static main.c ... -levent -lpcap
>
> but I get error:
>
> /usr/bin/ld: cannot find -lpcap
> /usr/bin/ld: cannot find -lc
>
> I tried to
On Nov 19, 2015, at 4:35 PM, liu wen wrote:
> On Fri, Nov 20, 2015 at 12:52 AM, Guy Harris wrote:
>
>> On Nov 19, 2015, at 3:29 PM, liu wen wrote:
>>
>>> I want to statically compile a C project in a laptop(fedora), using command
>>> line like:
>
On Nov 20, 2015, at 12:32 AM, Jamie Bainbridge
wrote:
> Fedora has glibc-static, but no libpcap-static.
Then he'll have to build libpcap from source.
I would suggest building with the *latest* version of libpcap from tcpdump.org,
currently 1.7.4:
http://www.tcpdump.org/#latest-relea
On Jan 15, 2016, at 10:44 AM, Guenter Ebermann
wrote:
> For which type of frame was the LINKTYPE_FLEXRAY 210 allocated?
>
> The file
> https://github.com/the-tcpdump-group/libpcap/blob/master/pcap-common.c
> simply state that:
> /*
> * FlexRay automotive bus - http://www.flexray.com/ - as req
On Jan 19, 2016, at 9:35 AM, Guenter Ebermann
wrote:
> I asked Hannes about DLT_FLEXRAY.
> He told me that they currently dont use pcap for FlexRay and have only
> used it in a limited scenario and that we are free to change the
> layout.
> The format represented the bitsream from the bus 1:1 wi
On Jan 19, 2016, at 5:50 PM, Guy Harris wrote:
> OK, so the new format is that the frame begins with a measurement header,
> which is followed by the bitstream from the bus?
>
> Is the bitstream from the bus padded in that fashion?
>
> From the Wikipedia article on FlexRay
On Jan 20, 2016, at 7:38 AM, Guenter Ebermann
wrote:
> I have a first draft of the packet-specification available:
> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=14264
So it looks as if the extra low-level framing bits aren't included; is that
correct?
The Frame Header is 16 bits; do
On Jan 24, 2016, at 6:46 AM, Yang Luo wrote:
> I have implemented a loopback adapter called "Npcap Loopback Adapter" on
> Windows. It's like lo in linux. I know that libpcap recognizes "lo" by just
> matching the adapter name with "lo".
...*if* the OS doesn't helpfully provide, as one of the int
On Jan 24, 2016, at 8:30 AM, Yang Luo wrote:
> I forgot about one most important thing that libpcap seemingly doesn't
> compile under Windows, even if there's a Win32\Prj in it. Actually I got
> many errors when I build libpcap under VS2005.
>
> I am quite confused with some lines like this in p
On Jan 24, 2016, at 7:47 PM, Yang Luo wrote:
> My ubuntu 14.04 shows the lines below, so I think it doesn't support
> IFF_LOOPBACK.
> root@ly-controller:~# ifconfig lo
> loLink encap:Local Loopback
>
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope
On Feb 4, 2016, at 5:48 PM, Rahmadi Trimananda wrote:
> I am a beginner user of tcpdump. What I want to do is to write my own
> version of tcpdump (or just extend it) to drop/reject network packets.
> AFAIK, tcpdump and libpcap can only sniff packets.
You are correct. The operating system mecha
On Mar 3, 2016, at 2:17 PM, jing dai wrote:
> I'm using tcpdump over a data link type.
>
> tcpdump -y PPP -c 1
No, what you're doing is using tcpdump on a *network interface*, and *trying*
to use a particular data link type on that interface.
> Here's prompt message, PPP is not
On Apr 3, 2016, at 11:47 PM, Yang Luo wrote:
> I'm adding Native 802.11 capture support to Npcap and demonstrate it on
> Wireshark. (See:
> https://github.com/nmap/npcap/releases/download/v0.06-r13/npcap-nmap-0.06-r13-wifi.exe).
> I found that the there are two 802.11 related values to show the a
On Apr 6, 2016, at 5:41 PM, Yang Luo wrote:
> I wonder why this mail went to my spam.. I don't know anything about radiotap
> header so I'm afraid i'm not supplying it.
It's a way to provide "radio metadata" for packets; see
http://www.radiotap.org
for a description of it.
If you wer
On Apr 13, 2016, at 8:44 AM, Ed Sealing wrote:
> Is there a way to programatically disable name resolution in libpcap
No.
> (similar to tcpdump "-n" argument)? I haven't been able to find a variable
> to pass in that would accomplish this directly in the library. I'm sure it
> exists, but can't
On Apr 14, 2016, at 12:05 AM, Denis Ovsienko wrote:
> On Wed, 13 Apr 2016 16:44:24 +0100 Ed Sealing wrote
>> We're writing an application around libpcap. The app may or may not have
>> DNS resolution available. We've noticed that when DNS resolution is not
>> available, we experienc
On Apr 19, 2016, at 10:02 AM, Denis Ovsienko wrote:
> As far as documentation goes, some sense may be presumed in libpcap calling
> posix_fadvise() with POSIX_FADV_SEQUENTIAL. This way the OS would be able to
> adjust the buffers better to read the .pcap file. Does anybody have any
> practical
I have a collection of VMware Fusion virtual machines that I use for
libpcap/WinPcap development.
Until recently, I was able to test monitor-mode support by plugging in a Belkin
Wireless G adapter (with a Zydas chip) into my Mac and telling Fusion to
connect it to the virtual machine.
That no
On Jun 7, 2016, at 6:02 AM, ikuzar RABE wrote:
> I catched the segfault with gdb. This time I put tcp as filter:
>
>Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x76125700 (LWP 5304)]
> 0x7772ddcb in pcap_lex () at scanner.c:3860
> 3860scanner.c
On Jun 8, 2016, at 5:53 AM, Christian
wrote:
> Now, my results in itself make sense and would give me the desired results,
> but they have a big offset to them. 36 seconds to be exact.
So you're saying there's a 36-second offset between which two times?
On Jun 8, 2016, at 1:29 PM, Christian Rupp
wrote:
> The Timestamp when tcpdump grabs the package off of the receiver is 36
> seconds( +/- innaccuracy, here roughly +/- 5-10 µs) after the timestamp when
> tcpdump grabs the package of the sender.
"The" packet in the sense that you have two tcp
On Jun 9, 2016, at 1:19 PM, Guenter Ebermann
wrote:
>> Am 09.06.2016 um 15:47 schrieb Michael Richardson :
>>
>> Guenter Ebermann wrote:
>>> Hardware timestamping of sending/receiving buffer descriptors is done
>>> by NIC.
>>
>> Receiving I understand.
>>
>> Are you sure that the hardware is
On Jun 9, 2016, at 4:09 PM, Guenter Ebermann
wrote:
>
>> Am 10.06.2016 um 00:13 schrieb Guy Harris :
>>
>> But that doesn't mean that the packets time stamped by the hardware when
>> transmitted will be delivered to the PF_PACKET sockets used by libpcap *wit
On Jun 9, 2016, at 4:47 PM, Guenter Ebermann
wrote:
> They are only delivered to the socket on which the packet was sent, not to
> all PF_PACKET sockets.
Then Christian can't get what I think he wants with libpcap - or anything else
doing PF_PACKET socket capturing on Linux - without doing so
On Jun 22, 2016, at 3:24 PM, Michael Richardson wrote:
> It looks like openssl has obsoleted the EVP_CIPHER_CTX type in 1.1.x.
> While 1.1 isn't shipping widely yet, I'd rather be ready.
> I have looked through openssl to see if we can replace it easily,
> and if the replacement will work in 1.0.
On Jun 24, 2016, at 8:58 PM, Yang Luo wrote:
> I found that there are a lot of “precompiled source code files" like
> grammar.c, scanner.c, grammar.h, ,scanner.h, etc. (which are also listed in
> .gitignore). They are NOT contained in the libpcap repo.
>
> I personally want to ship them in the
On Jun 25, 2016, at 7:25 AM, Yang Luo wrote:
> On Sat, Jun 25, 2016 at 3:09 PM, Guy Harris wrote:
>
>> On Jun 24, 2016, at 8:58 PM, Yang Luo wrote:
>>
>>> I found that there are a lot of “precompiled source code files" like
>>> grammar.c, scanner.
On Jun 25, 2016, at 8:01 AM, Yang Luo wrote:
> We know that the libpcap Windows version is called "wpcap", including the
> project files names (wpcap.sln, wpcap.vcxproj) and the library name
> (wpcap.dll). But the current libpcap trunk project is called "libpcap.sln",
> and the built executabl
On Jun 25, 2016, at 5:56 PM, Yang Luo wrote:
> Thanks! Then I will rename the MSVC project files later if you didn't do that.
I haven't renamed them.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/
On Jun 27, 2016, at 11:22 PM, Yang Luo wrote:
> So my thought is we need to add back those functions to libpcap on Windows,
> the related source code files are remote-ext.h, pcap-new.c, etc, which don't
> exist in libpcap. So are we OK with this?
I am not OK with any solution that reintroduces
On Jun 27, 2016, at 10:56 PM, Yang Luo wrote:
> Because of libpcap has exported the a data structure called eproto_db
> (https://github.com/the-tcpdump-group/libpcap/blob/master/nametoaddr.c#L320),
> when I compiled WinDump in MSVC specifying "wpcap.dll" as a delay loaded DLL,
> I encountered
On Jun 30, 2016, at 12:59 PM, Yang Luo wrote:
> But I encountered an issue here, the built out scanner.h and scanner.c will
> report these errors:
>
> 1> gencode.c
> 1>..\scanner.h(239): fatal error C1083: Cannot open include file: 'unistd.h':
> No such file or directory
> 1> grammar.c
> 1>.
On Jun 30, 2016, at 3:14 PM, Yang Luo wrote:
> TcApi.h is contained in WinPcap but not in libpcap. Where to put it?
Put it in the devpack/include directory underneath the directory in which the
TurboCap API:
https://support.riverbed.com/content/support/software/steelcentral-npm/turboc
On Jun 24, 2016, at 9:16 PM, 冲民过人 wrote:
> I am try to make the tcpdump source code. first i run configure, and meet
> some errors in the following. i already got the libpcap,but still get some
> error. The attachment files are the config.log of tcpdump and libpcap.
Unfortunately, the atta
On Jun 25, 2016, at 11:20 PM, Tal Attaly wrote:
> I would be happy if someone could help - Pcap link type of InfiniBand
> http://stackoverflow.com/questions/37936754/pcap-link-type-of-infiniband
The help that would be needed here would be code for Wireshark to interpret
LINKTYPE_INFINIBAND, whi
On Jul 6, 2016, at 12:50 PM, Guy Harris wrote:
> Currently, Wireshark includes no code to process those frames, so it cannot
> handle LINKTYPE_INFINIBAND pcap files or packets for LINKTYPE_INFINIBAND
> interfaces in pcapng files.
BTW, LINKTYPE_INFINIBAND was, according to p
On Jul 6, 2016, at 12:50 PM, Guy Harris wrote:
> Currently, Wireshark includes no code to process those frames, so it cannot
> handle LINKTYPE_INFINIBAND pcap files or packets for LINKTYPE_INFINIBAND
> interfaces in pcapng files.
tcpdump doesn't have any code to process them
On Jul 6, 2016, at 11:42 PM, Tal Attaly wrote:
> I understand that LINKTYPE_ value just saves an id for the link type, but
> parsing code for InfiniBand is exist in wireshark - under ERF link type
> (Extensible Record File), so I wonder why not using the actual link type of
> InfiniBand.
LINK
On Jul 6, 2016, at 11:58 PM, Tal Attaly wrote:
> Buy the way, for the user it looks like wireshark does support InfiniBand
There's "supports InfiniBand" and there's "supports LINKTYPE_INFINIBAND". If
there were, for example, an "InfiniBand over Ethernet" or "InfiniBand over UDP"
protocol, tra
On Jul 15, 2016, at 7:32 AM, Gerard Garcia wrote:
> vSockets are used for host<>guest communication using the standard socket
> API. They already supported in the mainline Linux kernel and can be used in
> VMware VMs.
>
> There is an ongoing work to implement a virtio transport which will add
On Jul 15, 2016, at 12:18 PM, Gerard wrote:
> There are control packets which don't have payload,
So presumably AF_VSOCK_OP_CONTROL packets are control packets that have no
payload; are AF_VSOCK_OP_CONNECT and AF_VSOCK_OP_DISCONNECT also packets with
no payload? (Presumably no packets should
OK, so here's a description of the header, in the style of other pages linked
to by the "Link-layer header types" page:
Packet structure
+---+
| Source CID|
| (8 Octets)|
+---+
| Destination CID |
|
On Jul 19, 2016, at 7:12 AM, Gerard Garcia wrote:
>> 2) What is the format of the transport header?
>
> It is well described in the virtio vsock specification:
> https://stefanha.github.io/virtio/#x1-287 May we just link there?
If that's
struct virtio_vsock_hdr {
le64 src_cid;
On Jul 28, 2016, at 7:12 AM, Christian
wrote:
> I have encountered a problem.
>
> I am capturing Packages with hardware timestamps and nanosecond
> precision...but the timestamps are bugged.
>
> sadly I'm not at the place where I captured the data, so the used used
> command might be slightl
On Jul 28, 2016, at 11:59 AM, Christian Rupp
wrote:
> Tcpdump is printing a good timestamp wrong, as far as i can tell.
So did you build tcpdump from source, or is this a binary version from your
Linux distribution? Which version of tcpdump is this?
___
On Aug 31, 2016, at 9:18 AM, Jonathan Brucker wrote:
> I am posting to request a value for DLT_RFTAP and LINKTYPE_RFTAP.
>
> RFtap is a simple protocol designed to provide Radio Frequency (RF)
> metadata about packets,
What types of packets? 802.11 packets? If so, this is probably better done
2001 - 2100 of 2521 matches
Mail list logo
