The FTP conntrack code currently only accepts the following format for
the 227 response for PASV:
227 Entering Passive Mode (148,100,81,40,31,161).
It doesn't accept the following format from an obscure server:
227 Data transfer will passively listen to 67,218,99,134,50,144
From RFC 1123:
The format of the 227 reply to a PASV command is not
well standardized. In particular, an FTP client cannot
assume that the parentheses shown on page 40 of RFC-959
will be present (and in fact, Figure 3 on page 43 omits
them). Therefore, a User-FTP program that interprets
the PASV reply must scan the reply for the first digit
of the host and port numbers.
This patch adds support for the RFC 1123 clarification by:
- Allowing a search filter to specify NUL as the terminator so that
try_number will return successfully if the array of numbers has been
filled when an unexpected character is encountered.
- Using space as the separator for the 227 reply and then scanning for
the first digit of the number sequence. The number sequence is parsed
out using the existing try_rfc959 but with a NUL terminator.
References: https://bugzilla.novell.com/show_bug.cgi?id=466279
References: http://bugzilla.netfilter.org/show_bug.cgi?id=574
Reported-by: Mark Post <mpost@novell.com>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netfilter-devel@vger.kernel.org
Cc: netfilter@vger.kernel.org
Cc: coreteam@netfilter.org
Cc: netdev@vger.kernel.org
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
4e7dba99c9