To: perot@pallas.amp.uni-hannover.de
Subject: STiK 2 testing etc.


On Fri, 14 Feb 1997 15:55:03 Peter Rottengatter <perot wrote: 
>
>your suggestion is an option much easier to implement, but people like 
>Martin won't like the idea of having the traffic routines twice.

Then we just tell him that this 'cost' will only happen to those who use 'both'
SLIP and PPP on a computer simultaneously.  This will normally not be the case
for the 'minimal' systems where RAM costs of this order can matter.  They can
still use multiple ports without these costs simply by consistently using one
of the two protocols, by renaming the unwanted STX to STZ (with XBOOT or such).
I really don't think he will be stupid enough to continue fuzzing then.


>> No that does not work.  I would not expect it to anyway, since the original
>> message then originated on a machine with an 'invented' IP number, which will
>> not be recognized by other machines on the net.  Their answers to that message
>
>I know, but some ISPs are kind enough to provide another IP address if 
>useful for the customer. Dunno if your ISP would do it.

Not for free.
I don't remember exactly now, but I think it costs a couple of hundred SEK.


>> What I did after failing to reach my ISP from the Falcon was simply to reedit
>> the configurations of both machines and connect the modem temporarily to my
>> Mega ST.  So it was directly connected to the modem when it reached my ISP,
>> and though I tried to reach them indirectly as well using the computer not
>> connected to the modem this never worked.  That may still be due to something
>> I've missed in the 'netmasking' etc.
>
>Ok, this is almost as nice. I'm still after the demonstration that a 
>machine running my system could act as a real router, that is routing 
>traffic from one different machine to a third one.

I could probably get some more STs set up in a chain, using MIDI and Modem 1
alternately for each link, sort of like:

+--<Modem 2>--[Falcon]--<MIDI>--[ST1]--<Modem 1>--[ST2]--<MIDI>--[ST3]
|
|                             (Example 1)
|
+--[Modem]--<phone>--[ISP]

Then I could sit at ST3 running TRACROUT and see that I get the correct chain
of responses when tracing for IPs of each node, including the ISP.  But since
I have not gotten STiK 2 to speak to the ISP through 'Modem 2' I can also use:

[Falcon]--<MIDI>--[ST1]--<Modem 1>--[ST2]--<MIDI>--[ST3]--<Modem 1>--+
                                                                     |
                              (Example 2)                            |
                                                                     |
                                            [ISP]--<phone>--[Modem]--+

Then I sit at the Falcon, tracing the routes instead.  Unfortunately this only
tests a linear chain, without branches, but if you have PLIP functional we can
use the ST printer port to make a branching net too.  We could then test:

[ST1]--<Modem 1>--[ST2]--<PrintPort>--[ST3]--<Modem 1>--[Modem]--<phone>--[ISP]
                    |
                    |         (Example 3)
                    |
                    +--<MIDI>--[Falcon]

Then I could run the tests alternately from ST1 and Falcon, This way all six
possible (software) transfer paths between the three ports within ST2 are used.
It also means that the router can be effectively tested independent of the ISP,
since no dial-up connection is needed to test local paths.


I have several ST motherboards in various states of disrepair, so fixing a pair
should be no real problem, and I have some spare floppy drives too, but I'm not
sure about power supplies.  If you feel such a test would be valuable, I'm sure
I can borrow (or possibly repair) some PSUs too.  It will take some work to set
this up of course, so I won't bother if you don't feel it would be of value.

Hmmm, I just noticed I'll have to get another pair of MIDI cables too, but I
guess I can borrow some from a friend.  I'll also have to make a couple of
null-modems, but those will be useful for other purposes too, so nevermind.


>Seems you understood, this is perfectly right. The port netmasks do not 
>really matter up to now, they aren't used until connections with more 
>than one host at the other end(s) are supported. For point to point 
>connections the port netmask is not important. You can probably set it to 
>any value right now. This changes as soon as MidiNet, EtherNet or 
>AppleTalk is available, then the port netmask must be carefully set in 
>order to be able to reach all machines.

Now you lost me again, I really don't see why a MidiNet netmask should have any
rules different from normal Midi. Only the low-level driver should be different.
The router must still handle traffic for many machines at the high level end of
the port, since that machine may have other ports in use.

Look at example 2 above. The netmasks on ST2 must handle traffic with ST1 and
with Falcon over the 'Modem 1' port, but must handle traffic with ST3 and with
the entire Internet (via ISP) over the MIDI port.  I don't see how it makes a
difference to the routing whether the other machines are reached directly or
indirectly through that port, since their packets still have to pass through it.

Hmmm, I just realized that it must be the low-level drivers that the port netmask
in the CPX is intended for...  I'll leave the above speculation though, just in
case this final conclusion happens to be wrong.

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