On 17.04, Hannes Frederic Sowa wrote:
>
>
> On Thu, Apr 16, 2015, at 22:56, Patrick McHardy wrote:
> > On 17.04, Herbert Xu wrote:
> > > On Thu, Apr 16, 2015 at 06:13:25PM +0200, Hannes Frederic Sowa wrote:
> > > >
> > > > So currently we have one fast path, that is: we are not fragmented, we
> >
On Thu, Apr 16, 2015, at 22:56, Patrick McHardy wrote:
> On 17.04, Herbert Xu wrote:
> > On Thu, Apr 16, 2015 at 06:13:25PM +0200, Hannes Frederic Sowa wrote:
> > >
> > > So currently we have one fast path, that is: we are not fragmented, we
> > > get out non-fragmented, none of this code is ever
On 17.04, Herbert Xu wrote:
> On Thu, Apr 16, 2015 at 06:13:25PM +0200, Hannes Frederic Sowa wrote:
> >
> > So currently we have one fast path, that is: we are not fragmented, we
> > get out non-fragmented, none of this code is ever touched and no
> > problem.
> >
> > We don't want to mak this mor
On 16.04, David Miller wrote:
> > Netfilter may change the contents of the packet, even change its size.
> > It is *really* hard to do this while keeping the original fragments
> > intact.
>
> I keep hearing a lot of "it's hard" as the only reason we shouldn't do
> this properly, and that frankly
On Thu, Apr 16, 2015 at 06:13:25PM +0200, Hannes Frederic Sowa wrote:
>
> So currently we have one fast path, that is: we are not fragmented, we
> get out non-fragmented, none of this code is ever touched and no
> problem.
>
> We don't want to mak this more complex, but
You should read Dave's oth
Am 16. April 2015 17:43:23 MESZ, schrieb David Miller :
>From: Hannes Frederic Sowa
>Date: Thu, 16 Apr 2015 14:11:42 +0200
>
>> On Thu, Apr 16, 2015, at 07:29, Herbert Xu wrote:
>>> On Thu, Apr 16, 2015 at 06:24:00AM +0100, Patrick McHardy wrote:
>>> >
>>> > Netfilter may change the contents of th
Hi David,
On Thu, Apr 16, 2015, at 17:43, David Miller wrote:
> From: Hannes Frederic Sowa
> Date: Thu, 16 Apr 2015 14:11:42 +0200
>
> > On Thu, Apr 16, 2015, at 07:29, Herbert Xu wrote:
> >> On Thu, Apr 16, 2015 at 06:24:00AM +0100, Patrick McHardy wrote:
> >> >
> >> > Netfilter may change the
From: Hannes Frederic Sowa
Date: Thu, 16 Apr 2015 14:11:42 +0200
> On Thu, Apr 16, 2015, at 07:29, Herbert Xu wrote:
>> On Thu, Apr 16, 2015 at 06:24:00AM +0100, Patrick McHardy wrote:
>> >
>> > Netfilter may change the contents of the packet, even change its size.
>> > It is *really* hard to do
From: Patrick McHardy
Date: Thu, 16 Apr 2015 06:24:00 +0100
> On 16.04, Herbert Xu wrote:
>> David Miller wrote:
>> >
>> > Because then there is no ambiguity at all, you preserve on output
>> > exactly what you had on input. The same geometry, the same
>> > everything. No special checks, no m
On Thu, Apr 16, 2015, at 07:29, Herbert Xu wrote:
> On Thu, Apr 16, 2015 at 06:24:00AM +0100, Patrick McHardy wrote:
> >
> > Netfilter may change the contents of the packet, even change its size.
> > It is *really* hard to do this while keeping the original fragments
> > intact.
>
> Perhaps we sho
On 16.04, Herbert Xu wrote:
> On Thu, Apr 16, 2015 at 06:24:00AM +0100, Patrick McHardy wrote:
> >
> > Netfilter may change the contents of the packet, even change its size.
> > It is *really* hard to do this while keeping the original fragments
> > intact.
>
> Perhaps we should provide better hel
On Thu, Apr 16, 2015 at 06:24:00AM +0100, Patrick McHardy wrote:
>
> Netfilter may change the contents of the packet, even change its size.
> It is *really* hard to do this while keeping the original fragments
> intact.
Perhaps we should provide better helpers to facilitate this?
So instead of di
On 16.04, Herbert Xu wrote:
> David Miller wrote:
> >
> > Because then there is no ambiguity at all, you preserve on output
> > exactly what you had on input. The same geometry, the same
> > everything. No special checks, no max frag len, none of this crap.
> > Those are all hacks trying to wor
David Miller wrote:
>
> Because then there is no ambiguity at all, you preserve on output
> exactly what you had on input. The same geometry, the same
> everything. No special checks, no max frag len, none of this crap.
> Those are all hacks trying to work around the _fundamental_ issue
> which
14 matches
Mail list logo
