Hi Pablo, Please find my comments below.
> On Thu, May 14, 2019 at 06:18PM, Pablo Neira Ayuso <pa...@netfilter.org> > wrote: > Hi Xiao, > > On Tue, May 14, 2019 at 03:45:13PM +0800, 肖瑞珠 wrote: > > Hi Pablo, > > > > Thanks very much for your reply. > > > > >On Thu, May 13, 2019 at 07:26PM, Pablo Neira Ayuso > > ><pa...@netfilter.org> wrote: > > > > > >I wonder if we can handle this from __nf_ct_expect_check() itself. > > > > > >We could just check if master mismatches, then return -EALREADY from > > >there? > > > > > >Similar to 876c27314ce51, but catch the master mismatches case. > > > > Thanks for your proposal. It is a neater solution. > OK, thanks for exploring this path and confirming this works! > > Still one more question before we go: I wonder if we should enable > this through flag, eg. extend nf_ct_expect_related() to take a flag > that NFCT_EXP_F_MASTER_MISMATCH. > > This would change the behaviour for the other existing helpers, which > would prevent them from creating expectations with the same tuple from > different master conntracks. > > So I would just turn on this for SIP unless there is some reasoning > here that turning it for all existing helpers is fine. Yes, please feel free to add the flag NFCT_EXP_F_MASTER_MISMATCH. It will minimize the impact on other helpers. Thanks. > > One more comment below. > > > Please find the patch updated accordingly below. > > For some reason this patch is not showing in patchwork: > > https://patchwork.ozlabs.org/project/netfilter-devel/list/ > > Would you resubmit via git send-mail? > > Thanks. Sorry, the network for using 'git send-mail' broke and the mail was sent via gui web. This time it is submitted via git send-mail. Please don't hesitate to let me know if still any problem. Please find the patch v4 below. When conntracks change during a dialog, SDP messages may be sent from different conntracks to establish expects with identical tuples. In this case expects conflict may be detected for the 2nd SDP message and end up with a process failure. The fixing here is to reuse an existing expect who has the same tuple for a different conntrack if any. Here are two scenarios for the case. 1) SERVER CPE | INVITE SDP | 5060 |<----------------------|5060 | 100 Trying | 5060 |---------------------->|5060 | 183 SDP | 5060 |---------------------->|5060 ===> Conntrack 1 | PRACK | 50601 |<----------------------|5060 | 200 OK (PRACK) | 50601 |---------------------->|5060 | 200 OK (INVITE) | 5060 |---------------------->|5060 | ACK | 50601 |<----------------------|5060 | | |<--- RTP stream ------>| | | | INVITE SDP (t38) | 50601 |---------------------->|5060 ===> Conntrack 2 With a certain configuration in the CPE, SIP messages "183 with SDP" and "re-INVITE with SDP t38" will go through the sip helper to create expects for RTP and RTCP. It is okay to create RTP and RTCP expects for "183", whose master connection source port is 5060, and destination port is 5060. In the "183" message, port in Contact header changes to 50601 (from the original 5060). So the following requests e.g. PRACK and ACK are sent to port 50601. It is a different conntrack (let call Conntrack 2) from the original INVITE (let call Conntrack 1) due to the port difference. In this example, after the call is established, there is RTP stream but no RTCP stream for Conntrack 1, so the RTP expect created upon "183" is cleared, and RTCP expect created for Conntrack 1 retains. When "re-INVITE with SDP t38" arrives to create RTP&RTCP expects, current ALG implementation will call nf_ct_expect_related() for RTP and RTCP. The expects tuples are identical to those for Conntrack 1. RTP expect for Conntrack 2 succeeds in creation as the one for Conntrack 1 has been removed. RTCP expect for Conntrack 2 fails in creation because it has idential tuples and 'conflict' with the one retained for Conntrack 1. And then result in a failure in processing of the re-INVITE. 2) SERVER A CPE | REGISTER | 5060 |<------------------| 5060 ==> CT1 | 200 | 5060 |------------------>| 5060 | | | INVITE SDP(1) | 5060 |<------------------| 5060 | 300(multi choice) | 5060 |------------------>| 5060 SERVER B | ACK | 5060 |<------------------| 5060 | INVITE SDP(2) | 5060 |-------------------->| 5060 ==> CT2 | 100 | 5060 |<--------------------| 5060 | 200(contact changes)| 5060 |<--------------------| 5060 | ACK | 5060 |-------------------->| 50601 ==> CT3 | | |<--- RTP stream ---->| | | | BYE | 5060 |<--------------------| 50601 | 200 | 5060 |-------------------->| 50601 | INVITE SDP(3) | 5060 |<------------------| 5060 ==> CT1 CPE sends an INVITE request(1) to Server A, and creates a RTP&RTCP expect pair for this Conntrack 1 (CT1). Server A responds 300 to redirect to Server B. The RTP&RTCP expect pairs created on CT1 are removed upon 300 response. CPE sends the INVITE request(2) to Server B, and creates an expect pair for the new conntrack (due to destination address difference), let call CT2. Server B changes the port to 50601 in 200 OK response, and the following requests ACK and BYE from CPE are sent to 50601. The call is established. There is RTP stream and no RTCP stream. So RTP expect is removed and RTCP expect for CT2 retains. As BYE request is sent from port 50601, it is another conntrack, let call CT3, different from CT2 due to the port difference. So the BYE request will not remove the RTCP expect for CT2. Then another outgoing call is made, with the same RTP port being used (not definitely but possibly). CPE firstly sends the INVITE request(3) to Server A, and tries to create a RTP&RTCP expect pairs for this CT1. In current ALG implementation, the RTCP expect for CT1 fails in creation because it 'conflicts' with the residual one for CT2. As a result the INVITE request fails to send. Signed-off-by: xiao ruizhu <katrina.xia...@gmail.com> --- Changes in v4: - take Pablo's proposal to handle checking in __nf_ct_expect_check(). Changes in v3: - take Pablo's advice about the comments, nf_conntrack_expect_lock and nf_ct_sip_expect_exists() - change the policy to reuse the exising expect(s) instead of removal then recreation, to avoid CPU cycle waste Changes in v2: - add a comment on release_conflicting_expect functionality - move local variable errp to the beginning of the block v1: - original patch --- net/netfilter/nf_conntrack_expect.c | 6 +++--- net/netfilter/nf_conntrack_sip.c | 2 ++ 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/net/netfilter/nf_conntrack_expect.c b/net/netfilter/nf_conntrack_expect.c index 334d6e5..bfc7936 100644 --- a/net/netfilter/nf_conntrack_expect.c +++ b/net/netfilter/nf_conntrack_expect.c @@ -252,8 +252,7 @@ static inline int expect_clash(const struct nf_conntrack_expect *a, static inline int expect_matches(const struct nf_conntrack_expect *a, const struct nf_conntrack_expect *b) { - return a->master == b->master && - nf_ct_tuple_equal(&a->tuple, &b->tuple) && + return nf_ct_tuple_equal(&a->tuple, &b->tuple) && nf_ct_tuple_mask_equal(&a->mask, &b->mask) && net_eq(nf_ct_net(a->master), nf_ct_net(b->master)) && nf_ct_zone_equal_any(a->master, nf_ct_zone(b->master)); @@ -421,7 +420,8 @@ static inline int __nf_ct_expect_check(struct nf_conntrack_expect *expect) h = nf_ct_expect_dst_hash(net, &expect->tuple); hlist_for_each_entry_safe(i, next, &nf_ct_expect_hash[h], hnode) { if (expect_matches(i, expect)) { - if (i->class != expect->class) + if (i->class != expect->class || + i->master != expect->master) return -EALREADY; if (nf_ct_remove_expect(i)) diff --git a/net/netfilter/nf_conntrack_sip.c b/net/netfilter/nf_conntrack_sip.c index f067c6b..3262fd9 100644 --- a/net/netfilter/nf_conntrack_sip.c +++ b/net/netfilter/nf_conntrack_sip.c @@ -983,6 +983,8 @@ static int set_expected_rtp_rtcp(struct sk_buff *skb, unsigned int protoff, /* -EALREADY handling works around end-points that send * SDP messages with identical port but different media type, * we pretend expectation was set up. + * It also works in the case that SDP messages are sent with + * identical expect tuples but for different master conntracks. */ int errp = nf_ct_expect_related(rtp_exp); -- 1.9.1
