forked from yellowman/nsh
-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO
48 lines (40 loc) · 1.97 KB
/
TODO
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
nsh is a work in progress, diffs are welcome
Cleanup:
* Document all new commands in the manual
* Some formatting for the manual. Simple markdown format?
* Bug hunt
To be implemented:
* handle newer bridge commands
* handle newer 802.11 gunk like rssi display, chan, flags
* ndp controls
* handle kernel sppp/pppoe client
* privsep? multiple daemons? web front end using privsep?
* Build a simple web interface that works through the rc file handler or
via imsg
* copy configs from/to tftp/ftp/http/other parts of filesystem/etc
* RSA certificate generation/management method (isakmpd, iked, sshd)
* Persistent comments/remarks in the config file (to document routes, etc..)
(this was already done for rtable descriptions, and the database could be
used the same way for routes)
* Better support for paging through displays of text X lines at a time
* Something comparable to pipe-grep for matching output
* Context-sensitive help
* Generate example configs for BGP+MPLS, IPv6+BGP, IPv6+Link local GIF,
vether+bridge, and many other interesting feature combinations/scenarios.
Would be nice:
* Perhaps some way for the shell to upgrade itself, or the entire system/
flash image when given a network source for new binaries?
(requires our environment be known, this may be doable with flashrd,
doable in a different way with a typical install, etc)
* Add more diagnostic messages for verbose output where useful
* Convenient/automatic mechanisms to centralize configurations for
tracking/revision control
(can already be done by adding cvs/git/... calls to save.sh)
Known Bugs (or, things that I don't want to bother with right now, but
better not forget later...):
* The kernel does not keep count of information displayed in 'show rtstat'
properly (what else??)
(Very old, possibly no longer valid)
* The kernel/wireless drivers do not use txpower data in any way. Also
TXPOWER_AUTO does absolutely nothing and is not even tracked in the kernel.
(Very old, possibly no longer valid)