Hi,
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.=20
I wonder if there is other solutions to this problem cause the =
above solution needs to set MTU to 1000 on both sides.=20
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.
Thanks for helps,
Al=20
-------------------------------------------------------
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
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
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.
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
Hi, Marcel:
There is no default size and packet number assigned to ISSC chip
if no HCI_Host_Buffer_Size command is sent from Host.
It sends whatever the size it receives to host. But it has problem to
send the packets with size more than 970 bytes from my current
observation.
BRs,
Al
-----Original Message-----
From: [email protected] ?N?z Marcel Holtmann
Sent: 2006/3/9 [?P???|] ?U?? 09:49
To: [email protected]
Cc:
Subject: RE: [Bluez-users] ISSC USB dongle can't ping with size 1000
Hi Al,
> I think the problem may not be the buffer size (678) that ISSC device
> has. When I ping with size 1400 bytes, hcidump shows host breaks 1400 bytes
> into serveal 678 byte packets and sends them to device. Both ping request and ping reply from the other side can be captured in air.
>
> Most likely the problem is occured when ISSC device trys to send
> packets with large size to host. From the hcidump, I observe that if devices
> like CSR receiving packets with size 1400, it breaks 1400 into serveral 300 (something) packets and sends to host. On the other hand, when ISSC device receives packet with size 900, it sends 900 byte packet to host without breaking. But when the size is more than 1000, hcidump shows ISSC device does not send any packet to host.
there exists the HCI_MAX_ACL_SIZE constant which is 1024 and the
HCI_MAX_FRAME_SIZE which is 4 times HCI_MAX_ACL_SIZE.
What is the default frame size and max packets number an ISSC chips
sends to the host if no HCI_Host_Buffer_Size has been called?
> After sending HCI_Host_Buffer_Size command, hcidump shows ISSC
> device sends max size of 256 byte to host. Ping with 1500 bytes and Internet
> access work so far. I only try this with PAN to implement NAP.
The kernel has the HCI_Host_Buffer_Size command in its code, but it is
commented out. I forget the reason why this has been done, but I assume
there was a reason for it.
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
Hi Al,
> I think the problem may not be the buffer size (678) that ISSC device
> has. When I ping with size 1400 bytes, hcidump shows host breaks 1400 bytes
> into serveal 678 byte packets and sends them to device. Both ping request and ping reply from the other side can be captured in air.
>
> Most likely the problem is occured when ISSC device trys to send
> packets with large size to host. From the hcidump, I observe that if devices
> like CSR receiving packets with size 1400, it breaks 1400 into serveral 300 (something) packets and sends to host. On the other hand, when ISSC device receives packet with size 900, it sends 900 byte packet to host without breaking. But when the size is more than 1000, hcidump shows ISSC device does not send any packet to host.
there exists the HCI_MAX_ACL_SIZE constant which is 1024 and the
HCI_MAX_FRAME_SIZE which is 4 times HCI_MAX_ACL_SIZE.
What is the default frame size and max packets number an ISSC chips
sends to the host if no HCI_Host_Buffer_Size has been called?
> After sending HCI_Host_Buffer_Size command, hcidump shows ISSC
> device sends max size of 256 byte to host. Ping with 1500 bytes and Internet
> access work so far. I only try this with PAN to implement NAP.
The kernel has the HCI_Host_Buffer_Size command in its code, but it is
commented out. I forget the reason why this has been done, but I assume
there was a reason for it.
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
Hi, Marcel:
I think the problem may not be the buffer size (678) that ISSC device
has. When I ping with size 1400 bytes, hcidump shows host breaks 1400 bytes
into serveal 678 byte packets and sends them to device. Both ping request and ping reply from the other side can be captured in air.
Most likely the problem is occured when ISSC device trys to send
packets with large size to host. From the hcidump, I observe that if devices
like CSR receiving packets with size 1400, it breaks 1400 into serveral 300 (something) packets and sends to host. On the other hand, when ISSC device receives packet with size 900, it sends 900 byte packet to host without breaking. But when the size is more than 1000, hcidump shows ISSC device does not send any packet to host.
I have tried to send HCI_Host_Buffer_Size for ALC link (300 byte for example) to ISSC device:
-----------------------------------------------------------------------------------------------------
int dd = hci_open_dev(di.dev_id);
host_buffer_size_cp cp;
struct hci_request rq;
memset(&rq, 0, sizeof(rq));
rq.ogf = OGF_HOST_CTL;
rq.ocf = OCF_HOST_BUFFER_SIZE;
cp.acl_mtu = 300;
cp.sco_mtu = 30;
cp.acl_max_pkt = 5;
cp.sco_max_pkt = 5;
rq.rparam = &cp;
rq.rlen = HOST_BUFFER_SIZE_CP_SIZE;
if (hci_send_req(dd, &rq, 1000) < 0)
return -1;
hci_close_dev(dd);
return 0;
--------------------------------------------------------
After sending HCI_Host_Buffer_Size command, hcidump shows ISSC
device sends max size of 256 byte to host. Ping with 1500 bytes and Internet
access work so far. I only try this with PAN to implement NAP.
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