On Aug 31, 2016, at 11:49 AM, Jonathan Brucker
wrote:
> On Wed, Aug 31, 2016 at 6:27 PM, Guy Harris wrote:
>> On Aug 31, 2016, at 11:03 AM, Jonathan Brucker
>> wrote:
>>
>>> RFtap is here to bridge this gap, for all protocols.
>>
>> That
On Sep 4, 2016, at 6:43 AM, Jonathan Brucker wrote:
> I am posting to request a value for DLT_RDS and LINKTYPE_RDS.
>
> Radio Data System (RDS) is a communications protocol standard
> published in 1992 for embedding small amounts of digital information
> in conventional FM radio broadcasts.
>
>
On Sep 14, 2016, at 7:13 AM, Jonathan Brucker wrote:
> Actually, I have a small dilemma regarding the offset words (the last 4
> bytes):
>
> Does it make more sense to define an enum (0..7) instead of ASCII symbols?
Either one would work.
A switch statement switching on the offset word value
On Oct 6, 2016, at 4:53 AM, Gisle Vanem wrote:
> Yang Luo wrote:
>
>> Given that WinDump is kind of "official" example to use libpcap/Npcap API,
>> it's not good that they can't compile.
>
> Why do you say that? IMHO, tcpdump/WinDump at:
> https://github.com/the-tcpdump-group/tcpdump.git
>
>
On Oct 30, 2016, at 9:18 AM, Michael Richardson wrote:
> When building libnetdissect into a virtual switch (uml_netjig), I started to
> get:
> /usr/bin/ld:
> /home/mcr/stuff/x86_64/tcpdump-4.8.1/libnetdissect.a(print-ripng.o):
> relocation R_X86_64_32 against `.rodata' can not be used when ma
On Nov 17, 2016, at 7:29 AM, Zaphod Beeblebrox wrote:
> Fundamental to my problem is filtering the PPP inside L2TP. Making this
> complex, the L2TP speakers I'm dealing with don't deliver at the same
> offsets.
...and libpcap's filter-to-BPF compiler doesn't have a "check for L2TP and, if
you
On Dec 6, 2016, at 10:15 AM, Martin Dubuc wrote:
> I am working on an application that requires to store packets in PCAPNG
> format. My understanding is that there isn't support for saving packets in
> PCAPNG format in the current code base. I have noticed that Apple has
> created an API in its c
still there, has anything happened about releasing Apple's
libpcap changes under the BSD license rather than under the APSL?
> Martin
>
> On Tue, Dec 6, 2016 at 1:32 PM, Guy Harris wrote:
> On Dec 6, 2016, at 10:15 AM, Martin Dubuc wrote:
>
> > I am working on an ap
On Nov 30, 2016, at 4:14 AM, ikuzar RABE wrote:
> I work on Debian 8, with linux version 3.16.0-4-amd64, libpcap.1.8.1,
> gcc-4.9.2
> I write a little program in C langage which reads a pcap file, apply
> filter, and write the result into a new pcap file.
>
> The problem: all filters do not work
On Dec 6, 2016, at 10:12 PM, Tugrul Erdogan wrote:
> There is a pcap file which stores last X seconds of packets. And with each
> X seconds of a period, a new pcap file is created.
>
> I can successfully read the initial pcap file for X seconds with "tail -n+o
> -F | tcpdump -r - -nn".
To quo
On Dec 1, 2016, at 10:34 AM, Scott Deandrea wrote:
> We’ve been working to provide developers with a software packet capture
> solution for USB transfers at Apple. To that end, I have implemented a
> solution which uses BPF and is libpcap compatible but is currently using the
> link type DLT_
On Nov 28, 2016, at 3:39 PM, Sergio Garcia Gutierrez
wrote:
> When i execute this line "sudo tcpdump -vvv dst host 'your IP' & port 80"
> You CANT STOP TCPDUMP using "Ctrl + C".
That's because you made it a background job.
If you type the command
sudo tcpdump -vvv dst host 'your IP' &
On Dec 5, 2016, at 1:18 PM, Martin Dubuc wrote:
> I am working on an application that requires to store packets in PCAPNG
> format. My understanding is that there isn't support for saving packets in
> PCAPNG format in the current code base. I have noticed that Apple has
> created an API in its cu
On Dec 9, 2016, at 1:37 PM, Scott Deandrea wrote:
> The link-layer header format is as follows:
> struct
> {
>// Control information
>uint16_t bcdVersion;// version of this structure
What's the current version? 0, 1, or something else?
>uint8_t headerLength; // length
On Dec 9, 2016, at 1:37 PM, Scott Deandrea wrote:
> The link-layer header format is as follows:
So are multi-byte integral fields in the byte order of the host providing the
packets, always in little-endian order (if, for example, Apple were to go Power
ISA again, they'd be little-endian even
On Dec 9, 2016, at 6:40 PM, Scott Deandrea wrote:
> For the initial release I’m planning to use 0x0100 for the bcdVersion.
So I'm guessing "bcd" implies that either octets or nibbles represent digits;
is that the case?
> tAppleUSBHostPacketFilterRequestType doesn’t exist in public domain at t
On Dec 9, 2016, at 1:37 PM, Scott Deandrea wrote:
>uint32_t deviceLocation;// locationID of the device
So is a locationID something defined by a USB specification, by Apple in a
fashion specific to Darwin, or something else? What is the format of a
locationID?
>uint32_t ioFrameCo
On Dec 11, 2016, at 8:12 AM, Scott Deandrea wrote:
> The bcdVersion field is interpreted as described by the bcdUSB field of the
> standard device descriptor in section 9.6.1:
> The bcdUSB field contains a BCD version number. The value of the bcdUSB field
> is 0xJJMN for version JJ.M.N (JJ – ma
On Dec 11, 2016, at 8:32 AM, Scott Deandrea wrote:
> The deviceLocation is an Apple specific property that describes the bus
> topology to which the device is connected. The most significant byte
> contains the bus number; a unique value given to a host controller and also
> used when generat
On Dec 12, 2016, at 6:53 AM, Martin Dubuc wrote:
> I was testing some of the libpcap API and would like to get some
> clarification on the return value of one of the function. Is pcap_dispatch
> supposed to return the number of packets read/processed?
If it successfully processes any packets, i.
On Dec 12, 2016, at 10:21 AM, Scott Deandrea wrote:
> The data is part of the complete packet regardless if the host is sending or
> receiving data to/from the device.
So the only submit packets with data would be packets sent to control
endpoints, which would contain setup data?
_
On Dec 12, 2016, at 6:11 PM, Scott Deandrea wrote:
> The bus number is 0 based and the port numbers are 1 based.
So if there are fewer than 6 ports in the route, the unused nibbles will be
zero.
> I decided to implement isochronous transfers today and changed the structure
> slightly:
> struc
On Dec 13, 2016, at 8:38 AM, Scott Deandrea wrote:
> The timestamps are in Mach Absolute Time Units
> (https://developer.apple.com/library/content/qa/qa1398/_index.html).
That says
This unit is CPU dependent, so you can't just multiply it by a constant
to get a real world value. Rathe
On Jan 5, 2017, at 8:48 PM, Scott Deandrea wrote:
> The mach absolute time base is different between ARM and x86/x64 though
> developers won’t have access to packet capture on iOS devices (internally the
> packet capture is used on iOS devices). The developers that would be using
> this softw
On Dec 9, 2016, at 1:37 PM, Scott Deandrea wrote:
> The link-layer header format is as follows:
> struct
> {
>// Control information
>uint16_t bcdVersion;// version of this structure
>uint8_t headerLength; // length of this structure
>uint8_t requestType; // t
On Jan 5, 2017, at 8:42 PM, Scott Deandrea wrote:
> The frameNumber is a USB spec defined value that correlates with the
> start-of-frame packets frame number as defined in section 8.4.3
> Start-of-Frame Packets.
So only 11 of the 64 bits are used?
> The ioTimestamp is in the same Mach Absolu
On Jan 5, 2017, at 9:59 PM, Scott Deandrea wrote:
> The ioLength for a submitted request will the the amount of data requested in
> the data stage.
So, for a submitted request on the Default Control Pipe, the ioLength won't be
8 for the setup data, it'll be the maximum amount of data requested
On Jan 5, 2017, at 10:11 PM, Scott Deandrea wrote:
> An interrupt is generated when the frame number rolls over and we use this to
> increment the upper bits so the frame number can grow beyond 11 bits. This
> allows software consuming the frame number not to worry about the frame wrap
> when
On Jan 5, 2017, at 11:22 PM, Scott Deandrea wrote:
> Correct, for a submitted request on the default control pipe is the maximum
> amount of data requested. The ioLength for a completed request of
> non-isochronous pipes will be equal to the amount of data payload transferred
> on the bus. I
On Jan 4, 2017, at 4:19 PM, Scott Deandrea wrote:
> Any update on allocating a DLT value? Perhaps #define DLT_MACOS_USB 266?
So here's a draft of the header format:
http://gharris.users.sonic.net/LINKTYPE_USB_DARWIN.html
It won't look exactly like this, as this doesn't have the www.tc
On Jan 6, 2017, at 10:22 AM, Scott Deandrea wrote:
> That draft looks correct and complete to me.
OK, I've assigned 266 for LINKTYPE_USB_DARWIN/DLT_USB_DARWIN. The changes are
checked into the master branch of libpcap, so it should appear in a future 1.9
release of libpcap (which macOS 10.1
On Dec 12, 2016, at 6:11 PM, Scott Deandrea wrote:
> I decided to implement isochronous transfers today and changed the structure
> slightly:
> struct
> {
>// Control information
>uint32_t frameHeaderLength; // 28
>
>// Frame information
>uint32_t frameLength; // Amount of da
On Jan 11, 2017, at 11:42 PM, Weber René wrote:
> We working at software for industrial cameras which are supported by the
> cameralink standard. We use Wireshark to monitor the control interface. We
> have implemented a solution similar like the u3v dissector and uses link type
> DLT_USER0.
On Jan 13, 2017, at 6:49 AM, Weber René wrote:
> On Jan 11, 2017, at 11:42 PM, Weber René wrote:
>
>>> We working at software for industrial cameras which are supported by the
>>> cameralink standard. We use Wireshark to monitor the control interface. We
>>> have implemented a solution simila
On Jan 16, 2017, at 4:06 AM, Becker (ELZET80) wrote:
> we are currently working on an USB tracer which captures messages from BITBUS
> connected devices.
> BITBUS is based on the SDLC protocol by IBM (see:
> https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control)
Several protocols, includ
On Jan 17, 2017, at 5:25 AM, Becker (ELZET80) wrote:
> I think my request was a bit misleading and wrong formulated. I told you we
> are working on a BITBUS tracer which in reality is a SDLC tracer that can
> trace BITBUS too.
So by "tracer" do you mean that it actually dissects and displays p
On Feb 8, 2017, at 10:38 PM, Erik de Jong wrote:
> I would like to request a link layer header type for encapsulation of LoRa
> packets. It will be used to encapsulate raw packets as logged directly from
> the air. As usage of this link layer header type will be similar to the
> radiotap header,
On Feb 9, 2017, at 10:41 AM, Erik de Jong wrote:
> You are correct, the packets encapsulated by the LoRaTap format will be
> those from the PHYPayload as listed in section 4. This document details the
> LoRaWan protocol which is something that can run on top of the LoRa radio
> phy layer. The LoR
On Feb 9, 2017, at 11:44 AM, Erik de Jong wrote:
> Please see the github link for an updated version with explanation and
> units for each field.
So what does "last packet" mean in "RSSI of last packet" and "Estimation of
last packet SNR"? (BTW, there's a typo - the spec says "Espimation" inst
On Mar 2, 2017, at 11:04 AM, Joerg Mayer wrote:
> Now it fails (i.e. it no longer crashes!) with:
> jmayer@newegg:~/worktmp/libpcap/build(master)$ dumpcap -i
> rpcap://10.122.4.11/wifi0
> Capturing on 'rpcap://10.122.4.11/wifi0'
> dumpcap: Invalid capture filter "(null)" for interface
> 'rpcap:
On Mar 11, 2017, at 3:19 AM, Joerg Mayer wrote:
> Subject: [PATCH] Bunch of build system fixes
>
> Add install target for rpcapd (todo: write manpage)
> Fix out of tree builds for rpcapd (wouldn't find includes in ..)
> File file permissions of rpcapd source
> Fix compiles when HAVE_REMOTE is se
On Mar 14, 2017, at 4:14 AM, Joerg Mayer wrote:
> with the ongoing work on getting rpcap client and server code working in
> libpcap,
> what is missing for libpcap to continue as the "official" successor of
> Winpcap?
The kernel-mode code and whatever user-mode code runs atop it.
> Are there
On Mar 24, 2017, at 12:36 AM, Joerg Mayer wrote:
> From: Joerg Mayer
> Date: Mon, 20 Mar 2017 21:06:34 +0100
> Subject: [PATCH] Make git_version_c.sh look more like gen_version_header.sh
Checked in as 99acf643a848bac8d25b9a35709319dd519efab6.
___
tcpd
On Apr 4, 2017, at 5:02 AM, Selvig, Bjorn wrote:
> I am working on a new header format for radio packet meta information to
> display in Wireshark.
For which particular link-layer protocol is this intended?
___
tcpdump-workers mailing list
tcpdump-wor
On Apr 4, 2017, at 10:53 PM, Selvig, Bjorn wrote:
> This header is for support of TI boards as sniffer adapter (LAUNCHXL boards)
> for low power wireless protocols like BLE, 802.15.4 or TI proprietary
> protocols.
So there are two ways of handling this:
1) a single LINKTYPE_/DLT_ valu
On Apr 5, 2017, at 4:58 AM, Selvig, Bjorn wrote:
> We would like to support this new header also with pcap format. Our tools
> currently supports pcap format only.
>
> Option 1 (single DLT value) sounds a bit simpler. It allows for sniffing of
> more than one protocol at a time even with pcap
On Mar 24, 2017, at 12:17 AM, Udit Chaudhary wrote:
> Can you please help us to decode Hex Dump for LINKTYPE_M3UA
There *is* no link type LINKTYPE_M3UA.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailm
On Apr 7, 2017, at 11:10 AM, Denis Ovsienko wrote:
> tcpdump can decode M3UA if that is what you mean.
It dissects M3UA running atop SCTP; tcpdump dissects either SCTP as a
"link-layer" protocol (LINKTYPE_SCTP/DLT_SCTP = 248) or as a protocol running
atop IPv4/IPv6 (which, obviously, run atop
On Apr 15, 2017, at 7:10 PM, Andrew Lunn wrote:
> Do you think this is a kernel problem, libpcap problem, or an
> application problem?
An application problem. See my response on netdev; the timeout (which is
provided by the kernel's capture mechanism, in most cases) is to make sure
packets do
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
On Apr 11, 2017, at 10:40 AM, Joseph Freemaker
wrote:
> On a 64 bit OS does a 64 bit compiled libpcap provide better performance than
> a 32 bit compiled libpcap?
I don't know whether anybody's measured it on any particular platforms.
A 64-bit libpcap would have bigger pointers and size_t var
On May 2, 2017, at 8:04 AM, chetan loke wrote:
> On Sat, Apr 15, 2017 at 7:41 PM, Guy Harris wrote:
>> On Apr 15, 2017, at 7:10 PM, Andrew Lunn wrote:
>>
>>> Do you think this is a kernel problem, libpcap problem, or an
>>> application problem?
>>
On May 2, 2017, at 10:54 AM, Guy Harris wrote:
> Yes, there's a case where user space wasn't being woken up.
See also this thread from almost 3 years ago, beginning with
http://marc.info/?l=linux-netdev&m=140633612828824&w=2
and this patch thread from a
On May 2, 2017, at 10:16 AM, chetan loke wrote:
> Commit that caused it:
>
> https://github.com/torvalds/linux/commit/41a50d621a321b4c15273cc1b5ed41437f4acdfb
>
> Reverting that change is what we need.
As long as you do *not* revert
https://github.com/torvalds/linux/commit/da413eec72
04:11:18.046715 IP (tos 0x0, ttl 64, id 35811, offset 0, flags [DF], proto TCP
(6), length 48)
192.168.119.11.41249 > 195.115.97.196.80: Flags [S], cksum 0xcc57
(correct), seq 358236700, win 24820, options [nop,nop,sackOK,mss 1460], length 0
06:45:19.021820 IP6 (hlim 64, next-header TCP (6)
On May 24, 2017, at 10:36 AM, Michael Richardson wrote:
> Guy Harris wrote:
>
>> Note that macOS's tcpdump has a -g flag ("g" for "greppable", more
>> greppable output being the purpose of the flag), which puts the IPv4
>> input back on one li
I've checked netmap support into the master branch of libpcap. The configure
script checks for netmap support and compiles pcap-netmap.c iff the header
files for netmap are present, as we do with other modules.
In order to allow capturing with Wireshark from the GUI (Wireshark *can* be
told to
On Jun 6, 2017, at 8:51 PM, Daniel O'Connor
wrote:
> I work for Clipsal (part of Schneider Electric) and have been developing a
> capture program and dissector for the C-Bus protocol -
> https://en.wikipedia.org/wiki/C-Bus_(protocol)
>
> Can we get a link layer header type assigned for this?
On Jun 26, 2017, at 12:45 AM, Zheng, Ruoqin wrote:
> The case is like this, I config my NIC to vlan subnet as:
> #ifconfig
> eth0.100 Link encap:Ethernet HWaddr 00:04:9f:04:b0:04
> inet addr:192.168.255.1 Bcast:192.168.255.255 Mask:255.255.255.0
> UP BROADCAST RUNNING
On Jun 26, 2017, at 5:57 PM, Zheng, Ruoqin wrote:
> Hi Guy
>Thank you for your answer, and here is the output with -d:
>
>root # ping -q -c 50 -I eth0.100 192.168.255.2&
> [2] 1208
> root # tcpdump -d -i eth0 ether broadcastPING 192.168.255.2
> (192.168.255.2) from 192.168.2
On Jun 26, 2017, at 7:35 PM, Daniel O'Connor
wrote:
>> On 7 Jun 2017, at 17:32, Guy Harris wrote:
>>
>> On Jun 6, 2017, at 8:51 PM, Daniel O'Connor
>> wrote:
>>> I work for Clipsal (part of Schneider Electric) and have been developing a
>
On Jul 18, 2017, at 12:44 PM, alice-cyberreboot wrote:
> In our enhancements these flags are available both when reading from an
> existing pcap file and when performing a live capture. The caveats are, this
> currently works solely for the Ethernet link layer (the scope of our project),
So if
On Aug 21, 2017, at 9:43 AM, Stig Bjørlykke wrote:
> The Nordic Semiconductor nRF Sniffer (a Bluetooth Low Energy sniffer
> [1]) uses the attached packet format between the host and a sniffer,
> and the packet EVENT_PACKET is currently dissected in Wireshark in
> packet-nordic_ble.c. A future ve
On Oct 13, 2017, at 1:30 AM, Bruno Verstuyft
wrote:
> at Excentis we are developing a DOCSIS 3.1 RF sniffer (XRA-31). Packets are
> saved in pcap format with an XRA header. This is a pseudo header that
> contains extra information on the sniffed DOCSIS packets, e.g. the MER
> (modulation erro
On Oct 29, 2017, at 12:42 PM, Michael Richardson wrote:
> I kinda prefer the first one, but I have no strong preference.
I'm OK with either one.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listi
On Nov 14, 2017, at 1:35 AM, Bruno Verstuyft wrote:
> thanks a lot. Is there any other action needed from our side to be added to
> the online linktype list (http://www.tcpdump.org/linktypes.html)?
Other than completing the specification at
http://www.xra31.com/xra-header
there's nothi
On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft wrote:
> we put the specification of the XRA header online.
So, presumably:
the payload of a Downstream SC-QAM DOCSIS MAC Frame, OFDM DOCSIS MAC
Frame, or Upstream DOCSIS MAC Frame packet type is a MAC Frame as described by
section 6.2 "MAC
On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft wrote:
> we put the specification of the XRA header online.
It mentions tcpdump in the page header and Wireshark in the page body; it
should probably just talk about pcap and pcapng, as the whole point of the pcap
and pcapng specifications, and the
On Nov 21, 2017, at 6:34 AM, Bruno Verstuyft wrote:
> we updated the XRA header specification with more clarifications.
So:
A "collection of NCP message blocks within a symbol" is a sequence of N-1
3-byte NCP Data Message Blocks followed by a 3-byte NCP CRC Message Block?
A "PLC structure as
On Nov 27, 2017, at 11:40 PM, Nimesh Prajapati
wrote:
> From: Yogesh Prasad
>
> Description
> This patch will correct the sequence of -pie and -shared options.
> When used together, -pie should be provided to the linker before
> -shared. If -pie is provided after -shared, the linker throws
> b
On Nov 30, 2017, at 1:42 AM, Anton Glukhov wrote:
> I've been working for IEEE802.1Qbu Frame Preemption Protocol and now it's
> part of TSN set of protocols. I would like to propose the new link type and
> sent this proposal to tcpdump-workers@lists.tcpdump.org, but unfortunately no
> response
On Nov 29, 2017, at 5:57 AM, Bruno Verstuyft wrote:
> thanks for the remarks. The specification is now updated with more
> clarifications
So "Segment Header Present" is 1 if it's present and 0 if it's absent?
Type 75 is still labeled as "ODMA REQ" rather than "OFDMA REQ". Also, it says
"ODMA
On Nov 30, 2017, at 2:27 AM, Anton Glukhov wrote:
> 1. You are right, I'm not subscribed there. I will fix this problem)
OK, I'm moving the discussion to tcpdump-workers.
> 2. I'd like to have completely separate LinkType number and this is not
> LINKTYPE_ETHERNET, because preamble must be sho
On Dec 1, 2017, at 3:34 AM, Bruno Verstuyft wrote:
>> Type 75 is still labeled as "ODMA REQ" rather than "OFDMA REQ". Also, it
>> says "ODMA REQ (75): as described by section 7.4.8 "REQ Messages" of the
>> DOCSIS 3.1 Physical Layer Specification. This is the "REQ message in MAC"
>> in figure 7-1
On Dec 1, 2017, at 12:56 AM, Anton Glukhov wrote:
> Correct. I think that CRC(or mCRC for preemption) is also important and I
> would like to add it too. So finally we have:
> Preamble with SFD | Mac header | Payload | CRC/mCRC
OK, so I guess the idea is that the payload of this link type is wh
On Dec 2, 2017, at 4:06 AM, Anton Glukhov wrote:
> You are right, “express" packet is exactly the same as “ordinary”. From my
> point of view it’s ok to show express traffic as part of preemption traffic,
> hence I’d like to see Express packets in favour of “ordinary” one. Anyway I
> guess If
On Dec 3, 2017, at 3:19 AM, Anton Glukhov wrote:
> Yes, absolutely.
OK, I've assigned 274 for LINKTYPE_ETHERNET_MPACKET/DLT_ETHERNET_MPACKET.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo
On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft wrote:
> we put the specification of the XRA header online.
The MAC document speaks of "logical" upstream and downstream channels; are
those what the "Downstream Channel ID" and "Upstream Channel ID" TLVs refer to?
To what do the start and stop mini
On Dec 5, 2017, at 4:47 AM, Bruno Verstuyft wrote:
> 2017-12-04 22:21 GMT+01:00 Guy Harris :
>
>> On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft
>> wrote:
>>
>>> we put the specification of the XRA header online.
>>
>> The MAC document speaks of &q
On Jan 4, 2018, at 5:47 AM, Bruno Verstuyft wrote:
> are any more clarifications needed for the XRA header spec?
How is the Symbol ID used for timing calculations?
Is the Burst ID just a sequence of octets?
What does the Burst ID Reference field contain? Another burst ID?
On Jan 19, 2018, at 5:03 AM, Bruno Verstuyft wrote:
> 2018-01-19 10:10 GMT+01:00 Guy Harris :
>
>> Is the Burst ID just a sequence of octets?
>
> For the moment, the Burst ID is a uint64_t. Should this not be not enough
> in future implementations, it can be increased to
On Jan 31, 2018, at 6:07 AM, Bruno Verstuyft wrote:
> can I already commit the dissector code for the XRA header to wireshark, or
> is it best to wait for finalization of the spec details?
At this point, I don't have any further questions; are there any more changes
you intend to make to the sp
On Mar 26, 2018, at 4:40 AM, Joerg Mayer wrote:
> attache are four tiny patches to current git head of libpcap:
>
> 0001-Fix-warning-from-Wshadow.patch
I need to stare at the code some more to figure out *why* it has an
on-the-stack copy of sockmain.
> 0002-Fix-warnnigs-from-Wdocumentation.pa
On Mar 26, 2018, at 11:11 AM, Ali Abdulkadir wrote:
> How about also adding -Wshadow to check_and_add_compiler_option()?
You mean like
check_and_add_compiler_option(-Wshadow)
which is currently at line 1626 of CMakeLists.txt as of commit
64cada32a854ef0b47e865e30be341867653c7f3?
_
On Mar 27, 2018, at 3:54 AM, Joerg Mayer wrote:
> On Mon, Mar 26, 2018 at 11:09:03AM -0700, Guy Harris wrote:
>>> 0004-Add-Wdocumentation-to-development-warnings.patch
>>>
>>> Patch 4 is kind of "unclean" as it still generates warnings in the
>&
On Mar 27, 2018, at 3:58 AM, Joerg Mayer wrote:
> On Tue, Mar 27, 2018 at 12:54:48PM +0200, Joerg Mayer wrote:
>> There is no doxygen code in scanner.l. I followed your advice above and the
>> attached patch fixes the problem.
>
> I should have added that I currently don't have GCC to test but
On Mar 28, 2018, at 1:14 AM, Joerg Mayer wrote:
> Can you please apply 0004-Add-Wdocumentation-to-development-warnings.patch
> from the original mail as well, now that the warnings are taken care of?
Done.
___
tcpdump-workers mailing list
tcpdump-work
On Mar 28, 2018, at 2:46 PM, Joerg Mayer wrote:
> These patches turn on some more warnings (or not) and fixes all warnings that
> come up
>
> Notes:
> - 0001 is not sent (it's the previously sent -Wshadow fix)
Turning that rock over found a lot more underneath; the whole way rpcapd
manages wo
On Mar 26, 2018, at 11:09 AM, Guy Harris wrote:
> On Mar 26, 2018, at 4:40 AM, Joerg Mayer wrote:
>
>> attache are four tiny patches to current git head of libpcap:
>>
>> 0001-Fix-warning-from-Wshadow.patch
>
> I need to stare at the code some more to figure
On Mar 31, 2018, at 10:41 AM, Joerg Mayer wrote:
> attached a patch with the almost trivial fixes for -Wunused-paramter warnings.
Checked in, which changes as needed, as
0a1a0ed3bce9d3b4fd41b1a0b53e948c15dd525b.
___
tcpdump-workers mailing list
tcpdum
On Mar 31, 2018, at 2:12 PM, Guy Harris wrote:
> On Mar 31, 2018, at 10:41 AM, Joerg Mayer wrote:
>
>> - rpcapd/daemon.c:1538:183: warning: unused parameter 'samp_param' could be
>> silenced
>> by removing it, or by removing the #if 0 around "//
On Jun 21, 2018, at 12:28 AM, Ryan Doyle wrote:
> Step2. Expand by adding meaning to XML. The printer could then start to know
> what a is and what it's attributes mean. At this point we could
> start adding color to these.
...
> Step3. Expand further, protocol by protocol adding pri
On Jun 24, 2018, at 10:58 AM, Michael Richardson wrote:
> Michael Richardson wrote:
>> Since we now support building on windows, should we attempt to get
>> appveyor to do regular builds for windows?
https://ci.appveyor.com/project/guyharris/libpcap
https://ci.appveyor.com/proj
On Jun 24, 2018, at 11:40 AM, Michael Richardson wrote:
> Questions:
> 1) should we have some test case or something that checks that the _MAX
> values are identical? Perhaps a compile-time test using #error?
That sounds like a good idea. I've done that in
3367fed4b1ff7341966428e5e596744757
On Jun 24, 2018, at 6:39 PM, Michael Richardson wrote:
> The README.Win32 must be wrong now that we've done all this work...
It's *way* out of date; we're using CMake now, they'd probably want to download
the WinPcap SDK rather than trying to do a WinPcap build-from-source, they'll
need a new
OK, I guess the universe hates "email for life" services, so I'm going to try
giving up on g...@alum.mit.edu for this list.
Testing to see whether my current direct e-mail address now works.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump
On Jul 10, 2018, at 10:08 AM, Guy Harris wrote:
> OK, I guess the universe hates "email for life" services, so I'm going to try
> giving up on g...@alum.mit.edu for this list.
>
> Testing to see whether my current direct e-mail address now works.
Testing to see whe
(Re-sending from my real e-mail address as opposed to my forwarding-for-life
address, as the latter was causing issues and required moderation.)
On Jul 5, 2018, at 11:18 AM, Kaushal Shriyan wrote:
> Is there a way to run tcpdump to do packet capture on SSL traffic?
Yes. Plug the machine runni
(Re-sending, from my real e-mail address rather than my forwarding-for-life
e-mail address, because the latter had issues and required moderation.)
On Jul 10, 2018, at 9:34 AM, Petr Vorel wrote:
> I'm playing with implementing LINKTYPE_LINUX_SLL2 [1] as a part of [3]
> in libpcap and using it i
On Jul 10, 2018, at 1:31 AM, Denis Ovsienko wrote:
> I have been looking at the man page for pcap_set_protocol() for some time.
> The man page explains the function is a Linux-specific extension. Would it be
> better to rename the function to something like pcap_set_linux_protocol()
> before i
2101 - 2200 of 2521 matches
Mail list logo
