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
There are two likely causes for this. One is that you are
trying to do non-transparent proxying, but the config file is
not setup correctly. Ensure that DoNTP is set to
yes in the config file, and comment out
NTPAddress - it is never necessary and only serves
a purpose if you are doing a mixture of transparent and
non-transparent proxying.
The other possiblity is that 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 Linux 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.
With HTTP caching frox makes a connection to the ftp server initially, and then the http proxy/cache makes its own connection when you initiate a download. If the http proxy and frox are both at the same IP address then there will be problems with any ftp server (and there are a few) which only allow one connection per host.
The workaround is not to use http caching! You can either do this globally, or put in a specific config file subsection to turn off caching for any hosts that you have this problem with. A better workaround should appear in a future version.
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.