--- 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 ---
On Apr 1, 2020, at 4:14 PM, Mario Rugiero via tcpdump-workers
wrote:
> 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,
--- 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 ---
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
; Date: Tue, 10 Mar 2020 15:25:38 -0300
> Subject: Re: [tcpdump-workers] Legacy Linux kernel support
> El mar., 10 mar. 2020 15:07, Michael Richardson
> escribió:
>
> >
> > Mario Rugiero wrote:
> > >> I am trying to process many pull requests for libpcap and tcpd
--- 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 from you
> yet.
> >> Am I wrong?
--- 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 ---
On Oct 23, 2019, at 1:43 AM, Anders Broman wrote:
> On Oct 23, 2019, at 12:26 AM, Anders Broman
> wrote:
>
>>> El mar., 22 oct. 2019 a las 15:08, Guy Harris ()
>>> escribió:
> Does it allow receiving copies of packets that are also handed either to
> the k
--- Begin Message ---
On Oct 23, 2019, at 12:26 AM, Anders Broman wrote:
> El mar., 22 oct. 2019 a las 15:08, Guy Harris () escribió:
>>
>>> Does it allow receiving copies of packets that are also handed either to
>>> the kernel networking stack or to other AF_XDP sockets for regular input
>>>
--- Begin Message ---
On Oct 22, 2019, at 2:24 PM, Mario Rugiero wrote:
> 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/ar
--- 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 ---
On Oct 22, 2019, at 1:22 PM, Mario Rugiero wrote:
> 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
>> distribut
--- 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 ---
On Oct 22, 2019, at 11:38 AM, Mario Rugiero wrote:
> 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 r
--- 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 RHEL6's kernel is pre-3.16 and t
--- Begin Message ---
On Oct 21, 2019, at 5:59 PM, Mario Rugiero via tcpdump-workers
wrote:
> 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 offic
--- 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,
>
On Oct 8, 2019, at 2:15 PM, Michael Richardson wrote:
> I don't really know which "legacy" compiler stuff that we may wish to
> continue to tolerate in tcpdump, but which we can dispense with in libpcap.
At this point, in the master branch, I'm not sure there's a difference between
how much C99
On Oct 8, 2019, at 8:43 AM, Michael Richardson wrote:
> And that's why I think we would agree that we don't want to let tcpdump go
> all C99, etc. yet, because people often *do* want the latest tcpdump, on top
> of a kernel-compatible libpcap.
What do you mean by "all C99"? The master branch's
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 "official" distro package, is it li
On Oct 8, 2019, at 9:29 AM, Mario Rugiero wrote:
> Supporting TPACKET_V2 should suffice to fill this gap, right?
> We would still need to make a few changes, currently you need to use a
> kernel which doesn't support TPACKET_V3 to use this correctly.
> It shouldn't be a big change to make immedia
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
From: Mario Rugiero
> Sent: 07 October 2019 19:07
...
> > 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, and would require that the headers with which libpcap is being
> > built be new enough to support TPAC
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
> protocol running directly atop the link layer, rat
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 protocol
>> running directly atop the link layer, rather than passively sniffing
>> traffic, you still get a pa
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
On Oct 7, 2019, at 11:07 AM, Mario Rugiero wrote:
>> So that would mean using non-memory-mapped capturing in immediate mode.
>> That might even work better for that purpose - yes, there's more copying
>> involved (copying the packet to the socket buffer and then copying from the
>> socket buf
> 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
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.fclose.com/linux-kernel
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
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 oldest version supported by upstream is 3.16.
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
34 matches
Mail list logo
