rfcomm_pppd fails (T40p and Nokia 7650)

[Peter Schuller]

Hello,

> > I've been trying to get connected using GPRS and Bluetooth on my IBM
> > ThinkPad T40p. It has a bluetooth card that sits on the USB bus, so
> > I'm using the ubt driver.
> 
> thank you for trying this :) 

My pleasure. Especially if I get it working :)

> good. i assume that "00:02:ee:73:89:0b" is your phone BD_ADDR, right?

Correct.

Now before I continue, I'll just tell you what's happened since I posted.
During the past few hours I had another crack at getting this to work. I
wasn't getting anywhere this time either, until I noticed that the BD_ADDR I
had put in /etc/bluetooth/hcsecd.conf did not match the one I was using on
the rfcomm_pppd command line.

This in combination with errors in the output of hcsecd lead me to believe
that I had put the wrong BD_ADDR in the configuration file. So I changed it.
(00:01 instead of 00:02). This didn't work either; and after further
investigation I realized I had the right address in the .conf all along - I
had just been using the wrong address on the command line during part of
this "session".

So I changed the .conf back to 00:02 and modified the command line
accordingly.

And now it works (a bit further, not quite, see below).

I don't get it. I am quite sure I did not make the same misstake before,
because at the time I was in X using cut'n'paste - never manually entering
the address. This time I was in the console without cut'n'paste and made a
typo.

The only possibility I can figure is that it had something to do with me
re-pairing the phone. I cannot remember anything else "special" I did. I
only hope it keeps working. Last time something suddently worked, it stopped
working after the laptop had been turned off for the night :)

I'll comment some of the parts below anyway since I still don't feel
confident I have it working permanently to begin with.

But first, let me just state that I am now at a point where I have the exact
same problem as in Windows. pppd will successfully dial and connect, and the
ppp stuff gets going. It negotiated ipv6 and fails among other things. It
looks mostly pretty fine, no errors/warning that should be fatal as far as
I can see (just stuff like ipv6 neg. failing). Then suddently it
receives a terminate request from the phone and the link goes down.

I believe this should be able to be rectified by using the initstring:

   AT+CGDCONT=1,IP,online.telia.se

to identify the access point for the phone. This is what my friend (same guy
with bluez/linux/same phone) is using with success. However when I modify
the chat script to send that string, I get an ERROR in return. I suspect I
would get it to work if I could get the phone to accept the above command,
or something equivalent. I will continue investigating. 

Of course, this is beyond the scope of freebsd/rfcomm/etc.

> this probably means that you have established Bluetooth RFCOMM connection
> and PPP has started, but then something went wrong with PPP. could you
> please add "set debug all" in your /etc/ppp/ppp.conf file and look in
> /var/log/ppp.log to see what the problem might be?

I turned on debug for most phases (Chat, LCP, IPCP, CCP) a while back, and
got nothing when I had the no-error-no-nothing syndrome.

> >    * Or it exits with:
> >         rfcomm_pppd[39117]: Could not connect socket. Connection refused
> > (61)
> 
> this means that PC was not able to establish Bluetooth RFCOMM connection.
> perhaps phone rejected it, or could be other reason. i would like to see
> HCI dump. could you please compile hcidump(1) from the snapshot's ports/
> directory and then run it 

I still get this sometimes, seemingly randomly. When I do, I can keep trying
and sooner or later it will work. If you are interested for purposes other
than helping me, I will gladly get you the hcidump output.

There is a couple of messages that appears in the kernel log sometimes (not
sure when) that you may be interested in:

ng_btsocket_rfcomm_receive_uih: Got UIH for clci=2 in invalid
state=5, flags=0x3

(line break added by me)

I have only gotten that perhaps 10 times, so it's almost certainly not
something that happens consistently when rfcomm_pppd fails as I have been
trying a lot more times than that.

> > On the phone side the bluetooth indicator indicates traffic is happening
> > for a while. However the GPRS indicator doesn't flinch (normally it's a
> > three-step indicator indicating either that nothing is happening, or a G if
> > GPRS is in the process of connecting, or an encircled G when GPRS is up and
> > running).
> 
> hmmm... strange... i need to see HCI dump to help you.

(I now get the non-encircled G, Windows style, on those attempts where it
gets going normally.)

> hcsecd(8) must be running all the time. 

I, I was unsure about that. Seemed like the right thing to do, but for some
reason I got into my head that I was supposed to turn it off. I was probably
just too tired when reading the "bluetooth on freebsd" guide.

> my ericsson t68i stores link
> key once i pair PC and the phone. next time when PC tries to connect to
> the phone, the phone will ask for the link key. if hcsecd(8) is not
> running then link key request from the phone will timeout and Bluetooth
> connection will fail. perhaps nokia phones use the same scheme.

Not sure. So far I've only seen stuff about the link key *not* existing. I
will look closer in the future. 

> another little problem is that hcsecd(8) does not store link keys, so
> you will need to enter PIN every time to get it working. this problem
> was fixed, but i did not release this yet (there is hcsecd(8) patch for
> recent snapshot however).

Ah, ok. I was wondering why the phone didn't seem to "remember" the laptop
pairing properly.

> it is probably "auto disconnect" feature. L2CAP node has auto disconnect
> timeout (default 5 seconds). if baseband connection was inactive for the
> duration of the auto disconnect timeout we will close it. you can use 
> l2control(8) utility to change (or disable) auto disconnect timeout.

5 secs sound right; probably it. I'll check l2control.

> > (The connection comes back automatically when doing an l2ping or similar
> > though.)
> 
> right, and it will go down once you stop l2ping and wait for auto disconnect
> timeout.

Correct.

> this looks normal to me. i would add "set debug all" to debug PPP problem.

I've since mucked about quite a bit with ppp.conf, mostly to try various
combos of the CGDCONT... stuff. But basically the same otherwise.

> empty authname/authkey should work just fine. it only matters if remote
> side requests them (and it seems your provider does not). also you should
> make sure you have the right service plan on you phone. APN (Access Point
> Name) should point to access point that talks PPP not WAP.

Yes, I have been wondering if this might be it. I will compare my settings
with that of my aforementioned friend.

> the phone, then start windows termial program and after you type
> 
> ATZ
> ATDT*99#
> 
> you can see PPP frames?

Yep.

> if that is true than you can do the same thing in
> FreeBSD. use rfcomm_sppd(8) utility to connect to the "serial port" service
> on your phone. then start ppp(8) and use tty in "set device" command and try
> to open PPP session. then look into /var/log/ppp.log to see what is going on.

Ahhh, thanks! I was just about to investigate if there was something like
this when I noticed your response. I'm hoping to solve my init string
problem easier by having interactive AT command access.

Thanks a lot! For both the bluetooth implementation and your help :)

If I get this stuff working and/or have more insight about the communication
problems I'll include it on the FreeBSD-on-T40p page I'm putting together.

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller at infidyne.com>'
Key retrival: Send an E-Mail to getpgpkey at scode.org
E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org