Hi Linus!
DaveM is probably travelling back from UKUUG at the moment and therefore
wasn't able to push this fix to you.
The following trivial patch is confirmed to solve an ICMP corruption
problem if NAT and the NOTRACK target are used together.
Please apply before 2.6.13 is released.
Thanks,
[ Cleaning up Cc list ]
On Mon, Aug 08, 2005 at 12:34:00AM +0200, Patrick McHardy wrote:
> > Looking at the latest traces Vladimir sent me, there is another case,
> > too.
>
> Yes, but nat_packet checks if manips have actually been set up before
> touching the packet. This can never happen for t
Harald Welte wrote:
> On Sun, Aug 07, 2005 at 08:42:56PM +0200, Patrick McHardy wrote:
>
>>The conntrack reference is manually attached to locally generated ICMP
>>errors and icmp_reply_translation() doesn't check if NAT mappings have
>>been set up but simply replaces IP/port by what is stored in
On Sun, Aug 07, 2005 at 08:42:56PM +0200, Patrick McHardy wrote:
> Harald Welte wrote:
> > On Sun, Aug 07, 2005 at 05:18:06PM +0200, Harald Welte wrote:
> >
> >>The following trivial patch was confirmed to solve the problem. Patrick
> >>also has no objections, so please apply this to mainline.
>
Harald Welte wrote:
> On Sun, Aug 07, 2005 at 05:18:06PM +0200, Harald Welte wrote:
>
>>The following trivial patch was confirmed to solve the problem. Patrick
>>also has no objections, so please apply this to mainline.
>
> Please hold it back for another minute. I'm still puzzled by this
> pro
On Sun, Aug 07, 2005 at 06:44:15PM +0200, Harald Welte wrote:
> On Sun, Aug 07, 2005 at 05:18:06PM +0200, Harald Welte wrote:
> > Hi Dave!
> >
> > The following trivial patch was confirmed to solve the problem. Patrick
> > also has no objections, so please apply this to mainline.
>
> Please hold
On Sun, Aug 07, 2005 at 05:18:06PM +0200, Harald Welte wrote:
> Hi Dave!
>
> The following trivial patch was confirmed to solve the problem. Patrick
> also has no objections, so please apply this to mainline.
Please hold it back for another minute. I'm still puzzled by this
problem. I can neit
Hi Dave!
The following trivial patch was confirmed to solve the problem. Patrick
also has no objections, so please apply this to mainline.
I'm undecided whether it should go into 2.6.12.x, since the problem only
occurs in very rare usage cases. OTOTH, the fix is very trivial... so I
leave it up
On Sat, Aug 06, 2005 at 06:17:56PM +0200, Harald Welte wrote:
> Ok, I re-thought. Given the following assumptions (combined from your
> three mails):
>
> 1) tcp/udp packets are matched by NOTRACK
> 2) icmp errors for packets in '1' are matched by NOTRACK
> 3) there are no NAT rules that affect th
On Sat, Aug 06, 2005 at 01:25:43PM +0400, Vladimir B. Savkin wrote:
> On Sat, Aug 06, 2005 at 11:13:37AM +0200, Harald Welte wrote:
> > On Sat, Aug 06, 2005 at 02:08:15AM +0400, Vladimir B. Savkin wrote:
> > > I found that it really is NOTRACK who cause? bogus ICMP errors.
> >
> > Well, this means
On Sat, Aug 06, 2005 at 04:58:46PM +0200, Patrick McHardy wrote:
> Harald Welte wrote:
> >On Sat, Aug 06, 2005 at 02:08:15AM +0400, Vladimir B. Savkin wrote:
> >
> >>I found that it really is NOTRACK who cause? bogus ICMP errors.
>
> Good work tracking this down. I've seen reports of this before,
On Sat, Aug 06, 2005 at 05:12:01PM +0200, Harald Welte wrote:
> > > Well, this means that your ICMP errors need to be NAT'ed but they
> > > cannot, since the original connection causing the ICMP error did not go
> > > through connection tracking.
> >
> > How so, when there are no NAT rules that ca
Harald Welte wrote:
As soon as you load NAT, _all_ connections need to be tracked, since
those with no NAT configured need to "allocate a null binding".
NAT needs to know about all connections, since otherwise it would not be
able to learn about all already-used port/ip tuples.
So independant o
On Sat, Aug 06, 2005 at 01:25:43PM +0400, Vladimir B. Savkin wrote:
> On Sat, Aug 06, 2005 at 11:13:37AM +0200, Harald Welte wrote:
> > On Sat, Aug 06, 2005 at 02:08:15AM +0400, Vladimir B. Savkin wrote:
> > > I found that it really is NOTRACK who cause? bogus ICMP errors.
> >
> > Well, this means
Harald Welte wrote:
On Sat, Aug 06, 2005 at 02:08:15AM +0400, Vladimir B. Savkin wrote:
I found that it really is NOTRACK who cause? bogus ICMP errors.
Good work tracking this down. I've seen reports of this before, but
never found the reason.
Well, this means that your ICMP errors need to
On Sat, Aug 06, 2005 at 11:13:37AM +0200, Harald Welte wrote:
> On Sat, Aug 06, 2005 at 02:08:15AM +0400, Vladimir B. Savkin wrote:
> > I found that it really is NOTRACK who cause? bogus ICMP errors.
>
> Well, this means that your ICMP errors need to be NAT'ed but they
> cannot, since the original
On Sat, Aug 06, 2005 at 02:08:15AM +0400, Vladimir B. Savkin wrote:
> I found that it really is NOTRACK who cause? bogus ICMP errors.
Well, this means that your ICMP errors need to be NAT'ed but they
cannot, since the original connection causing the ICMP error did not go
through connection trackin
On Fri, Aug 05, 2005 at 07:43:25PM +0200, Harald Welte wrote:
> On Wed, Aug 03, 2005 at 03:50:15PM +0400, Vladimir B. Savkin wrote:
> > Hello!
> >
> > When trying to upgrade a gateway from old 2.6.10-rc2 to
> > new 2.6.13-rc5, I noticed a flood of messages like
> > "172.16.12.1 sent an invalid IC
On Wed, Aug 03, 2005 at 03:50:15PM +0400, Vladimir B. Savkin wrote:
> Hello!
>
> When trying to upgrade a gateway from old 2.6.10-rc2 to
> new 2.6.13-rc5, I noticed a flood of messages like
> "172.16.12.1 sent an invalid ICMP type 11, code 0 error to a broadcast:
> 0.0.0.0"
> Source IP is always
Hello!
When trying to upgrade a gateway from old 2.6.10-rc2 to
new 2.6.13-rc5, I noticed a flood of messages like
"172.16.12.1 sent an invalid ICMP type 11, code 0 error to a broadcast:
0.0.0.0"
Source IP is always that of this gateway, destination IP is always 0.0.0.0.
Looks like it tries to se
20 matches
Mail list logo
