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 - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
