> 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). ... doh. Yes you are right. I've checked you are right. I can't believe I forgot that. I was working from a 8-month memory of the code. > >> 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. ooh sorry. Yes its fudging my head now too ;-) "in passive" == "need to respond in passive not active" but we seem to sync up later where its more important. > >> 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)? Yes, squid defaults to passive both in the setting and in the code. From the code it only attempts active (PORT/EPRT) if that setting is "off" or when the PASV fails. then it retries with a PORT immediately before going to error. > >> >> >> 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. Yup, so I said check 'ftp_passive on'. Should be trying a PASV first. if thats also failing there are NAT problems with the remote (server?) end. >> >> 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. Sorry, me getting the PASV and its response bass-ackwards again. Either end of control can send PASV. When squid receives one it sends out its control-sockets IP in response. > >> 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. I was, wrongly it seems. You can view the whole sequence with debug_options 9,2. > >> 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. Thus 'small'. But nasty. Lets hope it's not occuring. > > 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. Possibly a NAT or router at remote end playing evil with the data channel. > > 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 > Amos
