Serial Line is looped back!!

"This error message was bugging me for some time so decided to get to the root of it. This post is a result of that analysis which spanned over three days.

For those who have never encountered it, pppd throws up this error sometimes when you connect to a ppp server. In my case the problem was easily reproducible.

When you issue a command like 'pppd call gprs' then at first the daemon connects to the device (e.g. /dev/rfcomm0) at a prescribed speed (e.g. 57600 bps). Then it calls the chat command and passes the chat script to it. I noticed that the error is always thrown up after the chat command gets completed.

Since all the chat script was being send correctly to the modem (I saw the logs to verify this tail -f /var/log/messages) so I figured out there was nothing wrong with the communication link. Another point was rebooting the client machine always used to solve the problem. So the problem can't fully lie with the ppp server.

In a normal scenario once the chat script gets completed, pppd sends LCP (link control protocol) packets to the ppp server. If it receives a valid response (I guess that will be some kind of an acknowledgement packet) it then goes on to the next stage (IP control protocol packets) and only when this negotiation completes is the actual IP layer started so that you can use the PPP link for communication.

Now in our scenario, pppd sends an LCP packet to the server. Then it finds that the LCP packets are echoed back with the last bit stripped off (As printable ASCII characters are only 7 bit long) and throws up an error.

In a situation like this I normally try upgrading the package to the latest versions available but somehow I felt skeptical that this won't work in this scenario because I noticed that the same problem was there in Mandrake Linux 10.0 and Fedora Core 3. This also gave me a clue as to something was wrong with my configuration file, maybe a delay was required somewhere after the chat program.

Man pages for pppd contained a command connect-delay used to provide a delay after connection. So I decided to put connect-delay 5000 after the chat program is being called. And bingo!! It worked!

A delay of 5000 milli seconds allowed the ppp server (Slow one, in my case) to respond to the LCP packets sent earlier. Since pppd found that at the end of 5000 ms a vail response was waiting for it so it moved on to the next stage."