Gnut Manual: F.A.Q. at MROB
Author: Robert Munafo

Gnut Manual: F.A.Q.

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 `gnut`.

5.2 What's wrong with `ggnut` (the Gnome/GTK version of `gnut`)?

It was never finished. There is an old version of `ggnut` that sort of partly worked, but it was never finished. Check here if you're really interested.

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`

However, if you use the second method, the `set local_port` command must occur at the beginning of the `.gnutrc` file. The following will not work:

> `open server1.foo.bar:6346` gnut will choose its own local_port here
> `set local_port 6346` too late

5.4 Does `gnut` has feature xxx?

Look in this manual, read the other supplied files (like TUTORIAL and HACKING) and if you don't see it in either place, then the answer is no.

If you are a programmer and want to add features, a good place to start is the `gnut` developers' mailing list at http://groups.yahoo.com/group/gnut_dev

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:

If your address is | gnut can connect to (host list) | and can get files from (search results list)
type O | type O | any (O directly, A+B+C+P through push)
type A | type O (definitely) and A (maybe) | type O (definitely) and A (maybe)
type B | type O (definitely) and B (maybe) | type O (definitely) and B (maybe)
type C | type O (definitely) and C (maybe) | type O (definitely) and C (maybe)
type P | type O (definitely) and P (maybe) | type O (definitely) and P (maybe)

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 of other 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.1 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.

Most of the memory leaks seem to have been fixed in version 0.4.22. However, if you leave `gnut` running for days there might still be a bug involving memory getting allocated and then not de-allocated. If you think this is happening, email me and I'll try to get more info from you so I can fix it.

5.6.2 Why is `gnut` hogging the CPU?

You are probably sharing more than a few hundred files. Find out by typing `info s`; if it says something like "Num Shared: 19683", then that's the problem.

The CPU usage by gnut is almost entirely for responding to searches. You can estimate your gnut CPU usage by this formula:

> usage = K × connections × sharedFiles

where K is a constant, connections is the number of GnutellaNet connections (`info c`), and sharedFiles is the number of shared files. Thus, you will double your CPU usage either by doubling the number of connections or doubling the number of shared files.

5.7.1 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.

Sometimes spammers on the Gnutella network issue 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.7.2 If I search for anything at all, like "qwert asdfg zxcvb" I get some results like "qwert asdfg zxcvb.exe" that are not related to what I am searching for. What's up?

Those results are probably spam. "Spam" is unrequested data deliberately sent to a large number of people without their consent. Usually it is some type of advertising, and sometimes is meant to be an attack against the users, their computers, a company, a network or the Internet as a whole. The individual generating the spam is called a "spammer". Spamming is usually illegal.

Gnutella spam usually takes the form of query responses. Spammers send back results to every query, in an attempt to get you to download their files. The file itself is usually an advertisement for a web site (casinos and pornography are common advertisers) or a virus; in almost all cases the ads and viruses only work under Microsoft Windows.

The `gnut` command blacklist and variables strict_search, search_extensions and search_min_size are all useful for filtering out spam, but there is no perfect or permanent solution.

5.8.1 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 that you don't have.

5.8.2 I did a search, and the search shows files that I'm sharing. Why did this happen and how do I prevent it?

There is probably a server out on the Gnutella network that is connected to you via two different paths. Your search went out on one path and came back in along the other path, and `gnut` answered it. `gnut` doesn't bother to check for this because it is a very rare situation (most users don't search for files that they already have!). If you don't want to see your own files in searches, you can blacklist your own IP address with the blacklist command (see section 4.2).

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.

For more about the reasons behind this, read section 6.3.

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 2 minutes if min_connections is 8), `gnut` looks through the connection list for the connection with the highest dropped-packets ratio. If its ratio is greater than autokill_thres percent (default 10), 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 it connects 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.

You can set the leave_turds variable to control whether these small files get deleted automatically, and the last command allows you to see the contents of the error message (if any) from a failed download. You can also set the auto_download_retry and retry_push variables and `gnut` will automatically retry these failed downloads. See chapter 4 section 3 for more about these variables and how to use them.

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.

5.16 I keep getting "connection failed" messages. What's wrong?

Most Gnutella servers are busy, or are running BearShare which has the nasty habit of excluding non-BearShare users. If a server is busy you'll have to try downloading from somewhere else.

If you don't want to see the messages, change the verbose setting. Read the description of verbose in section 4.3 in the manual.

5.17.1 `gnut` is using the letters k, M, G and T to refer to 1000, 1000000, etc. These should be 1024, 1048576, etc.

Starting with version 0.4.26, `gnut` strictly follows the SI (Systeme Internationale) and CGMP (General Conference of Weights and Measures) specification by using these prefixes the same way they are used in all other forms of measurement, as powers of 1000 not 1024.

The following is from NIST (National Institute of Standards and Technology) publication SP811 "Guide for the Use of the International System of Units (SI)" (the relevant section can be read here):

> Alternative definitions of the SI prefixes and their symbols are not permitted. For example, it is unacceptable to use kilo (k) to represent 210 = 1024, mega (M) to represent 220 = 1 048 576, or giga (G) to represent 230 = 1 073 741 824.

The following is from "Etymology of Units" by PC Hariharan:

> Remember, both according to CGMP and SI, the prefixes refer to powers of 10. Mega is 106, exactly 1,000,000, kilo is exactly 1000, not 1024.

5.17.2 I know all that, but this is a computer program, and on computers we always use k to mean 1024, so you should change `gnut`.

I get this more often from people outside the United States. Apparently they don't know how hard it is to deal with non-SI unit systems.

Here's a test you can take:

- Assume one "MB" is 1024×1024 bytes, and one "GB" is 1024×1024×1024 bytes.

- Without using a calculator: How many bytes are in 17.04 MB?

- How many MB is 23066105 bytes?

- For extra credit: Add 3.406 GB and 173.4 MB. Give the answer in GB, and then give the answer in MB.

- Now assume one MB is exactly 106 bytes and one GB is 109 bytes, and repeat the problems again.

That's why the SI was adopted in the first place. It is difficult for people to convert between different types of units if the conversion factors are strange numbers.

`gnut` uses the easier system.

5.18 Can you put the `gnut` source code on CVS?

CVS has so many limitations that it isn't worth the effort for me to work around them. Here are the limitations that affect me the most:

- CVS doesn't allow to to create new deltas between two existing deltas. For example, if the revision tree currently includes a version 1.2, a 1.3 and a 1.4, I need to be able to add a revision between 1.2 and 1.3, with the result being 1.2, 1.3, 1.4 and 1.5. The old 1.3 and 1.4 should get renamed to 1.4 and 1.5. This is so I can retroactively change the structure of the tree without rebuilding it from scratch.

- If you add or remove whitespace, CVS treats it as a change. This causes havoc if I go through and untabify or reindent all the source code.

- When you create a new project under CVS, and then check it out for the first time, one or two extra directories (e.g. projectname/src) get added to your path. In other words, if the source was in /home/robert/gnut/src/foo.c before CVS, it ends up being in /home/robert/gnut/gnut/src/foo.c after putting it on CVS. The only way around this one is to type your "cvs" commands from your home directory, but that creates extra files and directories in your home directory and I don't want to be doing that.

If you can fix these problems for me, I'll consider using CVS.

5.19 Is there a mailing list for `gnut` developers?

Yes, it's described in the HACKING file. You should read that file if you want to modify gnut..

Next Previous Contents

The `gnut` pages are hosted by gnutelliums.com and gnutelanews.com

Permission is granted to copy, distribute and/or modify this text under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts and with no Back-Cover Texts.

Use of the `gnut` source code is subject to the terms and conditions of the GNU General Public License.

`gnut` is provided in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

`gnut` is currently maintained by Robert Munafo, mrob at mrob com

Back to main gnut page