--- Begin Message ---
François checked in a change to tcpdump so that, if it's handed a capture file
with a link-layer header type for which it has no dissector, it just dumps the
packet data in hex, rather than failing with an indication that the header type
isn't supported.
However, pcap_comp
--- Begin Message ---
On Jul 9, 2020, at 1:46 PM, Sultan Khan wrote:
> Through discussions with Joakim Anderson (of Nordic) and Mike Ryan (Ubertooth
> developer), and going through several iterations of proposed protocol
> updates, I/we came up with this:
> https://gistcdn.githack.com/sultanqa
--- Begin Message ---
A couple more editorial comments:
In the description of the bits in the Flags field, I'd describe the 0x3000 bits
as "PDU type dependent", and, after they're listed indicate that:
For PDU types other than type 1 (auxiliary advertising), the PDU type
dependent field
--- Begin Message ---
For an advertising physical channel PDU, it appears that the PDU type is in the
least-significant 4 bits of the PDU header.
Is that not present in an auxiliary advertising packet?--- End Message ---
___
tcpdump-workers mailing list
--- Begin Message ---
On Jul 10, 2020, at 2:57 PM, Sultan Khan wrote:
> Link to the updated version of the spec with the latest changes:
> https://gistcdn.githack.com/sultanqasim/8b6561309f5934f084a0d938ae733b7a/raw/199fb1867642c927f768fe7d67dae2a639acb48e/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html
--- Begin Message ---
On Jul 13, 2020, at 9:02 AM, Sultan Khan wrote:
> Thanks Chris. I’ll make a pull request to tcpdump-htdocs later today, and
> I’ll include a link to the previous version of the spec as an archive.org
> link to the old one on whiterocker.com.
The new version is a superset
--- Begin Message ---
On Jul 13, 2020, at 8:09 AM, Sultan Khan wrote:
> Hmm. Chris Kilgour (whiterocker) originally created the spec, and the version
> on tcpdump.org was just a backup copy. Now, Chris has said that he is no
> longer active in the Bluetooth LE sniffing space, and he doesn’t wan
--- Begin Message ---
On Aug 3, 2020, at 12:33 PM, Denis Ovsienko via tcpdump-workers
wrote:
>
> Whilst updating the description of files in tcpslice (the little
> relative of tcpdump) repository, it came to my attention that it does
> not have the customary LICENSE file. I have looked through t
--- Begin Message ---
On Aug 4, 2020, at 1:28 PM, Francois-Xavier Le Bail
wrote:
> lane_if_print() in print-lane.c
> (Added by 77b2a4405561467f66a3dfb0f8ce2b0eaa5ebaf9 in Sun Nov 21 1999 "print
> of ATM LanEmulation")
> is called for DLT_LANE8023:
>
> print.c-56-#ifdef DLT_LANE8023
> print.c:5
--- Begin Message ---
(Your first attempt seems to have worked - finally. Perhaps Michael cleared
the backlog?)
On Aug 10, 2020, at 4:24 AM, Denis Ovsienko via tcpdump-workers
wrote:
> It turns out, pcap_compile_nopcap() has been a part of the libpcap API
> since version 0.5 (June 2000), but
--- Begin Message ---
On Aug 11, 2020, at 4:55 AM, Bill Fenner via tcpdump-workers
wrote:
> Is there a plan for a public face for libnetdissect?
At some point we should probably do that.
(Back in the late '90's, I discovered a program called tcpview, which was a
Motif(!)-based GUI network ana
--- Begin Message ---
On Aug 12, 2020, at 1:31 PM, Guy Harris via tcpdump-workers
wrote:
> We should probably have an include/libnetdissect directory in which we
> install netdissect.h and the headers it requires.
Or include/netdissect.
> However, API-declaring headers should *NEVER
--- Begin Message ---
On Aug 21, 2020, at 2:48 PM, Denis Ovsienko via tcpdump-workers
wrote:
> The man page says:
>
> (In older versions of libpcap, the behavior when cnt was 0
> was undefined; different platforms and devices behaved
> differently, so code that must wor
--- Begin Message ---
This is not a security issue; questions about tcpdump should be sent to
tcpdump-workers@lists.tcpdump.org, which is where I'm sending this question.
On Sep 14, 2020, at 8:22 PM, Accepted <532876...@qq.com> wrote:
> hi, in this picture, I try to use tcpdump to get package wh
--- Begin Message ---
On Sep 28, 2020, at 12:06 PM, Michael Tuexen wrote:
> Do we want to finally publish that? Up to now, I think the point was to
> find a home where it is substantially discussed and improved...
For example, unlike pcap, which is not easily changeable (you *can* change it,
bu
--- Begin Message ---
On Sep 28, 2020, at 12:06 PM, Michael Tuexen wrote:
> On 28. Sep 2020, at 20:26, Michael Richardson wrote:
>
>> internet-dra...@ietf.org wrote:
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-tuexen-opsawg-pcapng-02
>>
>> Hi, I have converted the xml to markdown.
>
--- Begin Message ---
On Sep 28, 2020, at 1:42 PM, Michael Tuexen wrote:
> Shouldn't we write up (I can work on an initial version) of
> a specification for .pcap.
https://github.com/pcapng/pcapng/blob/master/draft-gharris-opsawg-pcap.xml
http://xml2rfc.tools.ietf.org/cgi-bin/
--- Begin Message ---
On Sep 28, 2020, at 2:00 PM, Michael Tuexen wrote:
> On 28. Sep 2020, at 22:48, Guy Harris wrote:
>
>> On Sep 28, 2020, at 1:42 PM, Michael Tuexen wrote:
>>
>>> Shouldn't we write up (I can work on an initial version)
--- Begin Message ---
On Sep 29, 2020, at 7:14 PM, Qin Wu wrote:
> Can you clarify what functionalities is missed for more modern applications?
> Since it is enhancement to libpcap, do you expect all the future packet
> capture tools support the format defined in this draft?
pcapng is a file f
--- Begin Message ---
On Oct 7, 2020, at 1:30 PM, Fernando Gont via tcpdump-workers
wrote:
> WHile using pcap_inject() in Linux, it is failing with "pcap_inject(): send:
> Resource temporarily unavailable". In principle, one would expect that for
> temporary problems (such as this one), one ma
--- Begin Message ---
On Oct 7, 2020, at 3:16 PM, Denis Ovsienko via tcpdump-workers
wrote:
> Do you mean to introduce a function like pcap_error(), which the
> developers would be able to interrogate if they need in use cases like
> this? Then existing functions could be slowly updated as neede
--- Begin Message ---
On Sep 28, 2020, at 4:28 PM, Michael Richardson wrote:
> Guy Harris wrote:
>> For 2), I note that
>
>>
>> https://github.com/pcapng/pcapng/blob/master/draft-tuexen-opsawg-pcapng.md
>
>> has a bunch of stuff that GitHub isn't tr
--- Begin Message ---
On Oct 17, 2020, at 4:19 PM, Guy Harris wrote:
> Or is there some site that will run kramdown-rfc2629 on a Markdown file and
> run xml2rfc on the result, along the lines of what xml2rfc.tools.ietf.org
> does? I haven't gotten
>
> https://xm
--- Begin Message ---
On Oct 17, 2020, at 6:01 PM, Michael Richardson wrote:
> Guy Harris via tcpdump-workers wrote:
>
>> So is there anything we do to arrange that the "Current committed
>> version as ..." links on the GitHub repository home page work again?
&g
--- Begin Message ---
On Oct 18, 2020, at 1:32 AM, Michael Tuexen wrote:
> Just a note. I'm using the .xml format and put a link in the README.md, which
> shows the .txt or .html file based on the current .xml.
Yes, that's what we were doing for the pcapng draft before switching to
kramdown-rf
--- Begin Message ---
On Oct 21, 2020, at 1:56 PM, Aki Van Ness via tcpdump-workers
wrote:
> I'm working on a project that plans to store PCI and PCI-Express
> packets in the pcapng format as that's the most appropriate storage
> format and I really rather not roll something custom.
>
> As such
--- Begin Message ---
What happens if you put
printf("Version: %s\n", pcap_lib_version());
before the pcap_lookupdev() call?
It won't fix the pcap_lookupdev() call not to return NULL, but it'll indicate
what version of libpcap your program is using, which might help determine what
the
--- Begin Message ---
On Nov 4, 2020, at 9:18 PM, Vaughan Wickham wrote:
> Version: libpcap version 1.5.3
That's an older version (CentOS, proudly trailing-edge!), and only returns
interfaces that the program can open.
Capturing on Linux generally requires, at minimum, the CAP_NET_RAW privileg
--- Begin Message ---
On Nov 4, 2020, at 10:26 PM, Vaughan Wickham wrote:
> In regards to your latest comments regarding
>
> sudo setcap cap_net_raw,cap_net_admin+eip {your program}
>
> Are you saying that I need to compile my program and then start the compiled
> version with these arguments,
--- Begin Message ---
On Nov 5, 2020, at 1:04 AM, Vaughan Wickham wrote:
> Appreciate all the info that you have provided.
>
> Although it probably doesn't look like it from my questions; I did actually
> read some tutorials prior to posting my initial question; and none made
> reference to th
--- Begin Message ---
(Resent, from the correct address this time.)
On Dec 21, 2020, at 5:51 PM, Michael Richardson wrote:
> The short of it is:
>
> 1) reserve bits 16:28 of linktype as zero.
In pcap files, presumably; you have only bits 0:15 in pcapng IDBs.
Note that the registry is for both
--- Begin Message ---
On Dec 21, 2020, at 4:31 PM, Michael Richardson wrote:
> Hi, I have reworked the document that Guy put into XML describing the *PCAP*
> (not NG) format. I found the text for LinkType to be confusing, and
> frankly, I think wrong.
>
> * LinkType (32 bits): an unsigned v
--- Begin Message ---
On Dec 22, 2020, at 1:01 AM, Guy Harris wrote:
> They were originally intended for use with some stuff NetBSD was doing (I'd
> have to look into the history of the NetBSD code), but I think NetBSD stopped
> doing that.
The commit message for the change
--- Begin Message ---
On Dec 22, 2020, at 8:36 AM, Michael Richardson wrote:
> Guy Harris wrote:
>
>> And, as per my idea of using 65535 to mean "custom linktype", similar
>> to pcapng custom blocks and options, with either:
>
> I'm happy with this prop
--- Begin Message ---
On Dec 22, 2020, at 2:05 PM, Linus Lüssing via tcpdump-workers
wrote:
> I was experimenting a bit with migrating from the use of
> pcap_offline_filter() to pcap_setfilter().
>
> I was a bit surprised that installing for instance 500 pcap
> handlers
What is a "pcap handler
--- Begin Message ---
On Dec 22, 2020, at 3:31 PM, Linus Lüssing wrote:
> Basically we want to do live measurements of the overhead of the mesh
> routing protocol and measure and dissect the layer 2 broadcast traffic.
> To measure how much ARP, DHCP, ICMPv6 NS/NA/RS/RA, MDNS, LLDP overhead
> etc.
--- Begin Message ---
On Jan 3, 2021, at 12:15 PM, Denis Ovsienko via tcpdump-workers
wrote:
> tcpdump source tree has a short file named "Readme.Win32", which was
> mostly updated on 8 Aug 2019, and a longer file named
> "doc/README.Win32.md", which was mostly updated on 5 Feb 2020. These
> see
--- Begin Message ---
$ curl -s
https://opensource.apple.com/source/tcpdump/tcpdump-100/tcpdump.xcodeproj/project.pbxproj.auto.html
| egrep SUPPORTED_PLATFORMS
SUPPORTED_PLATFORMS = "macosx iphoneos
appletvos watchos bridgeos";
SUPP
--- Begin Message ---
On Jan 7, 2021, at 9:35 AM, Bill Fenner via tcpdump-workers
wrote:
> These jobs are still failing, but now for a different reason.
Part of the problem is that pkg-config wasn't finding the locally-installed
libpcap under /tmp, because PKG_CONFIG_PATH wasn't set to point t
--- Begin Message ---
On Sep 9, 2020, at 9:07 AM, Denis Ovsienko via tcpdump-workers
wrote:
> The "Found pcap-config" message means that FindPCAP.cmake has not found
> libpcap by means of pkg-config, and the lack of the message means the
> pkg-config method worked. A few weeks ago Ubuntu 18.04 s
--- Begin Message ---
On Jan 7, 2021, at 3:21 PM, Guy Harris via tcpdump-workers
wrote:
> So we should either 1) require CMake 3.1 or later or 2) forcibly set
> PKG_CONFIG_USE_CMAKE_PREFIX_PATH to YES. For now, my inclination is to do
> the latter.
That w
--- Begin Message ---
On Jan 7, 2021, at 5:41 PM, Denis Ovsienko via tcpdump-workers
wrote:
> 5 years of backward compatibility might be OK'ish, although from time
> to time I run into such "long-term support" systems that in practice
> mean someone keeps paying good money for "support" for 5-10
--- Begin Message ---
Travis CI is announcing on the travis-ci.org site that "... travis-ci.org will
be shutting down in several weeks, with all accounts migrating to
travis-ci.com. Please stay tuned here for more information."
They don't provide any information there. However, at
htt
--- Begin Message ---
On Jan 22, 2021, at 2:54 PM, Denis Ovsienko via tcpdump-workers
wrote:
> I have tested it again with the current master branches of libpcap and
> tcpdump. Both builds (with and without libpcap0.8-dev) now complete
> without errors.
>
> However, in both cases the installed
--- Begin Message ---
On Jan 21, 2021, at 8:41 AM, Bill Fenner via tcpdump-workers
wrote:
> It would be perfectly reasonable (and fairly straightforward) to update
> libpcap to be able to filter on the Ethernet address in DLT_LINUX_SLL or
> DLT_LINUX_SLL2 mode.
Link-layer address, to be more ac
--- Begin Message ---
On Jan 22, 2021, at 7:11 PM, Guy Harris via tcpdump-workers
wrote:
> I'll try experimenting with one of my Ubuntu VMs.
Welcome to Shared Library Search Hell.
Most UN*Xes have a notion of RPATH (with, of course, different compiler
command-line flags to set it
--- Begin Message ---
On Dec 16, 2020, at 8:09 PM, Yao, Jiewen via tcpdump-workers
wrote:
> I write this email to request to below 2 link types.
>
>
> 1. MCTP
...
> MCTP packet is defined in DMTF PMCI working group Management Component
> Transport Protocol (MCTP) Base
> Specifica
--- Begin Message ---
On Dec 16, 2020, at 8:09 PM, Yao, Jiewen via tcpdump-workers
wrote:
> We did a prototype for the SpdmDump tool
> (https://github.com/jyao1/openspdm/blob/master/Doc/SpdmDump.md). We can
> generate a PCAP file and parse it offline.
> In our prototype, we use below definitio
--- Begin Message ---
On Feb 3, 2021, at 6:54 AM, developer--- via tcpdump-workers
wrote:
> We would like to request a dedicated LINKTYPE_* / DLT_* code.
> Auerswald is a major German telecommunications equipment manufacturer.
> We have implemented the option to capture (combined) network traffi
--- Begin Message ---
On Feb 4, 2021, at 3:41 AM, developer--- via tcpdump-workers
wrote:
> We currently use this code in our lua dissector to display (decoded) SIP
> messages.
>
> -- offsets will change with the new LINKTYPE
>if (buf(148,2):uint() == MSG_TYPE_SIP) then
>sadd("src_
--- Begin Message ---
On Mar 3, 2021, at 8:58 AM, Jan Adam via tcpdump-workers
wrote:
> for our new analysis product netANALYZER NG I would like to request a new
> link-layer type value.
>
> NETANALYZER_NG
>
> The new Link-Layer-Type format is described as following:
>
> Next-generation pack
--- Begin Message ---
On Mar 3, 2021, at 2:30 PM, Denis Ovsienko via tcpdump-workers
wrote:
> A partial replacement for that service is ci.tcpdump.org, which is a
> buildbot instance doing Linux AArch64 builds for the github.com
> repositories.
So where is that hosted? Are you hosting it yours
--- Begin Message ---
On Mar 8, 2021, at 12:07 AM, Jan Adam via tcpdump-workers
wrote:
> We have created a public document on our website You can point to for the
> description.
>
> Here is the link: https://kb.hilscher.com/x/brDJBw
>
> It contains a more detailed description of the fields i
--- Begin Message ---
On Mar 12, 2021, at 4:35 AM, Jan Adam wrote:
>> So is "the variable" the same thing as "the payload"?
>
> That is correct. To be more specific the payload is the value/content of the
> variable.
Can the variable be anything *other* than a packet of some sort? The current
--- Begin Message ---
https://devblogs.microsoft.com/cppblog/address-sanitizer-for-msvc-now-generally-available/--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcp
--- Begin Message ---
On Feb 12, 2021, at 4:49 AM, developer--- via tcpdump-workers
wrote:
> Sorry for the delay in responding, I had to look thru the code to make sure
> all the information is accurate.
>
> I looked into the option to change in particular the msg_type 1 (decoded SIP
> messa
--- Begin Message ---
On Mar 15, 2021, at 9:04 AM, Jan Adam wrote:
>> Can the variable be anything *other* than a packet of some sort?
>
> There are only the mentioned 5 representations planned for pcap files since
> this is what our capture device may capture into a pcap file. The
> represent
--- Begin Message ---
On Mar 22, 2021, at 7:33 AM, Jan Adam wrote:
>> Are they aligned on natural boundaries?
>
> No, it is not aligned but packet. We use #pragma pack(1) for the footer
> structure.
You should probably add that to the page with the structure definition.
>> What do the four f
--- Begin Message ---
On Mar 22, 2021, at 5:35 PM, Denis Ovsienko via tcpdump-workers
wrote:
> On Mon, 22 Mar 2021 19:00:31 +0100
> Harald Welte wrote:
...
>> btw: I'm not sure if qemu full system emulation of e.g. ppc on a
>> x86_64 hardware would be an option, though. I think
>> op
--- Begin Message ---
On Mar 24, 2021, at 12:32 AM, Jan Adam wrote:
>> So, with incl_len equal to {PayloadSize,VarSize} + 54, orig_len would be
>> equal to {original PayloadSize} + 54, so the original payload size would be
>> orig_len - 54.
>>
>> That would allow the original size and the slic
--- Begin Message ---
https://twitter.com/MeghanEMorris/status/1382109954224521216/photo/1
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
--- Begin Message ---
On Jul 23, 2021, at 4:11 PM, Denis Ovsienko via tcpdump-workers
wrote:
> As it turns out, on Solaris 9 it is impossible to compile current
> tcpdump with CFLAGS=-Werror because missing/getopt_long.c yields a few
> warnings (attached). As far as the current revisions of this
--- Begin Message ---
On Jul 31, 2021, at 3:37 AM, Denis Ovsienko via tcpdump-workers
wrote:
> # Solaris 11 with GCC #
> This is the opposite: the pre-compile libpcap feature test programs
> fail to link so all libpcap feature tests fail. However, libpcap is
> detected as available and t
--- Begin Message ---
On Jul 31, 2021, at 4:35 PM, Denis Ovsienko wrote:
> On Sat, 31 Jul 2021 14:55:32 -0700
> Guy Harris wrote:
>
> [...]
>> What version of CMake is being used, and how was it installed?
>>
>> My Solaris 11 x86-64 virtual machine has CMake
--- Begin Message ---
On Aug 1, 2021, at 6:08 PM, Denis Ovsienko wrote:
> On Sun, 1 Aug 2021 15:45:39 -0700
> Guy Harris wrote:
>
>> Probably some annoying combination of one or more of "different
>> compilers", "later version of CMake", "at lea
--- Begin Message ---
On Jul 31, 2021, at 3:37 AM, Denis Ovsienko via tcpdump-workers
wrote:
> # Solaris 11 with GCC #
> This is the opposite: the pre-compile libpcap feature test programs
> fail to link so all libpcap feature tests fail. However, libpcap is
> detected as available and t
--- Begin Message ---
On Aug 3, 2021, at 12:07 AM, Dagobert Michelsen wrote:
> The /64 suffix in bin/ and lib/ is a symlink to the respective architecture
> and simplifies cross-platform build between Sparc and x86.
For whatever reason, /usr/bin/64 isn't present on my Solaris 11.3 (x86-64) VM:
--- Begin Message ---
On Jul 31, 2021, at 3:37 AM, Denis Ovsienko via tcpdump-workers
wrote:
> # Solaris 11 with GCC #
> This is the opposite: the pre-compile libpcap feature test programs
> fail to link so all libpcap feature tests fail. However, libpcap is
> detected as available and t
--- Begin Message ---
On Aug 8, 2021, at 2:26 AM, Denis Ovsienko wrote:
> GCC+CMake fails early now (see attached).
Good! That reveals the *underlying* problem:
1) CMake, by default, checks for both a C *and* a C++ compiler;
2) if it's checking for both compilers, the way CMake determines
CM
--- Begin Message ---
On Aug 11, 2021, at 3:09 PM, Denis Ovsienko via tcpdump-workers
wrote:
> The other matter is that the gencode.h/grammar.h pair works best when
> it is included early.
Perhaps the gencode.h/grammar.h pair works best when it doesn't include
grammar.h. :-)
I've checked in a
--- Begin Message ---
On Dec 6, 2021, at 10:55 AM, Denis Ovsienko via tcpdump-workers
wrote:
> On Mon, 29 Nov 2021 19:20:32 +0100 Francois-Xavier Le Bail via
> tcpdump-workers wrote:
>
>> Does anyone use these files?
>> Win32/Prj/wpcap.sln
>> Win32/Prj/wpcap.vcxproj
>> Win32/Prj/wpcap.vcxproj
--- Begin Message ---
On Jan 5, 2022, at 9:38 AM, Timotej Ecimovic via tcpdump-workers
wrote:
> I'm requesting an addition of the new DLT type. I'd call it:
> DLT_SILABS_DEBUG_CHANNEL.
> The description of the protocol is here:
> https://github.com/SiliconLabs/java_packet_trace_library/blob/mas
--- Begin Message ---
On Jan 5, 2022, at 6:53 PM, Timotej Ecimovic
wrote:
> No. Like the document describes: tooling that deals with deframing is
> expected to remove the starting `[`, the ending `]` and the 2 byte length
> right after the `[`.
> In case of creating a PCAPNG file out of this s
--- Begin Message ---
I've just updated the libpcap .appveyor.yml to get Npcap from npcap.com (the
Npcap site has been moved there); I added [skip cirrus] to skip Cirrus CI for
that change, and it appears to work.
Are there other comments to add to suppress OpenCSW CI and to suppress the
other
--- Begin Message ---
On Jan 6, 2022, at 3:00 PM, Denis Ovsienko via tcpdump-workers
wrote:
> On Thu, 6 Jan 2022 14:11:54 -0800 Guy Harris via tcpdump-workers
> wrote:
>
>> I've just updated the libpcap .appveyor.yml to get Npcap from
>> npcap.com (the Npcap sit
--- Begin Message ---
On Jan 6, 2022, at 3:22 PM, Guy Harris via tcpdump-workers
wrote:
> On Jan 6, 2022, at 3:00 PM, Denis Ovsienko via tcpdump-workers
> wrote:
>
>> Do you think https://www.tcpdump.org/ci.html should document [skip cirrus]
>> and [skip appveyor]
--- Begin Message ---
On Mar 7, 2022, at 5:55 AM, Christian via tcpdump-workers
wrote:
> hello out there, I created a kernel probe module and I want to watch the
> outputs of that module with pcap/Wireshark or tcpdump... Just like
> usbmon. My prefered tool is dumpcap. So I defined a char device
--- Begin Message ---
On May 8, 2022, at 4:48 AM, Tomasz Moń via tcpdump-workers
wrote:
> I would like to remedy the situation by requesting additional speed
> specific link layer header types, for example:
> * LINKTYPE_USB_2_0_LOW_SPEED
> * LINKTYPE_USB_2_0_FULL_SPEED
> * LINKTYPE_USB_2_0_HI
--- Begin Message ---
On May 8, 2022, at 1:30 PM, Michael Richardson wrote:
> I guess I would have thought that a physical bus could have a mix of
> different devices which operate at different speeds. As such, I wondered if
> you really needed pcapng to be able to mix LINKTYPES in the same file
--- Begin Message ---
On May 8, 2022, at 10:47 PM, Tomasz Moń wrote:
> On Sun, May 8, 2022 at 8:53 PM Guy Harris wrote:
>> At least from a quick look at section 5.2.3 "Physical Bus Topology" of the
>> USB 2.0 spec, a given bus can either be a high-speed bus or
--- Begin Message ---
On May 8, 2022, at 11:09 PM, Tomasz Moń wrote:
> Note that end nodes cannot directly communicate with each other. The
> communication is always between host and a device.
Those two sentences, when combined, imply that either
1) a host is not an end node
or
--- Begin Message ---
On May 9, 2022, at 1:33 AM, Tomasz Moń wrote:
> On Mon, May 9, 2022 at 9:21 AM Guy Harris wrote:
>> On May 8, 2022, at 11:09 PM, Tomasz Moń wrote:
>>
>>> Device to device communication is not possible.
>>
>> Is the idea that the topo
--- Begin Message ---
On May 9, 2022, at 1:58 AM, Tomasz Moń wrote:
> On Mon, May 9, 2022 at 9:17 AM Guy Harris wrote:
>> On May 8, 2022, at 10:47 PM, Tomasz Moń wrote:
>>> On Sun, May 8, 2022 at 8:53 PM Guy Harris wrote:
>>>> At least from a quick look at sectio
--- Begin Message ---
On May 9, 2022, at 7:41 AM, Tomasz Moń wrote:
> That would require defining pseudoheader that would have to be included
> in every packet.
Is that really a great burden?
> And it would only solve the corner case that the
> currently available open-source friendly sniffers
--- Begin Message ---
On May 9, 2022, at 12:40 PM, Tomasz Moń wrote:
> On Mon, 2022-05-09 at 12:02 -0700, Guy Harris wrote:
>> On May 9, 2022, at 7:41 AM, Tomasz Moń wrote:
>>
>>> That would require defining pseudoheader that would have to be
>>> included in ev
--- Begin Message ---
On May 9, 2022, at 12:31 PM, Tomasz Moń wrote:
> There is no such thing as "low-speed bus" because low-speed is only
> allowed for non-hub devices. USB hosts and hubs *must* support atleast
> full and high speed. USB devices are allowed to be low-speed (such
> devices can op
--- Begin Message ---
On May 9, 2022, at 1:02 PM, Tomasz Moń wrote:
> The same as why URB level captures are confusing. Maybe not to the same
> level as that would be just a single byte (and the URB metadata
> contains way more information), but it would still raise the questions
> like "where in
--- Begin Message ---
On May 9, 2022, at 9:41 PM, Tomasz Moń wrote:
> On Mon, 2022-05-09 at 13:19 -0700, Guy Harris wrote:
>> On May 9, 2022, at 1:02 PM, Tomasz Moń wrote:
>>
>>> "Why this doesn't match all the documents on USB that I have
>>> read
--- Begin Message ---
On May 9, 2022, at 10:05 PM, Tomasz Moń wrote:
> On Tue, May 10, 2022 at 6:57 AM Guy Harris wrote:
>> On May 9, 2022, at 9:41 PM, Tomasz Moń wrote:
>>> Also Wireshark would have to show "USB Full/Low speed capture" section with
>>> o
--- Begin Message ---
On May 20, 2022, at 10:56 AM, Bill Fenner via tcpdump-workers
wrote:
> I'm helping to debug a system that uses many many pcap handles, and never
> calls pcap_loop - only ever pcap_next.
Both pcap_loop() and pcap_next() ultimately go to the same place.
Note, BTW, that pcap
--- Begin Message ---
On Jun 10, 2022, at 1:59 PM, Denis Ovsienko via tcpdump-workers
wrote:
> Below is a draft of such a file format. It addresses the following
> needs:
> * There is a header with a signature string to avoid false positive
> detection as some other file type that begins exact
--- Begin Message ---
On Jul 4, 2022, at 4:49 PM, Ryan Castellucci via tcpdump-workers
wrote:
> 1) TLS compression support is a foot-bazooka, is exploitable in practice, and
> should be removed. A modified version of the CRIME[1] attack should be
> completely feasible. I can't imagine any remo
--- Begin Message ---
On Jul 10, 2022, at 2:48 PM, Denis Ovsienko via tcpdump-workers
wrote:
> The last CI build of the libpcap-1.10 branch failed on netbsd-aarch64
> because the latter now uses GCC 12. Commit 4e7f6e8 makes a lazy fix
> for that in the master branch; if a more sophisticated sol
--- Begin Message ---
On Jul 17, 2022, at 10:10 AM, Francois-Xavier Le Bail via tcpdump-workers
wrote:
> The current nd_ipv4 and nd_ipv6 types were added in 2017 for alignment
> reasons.
>
> Since then,
> most of the 'struct in_addr' were replaced by 'nd_ipv4',
> most of the 'struct in6_addr'
--- Begin Message ---
On Jul 17, 2022, at 11:09 AM, Francois-Xavier Le Bail
wrote:
> Remain some stuff about 'struct in6_addr'. Any need to keep them?
>
> $ git grep -l 'struct in6_addr'
> CMakeLists.txt
> cmakeconfig.h.in
> config.h.in
> configure
> configure.ac
> netdissect-stdinc.h
That's t
--- Begin Message ---
On Jul 17, 2022, at 3:39 PM, Bill Fenner wrote:
> IMO it is safe to drop support for OSes lacking native IPv6 support.
Yeah. Back when IPv6 support was added to tcpdump, it was an experimental new
technology and the configure script had to figure out which of several add-
--- Begin Message ---
On Aug 12, 2022, at 7:27 AM, Christian via tcpdump-workers
wrote:
> I pick up this thread of mine again from 7th march of this year (wireshark
> extension for a Kernel Module (like Usbmon) ) enhanced with a configure
> issue,
Unless I've missed something, "again" means
--- Begin Message ---
On Aug 15, 2022, at 12:50 AM, Denis Ovsienko via tcpdump-workers
wrote:
> On Sun, 14 Aug 2022 11:49:57 -0700
> Guy Harris via tcpdump-workers
> wrote:
>
>> Or is this a ZIP archive provided by somebody other than tcpdump.org?
>
> github.com -&
--- Begin Message ---
What are the contents of config.log?
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
--- Begin Message ---
On Aug 15, 2022, at 1:37 PM, Christian wrote:
> configure:6075: checking for pcap_loop
> configure:6075: gcc -o conftest -g -O2 conftest.c -L/usr/local/lib
> -Wl,-rpath,/usr/local/lib -lpcap >&5
> /usr/bin/ld: /usr/local/lib/libpcap.so: undefined reference to
> `scsimon
2401 - 2500 of 2521 matches
Mail list logo
