ip_nat_mangle_udp_packet problems

ip_nat_mangle_udp_packet problems

[Christian Hentschel]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

Hi, 
	i hope someone could answer this problem i'm experimenting. I'm writing
a SIP/RTP conntrack/NAT helper, and i need to mangle packets multiple
times, since there are lots of fields to be mangled.
	I'm using new conntrack/nat framework (>2.6.11) and the way i took to
do it is causing me some problems.
	Basically, i just look for string into the packet, mangle it and call
ip_nat_mangle_udp_packet(). The problem is when i try to search the
nexts strings, i get the wrong offsets. 
I saw ip_nat_mangle_udp_packet() does not do it manipulation
immediatelly. Please could someone explain this ?.
Is there a way to "sync" so have the skbuff mangled immediately?
is multiple manips of the packets supported in new framework?. 

Thanks in advance. 

-- 
Christian Hentschel <chentschel@arnet.com.ar>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip_nat_mangle_udp_packet problems

[Patrick McHardy]

Christian Hentschel wrote:
> Hi, 
> 	i hope someone could answer this problem i'm experimenting. I'm writing
> a SIP/RTP conntrack/NAT helper, and i need to mangle packets multiple
> times, since there are lots of fields to be mangled.
> 	I'm using new conntrack/nat framework (>2.6.11) and the way i took to
> do it is causing me some problems.
> 	Basically, i just look for string into the packet, mangle it and call
> ip_nat_mangle_udp_packet(). The problem is when i try to search the
> nexts strings, i get the wrong offsets. 
> I saw ip_nat_mangle_udp_packet() does not do it manipulation
> immediatelly. Please could someone explain this ?.

enlarge_skb() called from ip_nat_mangle_udp_packet() might replace the
packet if it doesn't fit. You need to reload all pointers to the skb
after calling ip_nat_mangle_udp_packet().

Regards
Patrick

Re: ip_nat_mangle_udp_packet problems

[Christian Hentschel]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

On Fri, 2005-05-06 at 18:24 +0200, Patrick McHardy wrote:
> Christian Hentschel wrote:
> > Hi, 
> > 	i hope someone could answer this problem i'm experimenting. I'm writing
> > a SIP/RTP conntrack/NAT helper, and i need to mangle packets multiple
> > times, since there are lots of fields to be mangled.
> > 	I'm using new conntrack/nat framework (>2.6.11) and the way i took to
> > do it is causing me some problems.
> > 	Basically, i just look for string into the packet, mangle it and call
> > ip_nat_mangle_udp_packet(). The problem is when i try to search the
> > nexts strings, i get the wrong offsets. 
> > I saw ip_nat_mangle_udp_packet() does not do it manipulation
> > immediatelly. Please could someone explain this ?.
> 
> enlarge_skb() called from ip_nat_mangle_udp_packet() might replace the
> packet if it doesn't fit. You need to reload all pointers to the skb
> after calling ip_nat_mangle_udp_packet().

Hi, well first thanks for answering my problem. 
What i see in enlarge_skb() is that if packet is larger than 65536 it
does as u said a copy. But i'm mangling <1024bytes packets, and after
mangling searching from the start of the paiload. This is
(*pskb)->nh.iph->ihl*4 + sizeof(struct udphdr).

I see that enlarge_skb() does the "reload" of the pointer to pskb,
pointing it to the enlarged skbuff. This is what u meant?

        kfree_skb(*pskb);
        *pskb = nskb;
        return 1;

what is happening is really obscure for me.

Thanks in advance. 
Christian.

-- 
Christian Hentschel <chentschel@arnet.com.ar>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip_nat_mangle_udp_packet problems

[Patrick McHardy]

Christian Hentschel wrote:
> What i see in enlarge_skb() is that if packet is larger than 65536 it
> does as u said a copy.

No, it drops it if it gets this large. skb_copy_expand(), as it name
implies, copies the packet to a new one with more room.

> I see that enlarge_skb() does the "reload" of the pointer to pskb,
> pointing it to the enlarged skbuff. This is what u meant?
> 
>         kfree_skb(*pskb);
>         *pskb = nskb;
>         return 1;

Not really. What I meant is that if you have something like this before
the call to ip_nat_mangle_udp_packet():

struct udphdr *uh = (void *)(*pskb)->nh.iph + (*pskb)->nh.iph->ihl*4;

then you need to reload the pointer after the call like this:

uh = (void *)(*pskb)->nh.iph + (*pskb)->nh.iph->ihl*4;

otherwise it might point to the old and already freed skb.

> what is happening is really obscure for me.

Just post your code if this doesn't help.

Regards
Patrick

Re: ip_nat_mangle_udp_packet problems

[Christian Hentschel]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

On Fri, 2005-05-06 at 20:36 +0200, Patrick McHardy wrote:
> Christian Hentschel wrote:
> > What i see in enlarge_skb() is that if packet is larger than 65536 it
> > does as u said a copy.
> 
> No, it drops it if it gets this large. skb_copy_expand(), as it name
> implies, copies the packet to a new one with more room.

:).. sorry i didn't see thee return. 

> > I see that enlarge_skb() does the "reload" of the pointer to pskb,
> > pointing it to the enlarged skbuff. This is what u meant?
> > 
> >         kfree_skb(*pskb);
> >         *pskb = nskb;
> >         return 1;
> 
> Not really. What I meant is that if you have something like this before
> the call to ip_nat_mangle_udp_packet():
> 
> struct udphdr *uh = (void *)(*pskb)->nh.iph + (*pskb)->nh.iph->ihl*4;
> 
> then you need to reload the pointer after the call like this:
> 
> uh = (void *)(*pskb)->nh.iph + (*pskb)->nh.iph->ihl*4;
> 
> otherwise it might point to the old and already freed skb.

Well, this helps me a lot!!

> Just post your code if this doesn't help.

Thanks a lot again!. 

-- 
Christian Hentschel <chentschel@arnet.com.ar>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]