1 Nonstandard
PPP implementation causes problems with BSDI and other servers.
2 Degraded
SLIP/PPP performance versus Trumpet.
3 Killed applications/disconnects
cause total system freezes.
5 Win95 creates
fictional COM ports on some plug-and-pray machines.
6 DSCRIPT
might exit before getting all dynamically assigned information.
7 Modem on
COM4 incompatible with S3 video cards.
8 PPP compression
won't work on at least some Xyplex terminal server configs.
9 What are
some tips for better dialin performance?
10 IPX (NetWare)
compression bug.
11 Can't
log on to Sun PPP server, or cause Sun PPP server to crash.
12 What's
the difference between the Plus Pack and normal dialup scripters?
13 Where
is the SLIP and scripting support?
14 Why do
I get "host unreachable" on most remote hosts, though I can get
to my ISP's servers?
15 If my
connection drops, why don't my TCP sessions reconnect?
16 How do
I change my modem init string?
17 Will TwinSock
work in Win95? This
product is no longer being updated.
19 How do
you start dialup networking from the command line?
20 Why does
Win95 fail to negotiate with a Xylogics TIP if NetBEUI is enabled?
21 How can
multiple machines share one dialup TCP/IP connection?
22 How do
I avoid losing all my LAN (i.e., NetWare) connections when I dial up the
Internet?
23 Bug in
CHAP (password) negotiation.
24 How can
I use SLIP/PPP through a direct connection (i.e., no modem)?
25 Modem
locks up with an SMC 666 UART.
  
  |
Date: Wed, 27 Dec 95 16:03:00 -0800
From: Rich Graves <[email protected]>
Thanks to Richard Ryan <[email protected]> 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: <[email protected]>
From: Paul Borman <[email protected]>
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
[email protected]
[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 <[email protected]>
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.
[email protected] (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: <[email protected]>
Date: Sun, 17 Sep 95 08:51:33 -0400
From: richard <[email protected]>
To: [email protected]
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/comfaq.html. Please see also D.9.]
| |
Date: Tue, 12 Sep 1995 01:55:42 GMT
From: [email protected] (Jim Ewald)
Newsgroups: comp.os.ms-windows.win95.misc,comp.os.ms-windows.win95.setup
Message-Id: <[email protected]>
[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 ---------- [email protected] 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 ---------- [email protected] 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 <[email protected]>.
| |
Date: Wed, 27 Dec 95 16:08:00 -0800
From: Neil Moodie <[email protected]>
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: [email protected] (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: [email protected]
Newsgroups: comp.os.ms-windows.win95.misc
References: <[email protected]> <[email protected]> <[email protected]>
In article <[email protected]> [email protected]
(Romklau Nagamati) writes:
>John McGhie ([email protected]) wrote:
>: [email protected] (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: [email protected] (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 <[email protected]>
[email protected] (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 [email protected].
| |
Date: Wed, 27 Dec 1995 17:33:00 -0800
From: [email protected] (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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 [email protected] (Jon-Paul Herron).
[Please see D.6. for a possible hint.]
| |
Date: Sat, 23 Sep 95 06:15:40 -1000
From: Richard Puga <[email protected]>
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: [email protected] (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 1998 12:56:48 +1000
From: Troy Rollo <[email protected]>
[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.
This product is no longer being updated or developed it is however still available for download.
The last version was version 2.0
| |
Date: Tue, 3 Oct 1995 03:49:57 GMT
From: Steve Whittaker <[email protected]>
[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: [email protected] (Doug Olender)
Message-ID: <[email protected]>
You can start up DialUp Networking as follows:
rundll32.exe rnaui.dll,RnaDial connection_name
| |
Date: 13 Oct 1995 18:22:45 GMT
From: [email protected] (Joe Morris)
Message-ID: <[email protected]>
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 <[email protected]>
Message-ID: <[email protected]>
[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) <[email protected]>
Message-ID: <[email protected]>
Gordon Yuen <[email protected]>> 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: [email protected] (Vernon Schryver)
Message-ID: <[email protected]>
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 <[email protected]>
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: [email protected] (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, [email protected]
(Mike Golobay)
wrote:
[email protected] (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.