Re: NT and Cornell V1.0 TCP problem

Ian (virus@mad.scientist.com)
Sat, 09 May 1998 14:55:12 -0600


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Since there isn't a configurable binding order for Windows 95 (that
I know of), you will probably need to mess with the routing table on
your Windows 95 machine. White Pine might me on the right track by
telling you to install the Dial-Up adapter LAST. I think it might me
more benificial to remove all adapters and install the DUN FIRST and
your ethernet adapter LAST before messing with a routing table. This
*should* allow your DUN adapter be first in the adapter binding
order<?>... I don't have much experience with windows 95 :-)

I seriously doubt that this is a routing table issue because if you
can ping out of your private network while dialed up, your routing
table is working properly....

But for your own info, here is some stuff I got off of Technet:

A Windows 95 computer can also be configured with multiple network
adapters or otherwise be configured for simultaneous connection to
multiple subnetworks. A Windows 95 computer cannot be configured to
support routing between IP networks, but some routing table issues can
arise for a Windows 95 computer that is connected to multiple IP
networks.

You can create Windows 95 multihomed configurations for purposes such
as the following:
1. To connect a computer simultaneously to the local network and to
the Internet
2. To connect to different subnets when the computer is on a single
physical network that contains multiple logical IP networks
3. To allow a computer to communicate simultaneously on two otherwise
isolated networks

When such a computer attempts to access a particular IP address, the
destination server is located by checking the routing table and using
the following process:
1. If the destination IP address indicates that it is on the same IP
subnet as the workstation’s LAN adapter, then data is sent using the
LAN adapter.
2. If the destination IP address indicates that it is not on the same
subnet as the workstation’s LAN adapter, then data is sent to the
default gateway. The default gateway then locates the destination
route on behalf of the remote workstation.
3. If the default gateway IP address was previously configured for the
LAN adapter, it is ignored by default. If required, the remote
workstation can be configured so that the default gateway on the LAN
adapter is used instead of the default gateway on the remote
connection.
This configuration becomes complicated for a user who is either
dialing into the Internet when connected to a local private IP network
or, conversely, when connected directly to the Internet and dialing
into a private IP network. This is because PPP creates a default route
if the option named Use Default Gateway On Remote Net is checked.
Checking this might be something that you might want to try.

The default route that PPP creates establishes a priority for this
connection in the computer’s routing table. This priority allows full
access to the remote network for name resolution and forwarding
packets. However, it means more limited access for the local
connection, because the default gateway used for network
communications becomes the default gateway specified for the PPP
connection. You will probably become aware of problems that this can
cause when you try to connect to computer on a remote subnet, but
Windows 95 reports that it can’t find that computer name.

Basically this problem occurs because neither the Domain Name System
nor the TCP/IP protocol suite is not designed to support multiple
address spaces, which is the situation that occurs when a computer is
simultaneously connected to a private IP network and the public
Internet (or another private IP network).

The name resolution problems can occur when you maintain a local
network connection while using a Dial-Up connection to the Internet.
For example, if the Dial-up Adapter is connected to the Internet and
a network adapter is using TCP/IP on the local LAN, the following
route command allows this workstation to connect to a computer on a
remote subnet in the LAN, rather than routing to the Internet:

route add 11.1.0.0 mask 255.255.0.0 130.25.0.1

In this example:
11.1.0.0 is the remote subnet.
255.255.0.0 is the subnet mask.
130.25.0.1 is the default gateway on the local LAN.

Notice that this will fail unless the destination gateway can always
be reached from the directly connected network. In this example, the
local computer must always be able to reach the node with the address
130.25.0.1 without going through a router.

At 09:01 AM 5/9/98 PDT, you wrote:
>Ian:
>
>I am currently experiencing the same problem with a Win95 system,
again
>with an ethernet card with a 10.x.x.x address and a dial up
networking
>connection. In my case, the local ethernet card needs to stay
connected
>since this machine also acts as a proxy for the internet connection.
The
>only work around I have found is to have someone else connect to me,
and
>then CU realizes what address it should be using. This only appears
to
>work on WP, cornell did not seem to change it's preferred address.
>White Pine blames this on Microsoft, but personally I believe that it
is
>a normal situation to have more that a single network connection, and

>that there SHOULD be a way (command line, preference selection, etc)
to
>select which adapter to use as a primary for the CU program.
Hopefully
>some of the development team is listening ;-)
>
>I agree it is a binding order issue, I have seen some posts saying to

>remove DUN & reinstall DUN, so that it is the LAST adapter that has
been
>installed, but this did not seem to work in my case. White Pine tech

>support also suggested installing the latest DUN, which also had no
>effect.
>
>You did mention connecting connecting to a self reflect conference,
>would you possibly be able to point me in the direction of one of
>these??
>
>Glad there is a solution for this in the NT world, hopefully there
will
>be one in the Win95 worl as well ...
>
>

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.5.5 for non-commercial use <http://www.nai.com>

iQA/AwUBNVTCr7s0moVWlPcSEQKZdgCgl9WYt7RPPN+8tm2q0fmZPcC/BGUAoJj2
gfSXYNqZ6231zKfSlpZcoVgl
=Ufm8
-----END PGP SIGNATURE-----