C.1. How do I configure MTU and RWIN?
Date: Sat, 18 Nov 1995 12:50:07 -0800 (PST)
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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.
C.2. Netscape Packet Storm Bugs. c2
Date: Wed, 27 Dec 95 15:15:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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 <ids@zeus.HSRC.ac.za>
reports that the same thing happens to him in Johannesburg -- Hi! :-)
C.3. Why are some remote sites unreachable (TTL
bug)?
Date: Wed, 27 Dec 95 10:15:00 -0800
From: Bob Cringely <bob@cringely.com>
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.
C.4. Why don't I get DNS resolution for 32-bit applications?
Date: Wed, 27 Dec 1995 15:22:00 -0700
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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: parkerr@serv2.fwi.com
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: <47ervk$e0v@news.ios.com>
>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.
C.5. Interoperability with BootP servers.
Date: Fri, 12 Jul 96 16:48:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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.nwindex.htm,
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 jmwobus@syr.edu.
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:
- Microsoft sells a DHCP server for NT, but no BootP
server.
- DHCP and BootP are 95% identical. DHCP is based
on BootP. BootP is simpler and more widely used.
- The DHCP RFCs are at the "proposed" stage.
- This stage is defined as "likely to change"
and "experimental."
- The DHCP RFCs suggest that BootP and DHCP should
interoperate.
- Most non-Microsoft DHCP servers support BootP.
- Most newer non-Microsoft BootP clients support DHCP.
- Apple's Open Transport supports BootP, DHCP, and
RARP.
- Microsoft supported BootP in earlier versions of
TCP/IP for Windows.
- Most BootP servers run on UNIX.
- UNIX and NT are competitors.
- Windows dominates the market for network clients.
- Microsoft only supports DHCP in the current versions
of Win95, WFW, and NT.
I have been told that there is absolutely no causual
relationship here.
C.6. Can't mount servers by IP address.
Date: Fri, 25 Jan 96 14:38:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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.
C.7. How do I set up a HOSTS file?
Date: Wed, 27 Dec 95 23:00:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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.
C.8. Default hostname resolution order (broadcast-WINS-DNS-LMHOSTS)
is non-ideal for my site; how can I change it?
Date: Sun, 17 Sep 95 22:30:47 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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
<puppet@mail.dynamsol.com%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
C.9. DNS lookup timeout is ridiculously long.
Date: Sun, 17 Sep 95 22:30:47 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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?
C.10. Why can't I send mail/news or upload with
FTP (MTU path discovery problem)?
Date: Wed, 27 Dec 95 15:33:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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, <199509242223.PAA04539@Networking.Stanford.EDU>,
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
<443n5c$ff9@aix1.segi.ulg.ac.be> by Andri Pirard pirard@vm1.ulg.ac.be,
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."
C.11. What good commercial TCP/IP packages are available
for Windows 95?
Date: Fri, 29 Dec 95 17:20:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
You should probably just refer to Rawn
Shah's excellent PC-Mac
TCP/IP & NFS FAQ, http://www.rtd.com/pcnfsfaq/nwindex.htm 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 sales@tgv.com (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 <Manta@cybercomm.net>,
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 lvuong@cores.com,
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.
C.12. I can't get PC/NFS working under Windows 95.
Date: Thu, 18 Jan 96 20:00:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
At the polite request of Jody Jackson <jrj@micronexx.com,
who feels that no answer is better than an incomplete one, this question
has been removed. Please send Jody email
for the answer.
C.13. Will Trumpet and other Win3 TCP/IP stacks
work under Win95?
Date: Wed, 27 Dec 95 15:42:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
"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.
C.14. I'm using some 16-bit TCP/IP stack like Trumpet
and 32-bit apps like Netscape and Exchange don't work.
Date: Wed, 27 Dec 1995 15:44:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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.
C.15. Assorted DNS resolution problems.
Date: Thu, 07 Dec 95 10:15:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
At this time, I believe C.4.
and various configuration follies explain away most of the following. I
am still puzzled by Juha Noro <nco@noro.pp.fi>,
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.
C.16. What arcane TCP/IP parameters can be configured?
Date: Mon, 18 Sep 1995 04:44:07 +0000
From: Daniel M <puppet@mail.dynamsol.com>
Message-Id: <19950918044454.00974ece.in@toast.dynamsol.com>
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.
C.17. Nobody seems to be able to get routing to
work.
Date: Thu, 28 Dec 95 11:44:00 -0800
From: Vadim <vadim@melig.co.il>
Message-Id: <199509232144.XAA03624@mail.netvision.net.il>
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).]
C.18. Sockets get "eaten up" and WinSmtp
dies.
Date: Fri, 29 Dec 95 20:00:00 -0800
From: Jack De Winter <jackdw@metrics.com>
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 <thomas@rtp.ericsson.se>
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.]
C.19. Can I disable DNS for WINS resolution?
Date: Tue, 10 Oct 95 23:30:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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.
C.20. TCP/IP Requires Ethernet_II Frame Type for
ODI Driver.
Date: Tue, 10 Oct 95 23:30:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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:
C.21. Does Win95 support IP Multicast?
Date: Wed, 27 Oct 95 15:52:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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.
C.22. How to obtain DNS hostname via DHCP?
Date: Fri, 12 Jul 96 16:32:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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.
C.23. How to prevent anyone from accessing my entire
hard drive?
Date: Thu, 07 Dec 95 10:15:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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.
C.24. How can Win95 and UNIX computers share files
and printers?
Date: Sat, 30 Dec 95 10:00:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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.
- Freeware Samba file and print client and server
for UNIX
- The easiest way to get Windows (any version) to
share files and printers with UNIX (in either direction) is with Samba,
http://lake.canberra.edu.au/pub/samba/, a SMB implementation for UNIX
that allows your machine to masquerade as the NT Server that Microsoft
wants you to buy. Of course you need to be (good friends with) the system
administrator, but Samba is quite easy, reliable, and free. The main thing
to worry about is Windows' "password caching feature," which
by default would sort of compromise the security of your UNIX machines.
See question E.27. for instructions on turning
"password caching" off.
- Shareware for printing from Windows to UNIX
- WSLPRS is the standard LPR (Internet standard client
for printing to UNIX and other machines) implementation for Windows. A
recent version should be available on all the PC software archives, for
example, ftp://mirrors.aol.com/pub/cica/pc/win3/winsock/.
- Shareware for printing from UNIX to Windows
- David L. Brooks <info@brooksnet.com>,
http://brooksnet.com/, offers a shareware
LPD (Internet standard print server) implementation for Windows.
- Pay-through-the-nose-ware
- See C.11. for a few commercial
packages that include NFS (standard for file and print sharing) and
LPR/LPD (standard for printing).
C.25. Is there any way to run Win95 from a UNIX
server running Samba?
Date: Wed, 27 Dec 95 23:00:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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.
C.26. How can I prioritize multiple default routers?
Date: Wed, 1 Nov 1995 15:08:53 -0500
From: PLINSPO1.MSCHMITT@eds.com
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?
C.27. Why won't the Plus Pack install properly on
a machine with Internet Explorer installed?
Date: Wed, 1 Nov 1995 15:08:53 -0500
From: Mike Johnston (by way of Bob Verrinder)
Message-ID: <47958p$mq6@maureen.teleport.com>
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.
C.28. What do I do if Win95 won't wait long enough
for my DHCP server to assign an address?
Date: Mon, 6 Nov 1995 10:55:17 -0600
From: David Devereaux-Weber <djdevere@facstaff.wisc.edu>
Message-ID: <199511061655.KAA73144@audumla.students.wisc.edu>
[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
C.29. Why does my winsock.dll disappear or get renamed
to winsock.old?
Date: Fri, 29 Dec 1995 21:18:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
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.
C.30. Bug in NetBIOS name resolution stops LMHOSTS
from working.
Date: Wed, 20 Dec 1995 07:57:30 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
A Microsoft
Knowledge Base Article had said that LMHOSTS doesn't work when DNS
is enabled. This is incorrect.
Jeff Strain <jstrain@hp-vcd.vcd.hp.com>
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.
All Rights Reserved by the
author, Hans Klarenbeek
Windows95 (Win95-L)
FAQ © 1996 PERMISSION:
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(hansie@wantree.com.au)
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |