SP2 Ate my Dial Up Networking

[HandShaker]

Hello,

I'm new to the forums, finding them while on a mission to solve an obscure problem I'm having with XP SP2 computers and Dial Up Networking.

Our company has a product that runs on stand-alone Win2000Pro computers at client sites. These client computers are contacted via DUN through a modem connected to the PSTN.

The client computers simply use the Windows incoming connection setup. This setup is successfully implemented in dozens of installations. Pretty much all the computers we're using have USR External 56k modems.

My problem is:
Two of the remote computers we use to connect to the sites have recently been upgraded to XP SP2. Since then I can access all my Win2000Pro client computers except one with which the SP2 computers fail to authenticate with "Error 721: Remote computer not responding". This is after a successfull handshake and hangs at the authentication dialogue.

What puzzles me is that other remote computers running Win2000 connect to the rogue client without any problems. The issue is only evident in Win XP SP2.

I'm still unsure where the problem lies. I have checked, double checked and triple checked the settings on the problem client and can't find any inconsistencies. The User has permissions, the modem is configured (I assume) correctly. The fact that other Win2k machines can connect suggests the setup is ok.
The XP SP2 computers have no firewall running and I've been through the setup with the Microsoft SP2 support and they can't find the problem either. I've not finished with the Win2k support guys yet though.

I've sent a different modem out to site to see if that helps but I can't think how the hardware setup on the remote client would effect only XP SP2 and not all connecting computers.

Any Help would be very much appreciated. The problems double fold as one of the XP machines that won't connect is a clients new viewer. I need anything you can suggest no matter how trivial.

Thanks in Advance
Please say if you need any more details.

 

[HandShaker]

Well, I decided to just replace the hardware, Low and behold it now works. Unfortunately I'm no closer working out what caused the issue and why a remote modem stopped only SP2 computers from connecting. A mystery it shall remain.

Can anyone shed any light on what might have caused this so I can avoid hardware that might cause a problem in the future.

thanks

 

[mattjurado]

Must be a difference in driver sets. With XP SP2, driver sets may have been changed, enough for the handshake to not complete. You may have been able to get away with putting in an initialization string, usually dropping down from v90/v92 to v34 will help. However, if you could use the XP machines to connect to a bunch of other similar modems, except this one, then you were correct in swapping out the modem. The modem was just good enough to communicate with the older driver sets. It may also have simply required a firmware upgrade.

Matt J.

Please always take the time to backup any and all data before performing any actions suggested for ANY problem, regardless of how minor a change it might seem. Also test the backup to make sure it is intact.

 

[HandShaker]

Thanks for the reply. )

I don't think the driver set theory fits(although I'm free to be pursuaded otherwise). These modems appeared to handshake successfully.

The receiving modem (the one that was changed) was connected to a Win2k machine, not XPSP2. The modem on the XPSP2 computers were not changed so a driver missmatch to do with XPSP2 doesn't explain the problem....

All modems were both V90 and V92 compatible.

No need for head scrathing over this as it's solved but I would be happier knowing the cause so I can avoid it in the future, it was down-time I could have done without.

 

[mattjurado]

The receiving modem (the one that was changed) was connected to a Win2k machine, not XPSP2. The modem on the XPSP2 computers were not changed so a driver missmatch to do with XPSP2 doesn't explain the problem...."

That was my point, the modem on the xpsp2 may not have been changed, but a difference in the os may mean a difference in drivers. Enough of a difference that this particular modem had an issue. Anyways, it is a possibility. Another possiblity I mentioned was that the receiving modem may simply have needed a firmware upgrade.

Anyways, glad you fixed it.

Matt J.

Please always take the time to backup any and all data before performing any actions suggested for ANY problem, regardless of how minor a change it might seem. Also test the backup to make sure it is intact.

 

[HandShaker]

thanks for your reply Matt.

"the modem on the xpsp2 may not have been changed, but a difference in the os may mean a difference in drivers. Enough of a difference that this particular modem had an issue."

I didn't realise that a driver that allowed access from win2k machines would prevent access from an XPSP2 machine. bizarre stuff.
Is the actual transmission down the wire not soley dependant on the protocol it's transmitted in? I therefore thought that as long as the two ends were both compliant that the issue would be isolated to the transmissions and requests from the computers, not the modem hardware.
I'm genuinely interested as I do lots of work with modems.

Thanks again

 

[mattjurado]

The transmission is protocol dependent, but if the driver set in Windows has been changed/corrupted, the driver may have an issue issuing/receiving a command that it once had no problem with at all.

Realizing that you could connect to the same hardware configuration on other computers, then the problem was with that particular modem. That modem may have responded to the ones on the XPSP2 machines, resulting in a command being given to the drivers sets on the XPSP2 machines, that they just couldn't handle.

Possible resolutions short of replacing, which you already did, would include updating the firmware on that funky modem, or playing with initialization strings, which allow you to manipulate which protocols are/aren't used.



Matt J.

Please always take the time to backup any and all data before performing any actions suggested for ANY problem, regardless of how minor a change it might seem. Also test the backup to make sure it is intact.

 

[HandShaker]

thanks for all your input