2006-02-24 11:14:49

by Al

[permalink] [raw]
Subject: RE: [Bluez-users] ISSC USB dongle can't ping with size 1000

Hi, Marcel:

Frankly I don't know much about ISSC chip's internals since I work mainly
at application level. Your comments and information are highly appriciated and
I will pass them to ASIC and System team to see if I can get some feedbacks.

In the mean time, I wonder if there is a work-around solution to this problem.
For example, set MTU to 1000 or refrain BlueZ HCI to send smaller packet size.
Also, can you tell a bit more about the buffer size you mentioned? Where I can
modify for a quick test and what's the current buffer size?

Best Regards,

Al

-----Original Message-----
From: [email protected] ?N?z Marcel Holtmann
Sent: 2006/2/23 [?P???|] ?U?? 07:23
To: [email protected]
Cc:
Subject: Re: [Bluez-users] ISSC USB dongle can't ping with size 1000



Hi Al,

> > I have the same problem as below which was posted last month.
> >
> > > I started to play with the ping size. 'ping -s 900' works, 'ping -s 1000'
> > > kills the PAN connection. There was hope! Then I played with MTU (on both
> > > sides): 'ifconfig bnep0 mtu 1000' solves all my problems (default is
> > > 1500)!!! With this setting I've a rock solid 75 kByte/s transfer rate over
> > > ftp. A mtu of 1017 still works, 1018 definitely kills the connection.
> >
> > I wonder if there is other solutions to this problem cause the above solution needs to set MTU to 1000 on both sides.
> >
> > I try ISSC dongle with IVT software as NAP on Windows XP. Ping with size
> > 1500 works fine. It seems ISSC chip has some problems to work with BlueZ, in
> > addition to adding HCI_RESET.
>
> I am pretty sure that your chip is at fault here. I have no internals
> about your chip, but whatever buffer size you tell us, we will use. And
> BlueZ will use it as fast as possible. The latency is very low and the
> HCI flow control works fine. So I assume there exists a race condition
> in your side of the HCI flow control implementation which triggers a
> problem. You can verify with hcidump that we do everything right. The
> faulty application is actually not BNEP here. I think you can reproduce
> it with any program sending big L2CAP packets. So a test setup with
> l2test and different MTU might trigger it more easily.

and I just did a quick search through the mailing list archive and
actually I found these four version:

ACL MTU: 678:12 SCO MTU: 48:5 LMP Ver: 1.1 LMP Subver: 0x172
ACL MTU: 678:8 SCO MTU: 48:5 LMP Ver: 1.1 LMP Subver: 0x1a4
ACL MTU: 678:8 SCO MTU: 48:10 LMP Ver: 1.2 LMP Subver: 0x1ae
ACL MTU: 678:8 SCO MTU: 48:10 LMP Ver: 1.2 LMP Subver: 0x1f4

The LMP Subver must somehow decode into the version number of your
firmware, but I have no idea how. However you see the different ACL MTU
sizes the chip offers and BlueZ is simply using them.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users



Attachments:
winmail.dat (6.91 kB)

2006-03-08 19:21:42

by Agustin Jose Fusaro

[permalink] [raw]
Subject: [Bluez-users] Rfcomm connection with pin number question

Hi everybody,

I'm writing an application that uses rfcomm sockets to connect to remote
devices. I'm using some of the example code for how to use the blueZ
api, from Marcel.

I wanted to know if there's a way of connecting to a remote device, that
needs a PIN number, without using the pin helper file or any of those
scripts... I just want to connect to the device passing, for example,
the pin code as a function parameter.

Does anybody know if this can be achieved using the blueZ library, and
not using the pin helper file?

Thanks a lot!!!

Agustin Fusaro - Apexar Technologies



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users