16 Jul, 2019
1 commit
-
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
| 183 SDP |
5060 |---------------------->|5060 ===> Conntrack 1
| PRACK |
50601 ||5060
| 200 OK (INVITE) |
5060 |---------------------->|5060
| ACK |
50601 ||
| |
| INVITE SDP (t38) |
50601 |---------------------->|5060 ===> Conntrack 2With 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 | CT1
| 200 |
5060 |------------------>| 5060
| |
| INVITE SDP(1) |
5060 || 5060 SERVER B
| ACK |
5060 || 5060 ==> CT2
| 100 |
5060 || 50601 ==> CT3
| |
||
| |
| BYE |
5060 || 50601
| INVITE SDP(3) |
5060 | CT1CPE 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
Signed-off-by: Pablo Neira Ayuso
22 Jun, 2019
1 commit
-
Minor SPDX change conflict.
Signed-off-by: David S. Miller
19 Jun, 2019
1 commit
-
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundationthis program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Enrico Weigelt
Reviewed-by: Kate Stewart
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman
01 Jun, 2019
1 commit
-
.. so skb_make_writable can be removed soon.
Signed-off-by: Florian Westphal
Signed-off-by: Pablo Neira Ayuso
30 Apr, 2019
2 commits
-
Register amanda, ftp, irc, sip and tftp NAT helpers.
Signed-off-by: Flavio Leitner
Signed-off-by: Pablo Neira Ayuso -
Each NAT helper creates a module alias which follows a pattern.
Use macros for consistency.Signed-off-by: Flavio Leitner
Signed-off-by: Pablo Neira Ayuso
18 Dec, 2018
1 commit
-
Each media stream negotiation between 2 SIP peers will trigger creation
of 4 different expectations (2 RTP and 2 RTCP):
- INVITE will create expectations for the media packets sent by the
called peer
- reply to the INVITE will create expectations for media packets sent
by the callerThe dport used by these expectations usually match the ones selected
by the SIP peers, but they might get translated due to conflicts with
another expectation. When such event occur, it is important to do
this translation in both directions, dport translation on the receiving
path and sport translation on the sending path.This commit fixes the sport translation when the peer requiring it is
also the one that starts the media stream. In this scenario, first media
stream packet is forwarded from LAN to WAN and will rely on
nf_nat_sip_expected() to do the necessary sport translation. However, the
expectation matched by this packet does not contain the necessary information
for doing SNAT, this data being stored in the paired expectation created by
the sender's SIP message (INVITE or reply to it).Signed-off-by: Alin Nastac
Signed-off-by: Pablo Neira Ayuso
24 Apr, 2018
1 commit
-
This is a patch proposal to support shifted ranges in portmaps. (i.e. tcp/udp
incoming port 5000-5100 on WAN redirected to LAN 192.168.1.5:2000-2100)Currently DNAT only works for single port or identical port ranges. (i.e.
ports 5000-5100 on WAN interface redirected to a LAN host while original
destination port is not altered) When different port ranges are configured,
either 'random' mode should be used, or else all incoming connections are
mapped onto the first port in the redirect range. (in described example
WAN:5000-5100 will all be mapped to 192.168.1.5:2000)This patch introduces a new mode indicated by flag NF_NAT_RANGE_PROTO_OFFSET
which uses a base port value to calculate an offset with the destination port
present in the incoming stream. That offset is then applied as index within the
redirect port range (index modulo rangewidth to handle range overflow).In described example the base port would be 5000. An incoming stream with
destination port 5004 would result in an offset value 4 which means that the
NAT'ed stream will be using destination port 2004.Other possibilities include deterministic mapping of larger or multiple ranges
to a smaller range : WAN:5000-5999 -> LAN:5000-5099 (maps WAN port 5*xx to port
51xx)This patch does not change any current behavior. It just adds new NAT proto
range functionality which must be selected via the specific flag when intended
to use.A patch for iptables (libipt_DNAT.c + libip6t_DNAT.c) will also be proposed
which makes this functionality immediately available.Signed-off-by: Thierry Du Tre
Signed-off-by: Pablo Neira Ayuso
14 Oct, 2014
1 commit
-
The kernel used to contain two functions for length-delimited,
case-insensitive string comparison, strnicmp with correct semantics and
a slightly buggy strncasecmp. The latter is the POSIX name, so strnicmp
was renamed to strncasecmp, and strnicmp made into a wrapper for the new
strncasecmp to avoid breaking existing users.To allow the compat wrapper strnicmp to be removed at some point in the
future, and to avoid the extra indirection cost, do
s/strnicmp/strncasecmp/g.Signed-off-by: Rasmus Villemoes
Cc: "David S. Miller"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 Oct, 2013
1 commit
-
There are currently seven different NAT hooks used in both
nf_conntrack_sip and nf_nat_sip, each of the hooks is exported in
nf_conntrack_sip, then set from the nf_nat_sip NAT helper.And because each of them is exported there is quite some overhead
introduced due of this.By introducing nf_nat_sip_hooks I am able to reduce both text/data
somewhat. For nf_conntrack_sip e. g. I gettext data bss dec
old 15243 5256 32 20531
new 15010 5192 32 20234Signed-off-by: Holger Eitzenberger
Signed-off-by: Pablo Neira Ayuso
28 Aug, 2013
1 commit
-
Split out sequence number adjustments from NAT and move them to the conntrack
core to make them usable for SYN proxying. The sequence number adjustment
information is moved to a seperate extend. The extend is added to new
conntracks when a NAT mapping is set up for a connection using a helper.As a side effect, this saves 24 bytes per connection with NAT in the common
case that a connection does not have a helper assigned.Signed-off-by: Patrick McHardy
Tested-by: Martin Topholm
Signed-off-by: Jesper Dangaard Brouer
Signed-off-by: Pablo Neira Ayuso
24 Jun, 2013
1 commit
-
In (b20ab9c netfilter: nf_ct_helper: better logging for dropped packets)
there were some missing brackets around the logging information, thus
always returning drop.Closes https://bugzilla.kernel.org/show_bug.cgi?id=60061
Signed-off-by: Balazs Peter Odor
Signed-off-by: Pablo Neira Ayuso
19 Feb, 2013
1 commit
-
Connection tracking helpers have to drop packets under exceptional
situations. Currently, the user gets the following logging message
in case that happens:nf_ct_%s: dropping packet ...
However, depending on the helper, there are different reasons why a
packet can be dropped.This patch modifies the existing code to provide more specific
error message in the scope of each helper to help users to debug
the reason why the packet has been dropped, ie:nf_ct_%s: dropping packet: reason ...
Thanks to Joe Perches for many formatting suggestions.
Signed-off-by: Pablo Neira Ayuso
18 Jan, 2013
1 commit
-
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 TryingThe 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 TryingStandard 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 TryingBut 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
Acked-by: Eric Dumazet
Cc: Patrick McHardy
Signed-off-by: Pablo Neira Ayuso
03 Sep, 2012
1 commit
-
This merges (3f509c6 netfilter: nf_nat_sip: fix incorrect handling
of EBUSY for RTCP expectation) to Patrick McHardy's IPv6 NAT changes.
30 Aug, 2012
1 commit
-
Add IPv6 support to the SIP NAT helper. There are no functional differences
to IPv4 NAT, just different formats for addresses.Signed-off-by: Patrick McHardy