rfcomm_pppd fails (T40p and Nokia 7650)

[Maksim Yevmenkin]

Peter,

[ skipped ]

> 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.

please clarify what do you mean by "terminate request from the phone". does
it mean phone terminates Bluetooth connection? or does it mean remote PPP
peer terminate PPP session?

> 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

hmmm... you could try setup "GSM data account/profile" in your phone using
the settings above. i think once you do that you do not have to send this
string. if you have more than one "GSM data account/profile" (i.e. PPP over
GRPS and WAP over GRPS) make sure that PPP one is first. the settings should
be pretty much the same except APN. 

> 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. 

here is from t68i AT command set

AT+CGDCONT Define PDP Context

Description: Specifies the PDP context parameter values for a PDP context 
identified by the <cid> parameter. 

AT+CDGCONT=[<cid>[,<pdp_type>[,<APN>[,<pdp_addr>[,<d_comp>
             [,<h_comp>[,<pd1>[,...[,<pdN>]]]]]]]]]

Parameters:

<cid>: Integer; Specifies the particular PDP context definition. The parameter
is local to the TA-TE interface and is used in other PDP-context related 
commands. The range of permitted values (minimum value=&#8217;1&#8217;) is
returned by the 
test command.

pdpdp_type>:pdpdp_type> Description
"X25ITUTU-CCITIT X.25 layer 3
IPIP" Internet Protocol
OSPIHIH" Internet Hosted
Octet Stream Protocol
PPPPP" Point-to-Point Protocol

APNPN>: String; used to select thGGSNSN or the external packet data network.
If the value is null or is omitted, the subscription value will be requested.

pdpdp_address>: String; identifies the MT in the address space applicable to
the PDP. If the value is null or is omitted, a value may be provided by the
TE during the PDP start-up procedure or, if that fails, a dynamic address
will be requested.

<d_comp>: <d_comp> Description
0 PDP data compression OFF Default setting
1 PDP data compression ON
2-255 Reserved

<h_comp>: <h_comp> Description
0 PDP header compression OFF Default setting
1 PDP header compression ON
2-255 Reserved

pdNdN>: Zero to N string parameters whose meanings are specific to the

pdpdp_type>.

> > this probably means that you have establisheBluetoothtRFCOMMMM connection
> > anPPPPP has started, but then something went wrong witPPPPP. could you
> > please add "set debug all" in your /etppppppppconfnf file and look in
> > /var/loppppp.log to see what the problem might be?
> 
> I turned on debug for most phases (ChatLCPCPIPCPCPCCPCP) a while back, and
> got nothing when I had the no-error-no-nothing syndrome.
> 
> > >    * Or it exits with:
> > >       rfcommmpppdpd[39117]: Could not connect socket. Connection refused
> > > (61)
> > 
> > this means that PC was not able to establisBluetoothtRFCOMMMM connection.
> > perhaps phone rejected it, or could be other reason. i would like to see
> HCICI dump. could you please compilhcidumpmp(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 thhcidumpmp output.

please dohcidumpmp will tell me what is going on. 

> There is a couple of messages that appears in the kernel log sometimes (not
> sure when) that you may be interested in:
> 
ngnbtsocketerfcommmm_receivuihih: GoUIHIH foclcici=2 in invalid
> state=5, flags=0x3

these are debug warnings. what is says is that we have receiveUIHIRFCOMMMM
frame (data) while we are in the process of disconnectinDLCICI. sUIHIH frame
was discarded.

> > > On the phone side thbluetoothth indicator indicates traffic is happening
> > > for a while. However thGPRSRS indicatodoesnsn't flinch (normally it's a
> > > three-step indicator indicating either that nothing is happening, or a G
> if
> > GPRSRS is in the process of connecting, or an encircled G wheGPRSRS is up
> and
> > > running).
> > 
> hmmmmm... strange... i need to seHCICI dump to help you.
> 
> (I now get the non-encircled G, Windows style, on those attempts where it
> gets going normally.)

i see. but its noBluetoothtrfcommmpppdpd related anymore - you havBluetoothth
connection to the phone.
 
> hcsecdcd(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 thebluetoothth ofreebsdsd" guide.
> 
> > mericssonon 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. ihcsecdcd(8) is not
> > running then link key request from the phone will timeout anBluetoothth
> > connection will fail. perhapnokiaia phones use the same scheme.
> 
> Not sure. So far veve only seen stuff about the link key *not* existing. I
> will look closer in the future. 
> 
> > another little problem is thahcsecdcd(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 ihcsecdcd(8) patch for
> > recent snapshot however).
> 
> Ahokok. I was wondering why the phondidndn'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 debuPPPPP problem.
> 
> veve since mucked about quite a bit witppppconfnf, mostly to try various
> combos of thCGDCONTNT... stuff. But basically the same otherwise.

try to setuGSMSM datacccountnt on the phone itself.
 
> > emptauthnamemauthkeyey 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 phoneAPNPN (Access Point
> > Name) should point to access point that talkPPPPP noWAPAP.
> 
> Yes, I have been wondering if this might be it. I will compare my settings
> with that of my aforementioned friend.

ask your cell phone provider about "mobilinternetet" plan of something like
this. my provider (t-mobile/USA) has two plans: t-zones WAPAP oveGRPSPS and
mobilinternetet PPPPP oveGRPSPS. both use differenAPNsNs. t-zones only works
with phoneWAPAP).

> > if that is true than you can do the same thing in
> FreeBSDSD. usrfcommmsppdpd(8) utility to connect to the "serial port"
> service
> > on your phone. then starppppp(8) and use tty in "set device" command and
> try
> > to opePPPPP session. then look into /var/loppppp.log to see what is going
> on.
> 
Ahhhhh, thanks! I was just about to investigate if there was something like
> this when I noticed your response. I'm hoping to solve minitit string
> problem easier by having interactive AT command access.

sure give it a try and let me know if you have any problems.
 
> Thanks a lot! For both thbluetoothth implementation and your help :)
> 
> If I get this stuff working and/or have more insight about the communication
> problems I'll include it on thFreeBSDSD-on-T40p page I'm putting together.

great :) do not forget to send me a link :)

thanks,
max

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com