In a message of  Rick Van Ruth (3:640/937.6) wrote:

Hi Rick,

 RVR>>> I belong to the "other" group :)
 DF>> Then you're in the wrong group.  
 RVR> Not necessarily :)

Umm, actually, 'yes, necessarily'.  :)

 DF>> You have a wide area network (connection to the internet) using a PPP
 DF>> interface and using TCP/IP networking.  Once again, each machine on
 DF>> that wide area network must have it's own unique IP address so that
 DF>> data ends up where it's supposed to end up.

 RVR> Ok, that's true in the form of subnets - but why can't the IP for the
 RVR> LAN be the same as the WAN.

In this case, subnets are irrelevant to the situation.  Here is a couple of
quotes from a book called 'TCP/IP Network Administration':

"The Internet Protocol moves data between hosts in the form of
datagrams.  Each datagram is delivered to an address contained in the
Destination Address (word 5) of the datagram's header.  The Destination
Address is a standard 32-bit IP address that contains sufficient
information to uniquely identify a network and a specific host on that
network."

"IP addresses are often called host addresses.  While this is common
usage, it is slightly misleading.  IP addresses are assigned to network
interfaces, not to computer systems."

From here it goes on with a couple of examples that relate to diagrams in
the book that I'm not even going to attempt to reproduce here.  The fact
remains, however, that each and every network interface that you use _must_
have it's own IP address for things to work properly.  In your case that
means that each ethernet card that you use (essentially one per computer)
must have it's own IP address and _additionally_ the dialup interface (PPP)
must have it's own IP address.

 DF>> Now the key point, each of these networks is separate.  If a single
 DF>> machine is going to exist in both of these networks then it is going
 DF>> to have to have relevant IP address information for each network.

 RVR> But there is only one network, this is what I have stated in the past
 RVR> - my LAN is the WAN network.

Yes, an no.  I understand what you're saying here but despite that you do
in fact have two separate network components.  Yes, they are _effectively_
one network but in terms of network administration they must be considered
as being two networks with _one_ interconnection point.

 DF>> If it only has an IP address for the WAN, how is the LAN supposed to
 DF>> know how to send it traffic?  If it only has an IP address for the
 DF>> LAN, how is the WAN supposed to route traffic to it?

 RVR> Ok, confusion reigns, I still can't see why if I have 203.17.118.51
 RVR> and 203.17.118.52 why I can't do an ftp from .52 to .51 and have it
 RVR> work. It appears to do so here already. Both machines know the other
 RVR> exist.

Both machines are using those IP addresses (I assume) as the address for
their ethernet.  As a result they can see each other on those addresses
with no problems.  When it comes to then using the PPP on one from an
ethernet connected machine this will start to fail. Unfortunately, network
software tries to be semi-intelligent about what's going on and this will
help to mask the problems but if you only have two IP addresses for two
machines then you don't have enough IP addresses to go around.

 DF>> This is why an IP address really refers to the INTERFACE rather than
 DF>> the computer.  In the above case, one machine is going to have to
 DF>> have two IP addresses, one that relates to it's existance in the LAN
 DF>> (an IP address for it's ethernet interface) and one that relates to
 DF>> it's existance in the WAN (an IP address for it's PPP interface).

 RVR> I think I understand what you mean, but looking from my *.51, then
 RVR> the ppp interface is actually *.2 which is the machine at the other
 RVR> end. So you could actually say my ppp interface is *.2 and my
 RVR> ethernet is *.51

If your PPP is being assigned an IP address of *.2 then this is true. If
you're saying that *.2 is the address of the machine at the other end of
the modem link then it's not true.  As mentioned before, it
_really_ helps to think of this sort of thing as being two separate network problems.

Consider the PPP link in isolation (forget about the ethernet for now).  In
order for you to establish a PPP connection you need an IP address for the
machine at the ISP end of the link (more likely for the port on a router
depending on the size of the ISP).  That IP address may be fairly static
depending on how the ISP manages his links.  You will also need an IP
address for _your_ end of the connection.  That IP address will be the one
that your machine is known by to the rest of the world.  When data is sent
to your computer it will be sent to that IP address.

OK, now consider the ethernet in isolation.  Once again, each machine on
the ethernet will have to have an address.  That's how data moves around. 
In the case of ethernets those address are _mostly_ pre-assigned to a
machine (there are some dynamic assignment models for this now).  In your
case it means you need two IP addresses.  One for each machine.

Clear so far?  Now lets consider the computer that has both the ethernet
and the ppp on it.  Data from the outside world will be shot down the ppp
to the address assigned to you as a part of your dialup connection.  When
it arrives on your dialup machine that computer must work out what to do
with it.  It will look at the header information and work out which machine
(that it knows about) the data is destined for.  By making use of routing
statements and the like it will then forward the information to the
destination.

Does that make sense?

Now let's go the other way.  A computer that has _only_ an ethernet sending
data out onto the internet in general.  It will send it's data to the
computer that is defined as the gateway.  That computer will be known
(within the ethernet network) by it's ethernet IP address.  This has to
happen since, technically, the PPP address doesn't really know about any
machine other than the one it is connected to via ppp.

So data arrives at the ethernet ip address.  TCP/IP looks at it and sees
that it's supposed to go to an address that is not on the lan. It looks at
it's routing tables and from them sees that anything bound for addresses
not on it's lan gets shuffled off to the ppp interface for further
handling.  The ppp interface gets the data, decides that it's bound for the
world at large and sends it on down the phone line.

I'm not sure this is as clear as it should be though.  It's the crux of the
whole thing.  You _need_ an IP address for each interface or you will never
get things fully working.  As I said above, some TCP/IP software will help
to hide problems but if you want things to work properly you will need to
have two IP addresses on the machine that has the two network connections
(ppp and ethernet).

 DF>> machine has to be able to understand how to take traffic moving over
 DF>> your LAN that requires data from a machine not on your LAN and move
 DF>> it over to the WAN so that it gets where it has to.  It then has to

 RVR> Well I figure the gateway statements had covered this aspect of the
 RVR> routing.

Yes, it will but only if the gateway is suitably defined.

 DF>> Wrong.  If you only had a PPP link to your ISP and nothing else then
 DF>> you'd only need one IP address, the one for your PPP connection.  If
 DF>> you add in an ethernet connection on that same computer then you'll
 DF>> also need a second IP address that refers to that other network that
 DF>> also happens to be running on that one machine.

 RVR> But it's not an "other network", I see it as basically
an extension
 RVR> of the 203.17.118.* network.

Yes, and no.  Once again, I can see what you're saying but in terms of what
you are doing you _do_ have two networks with a single connection between
them.  The IP addresses involved are immaterial.  If it helps you to
understand it remember that there's absolutely no reason why you have to
have your ethernet connections using IP addresses in the 203.17.118.*
address space.  Even if they weren't, the network would still work as it
should.  Despite the addresses you're using you do in fact have two
networks with one connection between them.

 DF>> The address that is allocated by your IP will certainly work for any
 DF>> protocols that are running over the connection between you and your
 DF>> ISP but that same IP address will not be suitable for using on your
 DF>> local area network as, basically, your LAN won't know how to deal
 DF>> with it.

 RVR> This is where I am confused, understanding why the LAN cannot know
 RVR> the whereabouts of the first IP address. I am totally ignorant here
 RVR> because my LAN does seem to know where the first IP is, all pings etc
 RVR> go to the applicable machine.

Without seeing it physically I am only guessing but I'd say that one
machine is feeling slightly schizophrenic.  It's trying to make one IP
address do what two _should_ be doing.  The software itself is trying to
use the one IP address depending on the context of the TCP/IP datagrams it
receives.  So, when you ping from one ethernet to another it's trying to
use that IP address as the ethernet address and then when you ping from one
ppp machine to your isp it's trying to use it as a ppp IP address.  As I
said, the software is trying to cope with what it's got but the fact that
it's not working for everything indicates that there's a problem - from
what you've said I suspect that the problem is related to not having enough
IP addresses to do the job you are trying to do.

 DF>> I've yet to see an ISP that doesn't run multiple machines on a LAN of
 DF>> some sort.  When these machines are setup they only have one IP
 DF>> address because the only network connection is the ethernet
 DF>> interface. If, on

 RVR> No, each of his machines have a different IP address.

and the machine (router probably) that has more than one interface will
have more than one IP address.

 DF>> the other hand, you look at the terminal server (be it a computer
 DF>> with multi-serial cards or a dedicated box like a Cisco or some such)
 DF>> you'll find that it has quite a few IP addresses associated with it. 

 RVR> This is correct, the server does support multiple IP's, in fact it
 RVR> supports every IP address between 203.17.118.1 to 203.17.118.255 in
 RVR> one way or another whether it be a LAN, ppp, etc etc

Ummm, I don't mean support as in handle routing to I mean that each and
every interface on the ISP's local network setup will have an IP address.

 RVR> There is basically one main server, this is because it operates under
 RVR> Debian Linux and not under Win NT (Win NT ISP's seems to need a
 RVR> number of machines to play server...).

Not entirely true.  I know of a few ISP's using NT boxes these days. The
reasons for distributed functions are as much matters of redundancy as
anything else.  Mind you, the resources needed to run Linux are _far_ lower
than the resources needed to run NT so many of the smaller ISP's prefer to
use linux and save on computer hardware. Larger ISP's (who are better
funded) frequently use workstations like Sun and Silicon Graphics.  The
primary use of NT at the moment is on corporate networks where an internet
connection is being incorporated into a primarily Win31/Win95 internal LAN.

 RVR> Certain functions are handled
 RVR> by one of the other few ethernetted machines, each of these have
 RVR> their own IP address (much the same as my machines do).

But in each case, these machines _really_ have an IP address on the
interface.  The fact that they only have one IP address is more related to
the fact that they only have one network interface.  The box that maintains
the dialup connections will have more than one IP address associated with
it.

 RVR> mine, the only problem I think I will have is routing statements
 RVR> across the LAN network of the ISP. This is where your understanding
 RVR> and explanations come to bear - if I was a separate network, then it
 RVR> would be as you describe and handled at his end. Since I am not a
 RVR> separate network, I envisage I will have trouble running across my
 RVR> LAN, up the ppp link and then down another ppp link to another same
 RVR> network addressed machine. I figure an immense routing table will fix
 RVR> this :) Then again, I will not really require access to those
 RVR> machines anyway as there's nothing for me on them.

Now it sounds like part of the problem is at the ISP end as well.  In order
for your network connections to work properly, routing to your IP addresses
_must_ be correctly handled by your ISP as well.  If you are having trouble
reaching other machines on _his_ lan then that is a routing problem too. 
Mind you, that's also tied up in your not having an IP address associated
with your ppp link _as_ _well_ _as_ ip addresses associated with your
ethernet links.

 RVR> Anyway, I've yet to receive my updated sanaII device, so I am stuck
 RVR> with thinking about it 'til then. Once it arrives I can go through
 RVR> the actual attempts :)

I can't help thinking that the problem is not solely related to drivers.

  //  CYA,
\X/ Dave ;-)

... Borg Empire: Equal opportunity Assimilator! 

---