This section is not my own creation but rather a summary of the work of others - I am currently studying for the TCP/IP exams so I will addd an additional section as it pertains to Windows 95 soon.. The bulk of the information herein was written by Charles L. Hedrick of Rutgers University way back in 1987 - that's right 11 years ago! The copyright for this section hence belongs to Rutgers University and Charles Hedrick and is used by permission. I have also used Rawn Shah's PC TCP/IP & NFS Frequently Asked Questions to assist me in the creation this section. I will also be mirroring both FAQ's here at this site ...
Jump Directly to the Questions
This document is a brief introduction to TCP/IP, followed by advice
on what to read for more information. This is not intended to be a complete description.
It can give you a reasonable idea of the capabilities of the protocols. But if you need to
know any details of the technology, you will want to read the standards yourself.
Throughout the text, you will find references to the standards, in the form of
"RFC" or "IEN" numbers. These are document numbers. The final section
of this document tells you how to get copies of those standards.
1. What is TCP/IP?
TCP/IP is a set of protocols developed to allow cooperating computers to share resources
across a network. It was developed by a community of researchers centered around the
ARPAnet. Certainly the ARPAnet is the best-known TCP/IP network. However as of June, 87,
at least 130 different vendors had products that support TCP/IP, and thousands of networks
of all kinds use it.
First some basic definitions. The most accurate name for the set of protocols we are
describing is the "Internet protocol suite". TCP and IP are two of the protocols
in this suite. (They will be described below.) Because TCP and IP are the best known of
the protocols, it has become common to use the term TCP/IP or IP/TCP to refer to the whole
family. It is probably not worth fighting this habit. However this can lead to some
oddities. For example, I find myself talking about NFS as being based on TCP/IP, even
though it doesn't use TCP at all. (It does use IP. But it uses an alternative protocol,
UDP, instead of TCP. All of this alphabet soup will be unscrambled in the following
pages.)
The Internet is a collection of networks, including the Arpanet, NSFnet, regional networks
such as NYsernet, local networks at a number of University and research institutions, and
a number of military networks. The term "Internet" applies to this entire set of
networks. The subset of them that is managed by the Department of Defense is referred to
as the "DDN" (Defense Data Network). This includes some research-oriented
networks, such as the Arpanet, as well as more strictly military ones. (Because much of
the funding for Internet protocol developments is done via the DDN organization, the terms
Internet and DDN can sometimes seem equivalent.) All of these networks are connected to
each other. Users can send messages from any of them to any other, except where there are
security or other policy restrictions on access. Officially speaking, the Internet
protocol documents are simply standards adopted by the Internet community for its own use.
More recently, the Department of Defense issued a MILSPEC definition of TCP/IP. This was
intended to be a more formal definition, appropriate for use in purchasing specifications.
However most of the TCP/IP community continues to use the Internet standards. The MILSPEC
version is intended to be consistent with it.
Whatever it is called, TCP/IP is a family of protocols. A few provide
"low-level" functions needed for many applications. These include IP, TCP, and
UDP. (These will be described in a bit more detail later.) Others are protocols for doing
specific tasks, e.g. transferring files between computers, sending mail, or finding out
who is logged in on another computer. Initially TCP/IP was used mostly between
minicomputers or mainframes. These machines had their own disks, and generally were
self-contained. Thus the most important "traditional" TCP/IP services are:
- file transfer. The file transfer protocol (FTP) allows a user on
any computer to get files from another computer, or to send files to another computer.
Security is handled by requiring the user to specify a user name and password for the
other computer. Provisions are made for handling file transfer between machines with
different character set, end of line conventions, etc. This is not quite the same thing as
more recent "network file system" or "netbios" protocols, which will
be described below. Rather, FTP is a utility that you run any time you want to access a
file on another system. You use it to copy the file to your own system. You then work with
the local copy. (See RFC 959 for specifications for FTP.)
- remote login. The network terminal protocol (TELNET) allows a
user to log in on any other computer on the network. You start a remote session by
specifying a computer to connect to. From that time until you finish the session, anything
you type is sent to the other computer. Note that you are really still talking to your own
computer. But the telnet program effectively makes your computer invisible while it is
running. Every character you type is sent directly to the other system. Generally, the
connection to the remote computer behaves much like a dialup connection. That is, the
remote system will ask you to log in and give a password, in whatever manner it would
normally ask a user who had just dialed it up. When you log off of the other computer, the
telnet program exits, and you will find yourself talking to your own computer.
Microcomputer implementations of telnet generally include a terminal emulator for some
common type of terminal. (See RFC's 854 and 855 for specifications for telnet. By the way,
the telnet protocol should not be confused with Telenet, a vendor of commercial network
services.)
- computer mail. This allows you to send messages to users on
other computers. Originally, people tended to use only one or two specific computers. They
would maintain "mail files" on those machines. The computer mail system is
simply a way for you to add a message to another user's mail file. There are some problems
with this in an environment where microcomputers are used. The most serious is that a
micro is not well suited to receive computer mail. When you send mail, the mail software
expects to be able to open a connection to the addressee's computer, in order to send the
mail. If this is a microcomputer, it may be turned off, or it may be running an
application other than the mail system. For this reason, mail is normally handled by a
larger system, where it is practical to have a mail server running all the time.
Microcomputer mail software then becomes a user interface that retrieves mail from the
mail server. (See RFC 821 and 822 for specifications for computer mail. See RFC 937 for a
protocol designed for microcomputers to use in reading mail from a mail server.)
These services should be present in any implementation of TCP/IP,
except that micro-oriented implementations may not support computer mail. These
traditional applications still play a very important role in TCP/IP-based networks.
However more recently, the way in which networks are used has been changing. The older
model of a number of large, self-sufficient computers is beginning to change. Now many
installations have several kinds of computers, including microcomputers, workstations,
minicomputers, and mainframes. These computers are likely to be configured to perform
specialized tasks. Although people are still likely to work with one specific computer,
that computer will call on other systems on the net for specialized services. This has led
to the "server/client" model of network services. A server is a system that
provides a specific service for the rest of the network. A client is another system that
uses that service. (Note that the server and client need not be on different computers.
They could be different programs running on the same computer.) Here are the kinds of
servers typically present in a modern computer setup. Note that these computer services
can all be provided within the framework of TCP/IP.
- network file systems. This allows a system to access files on
another computer in a somewhat more closely integrated fashion than FTP. A network file
system provides the illusion that disks or other devices from one system are directly
connected to other systems. There is no need to use a special network utility to access a
file on another system. Your computer simply thinks it has some extra disk drives. These
extra "virtual" drives refer to the other system's disks. This capability is
useful for several different purposes. It lets you put large disks on a few computers, but
still give others access to the disk space. Aside from the obvious economic benefits, this
allows people working on several computers to share common files. It makes system
maintenance and backup easier, because you don't have to worry about updating and backing
up copies on lots of different machines. A number of vendors now offer high-performance
diskless computers. These computers have no disk drives at all. They are entirely
dependent upon disks attached to common "file servers". (See RFC's 1001 and 1002
for a description of PC-oriented NetBIOS over TCP. In the workstation and minicomputer
area, Sun's Network File System is more likely to be used. Protocol specifications for it
are available from Sun Microsystems.)
- remote printing. This allows you to access printers on other
computers as if they were directly attached to yours. (The most commonly used protocol is
the remote lineprinter protocol from Berkeley Unix. Unfortunately, there is no protocol
document for this. However the C code is easily obtained from Berkeley, so implementations
are common.)
- remote execution. This allows you to request that a particular
program be run on a different computer. This is useful when you can do most of your work
on a small computer, but a few tasks require the resources of a larger system. There are a
number of different kinds of remote execution. Some operate on a command by command basis.
That is, you request that a specific command or set of commands should run on some
specific computer. (More sophisticated versions will choose a system that happens to be
free.) However there are also "remote procedure call" systems that allow a
program to call a subroutine that will run on another computer. (There are many protocols
of this sort. Berkeley Unix contains two servers to execute commands remotely: rsh and
rexec. The man pages describe the protocols that they use. The user-contributed software
with Berkeley 4.3 contains a "distributed shell" that will distribute tasks
among a set of systems, depending upon load. Remote procedure call mechanisms have been a
topic for research for a number of years, so many organizations have implementations of
such facilities. The most widespread commercially-supported remote procedure call
protocols seem to be Xerox's Courier and Sun's RPC. Protocol documents are available from
Xerox and Sun. There is a public implementation of Courier over TCP as part of the
user-contributed software with Berkeley 4.3. An implementation of RPC was posted to Usenet
by Sun, and also appears as part of the user-contributed software with Berkeley 4.3.)
- name servers. In large installations, there are a number of
different collections of names that have to be managed. This includes users and their
passwords, names and network addresses for computers, and accounts. It becomes very
tedious to keep this data up to date on all of the computers. Thus the databases are kept
on a small number of systems. Other systems access the data over the network. (RFC 822 and
823 describe the name server protocol used to keep track of host names and Internet
addresses on the Internet. This is now a required part of any TCP/IP implementation. IEN
116 describes an older name server protocol that is used by a few terminal servers and
other products to look up host names. Sun's Yellow Pages system is designed as a general
mechanism to handle user names, file sharing groups, and other databases commonly used by
Unix systems. It is widely available commercially. Its protocol definition is available
from Sun.)
- terminal servers. Many installations no longer connect terminals
directly to computers. Instead they connect them to terminal servers. A terminal server is
simply a small computer that only knows how to run telnet (or some other protocol to do
remote login). If your terminal is connected to one of these, you simply type the name of
a computer, and you are connected to it. Generally it is possible to have active
connections to more than one computer at the same time. The terminal server will have
provisions to switch between connections rapidly, and to notify you when output is waiting
for another connection. (Terminal servers use the telnet protocol, already mentioned.
However any real terminal server will also have to support name service and a number of
other protocols.)
- network-oriented window systems. (X-Teminals
& more recenly Oracle's Net Computers / NetPC's) Until recently, high-
performance graphics programs had to execute on a computer that had a bit-mapped graphics
screen directly attached to it. Network window systems allow a program to use a display on
a different computer. Full-scale network window systems provide an interface that lets you
distribute jobs to the systems that are best suited to handle them, but still give you a
single graphically-based user interface. (The most widely-implemented window system is X.
A protocol description is available from MIT's Project Athena. A reference implementation
is publically available from MIT. A number of vendors are also supporting NeWS, a window
system defined by Sun. Both of these systems are designed to use TCP/IP.)
Note that some of the protocols described above were designed by Berkeley, Sun, or other
organizations. Thus they are not officially part of the Internet protocol suite. However
they are implemented using TCP/IP, just as normal TCP/IP application protocols are. Since
the protocol definitions are not considered proprietary, and since commercially-support
implementations are widely available, it is reasonable to think of these protocols as
being effectively part of the Internet suite. Note that the list above is simply a sample
of the sort of services available through TCP/IP. However it does contain the majority of
the "major" applications. The other commonly-used protocols tend to be
specialized facilities for getting information of various kinds, such as who is logged in,
the time of day, etc. However if you need a facility that is not listed here, we encourage
you to look through the current edition of Internet Protocols (currently RFC 1011), which
lists all of the available protocols, and also to look at some of the major TCP/IP
implementations to see what various vendors have added.
2. General description of the TCP/IP protocols
TCP/IP is a layered set of protocols. In order to understand what this means, it is useful
to look at an example. A typical situation is sending mail. First, there is a protocol for
mail. This defines a set of commands which one machine sends to another, e.g. commands to
specify who the sender of the message is, who it is being sent to, and then the text of
the message. However this protocol assumes that there is a way to communicate reliably
between the two computers. Mail, like other application protocols, simply defines a set of
commands and messages to be sent. It is designed to be used together with TCP and IP. TCP
is responsible for making sure that the commands get through to the other end. It keeps
track of what is sent, and retransmitts anything that did not get through. If any message
is too large for one datagram, e.g. the text of the mail, TCP will split it up into
several datagrams, and make sure that they all arrive correctly. Since these functions are
needed for many applications, they are put together into a separate protocol, rather than
being part of the specifications for sending mail. You can think of TCP as forming a
library of routines that applications can use when they need reliable network
communications with another computer. Similarly, TCP calls on the services of IP. Although
the services that TCP supplies are needed by many applications, there are still some kinds
of applications that don't need them. However there are some services that every
application needs. So these services are put together into IP. As with TCP, you can think
of IP as a library of routines that TCP calls on, but which is also available to
applications that don't use TCP. This strategy of building several levels of protocol is
called "layering". We think of the applications programs such as mail, TCP, and
IP, as being separate "layers", each of which calls on the services of the layer
below it. Generally, TCP/IP applications use 4 layers:
- an application protocol such as mail
- a protocol such as TCP that provides services
need by many
applications
- IP, which provides the basic service of
getting datagrams to
their destination
- the protocols needed to manage a specific
physical medium, such
as Ethernet or a point to point line.
TCP/IP is based on the "catenet model". (This is described in more detail in IEN
48.) This model assumes that there are a large number of independent networks connected
together by gateways. The user should be able to access computers or other resources on
any of these networks. Datagrams will often pass through a dozen different networks before
getting to their final destination. The routingneeded to accomplish this should be
completely invisible to the user. As far as the user is concerned, all he needs to know in
order to access another system is an "Internet address". This is an address that
looks like 128.6.4.194. It is actually a 32-bit number. However it is normally written as
4 decimal numbers, each representing 8 bits of the address. (The term "octet" is
used by Internet documentation for such 8-bit chunks. The term "byte" is not
used, because TCP/IP is supported by some computers that have byte sizes other than 8
bits.) Generally the structure of the address gives you some information about how to get
to the system. For example, 128.6 is a network number assigned by a central authority to
Rutgers University. Rutgers uses the next octet to indicate which of the campus Ethernets
is involved. 128.6.4 happens to be an Ethernet used by the Computer Science Department.
The last octet allows for up to 254 systems on each Ethernet. (It is 254 because 0 and 255
are not allowed, for reasons that will be discussed later.) Note that 128.6.4.194 and
128.6.5.194 would be different systems. The structure of an Internet address is described
in a bit more detail later.
Of course we normally refer to systems by name, rather than by Internet address. When we
specify a name, the network software looks it up in a database, and comes up with the
corresponding Internet address. Most of the network software deals strictly in terms of
the address. (RFC 882 describes the name server technology used to handle this lookup.)
TCP/IP is built on "connectionless" technology. Information is transfered as a
sequence of "datagrams". A datagram is a collection of data that is sent as a
single message. Each of these datagrams is sent through the network individually. There
are provisions to open connections (i.e. to start a conversation that will continue for
some time). However at some level, information from those connections is broken up into
datagrams, and those datagrams are treated by the network as completely separate. For
example, suppose you want to transfer a 15000 octet file. Most networks can't handle a
15000 octet datagram. So the protocols will break this up into something like 30 500-octet
datagrams. Each of these datagrams will be sent to the other end. At that point, they will
be put back together into the 15000-octet file. However while those datagrams are in
transit, the network doesn't know that there is any connection between them. It is
perfectly possible that datagram 14 will actually arrive before datagram 13. It is also
possible that somewhere in the network, an error will occur, and some datagram won't get
through at all. In that case, that datagram has to be sent again.
Note by the way that the terms "datagram" and "packet" often seem tobe
nearly interchangable. Technically, datagram is the right word to use when describing
TCP/IP. A datagram is a unit of data, which is what the protocols deal with. A packet is a
physical thing, appearing on an Ethernet or some wire. In most cases a packet simply
contains a datagram, so there is very little difference. However they can differ. When
TCP/IP is used on top of X.25, the X.25 interface breaks the datagrams up into 128-byte
packets. This is invisible to IP, because the packets are put back together into a single
datagram at the other end before being processed by TCP/IP. So in this case, one IP
datagram would be carried by several packets. However with most media, there are
efficiency advantages to sending one datagram per
packet, and so the distinction tends to vanish.
2.1 The TCP level
Two separate protocols are involved in handling TCP/IP datagrams. TCP (the
"transmission control protocol") is responsible for breaking up the message into
datagrams, reassembling them at the other end, resending anything that gets lost, and
putting things back in the right order. IP (the "internet protocol") is
responsible for routing individual datagrams. It may seem like TCP is doing all the work.
And in small networks that is true. However in the Internet, simply getting a datagram to
its destination can be a complex job. A connection may require the datagram to go through
several networks at Rutgers, a serial line to the John von Neuman Supercomputer Center, a
couple of Ethernets there, a series of 56Kbaud phone lines to another NSFnet site, and
more Ethernets on another campus. Keeping track of the routes to all of the destinations
and handling incompatibilities among different transport media turns out to be a complex
job. Note that the interface between TCP and IP is fairly simple. TCP simply hands IP a
datagram with a destination. IP doesn't know how this datagram relates to any datagram
before it or after it.
It may have occurred to you that something is missing here. We have talked about Internet
addresses, but not about how you keep track of multiple connections to a given system.
Clearly it isn't enough to get a datagram to the right destination. TCP has to know which
connection this datagram is part of. This task is referred to as
"demultiplexing." In fact, there are several levels of demultiplexing going on
in TCP/IP. The information needed to do this demultiplexing is contained in a series of
"headers". A header is simply a few extra octets tacked onto the beginning of a
datagram by some protocol in order to keep track of it. It's a lot like putting a letter
into an envelope and putting an address on the outside of the envelope. Except with modern
networks it happens several times. It's like you put the letter into a little envelope,
your secretary puts that into a somewhat bigger envelope, the campus mail center puts that
envelope into a still bigger one, etc. Here is an overview of the headers that get stuck
on a message that passes through a typical TCP/IP network:
We start with a single data stream, say a file you are trying to send to some other
computer:
......................................................
TCP breaks it up into manageable chunks. (In order to do this, TCP has to know how large a
datagram your network can handle. Actually, the TCP's at each end say how big a datagram
they can handle, and then they pick the smallest size.)
.... .... .... .... .... .... .... ....
TCP puts a header at the front of each datagram. This header actually contains at least 20
octets, but the most important ones are a source and destination "port number"
and a "sequence number". The port numbers are used to keep track of different
conversations. Suppose 3 different people are transferring files. Your TCP might allocate
port numbers 1000, 1001, and 1002 to these transfers. When you are sending a datagram,
this becomes the "source" port number, since you are the source of the datagram.
Of course the TCP at the other end has assigned a port number of its own for the
conversation. Your TCP has to know the port number used by the other end as well. (It
finds out when the connection starts, as we will explain below.) It puts this in the
"destination" port field. Of course if the other end sends a datagram back to
you, the source and destination port numbers will be reversed, since then it will be the
source and you will be the destination. Each datagram has a sequence number. This is used
so that the other end can make sure that it gets the datagrams in the right order, and
that it hasn't missed any. (See the TCP specification for details.) TCP doesn't number the
datagrams, but the octets. So if there are 500 octets of data in each datagram, the first
datagram might be numbered 0, the second 500, the next 1000, the next 1500, etc. Finally,
I will mention the Checksum. This is a number that is computed by adding up all the octets
in the datagram
(more or less - see the TCP spec). The result is put in the header. TCP at the other end
computes the checksum again. If they disagree, then something bad happened to the datagram
in transmission, and it is thrown away. So here's what the datagram looks like now.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F|
|
| Offset| Reserved |R|C|S|S|Y|I| Window
|
| | |G|K|H|T|N|N|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| your data ... next 500 octets
|
| ......
|
If we abbreviate the TCP header as "T", the whole file now looks like
this:
T.... T.... T.... T.... T.... T.... T....
You will note that there are items in the header that I have not described above. They are
generally involved with managing the connection. In order to make sure the datagram has
arrived at its destination, the recipient has to send back an "acknowledgement".
This is a datagram whose "Acknowledgement number" field is filled in. For
example, sending a packet with an acknowledgement of 1500 indicates that you have received
all the data up to octet number 1500. If the sender doesn't get an acknowledgement within
a reasonable amount of time, it sends the data again. The window is used to control how
much data can be in transit at any one time. It is not practical to wait for each datagram
to be acknowledged before sending the next one. That would slow things down too much. On
the other hand, you can't just keep sending, or a fast computer might overrun the capacity
of a slow one to absorb data. Thus each end indicates how much new data it is currently
prepared to absorb by putting the number of octets in its "Window" field. As the
computer receives data, the amount of space left in its window decreases. When it goes to
zero, the sender has to stop. As the receiver processes the data, it increases its window,
indicating that it is ready to accept more data. Often the same datagram can be used to
acknowledge receipt of a set of data and to give permission for additional new data (by an
updated window). The "Urgent" field allows one end to tell the other to skip
ahead in its processing to a particular octet. This is often useful for handling
asynchronous events, for example when you type a control character or other command that
interrupts output. The other fields are beyond the scope of this document.
2.2 The IP level
TCP sends each of these datagrams to IP. Of course it has to tell IP the Internet address
of the computer at the other end. Note that this is all IP is concerned about. It doesn't
care about what is in the datagram, or even in the TCP header. IP's job is simply to find
a route for the datagram and get it to the other end. In order to allow gateways or other
intermediate systems to forward the datagram, it adds its own header. The main things in
this header are the source and destination Internet address (32-bit addresses, like
128.6.4.194), the protocol number, and another checksum. The source Internet address is
simply the address of your machine. (This is necessary so the other end knows where the
datagram came from.) The destination Internet address is the address of the other machine.
(This is necessary so any gateways in the middle know where you want the datagram to go.)
The protocol number tells IP at the other end to send the datagram to TCP. Although most
IP traffic uses TCP, there are other protocols that can use IP, so you have to tell IP
which protocol to send the datagram to. Finally, the checksum allows IP at the other end
to verify that the header wasn't damaged in transit. Note that TCP and IP have separate
checksums. IP needs to be able to verify that the header didn't get damaged in transit, or
it could send a message to the wrong place. For reasons not worth discussing here, it is
both more efficient and safer to have TCP compute a separate checksum for the TCP header
and data. Once IP has tacked on its header, here's what the message looks like:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP header, then your data ...... |
| |
If we represent the IP header by an "I", your file now looks like this:
IT.... IT.... IT.... IT.... IT.... IT.... IT....
Again, the header contains some additional fields that have not been discussed. Most of
them are beyond the scope of this document. The flags and fragment offset are used to keep
track of the pieces when a datagram has to be split up. This can happen when datagrams are
forwarded through a network for which they are too big. (This will be discussed a bit more
below.) The time to live is a number that is decremented whenever the datagram passes
through a system. When it goes to zero, the datagram is discarded. This is done in case a
loop develops in the system somehow. Of course this should be impossible, but
well-designed networks are built to cope with "impossible" conditions.
At this point, it's possible that no more headers are needed. If your computer happens to
have a direct phone line connecting it to the destination computer, or to a gateway, it
may simply send the datagrams out on the line (though likely a synchronous protocol such
as HDLC would be used, and it would add at least a few octets at the beginning and end).
2.3 The Ethernet level
However most of our networks these days use Ethernet. So now we have to describe
Ethernet's headers. Unfortunately, Ethernet has its own addresses. The people who designed
Ethernet wanted to make sure that no two machines would end up with the same Ethernet
address.
Furthermore, they didn't want the user to have to worry about assigning addresses. So each
Ethernet controller comes with an address builtin from the factory. In order to make sure
that they would never have to reuse addresses, the Ethernet designers allocated 48 bits
for the Ethernet address. People who make Ethernet equipment have to register with a
central authority, to make sure that the numbers they assign don't overlap any other
manufacturer. Ethernet is a "broadcast medium". That is, it is in effect like an
old party line telephone. When you send a packet out on the Ethernet, every machine on the
network sees the packet. So something is needed to make sure that the right machine gets
it. As you might guess, this involves the Ethernet header. Every Ethernet packet has a
14-octet header that includes the source and destination Ethernet address, and a type
code. Each machine is supposed to pay attention only to packets with its own Ethernet
address in the destination field. (It's perfectly possible to cheat, which is one reason
that Ethernet communications are not terribly secure.) Note that there is no connection
between the Ethernet address and the Internet address. Each machine has to have a table of
what Ethernet address corresponds to what Internet address. (We will describe how this
table is constructed a bit later.) In addition to the addresses, the header contains a
type code. The type code is to allow for several different protocol families to be used on
the same network. So you can use TCP/IP, DECnet, Xerox NS, etc. at the same time. Each of
them will put a different value in the type field. Finally, there is a checksum. The
Ethernet controller computes a checksum of the entire packet. When the other end receives
the packet, it recomputes the checksum, and throws the packet away if the answer disagrees
with the original. The checksum is put on the end of the packet, not in the header. The
final result is that your message looks like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet destination address (first 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet dest (last 16 bits) |Ethernet source (first 16 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet source address (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP header, then TCP header, then your data |
| |
...
| |
| end of your data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If we represent the Ethernet header with "E", and the Ethernet checksum with
"C", your file now looks like this:
EIT....C EIT....C EIT....C EIT....C EIT....C
When these packets are received by the other end, of course all the headers are removed.
The Ethernet interface removes the Ethernet header and the checksum. It looks at the type
code. Since the type code is the one assigned to IP, the Ethernet device driver passes the
datagram up to IP. IP removes the IP header. It looks at the IP protocol field. Since the
protocol type is TCP, it passes the datagram up to TCP. TCP now looks at the sequence
number. It uses the sequence numbers and other information to combine all the datagrams
into the original file. The ends our initial summary of TCP/IP. There are still some
crucial concepts we haven't gotten to, so we'll now go back and add details in several
areas. (For detailed descriptions of the items discussed here see, RFC 793 for TCP, RFC
791 for IP, and RFC's 894 and 826 for sending IP over Ethernet.)
3. Well-known sockets and the applications layer
So far, we have described how a stream of data is broken up into datagrams, sent to
another computer, and put back together. However something more is needed in order to
accomplish anything useful. There has to be a way for you to open a connection to a
specified computer, log into it, tell it what file you want, and control the transmission
of the file. (If you have a different application in mind, e.g. computer mail, some
analogous protocol is needed.) This is done by "application protocols". The
application protocols run "on top" of TCP/IP. That is, when they want to send a
message, they give the message to TCP. TCP makes sure it gets delivered to the other end.
Because TCP and IP take care of all the networking details, the applications protocols can
treat a network connection as if it were a simple byte stream, like a terminal or phone
line.
Before going into more details about applications programs, we have to describe how you
find an application. Suppose you want to send a file to a computer whose Internet address
is 128.6.4.7. To start the process, you need more than just the Internet address. You have
to connect to the FTP server at the other end. In general, network programs are
specialized for a specific set of tasks. Most systems have separate programs to handle
file transfers, remote terminal logins, mail, etc. When you connect to 128.6.4.7, you have
to specify that you want to talk to the FTP server. This is done by having
"well-known sockets" for each server. Recall that TCP uses port numbers to keep
track of individual conversations. User programs normally use more or less random port
numbers. However specific port numbers are assigned to the programs that sit waiting for
requests. For example, if you want to send a file, you will start a program called
"ftp". It will open a connection using some random number, say 1234, for the
port number on its end. However it will specify port number 21 for the other end. This is
the official port number for the FTP server. Note that there are two different programs
involved. You run ftp on your side. This is a program designed to accept commands from
your terminal and pass them on to the other end. The program that you talk to on the other
machine is the FTP server. It is designed to accept commands from the network connection,
rather than an interactive terminal. There is no need for your program to use a well-known
socket number for itself. Nobody is trying to find it. However the servers have to have
well-known numbers, so that people can open connections to them and start sending them
commands. The official port numbers for each program are given in "Assigned
Numbers".
Note that a connection is actually described by a set of 4 numbers: the Internet address
at each end, and the TCP port number at each end. Every datagram has all four of those
numbers in it. (The Internet addresses are in the IP header, and the TCP port numbers are
in the TCP header.) In order to keep things straight, no two connections can have the same
set of numbers. However it is enough for any one number to be different. For example, it
is perfectly possible for two different users on a machine to be sending files to the same
other machine. This could result in connections with the following parameters:
Internet addresses TCP ports
connection 1 128.6.4.194, 128.6.4.7 1234, 21
connection 2 128.6.4.194, 128.6.4.7 1235, 21
Since the same machines are involved, the Internet addresses are the same. Since they are
both doing file transfers, one end of the connection involves the well-known port number
for FTP. The only thing that differs is the port number for the program that the users are
running. That's enough of a difference. Generally, at least one end of the connection asks
the network software to assign it a port number that is guaranteed to be unique. Normally,
it's the user's end, since the server has to use a well-known number.
Now that we know how to open connections, let's get back to the applications programs. As
mentioned earlier, once TCP has opened a connection, we have something that might as well
be a simple wire. All the hard parts are handled by TCP and IP. However we still need some
agreement as to what we send over this connection. In effect this is simply an agreement
on what set of commands the application will understand, and the format in which they are
to be sent. Generally, what is sent is a combination of commands and data. They use
context to differentiate. For example, the mail protocol works like this: Your mail
program opens a connection to the mail server at the other end. Your program gives it your
machine's name, the sender of the message, and the recipients you want it sent to. It then
sends a command saying that it is starting the message. At that point, the other end stops
treating what it sees as commands, and starts accepting the message. Your end then starts
sending the text of the message. At the end of the message, a special mark is sent (a dot
in the first column). After that, both ends understand that your program is again sending
commands. This is the simplest way to do things, and the one that most applications use.
File transfer is somewhat more complex. The file transfer protocol involves two different
connections. It starts out just like mail. The user's program sends commands like
"log me in as this user", "here is my password", "send me the
file with this name". However once the command to send data is sent, a second
connection is opened for the data itself. It would certainly be possible to send the data
on the same connection, as mail does. However file transfers often take a long time. The
designers of the file transfer protocol wanted to allow the user to continue issuing
commands while the transfer is going on. For example, the user might make an inquiry, or
he might abort the transfer. Thus the designers felt it was best to use a separate
connection for the data and leave the original command connection for commands. (It is
also possible to open command connections to two different computers, and tell them to
send a file from one to the other. In that case, the data couldn't go over the command
connection.)
Remote terminal connections use another mechanism still. For remote logins, there is just
one connection. It normally sends data. When it is necessary to send a command (e.g. to
set the terminal type or to change some mode), a special character is used to indicate
that the next character is a command. If the user happens to type that special character
as data, two of them are sent.
We are not going to describe the application protocols in detail in this document. It's
better to read the RFC's yourself. However there are a couple of common conventions used
by applications that will be described here. First, the common network representation:
TCP/IP is intended to be usable on any computer. Unfortunately, not all computers agree on
how data is represented. There are differences in character codes (ASCII vs. EBCDIC), in
end of line conventions (carriage return, line feed, or a representation using counts),
and in whether terminals expect characters to be sent individually or a line at a time. In
order to allow computers of different kinds to communicate, each applications protocol
defines a standard representation. Note that TCP and IP do not care about the
representation. TCP simply sends octets. However the programs at both ends have to agree
on how the octets are to be interpreted. The RFC for each application specifies the
standard representation for that application. Normally it is "net ASCII". This
uses ASCII characters, with end of line denoted by a carriage return followed by a line
feed. For remote login, there is also a definition of a "standard terminal",
which turns out to be a half-duplex terminal with echoing happening on the local machine.
Most applications also make provisions for the two computers to agree on other
representations that they may find more convenient. For example, PDP-10's have 36-bit
words. There is a way that two PDP-10's can agree to send a 36-bit binary file. Similarly,
two systems that prefer full-duplex terminal conversations can agree on that. However each
application has a standard representation, which every machine must support.
1 How do I configure MTU and
RWIN?
3 Why are some remote sites
unreachable (TTL bug)?
4 Why don't I get DNS
resolution for 32-bit applications?
5 Interoperability with BootP
servers.
6 Can't mount servers by IP
address.
7 How do I set up a HOSTS
file?
9 DNS lookup timeout is
ridiculously long.
10 Why can't I send
mail/news or upload with FTP (MTU path discovery problem)?
11 What good commercial
TCP/IP packages are available for Windows 95?
12 I can't get PC/NFS
working under Windows 95.
13 Will Trumpet and other
Win3 TCP/IP stacks work under Win95?
15 Assorted DNS resolution
problems.
16 What arcane TCP/IP
parameters can be configured?
17 Nobody seems to be able
to get routing to work.
18 Sockets get "eaten
up" and WinSmtp dies.
19 Can I disable DNS for
WINS resolution?
20 TCP/IP Requires
Ethernet_II Frame Type for ODI Driver.
21 Does Win95 support IP
Multicast?
22 How to obtain DNS
hostname via DHCP?
23 How to prevent anyone
from accessing my entire hard drive?
24 How can Win95 and UNIX
computers share files and printers?
25 Is there any way to run
Win95 from a UNIX server running Samba?
26 How can I prioritize
multiple default routers?
27 Why won't the Plus Pack
install properly on a machine with Internet Explorer installed?
29 What do I do if Win95
won't wait long enough for my DHCP server to assign an address?
30 Why does my winsock.dll
disappear or get renamed to winsock.old?
31 Bug in NetBIOS name resolution
stops LMHOSTS from working.
     |
Date: Sat, 18 Nov 1995 12:50:07 -0800 (PST)
From: Rich Graves <[email protected]>
By default, Win95 uses the largest value of MTU possible for the chosen media type. Most people who used the excellent 16-bit Trumpet Winsock, whose FAQ is at http://www.trumpet.com.au/wsk/faq/wskfaq.htm, configured these parameters for optimum efficiency and response, and really miss Trumpet's interface for setting them. This exchange should help:
>I would like to know how to customize PPP, if it's possible. >I mean how to change MTU value, RWIN value, etc... >(registration base ? ...) > >And if it's possible, what are the best values for a 28.8 connection ? MTU and RWIN are hidden in two different places in the Registry. MTU can be set for each protocol-adapter binding; RWIN is set globally. For MTU, open the Registry to: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\ Figure out which 000n is the TCP/IP protocol for your DUN connection by looking at the other values, then open up that 000n. Inside that 000n, create a new string variable called "MaxMTU" and enter your value. 1500 is the default; some terminal servers work better with 1002; lowest you should ever need is 552. In general, use the highest MTU your machine can handle without overruns. For RWIN, open the Registry to: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\ Create a new string variable called "DefaultRcvWindow" with a value 4 times (MTU + 24). It might also help to turn off your modem compression features; consult your modem manual, and enter an init string into DUN Modem Advanced Properties\Extra Settings.
| |
Date: Wed, 27 Dec 95 15:15:00 -0800
From: Rich Graves <[email protected]>
This appears to be a bug specific to Netscape, but it's worth mentioning here because so many people use it. Netscape 1.2N and 2.x, 32-bit versions, do not back off from TCP RESETs and ICMP unreachable messages; instead, they retransmits forever, with no timeout. On a dialup connection this will only cause some annoying "hangs," inducing the user to hit the "Stop" and "Reload" buttons a lot, but it can cause destructive packet storms on Ethernet and other high-bandwidth links.
Please see the initial post about this set of bugs at http://www-leland.stanford.edu/~llurch/win95netbugs/Readme-Netscape_Net_Bug.txt. That tells where to get relevant packet traces.
Two URLs you can try to check for these bugs are http://ftp.netscape.com (responds with a TCP RESET) and http://36.36.0.10 (nonexistent network, responds with an ICMP unreachable).
The Netscape product manager posted a message claiming the problem was irreproducible, to which I posted a response. Anyway, you can probably reproduce the problem yourself with the URLs above. You need some technical knowledge of the Internet Protocols to understand the problem.
Netscape 2.x attempts to avoid the problem by timing out, but this doesn't always work.
Netscape 2.0b4 also still seems to lose track of multiple TCP connections. E.g. local users usually can't load www-leland's root page all the way. If a page seems to load halfway and then "hang," then try hitting reload or stop. If this happens often, set maximum simultaneous TCP connections to 1 in network preferences. This will not really affect dialups, but it will noticeably slow page loading if you have a high-speed LAN connection.
Information from other winsock programmers indicates that this last problem is probably due to a bug in Win95's TCP/IP stack, not in Netscape. The Microsoft Internet Explorer works around the problem, but non-Microsoft programmers have not been given information that would allow them to do the same.
Ian Samson <[email protected]> reports that the same thing happens to him in Johannesburg -- Hi! :-)
| |
Date: Wed, 27 Dec 95 10:15:00 -0800
From: Bob Cringely <[email protected]>
Cringely's column in a recent InfoWorld said that Win95 couldn't connect to some sites because its TTL was set to 30 hops.
As far as I can tell, his source was wrong. It's 32 (which really isn't much of an improvement).
Because the Internet has grown to the point where routes including greater than 32 hops are rather common, everyone should open RegEdit to:
Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\MSTCP
Create a string variable named "DefaultTTL" with a value of, say, 128.
Another example of Microsoft's poor understanding of the Internet.
| |
Date: Wed, 27 Dec 1995 15:22:00 -0700
From: Rich Graves <[email protected]>
This is a more general form of Microsoft's Knowledge Base article Q139060, which appears to have been posted on December 5, a month after I sent them the following:
Problem: 1. You have Microsoft's TCP/IP protocol installed and properly configured. 2. 16-bit applications work by DNS name and IP address. 3. 32-bit applications work if you give an IP address. 4. 32-bit applications fail if you give a DNS hostname. Most Likely Cause: The file wsock32.dll is in your PATH, but is not correctly specified in the following Registry key: ->Hkey_local_machine->system->currentcontrolset->services->vxd-> mstcp->serviceprovider The normal value for this key is %WINDIR%\SYSTEM\WSOCK32.DLL Most Likely Solution: Make sure wsock32.dll is in your WINDOWS\SYSTEM directory. Run REGEDIT.EXE to specify the correct location. More information: There is a bug in NETSETUP that will cause this problem most of the time. (Thanks to Lee Gates of Microsoft for pointing this out). There appears to be a bug in SETUP that will cause this problem if you install Win95 in one directory, then later reinstall it into a different directory. You might also see this problem if you moved your various WinSock files around in an attempt to get a third-party WinSock.DLL file working. Microsoft has confirmed this to be a problem in Microsoft Windows 95. We will post more information here in the Knowledge Base as it becomes available.
I later got this reply, which is puzzling. He says his %WINDIR% variable is set incorrectly to C:, even though it is set correctly to C:\WINDOWS in MSDOS.SYS. remind me to follow up with this fella, or better, mail him yourself.
From: [email protected] Newsgroups: comp.os.ms-windows.win95.misc,comp.os.ms-windows.win95.setup,comp.os.ms-windows.networking.tcp-ip Subject: Re: Summary: 32-bit TCP/IP DNS problems on Win95 Date: 4 Nov 1995 04:59:32 GMT Message-ID: <[email protected]> >Okay, so it wasn't in my path. But it was specified correctly in the >registry. Needless to say, it didn't fix the problem. Does anyone have >a canonical list of "solutions" to this problem? There must be >something I haven't tried. I found my problem, though I still don't know why... The registry would be right, if windir actually pointed to my windows directory. Instead it is "C:". Not even "C:\". Unfortunately, I can't figure out who is responsible for this. My MSDOS.SYS has it specified correctly, and I don't find it anywhere in the registry (searching for windir). I solved my problem, at least for now, by creating c:\system and putting *sock* into it.
| |
Date: Fri, 12 Jul 96 16:48:00 -0800
From: Rich Graves <[email protected]>
One weekend, Lew Perin hacked together a BootP client for Win95's TCP/IP stack, which Microsoft said was too difficult to consider.
Microsoft chose to implement DHCP in a way that is not interoperable with BootP. One surmises they wanted to sell more NT DHCP servers.
John Wobus's DHCP FAQ, at http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html, might be of interest. There are some hybrid BootP/DHCP servers out there, but they don't all interoperate, and your routers might need to be upgraded to handle the kind of DHCP replies Microsoft likes. Anyway, read John's FAQ. If you absolutely can't get it from the Web, or from the periodic posts to the newsgroup comp.protocols.tcp-ip.ibmpc, you can ping John at [email protected].
We (various Stanford people) met with Microsoft officials about various DHCP issues on December 8th. I summarized the meeting for the list. Basically, they plan to support non-Microsoft BootP clients from NT Server "soon," but do not plan to support a BootP client for any version of Windows for the forseeable future.
Background:
I have been told that there is absolutely no causual relationship here.
| |
Date: Fri, 25 Jan 96 14:38:00 -0800
From: Rich Graves <[email protected]>
This is just an annoyance, really. It should be possible to mount servers by typing e.g. \\36.36.0.10, but it just isn't.
I suppose the workaround is to enter the machine name into your WINDOWS\HOSTS file, C.7.. See WINDOWS\HOSTS.SAM for the format, but note that the "live" version has no .SAM (or other) file type extension.
Note (thanks Thomas Lee) that the name put into HOSTS must be the same as the NetBIOS name of the target machine. For Windows 95, this is defined in the "Identification" tab in the Network control panel. Otherwise, the connection will be refused, even if you have the IP address correct. Chalk this up as another annoyance.
The reason I don't recommend LMHOSTS rather than HOSTS is that sometimes LMHOSTS doesn't work; see C.30.
Also see C.8. for information on prioritizing DNS, WINS, LMHOSTS, and local broadcasts for NetBIOS name resolution.
| |
Date: Wed, 27 Dec 95 23:00:00 -0800
From: Rich Graves <[email protected]>
Um, just set up a C:\WINDOWS\HOSTS file. The common mistake is to give this file a .SAM or .TXT extension. That's wrong -- it gets no file type extension. See HOSTS.SAM for the simple file format.
| |
Date: Sun, 17 Sep 95 22:30:47 -0800
From: Rich Graves <[email protected]>
I would think that the name resolution should work in precisely the opposite direction. Check the local LMHOSTS mappings first, then DNS, then WINS, and only as a last resort broadcast on the local subnet. Oh well.
This extract from the Resource Kit comes from Daniel M <[email protected]%gt;. This does not seem to apply to the 32-bit WinSock; could anybody tell me about that?
Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\MSTCP\ServiceProvider The following keys describe the order used to resolve host names. A lower number sets a higher priority for name resolution. These settings are used for 16-bit Windows Sockets, which need to rely on the resolvers that are expected to take the least time. The numbers indicate the default values specified in Windows 95. LocalPriority = 499 HostsPriority = 500 DNSPriority = 2000 NetbtPriority = 2001
| |
Date: Sun, 17 Sep 95 22:30:47 -0800
From: Rich Graves <[email protected]>
Most apps will freeze the machine while doing a DNS lookup, which is really annoying, especially since the timeout for DNS lookups is so long, especially in those weird places like Cornell and Clemson where Win95 doesn't seem to like the local DNS server. The "NameSrvQueryTimeout" in the Registry, which some people have pointed out, seems only to apply to Microsoft's proprietary WINS service, not Internet standard DNS.
There's gotta be a way to set this; anybody?
| |
Date: Wed, 27 Dec 95 15:33:00 -0800
From: Rich Graves <[email protected]>
If you can't send mail or news longer than 10 lines or so, or if you can't upload files with FTP or Microsoft networking, this is likely your problem. Downloads (from the net to your PC) are not affected. This assumes that you can upload files and send one-line messages fine; if not, you have a more fundamental problem. If the technical and political details don't interest you, skip them.
In late November, Microsoft finally documented this known problem in Knowledge Base Article Q138025. However, they got it wrong, because the Usenet article that Microsoft evidently copied, <[email protected]>, was unclear (my fault). In late December or early January, after reading this FAQ repeatedly through the tide and jericho proxy servers, Microsoft removed this article and every other mention of the PathMTU problem from the Knowledge Base. Apparently it's just to embarrassing to leave documented. I would appreciate it if Microsoft would please mail me when they have restored and corrected the KB article, so that I can remove this paragraph from the FAQ.
Anyway, the problem, as originally diagnosed in article <[email protected]> by Andri Pirard [email protected], is that Microsoft does MTU path discovery according to RFC 1191 (written in 1990 by folks from DEC and Stanford University), but many routers don't. Since Microsoft jumped on the TCP/IP bandwagon so late, they apparently don't understand that a standard only drafted in 1990 is an infant not likely to be adopted Internet-wide.
To fix this problem, run RegEdit.EXE and open it to the following key:
Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\MSTCP
Create the following binary variable with a value of 1:
PMTUBlackHoleDetect = 0 or 1
This should always fix the problem, unless there's a bug in their code, and we know that couldn't happen. If this doesn't solve the problem, create this variable in the same place:
PMTUDiscovery = 0 or 1
Now, this is where I believe Microsoft gets it wrong. Knowledge Base Article Q138025 says to create this with a binary value of 1. This does nothing. You really want to create it with a value of 0.
Setting MTU to some ridiculously low value is another effective way to fix the problem, but it hurts performance -- except over dialup, where an MTU of 576 or so might be a good idea anyway, especially if you have a cheap modem whose buffering doesn't work well.
All other TCP/IP stacks available for DOS and Windows fragment properly according to existing Internet standards. You'll only see this problem with the stack that Microsoft includes "free."
| |
Date: Fri, 29 Dec 95 17:20:00 -0800
From: Rich Graves <[email protected]>
You should probably just refer to Rawn Shah's excellent PC-Mac TCP/IP & NFS FAQ, http://www.rtd.com/pcnfsfaq/faq.html and in comp.answers. It's somewhat dated and has no Win95-specific information at this time, but it's got a lot of good stuff, which I see no need to reproduce here. Some Win95-specific addenda follow.
TGV (www.tgv.com), email [email protected] (TGV stood for Two Guys and a Vax many years ago before they got successful and went legit), is now shipping MultiNet 1.2. Nice clients for Telnet, FTP, News, and WWW, plus NFS, are included. However, according to John Casullo <[email protected]>, though, the current version of the TGV TCP/IP stack itself is not compatible with Win95 -- it only runs on Windows 3.x. Their advertising is very deceiving on this point. Some response from TGV would be nice.
Core Systems, http://www.win.net/~core/, email [email protected], has announced and is now shipping INTERNET-CONNECT for Windows 95. In addition to the features of Win95's stack, it supports BootP and includes better telnet and FTP clients. It does not support NetBIOS over TCP/IP, so you can't use Windows file/print sharing over this protocol. Demos are available. Be aware that Core appears to be a one-man virtual company...
FTP Software is now (started December 5?) shipping OnNet32, a stack and applications suite. Win95 Logo certification (for what it's worth), NFS client. Does support NetBIOS over TCP/IP.
| |
Date: Thu, 18 Jan 96 20:00:00 -0800
From: Rich Graves <[email protected]>
At the polite request of Jody Jackson <[email protected], who feels that no answer is better than an incomplete one, this question has been removed. Please send Jody email for the answer.
| |
Date: Wed, 27 Dec 95 15:42:00 -0800
From: Rich Graves <[email protected]>
"Usually." Trumpet will, and it's significantly faster than Win95's SLIP/PPP support. On the downside, TCP/IP stacks designed for Windows 3.x, even those based on 32-bit VxDs, will only support 16-bit TCP/IP clients. So you can't run 32-bit Netscape or Microsoft Exchange. For Win95 instructions and the latest information on the 32-bit Trumpet beta, see the Trumpet FAQ, http://www.trumpet.com.au/wsk/faq/wskfaq.htm.
There is also the issue that you must have exactly one WINSOCK.DLL in your PATH at a time. Rename them or shuffle them around while experimenting.
And there's the issue of Microsoft disabling third-party WinSocks. It was only designed to do this at installation time, but it actually does this on whim. If you are using a non-Microsoft winsock.dll, and find that your winsock.dll disappears or gets renamed at random, or if some applications call the wrong winsock.dll, the best thing to do, contrary to Microsoft's rear-end-covering advice, is to put your preferred winsock.dll into c:\windows and to set its read-only attribute with Win95's Properties dialog or the DOS attrib +r command.
| |
Date: Wed, 27 Dec 1995 15:44:00 -0800
From: Rich Graves <[email protected]>
That's right, they don't. You need to "upgrade" to Windows 95's included 32-bit TCP/IP, or one of the competitive commercial stacks, section C.11. For instructions, see A.3., related resources. If you use a modem, the Microsoft/Shiva package will be slower. Note that the new 32-bit shim for Trumpet WinSock (currently in open beta testing) will allow you to run 32-bit applications.
| |
Date: Thu, 07 Dec 95 10:15:00 -0800
From: Rich Graves <[email protected]>
At this time, I believe C.4. and various configuration follies explain away most of the following. I am still puzzled by Juha Noro <[email protected]>, the guy in Finland with the "personal" problem, i.e., he cannot resolve any hostname that begins with "personal."
I also saw this weird thing once where the NetBIOS-over-TCP/IP client (only) was spuriously appending the literal string "???" to DNS lookups for some hostnames (only). I got packet traces. But it went away mysteriously. If anyone else sees something similar, tell me.
I saved the old unresolved (if you'll pardon the pun) problems at http://www-leland.stanford.edu/~llurch/win95netbugs/DNS-Probs.txt and in some other files in that directory. Also see the email list, section A.2.
| |
Date: Mon, 18 Sep 1995 04:44:07 +0000
From: Daniel M <[email protected]>
Message-Id: <[email protected]>
Open the Registry to:
Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\MSTCP
BroadcastAddress = broadcast address in hexadecimal
Specifies the address to use for NetBIOS name query broadcasts. The default
is based on the IP address and the subnet mask.
BcastNameQueryCount = integer
Specifies the number of times the system will retry NetBIOS name query
broadcasts. The default is 3.
BcastQueryTimeout = milliseconds
Specifies the period of time the system will wait before timing out
broadcast name queries. The minimum value is 100. The default is 750.
BSDUrgent = 0 or 1
If this value is 1, specifies that Microsoft TCP/IP is to treat urgent data
the way some UNIX systems do (with a maximum of 1 byte of urgent data, for
example). If this value is 0, it specifies that the stack is to handle
urgent data as specified by RFC 1122. The
default is 1.
CacheTimeout = milliseconds
Specifies how long NetBIOS names are cached. The minimum is 60000
milliseconds (1 minute). The default is 360000 milliseconds (6 minutes).
DeadGWDetect = 0 or 1
Specifies whether Microsoft TCP/IP will use another gateway if the current
default gateway seems to be down. The default is 1.
DefaultRcvWindow = 16-bit number
Specifies the default receive window advertised by TCP. The default is
8192.
DefaultTOS = 8-bit number
Specifies the default type of service (TOS) for IP packets initiated by
Microsoft TCP/IP. The default is 0.
DefaultTTL = 8-bit number
Specifies the default time to live (TTL) for IP packets from Microsoft
TCP/IP. The default is 32.
DnsServerPort = port
Specifies which DNS server port to send queries to when resolving a name
using DNS. The default is 53.
EnableProxy = 0 or 1
If this value is 1, specifies that this computer is a WINS proxy agent. The
default is 0.
EnableRouting = 0 or 1
Specifies whether to enable static routing. Microsoft TCP/IP does not
supply a routing protocol, so all route table entries must be entered using
the route command. The default is 0.
IGMPLevel = 0, 1, or 2
Specifies the level of support allowed for IP multicast, corresponding to
the levels in RFC 1112. The default is 2.
InitialRefreshT.O. = milliseconds
Specifies the interval over which to contact WINS to refresh the name. The
minimum is 16 minutes, and the maximum is approximately 50 days
(0xFFFFFFFF). The default is 960000 milliseconds (16 minutes).
KeepAliveTime = 32-bit number
Specifies the connection idle time in milliseconds before TCP will begin
sending keepalives, if keepalives are enabled on a connection. The default
is 2 hours (7200000).
KeepAliveInterval = 32-bit number
Specifies the time in milliseconds between retransmissions of keepalives,
once the KeepAliveTime has expired. Once KeepAliveTime has expired,
keepalives are sent every KeepAliveInterval milliseconds until a response
is received, up to a maximum of MaxDat a Retries before the connection is
aborted. The default is 1 second (1000).
LmhostsTimeout = milliseconds
Specifies the period of time the system will wait before timing out when
seeking LMHOSTS for name resolution. The minimum value is 1000 (1 second).
The default is 10000 (10 seconds).
MaxConnections = 32-bit number
Specifies the maximum number of concurrent connections. The default is 100.
MaxConnectRetries = 32-bit number
Specifies the number of times a connection attempt (SYN) will be
retransmitted before giving up. The initial retransmission timeout is 3
seconds, and it is doubled each time up to a maximum of 2 minutes. The
default is 3.
MaxDataRetries = 32-bit number
Specifies the maximum number of times a segment carrying data or an FIN
will be retransmitted before the connection is aborted. The retransmission
timeout itself is adaptive and will vary according to link conditions. The
default is 5.
NameServerPort = port
Specifies the UDP port on the name server to which to send name queries or
registrations. The default is 137.
NameSrvQueryCount = integer
Specifies the number of times the system will try to contact the WINS
server for NetBIOS name resolution. The default is 3.
NameSrvQueryTimeout = milliseconds
Specifies how long the system waits before timing out a name server query.
The minimum is 100. The default is 750.
NameTableSize = integer
Specifies the maximum number of names in the NetBIOS name table. The
minimum allowable value is 1 and the maximum is 255. The default is 17.
NodeType = 1, 2, 4, or 8
Specifies the mode of NetBIOS name resolution used by NetBIOS over TCP/IP,
where 1 = b-node, 2 = p-node, 4 = m-node, and 8 = h-node. This value can be
configured using DHCP. The default is 1 (b-node), if no value is specified;
if WINS servers are specified and NodeType is not, then the default is 8
(h-node).
PMTUBlackHoleDetect = 0 or 1
Specifies whether the stack will attempt to detect Maximum Transmission
Unit (MTU) routers that do not send back ICMP fragmentation-needed
messages. Setting this parameter when it is not needed can cause
performance degradation. The default is 0.
PMTUDiscovery = 0 or 1
Specifies whether Microsoft TCP/IP will attempt to do path MTU discovery as
specified in RFC 1191. The default is 1.
RandomAdapter = 0 or 1
For a computer with multiple network adapters, specifies whether to respond
with an IP address selected randomly from the set of addresses on the
computer or whether to return the IP address of the adapter that the
request came in upon. The default is 0 ( not random; that is, return the
address of the adapter that the request came in on).
RoutingBufSize = 32-bit number
Specifies the total amount of buffer space to allocate for routing packets.
This parameter is ignored if EnableRouting=0. The default is 73216.
RoutingPackets = 32-bit number
Specifies the maximum number of packets that can be routed simultaneously.
This parameter is ignored if EnableRouting=0. The default is 50.
SessionKeepAlive = milliseconds
Specifies how often to send session keepalive packets on active sessions.
The minimum is 60 seconds. The default is 3600 seconds (1 hour).
SessionTableSize = integer
Specifies the maximum number of sessions in the NetBIOS session table. The
minimum allowable value is 1 and the maximum is 255. The default is 255.
SingleResponse = 0 or 1
For a computer with multiple network adapters, specifies whether to send
all IP addresses on a name query request from WINS. If this value is 1, the
system will send one address in a name query response; if 0, it will return
all the addresses of its adapters. The default is 0.
Size/Small/Medium/Large = 1, 2, or 3
Specifies how many buffers of various types to preallocate and the maximum
that can be allocated, where 1 = small, 2 = medium, and 3 = large. The
default is 1; the default is 3 if the WINS proxy is enabled.
| |
Date: Thu, 28 Dec 95 11:44:00 -0800
From: Vadim <[email protected]>
Message-Id: <[email protected]>
It's a common belief that windows 95 can't do IP forwarding (There were
several postings about it in comp.os.ms-windows.win95) and you have to use
NT to do it.
Win95 resource kit help file contains the following information:
[----]
Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\MSTCP\EnableRouting = 0
or 1
Specifies whether to enable static routing. Microsoft TCP/IP does not supply
a routing protocol, so all route table entries must be entered using the
route command. The default is 0.
[----]
I tried that on two machines (486DX2 and PENTIUM-75, both with ethernet card
and a RAS driver installed) and on both got a total system crash on boot (I
guess when loading vip.386).
Interesting enough, this whole routing issue has never been documented by
microsoft.
So, anybody "been there, done that" ?
Is it a bug, half-implemented feature or just wrong configuration ?
[Keith Davidson and Roger Pfister later reported that multiple TCP/IP interfaces only seem to work if each interface is on a different Class A net (because Win95 always creates a bogus route to 255.0.0.0 -- you can see it with ROUTE.EXE or the SNMP Agent).]
| |
Date: Fri, 29 Dec 95 20:00:00 -0800
From: Jack De Winter <[email protected]>
Has anyone else seen a problem where continuous access to a server
application will cause that application to run out of sockets or buffers
after a long time of continuous use?
Using NT, I can run my WinSmtp mail daemon (if you want details, send me a
quick message) for weeks with no problems. But after 12 hours under the
same conditions under win95 and its stacks (winsmtp as server and Exchange
as a client, checking every 2-5 minutes), it refuses to connect up any
more.
any ideas?
[Update 9/25/95: Eric Thomas <[email protected]> confirms the problem on his machine, but says that the 16-bit version of WinSMTP works fine.]>
[Update 9/30/95: Jack says this only happens with SLIP. WinSMTP seems to work fine over Ethernet and PPP. Also, the 16-bit version of WinSMTP works.]
[Update 10/20/95: Jack says, and I sort of understand:]
okay... the following is what I am doing, in asynchronous mode: case 1: client closes connection - receive FD_CLOSE - set to receive no more information - make sure information currently in layer is retrieved using 'recv' - send a lingering close (l_onoff set to FALSE and l_time set to 0) - delete internal node when close succeeds and doesn't block case 2: we initiate close - set so we don't receive any more data - lingering close, see above - delete internal node Just to reiterate, we are using Async mode and notifies (will be doing a port to non-async in a week or two), I believe we might have the Debug mode set on the protocol, and that is about it. Symptoms: - using NT's or almost any win16 stack, no problems - using win95 stack, runs out of buffer space or reports that it cannot connect after about 80 sessions
[A message from Jack to his user group concerning this problem is saved at http://www-leland.stanford.edu/~llurch/win95netbugs/jackdw-closes.txt.]
| |
Date: Tue, 10 Oct 95 23:30:00 -0800
From: Rich Graves <[email protected]>
WFW and NT have an "enable DNS for WINS resolution" checkbox that is turned off by default. In Win95 this feature is on by default, and there is no check box to turn it off. It turns out that this is what the "EnableDNS" switch in the Registry is for. If you turn it off, DNS is still enabled; it just isn't used for WINS resolution. This is part of Win95's redefinition of "intuitive." From article Q137368 in the Microsoft Knowledge Base:
How to disable NetBIOS name resolution on a domain-name system (DNS) while retaining other DNS functionality.
To disable NetBIOS name resolution on a DNS server, change the string value
EnableDNS
in the registry key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP
from 1 to 0.
| |
Date: Tue, 10 Oct 95 23:30:00 -0800
From: Rich Graves <[email protected]>
If you're using ODI drivers (usually for NetWare or really obscure network cards), you need to manually add the ETHERNET_II frame type to NET.CFG, or Microsoft TCP/IP won't work. This is just a particular case of general problem E.4. See article Q129726 in the Microsoft Knowledge Base:
| |
Date: Wed, 27 Oct 95 15:52:00 -0800
From: Rich Graves <[email protected]>
According to Microsoft, yes; there is a Registry switch for determining the level of support. However, at this time, I know of no applications that take advantage of Win95's claimed multicast support.
According to Microsoft's Dave MacDonald, Microsoft's IP multicast support (which is supposed to be the same for Win95 and WinNT) is detailed in ftp://ftp.microsoft.com/bussys/winnt/winnt-docs/papers/tcpipimp.doc.
Bob Quinn has posted some other relevant technical information at http://www.sockets.com/ch16.htm.
| |
Date: Fri, 12 Jul 96 16:32:00 -0800
From: Rich Graves <[email protected]>
You can't. Sorry. This is a huge problem for sites that, unlike Microsoft, have working DNS infrastructures and years of experience with Internet standards.
What you can do is configure TCP/IP properties to "Disable DNS." This does not actually disable DNS; it merely tells Win95 to use the DNS server(s) and domain returned by the DHCP response. Intuitive, huh? However, this still doesn't tell the client its hostname. That must be configured manually in, of all places, the NetBios "Identification" tab.
This little bug has caused many a problem for people who innocently put the name of a server they want to reach into the DNS hostname field. Because Win95 thinks that it is that server, the real server becomes unreachable.
(Also, the "Enable DNS" Registry switch is completely irrelevant; see question C.19.)
Another option is Lew Perin's billgPC BootP client for Win95.
| |
Date: Thu, 07 Dec 95 10:15:00 -0800
From: Rich Graves <[email protected]>
If you have a non-English-language version of Windows 95, you can't, unless you disable peer sharing and remote administration.
If you have the English-language version, get the patches from http://www.windows.microsoft.com/software/w95fpup.htm. Microsoft's clarification is incorrect (for starters, they didn't discover these problems; we know who pointed them out to them), but the patches appear to fix the problem.
These same problems have always affected Windows for Workgroups. Despite repeated warnings over the last nine months, Microsoft does not consider these problems important enough to mention in the TCP32B (Wolverine) distribution. The patch for WFW is called Wfwvsrvr.exe and is available on ftp.microsoft.com, CompuServe, and on the Web at http://www.microsoft.com:80/KB/PEROPSYS/windows/Q136418.htm.
| |
Date: Sat, 30 Dec 95 10:00:00 -0800
From: Rich Graves <[email protected]>
Microsoft chose not to make it easy for Win95 and UNIX machines to interoperate, because Microsoft sells Windows NT. But as Spock instructs us, there are always alternatives.
| |
Date: Wed, 27 Dec 95 23:00:00 -0800
From: Rich Graves <[email protected]>
In a word, no. Samba runs SMB over TCP/IP, which is a 32-bit-only protocol. You are able to run Win95 off a NetWare or SMB (LAN Manager, OS/2, NT) server because IPX/SPX and NetBEUI (only) are active in 16-bit DOS mode as well. But TCP/IP, no. Well, in theory you could load a 16-bit TCP/IP stack that supports SMB over TCP/IP, but then you wouldn't be able to run Win95's built-in file sharing or run any 32-bit WinSock apps, and that sort of defeats the purpose of running Win95.
| |
Date: Wed, 1 Nov 1995 15:08:53 -0500
From: [email protected]
The Resource Kit (Network Technical Discussion - TCP/IP Protocol - Configuring TCP/IP Settings Manually - Step 7) says that "Gateway addresses can be prioritized by dragging the IP address in the list of installed gateways." This is not true.
Does anybody have a method that works?
| |
Date: Wed, 1 Nov 1995 15:08:53 -0500
From: Mike Johnston (by way of Bob Verrinder)
Message-ID: <[email protected]>
I did find the answer and it seems that if you loaded Explorer previously it
will not load through Plus because it sees that it has already been loaded
from reading the registry during setup. To rectify the problem do the
following:
1) Start up REGEDIT.EXE - The registry editor
2) Go to key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer
3) You will should see two lines displayed in the right pane of
regedit.
(Default) (value not set)
IVer "xxx"
4) delete the IVer key by right clicking on the word IVer and
selecting delete
5) Close up regedit. Reinstall Plus! (or just the Jumpstart Kit if
that's all you need).
For good measure you might as well reboot before you do that.
| |
Date: Mon, 6 Nov 1995 10:55:17 -0600
From: David Devereaux-Weber <[email protected]>
Message-ID: <[email protected]>
[Complain, I guess, until Microsoft fixes this.]
We have had difficulty with Microsoft's implementation of DHCP in WIN95. the DHCP client is supposed to wait a reasonable period of time for the server to check an address before it is given to the client. Microsoft's client doesn't wait very long - it bails out early and reports no response. The people at Sun hacked their client software for us to temporarily work around the problem. Unfortunately, trying to get Microsoft to understand and support the official protocol has been unsuccessful to date.
We call our Internet software collection WiscWorld. We don't recommend using WiscWorld with WIN95, but we have a Web page with instructions on doing it if you really want to:
http://axle.adp.wisc.edu/NST/wiscwrld/ww95/ww95.html
| |
Date: Fri, 29 Dec 1995 21:18:00 -0800
From: Rich Graves <[email protected]>
If you're using a non-Microsoft winsock.dll, then Win95 is working as designed. See http://www.windows.microsoft.com/pr/clarifications.htm or certain papers filed with the US Department of Justice, Anti-Trust Division.
If you're using Microsoft's winsock.dll, as many people with this problem are, then this is a bug.
In any case, the solution is to make sure that the only copy of winsock.dll is in your %WINDIR% (i.e., C:\WINDOWS), and mark is read-only with Explorer Properties or attrib +r.
Microsoft's claim that non-Microsoft DLLs don't belong in the Windows directory is hogwash.
| |
Date: Wed, 20 Dec 1995 07:57:30 -0800
From: Rich Graves <[email protected]>
A Microsoft Knowledge Base Article had said that LMHOSTS doesn't work when DNS is enabled. This is incorrect.
Jeff Strain <[email protected]> appears to have found the real problem:
If you are running both IPX and TCP transports, and are using MS Network client and client for Novell networks, *and* have unbound MS Net from the IPX protocol settings, then LMHOSTS resolution will not work.
The workaround is to rebind MS Net over IPX, even if you do not use IPX for MS Network. This will slow down login a bit, but your LMHOSTS resolution should work.
Another workaround is to put the hosts to which you want to connect into a HOSTS file rather than LMHOSTS.
Windows95 (Win95-L) & Networking FAQ COPYRIGHT � 1998 by Hans Klarenbeek
Windows NT 4.0 FAQ COPYRIGHT � 1998 by Hans Klarenbeek
All Rights Reserved by the author, Hans Klarenbeek
Permission is granted freely to distribute this article in electronic form as long as it is posted in its entirety including this copyright statement. This article may not be distributed for financial gain. This article may not be included in any commerical collections or compilations without the express permision of the author, Hans Klarenbeek([email protected])