Note also that there is *NO* guarantee that the struct pcap_pkthdr or packet
data pointers handed to your callback remain valid after it returns, so those
pointers must not be saved by your callback or anything it calls.
___
tcpdump-workers mailing list
On Feb 13, 2014, at 7:21 AM, "Daniel H. Bahr" wrote:
> This keeps getting weirder...
>
> Just unplugged the SIGSEGV signal to get a stacktrace upon its
> occurrence and I've performed 3 complete cycle (that is 2 packets)
> simulations without getting any buggy behavior.
>
> Is it at all po
On Feb 13, 2014, at 10:23 AM, "Daniel H. Bahr" wrote:
> There IS a chance more than one instance of the Object owning the
> native methods would be created IF there would be need to sniff at
> several network interfaces simultaneously; in which case there would
> be a single instance of the clas
On Feb 13, 2014, at 1:24 PM, "Daniel H. Bahr" wrote:
> For some reason, as I said earlier, if the SIGSEGV is not connected to
> the bailout nothing queer happens,
Even if you leave SIGQUIT and SIGTERM connected?
___
tcpdump-workers mailing list
tcpdu
On Dec 27, 2013, at 3:13 AM, Michal Labedzki wrote:
> I think the best name for this is DLT_BLUETOOTH_LINUX_MONITOR, because
> this is Linux kernelspace, not BlueZ userland.
OK, LINKTYPE_BLUETOOTH_LINUX_MONITOR and DLT_BLUETOOTH_LINUX_MONITOR have been
assigned the value 254.
_
On Feb 14, 2014, at 12:18 PM, Chris Kilgour wrote:
> I'd like to request two LINKTYPE/DLT allocations for RF Bluetooth Captures,
> with the details described here [2].
What is the "nanosecond offset to pcap timestamp"? pcap-ng lets you specify
the resolution of time stamps, and even pcap let
On Feb 14, 2014, at 4:46 PM, Guy Harris wrote:
> Translating them into the style in the pages under
> http://www.tcpdump.org/linktypes would be helpful. It avoids worrying about
> C/C-derived-language data structure names - or anything *else* about C and
> languages derived f
On Feb 15, 2014, at 1:24 PM, Luigi Rizzo wrote:
> At runtime, netmap only uses open(), ioctl(), mmap() and poll().
...and nm_dispatch(). Is that an inline function defined in the headers?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdum
On Feb 15, 2014, at 12:17 PM, Luigi Rizzo wrote:
> + p->linktype = DLT_EN10MB;
So this either
1) only works on Ethernet devices and devices that supply Ethernet
headers
or
2) generates Ethernet headers that replace the native link-layer
headers for devices that don't su
On Feb 15, 2014, at 1:44 PM, Michael Richardson wrote:
> where do those headers come from? Would it make sense to just include
> those headers with libpcap? That way netmap would always be available.
There's "netmap", which is available only if the kernel includes netmap
support; as long as
On Feb 15, 2014, at 1:21 PM, Michael Richardson wrote:
> The ESP tests are failing because you haven't got libssl-dev.
Yes - some tests fail if the full set of support libraries weren't available
when tcpdump was built.
Perhaps we want to suppress some tests if we don't have the appropriate
On Feb 16, 2014, at 2:03 PM, Chris Kilgour wrote:
> I have established the following two documents that I can confirm will not be
> changed in any technically-significant way. There may be editorial changes
> for typos and the like. And, if there are any further libpcap-related
> technical
On Feb 14, 2014, at 7:41 PM, Chris Kilgour wrote:
> The motivation was classic pcap. I was up on pcap-ng, but did not realize
> the pcap format has an updated variant with higher-precision timestamps.
Yup. Use 0xa1b23c4d, rather than 0xa1b2c3d4, as the magic number, as per
http://ww
On Feb 16, 2014, at 10:58 AM, François-Xavier Le Bail
wrote:
>> From: Guy Harris
>
>> On Feb 15, 2014, at 1:21 PM, Michael Richardson wrote:
>>
>>> The ESP tests are failing because you haven't got libssl-dev.
>>
>> Yes - some tests fa
On Feb 16, 2014, at 5:02 PM, Chris Kilgour wrote:
> Sure, I will keep hosting these pages.
OK, I've assigned:
LINKTYPE_BLUETOOTH_BREDR_BB/DLT_BLUETOOTH_BREDR_BB - 255
LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR/DLT_BLUETOOTH_LE_LL_WITH_PHDR - 256
and will update the Link-Layer Header Types page soon.
On Feb 16, 2014, at 2:03 PM, Chris Kilgour wrote:
> There may be editorial changes for typos and the like.
(Speaking of typos, it's "multi-octet", not "multi-octect".)
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.s
On Feb 14, 2014, at 7:41 PM, Chris Kilgour wrote:
> It seems some folks choose little-endian for multi-byte fields and others
> choose network/big-endian. It there a preference here? Is it acceptable to
> define these fields as having the same endianness as the pcap file header (or
> pcap-n
On Feb 16, 2014, at 6:08 PM, Guy Harris wrote:
> On Feb 14, 2014, at 7:41 PM, Chris Kilgour wrote:
>
>> It seems some folks choose little-endian for multi-byte fields and others
>> choose network/big-endian. It there a preference here? Is it acceptable to
>> defin
On Jan 1, 2014, at 5:29 AM, Simon Berg wrote:
> I've written some capturing tools and a basic Wireshark dissector for
> the PROFIBUS protocol. Since it's delivered directly over a RS485-link,
> it needs a separate link-type. Since I haven't been able to find a
> suitable type among the existing
On Feb 21, 2014, at 2:20 AM, Simon Berg wrote:
> Given a valid octet-stream, all the data going over the wire would be
> part of a packet.
OK, {LINKTYPE,DLT}_PROFIBUS_DL (_DL to emphasize that this is at the data link
layer - if somebody wants, in the future, to provide something less than th
On Feb 15, 2014, at 2:10 PM, Luigi Rizzo wrote:
> Netmap works at least on any interface visible to the OS
> (in native or emulated mode, the latter with some limitations
> e.g not when the interface is bound to a switch),
So if I want to capture on eth0 in netmap mode, what interface name do I
On Feb 15, 2014, at 2:10 PM, Luigi Rizzo wrote:
> Netmap works at least on any interface visible to the OS
> (in native or emulated mode, the latter with some limitations
> e.g not when the interface is bound to a switch),
> but ports of VALE switches and netmap pipes are dynamically created
> s
On Feb 27, 2014, at 12:57 PM, Luigi Rizzo wrote:
> this can be used to plumb things together.
If you want to plumb things together, do you need libpcap?
> Say you want to interconnect two VMs,
Why would I use libpcap for that?
> or a traffic generator and a firewall/ids/monitor
> that you wa
On Feb 27, 2014, at 1:16 PM, Luigi Rizzo wrote:
> On Thu, Feb 27, 2014 at 1:05 PM, Guy Harris wrote:
>
>> On Feb 27, 2014, at 12:57 PM, Luigi Rizzo wrote:
>>
>>> this can be used to plumb things together.
>>
>> If you want to plumb things together, do
On Mar 4, 2014, at 5:43 AM, François-Xavier Le Bail wrote:
> Is it not better to add const in the propotype ?
In what cases, if any, are parameters that are const (rather than non-const
parameters that point to a const object) useful?
C is pass-by-value, so it's not as if the caller will see
On Mar 11, 2014, at 11:40 AM, Gisle Vanem wrote:
> Applying this patch fixes it though:
Checked into the trunk and pushed.
> Time for an INET6 aware util.c print-function for these cases?
ip6addr_string() is a macro wrapper for getname6().
getname6() uses both gethostbyaddr() and inet_ntop()
On Mar 15, 2014, at 12:02 PM, Michael Richardson wrote:
> I guess that this means that we also now have testing against bigendian
> systems. thank you wireshark guys!
As long as it's doing "make check" for tcpdump.
Gerald, is it doing that?
___
tcpd
On Mar 15, 2014, at 12:02 PM, Michael Richardson wrote:
> I guess that this means that we also now have testing against bigendian
> systems.
Big-endian systems *that require alignment*, so it's even better.
___
tcpdump-workers mailing list
tcpdump-wor
On Mar 21, 2014, at 11:59 PM, Denis Ovsienko wrote:
> 22.03.2014, 09:33, "buildbot-no-re...@wireshark.org"
> :
>> The Buildbot has detected a new failure on builder Solaris-10-SPARC while
>> building tcpdump+libpcap.
>> Full details are available at:
>> http://buildbot.wireshark.org/tcpdump/b
On Mar 27, 2014, at 1:50 PM, John Farnsworth
wrote:
>> If your application is expecting a low rate of packet delivery and needs to
>> see packets as soon as they arrive, it should simply call
>> pcap_set_immediate_mode() if it is available, regardless of what operating
>> system it's running
On Mar 27, 2014, at 3:15 PM, Guy Harris wrote:
> On Mar 27, 2014, at 1:50 PM, John Farnsworth
> wrote:
>
>> However, I don't see a method to place logic into code to invoke
>> pcap_set_immediate_mode only if it exists, as I can't trust it to exist,
>>
On Mar 27, 2014, at 3:27 PM, Guy Harris wrote:
> A third alternative
A *fourth* alternative, *if* your application can handle a delay between packet
arrival and delivery of up to 1 millisecond, would be to use a timeout value of
1 in pcap_open_live() (or pcap_set_timeout(), if you'
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
On Apr 12, 2014, at 1:17 AM, Francois-Xavier Le Bail
wrote:
> are there update problems with the tcpdump & libpcap git repos ?
>
> Many new branches and bad Travis runs.
Which new branches, and...
> See the attachments ...
...which attachments? (I don't know whether tcpdump-workers always
On Apr 12, 2014, at 1:48 AM, Francois-Xavier Le Bail
wrote:
> the images are here :
> https://gist.github.com/fxlb/10525029
Yes, those branches are branches that exist in the bpf.tcpdump.org
repositories; I guess pushing from there to GitHub causes the GitHub repository
to have them as well
On Apr 12, 2014, at 5:04 AM, Francois-Xavier Le Bail
wrote:
> 1) Are the branches marked "merged into master" (tcpdump: bare and origin ;
> libpcap : bare and origin) still useful? Otherwise, they could be deleted.
Michael? What are those branches for?
> 2) For all branches, first question
On Apr 15, 2014, at 5:37 AM, "Gisle Vanem" wrote:
> Here are some errors in lost parenthesis errors I've found when building using
> MSVC:
Fixed in 0516a28d2668e23776213960ad19631c4e5a2486.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdum
On Apr 18, 2014, at 5:40 AM, Philip Rosenberg-Watt
wrote:
> I apologize if this is a duplicate message. I sent a request on Monday but
> I have not received a response, so I'm trying again, this time as a member
> of the list.
I think non-member messages need to be moderated.
> I also did not
On Apr 18, 2014, at 5:18 PM, somebody who apparently harvested the e-mail
address "g...@alum.mit.edu" from somewhere wrote:
>
>
> ___
> tcpdump-workers mailing list
> tcpdump-workers@lists.tcpdump.org
> https://lists.sandelman.ca/mailman/listinfo/tcp
On Apr 21, 2014, at 6:38 AM, Philip Rosenberg-Watt
wrote:
> The frames as captured do not look like they've passed through the receive
> function. Here's an example preamble as captured:
>
> D5 55 55 3C 02 44
>
> As you can see, The first two bytes of the preamble have been stripped
> accordi
On Apr 21, 2014, at 3:24 PM, Philip Rosenberg-Watt
wrote:
> On 4/21/14 15:58 , "Guy Harris" wrote:
>
>> OK, so frames for LINKTYPE_ETHERNET_P2MP, or whatever we end up calling
>> it, are:
>>
>> the last 6 octets of the modified preamble as spec
On Apr 22, 2014, at 11:12 AM, Philip Rosenberg-Watt
wrote:
> I'm fine with LINKTYPE_EPON. You're right that the P2MP is implied in the PON
> and of course the Ethernet in the E.
OK, I've assigned 259 as LINKTYPE_EPON/DLT_EPON.
___
tcpdump-workers ma
(Resending to the list.)
On Apr 22, 2014, at 1:28 PM, Philip Rosenberg-Watt
wrote:
> Great! I just submitted my Wireshark dissector with the appropriate
> LINKTYPE.
Hmm.
That dissector does
/* Start_of_Packet delimiter (/S/) can either happen in byte 1 or byte 2,
* making the captured pre
On Apr 23, 2014, at 3:46 AM, Denis Ovsienko wrote:
> Updating these headers to use uint_XX_t instead of u_intXX_t fixes respective
> detection and the NFLOG test case in particular but it seems tcpdump should
> tolerate the u_intXX_t types from libpcap for indefinitely longer time as
> there
On Apr 23, 2014, at 10:24 AM, Guy Harris wrote:
> I made the change because a 64-bit build on Solaris 8 had to define u_int64_t
> but defined it as "unsigned long long int", which collided with the
> "%l[doux]" that was used as the print format.
>
> Probab
On Apr 23, 2014, at 6:58 AM, Philip Rosenberg-Watt
wrote:
> I sent this to the list -- twice -- but it never showed up, so I'll just
> resend it to you. I don't know what's going on.
Moderation? Michael?
> I only put in the first "if" clause because some PON sniffer manufacturers
> may inter
On Apr 22, 2014, at 2:29 PM, Guy Harris wrote:
> In addition, the code *still* has a preference to indicate whether the octet
> preceding the mode/LLID is just 0x55 or an encryption enabled/key ID field.
> Either
>
> 1) there should be *two* LINKTYPE_ values - LINKTYPE
On Apr 23, 2014, at 9:02 PM, Guy Harris wrote:
> So is there any technical reason *not* to dissect the frame by:
>
> if that octet doesn't have the upper 6 bits as 010101, report it as an
> error;
>
> if that octet is 0x55, show it as a preamble octet, an
On Apr 24, 2014, at 6:13 AM, Philip Rosenberg-Watt
wrote:
> I thought about that solution, and it's probably the best. The only thing
> you lose is the positive confirmation that the information is *not*
> encrypted,
You could show that octet as a preamble octet *and* show the 0x02 bit, so it'
On Apr 24, 2014, at 6:31 AM, Philip Rosenberg-Watt
wrote:
> Then how are we to determine if the capture is 1G or 10G mode? Do we
> simply exclude the possibility of XX being 010101 for the MPCP LSB? Or
> are we back to a preference, but to select 1G vs 10G mode? Or maybe a
> LINKTYPE_EPON_1
On Apr 8, 2011, at 7:51 PM, Darren Reed wrote:
> Printing PPI packets with tcpdump does not turn out
> to be that hard.
>
> My simple tests have produced the output as below.
Your simple tests were with invalid PPI files; as the PPI spec:
http://www.cacetech.com/documents/PPI%20Header
On May 3, 2014, at 11:55 AM, Michael Richardson wrote:
> Yes. My notion was to rid tcpdump.c of all code not related to option
> parsing, and then introduce a pktdump.c interface that that could start
> fresh in the short-option parsing space. Could toggle on $0/argv[0].
Unless pktdump goes
On May 8, 2014, at 9:07 AM, Dmitry wrote:
> Can I expect any reply (better positive :)) regarding my question?
You can't expect a reply until people see your message. :-)
Your original message never arrived in my mailbox, and may never have made it
to the list (moderation?), so I didn't see a
On May 9, 2014, at 4:11 AM, Dmitry wrote:
...
> ---
> 10 1Size of subpacket data.
> ---
> 11 NData bytes.
> ---
On Sep 10, 2012, at 10:50 AM, Guy Harris wrote:
>
> On Sep 10, 2012, at 3:41 AM, "David Laight" wrote:
>
>>>> What about the other OS - eg all the BSDs?
>>>> I had a vague idea that BPF was supposed to be reasonable portable.
>>>
>>
On May 27, 2014, at 8:52 PM, Dmitry wrote:
> 28.05.2014 3:24, Guy Harris пишет:
>
>> So are you saying that the packet data, starting with the Trace Data Block
>> Type byte, is in the format specified in some part of HPM.2?
>
> Correct. It is specified in the Tabl
On Jun 8, 2014, at 10:22 PM, Dmitry wrote:
> 08.06.2014 2:17, Guy Harris пишет:
>
>> OK, so all we would need to say on http://www.tcpdump.org/linktypes.html
>> would be:
>>
>> LINKTYPE_whatever {number}DLT_whateverTrace data
>>
On Jun 15, 2014, at 5:23 AM, Fernando Gont wrote:
> I'm trying to send an IPv6 packet with pcap_inject() on the loopback
> interface of a FreeBSD 9.2 system.
>
> What I write with pcap_inect() is the IPv6 packet, preceded with the
> 4-byte AF header (which I set to PF_INET6 (which is 28) in hos
On Jun 15, 2014, at 1:56 PM, Fernando Gont wrote:
> I will certainly file a bug report, and CC you. My understanding is that
> this should be filled in most (if not all) of the BSD variants? (because
> besides the error message one obtains, it seems that in several flavors
> of them, pcap_inject
On Jun 16, 2014, at 1:53 AM, richard lucassen wrote:
> Just a simple question: I have eth1 with some VLAN's. When tcpdumping
> with:
>
> # tcpdump -h
> tcpdump version 3.9.8
> libpcap version 0.9.8
>
> the vlan tags are printed using "tcpdump -ni eth1":
>
> 10:16:12.068967 vlan 65, p 0, IP 10
On Jun 16, 2014, at 2:50 AM, Guy Harris wrote:
> On Jun 15, 2014, at 1:56 PM, Fernando Gont wrote:
>
>> I will certainly file a bug report, and CC you. My understanding is that
>> this should be filled in most (if not all) of the BSD variants? (because
>> besides the e
On Jul 2, 2014, at 2:47 PM, Michael Richardson wrote:
> There has been discussion at the IETF about standardizing PCAPNG,
> and I was just wondering where we were in actually using it ourselves!
> It's better than I had feared, but worse than I'd hoped.
>
> As far as I can tell, we have support
On Jul 5, 2014, at 1:15 PM, Loganaden Velvindron wrote:
> FreeBSD has designed capsicum which is a sandboxing mechanism.
>
> Please find below a patch against FreeBSD 10 Release:
So this will compile on all versions of FreeBSD, correct?
If not, please update the configure script to test for t
On Jul 5, 2014, at 5:02 PM, Michael Richardson wrote:
> It appears that on Linux there is no way to build libpcap without USB
> support. There is no --disable-usb that I can see in ./configure, and
> it appears that if you don't have the right headers, you just fail.
> (Or did I miss something?
On Jul 5, 2014, at 5:39 PM, Guy Harris wrote:
> On Jul 5, 2014, at 5:02 PM, Michael Richardson wrote:
>
>> It appears that on Linux there is no way to build libpcap without USB
>> support. There is no --disable-usb that I can see in ./configure, and
>> it appears th
On Jul 5, 2014, at 5:02 PM, Michael Richardson wrote:
> Ubuntu 12.04 (which is what Travis runs), can not install both the amd64
> and i386 versions of libusb-dev. We don't attempt to build both in .travis,
> but I have another application that I build for -m32 as well, and it depends
> upon li
On Jul 5, 2014, at 7:21 PM, Guy Harris wrote:
> However, it assumes that, for example, struct usbdevfs_ctrltransfer will
> always be defined, even if doesn't exist. That
> probably needs to be fixed; I'll look at that.
Done. If that header isn't present, the USB
On Jul 6, 2014, at 3:41 AM, Guy Harris wrote:
> On Jul 5, 2014, at 7:21 PM, Guy Harris wrote:
>
>> However, it assumes that, for example, struct usbdevfs_ctrltransfer will
>> always be defined, even if doesn't exist. That
>> probably needs to be fixed; I&#x
On Jul 6, 2014, at 2:25 PM, Michael Richardson wrote:
> Romain Francoise wrote:
>>> is a kernel header; does USB sniffing require
>>> libusb-dev at all?
>
>> Nope. libusb is only required for canusb support.
>
> Ah, that's a bit confusing.
>
> There is a --disable-canusb, I think, so I'll t
On Jul 9, 2014, at 5:14 AM, Loganaden Velvindron wrote:
> On Sat, Jul 05, 2014 at 01:34:15PM -0700, Guy Harris wrote:
>>
>> On Jul 5, 2014, at 1:15 PM, Loganaden Velvindron wrote:
>>
>>> FreeBSD has designed capsicum which is a sandboxing mechanism.
>>>
On Jul 22, 2014, at 1:06 PM, Aravindhan Dhanasekaran wrote:
> Is there a packet level ID support in current tcpdump code? A simple
> non-decreasing integer for every packet (something similar to
> Wireshark) would do.
The trunk and 4.6 branch support the "-#"/"--number" command-line option to
On Jul 21, 2014, at 5:36 PM, Aaron Lehmann wrote:
> I think I understand why this was happening, at least in the context of
> TPACKET_V3. The issue is similar to #335. The kernel closes blocks after
> a certain timeout, handing them over to userspace. This happens whether
> the blocks contain an
On Aug 14, 2014, at 1:34 PM, Fernando Gont wrote:
> While trying to select() on a pcap descriptor in solaris
Which version? Solaris 11 (in which pcap descriptors should refer to BPF
devices), or earlier (in which pcap descriptors should refer to DLPI STREAMS
devices)?
> I found the followin
On Sep 3, 2014, at 12:34 PM, Michael Richardson wrote:
> It seems that we might need more patches to better select Linux memory mapped
> packet choices?
I'd prefer a patch that reduces or the removes the *need* to do so, such as
this patch, which I'm in the process of testing (yes, I already
On Sep 3, 2014, at 4:44 PM, Michael Richardson wrote:
> My logic is that if we have the switch/env-var to force libpcap to use a
> particular method, that permits not only benchmarking, but also isolation of
> bugs easier.
OK, I'd vote for an environment variable, so as not to
1) add a
On Sep 8, 2014, at 8:49 AM, Michael Richardson wrote:
> Since a long time ago, we test to see if the getaddrinfo() function
> is buggy. It appears that if we are cross-compiling, that we always
> forceably fail the test.
>
> But, since 2014-0-25, we don't even include getaddrinfo.c, is that b
On Sep 6, 2014, at 3:35 AM, Joshua Wright wrote:
> I request two DLTs for Z-Wave packet captures based on the ITU-T
> Recommendation G.9959 (http://www.itu.int/rec/T-REC-G.9959).
>
> My packet capture tool has support for three Z-Wave RF profiles
> (sometimes called "channel configurations"):
>
On Sep 10, 2014, at 11:39 AM, Joshua Wright wrote:
> It would be reasonable to anticipate additional characteristics that could
> make their way into a capture file for received traffic, such as RSSI and
> noise levels, antenna selection, etc. For the requested link types, the
> packet will
On Sep 12, 2014, at 4:08 PM, Michael Richardson wrote:
>
> Michal Sekletar wrote:
>> In the future I'd like to see pktdump to implement an architecture
>> which would allow a user to run a packet dissector completely
>> unprivileged. Meaning, that *all* privileged operations are done by a
>> v
On Dec 2, 2013, at 5:50 AM, Anders Broman wrote:
> So it seems libpcap is reporting the availability of HW timestamp when in
> fact it's not available.
Somewhere between Linux 3.0 and Linux 3.6, the ethtool ioctl
ETHTOOL_GET_TS_INFO was introduced; it allows userland to query the kernel
abou
On Oct 8, 2014, at 4:18 PM, Gaurav Kasliwal wrote:
> I am new to tcpdump. I just want to fetch http url from packets on given
> interface.
Do you mean that you only want to fetch packets containing HTTP requests with
URLs, such as HTTP GET requests?
Do you want to see HTTP responses?
Do you
On Oct 20, 2014, at 6:43 AM, Michael Richardson wrote:
> print-x test case:
>
> 16c16
> < IP 127.0.0.1.55920 > 127.0.0.1.80: Flags [P.], seq 1:203, ack 1, win 8192,
> options [nop,nop,TS val 1306300951 ecr 1306300950], length 202
> ---
>> IP 127.0.0.1.55920 > 127.0.0.1.80: Flags [P.], seq 1:20
Some of the other cases where a bug my changes introduced into print-udp.c; I
checked in a fix for that.
The one remaining check failure is with the RADIUS-RFC5176.pcap capture - and,
at least as I read RFC 768, the packets in that capture are, in fact, malformed:
> Length is the length in oc
On Oct 18, 2014, at 4:12 AM, Hei Chan wrote:
> Hi,
> The first 3 packets are corrupted according to wireshark.
What is the exact message Wireshark reports?
Can you send us the pcap file or make it available for downloading?
> As soon as I read the first packet with pcap_next(), my application
On Oct 23, 2014, at 11:29 AM, Michael Richardson wrote:
> On the other hand, we have:
> /*
> * Link-layer header type for the netlink protocol (nlmon devices).
> */
> #define LINKTYPE_NETLINK 253
>
> which suggests that I can capture all netlink messages (which is what I want
> to
On Oct 26, 2014, at 7:55 PM, "Jason Pyeron" wrote:
> When I './tcpdump -r -' I get a:
> reading from file -, link-type PFLOG (OpenBSD pflog file)
> tcpdump: packet printing is not supported for link type PFLOG: use -w
>
> I am using tcpdump 4ac7226 and libpcap 625575f.
>
> Did I miss a config
On Oct 27, 2014, at 6:12 AM, Jason Pyeron wrote:
> On Oct 27, 2014, at 1:47 PM, Guy Harris wrote:
>
>> On Oct 26, 2014, at 7:55 PM, "Jason Pyeron" wrote:
>>
>>> When I './tcpdump -r -' I get a:
>>> reading from file -, link-type PF
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
On Nov 10, 2014, at 2:17 PM, Matthew Schumacher wrote:
> I have an unprovisioned ethernet interface showing some TX packets:
>
> # ifconfig -a eth1
> eth1: flags=4163 mtu 1500
>inet6 fe80::224:e8ff:fe80:9258 prefixlen 64 scopeid 0x20
>ether 00:24:e8:80:92:58 txqueuelen 1000
On Nov 10, 2014, at 2:17 PM, Matthew Schumacher wrote:
> I have an unprovisioned ethernet interface showing some TX packets:
>
> # ifconfig -a eth1
> eth1: flags=4163 mtu 1500
>inet6 fe80::224:e8ff:fe80:9258 prefixlen 64 scopeid 0x20
>ether 00:24:e8:80:92:58 txqueuelen 1000
On Nov 12, 2014, at 3:07 PM, Matthew Schumacher wrote:
> On 11/11/2014 11:35 AM, Guy Harris wrote:
>>> But those aren't showing up with:
>>>
>>> # tcpdump -i eth1 -n -e -Q out
>>
>> What happens with
>>
>> tcpdump -i eth1 -n
On Nov 14, 2014, at 1:17 PM, Steve Bourland wrote:
> I have some programs that suffered terrible performance degradation when
> moving from Ubuntu 12.04 to Ubuntu 14.04.
Are those programs capturing and processing network traffic, are they sending
packets and expecting to receive a response,
On Nov 14, 2014, at 2:08 PM, Steve Bourland wrote:
> On Fri, 14 Nov 2014, Guy Harris wrote:
>
>> On Nov 14, 2014, at 1:17 PM, Steve Bourland wrote:
>>
>>> I have some programs that suffered terrible performance degradation when
>>> moving from Ubuntu 12.
On Nov 21, 2014, at 1:00 AM, Romain Francoise wrote:
> I'm looking for the official patches for CVE-2014-8767, CVE-2014-8768
> and CVE-2014-8769 but they don't seem to be in the Github repository.
Michael, are changes made to the bpf.tcpdump.org repository still getting
pushed to the Github re
On Nov 23, 2014, at 11:16 PM, Michal Sekletar wrote:
> Yes, I spent good couple hours backporting those to older versions we have in
> Fedora 19 and 20.
So did I. :-)
(See branches tcpdump_4.1 through tcpdump_4.6.)
> I started to work on the patches ASAP and after submitting the first one
> a
On Nov 21, 2014, at 2:01 PM, Romain Francoise wrote:
> Ok, the fixes still aren't on master, but now there's a tcpdump-4.7
> branch with the commits I need.
>
> So I apparently need all of these?
>
> 3f5693a 10 days ago Guy Harris Report a too-long unreachable de
On Nov 24, 2014, at 1:04 AM, Romain Francoise wrote:
> On Sun, Nov 23, 2014 at 11:35:21PM -0800, Guy Harris wrote:
>> So did I. :-)
>
>> (See branches tcpdump_4.1 through tcpdump_4.6.)
>
> Ah, great, I need patches for Debian stable, which ships tcpdump 4.3.0.
>
On Nov 24, 2014, at 10:25 AM, Michael Richardson wrote:
> Michal Sekletar wrote:
>
>> I don't agree. Rather what are you hearing is a request that code
>> should appear in master branch on GitHub with reasonable time delay.
>
> So, it happens occasionally that developers' forget to push, and
On Nov 24, 2014, at 1:24 PM, Denis Ovsienko wrote:
> So the problem is to let GitHub do its good things to tcpdump yet to protect
> from the bad ones. To me it seems that for the next few years the best
> balance between survivability and convenience would be in continuing to use
> both GitHu
On Nov 24, 2014, at 7:01 PM, Michael Richardson wrote:
> okay, can we start again.
> I would appreciate some clear data and clear complaints.
>
> This is what I heard:
> a) which is "master", bpf or github?
> b) bpf is unreliable.
> c) there is some issue (please explain more) wit
1901 - 2000 of 2521 matches
Mail list logo
