I've had a bear of a time lately with dialing in. The problem is that the two programs you have for setting up ppp accounts apparently recognize each other as being there but cannot work with each other. Accounts created or edited in linuxconf show up when I run netcfg. Those created in RP3 do not. Visa-versa accounts created in RP3 don't show up in either Linuxconf or netcfg. When I dial in on a RP3 ppp account, Netscape cannot recognize it and gives me a $SOCKS_NS environment error and cannot recognize any URL or collect my email. It took me a little while but I discovered that when I dial in the accounts listed in the netcfg file, Netscape runs just fine. I'm not sure what the conflict is, but I thought you may want to work at intergrating these tools a little more closely. (The reason I used both is that RP3 is simpler to use, but linuxconf offered more versatility in letting me specify my Init. string which my modem needed). Looking around the internet, I discovered I'm not the only one with the $SOCKS_NS problem. My work around is the only solution I've found. Thanks, Tim Koster
This is odd. The netcfg and linuxconf PPP setup routines should recognize that accounts set up using rp3 exist, but show them as mostly not set up. Can you send in a copy of the /etc/sysconfig/network-scripts/ifcfg-ppp? file that matches one of the non-functional accounts, as well as the contents of the /etc/wvdial.conf file (with all sensitive information replaced with dummy data, of course)? Netscape Navigator will throw up a dialog box suggesting SOCKS_NS if it can't resolve an address, which suggests that your ISP's DNS server addresses are not being placed in /etc/resolv.conf properly. Dialing in through netcfg or linuxconf doesn't modify these files, but using rp3 or wvdial will usually fetch the addresses during PPP link negotiation. If the contents of /etc/resolv.conf change when you dial in with rp3, please send the contents of resolv.conf in as well.
Closed due to inactivity.