--- Begin Message ---
El dom., 28 jun. 2020 a las 18:02, Michael Richardson
() escribió:
>
>
> Mario Rugiero via tcpdump-workers wrote:
> >> For a contract, I am trying to improve the write performance by using
> >> async I/O. {I also need to associate re
--- Begin Message ---
El sáb., 27 jun. 2020 a las 23:56, Michael Richardson
() escribió:
>
>
> Mario, can you confirm my understanding here.
>
Hi Michael.
> In TPACKET3 mode, there are (tp_block_nr) pools of memory.
> The beginning of each block is tp_block_size in size, which can
> be large numbe
--- Begin Message ---
OK, it seems fair. Besides, I just checked the code for the oldest
long-term release from kernel.org, a 3.16 one, and it doesn't contain
the fix, and I think it should be supported.
--- End Message ---
___
tcpdump-workers mailing lis
--- Begin Message ---
OK, follow up.
I haven't yet been able to test it, which is why I've been delaying
writing about this,
but these two commits[0][1], which according to these threads[2][3]
are the ones fixing
the timeout issue, have been applied to CentOS 7 default kernel,
3.10.0-1062.el7.
It c
--- Begin Message ---
El sáb., 21 mar. 2020 18:15, Guy Harris via tcpdump-workers <
tcpdump-workers@lists.tcpdump.org> escribió:
> 1) has the slight disadvantage that the name for the team suggests it's
> for pcapng only; it appears that teams can be renamed:
>
>
> https://help.github.com/en/githu
--- Begin Message ---
Hi again.
I'm not sure I'm reading it right (thus I ask here), but is this[0]
the fixing commit?
If it is, I think it's applied on CentOS 7, and since it's basically a
free rebuild of RHEL, I'd expect it to be fixed there, too.
I'll send a few links later so you can check it o
--- Begin Message ---
El mar., 10 mar. 2020 15:26, Mario Rugiero via tcpdump-workers <
tcpdump-workers@lists.tcpdump.org> escribió:
>
>
>
> -- Forwarded message ------
> From: Mario Rugiero
> To: Michael Richardson
> Cc: tcpdump-workers
> Bcc:
>
--- Begin Message ---
El mar., 10 mar. 2020 15:07, Michael Richardson
escribió:
>
> Mario Rugiero wrote:
> >> I am trying to process many pull requests for libpcap and tcpdump,
> get some
> >> things closed. I don't think that there is a pull request fro
--- Begin Message ---
El lun., 2 mar. 2020 a las 14:31, Michael Richardson
() escribió:
> I am trying to process many pull requests for libpcap and tcpdump, get some
> things closed. I don't think that there is a pull request from you yet.
> Am I wrong?
>
Some related PRs got merged already. My Gi
--- Begin Message ---
El mar., 22 oct. 2019 a las 18:01, Guy Harris () escribió:
>
> If RHEL 6 matters, oldest longterm from kernel.org only doesn't work, because
> RHEL 6 runs 2.6.32, according to
>
> https://access.redhat.com/articles/3078
>
> so if we're going to support only the oldest
--- Begin Message ---
El mar., 22 oct. 2019 a las 16:02, Guy Harris () escribió:
> I.e., the goal for libpcap support on Linux should be something such as
>
> it should work on min({kernel for oldest supported enterprise
> distribution}, {oldest "longterm maintenance" kernel release from k
--- Begin Message ---
El mar., 22 oct. 2019 a las 15:08, Guy Harris () escribió:
>
> On Oct 21, 2019, at 5:59 PM, Mario Rugiero via tcpdump-workers
> wrote:
> > - TPACKET_V2 stays for immediate-mode support.
> > - As a side-effect, RHEL6 remains supported.
>
> So RHE
--- Begin Message ---
I think it's time to summarize, and to propose one last idea.
I'm following the thread again to try and be as accurate as possible,
but of course any objections are welcomed.
- The oldest officially supported kernel is 3.16, as this is the
oldest LTS according to kernel.org.
El mié., 9 oct. 2019 a las 13:16, Michael Richardson
() escribió:
> Right, but the different mechanisms can be different modules, and distros can
> opt not to even build the modules, and eventually we can all move forward.
>
But that wouldn't make any difference maintenance wise that I can see.
>
El mar., 8 oct. 2019 a las 18:16, Michael Richardson
() escribió:
> So I'm hearing that on Linux we should support V2 and V3.
> *That we continue to need V2 support from the kernel for immediate mode*
>
I think so, yes.
> (This has implications to the *kernel* people as to what they can rip out,
>
El mar., 8 oct. 2019 a las 13:29, Mario Rugiero () escribió:
> It depends.
> Which distro is it?
> When does it EOL?
> Do we expect a release of libpcap before that?
> What version of libpcap does it ship?
> Do the providers ship it with custom patches?
> For the "offic
El mar., 8 oct. 2019 a las 3:59, Michael Richardson
() escribió:
> There are many people who use prototype new things this way.
> Even IP/IPv6 stuff that use a different protocol number. Often they move
> away from libpcap as their requirements grow, but they start that way.
>
> One reason to do
El lun., 7 oct. 2019 17:05, Guy Harris escribió:
> On Oct 7, 2019, at 12:55 PM, Mario Rugiero wrote:
>
> > El lun., 7 oct. 2019 a las 16:07, Guy Harris ()
> escribió:
> >
> >> So are you saying that, even if you're using libpcap to implement a
> protoco
El lun., 7 oct. 2019 a las 16:07, Guy Harris () escribió:
> So are you saying that, even if you're using libpcap to implement a protocol
> running directly atop the link layer, rather than passively sniffing traffic,
> you still get a packet firehose?
>
No, I get a packet fire hose because I pas
> A long time ago, I had the impression that 2.0.x kernels, and perhaps even
> 1.x kernels, were popular for some small embedded systems; some of them might
> perform networking functions, so that libpcap support might be useful, even
> if they didn't run full-blown tcpdump, but just ran somethi
El lun., 7 oct. 2019 a las 12:32, Michael Richardson
() escribió:
>
>
> 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.
> > The ol
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.
The oldest version supported by upstream is 3.16.74.
The most 'bleeding-edge' supported family has been there since the
2.6.y times, almost 10 years ago, so I think we
El jue., 3 oct. 2019 a las 4:28, Guy Harris () escribió:
>
> We might want to have another API to supply the *minimum* buffer size. For
> BSD-style BPF, we could use BPF_MINBUFSIZE if it's defined in .
>
That sounds good. Should we still allow passing buffers below that
minimum with the original
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 versioning is more future-p
El mié., 2 oct. 2019 a las 18:46, Guy Harris () escribió:
>
> 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
&g
25 matches
Mail list logo
