>
> > Some of you might have noticed that Eric has been rather busy
> > with Real Work and there hasn't been a diald release for quite
> > a while. Hence I am taking over (with Eric's permission) for
> > the foreseeable future.
> >
> > The diald/dctrl I am using is quite a bit changed from the
> > last 0.16.5. Some changes for the better, possibly some for
> > the worse. At this stage what I want is to know what people
> > think needs doing. There is no guarantee it will be done
> > before the next (0.2? 1.0?) release - even if you send patches
> > since they might have no relation to my current code anymore :-).
> > Send mail anyway. I get lonely :-(.
>
> My major thought for diald/dctrl is an improved mechanism for those of us
> running two (or more) diald demons. With the version I have at least,
> diald always talks to the same fifo. this makes using dctrl or any diald
> commands impossible. I have thought that the demon running sl0 should
> talke to pipe0 and sl1 should talke to pipe1 etc. I started to do this,
> but am really not a programmer.
>
I had dual-diald setups working for a while.
1) you can specify the fifo in the diald config file
2) I hacked up dctrl to allow passing the fifo name on the
command line. I'd post the patch, but I think I have
an older version. Let me know if you want it anyways.
3) As an aside, I may have a requirement for dial-out to
several hundred sites. I can't imagine several hundred
slip interfaces and several hundred diald processes.
Any ideas about how to set this up? Diald would need
to select from a pool of modems, and then pick the chat
and pppd config files based on IP address of the target.
Comments?
-- cary
> thanks for listening.
>
> bob
>
> >
> > The (possibly abridged :-) ) list of things done already include:
> > TCP monitor connections (with tcpwrapper support but no login style
> > authentication, yet), optional passing of syslog messages to
> > monitors using MESSAGE (plus corresponding dctrl changes), AF_PACKET
> > support if the running kernel supports it (with fallback to the
> > old SOCK_PACKET), block does not block a manual up request, new
> > block-route option that does not install routes if the link is
> > blocked (not quite complete yet), options to allow nice/scheduling
> > class to be specified, byte/packet counts are collected for active
> > links and dctrl can display them so you know where your bandwidth
> > has gone, changes for dev interfaces such as ippp (which has no
> > blocking dial and which is "interesting" when you have multiple
> > two way links sharing a limited set of ISDN channels :-( ), dctrl
> > can connect via TCP, dctrl has a toolbar, dctrl has a limit to the
> > number of lines it holds in the information window, the dctrl
> > scrollbars don't shuffle around when we change the displayed
> > information, dctrl is not so easily confused if some monitor
> > output is lost. Oh, and some fixes :-).
> >
Non-x dctrl version would be nice.
ENCRYPTION!
I've been kicking around VPN ideas lately. The Diald hack of
starting slip on a pty is a good way to get a stream of
IP datagrams destined for a target into a userspace program.
>From there you can run it through a stream cypher, make
a socket connection to a peer process doing the same thing,
and viola! a VPN.
Am I missing something?
> > At this stage there is no schedule, no change to the "official"
> > diald web site and no "official" release site. If you can offer
> > web or ftp space please feel free but otherwise don't ask :-).
> >
We need this.
> > Mike
Thanks for volunteering.
-- cary
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
