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

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




Hi Carlos,

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

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.

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

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.

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.


Regards,
Johan

Axis Bluetooth Team




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