Printable View
Hi,
I have a strange problem with Linux, pppd, bluetooth, and a Nokia mobile
phone (6310i/6230):
To get a connection I always have to start pppd twice. Exactly every
second time the connection fails. Log files say that pppd detects a
loop and terminates.
Any idea?
regards
Hadmut
On 2005-06-18, Hadmut Danisch <x5@danisch.de> wrote:[color=blue]
> I have a strange problem with Linux, pppd, bluetooth, and a Nokia mobile
> phone (6310i/6230):
>
> To get a connection I always have to start pppd twice. Exactly every
> second time the connection fails. Log files say that pppd detects a
> loop and terminates.[/color]
pppd debug output on success and failure would help here. man pppd
search for 'loop' shows up nomagic option which might be worth a try.
On the other hand, a 7650 I used failed every second time too when the
dial AT command resulted in failure. That was nothing PPP specific, just
a buggy phone.
-Mikko
Mikko Rapeli <foo@bar.invalid> wrote:[color=blue]
> On 2005-06-18, Hadmut Danisch <x5@danisch.de> wrote:[color=green]
>> I have a strange problem with Linux, pppd, bluetooth, and a Nokia mobile
>> phone (6310i/6230):
>>
>> To get a connection I always have to start pppd twice. Exactly every
>> second time the connection fails. Log files say that pppd detects a
>> loop and terminates.[/color][/color]
[color=blue]
> pppd debug output on success and failure would help here. man pppd
> search for 'loop' shows up nomagic option which might be worth a try.[/color]
[color=blue]
> On the other hand, a 7650 I used failed every second time too when the
> dial AT command resulted in failure. That was nothing PPP specific, just
> a buggy phone.[/color]
He might try adding "ATZ OK" at the beginning of the chat script.
Among other things it's supposed to clear the serial port buffers.
I seem to recall a post long ago that had a problem with left over
bytes there that caused an "every other fails" problem.
No guarantee that ATZ will work or even be accepted - I currently know
next to nothing about bluetooth.
--
Clifford Kite Email: "echo [email]xvgr_yvahk-ccc@ri1.arg[/email]|rot13"
PPP-Q&A links, downloads: [url]http://ckite.no-ip.net/[/url]
/* In my book, the first poster to resort to personal abuse in a Usenet
debate loses by default. - Rod Smith */
On 2005-06-19, Clifford Kite <kite@see.signature.id> wrote:[color=blue]
> He might try adding "ATZ OK" at the beginning of the chat script.
> Among other things it's supposed to clear the serial port buffers.
> I seem to recall a post long ago that had a problem with left over
> bytes there that caused an "every other fails" problem.[/color]
I'd like know if this was the issue I was seeing too, but I don't have any
Nokia's around. The problem could be that the phone has some crap in the
buffers, I suppose.
-Mikko
Mikko Rapeli <foo@bar.invalid> wrote:[color=blue]
> On 2005-06-19, Clifford Kite <kite@see.signature.id> wrote:[color=green]
>> He might try adding "ATZ OK" at the beginning of the chat script.
>> Among other things it's supposed to clear the serial port buffers.
>> I seem to recall a post long ago that had a problem with left over
>> bytes there that caused an "every other fails" problem.[/color][/color]
[color=blue]
> I'd like know if this was the issue I was seeing too, but I don't have any
> Nokia's around. The problem could be that the phone has some crap in the
> buffers, I suppose.[/color]
After posting, I stumbled across a post I'd saved back in May 1998 with
a solution to an "every-other-time-fails" problem caused by a buffer with
"NO CARRIER" left in it. The post had the source for a simple program
to flush buffers and showed how to compile and use it. FWIW, the basics
of the solution are reproduced below.
===
Before starting pppd do:
/usr/local/bin/tcflush < $MODEMPORT
where $MODEMPORT represents the device file (usually /dev/tty<something>)
used by pppd and chat for transferring data to and from the modem.
( compile as cc -O2 tcflush.c -o /usr/local/bin/tcflush )
------ Begin source to tcflush.c
#include <termios.h>
#include <unistd.h>
main()
{
if(tcflush(0, TCIOFLUSH)) {
perror("tcflush");
}
exit(0);
}
------- End source
---
Clifford Kite Email: "echo [email]xvgr_yvahk-ccc@ri1.arg[/email]|rot13"
Similar tcflush() call is in sys-linux.c/tty_disestablish_ppp of
pppd-2.4.3, but is it called from anywhere? Didn't seem like it after a
very quick grep/less.
-Mikko
Mikko Rapeli <foo@bar.invalid> wrote:[color=blue]
> Similar tcflush() call is in sys-linux.c/tty_disestablish_ppp of
> pppd-2.4.3, but is it called from anywhere? Didn't seem like it after a
> very quick grep/less.[/color]
(In)famous C indirection(?):
pppd/sys-linux.c: void tty_disestablish_ppp(int tty_fd)
pppd/pppd.h: struct channel {
....
/* take the channel out of PPP `mode', restore loopback if demand */
void (*disestablish_ppp) __P((int));
pppd/pppd.h: extern struct channel *the_channel;
pppd/tty.c: struct channel tty_channel = {
....
&tty_disestablish_ppp,
pppd/tty.c: the_channel = &tty_channel;
pppd/auth.c: the_channel->disestablish_ppp(devfd);
It does look similar, but not being a C programmer it's not for me to
say whether it's equivalent - at least not without more effort than I'm
willing to put into it.
--
Clifford Kite Email: "echo [email]xvgr_yvahk-ccc@ri1.arg[/email]|rot13"
PPP-Q&A links, downloads: [url]http://ckite.no-ip.net/[/url]
/* In my book, the first poster to resort to personal abuse in a Usenet
debate loses by default. - Rod Smith */
Hadmut Danisch wrote:
[color=blue]
> I have a strange problem with Linux, pppd, bluetooth, and a Nokia mobile
> phone (6310i/6230):
>
> To get a connection I always have to start pppd twice. Exactly every
> second time the connection fails. Log files say that pppd detects a
> loop and terminates.[/color]
I finally found the problem. It was my own blindness, very stupid
mistake. Just because others were reporting the same problem:
I simply forgot to wait for the "CONNECT" reply at the end of
my chat script.
So what happened?
With the first pppd the connection was initiated. But since the chat
script didn't wait for CONNECT, the pppd was starting too early, while
the modem (=mobile phone) was still in command line mode and thus in
echo mode. That's why pppd was always seeing it's own ppp frames and
detecting a loop back. pppd then terminated, while the phone was getting
into the GPRS connection.
With the second pppd the connection seemed to be already established,
then the AT command was simply ignored and the connection already working.
Just insert an expect CONNECT at the end of the chat script, and the
problem was gone. As I said, stupid mistake.
Hadmut