I got my setup working again. Below is the patch that I had to include on
top of your patch. The first chunk was not really necessary, but I think
it is more correct to include it. The idea behind it is that DNAT of the
the RTP session is only necessary if the SIP session has been SNATed. The
second chunk adds some headers that must be processed as they contain SDP
information in my case.
Regards,
Jerome
--- linux-2.6.21/net/ipv4/netfilter/nf_nat_sip.c 2007-06-16 12:14:42.000000000 +0200
+++ linux-2.6.21.new/net/ipv4/netfilter/nf_nat_sip.c 2007-06-16 12:04:07.000000000 +0200
@@ -259,7 +259,11 @@
DEBUGP("ip_nat_sdp():\n");
/* Connection will come from reply */
- newip = ct->tuplehash[!dir].tuple.dst.u3.ip;
+ if (ct->tuplehash[dir].tuple.src.u3.ip ==
+ ct->tuplehash[!dir].tuple.dst.u3.ip)
+ newip = exp->tuple.dst.u3.ip;
+ else
+ newip = ct->tuplehash[!dir].tuple.dst.u3.ip;
exp->saved_ip = exp->tuple.dst.u3.ip;
exp->tuple.dst.u3.ip = newip;
--- linux-2.6.21/net/netfilter/nf_conntrack_sip.c 2007-04-26 05:08:32.000000000 +0200
+++ linux-2.6.21.new/net/netfilter/nf_conntrack_sip.c 2007-06-16 11:16:02.000000000 +0200
@@ -442,6 +442,9 @@
/* RTP info only in some SDP pkts */
if (memcmp(dptr, "INVITE", sizeof("INVITE") - 1) != 0 &&
+ memcmp(dptr, "UPDATE", sizeof("UPDATE") - 1) != 0 &&
+ memcmp(dptr, "SIP/2.0 180", sizeof("SIP/2.0 180") - 1) != 0 &&
+ memcmp(dptr, "SIP/2.0 183", sizeof("SIP/2.0 183") - 1) != 0 &&
memcmp(dptr, "SIP/2.0 200", sizeof("SIP/2.0 200") - 1) != 0) {
goto out;
}
On Thu, 14 Jun 2007, Herbert Xu wrote:
On Thu, Jun 14, 2007 at 02:32:56PM +0200, Jerome Borsboom wrote:
Forgive me if I'm wrong, but doesn't the line below, which is in the
set_expected_rtp function, expect an RTP-connection which originates from
ct->tuplehash[!dir].tuple.src.u3 which is the IP-address of the SIP
control connection server in the case that the client sends a SIP packet
to the server?
Yes you're quite right. As you correctly note below, normally the
client would use the same IP address for both SIP and RTP and
therefore the client's first RTP packet would allow both RTP
directions to work.
I am not an expert in the netfilter code, but is it possible that your
client starts to send an RTP-stream to the server and hence generates a
conntrack entry that enables the server to send an RTP-stream back to
the client?
The only scenario where it would break is if you had two servers
talking to each other through NAT and both of them use different
addresses for RTP.
This is indeed a case which the current code does not handle.
However, I don't think we should handle it by accepting an RTP packet
from any address as we have the information available to do better
than that.
We should correlate the RTP addresses in the SIP packets and setup
a correct expectation once both are received.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
