[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] Re: ppp -> HANGS!!!!



First, in order for the ppp to work, you need to connect the rfcomm first.
However, for the 20001115 version of the stack, the "con" command is
disabled. So, what you can do is to use the userstack ie."btduser" with the
parameters same as "btd". Then additional menu will appear and you can use
"rf_conn" to connect up both server channel 0 and 1. Channel 0 is for
signalling and channel 1 is for data. Then you can start ppp on both machine
and it should connect. I previously has posted a summary of what I have
managed to test the stack with Null Modem Emulation. Attached for your
reference, hope it helps.

Benham




-----Original Message-----
From: owner-bluetooth-dev@xxxxxxx.com
[mailto:owner-bluetooth-dev@xxxxxxx.com]On Behalf Of Sami Kibria
Sent: Friday, February 23, 2001 1:25 AM
To: Daniel Ezekiel
Cc: bluetooth development
Subject: Re: [bluetooth-dev] Re: ppp -> HANGS!!!!


okay, well i am trying some new stuff right now...i got a previous email
from Lim Yong Beng and in the email he said add the local ip add, and
remote ip add...

well i did, i used the parameter -d <local ip add> and -D <remote ip add>,
and still no luck...maybe i am using it wrong???

i was wondering if you had any suggestions daniel, or even lim, about
what to do??? i am a little confused myself, there doesn't seem to be much
documentation on this...

by the way when i do a send i still get the same error as well, well not
really an error by it just hangs there...hmmmmmm.....

????

talk to you later


 -------------------------------------------------------
 Sami Kibria
 Researcher
 TRLabs - Winnipeg, MB.  CANADA
 email: skibria@xxxxxxx.ca
 -------------------------------------------------------


On Thu, 22 Feb 2001, Daniel Ezekiel wrote:

> YuP
>  I have the same problem too....as well as any other command
>  say 'send 100 100' says
> Now sending 1000 100-bytes packet (100 kB)
>
> after that does nothing (does not return to the menu prompt)
>
> same for ecs_testcontrol 11:22:33:44:55:66
> The server reports
>  BT SYS: ERROR :Discarding 13 bytes and waitin forever.....
>
>  after that the client does not return to menu prompt
>
> I am running 2 linux boxes over  a serial line connection in emulation
mode
> compiled with  HCI_EMULATION and define HW_DEFAULT HW_NOINIT
> stack version bluetooth_20001115
>
> Any quick help would be appreciated
>
>  Regards,
>  Danny
>
>    _____________________________________________
>
>     Daniel D. Ezekiel
>     E-Mail  : danny@xxxxxxx.com
>     Fone    : 91-80-5281461  Extn: 3322
>
>     PGP Key : hkp://keys.pgp.com/danny@xxxxxxx.com
>    ______________________________________________
>




-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com


I am using null modem for evaluation. I managed to get both the 1115 and
1031 stacks working in user mode with PPP running. Below are for your
reference. Please correct me if I am wrong. I hope this will help.


Both compiled with "HCI_EMULATION" defined in btconfig.h.
Both with SDP server started "./sdp_user /etc/sdp.xml &"

For 1031 stack,

server command used "./btduser -u /dev/ttyS0 -s 115200 -r server -i
none -m -d 192.168.1.1 -D 192.168.1.2 -e 0"
client command used "./btduser -u /dev/ttyS0 -s 115200 -r client -i
none -m -d 192.168.1.1 -D 192.168.1.2 -e 0"

then after stack initiation and reached the menu.
server command used "con 11:22:33:44:55:66 0 0 0"
the rfcomm layer should be connected and you should be able to test rfcomm
layer with "send <data length> <number of times>"

To start PPP,
server command used "ppp"
client command used "ppp"
both PC should be connected with PPP.
"ifconfig" should display a PPP connection.



For 1115 stack,

server command used "./btduser -u /dev/ttyS0 -s 115200 -r server -i
none -m -d 192.168.1.1 -D 192.168.1.2 -e 0"
client command used "./btduser -u /dev/ttyS0 -s 115200 -r client -i
none -m -d 192.168.1.1 -D 192.168.1.2 -e 0"

then after stack initiation and reached the menu.
the "con "<xx:xx:xx:xx:xx:xx> <x> <x> <x>" is disabled.
so have to manually use "rf_conn" to connect the rfcomm layer.
server command used "rf_conn 0"
server command used "rf_conn 1"
server command used "rf_conn 2"
Three channels required because channel 0 and 1 are for control purposes and
channel 2 is for data. This part I am not very sure, still need to be
verify.

To start PPP,
server command used "ppp"
client command used "ppp"
both PC should be connected with PPP.
"ifconfig" should display a PPP connection.


Can someone please enligthen me how to connect in kernel mode with null
modem? I can't seem it get it working. Thanks.

Benham





-----Original Message-----
From: gmcnutt@xxxxxxx.sg]On">mailto:gmcnutt@xxxxxxx.sg]On
Behalf Of Gordon McNutt
Sent: Friday, December 29, 2000 1:55 AM
To: sklaw
Cc: eng70834@xxxxxxx.com
Subject: Re: [bluetooth-dev] Evaluations of Axis bluetooth_20001031 and
_1115. with null modem


sklaw wrote:

> Hi Benham,
>
> Thanks.  Please tell you use real bt or null modem for evaluation.
>
> It seems we got the same findings that user mode works fine but not with
> kernel mode command in both _0814 and 1031 .
>
> For _1115,  we tried ppp and rf_conn and got handle 0 and return to
command
> menu without CRC_Check error in both kernel mode and user mode.  Is that
> because you use bt instead of null modem? Please confirm!
>
> If anyone got kernel mode connected, please help! Because according to
> previous email discussion with null modem, kernel mode command  btd -m
> .......  instead of btduser -m ........ commands is used.
>

I've had kernel mode working in both 8/14 and 10/31.

If you're certain that you really are not getting a connection then turn on
debug and, if you want help deciphering it, post it here. Debug flags are in
btdebug.h.

--Gordon


_________________________________________________________
Do You Yahoo!?
Get your free @xxxxxxx.com">http://mail.yahoo.com

-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com