-
Notifications
You must be signed in to change notification settings - Fork 4
/
napster.txt
1403 lines (895 loc) · 39.7 KB
/
napster.txt
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
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
napster messages
================
August 6, 2000
0. Foreward
This is meant to be an open specification. If you find errors or know of
additional functionality not described hereafter, please send me email. It
benefits the entire community to have a complete and accurate protocol
specification. Not only does it allow for clients to be developed for any
platform, but also decreases the strain on the server having to parse out
bad client messages.
Disclaimer: the following information was gathered by analyzing the protocol
between the linux nap client and may not resemble the official Windows client
protocol.
1. Client-Server protocol
Napster uses TCP for client to server communication. Typically the servers
run on ports 8888 and 7777. Note that this is different from the `metaserver'
(or redirector) which runs on port 8875.
each message to/from the server is in the form of
<length><type><data>
where <length> and <type> are 2 bytes each. <length> specifies the length in
bytes of the <data> portion of the message. Be aware that <length> and <type>
appear to be in little-endian format (least significant byte goes first). For
example, in the C language you would encode the number 1 as
const unsigned char num[2] = { 0x01, 0x00 };
and 256 would be encoded as
const unsigned char num[2] = { 0x00, 0x01 };
[The above is for illustrative purposes only, there are much quicker ways to
actually encode a number. -ed]
Note that in many cases, strings are passed as double-quoted entries. For
example, filenames and client id strings are always sent as
"random band - generic cowboy song.mp3"
or
"nap v0.8"
Where required, double quotes are used in the description of the messages
below.
Some additional information about use of quotes inside of quotes:
> The answer is, no, it doesn't do escaping of quotes. If you try searching
> for the phrase 'a "quoted" string' on the windows client, you get no songs
> found, and "invalid search request" printed in yellow in your console
> window. (don't know what code that is, sorry.)
>
> and no wonder-- a little birdie told me that the client sends this:
>
> FILENAME CONTAINS "a "quoted" string" MAX_RESULTS 100
[contributed by Ben Byer <[email protected]>. -ed]
Note that unlike the IRC protocol, each line does NOT end in \r\n. The
<length> field specifies exactly how much data you should read.
2. Message Types
The following section describes the format of the <data> section for each
specific message type. Each field is denoted with <>. The fields in a
message are separated by a single space character (ASCII 32). Where
appropriate, examples of the <data> section for each message are given.
<type> can be one of the following (converted to big-endian):
0 error message [SERVER]
Format: <message>
2 login [CLIENT]
Format: <nick> <password> <port> "<client-info>" <link-type> [ <num> ]
<port> is the port the client is listening on for data transfer. if
this value is 0, it means that the client is behind a firewall
and can only push files outward. it is expected that requests
for downloads be made using the 500 message (see below)
<client-info> is a string containing the client version info
<link-type> is an integer indicating the client's bandwidth
0 unknown
1 14.4 kbps
2 28.8 kpbs
3 33.6 kbps
4 56.7 kbps
5 64K ISDN
6 128K ISDN
7 Cable
8 DSL
9 T1
10 T3 or greater
<num> build number for the windows client [optional]
Example:
foo badpass 6699 "nap v0.8" 3
3 login ack [SERVER]
Format: <email>
the server sends this message to the client after a succesful
login (2). If the nick is registered, the <email> address given at
registration time is returned. If the nick is not registered, a
dummy value is returned.
4 version check [CLIENT]
Format: <version>
Server sends [5] if an update is needed. All other responses are
ignored.
<version> = string, version 2.0b5a sends "2.0"
5 "auto-upgrade" [SERVER]
Format: <version> <hostname:filename>
Napster is out of date, get a new version.
Or also known as gaping security hole.
<version> = string, the new version number.
<hostname> = string, hostname of upgrade (http) server
<filename> = string, filename
Connections are always made to port 80.
The HTTP Request:
GET <filename> HTTP/1.0
Connection: Keep-Alive
Host: <hostname>
Expected HTTP Response.
Content-Length: <size>
Content-Type: <doesn't matter>
<data>
Upgrade file is save as "upgrade.exe".
And executed as: upgrade.exe UPGRADE "<current.exe>"
As far as I can tell no confirmation is requested by Napster when it
receives this message. And immediately start to "auto-upgrade". To keep
users informed that Napster is doing something potentially very harmful
to their computer it displays a message saying it's "auto-upgrading".
I think this pretty bad, since all someone has to do is hack a napster
server et voila a zillion clients at your disposal.
As far as I known this only affects the Win32 2.0b5a Napster client.
Other clients/versions I don't know.
[This section was contributed by Thomas van der Heijden <[email protected]>
-ed]
6 new user login [CLIENT]
Format: <nick> <pass> <port> "<client-info>" <speed> <email-address>
This message is used when logging in for the first time to register
a new nickname. The client normally checks for an unused nick using
the "check nickname" (7) message and upon receipt of a "nickname not
registered" (8) from the server will proceceed to log in with this
command.
note: this message is similar to the 0x02 message, with the addition
of <email-address> on the end
Example:
foo foo 6699 "nap v0.8" 3 [email protected]
7 nick check [CLIENT]
Format: <nick>
Queries the server to see if <nick> is already registered. This
message is typically used prior to logging in for the first time to
check for a valid nickname.
Response to this message is one of 8, 9 or 10
8 nickname not registered [SERVER]
Format: (empty)
The server sends this message in response to the "nick check" (7)
message to indicate that the specified nickname is not already
registered and is ok to use.
9 nickname already registered [SERVER]
Format: (empty)
The server sends this message when the nickname the client has
requested has already been registered by another user
10 invalid nickname [SERVER]
Format: (empty)
This server sends this message in response to the "check nickname"
(7) messages when the specified nickname is invalid, usually due to
bad characters such as spaces or other non-printable characters.
The Napster, Inc. servers only accept (upper- and lower-case) nicks
comprised of the following:
abcdefghijklmnopqrstuvwxyz1234567890_[]{}-@^!$
11 ??? [CLIENT]
Format: <nick> <pass>
[returns "parameters are unparsable" -ed]
12 ??? [SERVER]
Format: (empty)
this message is returned in response to message 11 from the client
13 echo??? [SERVER]
Format: <numeric>: [args]
Prior to issuing a login (2) command, the server will echo back the
received numeric and any arguments of any commands it receives.
14 login options [CLIENT]
NAME:%s ADDRESS:%s CITY:%s STATE:%s PHONE:%s AGE:%s INCOME:%s EDUCATION:%s
Example:
NAME: kev ADDRESS: CITY: ephrata STATE: pa PHONE: AGE: 60 or older INCOME: $100,000 or more EDUCATION: Graduate Degree
100 (0x64) client notification of shared file [CLIENT]
Format: "<filename>" <md5> <size> <bitrate> <frequency> <time>
<md5> see section "MD5"
<size> is bytes
<bitrate> is kbps
<frequency> is hz
<time> is seconds
Example:
"generic band - generic song.mp3" b92870e0d41bc8e698cf2f0a1ddfeac7 443332 128 44100 60
102 (0x66) remove file [CLIENT]
Format: <filename>
client requests to remove file from shared library
200 (0xc8) client search request [CLIENT]
[FILENAME CONTAINS "artist name"] MAX_RESULTS <max> [FILENAME CONTAINS
"song"] [LINESPEED <compare> <link-type>] [BITRATE <compare> "<br>"] [FREQ
<compare> "<freq>"]
The artist name and the song name are, obviously, treated
the same by the server; confirm this for yourself
on the windows client.
max is a number; if it is greater than 100, the server will
only return 100 results.
<compare> is one of the following:
"AT LEAST" "AT BEST" "EQUAL TO"
<link-type> see 0x02 (client login) for a description
<br> is a number, in kbps
<freq> is a sample frequency, in Hz
The windows client filters by ping time inside the client.
It pretty much has to, and it's easy to see the
result by setting ping time to at best 100 ms or
so, and max search terms to 50. You'll get back
like 3 results, but the client will still tell you
that it found "50 results".
Examples:
FILENAME CONTAINS "Sneaker Pimps" MAX_RESULTS 75 FILENAME
CONTAINS "tesko suicide" BITRATE "AT LEAST" "128"
MAX_RESULTS 100 FILENAME CONTAINS "Ventolin" LINESPEED
"EQUAL TO" 10
[Thanks to Ben Byer <[email protected]> for this contribution. -ed]
201 (0xc9) search response [SERVER]
"<filename>" <md5> <size> <bitrate> <frequency> <length> <nick> <ip>
<link-type> [weight]
<md5> see secton "MD5"
<size> is file size in bytes
<bitrate> is mp3 bit rate in kbps
<frequency> is sample rate in hz
<length> is the play length of the mp3 in seconds
<nick> the person sharing the file
<ip> is an unsigned long integer representing the ip address of the
user with this file
<link-type> see message client login (2) message for a description
[weight] a weighting factor to allow the client to sort the
list of results. positive values indicate a "better"
match, negative values indicate a "worse" match.
If not present, the weight should be considered to be
0.
Example:
"random band - random song.mp3" 7d733c1e7419674744768db71bff8bcd 2558199 128 44100 159 lefty 3437166285 4
202 (0xca) end of search response from server [SERVER]
Format: (empty)
203 (0xcb) download request [CLIENT]
Format: <nick> "<filename>"
client requests to download <filename> from <nick>. client expects
to make an outgoing connection to <nick> on their specified data
port.
Example:
mred "C:\Program Files\Napster\generic cowboy song.mp3"
SEE ALSO: 500 alternate download request
204 (0xcc) download ack [SERVER]
<nick> <ip> <port> "<filename>" <md5> <linespeed>
server sends this message in response to a 203 request.
<nick> is the user who has the file
<ip> is an unsigned long integer representing the ip address
<port> is the port <nick> is listening on
<filename> is the file to retrieve
<md5> is the md5 sum
<linespeed> is the user's connection speed (see login(2))
Example:
lefty 4877911892 6699 "generic band - generic song.mp3" 10fe9e623b1962da85eea61df7ac1f69 3
205 (0xcd) private message to/from another user [CLIENT, SERVER]
<nick> <message>
note the same type is used for a client sending a msg or recieving one
[Commentary: this message causes problems if you consider linking
servers together. With the current one server situation, the server
just rewrites the message it receives with the name of the client that
sent it and passes it to the recipient client. However, in the case
where the recipient and sender are not on the same server, there is
loss of information without encapsulating it. It would have been
better to put both the sender and recipient because if the servers
are ever linked they will have to make a new message type for this
situation. -ed]
206 (0xce) get error [SERVER]
<nick> <filename>
the server sends this message when the file that the user has
requested to download is unavailable (such as the user is not logged
in).
207 (0xcf) add hotlist entry [CLIENT]
<user>
This message is used to add additional entries to the client's
hotlist. The server will send 209 and 210 messages when a user
on the hotlist has logged in or out, respectively.
208 (0xd0) hotlist [CLIENT]
<user>
This message is used to send the initial list of hotlist entries
during the initial login process. It is normally send prior to
to the add file (100) commands. To add more entries to the hotlist
after the initial list is sent, clients should use the 207 message
instead.
209 (0xd1) user signon [SERVER]
<user> <speed>
server is notifying client that a user in their hotlist, <user>,
has signed on the server with link <speed>
210 (0xd2) user signoff [SERVER]
<user>
server is notifying client that a user on their hotlist, <user>, has
signed off the server.
this message is also sent by the server when the client attempts to
browse a nonexistent client. [why don't they just use 404 for
this? -ed]
211 (0xd3) browse a user's files [CLIENT]
<nick>
the client sends this message when it wants to get a list of the files
shared by a specific client
212 (0xd4) browse response [SERVER]
<nick> "<filename>" <md5> <size> <bitrate> <frequency> <time>
<nick> is the user contributing the file
<filename> is the mp3 file contributed
<md5> is the has of the mp3 file
<size> is the file size in bytes
<bitrate> is the mp3 bitrate in kbps
<frequence> is the sampling frequency in Hz
<time> is the play time in seconds
Example:
foouser "generic band - generic song.mp3" b92870e0d41bc8e698cf2f0a1ddfeac7 443332 128 44100 60
213 (0xd5) end of browse list [SERVER]
<nick>
indicates no more entries in the browse list for <user>
214 (0xd6) server stats [CLIENT, SERVER]
client: no data
server: <users> <# files> <size>
<size> is approximate total library size in gigabytes
this message is sent by the server occasionaly without request
Example:
553 64692 254
215 (0xd7) request resume [CLIENT]
<checksum> <filesize>
client is requesting a list of all users which have the file with
the characteristics. the server responds with a list of 216 messages
for each match, followed by a 217 message to terminate the list
216 (0xd8) resume search response [SERVER]
<user> <ip> <port> <filename> <checksum> <size> <speed>
this message contains the matches for the resume request (215). the
list is terminated by a 217 message.
217 (0xd9) end of resume search list [SERVER]
no data.
this messag terminates a list of 216 messages initiated by a 215
client request
218 (0xda) downloading file [CLIENT]
no body.
client sends this message to the server to indicate they are in the
process of downloading a file. this adds 1 to the download count
which the server maintains.
219 (0xdb) download complete [CLIENT]
no body.
client sends this message to the server to indicate they have
completed the file for which a prior 218 message was sent. this
subtracts one from the download count the server maintains
220 (0xdc) uploading file [CLIENT]
no body.
client sends this message to indicate they are uploading a file.
this adds one to the upload count maintained by the server.
221 (0xdd) upload complete [CLIENT]
no body.
client sends this message when they are finished uploading a file.
this subtracts one from the upload count maintained by the server.
300 (0x12c) optional ports [CLIENT]
<port>
This command allows the client to specify optional ports to try for
data connections if the one currently in use is unreachable by other
parties.
301 (0x12d) hotlist ack [SERVER]
<user>
server is notifying client that <user> has successfully be added to
their hotlist
302 (0x12e) hotlist error [SERVER]
<user>
server is notifying client that it was unable to add <user> to their
hotlist. [can you only add registered nicks to your hotlist? -ed]
303 (0x12f) remove user from hotlist [CLIENT]
<user>
client is notifying the server that it no longer wishes to request
notifications about <user> when they sign on or off the server. no
response is sent in return.
310 ??? [CLIENT, SERVER]
client: no data
server: 0
unknown command. server returns 0 regardless of any parameters
316 client disconnect??? [CLIENT, SERVER]
client: no data
server: 0
The server sends this message with a value of `0' when the client is
about to be disconnected.
It is unkonwn what this command does when issued by the client. The
server appears to send the 316 message without disconnected the client
in this case.
[the server seems to send this message if you send it a numeric
greater than 1000. the server will also disconnect you after
sending this message. -ed]
320 (0x140) user ignore list [CLIENT, SERVER]
client: no data
server: <count>
client request to display the list of ignored users.
server returns the number of users being ignored
321 (0x141) user ignore list entry [SERVER]
<user>
server sends each ignored nick in response to a 320 request. the
list is terminated by a 320 message with the number of ignored users.
322 (0x142) add user to ignore list [CLIENT, SERVER]
<user>
server acks the request by returning the nick
323 (0x143) remove user from ignore list [CLIENT]
<user>
server acks the request by returning the nick to be removed from
the ignore list.
324 (0x144) user is not ignored [SERVER]
<user>
server indicates that <user> is not currently ignored in response to
a 323 request.
325 (0x145) user is already ignored [SERVER]
<user>
server indicates the specified user is already on the user's ignore
list
326 (0x146) clear ignore list [CLIENT, SERVER]
client: no data.
server: <count>
client requests the server clear its ignore list. server returns the
number of entries removed from the ignore list.
330 blocked ip list [CLIENT]
332 block ip [CLIENT]
333 unblock ip [CLIENT]
400 (0x190) join channel [CLIENT]
<channel-name>
the client sends this command to join a channel
401 (0x191) part channel [CLIENT, SERVER]
<channel-name>
The client sends this command to part a channel. Server sends this
message to indicate that the client has parted the channel. Note
that this is sometimes sent even when the client has not requested,
so a client _must_ be prepared to accept it at any time.
402 (0x192) send public message [CLIENT]
<channel> <message>
403 (0x193) public message [SERVER]
<channel> <nick> <text>
this message is sent by the server when a client sends a public message
to a channel.
Example:
80's espinozaf hello...hola
404 (0x194) error message [SERVER]
<text>
This message is used to send general error messages to a client that
is logged in. Note: Message 0 is only sent during the login process.
Examples:
User nosuchuser is not currently online.
Channel #nosuchchannel does not exist!
permission denied
ping failed, blah is not online
405 (0x195) join acknowledge [SERVER]
<channel>
the server sends this message to the client to acknowlege that it
has joined the requested channel (400)
406 (0x196) join message [SERVER]
<channel> <user> <sharing> <link-type>
<user> has joined <channel>
Example:
80's WilmaFlinstone 12 2
407 (0x197) user parted channel [SERVER]
<channel> <nick> <sharing> <linespeed>
Example:
80's DLongley 23 7
408 (0x198) channel user list entry [SERVER]
this message is identical to the join (406) message. the server will
send the list of users in the channel prior to the client join command
in this message. joins that occur after the client has joined will
be noted by a 406 message.
409 (0x199) end of channel user list [SERVER]
<channel>
this message is sent by the server to indicate it has sent all informati about the users in a channel
410 (0x19a) channel topic [CLIENT, SERVER]
<channel> <topic>
sent when joining a channel or a new topic is set. a client requesting
topic change also uses this message.
[why didn't they put a field to indicate WHO changed the topic? as
it is now you can only tell that it was changed. -ed]
420 (0x1a4) channel ban list [CLIENT]
<channel>
421 (0x1a5) channel ban list entry [SERVER]
422 (0x1a6) channel ban [CLIENT]
<channel> <user|ip> [ "<reason>" ]
423 (0x1a7) channel unban [CLIENT]
<channel> <user|ip> [ "<reason>" ]
424 (0x1a8) channel ban clear [CLIENT]
Format: <channel>
425 alternate topic (?) [SERVER]
Format: <message>
[The server sends this command when a user joins one of the
predefined channels. It seems to send a default message if the
topic for the channel is the default, otherwise it sends the current
channel topic. -ed]
500 (0x1f4) alternate download request [CLIENT]
<nick> "<filename>"
requests that <nick> make an outgoing connection to the requesters
client and send <filename>. this message is for use when the
person sharing the file can only make an outgoing tcp connection
because of firewalls blocking incoming messages. this message should
be used to request files from users who have specified their data
port as 0 in their login message
501 (0x1f5) alternate download ack [SERVER]
<nick> <ip> <port> "<filename>" <md5> <speed>
this message is sent to the uploader when their data port is set to
0 to indicate they are behind a firewall and need to push all data
outware. the uploader is responsible for connecting to the
downloader to transfer the file.
600 (0x258) request user's link speed [CLIENT]
<nick>
601 (0x259) link speed response [SERVER]
<nick> <linespeed>
602 (0x25a) ??? [CLIENT]
<?>
server returns a 404 with "*gulp* Drink milk, it does a body good!"
603 (0x25b) whois request [CLIENT]
<nick>
604 (0x25c) whois response [SERVER]
<nick> "<user-level>" <time> "<channels>" "<status>" <shared>
<downloads> <uploads> <link-type> "<client-info>" [ <total downloads>
<total_uploads> <ip> <connecting port> <data port> <email> ]
<user-level> is one of "User", "Moderator", "Admin" or "Elite"
<time> is seconds this user has been connected
<channels> is the list of channels the client is a member of, each
separated by a space (ASCII 32)
<status> is one of "Active", "Inactive" (offline) or "Remote" (on a
different server)
<shared> is number of files user has available for download
<downloads> is the current number of downloads in progress
<uploads> is the current number of uploads in progress
<link-type> see 0x02 (client login) above
<client-info> see 0x02 (client login) above
The following fields are displayed for user level moderator and
above:
<total uploads>
<total downloads>
<ip> note: can be "unavailable"
<connecting port>
<data port>
<email> note: can be unavailable
Example:
lefty "User" 1203 "80's " "Active" 0 0 0 3 "nap v0.8"
605 (0x25d) whowas response [SERVER]
<user> <level> <last-seen>
if the user listed in a 603 request is not currently online, the
server sends this message.
<user> is the user for which information was requested
<level> is the user's last known userlevel (user/mod/admin)
<last-seen> is the last time at which this user was seen, measured
as seconds since 12:00am on January 1, 1970 (UNIX time_t).
606 (0x25e) change user level [CLIENT]
<nick> <level>
changes the privileges for <nick> to <level>. client must be admin
level to execute this request
[I have not verified this message since I don't have admin status
on any of the servers. -ed]
607 (0x25f) upload request [SERVER]
<nick> "<filename>"
this message is used to notify the client that user <nick> has
requested upload of <filename>
Example:
lefty "generic band - generic song.mp3"
608 (0x260) accept upload request [CLIENT]
<nick> "<filename>"
client is notifying server that upload of <filename> to <nick> is
accepted, and that the requesting client may begin download
Example:
lefty "generic band - generic song.mp3"
609 (0x261) accept failed [SERVER]
<nick> <filename>
this message is sent by the server when the client that the file was
requested from does not accept the upload request.
[
610 (0x262) kill (disconnect) a user [CLIENT]
<nick>
client request to disconnect a user.
611 (0x263) nuke a user [CLIENT]
<nick>
client request to delete account for <nick>
612 (0x264) ban user [CLIENT]
<nick | ip> [ "<reason>" ]
client request to place a ban on either a specific nickname or
an ip address
613 (0x265) set data port for user [CLIENT, SERVER]
client: <user> <port>
server: <port>
This command is used by administrators to request that another
client set the port used for data transfers to <port>. The server
sends a message with the requested port number to the target
client. NOTE: the target client can change its port number to
whatever it wishes using the 703 command.
614 (0x266) unban user [CLIENT]
Format: <nick | ip> [ "<reason>" ]
615 (0x267) show bans for server [CLIENT]
Format: (empty)
client requests the list of banned ips for the current server
616 (0x268) (ip?) ban list entry [SERVER]
Format: <ip> <nick> "<reason>" <time> <n>
<ip> is the string version of the ip banned
<nick> is the user setting the ban
<reason> is the reason given
<time> is the time_t when the ban was set
<n> is ???. value is either 0 or 1
This message is sent in response to the 615 client request, one
for each ban. The list is terminated with a 0 length 615 message
from the server.
Example:
207.172.245. valkyrie "DoS exploit" 947304224 0
617 (0x269) list channels [CLIENT, SERVER]
Format: (empty)
client requests a list of channels on the server. server responds
with 618/617
server indicates end of channel list using this message.
618 (0x26a) channel list entry [SERVER]
Format: <channel-name> <number-of-users> <topic>
this is the server response to a 617 client request, one for each
channel.
Example:
Help 50 OpenNap help channel
619 (0x26b) queue limit [CLIENT]
Format: <nick> "<filename>" <n>
a client may limit the number of downloads from a particular client.
once the limit for a particular user has been reached, the uploading
client can send this message to notify the downloader that they
have hit the limit and can't have any more simultaneous downloads.
<nick> is the user who hit the limit, <filename> is the file they
were trying to download when they hit the limit, and <n> is the
number of simultaneous downloads allowed.
Example:
joebob "C:\MP3\Generic Band - Generic Song.mp3" 3
620 (0x26c) queue limit [SERVER]
<nick> "<filename>" <filesize> <digit>
This message is sent by the server in response to the 619 client
request, when one user needs to notify another that they have
reached the maximum allowed simultaneous downloads. When the server
recieves the 619 request from the uploading client, it sends the 620
message to the downloading client. The only difference in format is
the addition of the <nick> field in the 620 message which specifies
the username of the uploading agent which is notifying the
downloader that the queue is full.
Example:
joebob "C:\MP3\Generic Band - Generic Song.mp3" 1234567 3
621 (0x26d) message of the day [CLIENT, SERVER]
<text>
Server: each 621 message contains a single line of text
Client: client sends a 621 command with no data to request the
motd be sent. The server will usually send this automatically after
a user logs in, so this command allows a user to reread it upon
request.
622 (0x26e) muzzle a user [CLIENT]
<nick> [ "<reason>" ]
client requests that <nick> not be allowed to send public messages
623 (0x26f) unmuzzle a user [CLIENT]
<nick> [ "<reason>" ]
client requests that the enforced silence on <nick> be lifted
624 (0x270) un-nuke a user [CLIENT]
<user>
625 (0x271) change a user's linespeed [CLIENT]
<user> <speed>