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 th
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 i
rted in
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
de
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
a
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
https://lists.sandelman.ca/mai
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 po
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
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, that
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 DL
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 ve
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 pr
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 fewe
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 wo
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,
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 inst
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
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
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 =
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
On Jul 29, 2018, at 8:57 AM, Greg Steinbrecher wrote:
> When tcpdump calls pcap_set_tstamp_type, it only checks if the returned
> status is less than 0; if the specific type requested exists but isn't
> supported (e.g. `-j adapter` on a card that only supports adapter_unsynced)
> pcap_set_tsta
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’:
> ./tcpd
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 = "%02d:%02d:
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?
O
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.
>
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
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?
_
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:
> https://github.com/matwey/libopenvizsla/wiki/OpenVizsla-protocol-descript
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
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 alwa
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:
> https://github.com/openvizsla
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
>> people develo
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
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 i
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
https://lists.sand
Just testing - no need to reply.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
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 of
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.
>>&g
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&#x
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 offse
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 what
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
>>>
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 Versi
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
Delimiter)
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
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 form
...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 writi
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
On Jan 8, 2019, at 9:15 AM, wrote:
> Currently, I am extending a Sigfox demodulator
> https://github.com/Jeija/renard-phy.
> I already added a function to export the demodulated frames. During my work,
> I ran into a problem with the Linktype. Sigfox works directly on layer 2 to
> avoid misi
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 hea
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 forma
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
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
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 updated a comment in the pull request for that.
So, in any pre-4.19 kernels, does the directory /sys/class/net/{device}/dsa
exist even if there's no tagging
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/tag_*.c in Linux source for exactly length and offset
> within the Ethernet frame):
Unfortunately, tag_brcm.c, for example, doesn't give *enough* de
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
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
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 o
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, but
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.
...
>
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;
Wi
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:
https://bugs.w
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?
___
tcpdump-
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 (
Commit e150c713a2ea333e9ab173e062b447dd65c9a4ee added some ND_TCHECK_LEN()
calls before doing a memcpy.
Should we have a function
static inline void
get_bytes(netdissect_options *ndo, u_char *dst, const u_char *p, size_t
len)
{
if (!ND_TCHECK_LEN(p, len))
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 p
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 |
> |
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: dhcp_li_id
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 now
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 throug
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:
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 targ
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:
https://tools.ietf.org/html/draf
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
tcpdump-workers@lists.tcpdump.or
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* t
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 types and option
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 now
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 PDUs"
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
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 fir
On May 18, 2019, at 4:33 PM, Damir Franusic wrote:
> No I get now what you you're saying. You think that I should rewrite the
> draft to explain custom options in
> Enhanced Packet Block, rather than using a new DLT ?
No.
I'm suggesting that:
you use EPBs, with new options, for Conten
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 wo
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,
On Jul 21, 2019, at 12:40 PM, Tomasz Moń wrote:
> I would like to request a Link-Layer Header Type for USB 2.0 packets.
It looks as if USB 3.1's packets are different from USB 2.0's packets, so this
would be 2.0-specific.
> The new Link-Layer Header Type is supposed to contain the USB 2.0
> pa
On Jul 21, 2019, at 1:27 PM, Guy Harris wrote:
>
> On Jul 21, 2019, at 1:14 PM, Mikhail Gusarov wrote:
>
>> Now that I think about it, in a very rare case it is possible to not be able
>> to synchronize at all:
>> if a SOF byte is encountered inside the data fra
On Jul 21, 2019, at 2:19 PM, Mikhail Gusarov wrote:
> On 21 Jul 2019, at 23:07, Guy Harris wrote:
>
>> So a "garbage frame" would be any frame that begins with a value other than
>> 0x06, 0x15, 0x18, or 0x01?
>
>> Is there any reason for whatever cap
On Jul 21, 2019, at 9:22 PM, Tomasz Moń wrote:
> On Sun, Jul 21, 2019 at 10:47 PM Guy Harris wrote:
>> It looks as if USB 3.1's packets are different from USB 2.0's packets, so
>> this would be 2.0-specific.
>
> USB 3 operates on different hardware signals. US
So "USB 2.0" really means "USB 2.0", and we could describe this as something
such as
LINKTYPE_USB_2_0XXX DLT_USB_2_0 USB 2.0, 1.1, or 1.0
packet, beginning with a PID, as described by Chapter 8 "Protocol Layer" of the
Universal Serial Bus Specification Revision 2.0.
wit
On Jul 22, 2019, at 11:03 PM, Mikhail Gusarov wrote:
> Looks good for me.
OK, I've assigned 287 for LINKTYPE_Z_WAVE_SERIAL.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
On Jul 22, 2019, at 11:57 PM, Tomasz Moń wrote:
> Yes, this look fine.
OK, I've assigned 288 for LINKTYPE_USB_2_0.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
On Aug 18, 2019, at 11:07 AM, Michael Richardson wrote:
> I think that Perl is now ubiquitous enough on Windows
We already require that Flex and Bison for Windows be installed for a libpcap
build; requiring that Perl for Windows be installed is probably not an
excessive requirement.
If "make
On Aug 18, 2019, at 7:03 PM, Michael Richardson wrote:
> Guy Harris wrote:
>> If "make check" required *only* Perl, not a Bourne-compatible shell,
>> that might also make running "make check" on Windows easier.
>
> That's probably a good enough r
On Aug 18, 2019, at 12:52 PM, Francois-Xavier Le Bail
wrote:
> From my experience, it's not the same to build
> with 1) compiler for arch i386 (e.g. debian packages xxx:i386)
> than with 2) compiler for arch amd64 with -m32 option.
According to the GCC 9.2 manual:
https://gcc.gnu.org/
On Sep 18, 2019, at 3:59 PM, Michael Richardson wrote:
> It seems to be that numbers bigger than 1MB here for a *Section Header Block*
> should be more than enough. If we knew the size of the file (it's not a
> pipe, and it's not coming from a stream de-compressor), then we could set
> another
On Sep 20, 2019, at 2:02 PM, Michael Richardson wrote:
> Guy Harris wrote:
>> Currently, Wireshark's pcapng reading code imposes a block size limit
>> for all blocks:
>
>> enough that * the resulting block size would be less than the previous
>> 16 Mi
On Oct 2, 2019, at 2:16 PM, Mario Rugiero wrote:
> A new `pcap_set_buffer_size1` call is created, taking a `size_t`
> instead of an `int`, allowing for buffers as big as the platform
> allows.
Perhaps pcap_set_buffer_size_ext (Windows-style) would be better - a 1 at the
end 1) is a bit unclear
On Oct 2, 2019, at 6:40 PM, Mario Rugiero wrote:
> El mié., 2 oct. 2019 a las 19:48, Mario Rugiero ()
> escribió:
>> I used '1' because that's what Linux does when advertising newer
>> versions of syscalls.
>> '_ext' does look better, I think I'd go with that.
> On the other hand, numeric versio
On Oct 2, 2019, at 3:48 PM, Mario Rugiero wrote:
>
> El mié., 2 oct. 2019 a las 18:46, Guy Harris () escribió:
>
>> There should probably be an API to get the maximum buffer size as well, for
>> the benefit of 1) programs that want "the biggest buffer they can get&quo
On Oct 3, 2019, at 6:12 PM, Mario Rugiero wrote:
> The 'pcap-linux.c' implementation is plagued by #ifdefs and special
> cases aiming to support kernels as old as the 2.0.x family era.
Heck, it may even support 1.x kernels with SOCK_PACKET support.
> The oldest version supported by upstream is
On Oct 7, 2019, at 10:27 AM, Guy Harris wrote:
> If we were to drop TPACKET_V1 and TPACKET_V2 support, that'd mean we'd be
> dropping 2.x kernels and older 3.x kernels as targets
It looks as if TPACKET_V3 might have first appeared in the 3.2 kernel:
https://www.
While we're discussing dropping support for older OSes:
Do we still need to worry about:
SunOS prior to 4.x NIT?
SunOS 4.x STREAMS NIT?
IRIX?
DEC OSF/1^W^WDigital UNIX^W^WTru64 UNIX?
And do we need to continue supporting being built with WinPcap's packet.dll an
2201 - 2300 of 2521 matches
Mail list logo
