Closed Bug 390082 Opened 17 years ago Closed 17 years ago

FTP data connections use wrong address

Categories

(Core Graveyard :: Networking: FTP, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: pascal.mail, Assigned: Biesinger)

References

Details

(Keywords: fixed1.8.0.14, fixed1.8.1.8, regression)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; fr; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5

I observed that when the FTP server name resolves to multiple IPv4 and possibly IPv6 addresses, if Firefox fails to establish the control connection to the first one and connects to the next one with IPv4, then it tries again to establish the data connections to the first address, which is wrong.

Reproducible: Sometimes

Steps to Reproduce:
1. Find an FTP server name which resolves to multiple IPv4 and possibly IPv6 address with at least one address which does not work (unreachable or whatever) and one IPv4 address that works. For example, ftp.netfilter.org resolves to an IPv4 address and an IPv6 address, only the IPv4 has an FTP server. ftp.test.plouf.fr.eu.org resolves to 2 IPv4 addresses, only one has an FTP server (these are resources of my ISP, please don't abuse).
2. Browse ftp://<server_name>/.
3. Capture the generated network traffic with a packet sniffer such as (t)ethereal/wireshark.
4. If Firefox uses the "good" IPv4 address first and nothing goes wrong, close Firefox, flush the local DNS cache ("ipconfig /flushdns" on Windows NT family) and start over.
Actual Results:  
In the following trace, the client is 192.168.0.246 and the FTP server name in the URL resolves to 2 IPv4 addresses, 192.168.77.77 (which is unreachable) and 10.0.0.1 (which works).

Firefox tries to connect to 192.168.77.77, fails, then connects to 10.0.0.1. After issuing a PASV command, it tries to connect to the data port on 192.168.77.77 again instead of 10.0.0.1.

  0.003789 192.168.0.246 -> 192.168.77.77 TCP 2576 > ftp [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1406
  0.003982  192.168.0.1 -> 192.168.0.246 ICMP Destination unreachable (Host unreachable)
[FF tries to connect to the same address a couple more times, then tries the next one]
  22.927733 192.168.0.246 -> 10.0.0.1     TCP 2577 > ftp [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1406
 22.928141     10.0.0.1 -> 192.168.0.246 TCP ftp > 2577 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
 22.928365 192.168.0.246 -> 10.0.0.1     TCP 2577 > ftp [ACK] Seq=1 Ack=1 Win=16872 Len=0
 22.951537     10.0.0.1 -> 192.168.0.246 FTP Response: 220 zenith FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready.
[...]
[Below you can see that FF tries to connect to the passive data port on the wrong IP address]
 47.550885 192.168.0.246 -> 10.0.0.1     FTP Request: PASV
 47.552513     10.0.0.1 -> 192.168.0.246 FTP Response: 227 Entering Passive Mode (10,0,0,1,6,113)
 47.573527 192.168.0.246 -> 192.168.77.77 TCP 2579 > 1649 [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1406
 47.573676  192.168.0.1 -> 192.168.0.246 ICMP Destination unreachable (Host unreachable)
 47.582035 192.168.0.246 -> 10.0.0.1     FTP Request: LIST
 50.815537 192.168.0.246 -> 192.168.77.77 TCP 2579 > 1649 [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1406
 50.815738  192.168.0.1 -> 192.168.0.246 ICMP Destination unreachable (Host unreachable)
 57.377511 192.168.0.246 -> 192.168.77.77 TCP 2579 > 1649 [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1406
 57.377686  192.168.0.1 -> 192.168.0.246 ICMP Destination unreachable (Host unreachable)
[Eventually it gives up and connects to the next (and correct) address]
 70.501974 192.168.0.246 -> 10.0.0.1     TCP 2580 > 1649 [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1406
 70.502219     10.0.0.1 -> 192.168.0.246 TCP 1649 > 2580 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
 70.502437 192.168.0.246 -> 10.0.0.1     TCP 2580 > 1649 [ACK] Seq=1 Ack=1 Win=16872 Len=0
 70.510995     10.0.0.1 -> 192.168.0.246 FTP Response: 150 Opening BINARY mode data connection for '/bin/ls'.

Expected Results:  
Firefox should directly use the same IP address as the FTP control connection for the related FTP data connections instead of trying all the addresses again.

I believe this bug is related to the patch correcting bug #370559. It does not happen when the control connection uses IPv6. To my understanding it is because when the control connection uses an IPv6 address Firefox uses the same address for the data connections, whereas when the control connection uses an IPv4 address it does new name lookups to retrieve the address for the data connections, which is wrong.
Component: General → Networking: FTP
Keywords: regression
Product: Firefox → Core
QA Contact: general → networking.ftp
Version: unspecified → Trunk
Assignee: nobody → cbiesinger
Flags: blocking1.9?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Attached patch patchSplinter Review
Attachment #276189 - Flags: superreview?(bzbarsky)
Attachment #276189 - Flags: review?(bzbarsky)
Flags: blocking1.8.1.7?
Flags: blocking1.8.0.14?
Attachment #276189 - Flags: superreview?(bzbarsky)
Attachment #276189 - Flags: superreview+
Attachment #276189 - Flags: review?(bzbarsky)
Attachment #276189 - Flags: review+
Comment on attachment 276189 [details] [diff] [review]
patch

a=bzbarsky
Attachment #276189 - Flags: approval1.9? → approval1.9+
I also fixed the comment about getting the IPv6 address to remove the IPv6 part

Checking in src/nsFtpConnectionThread.cpp;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp,v  <--  nsFtpConnectionThread.cpp
new revision: 1.315; previous revision: 1.314
done
Checking in src/nsFtpConnectionThread.h;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.h,v  <--  nsFtpConnectionThread.h
new revision: 1.121; previous revision: 1.120
done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: blocking1.9?
Resolution: --- → FIXED
Flags: blocking1.8.1.7?
Flags: blocking1.8.1.7+
Flags: blocking1.8.0.14?
Flags: blocking1.8.0.14+
note that branch doesn't need bug 391499's patch
Attachment #278992 - Flags: approval1.8.1.7?
Attachment #278992 - Flags: approval1.8.0.14?
Comment on attachment 278992 [details] [diff] [review]
branch version of patch

approved for 1.8.1.7, a=dveditz for release-drivers
Attachment #278992 - Flags: approval1.8.1.7?
Attachment #278992 - Flags: approval1.8.1.7+
Attachment #278992 - Flags: approval1.8.0.14?
Attachment #278992 - Flags: approval1.8.0.14+
MOZILLA_1_8_BRANCH:
Checking in nsFtpConnectionThread.cpp;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp,v  <--  nsFtpConnectionThread.cpp
new revision: 1.296.8.6; previous revision: 1.296.8.5
done
Checking in nsFtpConnectionThread.h;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.h,v  <--  nsFtpConnectionThread.h
new revision: 1.114.8.2; previous revision: 1.114.8.1
done

MOZILLA_1_8_0_BRANCH:
Checking in nsFtpConnectionThread.cpp;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp,v  <--  nsFtpConnectionThread.cpp
new revision: 1.296.8.1.2.4; previous revision: 1.296.8.1.2.3
done
Checking in nsFtpConnectionThread.h;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.h,v  <--  nsFtpConnectionThread.h
new revision: 1.114.8.1.2.1; previous revision: 1.114.8.1
done

Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: