Zen Internet Support Forum

I have a problem logging into the backup dial-in service.

Although I can get a ppp connection; as seen from my logs:

Jul 25 14:29:27 tiptoe pppd[9292]: Serial connection established.
Jul 25 14:29:27 tiptoe pppd[9292]: Using interface ppp0
Jul 25 14:29:27 tiptoe pppd[9292]: Connect: ppp0 <--> /dev/ttyS1

the subsequent "LCP ConfReq"'s I send: e.g. -

Jul 25 14:31:15 tiptoe pppd[9338]: sent [LCP ConfReq id=0x1 ]

get no response, and after 10 (or the value set by lcp-max-configure) have been sent the connection fails and times out.

I know my modem etc are working fine, because I can connect to another ISP while using a very similar (ppp) options file and have no problems. Presumably the server is expecting something else before it will deign to respond to the "LCP ConfReq"'s.

What is that something, and how do I generate it?

Is it some ppp option (although I can't see what it might be); or do I have to adjust my chat script to send something blind to the server?

Note that I have tried logging in manually using minicom to drive my modem: I see a normal CONNECT and a speed reported, then nothing. Typing random stuff at it gives no response.

System: Linux Slackware 9.1 (patched), pppd 2.4.1, chat 1.22

Coo - this had me scratching my head - I remember coming across this years ago... LCP stands for Link Control Protocol, and is an extension of PPP. Sadly thats about all I remember, except that in a windows box, there was an option to enable or disable it - I think the best results were disabling it. I don't know how you would change that it Linux - possible edit an entry in a config file, or if you are using a GUI, there may be an option in the PPP dialogue box, but other than that, not sure I can be much help Sorry...

---

The box said "needs Windows 2000 or better" so I installed Fedora Core 6

Eh? Everything I've read says that the LCP stuff is required to negotiate the properties of the connection; you can't remove it!

Mind you, I wouldn't put it past MS to assume/insist everyone uses a MS client, hence LCP can be dispensed with because no negotiation is required.

But surely an ISP wouldn't be so, er, creative, with the PPP protocol? Whatever was left wouldn't be PPP.

Ref: (eg)
http://www.tcpipguide.com/free/t_PPPLinkControlProtocolLCP.htm

I suppose you could try a packet sniffer (eg ethereal) on a windows box (or some other box thats getting a working connection) and find out what the conversation should be looking like....

---

Kindest regards,

James Sweet
http://www.zen.co.uk

"Eh? Everything I've read says that the LCP stuff is required to negotiate the properties of the connection; you can't remove it!"

Got me digging back into the settings for dial up! On W2K (and I think that was the case for previous windows versions) there is certainly a check box for LCP extensions - which are enabled. But I couldn't find any advanced configuration options for it - it is either on or off.

I can't find any reference to it in my RH manual, but it might be worth looking in the pppd man pages (man pppd) or the

ifcg-ppp0 file in /etc/syscongig/network-scripts/ifcfg-ppp0

Notre that these files/locations are for a Red Hat system - the locations names might be different for yours.

Hth - good luck

---

The box said "needs Windows 2000 or better" so I installed Fedora Core 6

> I suppose you could try a packet sniffer (eg ethereal)
> on a windows box (or some other box thats getting a
> working connection) and find out what the conversation
> should be looking like...."

I've got a better idea. Why doesn't Zen technical support tell me what the conversation should be like? After all, they should know.

I tried the phone support, but didn't get a specific enough answer to be of any help; except learn that I need to send something other than LCP ConfReq ( although that wasn't what was said).

The whole point of LCP is that it would give Zen's servers the mechanism to tell my software what it is they want it to do. Even if it's some vendor-specific thing my software might not know about. But they don't.

EDIT: so, can someone who _can_ dial-up sucessfully click whatever boxes (or adjust options) necessary to get a ppp log file of a sucessful connection, and send it to me?

EDIT EDIT: or, better yet, some linux user who /can/ dial in could send me a suitably sanitized version of their ppp/options file. And if I need to use some sort of plugin (like that RADIUS one), the relevent conf.files

Here's the solution, if anyone else has a similar problem.

The Zen dial-in servers, it turns out, do the "normal" thing of starting ppp automatically at their end. The catch is that it seems to be a rather intolerant implimentation. The other auto-started (ISP-end) ppp's which I've encountered will start talking IMMEDIATELY, so a manual dial-in (using e.g. minicom) will show the ISP ppp talking (usually looking like a bunch of junk with lots of "}"'s in it). The Zen ppp remains silent; which doesn't help with debugging. I assume that unless the very first thing it sees is a valid LCP frame, it sulks and refuses to cooperate (or maybe crashes, who knows).

I had a slightly broken connect string, which meant that I sent two junk characters before starting ppp myself after detecting the CONNECT from the modem. Most ppp's would ignore this -- I've been using the connect string for over five years and never had a problem dialling in to a range of ISP's.

As in the title of this topic, the "LCP ConfReq"'s I was sending were being ignored.

This is the connect string that works for me:

connect "/usr/sbin/chat '' AT\\\&F0 OK ATX1 OK ATX2 OK ATDT08456000194 CONNECT '\\\d\\\c' "

Obviously your quoting may need to be different (i.e. not three \'s but one, or whatever), and your modem will probably want a different set of AT commands.

I'd like to thank Moe Trin, over in uk.comp.os.linux, for helping and spotting the glitch. I will refrain from giving my opinion of Zen support in their own forums.

Here is a log from a sucessful connection:
Aug 14 10:59:24 tiptoe pppd[16869]: pppd 2.4.1 started by net, uid 1006 Aug 14 10:59:25 tiptoe chat[16875]: send (AT&F0^M) Aug 14 10:59:25 tiptoe chat[16875]: expect (OK) Aug 14 10:59:25 tiptoe chat[16875]: AT&F0^M^M Aug 14 10:59:25 tiptoe chat[16875]: OK Aug 14 10:59:25 tiptoe chat[16875]: -- got it Aug 14 10:59:25 tiptoe chat[16875]: send (ATX1^M) Aug 14 10:59:25 tiptoe chat[16875]: expect (OK) Aug 14 10:59:25 tiptoe chat[16875]: ^M Aug 14 10:59:25 tiptoe chat[16875]: ATX1^M^M Aug 14 10:59:25 tiptoe chat[16875]: OK Aug 14 10:59:25 tiptoe chat[16875]: -- got it Aug 14 10:59:25 tiptoe chat[16875]: send (ATX2^M) Aug 14 10:59:25 tiptoe chat[16875]: expect (OK) Aug 14 10:59:25 tiptoe chat[16875]: ^M Aug 14 10:59:25 tiptoe chat[16875]: ATX2^M^M Aug 14 10:59:25 tiptoe chat[16875]: OK Aug 14 10:59:25 tiptoe chat[16875]: -- got it Aug 14 10:59:25 tiptoe chat[16875]: send (ATDT08456000194^M) Aug 14 10:59:25 tiptoe chat[16875]: expect (CONNECT) Aug 14 10:59:25 tiptoe chat[16875]: ^M Aug 14 10:59:53 tiptoe chat[16875]: ATDT08456000194^M^M Aug 14 10:59:53 tiptoe chat[16875]: CONNECT Aug 14 10:59:53 tiptoe chat[16875]: -- got it Aug 14 10:59:53 tiptoe chat[16875]: send (\d) Aug 14 10:59:54 tiptoe pppd[16869]: Serial connection established. Aug 14 10:59:54 tiptoe pppd[16869]: Using interface ppp0 Aug 14 10:59:54 tiptoe pppd[16869]: Connect: ppp0 <--> /dev/ttyS1 Aug 14 10:59:54 tiptoe pppd[16869]: using channel 108 Aug 14 10:59:55 tiptoe pppd[16869]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x7ba04711> <pcomp> <accomp>] Aug 14 10:59:55 tiptoe pppd[16869]: rcvd [LCP ConfReq id=0x62 <asyncmap 0xa0000> <auth pap> <magic 0x1027992b> <pcomp> <accomp>] Aug 14 10:59:55 tiptoe pppd[16869]: sent [LCP ConfAck id=0x62 <asyncmap 0xa0000> <auth pap> <magic 0x1027992b> <pcomp> <accomp>] Aug 14 10:59:55 tiptoe pppd[16869]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x7ba04711> <pcomp> <accomp>] Aug 14 10:59:55 tiptoe pppd[16869]: sent [PAP AuthReq id=0x1 user="zenXXXXX@zen" password=<hidden>] Aug 14 10:59:55 tiptoe pppd[16869]: rcvd [PAP AuthAck id=0x1 ""] Aug 14 10:59:55 tiptoe pppd[16869]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>] Aug 14 10:59:55 tiptoe pppd[16869]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] Aug 14 10:59:55 tiptoe pppd[16869]: rcvd [IPCP ConfReq id=0x1 <addr 62.3.X.X>] Aug 14 10:59:55 tiptoe pppd[16869]: sent [IPCP ConfAck id=0x1 <addr 62.3.X.X>] Aug 14 10:59:55 tiptoe pppd[16869]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>] Aug 14 10:59:55 tiptoe pppd[16869]: sent [IPCP ConfReq id=0x2 <addr 0.0.0.0>] Aug 14 10:59:55 tiptoe pppd[16869]: rcvd [LCP ProtRej id=0x1 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f] Aug 14 10:59:56 tiptoe pppd[16869]: rcvd [IPCP ConfNak id=0x2 <addr 82.71.X.X>] Aug 14 10:59:56 tiptoe pppd[16869]: sent [IPCP ConfReq id=0x3 <addr 82.71.X.X>] Aug 14 10:59:56 tiptoe pppd[16869]: rcvd [IPCP ConfAck id=0x3 <addr 82.71.X.X>] Aug 14 10:59:56 tiptoe pppd[16869]: Script /etc/ppp/ip-up started (pid 16917) Aug 14 10:59:56 tiptoe pppd[16869]: local IP address 82.71.X.X Aug 14 10:59:56 tiptoe pppd[16869]: remote IP address 62.3.X.X