asked on

Dialup networking configuration

I configured a new dialup networking item using a phone number to my office server. When I run it, it connects fine, but then when I try to use telnet to my server from the dos prompt, I hang. I can do the same thing through AOL with no problem.
Other people in my office have no problems using dial-up networking and telnet to the office server on their home computers.
I suspect there is something wrong with my TCP/IP driver configuration.
When I go to control panel/network, I see the following:
AOL Adapter
Dial-up Adaper
Dial-up Adapter #2(VPN support)
TCP/IP => AOL Adapter
TCP/IP => Dial-up Adapter
TCP/IP => Dial-up Adapter
TCP/IP => Dial-up Adapter#2 (VPN support)
Is this normal?
What can I do to fix my problem?

dew_associates

MG, I suspect that for some reason your system is not using the correct dialup for your work network. The AOL and regular dialup appear correct (although I do not know about the settings), but the VPN adapter (virtual private networking) may be the cause. You may want to remove the dialup adapters (except AOL) and then reload one fresh and give that a try.
Dennis

mgokman

ASKER

How do I reload the fresh adapter?

dew_associates

Okay, the easiest way would be to go into networking and remove those two dialup adapters and then go into My Computer and remove any dialups you have there. Don't remove the AOL.

Reboot the system and then recreate a dialup connection to the network and make sure you check the network settings such as TCP/IP addresses and subnet etc to make sure they conform to your business network.

mgokman

ASKER

I deleted Dial-up adapter and then added it again. This got rid of my duplicate tcp/ip -> dial-up adapter entry.
Then rebooted and recreated the dialup networking item. This fixed it. I think the problem was duplicate tcp/ip->dialup adapter entry.
To award you the points I need you to put an answer, so I accept it.
I will always hate MS, because most of the problems are "resolved" by deleting and reinstalling some components, without knowing why.

ASKER CERTIFIED SOLUTION

dew_associates

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

mgokman

ASKER

>>Sometimes this happens and we never know why! <<
Not in my field of database administration<G>.
Thanks for your help.

dew_associates

Well then, since you are involved with database management you are also familiar with small files becoming corrupted for no particular reason. You may hate MS, but right now it is the *only* software developer that has even thought about a self-healing OS, and the only one to actually implement it. Win98 is partially capable, but Win2000 is nearly fully capable. Win98 will have a major update sometime in Q1 or Q2 of 2000 called Millenium that will boost this in Win98.

mgokman

ASKER

In my 15 years of DBA (10 of which is Oracle) I never had files corrupted for no particular reason. The reason was always either a RDBMS bug or an improper operation of the database. Bugs usually were reported by the time people experienced these problems. Nevertheless, while being a big pain in the neck, these corruptions are easily resolved by restoring files from backups. On the other hand, I never experienced software or configuration components corruption due to configuration changes or because of the installation of some new components.
I don't think I will be be so wrong in saying that this type of problems never existed in the mainframe or Unix environment. I will give all credits to MS for inventing this new concept of problems due to duplicate/incompatible DLLs, intermittent corruption of drivers, and the best of all, hung servers and frequent reboots as the only remedy.
As far as the self-healing software, this will be very nice, but how about the software that rarely gets sick? After all, prevention is becomming more and more popular even among the main stream doctors.

dew_associates

MG, I don't disagree with you, but unfortunately we're not dealing with a main frame or Unix envorinment, we're dealing with a user environment that is easily invaded by third party software that, at times, involves installers that (A) do not compare file types and versions, and (B) do not hesitate to install older system files, including DLL's after which the user then complains of a failure or a "bug".