Received: by maskin (mbox dlanor)
 (with Cubic Circle's cucipop (v1.31 1998/05/13) Mon Apr  5 21:49:26 1999)
X-From_: owner-stik-beta-testers@list.zetnet.co.uk Mon Apr  5 11:16:15 1999
Received: (from uucp@localhost)
	by maskin.ettnet.se (8.9.1a/8.8.8) id LAA22995
	for <dlanor@oden.se>; Mon, 5 Apr 1999 11:16:15 +0200 (MET DST)
Received: from UNKNOWN(194.247.47.34), claiming to be "spodden.zetnet.co.uk"
 via SMTP by maskin, id smtpdAAAa005bF; Mon Apr  5 11:16:09 1999
Received: from majordom by spodden.zetnet.co.uk with local (Exim 2.05 #1 (Debian))
	id 10U5SL-00030C-00; Mon, 5 Apr 1999 10:14:09 +0100
Received: from maskin.oden.se (maskin.ettnet.se) [193.220.120.1] 
	by spodden.zetnet.co.uk with esmtp (Exim 2.05 #1 (Debian))
	id 10U5SI-000303-00; Mon, 5 Apr 1999 10:14:06 +0100
Received: (from uucp@localhost)
	by maskin.ettnet.se (8.9.1a/8.8.8) id LAA22919
	for <stik-beta-testers@list.zetnet.co.uk>; Mon, 5 Apr 1999 11:13:44 +0200 (MET DST)
Date: Mon, 5 Apr 1999 11:13:44 +0200 (MET DST)
Message-Id: <199904050913.LAA22919@maskin.ettnet.se>
Received: from UNKNOWN(193.220.122.46), claiming to be "oden.se"
 via SMTP by maskin, id smtpdAAAa005a2; Mon Apr  5 11:13:26 1999
To: stik-beta-testers@list.zetnet.co.uk
From: dlanor@oden.se (Ronald Andersson)
Organization: Atari
Subject: STinG CNgetinfo and alternate routing methods
X-Mailer: NEWSie Version 0.94 (Atari)
X-Sender: POPwatch v2.91 (Atari)
Sender: owner-stik-beta-testers@list.zetnet.co.uk
X-Loop: stik-beta-testers@list.zetnet.co.uk
Precedence: bulk
Reply-To: stik-beta-testers@list.zetnet.co.uk

Hi Dan,

as you can see I thought it was time to change the subject, to reflect the
way our discussion has turned.  I have now read through the RFC 1631 that
you mentioned, and it was quite interesting, though not directly applicable
to STinG.  The NAT method of using an 'array' of globally valid addresses
to dynamically mask LAN machines by masking only their IP number is one
thing we can't do, since normal users only have one globally valid address.

Also, it seems a bit of overkill having to route ALL traffic through one
specific machine, including even traffic between two other machines that
have a direct connection.  This would impose heavy delays for all local
traffic.

Apart from those differences the NAT methods seem quite similar to ordinary
masquerade.  The comments on TCP sequence numbers and acknowledge numbers
are directly relevant to the changes I am working on for the 'high-level'
masking of MASQUE.STX.


>On Sun, 4 Apr 1999, Ronald Andersson wrote:
>
----- snip ----- re: description of problems finding local IP of 'listener'

----- snip ----- re: your description of dual IP use on a Mac

Ok, but a big question for me is what parameters they use to open those
connections.  Are you saying they specify _only_ the port numbers, just
like STiK's TCP_open call for listening connections ?


>	Now how does this translate into the above problem.  Easy it's a
>question of domains.  If you are running a system with 'masqueraded' ip
>address, clients grab the masqueraded IP addres only.

How ?  That address is only known on the machine with direct modem link
to the ISP (or other direct Internet connection).  It is never passed to
any of the other machines.  Or do you mean the opposite, that clients
grab an address valid internally on the LAN for the given machine ?


----- snip ----- re: NAT-like routing with possibly broken masking

Any masquerading may be broken by newly implemented protocols that pass IP
information in high-level protocols that are not implemented by the masque
modules.  That is not really something to worry about I think.  When it
does happen it just means that a new masque module must be written.
(Not masque.stx itself, but submodules of it for high-level masking.)

Much worse is what this appears to mean for the bandwidth of _all_ traffic
on the entire LAN.


>	Now there is a second route that is much easier to impelement and
>avoids the problems we have before encountered.  When does an application
>need to know what it's IP address is?  When it is going to be passing the
>IP addres across the network.  Such as dcc, ftp, icq or a host of other
>applications.  Now when we pass the IP address, of course we need the IP
>address to be valid for the client no matter what happens (local traffic
>or external traffic).  In this case there is only the one IP address that
>fits the bill, that's the Real IP address of the stub router for the local
>network.

Yes of course, that is what high-level masquerade is all about.  Replacing
the IP+port specification sent in a high-level packet (eg: FTP) by similar
data using the valid Internet IP + port number assigned from the range that
is reserved for masking.  But this has NOTHING to do with the local IP
put in the CIB...  That must always be the IP number of the port driver
that leads to the route if future packets.  But of course, by forcing all
traffic to pass a router that IP address will then be a constant, so you
are correct in that the STiK method of using a constant can then work for
such a modified STinG version too.

But the cost of getting this constant will reduce bandwidth of the entire
LAN to a fraction of what it would otherwise be.  One of the strengths of
STinG is that routing is done in a distributed fashion on each machine,
which gives much better speed.  But that is also what causes the STiK
TCP_open function to be insufficient to deduce the route for a listening
connection, as described previously.  Perhaps we can find another way
of distributing the 'stub' router too...  (I think it can be done.)

That could allow STiK-like use of local IP, without requiring that all
traffic must pass a special router machine, though naturally any traffic
intended for Internet would still get routed to the modem machine which
would still have to handle the real masking/unmasking of packets.

Devising this method will take some further thinking and discussion but
I am sure it can be done.


>	This increases trafic on the router on the system.  That's a
>problem if you have slow machines, but this is why you will often see
>linux users setting up a slower older cheaper machine in the corner to
>operate as the router.

Eh..?  If that machine is going to handle _all_ the traffic of the LAN,
then it should be as fast as possible, so as to not become a 'bottleneck'.
But of course, for very small LANs it may not matter much, and I suppose
the users prefer to have their best machines for general purpose work.


>But it has the benefit that no data in packets
>needs to be manipulated internally.  The only manipulation needed is when
>the router is operating and linking the connections.  Providing a proxy or
>tunneling service to the rest of the computers on the network.

I don't see how 'tunneling' can apply here, and I do not see what you mean
by proxy.  We can only assume one ISP-supplied address valid on Internet,
so we'll have to do normal masking by use of TCP/UDP port numbers and ICMP
'identifier' codes.


>	I'm not certain what the full function of your masq.stx is, but
>ideally this would provide/replace the current open functions in the API.
>Providing network requests for these functions to the actual host/router
>machine.

No.  It does not alter any API functions whatever in any way whatever.
It is written purely as a STinG IP-level input/output port driver that
filters data packets in both directions, while also maintaining data
structures for all masked connections/datagrams.

Athough it could possibly modify the API, just like LogSTinG.Prg does,
I currently do not have any plans for such modifications.


>	The only downside to this method is the increased trafic on the
>router.  If on a 3 machine network, machine wants to connect to something
>on machine 2, it still handles it's traffic trough machine 1 which is the
>router.

And on a greater LAN that router could quickly become overloaded just by
local traffic, since this concept requires that _all_ traffic pass it...

That is what needs to be changed of course.  Some of its work, but not
the main masquerading work, needs to be distributed amongst the
individual machines of the LAN in a slightly different manner from how
the current distributed routing of STinG works.  That should allow all
traffic to/from any given LAN machine to use a constant local IP, with
no difference being made between pure LAN traffic and traffic with
Internet, except for the masquerading done at the 'modem machine'.

Hmmm.  I begin to see several different approaches to this, any of which
might turn out well.  I suppose some experimentation is in order.  Too
bad that Peter can't participate in this yet, since some of the ideas do
require minor kernel patches.

Still, some of the variants could be handled just by patching TCP.STX,
which I do have the sources for.  Masque.Stx also needs completion of
the high level masking, but that does not need to be complete in order
to test the basic methods.


>	What's the benefit of this sytem... All clients should work by
>default.  DCC, ftp etc.  They are always passing the real ip address for
>the network across the connections.

Both Internet and the LAN are networks, so that was a bit vague.  ;-)
I assume that you here mean network=LAN and not network=Internet.


>They don't need to worry about this
>not being their IP address, since they are referencing the packets by a
>connection handle.  A connection handle that is linked to the real
>connection handle on the stub router of the system.

I'm not sure exactly how you mean that, since IMHO the router should not
deal with API-level handles at all, but only with IP addresses and port
numbers.  Possibly you do mean that the IP_number+port_number+protocol
combinations constitute a sort of 'handle' for each masked connection.
That is actually quite similar to how I think of them, and to how I treat
them in my masquerade routines.


----- snip ----- re: Your statements on speed drawbacks of router
>
I do not agree that the router load will be negligible even for small
networks, but fortunately I do not think that it will be necessary to
pass all local traffic through it as the model you describe requires.
I think it can be done so that only traffic intended for Internet is
passed via the router.  For all pure LAN traffic the routing can be
done in a distributed way almost identical to what is now used.


----- snip ----- re: some stuff no longer relevant


----- snip ----- re: quoting stuff from other stacks
>> 
>> I agree that it would have very little relevance.
>> 
>
>	Not entirely.  If someone says an apple is not an apple, it's
>sometimes usefull to cite the dictionary definition of an apple.

I don't think we have so clear-cut a situation here.  It's more like
a difference of opinion about the number of healthy appleseeds inside
the core.  Neither STiK nor STinG uses methods that conform exactly
with how any other stack does things, and it serves no purpose to
argue about which deviations are more serious and which less.

The important thing is that the dialog (finally a dialog ;-) has now
resulted in some ideas that can solve the problems under discussion.


----- snip ----- re: 'Unadapted' compatibility of STinG with STiK
>
>	Yes it is a good score for STiNG.  It was a better score before
>peter put in the CAB in the CIB.

I think there must be some misunderstanding here.  The use of the CAB
structure does not alter any data elements in the CIB structure.  It is
just a substructure used to access some of the elements in a different
way for a C source, but with identical offsets in the binaries.


----- snip ----- re: limited STiK TCP_open flexibility
>> 
>> NB:  Correctly opened listening connections for FTP PORT commands or
>>      IRC DCC commands should be listening ONLY for packets from one
>>      specific remote IP. That's not possible with old STiK TCP_open.
>>
>
>	The client does not necessarily know which machine is going to
>connect to it.

That is not so.  It must know this for both cases stated.


>With dcc yes one generally does know what ip address is
>goig to connect to it. With ftp it is possible to have a seperate machine
>vending files than the one handling the control connection.

AFAIK that is not the case.  It is possible for a client to order two
servers to transfer files between each other, so that the client is not
directly involved with the data connection, but it must then maintain
two separate control connections (one for each of the servers).  And it
must naturally start by opening those connections, meaning it must know
the IP addresses of both servers.  It must then send PASV command to
one of them and use the returned data in a PORT command to the other.
Thus the local IP of the client is never used for the data transfer.

What you describe is something else, and would mean that a client could ask
one server to make another one do transfers.  That is not what I find in
any RFC I've seen.  Please correct me if I am wrong though.

Hmm, I just realized that what you said would be correct from the point
of view of one of the servers in my example, rather than the client.
But we were actually discussing the client, not any servers, and not that
very complex mode of usage which I doubt that any available client can
support.  (Nor do I see any reason to use it if they did.)


----- snip ----- re: message 'cut' and/or ignored
>
>	I read through most of your messages note, I did say most.  I cut
>and clip when you seem to have misunderstood me and gone off on some long
>post along a seperate line.  

But you can't be sure that it does not lead back to relevant things if you
don't follow all of it, and then perhaps some things that seemed not to be
relevant have turned out to be so.  But how you read mail is up to you...

The main part of my 'complaint' was that you had ignored several questions,
and rejected several suggestions without explaining why.  Now that you have
addressed some of these things in this mail we can forget about that.


----- snip ----- re: STinG calls and reasons for incompatibility
>>
>> The only reason why this incompatibility exists is because we CAN'T
>> resolve a future local IP for a connection given only the local port
>> number, because that provides NO routing information.  For that the
>> known future remote IP must be used, which is not passed by STiK's
>> TCP_open call for listening connections.
>> 
>
>	You don't see the insertion of the CAB structure as an
>incompatibily?

No, I do not, for reasons that I will explain in detail.

Here is the CIB as 'traditionally' defined by STiK:
----- old STiK TRANSPRT.H quote start -----
/* Connection information block	*/

typedef struct cib {        /* Connection Information Block.    */
    uint16      protocol;   /* TCP or UDP or ... 0 means CIB not in use */
    uint16      lport;      /* TCP client port.  (ie: At this machine)  */
    uint16      rport;      /* TCP server port.  (ie: remote machine)   */
    uint32      rhost;      /* TCP server IP addr. (ie: remote machine) */
} CIB;
----- old STiK TRANSPRT.H quote end -----

Here is the CIB as defined for STinG before use of CAB structure:
----- old STinG TRANSPRT.H quote start -----
typedef struct cib {        /* Connection Information Block                 */
    uint16      protocol;   /* TCP or UDP or ... 0 means CIB is not in use  */
    uint16      lport;      /* TCP local  port     (ie: local machine)      */
    uint16      rport;      /* TCP remote port     (ie: remote machine)     */
    uint32      rhost;      /* TCP remote IP addr  (ie: remote machine)     */
    uint32      lhost;      /* TCP local  IP addr  (ie: local machine)      */
    uint16      status;     /* Net status. 0 means normal                   */
 } CIB;
----- old STinG TRANSPRT.H quote end -----

Here all the old elements still remain, at identical offsets, and the only
change is that two new elements have been added.  This is the structure that
has figured in most discussions of STinG CIB, and the one we have discussed
with you in particular.  I think you confirmed the addition of the two new
elements in identical fashion for STiK as well, but please confirm or deny
this again, so I now for sure if it is so.

Finally, here is the CIB as defined for STinG at present:
----- new STinG TRANSPRT.H quote start -----
/*
 *   Addressing information block.
 */

typedef  struct cab {
    uint16      lport;      /* TCP local  port     (ie: local machine)      */
    uint16      rport;      /* TCP remote port     (ie: remote machine)     */
    uint32      rhost;      /* TCP remote IP addr  (ie: remote machine)     */
    uint32      lhost;      /* TCP local  IP addr  (ie: local machine)      */
 } CAB;


/*
 *   Connection information block.
 */

typedef struct cib {        /* Connection Information Block                 */
    uint16      protocol;   /* TCP or UDP or ... 0 means CIB is not in use  */
    CAB         address;    /* Adress information                           */
    uint16      status;     /* Net status. 0 means normal                   */
 } CIB;
----- new STinG TRANSPRT.H quote end -----

Study the quote above closely, and then compare it with the quote above it.
Note that the only difference is in how the expressions that access the
elements will be written at source level.  The binary offsets are identical.

I don't see why you regard this as incompatible, except possibly if you
misread the new CIB structure so as to interpret the 'address' element as
a pointer, which it is not.  It is a straight inline substructure.


----- snip ----- re: AtarIRC problems
>
>	Yes it's described in the previous line of mine.  AtarIRC looks
>for a CIB, instead it gets a STiNG CIB, which is not compatible.  So it
>fails.

The STinG CIB, even after the introduction of the CAB substructure still
has all the same elements, at the same offsets, as when we discussed the
CIB structure with you previously.  I thought that we had then agreed on
how it should be, and that structure is _not_ altered physically in any
way by use of the CAB substructure.  It is entirely optional whether a
client is compiled with the older or the newer STinG CIB definition,
because the binary will use the same address offsets in either case.


----- snip ----- re: how peter documented the CAB structure

>	Hmm, must be several of us that missed it then.  Was kind of a hot
>topic on #atari one day.  As several people found out why they had been
>getting bug reports from STiNG users that made no sense.

I don't get it.  There is _no_ difference to clients due to the structure
definition with or without the substruct.  You must have had some other
problem that you mistakenly blamed on the CAB struct.  I'm not saying it
was not a STinG bug of some kind, it probably was, since such are to be
expected occasionally in developing software.  But it was not due to the
new CIB structure, because that is not possible.  It is fully compatible.

The _use_ of that structure may have had problems, possibly caused by the
TCP module in some way, but the structure itself is correct.


----- snip ----- re: The need to read docs for technical information
>
----- snip ----- re: you saying Peter made CAB struct to break compatibility

The CAB structure does not affect access to the CIB by existing clients,
or future STiK-related clients, in any way.  The only effect of it is at
source level, where STinG-related programmers (only) need to use another
symbolic expression to access the same physical elements.  Because it
only concerns those who program with the STinG TRANSPRT.H, there never
was any reason to mention it outside of STinG docs and STinG-related mail.


----- snip ----- re: someone (who?) being 'hot', not wanting to change stuff
>
>	Yes you did misunderstand me.  Lonny does not plan on fixing
>AtarIRC to handle the STiNG CIB structure.

Ok, I see now.  You followed a sentence where 'he' meant Peter with another
sentence where 'he' meant Lonny, without mentioning either name explicitly.
It doesn't matter really, but it made things seem a bit vague.

But again, I see nothing wrong with the structure itself.


----- snip ----- re: you and lonny always refused even simple workarounds
>
>	This is a funny twist.  Yes it was I who went into the STiNG code
>and changed the CIB structure.  I admit it to all.

No one has changed the CIB structure lately.  Only its symbolic definition
for STinG users has changed.  I don't see what you mean by it at all.

The incompatibility has nothing to do with that structure declaration, but
with the fact that under STinG all outgoing packets are given a source IP
address matching the address of the outgoing route port on the machine of
origin.  For a listening connection it is not possible to know what that
physical port will be, unless the expected calling remote is known, because
the arrival port will depend on which other machine the call is coming from.

Fortunately some of the ideas discussed earlier in this mail will probably
lead to a solution in the form of a modified usage of IP addresses under
STinG, so that full STiK compatibility in this respect can be achieved.


----- snip ----- re: RFC 1631, on 'Network Address Translator'
>
>	I personally don't like it's method.

Neither do I.  It would inevitably 'bottleneck' all traffic.


>But from what you have discussed in the past it sounds like it might be
>applicable in your situation.   There are other ways around this that
>have been in use for some time.

Sure, and normal masquerading is of course one of them.  In any case, I
have had some new ideas partly based on some of the things in the RFC and
some of the things you said, but utterly rejecting the idea of centralized
routing.  The routing must remain distributed to maintain decent speed.


----- snip ----- re: more on the 'local listening IP' problem
>
>	No, this is not the case.  A single IP number is not used across
>all connections.  I'm not certain where the problem comes in with STiNG.

Hopefully my comments on routing VS source IP in outgoing packets have
clarified where the problem comes in.


>I have heard alternatively over time that the CIB is not actively used
>internally in STinG and then that it is.

The straight dope:

	STinG kernel has no idea that any CIBs even exist.
	It never deals with high-level connection structures which are
	thus only known to the corresponding high-level module.

	STinG TCP module creates CIB when the first CNgetinfo call is
	made for a given connection, at which time it also copies the
	field values it needs from various part of the TCP connection
	structure, and stores the CIB pointer in on element of that
	connection structure for future use.

	The TCP module also updates relevant parts of the CIB structure
	at connection of a 'listener', and at reception of ICMP error
	messages (the status word).

	The TCP module never uses the data in a CIB for anything at all.
	It is entirely up to the client what it wants to do with it,
	but smashing the data in a CIB is not very meaningful, though
	it should have no effect at all on the TCP module.

	Finally, the CIB is released to free RAM in the same routine
	that also releases the RAM holding the TCP connection struct.
	Both those RAM blocks are naturally taken from ALLOCMEM RAM.

Hmmm...  Nope, I can't think of any more relevant info on this.


----- snip ----- re: some old, now irrelevant stuff

----- snip ----- re: Author recognition as identifier for enhancements
>
>	But for how long will this remeain true?   I'm not saying that you
>will be stealing peter's work.  How long before someone rewrites one of
>the modules?  Could be never I guess...

Actually I can't imagine why you would ever need to worry about any other
modules than TCP and (rarely) UDP.  IP and ICMP are both in the kernel,
and I seriously doubt that any clone of that will appear.

Still, who knows...
That has always been the trouble with version identification, that we
can never know when someone new is going to do something radical.


>	Are you happy now?

Yes, much happier, because now we have a dialog which we didn't before.
Active dialogs are fertilizer for ideas !

NB: No pun intended on the nature of other common fertilizers...  ;-)

-------------------------------------------------------------------------
Regards:  Ronald Andersson                   mailto:dlanor@ettnet.se
http://www.ettnet.se/~dlanor/                mailto:dlanor@oden.se
http://dlanor.atari.org/                     mailto:ra@cgiforme.com
-------------------------------------------------------------------------

---------------------------------------------------------------------------
To unsubscribe from this list, e-mail Majordomo@list.zetnet.co.uk
with the body of the message containing "unsubscribe Stik-Beta-Testers"
---------------------------------------------------------------------------

.
