File: TODO

package info (click to toggle)
nc6 1.0-1
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k
  • size: 2,108 kB
  • ctags: 1,581
  • sloc: ansic: 12,966; sh: 6,695; makefile: 541; yacc: 288; sed: 16
file content (134 lines) | stat: -rw-r--r-- 5,320 bytes parent folder | download | duplicates (4)
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

big features to be added in the next releases:

- ascii and hexdump logging of connections
- UDP path mtu discovery support
- ssl support
- simple (maybe even advanced/stealth?) portscanning
- telnet support?
- plugin capability



the following is a mail which was sent to me by Mark Doll on Mon, 28 Jan 2002.
Mark has pointed out some very interesting features which will surely be added
in the next releases of netcat6.


Mauro Tortonesi schrieb am 27.01.02:

> please, let me know if you'd like a particular feature to be implemented
> in netcat6 - now that UDP works the TODO list for the next releases is
> _really_ empty.

Hmm, when I look at the help page of netcat v1.1 (from the SuSE 7.3
Distribution), there are some interesting features:

doll@borg:/.amd/home/doll >netcat -h
[v1.10]
connect to somewhere:   netcat [-options] hostname port[s] [ports] ...
listen for inbound:     netcat -l -p port [-options] [hostname] [port]
options:
        -g gateway              source-routing hop point[s], up to 8
        -G num                  source-routing pointer: 4, 8, 12, ...
        -h                      this cruft
        -i secs                 delay interval for lines sent, ports
                                scanned
        -l                      listen mode, for inbound connects
        -n                      numeric-only IP addresses, no DNS
        -o file                 hex dump of traffic
        -p port                 local port number
        -r                      randomize local and remote ports
        -s addr                 local source address
        -t                      answer TELNET negotiation
        -u                      UDP mode
        -v                      verbose [use twice to be more verbose]
        -w secs                 timeout for connects and final net reads
        -z                      zero-I/O mode [used for scanning]
port numbers can be individual or ranges: lo-hi [inclusive]

Since in IPv6 the source routing is done by an extra header, it's
use is not that limited and may be interesting (but also hard to
implement? i don't know). IMO it's not that important and maybe it
better fits into ping6 anyway.

Another interesting features is port scanning, but since nmap does the
same (and better), i don't think it's worth implementing it here.

If you're curious, portscanning with netcat looks like this:

doll@borg:/.amd/home/doll >netcat -v -z localhost 1-1023
localhost [127.0.0.1] 849 (?) open
localhost [127.0.0.1] 742 (netrcs) open
localhost [127.0.0.1] 515 (printer) open
localhost [127.0.0.1] 389 (?) open
localhost [127.0.0.1] 139 (netbios-ssn) open
localhost [127.0.0.1] 113 (ident) open
localhost [127.0.0.1] 111 (sunrpc) open
localhost [127.0.0.1] 37 (time) open
localhost [127.0.0.1] 25 (smtp) open
localhost [127.0.0.1] 22 (ssh) open

or randomly with 1 second between each try and more verbose (show refused
connects, summary of send/recv bytes)

doll@borg:/.amd/home/doll >netcat -v -v -z -r -i 1 localhost 20-25
localhost [127.0.0.1] 22 (ssh) open
localhost [127.0.0.1] 21 (ftp) : Connection refused
localhost [127.0.0.1] 25 (smtp) open
localhost [127.0.0.1] 24 (?) : Connection refused
localhost [127.0.0.1] 23 (telnet) : Connection refused
localhost [127.0.0.1] 20 (ftp-data) : Connection refused
 sent 0, rcvd 0

(The intervall option is not very usefull because of it uses seconds
instead of i.e. milliseconds.)

The integrated hexdump feature is nice, but also ugly if you want to log
ASCII Protocols like HTTP. It looks like this:

> 00000000 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 30 0a    # GET / HTTP/1.0.
> 0000000f 0a                                              # .
< 00000000 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d # HTTP/1.1 200 OK.
< 00000010 0a 44 61 74 65 3a 20 4d 6f 6e 2c 20 32 38 20 4a # .Date: Mon, 28 J
[...]

IMO you really don't want to test non-ASCII protocols with netcat. A
simple logger which logs everything in simple ASCII prepended
optionally with a stamp and either < or > to indicate direction (and maybe
also to syslog?) should be easier to implement and much more useful.

Thus my suggestion for new features is to implement ASCII-Text
logging with timestamps and eventually with a syslog option.

I don't know how you think about "featuritis", but I dislike it! Ok,
sometimes it's more convenient to have features integrated although the
same can be achieved by simply combining two programs, i.e. recursive grep
by combining grep and find.

But espacially this case is a good example of useful "featuritis",
because it's one of the most heavily used features of grep.

So I think logging may also be a heavily used feature of nc6, and it's
worth to implement it, although normally I prefer things like

doll@borg:/.amd/home/doll >cat |tee httptest.in|netcat www 80|tee httptest.out

to log a session, or better than that, to log into one file and with time
stamps

doll@borg:/.amd/home/doll >cat | { while read; do  echo "`date` > $REPLY"
>> log.txt; echo $REPLY; done; } | netcat -v -v fs0 smtp | { while read;
do  echo "`date` < $REPLY" >> log.txt; echo $REPLY; done; }

Looks ugly, I know, but if you use while loops and bash's read builtin as
often as I do, you somehow get used to it...

Hope this helps to fill your next nc6 version's ToDo list!

Regards,

Mark.