* [PATCH v3] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones @ 2010-11-22 2:40 Kevin Cernekee 2010-11-22 7:52 ` Eric Dumazet 0 siblings, 1 reply; 6+ messages in thread From: Kevin Cernekee @ 2010-11-22 2:40 UTC (permalink / raw) To: Eric Dumazet, Patrick McHardy, David S. Miller, Alexey Kuznetsov, "Pekka Savola (ipv6)" <pek Cc: netfilter-devel, netfilter, coreteam, linux-kernel, netdev [v3: Only activate the new forced_dport logic if the IP matches, but the port does not. ] Most SIP devices use a source port of 5060/udp on SIP requests, so the response automatically comes back to port 5060: phone_ip:5060 -> proxy_ip:5060 REGISTER proxy_ip:5060 -> phone_ip:5060 100 Trying The newer Cisco IP phones, however, use a randomly chosen high source port for the SIP request but expect the response on port 5060: phone_ip:49173 -> proxy_ip:5060 REGISTER proxy_ip:5060 -> phone_ip:5060 100 Trying Standard Linux NAT, with or without nf_nat_sip, will send the reply back to port 49173, not 5060: phone_ip:49173 -> proxy_ip:5060 REGISTER proxy_ip:5060 -> phone_ip:49173 100 Trying But the phone is not listening on 49173, so it will never see the reply. This patch modifies nf_*_sip to work around this quirk by extracting the SIP response port from the Via: header, iff the source IP in the packet header matches the source IP in the SIP request. Signed-off-by: Kevin Cernekee <cernekee@gmail.com> --- include/linux/netfilter/nf_conntrack_sip.h | 3 +++ net/ipv4/netfilter/nf_nat_sip.c | 26 +++++++++++++++++++++++--- net/netfilter/nf_conntrack_sip.c | 17 +++++++++++++++++ 3 files changed, 43 insertions(+), 3 deletions(-) diff --git a/include/linux/netfilter/nf_conntrack_sip.h b/include/linux/netfilter/nf_conntrack_sip.h index 0ce91d5..feda699 100644 --- a/include/linux/netfilter/nf_conntrack_sip.h +++ b/include/linux/netfilter/nf_conntrack_sip.h @@ -2,12 +2,15 @@ #define __NF_CONNTRACK_SIP_H__ #ifdef __KERNEL__ +#include <linux/types.h> + #define SIP_PORT 5060 #define SIP_TIMEOUT 3600 struct nf_ct_sip_master { unsigned int register_cseq; unsigned int invite_cseq; + __be16 forced_dport; }; enum sip_expectation_classes { diff --git a/net/ipv4/netfilter/nf_nat_sip.c b/net/ipv4/netfilter/nf_nat_sip.c index e40cf78..e5856b0 100644 --- a/net/ipv4/netfilter/nf_nat_sip.c +++ b/net/ipv4/netfilter/nf_nat_sip.c @@ -73,6 +73,7 @@ static int map_addr(struct sk_buff *skb, unsigned int dataoff, enum ip_conntrack_info ctinfo; struct nf_conn *ct = nf_ct_get(skb, &ctinfo); enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo); + struct nf_conn_help *help = nfct_help(ct); char buffer[sizeof("nnn.nnn.nnn.nnn:nnnnn")]; unsigned int buflen; __be32 newaddr; @@ -85,7 +86,8 @@ static int map_addr(struct sk_buff *skb, unsigned int dataoff, } else if (ct->tuplehash[dir].tuple.dst.u3.ip == addr->ip && ct->tuplehash[dir].tuple.dst.u.udp.port == port) { newaddr = ct->tuplehash[!dir].tuple.src.u3.ip; - newport = ct->tuplehash[!dir].tuple.src.u.udp.port; + newport = help->help.ct_sip_info.forced_dport ? : + ct->tuplehash[!dir].tuple.src.u.udp.port; } else return 1; @@ -121,6 +123,7 @@ static unsigned int ip_nat_sip(struct sk_buff *skb, unsigned int dataoff, enum ip_conntrack_info ctinfo; struct nf_conn *ct = nf_ct_get(skb, &ctinfo); enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo); + struct nf_conn_help *help = nfct_help(ct); unsigned int coff, matchoff, matchlen; enum sip_header_types hdr; union nf_inet_addr addr; @@ -229,6 +232,20 @@ next: !map_sip_addr(skb, dataoff, dptr, datalen, SIP_HDR_TO)) return NF_DROP; + /* Mangle destination port for Cisco phones, then fix up checksums */ + if (dir == IP_CT_DIR_REPLY && help->help.ct_sip_info.forced_dport) { + struct udphdr *uh; + + if (!skb_make_writable(skb, skb->len)) + return NF_DROP; + + uh = (struct udphdr *)(skb->data + ip_hdrlen(skb)); + uh->dest = help->help.ct_sip_info.forced_dport; + + if (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, 0, 0, NULL, 0)) + return NF_DROP; + } + return NF_ACCEPT; } @@ -280,8 +297,10 @@ static unsigned int ip_nat_sip_expect(struct sk_buff *skb, unsigned int dataoff, enum ip_conntrack_info ctinfo; struct nf_conn *ct = nf_ct_get(skb, &ctinfo); enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo); + struct nf_conn_help *help = nfct_help(ct); __be32 newip; u_int16_t port; + __be16 srcport; char buffer[sizeof("nnn.nnn.nnn.nnn:nnnnn")]; unsigned buflen; @@ -294,8 +313,9 @@ static unsigned int ip_nat_sip_expect(struct sk_buff *skb, unsigned int dataoff, /* If the signalling port matches the connection's source port in the * original direction, try to use the destination port in the opposite * direction. */ - if (exp->tuple.dst.u.udp.port == - ct->tuplehash[dir].tuple.src.u.udp.port) + srcport = help->help.ct_sip_info.forced_dport ? : + ct->tuplehash[dir].tuple.src.u.udp.port; + if (exp->tuple.dst.u.udp.port == srcport) port = ntohs(ct->tuplehash[!dir].tuple.dst.u.udp.port); else port = ntohs(exp->tuple.dst.u.udp.port); diff --git a/net/netfilter/nf_conntrack_sip.c b/net/netfilter/nf_conntrack_sip.c index bcf47eb..776130d 100644 --- a/net/netfilter/nf_conntrack_sip.c +++ b/net/netfilter/nf_conntrack_sip.c @@ -1363,8 +1363,25 @@ static int process_sip_request(struct sk_buff *skb, unsigned int dataoff, { enum ip_conntrack_info ctinfo; struct nf_conn *ct = nf_ct_get(skb, &ctinfo); + struct nf_conn_help *help = nfct_help(ct); + enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo); unsigned int matchoff, matchlen; unsigned int cseq, i; + union nf_inet_addr addr; + __be16 port; + + /* Many Cisco IP phones use a high source port for SIP requests, but + * listen for the response on port 5060. If we are the local + * router for one of these phones, save the port number from the + * Via: header so that nf_nat_sip can redirect the responses to + * the correct port. + */ + if (ct_sip_parse_header_uri(ct, *dptr, NULL, *datalen, + SIP_HDR_VIA_UDP, NULL, &matchoff, + &matchlen, &addr, &port) > 0 && + port != ct->tuplehash[dir].tuple.src.u.udp.port && + nf_inet_addr_cmp(&addr, &ct->tuplehash[dir].tuple.src.u3)) + help->help.ct_sip_info.forced_dport = port; for (i = 0; i < ARRAY_SIZE(sip_handlers); i++) { const struct sip_handler *handler; -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v3] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones 2010-11-22 2:40 [PATCH v3] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones Kevin Cernekee @ 2010-11-22 7:52 ` Eric Dumazet 2012-12-17 0:17 ` David Woodhouse 0 siblings, 1 reply; 6+ messages in thread From: Eric Dumazet @ 2010-11-22 7:52 UTC (permalink / raw) To: Kevin Cernekee Cc: Patrick McHardy, David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI, netfilter-devel, netfilter, coreteam, linux-kernel, netdev Le dimanche 21 novembre 2010 à 18:40 -0800, Kevin Cernekee a écrit : > [v3: > Only activate the new forced_dport logic if the IP matches, but the > port does not. ] > > Most SIP devices use a source port of 5060/udp on SIP requests, so the > response automatically comes back to port 5060: > > phone_ip:5060 -> proxy_ip:5060 REGISTER > proxy_ip:5060 -> phone_ip:5060 100 Trying > > The newer Cisco IP phones, however, use a randomly chosen high source > port for the SIP request but expect the response on port 5060: > > phone_ip:49173 -> proxy_ip:5060 REGISTER > proxy_ip:5060 -> phone_ip:5060 100 Trying > > Standard Linux NAT, with or without nf_nat_sip, will send the reply back > to port 49173, not 5060: > > phone_ip:49173 -> proxy_ip:5060 REGISTER > proxy_ip:5060 -> phone_ip:49173 100 Trying > > But the phone is not listening on 49173, so it will never see the reply. > > This patch modifies nf_*_sip to work around this quirk by extracting > the SIP response port from the Via: header, iff the source IP in the > packet header matches the source IP in the SIP request. > > Signed-off-by: Kevin Cernekee <cernekee@gmail.com> > --- Thanks for doing this work Keven ! Acked-by: Eric Dumazet <eric.dumazet@gmail.com> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones 2010-11-22 7:52 ` Eric Dumazet @ 2012-12-17 0:17 ` David Woodhouse 2012-12-17 0:44 ` Pablo Neira Ayuso 0 siblings, 1 reply; 6+ messages in thread From: David Woodhouse @ 2012-12-17 0:17 UTC (permalink / raw) To: Eric Dumazet Cc: Kevin Cernekee, Patrick McHardy, David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI, netfilter-devel, netfilter, coreteam, linux-kernel, netdev [-- Attachment #1: Type: text/plain, Size: 6988 bytes --] On Mon, 2010-11-22 at 08:52 +0100, Eric Dumazet wrote: > Le dimanche 21 novembre 2010 à 18:40 -0800, Kevin Cernekee a écrit : > > [v3: > > Only activate the new forced_dport logic if the IP matches, but the > > port does not. ] > > > > Most SIP devices use a source port of 5060/udp on SIP requests, so the > > response automatically comes back to port 5060: > > > > phone_ip:5060 -> proxy_ip:5060 REGISTER > > proxy_ip:5060 -> phone_ip:5060 100 Trying > > > > The newer Cisco IP phones, however, use a randomly chosen high source > > port for the SIP request but expect the response on port 5060: > > > > phone_ip:49173 -> proxy_ip:5060 REGISTER > > proxy_ip:5060 -> phone_ip:5060 100 Trying > > > > Standard Linux NAT, with or without nf_nat_sip, will send the reply back > > to port 49173, not 5060: > > > > phone_ip:49173 -> proxy_ip:5060 REGISTER > > proxy_ip:5060 -> phone_ip:49173 100 Trying > > > > But the phone is not listening on 49173, so it will never see the reply. > > > > This patch modifies nf_*_sip to work around this quirk by extracting > > the SIP response port from the Via: header, iff the source IP in the > > packet header matches the source IP in the SIP request. > > > > Signed-off-by: Kevin Cernekee <cernekee@gmail.com> > > --- > > Thanks for doing this work Keven ! > > Acked-by: Eric Dumazet <eric.dumazet@gmail.com> What happened to this? OpenWRT is still carrying it, and it broke in 3.7. Here's a completely untested update... + if (!skb_make_writable(skb, skb->len)) + return NF_DROP; + -+ uh = (struct udphdr *)(skb->data + ip_hdrlen(skb)); ++ uh = (void *)skb->data + protoff; + uh->dest = ct_sip_info->forced_dport; + -+ if (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, 0, 0, NULL, 0)) ++ if (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, 0, 0, NU + return NF_DROP; + } + return NF_ACCEPT; } diff --git a/include/linux/netfilter/nf_conntrack_sip.h b/include/linux/netfilter/nf_conntrack_sip.h index 387bdd0..ba7f571 100644 --- a/include/linux/netfilter/nf_conntrack_sip.h +++ b/include/linux/netfilter/nf_conntrack_sip.h @@ -4,12 +4,15 @@ #include <net/netfilter/nf_conntrack_expect.h> +#include <linux/types.h> + #define SIP_PORT 5060 #define SIP_TIMEOUT 3600 struct nf_ct_sip_master { unsigned int register_cseq; unsigned int invite_cseq; + __be16 forced_dport; }; enum sip_expectation_classes { diff --git a/net/netfilter/nf_conntrack_sip.c b/net/netfilter/nf_conntrack_sip.c index df8f4f2..72a67bb 100644 --- a/net/netfilter/nf_conntrack_sip.c +++ b/net/netfilter/nf_conntrack_sip.c @@ -1440,8 +1440,25 @@ static int process_sip_request(struct sk_buff *skb, unsigned int protoff, { enum ip_conntrack_info ctinfo; struct nf_conn *ct = nf_ct_get(skb, &ctinfo); + struct nf_ct_sip_master *ct_sip_info = nfct_help_data(ct); + enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo); unsigned int matchoff, matchlen; unsigned int cseq, i; + union nf_inet_addr addr; + __be16 port; + + /* Many Cisco IP phones use a high source port for SIP requests, but + * listen for the response on port 5060. If we are the local + * router for one of these phones, save the port number from the + * Via: header so that nf_nat_sip can redirect the responses to + * the correct port. + */ + if (ct_sip_parse_header_uri(ct, *dptr, NULL, *datalen, + SIP_HDR_VIA_UDP, NULL, &matchoff, + &matchlen, &addr, &port) > 0 && + port != ct->tuplehash[dir].tuple.src.u.udp.port && + nf_inet_addr_cmp(&addr, &ct->tuplehash[dir].tuple.src.u3)) + ct_sip_info->forced_dport = port; for (i = 0; i < ARRAY_SIZE(sip_handlers); i++) { const struct sip_handler *handler; diff --git a/net/netfilter/nf_nat_sip.c b/net/netfilter/nf_nat_sip.c index 16303c7..552e270 100644 --- a/net/netfilter/nf_nat_sip.c +++ b/net/netfilter/nf_nat_sip.c @@ -95,6 +95,7 @@ static int map_addr(struct sk_buff *skb, unsigned int protoff, enum ip_conntrack_info ctinfo; struct nf_conn *ct = nf_ct_get(skb, &ctinfo); enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo); + struct nf_ct_sip_master *ct_sip_info = nfct_help_data(ct); char buffer[INET6_ADDRSTRLEN + sizeof("[]:nnnnn")]; unsigned int buflen; union nf_inet_addr newaddr; @@ -107,7 +108,8 @@ static int map_addr(struct sk_buff *skb, unsigned int protoff, } else if (nf_inet_addr_cmp(&ct->tuplehash[dir].tuple.dst.u3, addr) && ct->tuplehash[dir].tuple.dst.u.udp.port == port) { newaddr = ct->tuplehash[!dir].tuple.src.u3; - newport = ct->tuplehash[!dir].tuple.src.u.udp.port; + newport = ct_sip_info->forced_dport ? ct_sip_info->forced_dport : + ct->tuplehash[!dir].tuple.src.u.udp.port; } else return 1; @@ -144,6 +146,7 @@ static unsigned int nf_nat_sip(struct sk_buff *skb, unsigned int protoff, enum ip_conntrack_info ctinfo; struct nf_conn *ct = nf_ct_get(skb, &ctinfo); enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo); + struct nf_ct_sip_master *ct_sip_info = nfct_help_data(ct); unsigned int coff, matchoff, matchlen; enum sip_header_types hdr; union nf_inet_addr addr; @@ -258,6 +261,20 @@ next: !map_sip_addr(skb, protoff, dataoff, dptr, datalen, SIP_HDR_TO)) return NF_DROP; + /* Mangle destination port for Cisco phones, then fix up checksums */ + if (dir == IP_CT_DIR_REPLY && ct_sip_info->forced_dport) { + struct udphdr *uh; + + if (!skb_make_writable(skb, skb->len)) + return NF_DROP; + + uh = (void *)skb->data + protoff; + uh->dest = ct_sip_info->forced_dport; + + if (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, 0, 0, NULL, 0)) + return NF_DROP; + } + return NF_ACCEPT; } @@ -311,8 +328,10 @@ static unsigned int nf_nat_sip_expect(struct sk_buff *skb, unsigned int protoff, enum ip_conntrack_info ctinfo; struct nf_conn *ct = nf_ct_get(skb, &ctinfo); enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo); + struct nf_ct_sip_master *ct_sip_info = nfct_help_data(ct); union nf_inet_addr newaddr; u_int16_t port; + __be16 srcport; char buffer[INET6_ADDRSTRLEN + sizeof("[]:nnnnn")]; unsigned int buflen; @@ -326,8 +345,9 @@ static unsigned int nf_nat_sip_expect(struct sk_buff *skb, unsigned int protoff, /* If the signalling port matches the connection's source port in the * original direction, try to use the destination port in the opposite * direction. */ - if (exp->tuple.dst.u.udp.port == - ct->tuplehash[dir].tuple.src.u.udp.port) + srcport = ct_sip_info->forced_dport ? ct_sip_info->forced_dport : + ct->tuplehash[dir].tuple.src.u.udp.port; + if (exp->tuple.dst.u.udp.port == srcport) port = ntohs(ct->tuplehash[!dir].tuple.dst.u.udp.port); else port = ntohs(exp->tuple.dst.u.udp.port); -- dwmw2 [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 6171 bytes --] ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v3] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones 2012-12-17 0:17 ` David Woodhouse @ 2012-12-17 0:44 ` Pablo Neira Ayuso 2012-12-17 7:26 ` Kevin Cernekee 0 siblings, 1 reply; 6+ messages in thread From: Pablo Neira Ayuso @ 2012-12-17 0:44 UTC (permalink / raw) To: David Woodhouse Cc: Eric Dumazet, Kevin Cernekee, Patrick McHardy, David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI, netfilter-devel, netfilter, coreteam, linux-kernel, netdev Hi David, On Mon, Dec 17, 2012 at 12:17:21AM +0000, David Woodhouse wrote: > On Mon, 2010-11-22 at 08:52 +0100, Eric Dumazet wrote: > > Le dimanche 21 novembre 2010 à 18:40 -0800, Kevin Cernekee a écrit : > > > [v3: > > > Only activate the new forced_dport logic if the IP matches, but the > > > port does not. ] > > > > > > Most SIP devices use a source port of 5060/udp on SIP requests, so the > > > response automatically comes back to port 5060: > > > > > > phone_ip:5060 -> proxy_ip:5060 REGISTER > > > proxy_ip:5060 -> phone_ip:5060 100 Trying > > > > > > The newer Cisco IP phones, however, use a randomly chosen high source > > > port for the SIP request but expect the response on port 5060: > > > > > > phone_ip:49173 -> proxy_ip:5060 REGISTER > > > proxy_ip:5060 -> phone_ip:5060 100 Trying > > > > > > Standard Linux NAT, with or without nf_nat_sip, will send the reply back > > > to port 49173, not 5060: > > > > > > phone_ip:49173 -> proxy_ip:5060 REGISTER > > > proxy_ip:5060 -> phone_ip:49173 100 Trying > > > > > > But the phone is not listening on 49173, so it will never see the reply. > > > > > > This patch modifies nf_*_sip to work around this quirk by extracting > > > the SIP response port from the Via: header, iff the source IP in the > > > packet header matches the source IP in the SIP request. > > > > > > Signed-off-by: Kevin Cernekee <cernekee@gmail.com> > > > --- > > > > Thanks for doing this work Keven ! > > > > Acked-by: Eric Dumazet <eric.dumazet@gmail.com> > > What happened to this? OpenWRT is still carrying it, and it broke in > 3.7. Here's a completely untested update... I requested Kevin to resend a new version based on the current kernel tree while spinning on old pending patches since I have no access to that hardware, but no luck. So I'll review this and, since OpenWRT is carrying, I guess we can get this into net-next merge window. Thanks for the reminder. -- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones 2012-12-17 0:44 ` Pablo Neira Ayuso @ 2012-12-17 7:26 ` Kevin Cernekee 2012-12-17 9:55 ` Pablo Neira Ayuso 0 siblings, 1 reply; 6+ messages in thread From: Kevin Cernekee @ 2012-12-17 7:26 UTC (permalink / raw) To: Pablo Neira Ayuso Cc: David Woodhouse, Eric Dumazet, Patrick McHardy, David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI, netfilter-devel, netfilter, coreteam, linux-kernel, netdev On Sun, Dec 16, 2012 at 4:44 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote: >> What happened to this? OpenWRT is still carrying it, and it broke in >> 3.7. Here's a completely untested update... > > I requested Kevin to resend a new version based on the current kernel > tree while spinning on old pending patches since I have no access to > that hardware, but no luck. > > So I'll review this and, since OpenWRT is carrying, I guess we can get > this into net-next merge window. Sorry, been putting it off since the OpenWRT version has worked flawlessly... I just reassembled my test rig and I'll get you a working patch this week. Is it OK to use git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git as the baseline? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones 2012-12-17 7:26 ` Kevin Cernekee @ 2012-12-17 9:55 ` Pablo Neira Ayuso 0 siblings, 0 replies; 6+ messages in thread From: Pablo Neira Ayuso @ 2012-12-17 9:55 UTC (permalink / raw) To: Kevin Cernekee Cc: David Woodhouse, Eric Dumazet, Patrick McHardy, David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI, netfilter-devel, netfilter, coreteam, linux-kernel, netdev On Sun, Dec 16, 2012 at 11:26:31PM -0800, Kevin Cernekee wrote: > On Sun, Dec 16, 2012 at 4:44 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote: > >> What happened to this? OpenWRT is still carrying it, and it broke in > >> 3.7. Here's a completely untested update... > > > > I requested Kevin to resend a new version based on the current kernel > > tree while spinning on old pending patches since I have no access to > > that hardware, but no luck. > > > > So I'll review this and, since OpenWRT is carrying, I guess we can get > > this into net-next merge window. > > Sorry, been putting it off since the OpenWRT version has worked flawlessly... > > I just reassembled my test rig and I'll get you a working patch this week. > > Is it OK to use > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git as the > baseline? That's fine in this case because no recent changes went into that code, but better if you use the netfilter next tree: git://1984.lsi.us.es/nf-next Thanks Kevin. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-12-17 9:55 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-11-22 2:40 [PATCH v3] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones Kevin Cernekee 2010-11-22 7:52 ` Eric Dumazet 2012-12-17 0:17 ` David Woodhouse 2012-12-17 0:44 ` Pablo Neira Ayuso 2012-12-17 7:26 ` Kevin Cernekee 2012-12-17 9:55 ` Pablo Neira Ayuso
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).