Next Previous Contents

5. F.A.Q.

5.1 Will gnut run on Slackware 4.0?

No. gnut requires glibc2.0, you need to upgrade to this before you can use it.

5.2 Does ggnut (the Gnome graphical-interface front end to gnut) work?

Yes -- Jon Arney has been releasing working versions of ggnut since May 2000. Jon and Robert Munafo are working on combining their work so that gnut and ggnut will once again be part of the same release -- but for now, visit Jon Arney's site if you want to use ggnut. Also, remember that gnut has an HTTP interface, so if you just don't like typing commands you can use your gnut through your web browser.

5.3 How do I change the port in gnut?

Starting with version 0.4.7, you can change the port in two ways: with the -p option on the command line:

gnut -p 6346

or by putting a command in your .gnutrc file:

set local_port 6346

5.4 Does gnut has feature xxx?

Look in this manual, read README, if you don't see it in either place, then the answer is no.

5.4.3 What are the "Virtual Private Network" (VPN) and other special addresses?

Certain IP addresses are only used behind firewalls or within institutional (corporate, educational, government, etc.) private networks. They are called VPN (Virtual Private Network) and APIPA (Automatic Private IP Addressing) addresses. The VPN addresses were originally defined in the Internet document RFC 1597 (later supplanted by RFC 1918); APIPA is most often seen being used by Windows 98 and Windows 2000 systems. Here are the VPN and APIPA ranges:

10.0.0.0 to 10.255.255.255 (type A)
172.16.0.0 to 172.31.255.255 (type B)
192.168.0.0 to 192.168.255.255 (type C)
169.254.0.0 to 169.254.255.255 (type P)

Sometimes, depending on the situation, the following addresses are either handled like the above "special" addresses, or are not available for use, or both:

208.0.0.0 to 215.255.255.255 (class F)
216.0.0.0 to 219.255.255.255 (class G ARIN, RIPE NCC, IANA reserved)
220.0.0.0 to 221.255.255.255 (class H)
222.0.0.0 to 223.255.255.255 (class K)
224.0.0.0 to 239.255.255.255 (class D multicast)
240.0.0.0 to 255.255.255.255 (class E reserved)

In addition, there are some ranges that are reserved for testing and other special uses, and can never be used as a normal IP address. These are:

0.0.0.0 to 0.255.255.255 (local broadcast)
127.0.0.0 to 127.255.255.255 (node loopback)
192.0.2.0 to 192.0.2.255 (TEST-NET)

5.4.4 Why do some uploads/downloads appear as "SEND PUSH" or "RCV PUSH" in the info c display?

Uploads and downloads to hosts at VPN addresses (see question 5.4.3) have to use something called a "push request" to establish a connection. This request is sent through the GnutellaNet network, and usually takes a few minutes to get started. If you are within a VPN, all of your uploads will happen by PUSH requests (unless they were requested by others within your institution's network).

5.5.A I'm behind a firewall, and gnut is showing host addresses behind other firewalls. That's not right, is it?
5.5.B I'm not behind a firewall, and gnut is showing host addresses behind firewalls. That's not right, is it?

The "behind firewall addresses" are the VPN addresses described in question 5.4.3 above. We'll refer to all other addresses as "type O". Starting with version 0.4.8, gnut filters addresses in the host list and search results lists to remove hosts that are definitely inaccessible, depending on gnut's local IP address. It cannot remove all inaccessible hosts if the local IP is behind a firewall. Here are the rules gnut uses:

Thus, even if you are not behind a firewall, gnut must show all addresses in search results because files are accessible through push requests.

And even if you are behind a firewall, gnut must show addresses ofother hosts whose addresses are of the same type, because they might also be behind your firewall. This is particularly important to users in very large institutions, such as universities. gnut does not test each address to see if it is actually accessible, because that would be very slow and would be a waste of network bandwidth.

5.6 Why does gnut launch 10 copies of itself, and why does it use so much memory?

If you are running Linux and use ps or top to look at the running processes on your machine, you will see many copies (usually about 3 plus the number of active connections, uploads and downloads), all with the same SIZE and RSS (virtual and resident memory) figures. These are actually threads (simultaneous concurrent execution states) running within a single copy of gnut. ps and top display them as separate processes because they are not thread-aware and because of the way the Linux kernel implements threads. Rest assured that they are not each taking up the amount of memory indicated. There is only a fairly low per-thread memory overhead used for the stack and processor state for context switches.

So if you type ps u and gnut appears 7 times each with a SIZE of 8400, then your gnut is currently using 8.4 megs of virtual memory.

That 8.4 megs (or whatever number you're seeing) grows as gnut runs, mainly because of the GUID and host lists. These are lists of Gnutella packets that have been seen, host IP addresses, and other things used to route packets in the Gnutella network. When you quit and restart gnut, the memory usage will go down, but it builds up again over time as the packets come in.

There is also a memory leak (bug that causes memory to be allocated and then not de-allocated, causing a buildup of wasted memory). This bug has been around since before version 0.3.29 and I have not been able to find it (yet) and no other programmers have been able to find it for me, but plenty of people report it as a problem. Any help would be appreciated.

5.7 Someone is downloading a file "nonsense.mp3" from me, but I have no such file on my computer. What's up?

When you use the info or info t command, gnut displays all transfers and transfer attempts, even those transfers that are not working. Furthermore, the "filename" displayed is the filename they asked for, and the length transferred and percent transferred correspond to the requested data range (which is nonzero if the request is for a resume-in-the-middle transfer). gnut displays this info even when the file is nonexistent because it is often useful to know what is being requested even if you don't have it.

Recently, a spammer on the Gnutella network has been issuing requests for downloads of nonexistent files such as "nonsense.mp3", then letting the connection hang (without acknowledging the error or closing) in an attempt to impede the functionality of your node and other nodes on the network. That's why you see that bogus file transfer.

5.8 I did a search, and I know I'm sharing files that match this search. Why didn't the search show the files I'm sharing?

gnut does not search your own files when you do a search. Searches are for finding things out on the network, not things you already have.

5.9 How can I get the most results from my searches?

• Increase min_connections.
• Set autokill_thres to 10 (see question 5.10 for an explanation).
• Be patient -- it takes about 5 minutes for all search results to arrive.

5.10 Why do connections get closed so often?

Some connections close because the other end closed it (usually from the user quitting their Gnutella client) but gnut also implements something called autokill.

Once every 16/min_connections minutes (for example, once per 2minutes if min_connections is 8), gnut looks through theconnection list for the connection with the highest dropped-packets ratio. If its ratio is greater than autokill_thres percent (default10), the connection is closed and a new connection initated to a randomly-chosen host.

The effect of this action is to spread the connections as far from each other as possible in the Gnutella network. A connection with a high dropped-packets ratio is connected to a node that is "close" (in terms of hop count) to one or more other nodes in the connection list, and furthermore it has a slower propagation delay (inasmuch as the packets are arriving over other links first). Therefore, closing it will not lose much, and opening a new connection to a randomly-selected host elsewhere on the network stands a good chance of reaching a whole new bunch of hosts.

Because the network is always changing, the connection list has to be continually adjusted to maintain maximum coverage. After about 30 minutes this algorithm gets close to the theoretical limit of reaching the greatest possible number of hosts without increasing the TTL or min_connections.

If you don't want gnut to autokill, disable it either by setting autokill_thres to 0 or min_connections to less than 5.

5.11 Why can't I get eval scripts to read gnut's output?

There are three ways to run a shell command (such as a script) within gnut:

 gnut> ! perl script1
 gnut> `perl script1`
 gnut> eval perl script1

All three methods allow you (the user at the keyboard) to interact with the invoked program. In fact, the command takes over -- the gnut command-line will not respond until the command is done.

This was done so that you could interact with a command, like in this example:

 gnut> ! vi tempfile

Your typing on the keyboard goes into the program (vi in this case) and the stuff printed by vi shows up on the screen. When vi is done, you're back in gnut.

In the case of back-quote and eval, gnut reads the stuff printed out and does something with it (executes it as gnut commands). It would seem to make sense to feed gnut's output into the running program so that the program and gnut could have a back-and-forth ongoing conversation.

Unfortunately, this leads to deadlock problems. One problem is starvation, which happens when both processes are waiting for input but neither is supplying anything to the other. Another is buffer overrun, when both programs output so much that the other cannot keep up, until the buffers get full. In both cases, both programs freeze.

If you want to create a script that interacts with gnut, you will have to write your script in expect, or in another language using an expect library, and have your script launch gnut itself and supply all the commands to gnut.

5.12.1 I cannot get gnut to connect to other hosts. I think it's because of my firewall or my dialin access configuration. How do I fix this?

To use any Gnutella client, including gnut, you need a standard TCP/IP connection. To test your system to see if the TCP/IP connection is standard, run a command like:

ping www.cnn.com

or:

nslookup www.n-tv.de

If these commands work, you probably have a standard TCP/IP connection.

gnut establishes all of its connections via the standard kernel socket(2), connect(2), setsockopt(2) and bind(2) calls. For incoming connections it binds to the port specified in your .gnutrc local_port configuration variable, and for outgoing connections itconnects to the actual IP address and port, for example 12.34.56.78:6346. gnut does not pay attention to environment variables like telnet_proxy, nor does it attempt to open all its outgoing connections through an intermediate protocol, unless that protocol is automatically provided by the kernel in response to the standard functions just listed. The code that implements this is in gnut_net.c.

Therefore, to run gnut (or just about any other program that uses TCP/IP in the standard way), your operating system must be configured in such a way that the standard kernel calls accomplish the correct result without any need for the program to treat your system as a special case. From the program's point of view, your system must appear to have a "direct" Internet connection rather than being behind a firewall.

5.12.2 gnut connects to other hosts, but can't download (or upload) files, or can only download (upload) with the push command. How do I fix this?

Your firewall, or the firewall at the other end, might be rejecting certain types of connections and not others, based on the IP address or the port number. If your local IP address is different from the IP address that others need to use to connect to you, you need to use the -i command-line option (see section 4.1). The local port number is set by the local_port variable or the -p command-line option.

5.13 A download failed after 47 bytes leaving a tiny text file containing an error message like 'server busy'. Please fix this!

This problem is actually caused by a bug in the program at the other end (the server that is supplying the file). When you try to download the file it sends an error message rather than just closing the connection. This is supported by the HTTP transfer protocol but not by the Gnutella protocol specification, and as a result there is no way a program (like gnut) can distinguish that the data sent is part of the "real" data for the requested file or an error message.

However, gnut does contain a partial fix to this problem. If you attempt the download again, and if a previous partially-transferred file already exists, and if that partial file is less than 512 bytes long, then gnut ignores those bytes and starts the download over from the beginning. That means that if the transfer works the second time, it will not have those 47 bytes of error-message text at the beginning.

5.14 If I already know the IP address and filename of a file I want to download, how can I download that file without doing a "search"? Can I do this from a web browser?

The IP and filename are not enough. Gnutella servers require a file ID number, also called a "refnum", to specify which file is being downloaded. The filename is ignored.

A web browser might work, but might not, depending on what type of Gnutella program implements the server. Some Gnutella programs reject web browsers, and allow downloads only by other Gnutella programs.

If you want to try a web browser, the URL you have to type looks like this:

http://12.34.56.78:6346/get/37/Touch%20Of%20Gray.mp3

Notice the ID number 37, and %20 for blank spaces.

5.15 My firewall administrator is telling me that there are unauthorized outgoing (or incoming) connections to (or from) random IP addresses. Is this gnut's fault?

Assuming you have a good working Internet conection (see question 5.12), any Gnutella client, including gnut, will cause lots of connections to happen in both directions, outbound and inbound, to/from any IP address of someone else running a Gnutella client. Most of these connections are for GnutellaNet connections, which are the connections through which the packets get sent. The others are for uploads and downloads and PUSH requests.

You can prevent random IP addresses from connecting to you by using the "-i" command-line argument (manual section 4.1). Give it an IP address like 0.0.0.0. Then the other Gnutellas will think you are unreachable. However, they will not be able to download files from you in any way other than sending you a PUSH request. Please note, the connections won't stop coming until everyone else in the entire Gnutella network quits and restarts their Gnutella clients, which might take as long as 3 weeks, or even longer.

There is no way to prevent your Gnutella program from connecting out to lots of random IP addresses. All Gnutella clients (including gnut) work that way because that's the way the Gnutella protocol works.

Next Previous Contents

Back to main gnut page