Look at the log file that frox produces and see if it gives you any clues. It should say ``Connect from A to B''. If it doesn't say anything then you aren't getting through to frox at all - check the config file to see frox is listening on the right address/interface. Have you remembered to do the ipchains/iptables command that is in the INSTALL file?
If the log file suggests frox is connecting back to itself then you are probably contacting it directly and non-transparent proxying is switched off. Either switch non-transparent proxying on in the config file, or make sure that your ftp client is not trying to connect directly to frox - either from you specifying the frox machine as the ftp host on the command line, or from the client trying to use it explicitly as a proxy.
If you have a complicated network setup then check the Network Problems section.
Read the client configuration section again
This happens when your connection is transparently redirected to frox, but frox is unable to determine the orriginal destination. The most likely cause is if you are using kernel 2.4.x with ipchains compatability. I do not know of a way around this short of changing from ipchains to iptables (or changing back to a 2.2.x kernel!).
Check whether you have NTPAddress set. If this is set then it must be set to the address and port that the ftp clients are using to contact the proxy, otherwise clients will not be offered non transparent proxying. If you unset it then all clients will be offered non transparent proxying.
If you have HTTP caching set up then frox should conduct all anonymous downloads through your proxy. But, frox also needs to make an ftp connection to the remote ftp server for retrieving directory listings etc. Therefore if you do netstat or equivalent you will not see a connection from frox to squid unless a file download is actually in progress.
This also means that you cannot use frox + squid and then
firewall off ftp access to the outside world altogether. Your
best bet is to keep frox (with or without squid), and set
ApConv
to yes
in the config file. You will
still need to allow frox to make outbound tcp connections on
port 21, and any ports in the PasvPorts range, but you should
not have any of the usual problems associated with firewalling
ftp.
As of version 0.7.8 frox scans the username from right to left when looking for the dividing @. If your username on the remote server is abc@def.org and you are logging in to ftp.gnu.org you can simply give "abc@def.org@ftp.gnu.org" to frox as your username.
If you are using both transparent and non-transparent
proxying then you will need to use the NTPAddress
option so that when your direct connection to ftp.gnu.org is
intercepted by frox it won't interpret your username
"abc@def.org" as a login to def.org with username abc.
Audiogalaxy is a music sharing program. Although audiogalaxy works through port 21 it does not use the ftp protocol, and therefore frox does not allow its connections through. If you are using frox as a transparent proxy and you wish to use audiogalaxy then you need to change your iptables/netfilter rules so that packets addressed to the audiogalaxy servers do not pass through frox. Fortunately audiogalaxy does not use port 21 to contact other machines using the audiogalaxy client so these do not also need to be added.
There is a mailing list at frox-user at lists.sourceforge.net
.
Please say what version of frox you are running, what
version of the linux kernel, whether you gave any options to
./configure
at compile time, and what point exactly
it fails at. The log file should give you some info, especially if
you set LogLevel to 25.