summaryrefslogtreecommitdiff
path: root/net-p2p/linux-edonkey-core/files/README.FreeBSD
blob: 8fe970822fc36378cd7ce58f58e384f22ed14125 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
[ HELP file resumed from FAQ at
  http://users.aber.ac.uk/tpm01/ed2k_tools/faq.html ]

	Read the aforementioned FAQ for complete instructions.

	1) You have to configure the 'core' client and add a password

	Install the "net/edonkey-core" port and type 'donkey'
from the command line and then typing 'pass username password' (and
hitting ENTER). Once you are finished, type 'q' (ENTER) and 'y'
(ENTER) to quit and make the core save its preferences.

	Of course, username must be a username you desire; and,
password, a password you want to use. These are for connecting to
the 'core' client, not for anything else. Therefore, unless you
want someone mischiefly connecting to your client, choose both
carefully. :)

	2) Start 'core' client prior to running any of the GUIs
after you have setup a password

	To start the core client to make it controllable via a GUI,
type 'donkey - !' from the command line.

	3) Run the GUI and connect to the core client

	Install the port "net/edonkey-gui-gtk" or "net/edonkey-gui-java",
whichever one you prefer. Next run 'edonkey-gui-gtk' (if you chose
the FreeBSD native GTK GUI client, or linux-edonkey-gui-gtk if Linux
one) or 'edonkey-gui-java' (if you chose the Java GUI client). The
Java GUI is very slow compared to the GTK one but it both supports
multiple line selections and ed2k link pastes. The GTK one cannot
do that now but it's very fast; it can accept ed2k link drag-n-drops
using a mouse and keeps getting new features all the time. Therefore,
I would advise using both, each for what their strong points are.
The Java one to multiple select and the GTK one for normal use.

	Okay, the GUI starts and there is that 'connect to' dialog,
now what do I do?

	First of all, you'll need an edonkey core running somewhere.
Usually this will be the computer you're running the GUI on. There
should be a status message above the buttons that tell you if there
is already a core running locally or not. If not, hit the 'spawn
local donkey' button to start the edonkey2000 core program. Now the
status message should change. If not, you'll have to start the core
client manually (Refer to step #2).

	Second, if you spawned the donkey core alright, you enter
the admin username and password into the appropriate fields in the
'connect to' dialog and hit the 'connect' button. Now the 'connect
to' dialog should disappear and the GUI should be connected to the
core. If this does not happen, there could be the following problems
(also check the statusbar of the GUI main window for messages):

  (a) If you have started the core manually, you forgot the '-'
  option. Start it with 'donkey - !' from the command line.

  (b) You're connecting to the wrong computer ('host'). This should
  be 'localhost' by default.

  (c) You're connecting to the wrong port on your computer. The
  default GUI port can be set in the command line 'core' client via
  the 'aport' command, but should be 4663 by default.

  (d) You haven't set a username and/or password with the core
  manually (Refer to step #1).

  (e) Your username/password are wrong (run the core manually and
  type the 'vo' command to see what they are set to).

  (f) The 'connect to' dialog disappears, but nothing seems to
  happen. Most notably, the options page shows 'pleasewait' as a
  nickname: This happens if you connect to the core on the wrong
  port, namely on the port the core uses as its _data_ port. Start
  the core manually and type 'vo' to see what the admin port is.
  Make sure the 'admin port' is different from the 'door port'
  (=data port). If in doubt, type 'netstat -l' from the command
  line to see on what ports the donkey is listening. It should be
  one of those.

  (g) If you're trying to control a GUI on a remote host, chances
  are that there is a firewall between you and the remote host that
  blocks all TCP connections on the admin port. If this is the case,
  you have to check your firewall settings and allow these connections
  or try a different port as an admin port.

	Third, you're connected, and the options page does NOT show
'pleasewait' as a nickname. This is a very good sign, meaning that
the GUI and the core can actually talk to each other. Now you should
be able to do whatever you want: Go to the servers page and connect
to a server first. Then you can search and start to download things.
If you right-click on the list-entries you'll get all the available
actions. Don't forget to share! :)