--- Begin Message ---
Hi,
The only information I found is the commit
5b7ead917355395a613b637c0de01901fbb156af with title:
"add configure option --disable-protochain, to make Arne happier".
and in it a comment:
"dnl to pacify those who hate protochain insn".
Does anyone use it?
--
Francois-Xavi
I think that there should be a page in the libpcap manual that
explicitly explains the multithreading capabilities and limitations.
Some libraries have an entry in the manual stating that the library is
not threadsafe at all. Nine times out of ten, you're safe to use these
libraries from multiple
--- Begin Message ---
Hello list,
I use libpcap on linux to start a measurement on the PCIe NIC that my company
developed. I set the tstamp type to adapter_unsynced. pcap_set_tstamp_type
returns with PCAP_WARNING_TSTAMP_TYPE_NOTSUP. The packets I receive in the
packet_handler function I reg
--- Begin Message ---
On 07/12/2021 02:26, Denis Ovsienko via tcpdump-workers wrote:
> On Mon, 6 Dec 2021 12:31:33 -0800
> Guy Harris wrote:
>
> [...]
>> The CMake files are likely to be better maintained than the "use
>> Visual Studio directly" files, as you don't need Visual Studio, and
>> don'
--- Begin Message ---
On Mon, 6 Dec 2021 12:31:33 -0800
Guy Harris wrote:
[...]
> The CMake files are likely to be better maintained than the "use
> Visual Studio directly" files, as you don't need Visual Studio, and
> don't need to know how Visual Studio solution or project files work
> internal
--- Begin Message ---
On Dec 6, 2021, at 10:55 AM, Denis Ovsienko via tcpdump-workers
wrote:
> On Mon, 29 Nov 2021 19:20:32 +0100 Francois-Xavier Le Bail via
> tcpdump-workers wrote:
>
>> Does anyone use these files?
>> Win32/Prj/wpcap.sln
>> Win32/Prj/wpcap.vcxproj
>> Win32/Prj/wpcap.vcxproj
--- Begin Message ---
On Mon, 29 Nov 2021 19:20:32 +0100
Francois-Xavier Le Bail via tcpdump-workers
wrote:
> Hello,
>
> The information on building libpcap on Windows with Visual Studio is
> here:
> https://github.com/the-tcpdump-group/libpcap/blob/master/doc/README.Win32.md
> (The supported wa
--- Begin Message ---
Hello,
The information on building libpcap on Windows with Visual Studio is here:
https://github.com/the-tcpdump-group/libpcap/blob/master/doc/README.Win32.md
(The supported way to build libpcap (and tcpdump) on Windows is with CMake)
Does anyone use these files?
Win32/Prj/w
--- Begin Message ---
Guy Harris via tcpdump-workers wrote:
> (The existence of libtool is an indication that shared libraries have
> gotten messy on UN*X.)
> Perhaps for this particular case the right thing to do is to set
> LD_LIBRARY_PATH when running the temporarily-installed
--- Begin Message ---
On Jan 22, 2021, at 7:11 PM, Guy Harris via tcpdump-workers
wrote:
> I'll try experimenting with one of my Ubuntu VMs.
Welcome to Shared Library Search Hell.
Most UN*Xes have a notion of RPATH (with, of course, different compiler
command-line flags to set it).
pcap-conf
--- Begin Message ---
Guy Harris via tcpdump-workers wrote:
>> $ /tmp/libpcap/bin/pcap-config --libs -L/tmp/libpcap/lib
>> -Wl,-rpath,/tmp/libpcap/lib -lpcap
> So that *should* cause /tmp/libpcap/lib to be added to the executable's
> path, which *should* cause it to look in /tmp/l
--- Begin Message ---
On Jan 22, 2021, at 2:54 PM, Denis Ovsienko via tcpdump-workers
wrote:
> I have tested it again with the current master branches of libpcap and
> tcpdump. Both builds (with and without libpcap0.8-dev) now complete
> without errors.
>
> However, in both cases the installed
--- Begin Message ---
On Wed, 9 Sep 2020 17:07:25 +0100
Denis Ovsienko via tcpdump-workers
wrote:
> Here are my steps to reproduce:
>
> libpcap$ ./configure --enable-remote --prefix=/tmp/libpcap
> libpcap$ make
> libpcap$ make install
> tcpdumpbuild$ cmake -DWITH_CRYPTO="yes"
> -DCMAKE_PREFIX_PA
--- Begin Message ---
On Jan 7, 2021, at 5:41 PM, Denis Ovsienko via tcpdump-workers
wrote:
> 5 years of backward compatibility might be OK'ish, although from time
> to time I run into such "long-term support" systems that in practice
> mean someone keeps paying good money for "support" for 5-10
--- Begin Message ---
On Thu, 7 Jan 2021 16:46:41 -0800
Guy Harris wrote:
> 3.1 dates back to 2015. That might be sufficient to treat as a
> minimum.
5 years of backward compatibility might be OK'ish, although from time
to time I run into such "long-term support" systems that in practice
mean s
--- Begin Message ---
On Jan 7, 2021, at 3:21 PM, Guy Harris via tcpdump-workers
wrote:
> So we should either 1) require CMake 3.1 or later or 2) forcibly set
> PKG_CONFIG_USE_CMAKE_PREFIX_PATH to YES. For now, my inclination is to do
> the latter.
That won't work - PKG_CONFIG_USE_CMAKE_PREF
--- Begin Message ---
On Sep 9, 2020, at 9:07 AM, Denis Ovsienko via tcpdump-workers
wrote:
> The "Found pcap-config" message means that FindPCAP.cmake has not found
> libpcap by means of pkg-config, and the lack of the message means the
> pkg-config method worked. A few weeks ago Ubuntu 18.04 s
--- Begin Message ---
On Jan 7, 2021, at 9:35 AM, Bill Fenner via tcpdump-workers
wrote:
> These jobs are still failing, but now for a different reason.
Part of the problem is that pkg-config wasn't finding the locally-installed
libpcap under /tmp, because PKG_CONFIG_PATH wasn't set to point t
--- Begin Message ---
On 07/01/2021 18:35, Bill Fenner via tcpdump-workers wrote:
> These jobs are still failing, but now for a different reason. The build
> succeeds, but the tests fail - the tests that require the new libpcap.
> However, if you augment TESTrun to print the version, it says
> 1.1
--- Begin Message ---
On Wed, Sep 9, 2020 at 12:08 PM Denis Ovsienko via tcpdump-workers <
tcpdump-workers@lists.tcpdump.org> wrote:
> Travis CI tcpdump builds have been failing for a while and I went to
> see why. It is easy to see that only the jobs that have
> "BUILD_LIBPCAP=yes CMAKE=yes" fail
--- Begin Message ---
On Oct 7, 2020, at 3:16 PM, Denis Ovsienko via tcpdump-workers
wrote:
> Do you mean to introduce a function like pcap_error(), which the
> developers would be able to interrogate if they need in use cases like
> this? Then existing functions could be slowly updated as neede
--- Begin Message ---
On Wed, 7 Oct 2020 14:37:41 -0700
Guy Harris via tcpdump-workers
wrote:
[...]
> A new API could be added that returns a PCAP_ERROR_ value rather than
> -1 on error (so as not to break source or binary compatibility with
> code using the existing APIs).
Do you mean to intro
--- Begin Message ---
On Oct 7, 2020, at 1:30 PM, Fernando Gont via tcpdump-workers
wrote:
> WHile using pcap_inject() in Linux, it is failing with "pcap_inject(): send:
> Resource temporarily unavailable". In principle, one would expect that for
> temporary problems (such as this one), one ma
--- Begin Message ---
Hi,
WHile using pcap_inject() in Linux, it is failing with "pcap_inject():
send: Resource temporarily unavailable". In principle, one would expect
that for temporary problems (such as this one), one may one to wait a
bit and retry. So it would make sense to somehow be ab
--- Begin Message ---
Hello list.
Travis CI tcpdump builds have been failing for a while and I went to
see why. It is easy to see that only the jobs that have
"BUILD_LIBPCAP=yes CMAKE=yes" fail, for example [1], and the same jobs
built well before, for example [2].
The tcpdump build process fails
--- Begin Message ---
On 21/08/2020 20:26, Michael Richardson wrote:
>
> Ray, I rebased raybellis-gzip-v2 upon libpcap head.
> Do you have a github that I can add as as reviewer?
Do you mean my github a/c name? That's just "raybellis".
> Mostly I did this because the FreeBSD tests seemed to
Now that the libpcap repo has a program (rpcapd) and travis.yml, it seems
that maybe it should have a logo unique to it. I am inspired in asking
simply because github wants to know what my social media image should be :-)
{maybe we already have one, and I've forgotten?}
I envision something arou
Dear experts,
Could somebody tell is this changes are reasonable?
The pcap-config.in file have the following check that if $libdir is
not /usr/lib then set RPATH env:
if [ "$libdir" != "/usr/lib" ]
then
RPATH=$V_RPATH_OPT$libdir
fi
The problem is if the build system is x86_64 then $libdir wil
Thanks Guy.
Is the best way then to parse pcapNG in code and run bpf_filter on the
packets please.
a) open the pcap file in c
b) parse the blocks
c) For every enhanced packet block
c1) Manually construct struct pcap_pkthdr *
c2) Run bpf_filter explicitly
This file can be updated as it is
On Sep 13, 2018, at 1:49 PM, Madhav Ancha wrote:
> Is there a way to get the "options" along with the "packet data "in an
> Enhanced Packet Block when reading the pcapNG files please?
No. There are no provisions in the current pcap API to provide that
information, as the API was designed whe
Hi,
Is there a way to get the "options" along with the "packet data "in an
Enhanced Packet Block when reading the pcapNG files please?
pcap_next_ex() seems to return only the packet data.
Thanks
Madhav.
___
tcpdump-workers mailing list
tcpdump-
>Behalf Of Francois-Xavier Le Bail
>On 23/07/2018 15:33, Michael Richardson wrote:
>> Francois-Xavier Le Bail via tcpdump-security wrote:
>> > Need autoreconf.
>> > And 1.9.1 ?
>>
>> Let's do 1.9.1 in September.
>
>Why not this week to have a proper version tag ?
Agreed, seems like a simpl
On 23/07/2018 15:33, Michael Richardson wrote:
> Francois-Xavier Le Bail via tcpdump-security wrote:
> > Hello,
>
> > We have in 1.9.0 branch:
>
> > $ git grep '1\.9\.0-PRE-GIT'
> > configure:# Generated by GNU Autoconf 2.69 for pcap 1.9.0-PRE-GIT.
> > configure:PACKAGE_VERSIO
Francois-Xavier Le Bail via tcpdump-security wrote:
> Hello,
> We have in 1.9.0 branch:
> $ git grep '1\.9\.0-PRE-GIT'
> configure:# Generated by GNU Autoconf 2.69 for pcap 1.9.0-PRE-GIT.
> configure:PACKAGE_VERSION='1.9.0-PRE-GIT'
> configure:PACKAGE_STRING='pcap 1.9.0-PR
I've released the 1.9.0 version.
It is not identical to the 1.9.0rc2 release.
It includes a bunch of small typos/fixes found in the rc2 release,
including some missing files in the release tarball, and a
64-bit alignment fix.
There are no CVEs or security issues fixed in libpcap compared to the 1.
Hi,
I've an application which uses libpcap 1.8.1 in TPACKET_V2 mode on an Azure VM
with multiple cores (4 - 8 in my case). The underlying interface is Azure's
paravirtualized NIC - hv_netsvc.
In this setup, I observe that under heavy ingress traffic the notion of kernel
and user space ownershi
On Apr 16, 2017, at 12:19 PM, Joseph Freemaker
wrote:
> When compiling libpcap on AIX 6.1 receive the error:
>
> configure: error: flex is insufficient to compile libpcap. libpcap requires
> Flex 2.5.31 or later, or a compatible version of lex.
>
> However flex 2.5.4 is installed per the belo
When compiling libpcap on AIX 6.1 receive the error:
configure: error: flex is insufficient to compile libpcap. libpcap requires
Flex 2.5.31 or later, or a compatible version of lex.
However flex 2.5.4 is installed per the below:
$ flex --versionflex version 2.5.4
Is there a workaround for this
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
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: No such file or directory.
(gdb) bt
#0 0x7772ddcb
Hi all,
I work on Debian 8, with linux version 3.16.0-4-amd64, with flex
2.5.39-8+b1.
I wrote a C program which reads packets on one interface (NIC), then dumps
it into a pcap file. I usually use filter (vlan 1024) when I capture with
my program and it works fine with libpcap-1.3.0 (soname: libpca
dear team,
i'm still waiting for your idea on how to achieve fast link loss
detection with libpcap
thanks in advance,
csaba mate
niif/as1955
On 01/07/2016 12:50 PM, mate csaba wrote:
hi,
On 01/07/2016 11:51 AM, Guy Harris wrote:
On Jan 7, 2016, at 2:20 AM, mate csaba wrote:
i'm devel
hi,
On 01/07/2016 11:51 AM, Guy Harris wrote:
On Jan 7, 2016, at 2:20 AM, mate csaba wrote:
i'm developing a router (rtros.nop.hu) which uses libpcap to capture and send
packets to interfaces.
the interface handler can be found here:
http://sources.nop.hu/src/zzz/nat-pcapInt.c
it's an inter
> Since this is [RFC] and - if I understand correctly - there are
> problems with the produced BPF code, maybe this should be
> discussed in the tcpdump-workers mailing-list?
Michal Sekletar wrote:
> Any particular reason why we shouldn't continue discussion here? I
> think it
Hi AJ
I google it but I didn't get any specific java libpcap library.
Regards
Shashi
-Original Message-
From: Ander Juaristi [mailto:ajuari...@gmx.es]
Sent: Wednesday, July 15, 2015 12:04 PM
To: tcpdump-workers@lists.tcpdump.org
Cc: H R, Shashikumar
Subject: Re: [tcpdump-wo
On 07/15/2015 07:42 AM, H R, Shashikumar wrote:
Hi All
I want know whether any libpcap library is available in java. If there please
provide me the link.
Thanks and Regards
Shashikumar H R
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdu
Hi All
I want know whether any libpcap library is available in java. If there please
provide me the link.
Thanks and Regards
Shashikumar H R
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo
As discussed a few months ago, this is how github is being used.
1) "master" for tcpdump, libpcap and tcpdump-htdocs lives on
http://github.com/the-tcpdump-group
We pull daily from github master to the server at bpf.tcpdump.org.
2) release branches live on bpf.tcpdump.org, and are
Denis Ovsienko wrote:
> Could you please check bpf repository once again? There is still no
> such commit in it.
okay, I sorted things out.
The problem is that I got stuck with the MPTCP patch which no longer
compiled, and wound up reverting too much, and then I had code on the wrong
br
Those headers are in BlueZ 4 (or 5) and Linux (source:
include/net/bluetooth/; not exported to userland)
"own copy" --> own version of "unofficial" Linux API for Bluetooth.
Feel free to rewrite that "code" to satisfy BSDvsGPLv2. As I remember
there is no plan to publish API by Bluetooth Linux group
Guy Harris wrote:
> I guess my concern is whether the "our own copy" could get people
> complaining that we just took GPLed code from Linux or not; if it was a
> reimplementation from scratch (I don't think "clean room" is
> necessary), that should suffice.
I am not disputing thi
From: Guy Harris
> 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 you are capturing a high volu
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're printing packets to the console,
>> you'
Hi,
We are using version 1.6.2.
Regards,Giray
> From: anders.bro...@ericsson.com
> To: tcpdump-workers@lists.tcpdump.org
> Date: Wed, 28 Jan 2015 15:21:10 +
> Subject: Re: [tcpdump-workers] Libpcap performance problem
>
>
> Hi,
> What version of libpcap are you usin
ernel.
Regards,Giray
> From: david.lai...@aculab.com
> To: rick.jon...@hp.com; tcpdump-workers@lists.tcpdump.org
> Date: Wed, 28 Jan 2015 17:17:15 +
> Subject: Re: [tcpdump-workers] Libpcap performance problem
>
> From: Rick Jones
> > On 01/28/2015 06:57 AM, Giray Simsek
From: Rick Jones
> On 01/28/2015 06:57 AM, Giray Simsek wrote:
> > Hi,
> > We are currently working on testing Linux network performance. We
> > have two Linux machines in our test setup. Machine1 is the attacker
> > machine from which we are sending SYN packets to Machine2 at a rate
> > of 3millio
On 01/28/2015 06:57 AM, Giray Simsek wrote:
Hi,
We are currently working on testing Linux network performance. We
have two Linux machines in our test setup. Machine1 is the attacker
machine from which we are sending SYN packets to Machine2 at a rate
of 3million pps. We are able to receive these p
To: tcpdump-workers@lists.tcpdump.org
Subject: [tcpdump-workers] Libpcap performance problem
Hi,
We are currently working on testing Linux network performance. We have two
Linux machines in our test setup. Machine1 is the attacker machine from which
we are sending SYN packets to Machine2 at a rate
Hi,
We are currently working on testing Linux network performance. We have two
Linux machines in our test setup. Machine1 is the attacker machine from which
we are sending SYN packets to Machine2 at a rate of 3million pps. We are able
to receive these packets on Machine2's external interface and
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
Hello,
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 Github commit.
https://github.com/peugnezb/libpcap/commi
Hello Guy,
It would certainly make sense to try and make it generic so that the
LINKTYPE could be used by multiple families. If the other families
don't have a dongle code and packet delay, they could fill them in
with some consistent values (i.e. match the DLM values, have zero
packet delay) if
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
Hello,
Is there anything pending before assigning a new DLT? I put a pull
request into GitHub:
https://github.com/the-tcpdump-group/libpcap/issues/401
Are there other files that I need to modify (i.e. HTML or documentation files)?
Best Regards,
Steve
Hello,
I am new to this community. And i would like to know from where i should start.
Please guide me.
Thanking you
Bipul kumar
On 1/12/15, David Laight wrote:
> From: Guy Harris
>> On Jan 9, 2015, at 2:09 AM, Michal Sekletar wrote:
>>
>> > Can't we use new default timeout value (lower) if we
From: Guy Harris
> 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 h
Hello Guy,
> 6 or 7 - escape
> 7 or 6 - DLM Bootloader
>
> The information you quoted said "111=escape, and 111=DLM Bootloader"; I
> assume one of those 111's is supposed to be 110. Which one of them should be
> 110?
6 - unused
7 - escape and DLM Bootloader (unfortunately).
Th
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
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 PLC, 100=CAD IR, 101=DLM, 111=escape, and 111=DLM
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 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:"
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're printing packets to the console,
> you're probably doomed if it's a high volume of tr
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 PLC, 100=CAD IR, 101=DLM, 111=escape, and 111=DLM Bootload
On Thu, Jan 08, 2015 at 06:57:08PM -0800, Guy Harris wrote:
> 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
>
>
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 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
Hi Denis,
> Steve, if this time you are receiving this as a subscriber to the mailing
> list, could you describe the encoding in a way similar to one used for
> http://www.tcpdump.org/linktypes/ ?
See below.
Best Regards,
Steve
WattStopper DLM room bus protocol from LMCI USB dongle.
+--
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 Thu, 18 Dec 2014 06:46:10 +0200 Guy Harris wrote
>
> 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 pr
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
It's much easier to get the wider review and long term archival by posting to
the mailing list. I have done that for you.
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
> Lig
There seems to be a bug in libpcap version 1.4.0 . The same code works
good in 1.6.2 :)
Thanks a lot.
Aparna N
On 6 November 2014 13:56, Aparna Nagarajan wrote:
> Hi Guy Harris,
>
> Here is the translated code.
>
> /*initialization*/
> static u_int off_didx = 5;
> bpf_u_int32 didx_m
Hi Guy Harris,
Here is the translated code.
/*initialization*/
static u_int off_didx = 5;
bpf_u_int32 didx_mask = 0x0ffc;
didx = didx<<18;
b0 = gen_ncmp(OR_MACPL, off_didx, BPF_W, didx_mask, BPF_JEQ, 0,
(bpf_int32)didx);
the i/p value of didx is 0x40.
here is what 'ge
On Nov 5, 2014, at 10:41 PM, Aparna Nagarajan
wrote:
>>
>> Hi All,
>>
>> I am trying to add some BPF code for capture filters.
>>
>> I am basically trying to load data into accumilator from some offset,
>> Mask it and them match it with some value.
>>
>> Here is the OPcode:
>>
>> { 0x20, 0
>
> Hi All,
>
> I am trying to add some BPF code for capture filters.
>
> I am basically trying to load data into accumilator from some offset,
> Mask it and them match it with some value.
>
> Here is the OPcode:
>
> { 0x20, 0, 0, 0x0013 }, { 0x54, 0, 0, 0x0ffc }, { 0x15, 0, 1,
> 0x0100
morphyno wrote:
> sudo /usr/sbin/tcpdump -s 0 -nei eth9 -w /mnt/tmpfs/eth9_rx.pcap -B
> 200 From "free -k", I see about 2G allocated on Ubuntu
> Before:
> free -k total used free shared buffers cached Mem: 65928188 1337008
> 64591180 1164 26556 68596 -/+ buffers/cache: 1
Michael,
Thanks a lot for the reply.
It's not critical at all so don't worry about it. I just need to
set an expectation of which upstream version the fix will be
in. For our OS releases, we maintain a patch stream which we
apply to a fixed revision (currently 1.5.1) until it's suitable
for us
Jon Anderson wrote:
> I recently had a change merged with the-tcpdump-group/libpcap
> (39540b9e1c4a9e4343c6cab77ee66e054f6bce51)
> Is there any way to tell which libpcap version this change will
> distributed with?
General answer:
Unless someone said that they pulled it up to li
Hi,
I recently had a change merged with the-tcpdump-group/libpcap
(39540b9e1c4a9e4343c6cab77ee66e054f6bce51)
Is there any way to tell which libpcap version this change will
distributed with?
Thanks,
Jon
--
Jon Anderson
Principal Software Engineer
ORACLE RPE Systems (Networking)
Tel: ++44 (0)
Hello,
A few weeks ago, I reported a problem with TPACKET v3 missing packets
when using libpcap in nonblocking mode. I managed to work around this
reliably, but I continued seeing missed packets on platforms which don't
support TPACKET v3.
The problem seems to be due to the way libpcap sometimes
On Thu, Jun 05, 2014 at 07:21:26PM +0200, Steffen Bauch wrote:
> Hi,
>
> libpcap 1.5.3 (as deployed in Ubuntu 14.04 LTS) (and current GIT
> master head) will not output timestamps in a right way if pcapng
> savefiles are used and timestamp conversion is requested with
> pcap_open_offline_with_tsta
Hi,
libpcap 1.5.3 (as deployed in Ubuntu 14.04 LTS) (and current GIT master
head) will not output timestamps in a right way if pcapng savefiles are
used and timestamp conversion is requested with
pcap_open_offline_with_tstamp_precision(). For traditional pcap files
necessary timestamp convers
Guy Harris wrote:
> Note also that there will be a configure-script option to enable this,
with the
> default being "no". Enabling remote capture increases the attack surface
of an
> application using libpcap, as it would receive messages from a
> not-necessarily-trusted remote
Guy Harris wrote:
> information (which should NOT be supplied in the URL, as that can show up
in
> the output of ps!) or "we're running over SSL/TLS but the certificate has
> expired, so do you want me to continue or not?" information or
Could we put a hash of the public key in
On Mar 30, 2014, at 7:01 AM, barcaroller wrote:
> I have two questions related to buffers in libpcap.
>
> - I would like to to use the pcap_set_buffer_size() to run various
> performance tests. However, I do not know the default buffer size (on a
> 64-bit Linux system with 16 GB of RAM) and
yahoo.com> writes:
>
> That does not solve the cases I wrote below. The filters I wrote are also
difficult to translate to the syntax
> you suggested:
> * (vlan 1 or vlan 2) and ip
> * (vlan 1 or ether) and ip
>
> I'm hoping to be free to implement the algorithm I suggested in the near
future.
On Dec 11, 2013, at 5:54 AM, Michael Richardson wrote:
> I propose to release a libpcap 1.5.3 this week with the following changes:
It doesn't appear that it's been released yet; if it hasn't, and if you release
one from the current top of the 1.5 branch, it should have fixes for this bug,
as
I propose to release a libpcap 1.5.3 this week with the following changes:
1) if PCAP_LINUX_TPACKET="v3" or ="v2" then the specific method
will be used chosen, unless:
2) a new pcap_linux_tpacket(enum method) has been called by the application
(which having a GUI, I presume) can let the u
Gianfranco Costamagna wrote:
> as said into the title, a macports developer reports that some dbus stuff
is
> shown as interface.
> Please read this bug report Ettercap/ettercap#416
> At this moment we are just excluding them from ettercap, but I want ask
you if
> you think
Sébastien Luttringer wrote:
> I found a regression in libpcap between 1.4.0 and >=1.5.1 which cause
arpwatch
> to consume 100% of CPU and stop working when listening on a bridge
interface on
> i686.
> I'm currently not able to reproduce it on another computer (vm).
> I tes
1 - 100 of 655 matches
Mail list logo
