Date: Mon, 26 Jul 93 04:30:08 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #190
To: tcp-group-digest


TCP-Group Digest            Mon, 26 Jul 93       Volume 93 : Issue  190

Today's Topics:
                    convers-ping-pong release 1.18
            Minimal IP Routers (was Minimal NOS) (2 msgs)
                       sbrk() declaration ????
                              subscribe 
                         Z80 compilers & co.

Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Sun, 25 Jul 1993 13:38:21 +0100 (MET DST)
From: dc6iq@insi4.etec.uni-karlsruhe.de (Fred Baumgarten)
Subject: convers-ping-pong release 1.18
To: BTITMARS@esoc.bitnet (BARRY TITMARSH)

Barry Titmarsh wrote:

> [...]
> from the convers.conf file
> hostname
> host host:3600
> 
> which will make the Linux kernel (net-2) to make a tcpip connect to the
> host named in the convers.conf :3600 being the port number..
> Over slow links via my router (wnos) the conversd program  appears to hand up
> untill the perm link is established once established any other logins to the
> conversd works fine...

This is normal - You should use this to connect via ethernet, not over
slow links.

> Also i have noticed that perm links between conversd hosts dont work if
> the sym linked copies of the conversd ie kaconversd wconversd lconversd
> are also started, this does work fine if the ka.. l.. w.. conversd bin's
> are real and not sym links as made by the make install process.

symlinks work fine over here, thus I can't reproduce your problem.

> I can say for unix - linux users WW should try this code out Its nice
> again thanks to Fred DC6IQ for takeing the timeout to write it.

BTW: I posted the code into the german NNTP-Net so you missed it in the
     internet world. I will put a copy of the actual source into
     insu1.etec.uni-karlsruhe.de ~pub/hamradio/convers
-- 
Fred Baumgarten       Email: dc6iq@insu1.etec.uni-karlsruhe.de
Kandelstrasse 27                 Packet: dc6iq@db0sao.ampr.org
D-76297 Stutensee-Buechig        IP: [44.130.29.10] (AmPR-Net)

------------------------------

Date: Sun, 25 Jul 1993 23:32:59 -0500 (CDT)
From: Mr. Sampson <ssampson@sabea-oc.af.mil>
Subject: Minimal IP Routers (was Minimal NOS)
To: TCP-Group@UCSD.Edu

I've also been thinking of a minimal NOS with a slightly different target.
After several years of packeting I've seen mostly Net/Rom, then everyone
went The/Net, then a little later many tried Rose.  The advantage of these
systems is the fact that you just plug in a ROM and they have simple
administration.  The disadvantage is they use the AX.25 connection mode.
I can see a role for a ROM chip that doesn't do much more than routing
IP packets in the datagram mode.  Along these lines I've found a Z-80
assembler and have been making various modules (haven't got very far) and
referencing the KISS code for TNC-2 particulars.  Actually I'd like to find
a cheap Z-80 C compiler.  My H-89 with Software Toolworks C would have been
good, alas it bought the farm :-) Out at remote sites you probably don't want
or need a computer for these slow 1200 bps systems, and their function is to
merely relay data.

---

The router program is a proposed design that enables a TNC-2 clone to operate
as a router on an AX.25 network.  It basically listens for its IP callsign
and determines which way the data should be routed for rebroadcast.
Two or more TNC's connected to a diode matrix can be set up on multiple
frequencies, with each having a seperate address.  The TNC also has a Host
callsign for on-the-fly configuration.  It prompts for a password.

No special handling is done on data to/from the COM ports.  The data is
sent as if it were going to be transmitted by or just received by an
HDLC chip.

A. 
 1. Receive data from RAD port.
 2. Each byte is sent to a ring buffer using interrupts.
 3. AX.25 header is decoded, and if sent to our two possible
  addresses (Host or Router) is then processed, otherwise the
  data is dropped and ignored.
 4. AX.25 data for HOST callsign is processed.

   Commands

   IFC <port> <sub-command> <value>

   Ports
    RAD Radio Port
    COM Serial Port
   Sub-Commands
    IPA IP Address
    NET Network Mask
    BRO Broadcast Mask
  
   ROUTE <sub-command> <route> <port> [gateway] [metric]

   Sub-commands
    ADD
    DEL
   Route
    44/8
    44.78/16
    44.78.4/24
    44.78.4.2
    default
   Port
    RAD
    COM
   Gateway
    IP Address of Gateway Node
   Metric
    Number of hops to neighbor

   ARP <sub-command> <IP Address> <port> <callsign>

   Sub-command
    ADD
    DEL
    PUB
   IP Address
    IP Address of neighbor
   Port
    RAD
    COM
   Callsign
    Call sign and SSID of neighbor

 6. AX.25 data for Router callsign is processed.
  AX.25 encapsulation is removed and checked to see if it
  meets IP specs.


B. Receive data from COM port

 1. Each byte is sent to the COM ring buffer using interrupts

 [ processing is the same as for the RAD port ]

C. Transmit data to RAD port

 1. Each byte is sent from the RAD tx buffer using interrupts


D. Transmit data to COM port

 1. Each byte is sent from the COM tx buffer using interrupts


E. Timer interrupts keep everything synchronized

 1. WATCHDOG
 2. TASK SWITCHER
 3. T1
 4. T2
 5. T3
 6. GENERAL PURPOSE
 7. 1/10 SECOND
 8. SECOND
 9. MINUTE
---

Actually this has probably all been invented before, but the node owners are
looking for something new and better, and there's no plug-n-play yet.

Steve N5OWK

------------------------------

Date: Mon, 26 Jul 93 16:42:03 EST
From: dave@eram.esi.com.au (Dave Horsfall)
Subject: Minimal IP Routers (was Minimal NOS)
To: TCP-Group@UCSD.Edu

Mr. Sampson <ssampson@sabea-oc.af.mil> writes:

| Actually I'd like to find a cheap Z-80 C compiler.

Assuming you want a native compiler rather than a cross-compiler,
they don't come much cheaper (or better) than "Hi-Tech C" which was
recently released to the public domain...


-- Dave

------------------------------

Date: 26 Jul 93 09:30:58 GMT
From: Jon Jagger <J.R.Jagger@sheffield-hallam.ac.uk>
Subject: sbrk() declaration ????
To: tcp-group@ucsd.edu

Hi again,
I'm looking at a *very* early version of net with a view to
hacking it down to a *really* minimal system. This would not
be a nos designed for use, but designed to learn from.
I was looking at the sources and saw this in alloc.c

unsigned grabcore(void)
    {
    unsigned int size;
    char * cp;
    ...
    cp = sbrk(0);
    ...
    for (size=256; ; size += 256)
        if (brk(cp + size) == -1)
            break;
    ...
    }


In particular I'm looking at  brk(cp + size).
Now I know that if you have
char x[10];
then
x[4] == *(x + 4)
and
&x[4] == (x+4)

My problem is that brk(cp+size) is rejected by my compiler
as is brk(&cp[size]).
Can anyone enlighted me?

Thanks
JJ
:: Jon Jagger, Comp. Serv., Sheffield Hallam University, S1 1WB, UK
:: Internet J.R.Jagger@shu.ac.uk  AMPRnet 2e1bsd (TCP/IP mailbox soon)
:: Tel 0742 533802/432889 (work/home)     Fax 0743 533840
::               Roses are red, violets are blue,
::               I'm schizophrenic, and so am I

------------------------------

Date: Sun, 25 Jul 93 21:39:50 PDT
From: sutyarjo@chaph.usc.edu ([meidi])
Subject: subscribe 
To: tcp-group@ucsd.edu

subscribe 

------------------------------

Date: Mon Jul 26 20:50:02 1993
From: iiitac@pyr.swan.ac.uk
Subject: Z80 compilers & co.
To: tcp-group@ucsd.edu

HiTech Z80 C compiler for CP/M is free. That should do what you want.

Alan

------------------------------

End of TCP-Group Digest V93 #190
******************************
******************************