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


On Mon, 17 Feb 1997 12:22:29 Peter Rottengatter <perot wrote: 
>
>On Sat, 15 Feb 1997, Ronald Andersson wrote:
>
----- snip ----- re: personal IP numbers
>>
>> Not for free.
>> I don't remember exactly now, but I think it costs a couple of hundred SEK.
>
>That sounds like a lot of money ! How does it convert to DM or US$ ?

I'm not sure.
I haven't checked it in a long time, but I can convert other ways.

15 halfkilo packets of decent quality coffee,
or a carton of 10 20-packs of my favourite cigarillos.
(Yep!  These two are my main staple-wares ;-)


----- snip ----- re: STiK 2 Intranet examples
>
>I'd done these myself if the problem with the invented IP number had 
>not existed. I think you must have the same problem ? I might be able 
>to do it soon, after I got my Linux machine set up, using it for IP 
>masquerading, or just doing a chain : PC -- ST -- ST.

Right, I'd temporarily forgotten that I shouldn't access Internet IPs
except on the machine haveing direct access to the modem.  But it should
not be any real problem for you to provide optional masquerading either.
Just allow definition of a specific port for this, and let the router
keep a table of all connections that use this port, translating the local
IP at the 'other' end of the connection to and from the dial-up IP for
incoming and outgoing packets respectively.

Alternatively, you could do this by implementing the TCP patch I describe
in a mail I sent you earlier today.

I definitely think that 'masquerading' should be provided at some stage.


----- snip ----- re: PLIP for intranet branches on STs
>
>That would be terrific. I got the MiNTnet PLIP source code, and when I 
>was bored with PPP for a moment, I started with the CENTR.STX. But I soon 
>moved to PPP again, so the CENTR.STX is still in an early state. If you 
>want you can proceed with it.

Well, I'm not sure I have as firm a grasp on all stuff I should have as yet.
Still, there's no way short of trying it to find out either.  Send me the code
and I'll see what I can do with it.  If I find my network knowledge lacking I
will just have to study some more before proceeding.


----- snip ----- re: actually setting these networks up for testing
>
>Sounds like a major effort, so we should think it over well.

Yep, but eventually I will do it anyway, just for the fun of it.


>> 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.
>
>Easy. With a Midi connection, you have a point to point connection. This 
>means, if a route (a line in ROUTE.TAB) points to the midi port, the 
>driver does not need to check, it simply sends the packet away. Either 
>the peer (the other end of the point to point connection) is the 
>destination, then it keeps the datagram, or it forwards it again. For 
>both cases the local host does not need to distinguish.
>
>The situation changes if a 'real' LAN, like MidiNet is used. If the 
>datagram can be delivered locally (the destination is inside the LAN), 
>the datagram is sent there directly. Otherwise the datagram must be sent 
>to a gateway in that LAN, which is specified by the route. For distinguishing
>between these cases the port netmask is needed : If the destination IP 
>ANDed with the port netmask equals the template (the 'LAN address'), the 
>destination host is inside the LAN, and the datagram can be delivered 
>directly. Otherwise the gateway address is used as the next hop.
>
>Got me now ?

Yep, and it does fit my assumption at the end of my previous mail, so I was on
the right track there.  The port netmask is only used by the STX that drives
the port, whereas the netmask in ROUTE.TAB is used by the kernel's router.
(and then as I read on I found it wasn't so...)


----- snip ----- re: some of my speculations on the wrong track

>> 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.
>
>Yes, it could be done inside the low-level drivers. I decided to put this 
>into the IP core's router because things like the routing table are more 
>consistent and less confusing then, and duplicated code is avoided.

Oh, I see, then I was wrong above too.  It is actually only the router which
handles all the netmasks.  Then I think that mask should be in ROUTE.TAB too.
Not that this matters greatly, but I like being able to edit a single file to
adjust stuff that is related to each other.

Here we have four codes that affect routing and are handled by the router, yet
one of them is only alterable via CPX which I find inconvenient.

I've noticed that STIK.INF also contains three IP-related numbers per port,
including the actual IP number and what I think is the port netmask.

I'd prefer having all the routing info in a single editable file, which should
be read by the system on startup, although it can be overridden by CPX or even
reread by CPX command (as in the current CPX) to activate changes.  After all,
the gateway IP is in ROUTE.TAB, and its use is dependent on the port netmask.
I suggest you update the ROUTE.TAB structure to be:

subnet_number subnet_mask port_name port_mask port_gateway


I have assumed that it is legal to have more than one route line per port,
so that routing to several subnets needing indirect access is possible.
I just thought I should ask you to confirm that this is so, so I know.

Actually this means that both port_mask (new) and port_gateway(old) would
have redundant definitions, so it may be better to split ROUTE.TAB into
two sections.

One section would specify:

subnet_number	subnet_mask	port_name

and multiple subnet definitions would be allowed per port, since this means
that various IP-number groups will be routed either to or through this port.

The other section would specify:

port_name	port_IP		port_mask	port_gateway

and only one such line per port would be allowed, since there can only be one
physical network on a given port, and IP numbers too must be unique.  Point
to point ports would not really need to be mentioned in this second section,
unless you decide to also move the other stuff from STIK.INF into it.
That is what I would really prefer, since this reduces two files to one.

The CPX could easily scan the file to find the lines beginning with port names,
and extract the needed information, but when writing CPX data it is necessary
to carefully copy those lines not beginning with port names, to preserve user
remarks.  This means a new file should be opened for this copying and that the
old file should be deleted after it so the new file can be renamed.  I think
ROUTE.TMP would be a good name for the intermediate file.

You must decide for yourself of course, but I really think the above method is
more logical and useful than the current one.

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