| |
PA2AGA > TCPDIG 10.09.96 07:09l 143 Lines 5910 Bytes #-10891 (0) @ EU
BID : TCP_96_185B
Read: DG7DAH GUEST
Subj: TCP-Group Digest 96/185B
Path: DB0AAB<DB0SL<DB0RGB<DB0ABH<DB0SRS<DB0SIF<DB0AIS<DB0NDK<DB0ACH<DB0ACC<
PI8DRS<PI8DAZ<PI8APD<PI8GCB<PI8WFL<PI8VNW
Sent: 960909/2337Z @:PI8VNW.#ZH2.NLD.EU #:64510 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA17395 ; Mon, 09 Sep 96 22:50:00 UTC
Received: from pa2aga-10 by pa2aga (NET/Mac 2.3.61/7.1) with SMTP
id AA00004422 ; Mon, 09 Sep 96 23:44:38 MET
Received: from pa2aga-10 by pa2aga-10 (NET/Mac 2.3.61/7.1) with SMTP
id AA00005495 ; Mon, 09 Sep 96 18:38:51 MET
Date: Mon, 09 Sep 96 08:41:14 MET
Message-Id: <tcp_96_185B>
From: pa2aga
To: tcp_broadcast@pa2aga-10
Subject: TCP-Group Digest 96/185B
X-BBS-Msg-Type: B
>binary down to something reasonable, but I'm re-thinking the whole
>project.
>
>What I think is really needed as a pair of processes, one for send and
>one for receive that can block when nothing is going through them and not
>continually "loop", wasting processor cycles, and that do AX.25 and
>function as a specialized IP router with features like RSPF.
>
>I also like to run a bbs that takes advantage of unix, with several
>small processes that do specific jobs like user interface, mail routing,
>etc. This makes it possible to do things like use sendmail for a
>packet/internet mail gateway, interface to a web page form and forward
>via FTP fairly easily.
>
>Just some thoughts..
I like 'em. Have thought much along the same lines but decided I
needed to jump into the current fray and see what I could get to
work. It looks like TNOS can handle our current "needs" for now
and replace the aging AA4RE system now in place. One of the things
KO4KS once listed under thoughts for future TNOS's was to split
out each of the servers into separate executables in a more
traditional Unix fashion.
Someone once suggested an inetd-like daemon for Un*x and AX.25.
Maybe a single daemon for each hardwired port? One for TX and
another for RX might be overkill but who cares? The idea is to
make something reliable and portable and maintainable, right?
Then this inetd-like daemon could fire up a bbs or telnet
session or whatnot for incoming connections.
I'd like to see a Unix PBBS written in Perl. Or as simple as
PBBS's are good old /bin/sh shouldn't have any trouble with
external assist. Something like the way MH processes mail.
While external processes to hook AX.25 into the kernal as if it
was any other network interface is nice, there is something to
consider in the Linux AX.25 kernel stuff for establishing a
unique address family for amateur radio connections. Am not sure
of their internal details. Am not sure I like the AX.25 network
functioning *differenty* than the good old standard internet.
Am not really sure how Linux's kernel AX.25 is from ethernet.
73,
--
David Kelly N4HHE, dkelly@tomcat1.tbe.com (wk), dkelly@hiwaay.net (hm)
=====================================================================
The human mind ordinarily operates at only ten percent of its
capacity -- the rest is overhead for the operating system.
------------------------------
Date: Sat, 7 Sep 1996 23:59:21 +0100 (BST)
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Anyone running FreeeBSD?
> What I think is really needed as a pair of processes, one for send and
> one for receive that can block when nothing is going through them and not
> continually "loop", wasting processor cycles, and that do AX.25 and
> function as a specialized IP router with features like RSPF.
If you are going to do that kind of work, do yourself and the whole BSD
community a favour - put your AX.25 and IP over AX.25 in the kernel over
the BSD socket API. Its not much more work that trying to patch bits
of wampes and stuff together and it gives you a much nicer final result.
Alan
------------------------------
Date: Sat, 7 Sep 1996 23:03:25 -0400 (EDT)
From: Jim Durham <durham@durham.UCSD.EDU>
Subject: Anyone running FreeeBSD?
On Sat, 7 Sep 1996, David Kelly wrote:
> On 19:21:02 Jim Durham wrote:
> >The problem with wampes or tnos or any of them is that there is a lot
> >of functionality that is a duplicate of what's in the unix kernel.
> >
(stuff deleted)
>
> Someone once suggested an inetd-like daemon for Un*x and AX.25.
> Maybe a single daemon for each hardwired port? One for TX and
> another for RX might be overkill but who cares? The idea is to
> make something reliable and portable and maintainable, right?
>
> Then this inetd-like daemon could fire up a bbs or telnet
> session or whatnot for incoming connections.
>
> I'd like to see a Unix PBBS written in Perl. Or as simple as
> PBBS's are good old /bin/sh shouldn't have any trouble with
> external assist. Something like the way MH processes mail.
Well, I guess I should have explained what I have going now.
It actually began on this group in 1989 8-).
I modified the original unix version of KA9Q NET by removing
the original BBS code and adding a second SSID to the AX.25
stuff so that I could have an address for IP and an address that
caused fork and exec of a bbs, taling to the NET process using
IPC, originally SYSV message queues, now a BSD socket pair.
The reason for this was that there was no way to tell the NET
process the user was AX.25 and wanted the bbs by the connect
packet. The user send something with a protocol ID in it
before things would happen, hence the second SSID.
The bbs can be called as a "mailer" from sendmail by using a
"front-end" process in between that translates RFC-822 mail
format to ham BBS format. My sendmail.cf file has the ham
"domains" (NOAM, SOAM, OC, AS, AF, ME, EU) in its rule sets so
that mail coming in to a packet address calls the bbs as a mailer.
I also have a process that looks in the var/spool/mail directory for mail
files to the user "import" at this system, and feeds the file to the input
of the bbs. This allows e-mailing files in the old RLI "import/export"
format via e-mail for forwarding. On the other end, the bbs has an
expanded forwarding file that understands forwarding by e-mail, using the
To be continued in digest: tcp_96_185C
Read previous mail | Read next mail
| |
