Date: Wed, 27 Dec 95 16:03:00 -0800 From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
Thanks to Richard Ryan <rryan@bhost.blackhills.com> for calling this set of problems to our attention. For more information on this problem, see the searchable bsdi-users archive at http://www.nexial.nl/cgi-bin/bsdi.
Microsoft's RFC for their "extensions" to PPP, which were rejected by the Internet Engineering Task Force (IETF), is at ftp://ftp.microsoft.com/developr/rfc/ipcpexts.txt. Note 8-character truncation to developr! Limited and incomplete information on Microsoft's nonstandard CHAP implementation is available in that directory.
There has been some discussion of this on the comp.protocols.ppp newsgroup, and here's an unofficial discussion of the problem from BSDI:
Date: Sat, 26 Aug 1995 11:46:58 -0500 Message-Id: <199508261646.LAA05931@krystal.com> From: Paul Borman <prb@BSDI.COM> Subject: Re: Pesky IPCP Messages > Now that Windows 95 is beginning to appear, I am beginning to get more > of these messages with the BSDI 2.0 ppp implementation. No real > problems but a real drag on the messages log. > > ppp3: unknown IPCP option received (129) > ppp3: unknown IPCP option received (130) > ppp3: unknown IPCP option received (131) > ppp3: unknown IPCP option received (132) Microsoft proposed some extensions to IPCP to negotiate the DNS server and the NetBUI server. The IETF rejected them as this was the wrong level to do this. Microsoft decided to ignore the IETF and implement them anyhow. Microsoft should provide a way to not use them (since they are totally non-standard and are only supported by Microsoft clients). Users of Microsoft networking products would need to contact Microsoft to determine how to do this. [Rich's note: in fact there is no way to turn them off, and I believe Paul knew it.] This note is meant to be an explanation of what is happening and should not be interpreted in any way as an official statement by BSDI on The Microsoft IPCP Options. -Paul Borman prb@bsdi.com
[Update December 27th: there have been some posts on Usenet that Microsoft's IPCP documentation is also wrong about what Win95 actually does. See comp.protocols.ppp and a particularly informative article I've saved at http://www-leland.stanford.edu/~llurch/win95netbugs/ipcp-huh.txt.]
Date: Fri, 29 Dec 95 16:06:00 -0800 From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
There have been a heck of a lot of posts in comp.os.ms-windows.win95.setup complaining that file transfers using Win95's native SLIP/PPP are slower than they were using Trumpet WinSock. There have been lots of posts that say performance is OK, but I don't recall any claiming that performance has improved.
The problem is probably rooted in the fact that when you use Win95's built-in SLIP/PPP, you're really using two protocol stacks, a TCP/IP stack built by Microsoft, and a remote access stack developed by Shiva Corporation, so you've got extra overhead to deal with.
aladin@scruznet.com (Leo Szumel) claims that he got better performance turning IP header compression off, which makes no sense, but you can try it.
Here are some general tips applicable to any dialin protocol:
Message-Id: <199509171252.IAA01886@panix.com> Date: Sun, 17 Sep 95 08:51:33 -0400 From: richard <rpritz@panix.com> To: llurch@networking.stanford.edu Subject: faq: dialup speed Two things improved speed for me: 1) Turn off software compression (DialUpNetworking->Properties ->ServerType->EnableSoftwareCompression) 2) Turn off error correction for my modem - at AT&Q6 to the init string. this may be a modem interoperability problem of mine, rather than a general win95 issue. 3) A few people have said that fiddling with mtu, etc. settings does not help. I haven't tried.
[See also the Windows Comm FAQ, http://www.malch.com/comnwindex.htm. Please see also D.9.]
Date: Tue, 12 Sep 1995 01:55:42 GMT From: jewald@primenet.com (Jim Ewald) Newsgroups: comp.os.ms-windows.win95.misc,comp.os.ms-windows.win95.setup Message-Id: <432pb4$n3@nnrp3.primenet.com>
[There have been several followup posts in the Win95 newsgroups confirming that the problem is not specific to any particular client software or ISP.]
Some of us in a local news group have discovered a nasty problem that causes Win95 to lock up solid. Does anyone have a fix for this or can anyone at least let MS know about it? The tech support lines are very useless right now. An excerpt from the conversation follows. Thanks! - Jim Ewald MSG 1 ---------- bigrex@primenet (Bob Nixon) wrote: >I'm using Win 95 to connect up to Primenet and I keep encountering an >infrequent but ANNOYING problem. Everything appears to work ok and >every once in awhile(1 out of 25 times) when I click on disconnect, my >computer freezes. The clock stops, the cursor won't move and the only >remedy is to power off. At the time I click disconnect I have no other >programs running...just the TCP/IP dial-up. I was wondering if anyone >else is having this same problem? MSG 2 ---------- budster@primenet.com says... >This has happened to me too but, it always happens after I force closure of >some winsock app(example CTRL-ALT-DEl of Telnet, WS-FTP32 or one of the >newsreaders that's slow to or not responding). I think it leaves a bad code >somewhere in the system and causes a lockup when you close Win95's winsock. MSG 3 ---------- Claudio@primenet.com writes: >This happens to me whenever I'm disconnecting and I happen to move the >mouse at the same moment the modem is hanging up. My computer freezes, >dnd there's nothing you can do except to turn the machine off and on >again. I knew of this bug a long time ago, and I thought It was that I >had something not configured right, but for what I can see here, it >happens to other people too. By the way, I'm still using a beta >version of win95, build 950r2. Are you guys using the commercial >version?
Another person with this problem is Bob Werth <bobw@on-ramp.ior.com>.
Date: Wed, 27 Dec 95 16:08:00 -0800 From: Neil Moodie <nmoodie@c031.aone.net.au>
When making network config changes (often small, unimportant, insignificant etc changes), the properties of the dial-up connection are reset back to defaults. These defaults include PPP transport, with "server assigned" IP address and "server assigned" name server address.
This caught me out a few times, as I have a locally assigned name server address and have had to re-enter this information into the dial-up connection properties TCP/IP Settings after making minor changes to the dial-up config. Even configuring a new modem can reset these settings.
This problem is only compounded by the "Internet Setup Wizard" included with the Plus Pack and the Microsoft Internet Explorer, which adds a third confusing interface to TCP/IP settings.
Date: 23 Sep 1995 03:28:47 GMT From: oturn@gulf.net (Oran Turner)
The "phantom" com port seems to be a common problem with PNP motherboards and internal modems. I have a mouse on COM1 and an internal modem on COM2, with my physical COM2 turned off in BIOS. This is the problem...in the "Device Manager" in Windows 95, under "Ports (COM & LPT)", not only are my standard COM1, COM2 & LPT1 ports listed, but also listed is another entry labeled only "Communications Port." The settings for this extra entry correspond to the settings for COM1 (IRQ 4, I/O 03F8-03FF). I simply disable this extra entry to avoid the conflict the system detects, and everything seems to work fine.
Probably 90% of the phantom port problems are related to the interaction between an internal modem, a physical COM port, a PNP system and Windows 95. I've brought the problem to the attention of my motherboard manufacturer, but they pretty much blew me off. (I've got an Asus P55TP4XE.)
[Another hardware detection problem that might hit you is that on many Pentium motherboards, Win95 insists on loading a driver for a nonexistent bus mouse. Someone posted a technical explanation of how Microsoft made this mistake, but I lost it.]
Date: Sat, 23 Sep 1995 00:49:16 GMT From: peeler@peeler.com Newsgroups: comp.os.ms-windows.win95.misc References: <43edr8$rfd@grovel.iafrica.com> <43rofb$50u@sydney1.world.net> <nagamatiDFBExI.DnC@netcom.com> In article <nagamatiDFBExI.DnC@netcom.com> nagamati@netcom.com (Romklau Nagamati) writes: >John McGhie (jmcghie@world.net) wrote: >: markdm@iafrica.com (Mark Maunder) wrote: >: >: >I am at my wits end. I have been trying to get a 32 bit PPP connection with >: >win95 for the past 2 weeks and have finally managed to get it to dial in and >: >log on, but now it looks as though either the DNS is not working or my >: >applications or just not talking to the win95 Dialup adapter. (Much Deleted) I had the same problem and was able to resolve it by putting a delay statement immediately before the "endproc" line. It appeared that the script routine was closing off before the server parsed back the Dynamic Address. I found a delay of anywhere between 2 and 5 seconds was sufficient.
Date: 6 Oct 1995 07:43:12 GMT From: tatosian@plough.enet.dec.com (Dave Tatosian)
If you have an S3-based video card (most 64-bit cards including Number 9 and Diamond), you cannot use COM4 because of a memory base address conflict.
These cards use port addresses (46E8h, in the case of S3) for 8514/XGA support, which will be *aliased* to address 2E8h by most COM port address decoders - which tend to only decode the low order 10 bits of the address field. Putting a modem on COM4 therefore ends up in conflict with the graphics card - but it's usually only apparent when the graphics card is running in a mode other than straight VGA (ie: in DOS, you won't see a problem, but running in Windows/Win95 in say 800x600, you will).
The solution is to move the modem to some other port address, but of course you have to avoid conflicts with your other COM ports. If your mouse is on COM1, and COM2 is free, you should use COM2. But if you want to keep your COM2 available for a serial port, you can't use the "standard" COM3 setup for the modem, because COM3 normally uses IRQ4 (which will conflict with COM1).
But you *can* set the modem up to use COM3 with *IRQ5* (most modems will support this configuration). That way, you won't conflict with COM1's use of IRQ4. If IRQ5 is already being used by a sound card, switch the sound card to use IRQ7 instead.
After making the required changes to the modem (and sound card if required) you'll have to make sure that Win95 does the right thing on startup. It should detect the new configuration and make the appropriate changes to the properties and resource allocations, but you should check under Control Panel-System-Device Manager to be sure. If needed you might have to set some of the resources manually.
Microsoft has also finally woken up to this problem, and has documented it in Knowledge Base article Q127138, http://www.microsoft.com:80/KB/PEROPSYS/win95/Q127138.htm.
Date: Wed, 27 Dec 95 17:31:00 -0800 From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
waung@mprgate.mpr.ca (William Waung) and a dozen others report that they can not establish a PPP connection to Xyplex, IOLAN, older Teleport, and other terminal servers unless they disable IP compression. More investigation is needed. You can see William's message and followups on the win95netbugs list archive, gopher://quixote.stanford.edu/1m/win95netbugs, under the subject "Internet connection failure: no network protocol compatibility." Or look for his original newsgroup post to comp.os.ms-windows.win95.* on the www.dejanews.com searchable USENET archive. To help you recognize the symptoms, the error entries in his PPP log referred to problems with CCP (protocol 80fd). If you also run into problems with PPP-level compression (not modem-level compression), please mail win95netbugs-owner@lists.stanford.edu.
Date: Wed, 27 Dec 1995 17:33:00 -0800 From: neal@postoffice.ptd.net (NR Haslam) Newsgroups: comp.os.ms-windows.win95.misc Here is some information that may help someone experiencing slower than expected downloads. For the good of the order: Start by ensuring that your machine is not doing extra work by compressing data unnecessarily. Double click on My Computer / Dial Up Networking Right Click on Prolog Icon (or whatever you called it on your machine) Click on Properties / Server Type Remove all checks from boxes except for the TCP/IP box. Next, let's be sure that your modem is answering your computer correctly: Click Start / Settings / Control Panel Double click on Modem Click on Diagnostics Click Com2 (or what ever port your modem is assigned) Click More Info Mine says: Port COM2 Int 3 Addr 2F8 UART NS 16550AN Highest Speed 115K Baud Another trick you might try is to change your modem driver to the Supra 288i. See if that makes any difference compared to the Hayes 288 settings. Don't know how you feel about those "standard" selections, but I am not a fan of default settings.
[Also see C.1. for information on setting MTU and RWIN.]
Date: Wed, 27 Dec 95 17:35:00 -0800 From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
A highly regarded source at a terminal server vendor told me, and we and InfoWorld Magazine have verified, that Win95 sends the CIPX length field backwards. As a result, properly behaved PPP servers will discard the bad packets, and you get no IPX connectivity. The solution is either to disable IPX compression on the Win95 client (there's a convenient checkbox for this), or to disable CIPX length field verification at the PPP server (many vendors are starting to do this by default because it's usually easier to accommodate Microsoft's bugs than to get them fixed).
Date: Wed, 27 Dec 95 17:49:00 -0800 From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
There is some controversy over who is at fault here. Since Sun's PPP client/server works fine with non-Microsoft PPP clients and servers, fingers tend to point towards Redmond. For some discussion of this issue, see the Usenet threads saved at http://www-leland.stanford.edu/~llurch/win95netbugs/ppp/ and the win95netbugs list archive.
Currently, the fix is to run a third-party PPP server, such as dp. Sun released a patch for this problem with Win95, but it solves the crashing problem simply by shutting Win95 clients out.
Date: Wed, 27 Dec 95 20:07:00 -0800 From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
The dialup scripter that Microsoft sells as part of the Plus! Pack supports useful features like branching, intelligent retries, and variables. The dialup networking scripter included with Win95 (see D.13.) only supports simple linear scripts. Because Microsoft never documented this difference, some ISPs were distributing scripts that would only work with the Plus! scripter, and scratching their heads when they didn't work. Don't make this mistake.
Date: Wed, 27 Dec 95 19:49:00 -0800 From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
SLIP and the scripter aren't included on the floppy or some OEM versions of Win95, and there exists no Setup option to install them, but you can get them free without buying the Plus Pack. If you have the CD, use Add/Remove Programs\Windows Setup\Have Disk and navigate to Admin\Apptools\DSCRIPT. If you don't have the CD, you can download DSCRPT.EXE (note missing "I") from Microsoft's online services, such as www.windows.microsoft.com, specifically on the CD Extras Page, http://www.windows.microsoft.com/windows/software/cdextras.htm.
Date: Wed, 27 Dec 95 19:49:00 -0800 From: Rich Graves <win95netbugs-owner@lists.stanford.edu>
Here's a bizarre one. If:
Then you don't get a default router, and you can't reach remote sites. However, because of some other odd Win95 behavior and the proxy arp features of most terminal servers, you can usually get to hosts within your Class A net (i.e., X.*.*.*).
It's not just me -- ask jpherron@indiana.edu (Jon-Paul Herron).
[Please see D.6. for a possible hint.]
Date: Sat, 23 Sep 95 06:15:40 -1000 From: Richard Puga <puga@maui.com>
I must be the only person on earth who has a statically assigned IP address which stays the same each time I dial in... or at least I'm the only one who is annoyed by the problem...
When I am dialed in PPP and have several telnet sessions open and say a couple of FTP's going and maybe even IRC the PPP daemon will kill all those sessions if the phone line drops!
And I mean KILL.. all my screens either completely Zap off my screen or erase themselves.. all my ftp's stop and IRC dies..
In the other operating systems I have on my computer or use from time to time (which include FreeBSD, NetBSD, NextStep, SunOS, OS/2, windows311(w/ trumpet)... (and Mac OS but I don't use it:)) will all allow me to simply redial the ISP and continue where they left off.. Its not unreasonable for the FTP sessions to keep going as well.. Heck even HTML transfers have picked back up upon redialing...
It's my understanding that the original DOD purpose for TCP/IP protocol was to withstand intermittent loss of signal or even to reroute traffic in case of loss of that signal...
[Indeed, every PPP interface I know of save the Shiva/Microsoft package will reconnect. This is how TCP/IP and PPP were designed. There is no reason Win95 should do this.]
Date: Mon, 2 Oct 1995 21:18:48 GMT From: ramesh@scr.siemens.com (Ramesh Viswanathan)
Open My Computer -> Dial-Up Networking -> Right-click your ISP icon and choose Properties -> Configure button -> Connection Tab -> Advanced Button -> Enter desired modem initialization string in the Extra Settings box.
Date: Fri, 19 Jan 1996 12:56:48 +1000 From: Troy Rollo <troy@corvu.com.au>
[Please note that TwinSock is not the same thing as Trumpet WinSock.]
Yes, and the new version supports 32-bit applications, too. See the TwinSock Page, http://www.corvu.com.au/twinsock/, or any SimTel mirror for a recent version.
Date: Tue, 3 Oct 1995 03:49:57 GMT From: Steve Whittaker <swhitt@u.washington.edu>
[The Internet Adapter is a SLIP/PPP emulator that runs in UNIX to give you a near complete Internet connection even if you only have a shell account.]
Yes, though for older versions you might need to disable IP header compression. There are some useful FAQs at:
The freeware SLiRP will also work fine.
Date: Mon, 09 Oct 1995 20:07:47 GMT From: dolender@solutions.net (Doug Olender) Message-ID: <45bruv$fet@Alpha.remcan.ca>
You can start up DialUp Networking as follows:
rundll32.exe rnaui.dll,RnaDial connection_name
Date: 13 Oct 1995 18:22:45 GMT From: jcmorris@mwunix.mitre.org (Joe Morris) Message-ID: <45mapl$lsk@reuters2.mitre.org>
A couple of points:
Access ports that use challenge/response authentication (for example the SecurID card from Security Dynamics) require a post-connect window in order to deliver the challenge and receive the response.
Also, on our dial-in interface systems (Xylogics Annex boxes) I've found that WIN95 will fail to complete the initial PPP handshaking if the dialup connection is configured to use NetBEUI. Assuming that you are planning to use just TCP/IP over the dial link, right-click the connection icon (in "Dial-up Networking") and select PROPERTIES; then click the "Server Type" button. Make sure that the "Type of dial-up server" is correct (default and almost always correct value is "PPP; Windows 95; Windows NT 3.5; Internet"), and make sure that the NetBEUI and IPX/SPX protocols at the bottom of the window are *not* checked.
Date: Mon, 16 Oct 1995 16:46:22 -0700 From: Adrien de Croy <adrien@iconz.co.nz> Message-ID: <3082EECE.72E1@iconz.co.nz>
[With all due respect to Adrien, I really think Win95 is the wrong tool for the job. A dedicated DOS-based router, like the ones mentioned in the FAQ for comp.protocols.tcp-ip.ibmpc, would give better performance on much cheaper hardware. Of course, the user interface would be nowhere hear as pretty, which is why WinGate is the right tool for most "normal" people.]
Adrien wrote the very cool proxy server WinGate for this purpose. It runs under Win95 or WinNT. Get it from http://nz.com/NZ/Commerce/creative-cgi/special/qbik/wingate.htm.
For those of you who don't know the jargon, a proxy server lets you use common TCP applications like mail, telnet, ftp, and the Web by going through an intermediate site. Proxy servers are often used by corporate sites for security and bandwidth control. It occurred to Adrien that they're also a convenient way for home and small business users to share a single Internet address.
A proxy server is not a router, which passes all packets from one network to another. So you can't ping or use SNMP through WinGate, but you should be able to do what most normal people do on the net.
Date: Wed, 27 Dec 95 09:40:18 PST From: Scott McArthur (NC) <scottmca@microsoft.com> Message-ID: <199512271420.GAA28435@imail2.microsoft.com> Gordon Yuen <gdccyuen@asiaonline.net>> wrote: >I use MS NDS service started from when it published (2-3 months) and all >are fine, except one thing: > >I also used modem to establish Internet connection. Every time I tried >to dial up my ISP, a warning box like 'You are now using NDS service >which will be unavailable when you establish the [mode] connection, >proceed?'. This is very annoying because if I have to redial, the >warning box will show up again, also the NDS (actually all the Netware >connections are cut). Until I successfully log in the ISP, the Netware >connections will re-established, I think, by Win 95 re-connect >mechanism. On contrast, if I never get connected to the ISP, the Netware >connection will not re-establish too. In the properties of the connection in dial up networking uncheck "logon to network." This is not needed when connecting to the internet. This is a known problem and we are taking a look at it.
[I believe what's happening here is that Win95 asks for its NBT "extensions," sees them rejected by any standard (non-Microsoft) dialup server, and fails to recover.]
Date: Fri, 3 Nov 1995 05:46:55 GMT From: vjs@rhyolite.com (Vernon Schryver) Message-ID: <DHGDE7.J1q@calcite.rhyolite.com>
I've only seen traces where my code has failed to get CHAP working because a system insisted on the (not really) mysterious algorithm 128 instead of MD5. Supposedly nothing wrong except a configuration problem on the other end.
However, it has regularly been reported, here and elsewhere, that the only way to do PAP with Microsoft systems is to use Configure-Rejects instead of Configure-Naks. I most recently heard this Tuesday from an implementor at another vendor.
[More background on these problems can be found at http://www-leland.stanford.edu/~llurch/win95netbugs/ipcp-huh.txt, http://www-leland.stanford.edu/~llurch/win95netbugs/ppp/, and ftp://ftp.microsoft.com/developr/rfc/.]
Date: Sun, 5 Nov 1995 00:00:00 GMT From: Kevin Wells <kewells@vt.edu>
You need to create a null modem .inf file, since Microsoft did not think of that. Fortunately, Kevin Wells has posted such an .inf file to the net; see http://www.vt.edu:10021/K/kewells/net/
Date: Mon, 13 Nov 1995 18:36:46 GMT From: venem@cruzio.com (Shane Venem)
[Note that this is probably SMC's problem, not Win95's problem, though perhaps Win95 should recognize the SMC 666 as not really 16550-compatible.]
On Fri, 10 Nov 1995 19:29:05 GMT, 722-0447@mcimail.com
(Mike Golobay)
wrote:
darkstar@valleynet.com (DarKStaR) wrote:
Has anyone ever experienced any locking with the TCP/IP stack? have been fighting this thing for quite some time. I'll go and use my Dial-up adapter to call my provider and things look fine at first. Then when I go to use anything (like wsping, telnet, ftp....) it locks up and gives me no information or errors. The modem checks out fine and it seems to be the TCP/IP stack. It will not send or receive any packets what so ever. I can hang up and redial and still the same thing until I have to reboot, then it will work fine for a while. I have reinstalled the stack many times and no luck. I know you're looking for help... but I just wanted to let you know that you're far from alone with this problem. I've had TCP/IP lockups now for weeks and keep getting the same lame newbie advice about modem >setup strings, modem ROM upgrades and other manure.
I have had this problem because I use a controller
card with the SMC 666 chip on board. It is supposed to work as a 16550
UART when addressing the com ports, but it isn't really compatible. This
results in lockups when using the com ports. For me it was mainly evident
during PPP sessions. The only solution I'm aware of for Win95 is to shut
off the FIFO buffers.
Windows95 (Win95-L) & Networking FAQ COPYRIGHT © 1996 by Hans Klarenbeek
Windows NT 4.0 FAQ COPYRIGHT © 1996 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(hansie@wantree.com.au)