1. Home
  2. General Telecommunications Forum
  3. Dialup to 844 # fails at LCP. Is it telecom or server? [telecom]

Dialup to 844 # fails at LCP. Is it telecom or server? [telecom]

I have two dialup ISPs, one of which is working.

The other has, until recently, had a major telco handling all the phone number, dialup and telecom details and supplying the network access servers. These NASs consulted the ISP's RADIUS server for authentication. The ISP has never had to deal directly with dialup, LCP, PAP or the many potential telecom gotchas.

Now the telco has dropped out of the deal. The ISP now offers an 844 toll-free number in Ontario for their dialup customers. Only it doesn't work for me (Linux) or for my wife (Win-XP).

The 844 number answers, the modem handshake completes and I get a connection. Then the server fails to respond in any way to LCP ConfReq packets. After 10 tries, my pppd client drops the connection. Fail.

Support at the ISP say, "Gee, it works for me. Must be your phone line."

Ha. My phone line works fine for the other dialup ISP, both Win and Linux. I get the banner text from the new server without funny chars. My USR modem diagnostics report no blers, no retrains, good SNR. Carrying a laptop to another phone line in 902-688-nnnn (instead of my 902-543-nnnn) exchange produces the same good connection with failure of LCP after the connection.

Is there any way this could be attributed to the various ways/options by which toll-free numbers are routed? Or other telco factors that I don't understand? (And that perhaps the ISP guys don't either?)

I'd welcome any suggestions that I can pass on to the ISP, either about getting the 844 number set up right for this purpose or about configuring the the server to which it connects.

Off-list email welcome if you have helpful wisdom of little interest to the general reader.

- Mike

Reply to
Mike Spencer
Loading thread data ...

Can you "sniff" the serial port connection during the login, and attempt at a PPP handshake?

Some dialup servers send the greeting text, require a username/password login, and then start the PPP negotiation and authentication after you've successfully "logged in". Others send the greeting text, wait for a username/password login, but will recognize an LCP "handshake" attempt and will skip around the normal login.

You might have a problem in which (1) the new connection requires that your computer send your username/password combination (or some other sentinal) in order to get as far as PPP negotiation, or (2) your computer is already trying to "log in" prior to starting PPP/LCP, but your username/password combination is being rejected.

If you aren't seeing bit-level errors, then it's probably not your phone line.

One thing you could try - turn off V.42/V.42bis error correction and compression, and try the call again. Dial up the 844 number manually (e.g. using miniterm or kermet) and just observe what happens after you connect and see the banner text.

If you see a "}" every few seconds, it's an indication that there is a timing slip somewhere in the connection... two phone switches are talking to one another, but don't have their bit-clocks properly synchronized to a standard source. That can raise hell with a dialup connection... V.42 will try to recover from the injection of bad data, but reliability will suffer.

Reply to
Dave Platt

Most likely there's a subtle change required in the Windows DUN connectoid settings, or their Linux counterparts. Only the ISP can tell you for sure, if you can provide them *all* the settings you'd been using, and ask them how, if at all, they'd need to be modified. HTH. Cheers, -- tlvp

Reply to
tlvp

Just to follow up, thanks for the replies.

Now that the Telus NASs are turned off, they've been replaced by a toll-free number at Fibernetics.ca. The "escalation specialists" at Fibernetics say they've installed the dialup software "out of the box" but can't say just what configuration that represents. They say that the prompted ASCII authentication mode should work but it doesn't.

They both opine that I know more about this than they do. (I'm a retired artist blacksmith, not an IT or telecom pro.) Neither of them can answer my questions about details except with assertions that are apparently contrary to fact.

A "subtle change" in their server config seems to be outside their scope. Still working on it, hoping to learn enough that I can tell them how to fix their server. Best guess still points to their server config but the possibilty remains that it has to do with running analog dialup through some telco digital connection beyond my horizon.

Still vexed. Thanks for your attention.

Reply to
Mike Spencer

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.