Bug 106416 - vsftpd fails in PORT mode in IPv6 enabled server machine with IPv4 client
vsftpd fails in PORT mode in IPv6 enabled server machine with IPv4 client
Product: Red Hat Raw Hide
Classification: Retired
Component: vsftpd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2003-10-06 18:02 EDT by matti aarnio
Modified: 2007-04-18 12:58 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-23 03:25:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description matti aarnio 2003-10-06 18:02:51 EDT
Description of problem:
  Confusion of IPv4 and IPv6 address modes, wrong type parameter
  to  connect(2)  call.

Version-Release number of selected component (if applicable):
  RawHide: vsftpd-1.2.0-4.1

How reproducible:

Steps to Reproduce:
1. Have a IPv6 enabled machine with default  vsftpd  setup running in it
    ('modprobe ipv6' will be sufficient)
2. Contact it from another machine with only IPv4 connection
3. Let the FTP client do in PORT mode: 'dir'
Actual results:
  Client sees mysterious "connection failed",  server strace reveals
  what really happens, e.g. half of the server produces a PF_INET6
  socket, and second half uses it in  connect(2) by giving it a AF_INET
  address structure --> kernel complains about invalid parameters

Expected results:
  successfull directory listing

Additional info:
  kernel is  2.4.22-1.2061.nptl  (of RawHide),  disabling the listen_ipv6=YES
  in /etc/vsftpd/vsftpd.conf  (and adding   listen=YES)  disables IPv6 support,
  and lets the server to work.
Comment 1 Radek Vokal 2004-08-30 06:48:50 EDT
Is the bug still present in vsftpd-2.0.1? This should also be IPv6
module bug. Try 2.6 kernel. 
Comment 2 matti aarnio 2004-08-30 07:12:07 EDT
The same behaviour continues.

Kernel  2.6.7-1.517smp 
vsftpd  2.0.1-2

This does relate to connection coming in as IPv6-mapped, e.g.
when system is listening on  :::21  the connection comes in
to local address ::ffff:   and now the system will
consider the remote to be IPv6 speaker, even tough it is coming
in thru that IPv6-mapped address space, and it will produce v6-
sockets for outbound connections as well, BUT it will still
use V4 addresses to connect() to them (see strace below.)

This relates also to newish "you can't bind :::21  and *:21
at the same time" behaviour in IPv6.

The  vsftpd  appears to function as two processes for each
connection.  Child runs with logged-in user's privileges,
while parent runs as 'nobody'.

Child talks with remote user, and asks parent to create sockets
for it.

  --- child ---
recv(0, "PORT 62,78,96,80,201,165\r\n", 4096, MSG_PEEK) = 26
read(0, "PORT 62,78,96,80,201,165\r\n", 26) = 26
write(0, "200 PORT command successful. Con"..., 51) = 51
rt_sigaction(SIGALRM, {0x948930, ~[RTMIN], SA_RESTORER, 0x1f4778},
NULL, 8) = 0
alarm(300)                              = 288
recv(0, "LIST\r\n", 4096, MSG_PEEK)     = 6
read(0, "LIST\r\n", 6)                  = 6
fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
write(5, "\3", 1)                       = 1
read(5, "\1", 1)                        = 1
recvmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}],
msg_controllen=16, msg_control=0xfee734d0, , msg_flags=0}, 0) = 1
fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
connect(6, {sa_family=AF_INET, sin_port=htons(51621),
sin_addr=inet_addr("")}, 16) = -1 EINVAL (Invalid argument)
fcntl64(6, F_GETFL)                     = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(6, F_SETFL, O_RDWR)             = 0
write(0, "425 Failed to establish connecti"..., 37) = 37
close(6)                                = 0
close(4)                                = 0
rt_sigaction(SIGALRM, {0x948930, ~[RTMIN], SA_RESTORER, 0x1f4778},
NULL, 8) = 0
alarm(300)                              = 300

  ---- parent ---
read(4, "\3", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
setsockopt(6, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(6, {sa_family=AF_INET6, sin6_port=htons(20), inet_pton(AF_INET6,
"::ffff:", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
28) = 0
write(4, "\1", 1)                       = 1
sendmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}],
msg_controllen=16, msg_control=0xfee737f0, , msg_flags=0}, 0) = 1
close(6)                                = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
Comment 3 matti aarnio 2004-08-30 07:58:16 EDT
I do recall, that the "you shall not bind *:21 and :::21 at the same
time" is IETF mandated behaviour, so Linux kernel does it correctly.
.. that comes (indirectly) from RFC 3493 section 5.3.

Oh, and there is no "IPv6-mapped" address format, there is
"IPv4-mapped" one.
Comment 4 Radek Vokal 2005-03-14 07:20:17 EST
Seems that this issue is fixed in the latest prerelease of vsftpd. The
test rpms can be found on personal page and are avaliable for tests.


Would be great to confirm if this issue gets fixed. 
Comment 5 Radek Vokal 2005-03-23 03:25:40 EST
vsftpd-2.0.3 released and is now avaliable in devel tree. 

Note You need to log in before you can comment on or make changes to this bug.