To: perot@pallas.amp.uni-hannover.de
Subject: Re: [2] TCP patch for STiK 2                                                        


On Tue, 18 Feb 1997 13:28:22 Peter Rottengatter <perot wrote: 
>
>On Mon, 17 Feb 1997, Ronald Andersson wrote:
>
>> This set me thinking even further on the subject of pseudo ports, and I think
>> I have come up with a way to make use of the TCP routines in STiK 1 for STiK 2,
>> without having to wait for Dan to deliver a module (if ever).
>
>I must say the idea is intriguing. I think I haven't understood 
>completely what you suggest. Do you mean to give ST1K access to the 
>serial port to do the networking, and let ST2K do the client interfacing ? 

Yes, or rather:

	ST1K does the modem-Internet networking
	ST2K does the local Intranet networking

Btw: ST1K and ST2K are convenient handles for us to use here, but I suggest
     we do not use this terminology in the list.  There I am still using
     STiK 1 and STiK 2, since I still regard STiK 2 as the natural next
     official STiK version.  Some people are agitating for a definite split
     and I do not want to make their efforts any easier by split terminology.


>In that case very little of ST2K is used. Or do you mean the other way 
>round, ST2K doing the low level stuff, with the clients interfacing to 
>ST1K ? I combined both to suggest a modification, please compare it to 
>what you really have in mind, and tell me. You find it described below.

Ok, from my first glance at it I find it resembles my extended idea, that
I did not fully describe, quite closely.  But, more on this below then.


>> One problem is that STiK 2 must have an identical cookie as STiK 1 had, and two
>> such cookies can not coexist peacefully on the system.  This is easily solved
>> by making new copies of STIKTSR.PRG and STIK.ACC, renamed to ST1KTSR.PRG and
>> ST1K.ACC .  We then use a file editor to change each "STiK" sequence in those
>> files to "ST1K".  That solves coexistence completely.  Next we have to make
>> them work together, as follows.
>
>This MIGHT work. I've seen various programs with do the test for the 
>cookie name with four CMP.B #letter, (Adunno)+ instructions. You won't 
>find those. But sure, we can hope that ST1K is written in a better way.

If not, it is not really that hard to find it anyway.  Immediate byte arguments
are usually compiled to $00xx with xx being the byte constant, so we can check
for that format too and shortly find all points to patch anyway.


>> We need a dummy TCP.STX, which simply sends each client TCP command on to the
>> old ST1K interface and vice versa.  It should also remember the IP number of
>> the client port for each channel, and translate between the multiple local
>> numbers of STiK 2 to the single local number of STiK 1.  Thus we already have
>> IP masquerading for TCP.
>
>What is this masquerading good for ? What's the meaning of multiple local 
>numbers if ST1K does the IP traffic ? Note these questions arise probably 
>because I haven't understood fully your suggestion.

ST1K handles IP with Internet ONLY.  ST2K handles all local stuff, including
all contact with clients.  This means that any stuff from other machines to
Internet needs to be sent through ST1K, which enforces masquerading since it
only knows a single IP.  ST2K however knows what IP the real client of that
connection has in the local net, and can translate IP headers accordingly.

But I've realized that the simple method wouldn't allow clients on the other
local machines anyway, because they would need a TCP STX too, and the one
used for the simple method only works on the machine with the modem...!
The complex method does allow that, since all machines then run the same STX,
and ST2K handles all IP traffic including that to the modem.

And the masquerading should be built in 'properly' anyway, not dependent on a
(hopefully temporary) patch.  Since it has to do with IP handling, perhaps the
router should do it in transferring packets to/from a particular port.  I am
not sure were best to place it, but I know we will need it eventually.
(In fact I have already needed it in my trace routing tests...)


>> At boot, this module searches for the ST1K cookie interface, and refuses to be
>> installed if not present.  Otherwise it prepares a pointer to a routine which
>> will initialize ST1K.ACC in much the same way that your STiK 1 dialer does,
>> but without actually dialling, or transmitting anything at all.  It should
>> however tell ST1K.ACC the IP number used in the last STiK 2 dialling, so ST1K
>> has a legal way of talking to Internet.  At the end of that init routine the
>> pointer should be repatched to point to a function which handles the passing
>> of calls to ST1K, whereafter the init function should call that function.
>
>I guess this describes how to link a module on top of ST1K ?

Yes, exactly.


----- snip ----- re: lots of stuff quoted from my last mail
>>
>> Actually I have thought of a method to do fully local TCP as well, but I do
>> not find it reasonable to implement this due to the complexity of it.  It
>> would waste time that would be better invested in making a proper TCP STX.

That of course depends on how much work a proper TCP STX demands.


>> But the method to get non-local TCP should be a lot simpler to implement,
>> and uses modules similarly to what the 'real' implementation will later,
>> so that updating is then mainly a matter of replacing those modules and
>> disabling ST1KTSR.PRG and ST1K.ACC.

Actually I've had some doubts about how clients on other machines than the
one with the modem would work with the simple method.  This requires the
more complex solution, similar to what you describe below.


>Here is my modification to your idea. It might be a little more effort, 
>but if sounds (dunno if it is actually) more self-contained. Your 
>description made me think about a ST1K (which itself is precisely what 
>you described above), that is completely encapsulated into a ST2K module. 

I was unsure whether a single module could do it, but I think you're right.


>This means a ST2K installation is in place, and ST1K together with a link 
>STX form the TCP module. To that end I view ST1K as a black box with two 
>ends, each providing data in/out. Data going into the TCP end comes out 
>at the IP end as an IP datagram, and vice versa. The TCP end is pretty 
>much what we need, so calls of the STX client interface are directly 
>passed to the corresponding ST1K calls.

This was my intention too, for both versions of my idea, though the STX will
also need to remember the local IP numbers of the various connections, since
ST1K has no support for this.  Note that this will be needed regardless of
any actual masquerading, since all outgoing packets will be given the source
IP which ST1K uses.  I do not know about incoming packets.  It is possible
that ST1K assumes they are all valid, ignoring the IP, but I doubt it.

If not, then translation of destination IP's to the one used by ST1K is also
needed. The real local IP's should be remembered per channel however, so that
the correct stuff reaches the right client on the proper machine  (complex ?).
Again note that this has nothing to do with masquerading, but only with the
single-IP  nature of ST1K.

Note that in the above I used 'incoming' and 'outgoing' as viewed by ST1K,
although actually it may all be local traffic.

Whooosh! I'm even managing to confuse myself now. I hope you see what I mean.


>The IP end, however, appears as a serial interface. We need a way to intercept
>it, extracting the (TCP) data from the IP datagram, and send it away using the
>ST2K core IP calls. The same way data coming in from the ST2K core for TCP is
>padded with a dummy IP header, and fed into the IP end of ST1K.

Yep, and for this I envisioned having to patch a dummy driver into BCONMAP etc.


>This way, the final TCP.STX just replaces the dummy STX and the ST1K, 
>without changing anything else in the ST2K installation. Even better, all 
>flexibility of ST2K prevails, and you can network several machines as 
>before. However, the hard part is to gain proper access to the serial 
>interface of ST1K. Must be done by intercepting some TOS features ?

It could be done that way, but could have secondary effects (risky).
I prefer patching a dummy driver into the BCONMAP structure etc.  I won't go
into detail on this, because I think you know this stuff better than I do.
This way the device lib of ST1K will call our 'driver' routines directly,
to read/write data just as they would call corresponding routines of normal
serial drivers.  The only problem with this is that at this level the data
may not be packet oriented, or is it ?


>Maybe SERIAL.STX need to be slightly modified too, in order to be able
>to cope with the modified TOS serial handler.

No, I don't think that is necessary.  With the 'dummy driver' approach it will
not be, since we simply will not use that driver for other purposes, and even
if we do patch GEMDOS/BIOS, these patches would themselves 'know' whether a
call should be affected or not, since they reside in the STX sharing data.


>Please compare this with your's, but please add some clarifying details 
>to your description too, as I'd like to see if and why your suggestion
>is superior.

I wouldn't say superior... our concepts here are almost identical !!!
We only differ in how to access the 'hidden' interface of ST1K, and you
do not seem very firmly decided there whereas I too am open to both methods.

We could do both.

This way we have a reserved device code, so the patched Fopen can ignore all
normal calls and leave them unaffected, but register the handle returned to
ST1K when the special device is active (Bconmap).  The patched Fread/Fwrite
etc simply leave all calls using other handles unaffected to the original TOS
routines, but transfer data for the special handle to/from STX packet buffers.  Bis
BIOS functions would also know when to leave calls unaffected by the active
device, so I see no problems arising from this.

Do we know at what level ST1K handles these data transfers ?
Is it enough to patch GEMDOS or must BIOS too be used ?

We really want packet oriented data, and I'm not sure if ST1K always reads and
writes entire packets.  The real problem may be those writes, because for the
reads the packets are prepared by the STX, not by ST1K.

These are some of the complications I mentioned before, but perhaps you know
some answers to these questions that can simplify things.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
