![[Update]](icons/update.gif){kind=icon}
![[New]](icons/new.gif){kind=icon}
![[Correction]](icons/correction.gif){kind=icon}
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.
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! :-)
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\MSTCPCreate 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 <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.
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.toc.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 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:
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.
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.
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
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?
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\MSTCPCreate the following binary variable with a value of 1:
PMTUBlackHoleDetect = 0 or 1This 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 1Now, 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 <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/toc.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 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.
Date: Thu, 18 Jan 96 20:00:00 -0800 From: Rich Graves <win95netbugs-owner@lists.stanford.edu>At the polite request of Jody Jackson, who feels that no answer is better than an incomplete one, this question has been removed.
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.
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.
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.
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.
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).]
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.]
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
EnableDNSin the registry key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCPfrom 1 to 0.
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:
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.
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.
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.
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.
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.
Date: Wed, 1 Nov 1995 15:08:53 -0500 From: PLINSPO1.MSCHMITT@eds.comThe 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: <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.
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
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.
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.