lkml.org 
[lkml]   [2004]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BK PATCH] Fix ip_conntrack_amanda data corruption bug that breaks amanda dumps
On Thu, 04 Nov 2004, Patrick McHardy wrote:

> Matthias Andree wrote:
>
> >You can use "bk receive" to patch with this mail.
> >
> >BK: Parent repository is bk://linux.bkbits.net/linux-2.5
> >
> >Patch description:
> >ChangeSet@1.2427, 2004-11-04 13:00:54+01:00, matthias.andree@gmx.de
> > Fix ip_conntrack_amanda data corruption bug that breaks amanda dumps.
> >
> > Fix a bug where the ip_conntrack_amanda module replaces the first LF
> > after "CONNECT " by a NUL byte. This causes the UDP checksum to become
> > corrupt and strips off the OPTIONS argument from the received packet,
> > breaking amanda's sendbackup component altogether. Replace the LF
> > character before releasing the buffer.
> >
> The data that is changed is only a copy, the actual packet is not touched.

Why then does the application not see the packets as long as
ip_conntrack_amanda is loaded and starts seeing them again as soon as
"rmmod ip_conntrack_amanda" has completed?

And I'm not even arguing with tcpdump which may get the altered copy of the packet.

I am unaware of two things:
1. detailed packet flow and SKBs
2. internal ip_conntrack API.

I am however seeing that ip_conntrack_amanda
1. jams the application's protocol
2. modifies the packet.

So is there any evidence to support the "only a copy" theory?

--
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.069 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site