Configuration Questions

Generally, CGI connection mode is the slowest of all possible connection modes. This is due to the way it works, it needs to accumulate data before it sends it off to the other side. But you can adjust a few knobs and try to make it faster.

You need to locate the ".ems.cfg" config file first. Have a look at the user guide if you need help with this step. This file can be edited with any text editor, for example Notepad. Ensure the YF client is NOT running when you edit the file or your changes may be lost. It is difficult to break this file so don't hesitate to try...

There are four values that control the timing of CGI connections and you can change everyone of them, but I would not recommend changing any other timing but "cgi_uplink_maxdelay". Here are the parameters with their default values and their meaning:

• cgi_uplink_maxdelay. Defaults to 500 milliseconds. The YF client will accumulate data for at most this time until it initiates a new uplink connection no matter how much data has been accumulated. You might want to set this to a lower value, maybe 200 milliseconds.
• cgi_uplink_urgentdelay. Defaults to 20 milliseconds. The YF client will use this value instead of the previous value when it has frames to deliver that are considered urgent, for example acknowledgements.
• cgi_uplink_threshold. Defaults to 3. If this many frames (YF data units) are to be delivered, a new uplink connection will be made right away. Setting this to 1 will effectively disable data accumulation and make your connection much more responsive, but it will also create much more overhead. If you don't care about how many connections are made and how much overhead it generates, set this to 1 and don't worry about the rest.
• cgi_uplink_mindelay. Defaults to 1 millisecond. This is the minimum amount of time between two uplink connections. You should not set it to 0 and most people should not have to increase it, but if your network connection drops connection attempts that appear in bursts, try setting it to a higher value!

All these values normally do not appear in the config file and are not configurable through the front end. Just add lines to the file (it does not matter where) that contain the name of the value, a space, and the numeric value to which you would like to set it (no unit).

Optimum performance is probably achieved by setting cgi_uplink_threshold to 1 and cgi_uplink_mindelay to maybe 20. Try it, you can't break anything, if it doesn't work just remove the lines again.

YF server "names" starting with U2 are encrypted IP addresses. If you ever see them it means that the YF client believes that you are pretty much filtered. It will then try some addresses reserved for desperate people, and these addresses are only distributed in encrypted form.

Don't worry about the strange look of them, they work nevertheless. And if they don't, they got filtered as well.

This is a feature added in version 20100204-01. Basically it's a set of rules how a connection between the YF client and the YF server can be made in some special networking situations. Most people don't need these and can safely leave it disabled; in fact if you are able to connect, do not enable tweaks. However if you are unable to connect check whether one of the tweaks seems to match your networking situation. Their names are very explicit.

Will we add more of these? Probably. We add them when needed, and we can only add them if we learn about such tweaks. If you've got a clever way to configure the YF client to connect to its servers in some unusual networking situation, please tell us about it.

Why are there no such tweaks for Iran, China, and whatnot? Basically because you don't need them there. :-)

It does what the name suggests. 8) The "HTTPS" communications scheme uses a codec that relies on a transparent TCP connection, as it is normally used to provide HTTP with SSL protection (commonly known as "HTTPS"). Now, while the channel that web proxies and firewalls normally provide to web browsers for HTTPS is typically (but not always) transparent, they sometimes check that the protocol spoken is actually SSLv2 or SSLv3 (TLS) and not something else -- this is to prevent e.g. SSH tunneling through this port. Of course, they detect that our protocol isn't SSL either and disrupt the connection after they have determined this. The symptoms are that the YF client can initially connect to the server, maybe even authenticate, but then the connection freezes and gets re-established after a while, ad nauseam. A simple and most of the time effective solution to this is to enable the "true SSL" feature. It takes our binary data stream and wraps it in SSLv3 (TLS), making suspicious proxies and firewalls believe that it is really a browser speaking HTTPS. Two questions remain: a) is it more secure, and b) will it always help? The answer to both is: no. Well, not exactly. Let me explain why. Using an SSLv3 wrapper does indeed employ additional encryption (in this case it's RC4 with a 128bit key, like it's commonly used for HTTPS). But remember that each encryption is only as good as the key used. The key is negotiated under protection by the public/secret keypair (in this case: an RSA pair). But this only helps if the client side can rely on the public key really belonging to the server and not some man in the middle -- to ensure this, public keys are usually signed with a certificate, the certificate is provided to the requester as well in the negotiation phase, and this certificate carries a signature by a trustworthy party. This last step is something we cannot provide -- our certificate is self-signed (as it is the case with many web sites), which does [i]not[/i] protect in any way against man-in-the-middle attacks. We cannot sign it by a trustworthy party because then we cannot replace the certificate frequently, and this would mean that it's too simple to detect our protocol -- you just need to detect the use of a particular certificate. This has two consequences. The additional encryption does not protect against man-in-the-middle attacks (but our own encryption does), but it protects against record-and-decrypt-later types of attacks. In this way, using the "true SSL" feature actually makes the connection more secure. If you are expecting someone to eavesdrop on your connection and investing several PC days to decrypt your traffic, enable "true SSL" to make their life absolutely miserable. Contrary to HTTPS, a known-plaintext dictionary attack against RC4 is much more complicated with our protocol because it uses some random seed bytes of random length. The other consequence is that proxies and firewalls who completely decrypt and re-encrypt all HTTPS traffic, verifying the site certificate and refusing self-signed certificates, will still block our connection. (I hate to promote this technology but if a company is really serious about stopping tunneling, this is a must.) Will this block our service? No. There is still HTTP. :-) I hope this has clarified what the "true SSL" feature is and what you can use it for. It's for those paranoid about an attack against recorded traffic, and for those who need it because otherwise the connection doesn't work. We haven't enabled it by default because it uses resources on the server and may slightly increase latency.

If you are a registered, logged-in user have a look at the "Internals" section in the documentation part of the web site.

Most likely you or your applications are confusing local ports and server ports.

Your application is listening on Port X on your PC for connections. The Your Freedom server listens on Port Y for you. But do the others know about port Y? Probably not, because your P2P application reports to the trackers that it is listening on port X! The trackers learn about the YF server's IP address from the registration request, but the proper port needs to be within the message, and if your application has no place where you can configure your external port different from the port the app is listening on, then the tracker does not know it and the others will never learn about it. The easiest way around this is to make X = Y. Let your P2P application use the same port number as the YF server! This way your application will still not report info about the YF server port, but that doesn't matter because the number is the same. So if you have the YF port 23456 assigned to your profile, let your P2P application listen on port 23456 and configure a server port forward of 23456 -> localhost 23456.

Another thing that can easily go wrong is that some applications only listen on one IP address instead of all IP addresses. For example, BitSpirit will never listen on the loopback interface IP address 127.0.0.1, so it's no good to forward a serverport to this address! Use the Ethernet IP address instead. To check if your application is listening on all IPs open a command shell and type "netstat -an" (works on Windows, Unix, MacOS, ...). Look out for a TCP LISTEN line having the right port in it on the left hand side -- what's the IP? 0.0.0.0 means "all IPs"; if you don't see 0.0.0.0 you probably cannot use 127.0.0.1 but only the one shown instead.

The Windows firewall can also play tricks on you. Be sure you open the port your application is listening on, or allow the connection when prompted.

From the Forums, by Sandy:

In local port forward , you assign a local port to a remote address and port .. So when you connect to the port in your localhost , the connection will be automatically forwarded to the remote host.

This is particularly useful in bypassing proxies that dont allow irc , ftp etc .

For eg , lets say that your proxy doesnot allow any irc connections, and you want to chat with your friend in some channel in Efnet IRC network. So you make a local port forward in Your-Freedom say 2222 to any irc host say,

Local Port : 2222

Remote Host : irc.efnet.net

Remote Port : 6667

Now connect to localhost:2222 in your irc client and you'll be connected to efnet irc network.

I hope that'll clear up the doubt a little bit and as you can see local port forwarding is of no use in p2p applications.

For more info : you may "google" for "ssh port forwarding", which is somewhat similar to this but the basic idea is same for both