Mailing List Archive: An ip_conntrack / nat problem with kernel 2.4.17

An ip_conntrack / nat problem with kernel 2.4.17_mvl21

Jul 20, 2007, 1:50 AM

Post #1 of 3 (2171 views)

Hey everyone,

I'm using a version of the 2.4.17_mvl21 kernel (from MontaVista
originally) which was modified by Texas Instruments for their
additions of some hardware.

The problem I'm facing is this:
[computer A: 172.16.0.33] --> [LAN IP: 172.16.0.1 ...linuxbox... WAN
IP 172.17.1.4] -->[computer B: 172.17.1.44]
The situation is that a computer on the LAN side of the linux box
running that kernel with
an IP of say 172.16.0.33 (computer A) pings a computer behind the WAN
IP, say computer B with IP of 172.17.1.44
isn't getting an reply.
When I started wireshark on computer B to see what's going on I saw
that it receives icmp echo requests
from the IP address 172.16.0.33 and tries to reply back which is
ofcourse totally wrong as it's
unreachable and what should've happened is that it was supposed to see
a request from the WAN IP
172.17.1.4 and reply to that.

I can say that anything related to the actual configuration of the
NAT/Masquerading information
is irrelevant since it is working with a previous kernel version just fine.

That previous version we had of this kernel had a problem with
ip_conntrack or basically a nat problem and the guy who was dealing
with it before me "solved" it by overwriting some files from kernel
2.4.20 vanilla. Files like net/ipv4/netfilter/*
include/linux/netfilter_arp/* and include/linux/netfilter_ipv4 if I
can remember correctly.

Anyway, I can not do the same procedure with this new version of the
kernel they gave us because the guys at TI inserted some of their own
code into the networking stack which seems about dealing with qos and
some files have includes to ti_qos.h etc

I'm really looking for a lead on which files to look at exactly and what
should I be exactly looking for?

If anyone has any idea how to approach this or any leads
I'll appreciate that very much.

Thanks,
Lir.

Re: An ip_conntrack / nat problem with kernel 2.4.17_mvl21 [ In reply to ]

yasuyuki.kozakai at toshiba

Jul 20, 2007, 4:45 AM

Post #2 of 3 (2088 views)

Permalink

From: "liran tal" <liransgarage@gmail.com>
Date: Fri, 20 Jul 2007 10:50:24 +0200

> Hey everyone,
>
> I'm using a version of the 2.4.17_mvl21 kernel (from MontaVista
> originally) which was modified by Texas Instruments for their
> additions of some hardware.
>
> The problem I'm facing is this:
> [computer A: 172.16.0.33] --> [LAN IP: 172.16.0.1 ...linuxbox... WAN
> IP 172.17.1.4] -->[computer B: 172.17.1.44]
> The situation is that a computer on the LAN side of the linux box
> running that kernel with
> an IP of say 172.16.0.33 (computer A) pings a computer behind the WAN
> IP, say computer B with IP of 172.17.1.44
> isn't getting an reply.
> When I started wireshark on computer B to see what's going on I saw
> that it receives icmp echo requests
> from the IP address 172.16.0.33 and tries to reply back which is
> ofcourse totally wrong as it's
> unreachable and what should've happened is that it was supposed to see
> a request from the WAN IP
> 172.17.1.4 and reply to that.
>
> I can say that anything related to the actual configuration of the
> NAT/Masquerading information
> is irrelevant since it is working with a previous kernel version just fine.
>
> That previous version we had of this kernel had a problem with
> ip_conntrack or basically a nat problem and the guy who was dealing
> with it before me "solved" it by overwriting some files from kernel
> 2.4.20 vanilla. Files like net/ipv4/netfilter/*
> include/linux/netfilter_arp/* and include/linux/netfilter_ipv4 if I
> can remember correctly.
>
> Anyway, I can not do the same procedure with this new version of the
> kernel they gave us because the guys at TI inserted some of their own
> code into the networking stack which seems about dealing with qos and
> some files have includes to ti_qos.h etc
>
>
> I'm really looking for a lead on which files to look at exactly and what
> should I be exactly looking for?
>
> If anyone has any idea how to approach this or any leads
> I'll appreciate that very much.

I have no idea. But if I was you, I would try main line kernel 2.4.17 on
other machine if thre is no difference between them (maybe what you should
see are ip_conntrack_*.c and ip_nat_*.c in net/ipv4/netfilter), look for
changes at following if the kernel 2.4.17 has same problem,

http://linux.bkbits.net:8080/linux-2.4/
http://git.kernel.org/?p=linux/kernel/git/wtarreau/linux-2.4.git;a=summary

and try related fix. If the recent kernel (2.4.33) had same
problem, I would make a patch to fix or report it on this list.

We don't usually take care of distro's customized kernel, so I recommend
to ask Montavista guys or TI guys about details.

-- Yasuyuki Kozakai

Re: An ip_conntrack / nat problem with kernel 2.4.17_mvl21 [ In reply to ]

liransgarage at gmail

Jul 22, 2007, 5:02 AM

Post #3 of 3 (2082 views)

Permalink

Hey Yasuyuki,

Thanks for your attention and reply.
I haven't checked 2.4.17 but I doubt it's an actual problem with that
kernel version as this error is a show stopper and I doubt it would
have been released and so the only conclusion I have right now is that
TI guys have modified some code there
and screwed up things in the middle.

I have tried disabling some config options regarding their changes and other
things but still not much luck.

I really need something to go with here...
If you can help in any way I'd very much appreciate that.

Thanks,
Liran.

On 7/20/07, Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp> wrote:
> From: "liran tal" <liransgarage@gmail.com>
> Date: Fri, 20 Jul 2007 10:50:24 +0200
>
> > Hey everyone,
> >
> > I'm using a version of the 2.4.17_mvl21 kernel (from MontaVista
> > originally) which was modified by Texas Instruments for their
> > additions of some hardware.
> >
> > The problem I'm facing is this:
> > [computer A: 172.16.0.33] --> [LAN IP: 172.16.0.1 ...linuxbox... WAN
> > IP 172.17.1.4] -->[computer B: 172.17.1.44]
> > The situation is that a computer on the LAN side of the linux box
> > running that kernel with
> > an IP of say 172.16.0.33 (computer A) pings a computer behind the WAN
> > IP, say computer B with IP of 172.17.1.44
> > isn't getting an reply.
> > When I started wireshark on computer B to see what's going on I saw
> > that it receives icmp echo requests
> > from the IP address 172.16.0.33 and tries to reply back which is
> > ofcourse totally wrong as it's
> > unreachable and what should've happened is that it was supposed to see
> > a request from the WAN IP
> > 172.17.1.4 and reply to that.
> >
> > I can say that anything related to the actual configuration of the
> > NAT/Masquerading information
> > is irrelevant since it is working with a previous kernel version just fine.
> >
> > That previous version we had of this kernel had a problem with
> > ip_conntrack or basically a nat problem and the guy who was dealing
> > with it before me "solved" it by overwriting some files from kernel
> > 2.4.20 vanilla. Files like net/ipv4/netfilter/*
> > include/linux/netfilter_arp/* and include/linux/netfilter_ipv4 if I
> > can remember correctly.
> >
> > Anyway, I can not do the same procedure with this new version of the
> > kernel they gave us because the guys at TI inserted some of their own
> > code into the networking stack which seems about dealing with qos and
> > some files have includes to ti_qos.h etc
> >
> >
> > I'm really looking for a lead on which files to look at exactly and what
> > should I be exactly looking for?
> >
> > If anyone has any idea how to approach this or any leads
> > I'll appreciate that very much.
>
> I have no idea. But if I was you, I would try main line kernel 2.4.17 on
> other machine if thre is no difference between them (maybe what you should
> see are ip_conntrack_*.c and ip_nat_*.c in net/ipv4/netfilter), look for
> changes at following if the kernel 2.4.17 has same problem,
>
> http://linux.bkbits.net:8080/linux-2.4/
> http://git.kernel.org/?p=linux/kernel/git/wtarreau/linux-2.4.git;a=summary
>
> and try related fix. If the recent kernel (2.4.33) had same
> problem, I would make a patch to fix or report it on this list.
>
> We don't usually take care of distro's customized kernel, so I recommend
> to ask Montavista guys or TI guys about details.
>
> -- Yasuyuki Kozakai
>