Amos Jeffries wrote:
Well ... To 'initiate' passive data mode is to send a PASV or PORT control message.
Minor niggle. To initiate passive data mode is to send a PASV control message. Sending the PORT command means you want the remote server to connect to you (and hence sets up an active transfer).
To do that the _sender_ must already have a data listening port open and ready to 'passively' receive the response.
Erm... In passive mode FTP the client originates both the control and data connections. The PASV command is a request for information on what IP and which port to connect to for the data channel.
To my mind that makes the side which is capable of receiving anonymous FTP connects in passive.
I'm having a bit of trouble parsing this statement.
If your squid is connecting _out_ badly, _it_ must be in passive and accept requests from clients.
Agreed, and I think I now better understand what you are saying, and why you made the suggestion you did.
This it show squid behaves with "ftp_passive on". It just opens a listening socket (on port 20 I believe) and issues a number of PORT/EPRT/PASV/EPSV controls to tell the client where to connect to.
It issues the PASV/EPSV to the server, correct (since it wouldn't issue a PORT or EPRT with ftp_passive enabled)?
Back to the initial problem; was with _squid_ outgoing data traffic going through the wrong ADSL link. Which to me means the passive was OFF, or the client incoming request came _in_ through that second ADSL.
In other words perhaps Squid gave a PORT command and specified a different IP than was used for the command channel? Odd behavior, but fair enough.
I considered the possibility squid might be sending the wrong IP in PASV.
I don't understand this statement either. The PASV command is sent without arguments. The response to a PASV request contains IP and port information.
BUT, found that its looking up the dst-IP of the control connection to generates the PASV. That means it sends out the IP the client is connecting to.
Are you saying that Squid (with ftp_passive on) originates the data connection from the same IP/interface as is used for the control channel? The comment from ftp.c "Open data channel with the same local address as control channel" indicates that this should be the case. Then again, the variable (addr.sin_addr) looks to be used when constructing the PORT command, so the same IP used for the control channel should be used to accept active FTP connections.
There is only a small possibility of this going wrong if in transparent mode.
But it shouldn't be an issue in transparent mode, as port 21 would not be intercepted by the proxy, and the likelihood of port 80 being used for the data channel is minuscule.
If I'm my above understanding of what you are saying is correct, using ftp_passive on (the default) sounds like a winning plan to me then. It allows for fail-over (in that FTP transfers are not limited to one tcp_outgoing_address as in my solution), but should keep all related-to-the-FTP-connection traffic on the same network path. I still find it odd that Squid would send out a PORT command specifying a different IP than was used to originate the command channel... My C-foo is pretty weak, but it sure doesn't look like this is the case, so I am now left to believe that the issue is outside of Squid.
From the original message:
> Im thinking to use squid ftp proxy under the firewall in other > machine and procces the data for later send all ftp to the open bsd > firewall. >
Heck if I know...
Amos
Chris
