Bug 106416
Summary: | vsftpd fails in PORT mode in IPv6 enabled server machine with IPv4 client | ||
---|---|---|---|
Product: | [Retired] Red Hat Raw Hide | Reporter: | matti aarnio <matti.aarnio> |
Component: | vsftpd | Assignee: | Radek Vokál <rvokal> |
Status: | CLOSED RAWHIDE | QA Contact: | Mike McLean <mikem> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1.0 | CC: | rvokal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-03-23 08:25:40 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
matti aarnio
2003-10-06 22:02:51 UTC
Is the bug still present in vsftpd-2.0.1? This should also be IPv6 module bug. Try 2.6 kernel. 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:2.3.4.5:21 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 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4 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("62.78.96.80")}, 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 socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 6 setsockopt(6, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 bind(6, {sa_family=AF_INET6, sin6_port=htons(20), inet_pton(AF_INET6, "::ffff:62.78.96.67", &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 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. 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. http://people.redhat.com/rvokal/vsftpd/2.0.3-pre2/ Would be great to confirm if this issue gets fixed. vsftpd-2.0.3 released and is now avaliable in devel tree. |