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
|
Add mechanisms for manual start/stop of other links when bandwidth
thresholds are crossed. (e.g. slave ISDN links or equal-cost routes).
Add authentication on control connections with user/password login,
maybe SSL?
In dctrl the connection queue, dialling log etc. should be
independently resizable.
Now using STATUS2 message to pass flags (blocked, forced etc.). This
happens at the same time as STATUS. Really it only needs to happen
when we get a new monitor connection or when the flags change.
The behaviour of the horizontal scrollbar on the dctrl information
window is "unpleasant".
If we have ISDN ippp links that are both dial out and dial in there
is no way to get locking right. If we have more than one link there
are all kinds of races when adding phone numbers to links, dialling
and accepting incoming calls that seem unavoidable. Mainly because
the ISDN layers don't have any form of blocking dial.
-- We can use the lock option to have diald use lock files for
devices other than ttys and thus prevent two dialds from
trying to use the same ippp interface to dial out at once.
If you have static IP addresses you can make the connect
scripts fairly robust too. If you have dynamic IP addresses
I can see no obvious way of knowing if your dial out succeeded
or if the ippp interface just accepted an incoming call.
Rewrite dctrl in Java...
It doesn't make sense to buffer some types of packets (e.g. ntp?).
Does diald allow us to (not) do that?
If we get an EAGAIN back on writing to a monitor pipe we should
try and flush the pipe in order to avoid a stalled monitor from
causing diald to suck resources.
-- Or should we? Maybe the pipe buffer just isn't big enough. In which
case we want to preserve what we managed to write so the monitor
gets something even if not everything.
When dctrl is not displaying the packet queue it should not ask
diald for it.
Need to sort out keyboard accelerators and shortcuts on dctrl's menus.
It would be nice for dctrl to have some obvious display of how
long the link has been up somewhere.
Is it possible to run with no timeout for the connect script and
let the connect script handle everything?
Add Unix domain sockets for monitor connections. I believe they
have better data buffering than simple pipes. Unfortunately dctrl
can't use them as Tcl/Tk does not support Unix domain sockets
(as of tcl 8.0p2 at least)
Firewall rules should be tagged with the file and line no. they
came from (or something equally meaningful for on-the-fly reconfig).
We can use that to give more meaningful log messages.
Have some way of reading config files through cpp or m4 or ??? so
that they can be parameterized.
Impulse timing should start from START_LINK not UP.
Currently you can only add devices to the list to be used while
diald is running (with the "config ..." control command), you should
be able to delete them as well. Actually you can but only by doing
a full "reset" which is overkill and not always something you want.
Log the pid of the ip-up script, put it in its own process group.
If it is still around when we are about to take the link down
kill it off first.
Diald sends data to monitors without caring if they receive it
or not. This is a job for UDP not TCP. In fact diald sends the
same data to all monitors. This is a job for multicasting surely?
We should make the modem access routine more generic (a la proxy)
and add a "device ssh" mode that sets up a pty with ssh to a remote
system running on it so that we can then start pppd through it.
|
