All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Florian Fuessl" <flo@degnet.de>
To: <netfilter-devel@vger.kernel.org>
Cc: "'Florian Fuessl'" <flo@degnet.de>
Subject: RE: T.38 FAX support via nf_nat_sip,nf_conntrack_sip
Date: Thu, 1 Oct 2009 17:48:19 +0200	[thread overview]
Message-ID: <003201ca42ae$998651e0$cc92f5a0$@de> (raw)
In-Reply-To: <002401ca405e$91c4ae90$b54e0bb0$@de>

I've an update regarding this issue:

According to my packet dumps the nf_conntrack_sip.c function:

static int process_sdp(struct sk_buff *skb,
                       const char **dptr, unsigned int *datalen,
                       unsigned int cseq)
{
[...]
        /* Update session connection and owner addresses */
        nf_nat_sdp_session = rcu_dereference(nf_nat_sdp_session_hook);
        if (nf_nat_sdp_session && ct->status & IPS_NAT_MASK)
                ret = nf_nat_sdp_session(skb, dptr, sdpoff, datalen,
&rtp_addr);

        if (ret == NF_ACCEPT && i > 0)
                help->help.ct_sip_info.invite_cseq = cseq;

        return ret;
}

... seems to rewrite the SIP/SDP (IN IP4) owner address and connection
address with garbage IP data on REINVITE packets sourcing from NAT outbound
to NAT inbound.

For example:
REINVITE packet sourcing from NAT outbound with connection information:
SIP Call IN IP4 212.77.188.67
... will be rewritten by the garbage IP address:
SIP Call IN IP4 128.41.188.128

Should this information not only be rewritten for packets sourcing from NAT
inbound to NAT outbound? 
What information does nf_nat_sip,nf_conntrack_sip read in order to determine
the garbage IP? Is this maybe a security (buffer) problem, too?

Sorry I'm no coder, so any help is very welcome :)

-Florian

> -----Original Message-----
> From: netfilter-devel-owner@vger.kernel.org [mailto:netfilter-devel-
> owner@vger.kernel.org] On Behalf Of Florian Fuessl
> Sent: Monday, September 28, 2009 7:10 PM
> To: netfilter-devel@vger.kernel.org
> Subject: T.38 FAX support via nf_nat_sip,nf_conntrack_sip
> 
> Hi,
> 
> T.38 FAX support via nf_nat_sip,nf_conntraack_sip does currently not
> seem to
> work, because the REINVITE for the codec change is not handled
> correctly at
> the moment (Figure: Fax Pass-Through and Call Flow diagram i.e. at
> http://docwiki.cisco.com/wiki/Cisco_IOS_Voice_Troubleshooting_and_Monit
> oring
> _--_Fax_Call_Flow )
> 
> Do you have an idea how to patch this problem?
> 
> -Florian
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-
> devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


      reply	other threads:[~2009-10-01 15:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-28 17:10 T.38 FAX support via nf_nat_sip,nf_conntrack_sip Florian Fuessl
2009-10-01 15:48 ` Florian Fuessl [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='003201ca42ae$998651e0$cc92f5a0$@de' \
    --to=flo@degnet.de \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.