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

RE: [bluetooth-dev] Bluetooth link stall (08/14 release)



Hi Johan,

Your prompt answer is much appreciated.
Pls see embedded comments below, marked "CT>". 

Best regards and a Merry Christmas.

Carlos M. Tomaz
Smarter Mobiles Ltd, Perth, Western Australia


-----Original Message-----
From: Johan Zander [mailto:johan.zander@xxxxxxx.com]
Sent: Thursday, December 21, 2000 4:12 PM
To: 'Carlos Tomaz'; Axis Support (E-mail)
Cc: 'Alexander Gordon (QIC)'
Subject: RE: [bluetooth-dev] Bluetooth link stall (08/14 release)



Hi Carlos,

always use the latest release, there are many bugfixes since the august
release.


CT> It was apparent that the 11/15 release was in a state of flux. We tried
to use it, but the lack of a "connect" command led us to believe that a
baseband connection was not possible. Please correct me if I'm wrong. Other
comments in the forum seemed to back our assumption as well.


Please explain what you mean by "no support for peer-to-peer connection at
PPP level". The bluetooth stack runs below PPP and the later versions
support PPP as well.


CT> With no "connect" command, how can you establisha an L2CAP/RFCOMM
connection, over which you can run a PPP connection? Please clarify. That is
what I mean, I could not start a PPP connection without first establishing a
baseband up to RFCOMM connection.
 

From the logs below, you are receiving thrashed data on the UART.


CT> Matches what I think. 


You could be experiencing a bad serial port. Are you using a laptop? We have
seen that older laptops can give this sort of behaviour. Run PPP without the
BT stack, but over a serial cable between two computers to see if the
problem still occurs. If it does you have a bad serial port.


CT> I'm using a desktop. I'll try what you suggest, over a null modem
connection.


The Ericsson P9A firmware can also thrash data at certain UART speeds. Get
the latest Axis BT-stack and latest Ericsson firmware and see if the problem
still occurs. P9B should solve this. To run the latest firmware (P912) you
need new Ericsson hw as well.


CT> As you see below, we have P9A revision F/W. That's certainly a likely
cause. Hope that I can get P9B from Sigma or Ericsson on line, would you
know if that is possible?


Regards,
Johan

Axis Bluetooth Team


CT> Thank you once more.





-----Original Message-----
From: Carlos Tomaz [mailto:Carlos.Tomaz@xxxxxxx.com]
Sent: Wednesday, December 20, 2000 7:52 AM
To: Axis Support (E-mail)
Cc: Mason Allen; Hiep Nguyen
Subject: [bluetooth-dev] Bluetooth link stall (08/14 release)


Greetings,

We are setting a small demonstration of Web browsing over Bluetooth. The
setup is as follows:

*	Axis stack release 08/14 (14th of August). We found that neither
11/15 or 10/31 support peer-to-peer connection at PPP level.
*	One stack is configured as client, the other as server. Both stacks
run in kernel mode. PPP daemon configuration below.
*	Red Hat Linux 6.2, kernel version 2.78. 
*	Squid caching proxy server V2.3. Squid listens to port 3128 for
client accesses.
*	Netscape browser client V 4.72. The browser connects to the Squid
proxy server for Web access across the established PPP link.
*	Ericsson/Sigma mini-kits (EBMK), F/W revision P9A (CXC 125 244 P9A,
2000-04-28 15:54). 

We have found that, for no apparent reason, the connection will eventually
stall whilst retrieving Web pages with the browser. When the stall occurs,
all the applications involved still run: Web browser, PPP daemon in client
side, Bluetooth client stack, Bluetooth server stack, PPP daemon on server
side and Squid proxy. However, the Bluetooth connection between client and
server is lost (cannot ping either server's localhost or PPP endpoint). We
believe that the server actually shuts the connection down. See below
extract from /var/log/messages, client and server sides. 

We do not understand the reason for this behaviour, but suspect it is
related to either a stack malfunction and/or a firmware problem. The reason
for our belief is the constant loss or corruption of packets over the HCI,
as illustrated by constant re-synchronisation of the HCI state machine.


Any help in solving or providing further insight into this problem would be
greatly appreciated.

Best regards,
Carlos M. Tomaz (carlos.tomaz@xxxxxxx.com)
Smarter Mobiles Ltd, Perth, Western Australia


===Extract from /var/log/messages, server side===
Dec 20 10:05:50 wittenoom kernel: BT SYS:  ERROR :hci_receive_data: 0x00 is
an unknown HCI type! 
Dec 20 10:05:50 wittenoom kernel: lst rec data pointer 0xc0bf715c, count 1,
data_len 12 
Dec 20 10:05:50 wittenoom kernel: Bad UART baud rate ? Check if baudrate
really was successfully set in HW 
Dec 20 10:05:50 wittenoom kernel: Resetting state machine and trying to
resync 
........
Dec 20 10:05:51 wittenoom kernel: lst rec data pointer 0xc0bf735c, count 1,
data_len 12 
Dec 20 10:05:51 wittenoom kernel: Bad UART baud rate ? Check if baudrate
really was successfully set in HW 
Dec 20 10:06:05 wittenoom kernel: BT SYS:  ERROR :rfcomm_send_data: DLCI 2
not connected 


===Extract from /var/log/messages, client side===
........
Dec 19 09:58:54 katherine kernel: BT SYS:  ERROR :hci_receive_data: 0x7e is
an unknown HCI type! 
Dec 19 09:58:54 katherine kernel: lst rec data pointer 0xc37f635c, count 10,
data_len 135 
Dec 19 09:58:54 katherine kernel: Bad UART baud rate ? Check if baudrate
really was successfully set in HW 


=== etc/ppp/options, server side ===
noauth nodeflate nobsdcomp lock
mtu 296 
mru 296
debug
local
silent
(local subnet).100:(local subnet).101 
proxyarp


=== etc/ppp/options, client side ===
noauth nodeflate nobsdcomp lock
mtu 296
mru 296
debug
local



 <<Carlos M. Tomaz (E-mail).vcf>> 
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com