Messages in this thread | | | Date | Fri, 5 Nov 2004 00:17:34 +0100 | From | Matthias Andree <> | Subject | Re: [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/
| |