Re: [tcpdump-workers] New link-type for Z-Wave serial interface

On Jul 21, 2019, at 1:14 PM, Mikhail Gusarov wrote: > That's right. Also there might be some garbage frames at the beginning of > capture > (basically, the contents of the current packet up to ACK/NAK/CAN/data). So a "garbage frame" would be any frame that begins with a value other than 0x06,

Re: [tcpdump-workers] New link-type for Z-Wave serial interface

On Jul 21, 2019, at 9:23 AM, Mikhail Gusarov wrote: > I'd like to request a number for Z-Wave serial interface link type. > > The link-level protocol is described in section 5 of > https://www.silabs.com/documents/login/user-guides/INS12350-Serial-API-Host-Appl.-Prg.-Guide.pdf So the packets

Re: [tcpdump-workers] New official link-layer type request

On May 18, 2019, at 5:03 PM, Damir Franusic wrote: > And does wireshark currently support new block types and custom options in > EPBs. I would need to access them in dissector plugin, that's what I'm > worried about. There are three types of blocks: 1) standard blocks - you must

Re: [tcpdump-workers] New official link-layer type request

On May 18, 2019, at 4:26 PM, Damir Franusic wrote: > I chose pcap since it's older and there's a better change for support and I > have previously encountered one agency that actually demanded it. That might be a sufficient reason for pcapng not to be the answer - if there are law enforcement

Re: [tcpdump-workers] New official link-layer type request

On May 18, 2019, at 3:05 PM, Damir Franusic wrote: > I know it's extensible but ELEE is used for different purpose LINKTYPE_ELEE is used for the *same* purpose as pcapng - recording timestamped network events, and metadata for those events and for the capture process, in a file. "Target

Re: [tcpdump-workers] New official link-layer type request

On May 12, 2019, at 1:28 PM, Damir Franusic wrote: > I've tried to be as prompt and as accurate as possible so here is the draft, > I hope you'll appreciate the effort. I agree > that the initial thing I sent was an abomination. I will work on this draft > as the project progresses, but for

Re: [tcpdump-workers] New official link-layer type request

On May 18, 2019, at 3:54 PM, Michael Richardson wrote: > Guy Harris wrote: >> If we *do* use pcapng, that would mean that: > >> 1) Wireshark wouldn't be able to read the lawful intercept information >> in the files until support for new block typ

Re: [tcpdump-workers] New official link-layer type request

On May 11, 2019, at 3:42 PM, Michael Richardson wrote: > Also, it might be that pcapng would actually be a really good container for > your work rather than inventing yet-another-TLV. Are there any law enforcement agencies that *will* accept a pcap file but *won't* accept a pcapng file? *If*

Re: [tcpdump-workers] New official link-layer type request

On May 17, 2019, at 1:50 PM, Damir Franusic wrote: > Can we conclude this and make a nek LINKTYPE_ entry linked to this draft? OK, I've added LINKTYPE_ELEE/DLT_ELEE, with a value of 286. ___ tcpdump-workers mailing list

Re: [tcpdump-workers] New official link-layer type request

On May 17, 2019, at 1:35 PM, Damir Franusic wrote: > Hmm In wouldn't want to ask for a new group but from all the those groups, > opsawg seems somehow appropriate, or maybe not? Well, there is at least one lawful intercept related I-D from that group:

Re: [tcpdump-workers] New official link-layer type request

On May 17, 2019, at 11:34 AM, Damir Franusic wrote: > I apologize for my previous mail, issues with email client. What I wanted to > ask is whether I should name the draft like this: > > draft-dfranusic-tsvwg-elee-00 See https://www.ietf.org/standards/ids/guidelines/#7 If you're

Re: [tcpdump-workers] New official link-layer type request

On May 12, 2019, at 2:33 PM, Damir Franusic wrote: > You know a lot about this RFC process than I do. A small amount, maybe, but definitely not a lot. What I know I found out by doing a Web search for internet-draft process and reading pages on IETF Web sites. See, for example:

Re: [tcpdump-workers] New official link-layer type request

On May 12, 2019, at 1:48 PM, Damir Franusic wrote: > That would be great thanks. That's all I ever wanted really, but now I > understand the relevance of having a proper I-D. It will also be useful for documenting the protocol when run over SCTP. Are you planning on running the protocol

Re: [tcpdump-workers] New official link-layer type request

On May 12, 2019, at 1:28 PM, Damir Franusic wrote: > I've tried to be as prompt and as accurate as possible so here is the draft, > I hope you'll appreciate the effort. I agree > that the initial thing I sent was an abomination. I will work on this draft > as the project progresses, but for

Re: [tcpdump-workers] New official link-layer type request

On May 11, 2019, at 7:26 AM, Damir Franusic wrote: > *Example tshark output for IRI:* ... > ELEE Protocol >Protocol version: 1 >PDU type: Target PDU (1) >Source node: elee.ppd.node_1 >Destination node: . >Target PDU >Lawful interception identifier:

Re: [tcpdump-workers] New official link-layer type request

On May 11, 2019, at 1:39 PM, Damir Franusic wrote: > Like I sad, I don't have the complete documentation ready, When you have the complete documentation ready, let us know. > but this is the general format: > > +-+ > | Version | > |

Re: [tcpdump-workers] New official link-layer type request

On May 11, 2019, at 2:51 PM, Damir Franusic wrote: > PDU types are extendable and there might be more of them in the future. I > wanted to make it like this so adding new types would not present a big > issue. I can define the two PDU types used at present moment but maybe it > would be more

Re: [tcpdump-workers] Link-layer header type for unix domain sockets (UDS)

On Mar 24, 2019, at 3:14 AM, František Kučera wrote: > Dne 23. 03. 19 v 21:04 Guy Harris napsal(a): >> On Mar 23, 2019, at 12:50 PM, František Kučera >> wrote: >> >>> There is no MAC or IP address, but there are other useful metadata: socket >>> path (

Re: [tcpdump-workers] Link-layer header type for unix domain sockets (UDS)

On Mar 23, 2019, at 12:50 PM, František Kučera wrote: > There is no MAC or IP address, but there are other useful metadata: socket > path (might be also abstract), direction, UID, GID, PID... Stream, datagram, or sequenced-packet sockets? ___

Re: [tcpdump-workers] Request for a DLT code for IPMB packet

On Aug 13, 2007, at 11:45 AM, Toeung, Chanthy wrote: >> So presumably the first byte of the packet data will be the slave address, >> followed by the netFn and LUN, followed by the checksum, etc.? > yes. It is correct. No, it's not. The test file in this Wireshark bug:

[tcpdump-workers] What bit order should be used for the pcapng Enhanced Packet Block flags field?

The pcapng spec, as I read it, says that bit 0 of the Enhanced Packet Block flags field is the high-order bit of the word. However, several implementations of pcapng, including those in: Wireshark's pcapng reading code (sorry about that); macOS's libpcap and tcpdump;

Re: [tcpdump-workers] Requesting DLT_* values for Ethernet switches proprietary tagging protocol

On Jan 18, 2019, at 10:24 AM, Florian Fainelli wrote: > In pre-4.19 kernels there was really no way you could reliably tell a > DSA management interface apart from a regular Ethernet device in the > system, even by scanning the network device's relationship through > ifindex etc. ... >

Re: [tcpdump-workers] Requesting DLT_* values for Ethernet switches proprietary tagging protocol

On Jan 18, 2019, at 6:13 AM, Michael Richardson wrote: > Guy, do we want to allocate 16 or 32 values, aligned, so that the > it be can DLT_TAG_BASE + DSA_TAG_xx maps? "Aligned" would mean you want to support DLT_TAG_BASE | DSA_TAG_xx; alignment is necessary to support ORing in the tag type,

Re: [tcpdump-workers] Requesting DLT_* values for Ethernet switches proprietary tagging protocol

On Jan 17, 2019, at 9:16 PM, Florian Fainelli wrote: > On 1/17/2019 8:12 PM, Guy Harris wrote: > >> But if /sys/class/net/{device}/dsa doesn't exist in pre-4.19 kernels, how >> can you determine, from userland, whether a device is a DSA management-port >> NIC or not

Re: [tcpdump-workers] Requesting DLT_* values for Ethernet switches proprietary tagging protocol

On Jan 17, 2019, at 8:22 PM, Florian Fainelli wrote: > On 1/17/2019 6:56 PM, Guy Harris wrote: >> On Jan 17, 2019, at 2:39 PM, Florian Fainelli wrote: >> >>> DSA currently supports the following tagging protocols (details can be >>> found under net/dsa/ta

Re: [tcpdump-workers] Requesting DLT_* values for Ethernet switches proprietary tagging protocol

On Jan 17, 2019, at 7:49 PM, Florian Fainelli wrote: > Le 1/17/19 à 6:29 PM, Guy Harris a écrit : >> On Jan 17, 2019, at 6:01 PM, Florian Fainelli wrote: >> >>> Correct. The other ports are exposed as regular Ethernet network devices. >> >> OK, I've u

Re: [tcpdump-workers] Requesting DLT_* values for Ethernet switches proprietary tagging protocol

On Jan 17, 2019, at 4:56 PM, Florian Fainelli wrote: > These Ethernet adapters can be regular/normal Ethernet adapters, e.g: > e1000e/igb/ixgbe on a PC connected to an Ethernet switch via GMII (for > data path), and controlled by that PC through GPIO/SPI/I2C/MDIO for > instance. If the switch is

Re: [tcpdump-workers] Requesting DLT_* values for Ethernet switches proprietary tagging protocol

On Jan 17, 2019, at 2:39 PM, Florian Fainelli wrote: > A number of Ethernet switches from Broadcom, Marvell, Microchip, > Qualcomm, Lantiq/Intel, etc. utilize proprietary tags that are processed > by these switches in-line with the Ethernet frame being sent/received. > > These tags are inserted

Re: [tcpdump-workers] Add Sigfox support to libpcap

On Jan 10, 2019, at 10:17 AM, Jeija wrote: >> 1) Would the link-layer header include any radio metadata? For 802.11, >> there are various forms of radio metadata headers, such as the radiotap >> header: >> >> http://www.radiotap.org >> >> If so, what would the

Re: [tcpdump-workers] Add Sigfox support to libpcap

On Jan 8, 2019, at 11:20 AM, wrote: > A protocol specification can be found here > https://github.com/Jeija/renard-spec/releases OK, so: 1) Would the link-layer header include any radio metadata? For 802.11, there are various forms of radio metadata headers, such as the radiotap

Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.

On Dec 29, 2018, at 4:50 AM, Dave Barach (dbarach) wrote: > The same packet - with [traced] metadata changes - will appear multiple times > as the packet traverses the vpp forwarding graph. The description of the format should probably warn about that, because protocol analyzers that maintain

[tcpdump-workers] If you think you need to wrap your own buffering around pcap_dump() for performance...

...the problem is probably just that the standard buffer size for the I/O library on your platform is too small, and libpcap should increase it. See libpcap issue 792: https://github.com/the-tcpdump-group/libpcap/issues/792 If you've done any buffering of that sort to increase the

Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.

On Nov 28, 2018, at 4:34 AM, Dave Barach (dbarach) wrote: > The buffer index is an opaque 32-bit cookie which allows consumers of these > data to easily filter/track single packets as they traverse the forwarding > graph. Multiple records per packet are normal, and to be expected. In what

Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.

On Nov 28, 2018, at 10:53 AM, Dave Barach (dbarach) wrote: > On Wednesday, November 28, 2018, at 1:40 PM, Guy Harris > wrote: > >> And do 4 (VLIB_NODE_PROTO_HINT_TCP) and 5 (VLIB_NODE_PROTO_HINT_UDP) mean, >> respectively, "the payload is probably a TCP seg

Re: [tcpdump-workers] DLT request for EBHSCR

On Sep 25, 2018, at 6:16 AM, guenter.eberm...@elektrobit.com wrote: > I have updated http://www.elektrobit.com/ebhscr So what is the origin of the scale for the time stamps? For BroadR-Reach, I'm guessing, from The timestamp is taken after the end of the SFD (Start of Frame

Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.

On Nov 28, 2018, at 4:34 AM, Dave Barach (dbarach) wrote: >0 1 2 3 >0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Major Version | Minor

Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.

On Nov 27, 2018, at 3:11 PM, Dave Barach (dbarach) wrote: > On November 27, 2018, at 5:58 PM, Guy Harris wrote: > >> On Nov 27, 2018, at 1:50 PM, Dave Barach (dbarach) wrote: >> >>> The buffer index allows downstream consumers of these data to easily >

Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.

On Nov 27, 2018, at 1:50 PM, Dave Barach (dbarach) wrote: > After thinking about some of your feedback, I decided to move most of the > work back to the vpp side where it probably belonged in the first place. ... > Anyhow, here's what I implemented. Take a look AYC and let me know

Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.

On Nov 27, 2018, at 4:08 AM, Dave Barach (dbarach) wrote: > Opaque[10] is the primary metadata. That's only 40 bytes. Do you mean that > /* Offset within data[] that we are currently processing. >If negative current header points into predata area. */ > i16 current_data; /**< signed

Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.

On Nov 26, 2018, at 12:43 PM, Dave Barach (dbarach) wrote: > On November 26, 2018, at 3:01 PM, Guy Harris wrote: > >> So which of those structures describes the primary metadata? > > vlib_buffer_t. The key fields are flags, current_data, and current_length. So that's:

Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.

On Nov 26, 2018, at 12:43 PM, Dave Barach (dbarach) wrote: > On November 26, 2018, at 3:01 PM, Guy Harris wrote: > >> On Nov 26, 2018, at 6:03 AM, Dave Barach (dbarach) wrote: >> >>> VPP graph dispatch trace record description, in network byte order. >

Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.

On Nov 26, 2018, at 6:03 AM, Dave Barach (dbarach) wrote: > I've built a wireshark dissector for fd.io vpp graph dispatcher pcap traces. > Please see https://fdio-vpp.readthedocs.io/en/latest/ for a description of > the code base / project, etc. > > For development purposes, I borrowed one

[tcpdump-workers] Test message

Just testing - no need to reply. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] DLT request for EBHSCR

On Sep 24, 2018, at 11:22 AM, wrote: > The "Major number specific header" is fixed-length. > It is 8 bytes long. Please update the specification page to note that. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org

Re: [tcpdump-workers] DLT request for EBHSCR

On Sep 24, 2018, at 1:46 AM, guenter.eberm...@elektrobit.com wrote: > Thanks for the suggestions! > I have updated the description accordingly. Please find it here: > http://www.elektrobit.com/ebhscr > > Do you need any more information? Is the "Major number specific header" fixed-length or is

Re: [tcpdump-workers] libpcap usage while reading pcapNG files

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

Re: [tcpdump-workers] Link-layer header type request for libopenvizsla

On Aug 25, 2018, at 1:27 PM, Guy Harris wrote: > On Aug 25, 2018, at 1:10 PM, Matwey V. Kornilov > wrote: > >> Answering your questions and Michael question, the url describes the >> data coming from the hardware as is. Its format is defined by the >> peop

Re: [tcpdump-workers] Link-layer header type request for libopenvizsla

On Aug 25, 2018, at 1:10 PM, Matwey V. Kornilov wrote: > Answering your questions and Michael question, the url describes the > data coming from the hardware as is. Its format is defined by the > people developing FPGA firmware, that is currently not quite active: >

Re: [tcpdump-workers] Link-layer header type request for libopenvizsla

On Aug 22, 2018, at 1:57 AM, Matwey V. Kornilov wrote: > Current OpenVizsla data encapsulation format is described here: > https://github.com/matwey/libopenvizsla/wiki/OpenVizsla-protocol-description Why are: the magic header; the size field; needed? The magic number is

Re: [tcpdump-workers] Link-layer header type request for libopenvizsla

On Aug 22, 2018, at 10:45 AM, Matwey V. Kornilov wrote: > ср, 22 авг. 2018 г. в 20:31, Guy Harris : > >> So what *does* the data field there contain? > > The data is the captured USB packet starting from PID field. As specified by: Chapter 8 "Protoco

Re: [tcpdump-workers] Link-layer header type request for libopenvizsla

On Aug 22, 2018, at 1:57 AM, Matwey V. Kornilov wrote: > Unfortunately, data coming from OpenVizsla doesn't fit to any existing > USB link layers headers. > Current OpenVizsla data encapsulation format is described here: >

Re: [tcpdump-workers] Should the tcpdump tests be run with TZ=GMT0, or should the AFS printer print time stamps in UTC?

On Aug 12, 2018, at 7:06 AM, Francois-Xavier Le Bail wrote: > Should we add the "Z" suffix (for UTC) ? > strftime(time_buf, sizeof (time_buf), "%Y-%m-%dT%H:%M:%SZ", tm); Should we do so in ts_date_hmsfrac_print() as well, if time_flag isn't LOCAL_TIME?

Re: [tcpdump-workers] DLT request for EBHSCR

On Aug 8, 2018, at 8:23 AM, Michael Richardson wrote: > wrote: >> After the header comes a captured frame-payload. Its content depends on the >> major number in the header. > >> Do you need any more information? > > it would be great to point to a web site for this info. ...especially if the

Re: [tcpdump-workers] Should the tcpdump tests be run with TZ=GMT0, or should the AFS printer print time stamps in UTC?

On Aug 3, 2018, at 6:44 PM, Michael Richardson wrote: > Guy Harris wrote: >> Currently, the tcpdump tests for AFS fail if you're not in the time >> zone where the .out files were generated, because AFS time stamps are >> printed as local time rather than as UTC. > >

[tcpdump-workers] Should the tcpdump tests be run with TZ=GMT0, or should the AFS printer print time stamps in UTC?

Currently, the tcpdump tests for AFS fail if you're not in the time zone where the .out files were generated, because AFS time stamps are printed as local time rather than as UTC. Should we run the tcpdump tests with TZ=GMT0 (at least on UN*X), so that all time stamps are interpreted as UTC?

Re: [tcpdump-workers] if anyone wanted to practice fixing compiler warnings in tcpdump...

On Jul 29, 2018, at 5:48 AM, Denis Ovsienko wrote: > ./util-print.c: In function ‘ts_format.isra.0’: > ./util-print.c:265:27: warning: ‘%06u’ directive output may be truncated > writing between 6 and 10 bytes into a region of size between 5 and 12 > [-Wformat-truncation=] > format =

Re: [tcpdump-workers] if anyone wanted to practice fixing compiler warnings in tcpdump...

On Jul 29, 2018, at 5:48 AM, Denis Ovsienko wrote: > Building (configure+gcc) tcpdump master branch with libpcap 0.6.1 yields the > following compiler warnings, some of which are as easy as decorating a > variable declaration with #ifdef: > > ./tcpdump.c: In function ‘open_interface’: >

Re: [tcpdump-workers] Update of XRA header spec

On Jul 27, 2018, at 3:51 AM, Bruno Verstuyft wrote: > I was wondering what the procedures are for updating specifications for a > certain link type? If the layout of the header is specified, in whole or in part, by a page on tcpdump.org's Web site, i.e. one of the linktypes/LINKTYPE_XXX.html

Re: [tcpdump-workers] Endianness issue with selecting non-fragmented packets

On Jul 27, 2018, at 11:21 AM, Richard Clayton wrote: > I am running tcpdump under FreeBSD 11 on an AMD64. > > I have a file containing UDP packets and IP fragments. > > This command (the filter corresponds to the information on the man > page): > >tcpdump -r file.pcap "(ip[6:2] & 0x1FFF =

Re: [tcpdump-workers] corrupted frame on kernel ring mac offset

On Jul 24, 2018, at 9:05 AM, Joseph Freemaker wrote: > Running Centos 7.3.1611 and libpcap 1.8.1. > Received the error message: corrupted frame on kernel ring mac offset 21061 + > caplen 1414873360 > frame len 262144 > Is there a fix or suggested work around for this issue? There isn't even a

Re: [tcpdump-workers] Metamako DLT Request

On Jul 25, 2018, at 1:47 AM, David Mirabito wrote: > I have attached a more detailed description as a text file (lest email mangle > the ASCII-art), but in short, a packet would look on the wire like: > > * SOF > * Destination address > * Source Address > * EtherType/Length > * Payload > * FCS

Re: [tcpdump-workers] PCAP_ERROR/PCAP_ERROR_BREAK or -1/-2?

On Jul 25, 2018, at 12:57 AM, Denis Ovsienko wrote: > Roughly a half of the libpcap man pages text uses the values -1 and -2 to > discuss the return value of particular libpcap functions, the other half uses > PCAP_ERROR and PCAP_ERROR_BREAK. > > Is there a good reason to keep it this way

Re: [tcpdump-workers] Metamako DLT Request

On Jul 23, 2018, at 6:36 PM, David Mirabito wrote: > We'd like to request a new DLT_ value for Metamako's packet capture trailer > that is generated by our MetaWatch network application. > > https://www.metamako.com/applications/metawatch-app.html > > It is a variable length data trailer,

Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

On Jul 23, 2018, at 1:04 PM, Jan Stary wrote: > From both a sysadmin and user perspective, I find the GNU autotools > amd CMake a major annoyance. Would you please consider doing what e.g. > http://mandoc.bsd.lv/cgi-bin/cvsweb/configure does? What advantage would it give us that would make it

Re: [tcpdump-workers] About LINKTYPE_LINUX_SLL / LINKTYPE_LINUX_SLL2

On Jul 13, 2018, at 10:00 AM, Francois-Xavier Le Bail wrote: > In http://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html and > http://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL2.html, there is: > > "If there are more than 8 bytes, only the first 8 bytes are present, and if > there are

Re: [tcpdump-workers] [RFC TCPDUMP PATCH 2/2] Add sll_ifindex into sll_header + use it to print ifname

On Jul 12, 2018, at 11:33 AM, Petr Vorel wrote: > +#ifdef PCAP_SUPPORT_SLL_V2 > + char ifname[IF_NAMESIZE]; > + if (if_indextoname(EXTRACT_BE_U_6(sllp->sll_ifindex), ifname)) > + ND_PRINT("IFNAME %s ", ifname); > +#endif What happens if you capture traffic on machine A and

Re: [tcpdump-workers] [RFC TCPDUMP PATCH 0/2] LINKTYPE_LINUX_SLL2 implementation

On Jul 12, 2018, at 11:33 AM, Petr Vorel wrote: > Main problem is that libpcap supports only one from LINKTYPE_LINUX_SLL > and LINKTYPE_LINUX_SLL2 Not in the version in the libpcap Git repository; both are supported. > Tests (make check) are broken as the output is different [2]. Not in the

Re: [tcpdump-workers] [RFC LIBPCAP PATCH 0/1] LINKTYPE_LINUX_SLL2 implementation

On Jul 12, 2018, at 11:02 AM, Petr Vorel wrote: > Unfortunately I haven't found a way how to coexist in runtime library > both LINKTYPE_LINUX_SLL and LINKTYPE_LINUX_SLL2, See libpcap commit 8cff296dc7c321c76933359d586dbde5b580ce8c, which adds DLT_LINUX_SLL2/LINKTYPE_LINUX_SLL2 support. Both

Re: [tcpdump-workers] Packet capture of SSL traffic

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 running tcpdump into a network on which SSL traffic is being sent, in a fashion that allows it to see that traffic (bearing in mind, for example,

Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

Note, by the way, that, for memory-mapped captures, the Linux kernel appears, in tpacket_rcv(), to reserve 16 octets of extra space, which is exactly enough to insert a DLT_LINUX_SLL header, but not enough for a DLT_LINUX_SLL2 header (and wouldn't even be enough if we *didn't* pad it to put the

Re: [tcpdump-workers] Update configure for libpcap

On Jul 11, 2018, at 1:32 PM, Ali Abdulkadir wrote: > Nope. Although it wouldn't be super helpful if they were to remove/update the > ANSI compiler test. That would make libpcap at least *compile* on windows > with the autotools. I think tcpdump's configure script removed that test at > some

Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

On Jul 11, 2018, at 1:14 PM, Denis Ovsienko wrote: > Could the 4-octet field (ifindex) be at the beginning? Yes, but the padding would still be necessary. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org

Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

Currently https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL2.html has a 2-octet field followed immediately by a 4-octet field. This means the 4-octet field isn't aligned on a 4-octet boundary; I'm going to update the LINKTYPE_LINUX_SLL2 specification to put a 2-byte reserved field

Re: [tcpdump-workers] Update configure for libpcap

commit a130d564ba9c9e82dd4ec5afd85f20c1701c7a0a Author: Guy Harris Date: Tue Oct 3 13:41:35 2017 -0700 Use a place-holder version in configure.ac, so it doesn't have to be updated. And add a comment explaining why, and what we'd have to do if we decided to

Re: [tcpdump-workers] Update configure for libpcap

On Jul 11, 2018, at 4:22 AM, Petr Vorel wrote: > Libpcap's configure script is outdated. > Although I'd prefer remove configure from git and ask user to run autoconf > manually (+ update travis and coverity to run it, of course), but maybe you > have > some reason for it (problematic autotools

Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

On Jul 11, 2018, at 7:06 AM, Petr Vorel wrote: > It looks like 1) is impossible the need for both to define > pcap_create_interface(). Currently, the list isn't set in pcap_create(), it's set in pcap_activate(), so it'd be set in pcap_activate_linux(). You would then either 1) have

Re: [tcpdump-workers] about pcap_set_protocol()

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

Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

(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

Re: [tcpdump-workers] Packet capture of SSL traffic

(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

Re: [tcpdump-workers] Test mail - no need to reply

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 whether

[tcpdump-workers] Test mail - no need to reply

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

Re: [tcpdump-workers] getting libpcap out the door

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

Re: [tcpdump-workers] [the-tcpdump-group/tcpdump] Color support: WIP with code+screenshots (#686)

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

Re: [tcpdump-workers] RFC Almost trivial unused-parameter patch (and lots of questions)

On Mar 31, 2018, at 2:12 PM, Guy Harris <g...@alum.mit.edu> wrote: > On Mar 31, 2018, at 10:41 AM, Joerg Mayer <jma...@loplof.de> wrote: > >> - rpcapd/daemon.c:1538:183: warning: unused parameter 'samp_param' could be >> silenced >> by removing it, or by

Re: [tcpdump-workers] RFC Almost trivial unused-parameter patch (and lots of questions)

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

Re: [tcpdump-workers] 4 small patches to libpcap

On Mar 26, 2018, at 11:09 AM, Guy Harris <g...@alum.mit.edu> wrote: > On Mar 26, 2018, at 4:40 AM, Joerg Mayer <jma...@loplof.de> wrote: > >> attache are four tiny patches to current git head of libpcap: >> >> 0001-Fix-warning-from-Wshadow.patch >

Re: [tcpdump-workers] Four more warning fix patches

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

Re: [tcpdump-workers] 4 small patches to libpcap

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

Re: [tcpdump-workers] 4 small patches to libpcap

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

Re: [tcpdump-workers] 4 small patches to libpcap

On Mar 27, 2018, at 3:54 AM, Joerg Mayer <jma...@loplof.de> 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 war

Re: [tcpdump-workers] 4 small patches to libpcap

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

Re: [tcpdump-workers] 4 small patches to libpcap

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. >

Re: [tcpdump-workers] Request for link-layer header type (XRA)

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

Re: [tcpdump-workers] Request for link-layer header type (XRA)

On Jan 19, 2018, at 5:03 AM, Bruno Verstuyft <bruno.verstu...@gmail.com> wrote: > 2018-01-19 10:10 GMT+01:00 Guy Harris <g...@alum.mit.edu>: > >> Is the Burst ID just a sequence of octets? > > For the moment, the Burst ID is a uint64_t. Should this not be not enou

Re: [tcpdump-workers] Request for link-layer header type (XRA)

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

Re: [tcpdump-workers] Request for link-layer header type (XRA)

On Dec 5, 2017, at 4:47 AM, Bruno Verstuyft <bruno.verstu...@gmail.com> wrote: > 2017-12-04 22:21 GMT+01:00 Guy Harris <g...@alum.mit.edu>: > >> On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft <bruno.verstu...@gmail.com> >> wrote: >> >>>

Re: [tcpdump-workers] Request for link-layer header type (XRA)

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

Re: [tcpdump-workers] Link type proposal, IEEE 802.1Qbu Frame Preemption Protocol

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

Re: [tcpdump-workers] Link type proposal, IEEE 802.1Qbu Frame Preemption Protocol

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,

Re: [tcpdump-workers] Request for link-layer header type (XRA)

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

<    1   2   3   4   5   6   7   8   9   10   >