We tried to write a 64k data to rfcomm socket, but it will break
before sending all of the data out. The problem is in function
rfcomm_sock_sendmsg() in net/bluetooth/rfcomm/sock.c, it breaks after
calling sock_alloc_send_skb().
static int rfcomm_sock_sendmsg(...)
{
...
skb = sock_alloc_send_skb(sk, size + RFCOMM_SKB_RESERVE,
msg->msg_flags & MSG_DONTWAIT, &err);
if (!skb)
break;
...
}
Looks the send buffer is not adequate. Then I increased the send
buffer size in function rfcomm_sock_alloc(), build kernel and try
again, this time the sendmsg can complete sending all the data.
Can we use the setsockopt() method to change the socket's send/receive
buffer size, just like the usual tcp/ip socket?
Thanks,
Zhu Lan
Hi Lain,
2009/8/29 Iain Hibbert <[email protected]>:
> On Fri, 28 Aug 2009, Marcel Holtmann wrote:
>
>> > Yes, it's our kernel's problem. We used another version and it worked
>> > fine. Here the change in rfcomm_sock_alloc() is only for testing. What
>> > I'm doing now is adding a case for RFCOMM_SNDBUF in the function
>> > rfcomm_sock_setsockopt_old(), as below.
>> >
>> > =A0 =A0 case RFCOMM_SNDBUF:
>> > =A0 =A0 =A0 =A0 =A0 =A0 sk->sk_sndbuf =3D opt;
>> > =A0 =A0 =A0 =A0 =A0 =A0 break;
>> >
>> > I'm thinking to add a limitation for a maximum buffer size, but don't
>> > know what maximum size is appropriate here. Do you have any idea?
>>
>> no that is bluntly wrong. Why do you think the function has _old in its
>> name. It clearly shows that we are going to deprecate it soon. If you do
>> this for RFCOMM, then it should also be done for L2CAP. So make sure you
>> use SOL_BLUETOOTH. And make it similar to what TCP is doing.
>
> Eh? Why would you need to invent a SOL_BLUETOOTH setting for this when
> there is a standard "SOL_SOCKET, SO_SNDBUF" option that covers it already=
?
>
> =A0http://www.opengroup.org/onlinepubs/000095399/functions/setsockopt.htm=
l
>
> regards,
> iain
>
>
>
>
Lain, you are right. I tried setsockopt with level SOL_SOCKET and opt
SO_SNDBUF, it worked well. So, Bluetooth socket can set all the
standard sock options, no need to add extra code for that. Thanks a
lot for your suggestion.
Marcel, also thank you for considering this issue these days.
Thanks,
Zhu Lan
On Fri, 28 Aug 2009, Marcel Holtmann wrote:
> > Yes, it's our kernel's problem. We used another version and it worked
> > fine. Here the change in rfcomm_sock_alloc() is only for testing. What
> > I'm doing now is adding a case for RFCOMM_SNDBUF in the function
> > rfcomm_sock_setsockopt_old(), as below.
> >
> > case RFCOMM_SNDBUF:
> > sk->sk_sndbuf = opt;
> > break;
> >
> > I'm thinking to add a limitation for a maximum buffer size, but don't
> > know what maximum size is appropriate here. Do you have any idea?
>
> no that is bluntly wrong. Why do you think the function has _old in its
> name. It clearly shows that we are going to deprecate it soon. If you do
> this for RFCOMM, then it should also be done for L2CAP. So make sure you
> use SOL_BLUETOOTH. And make it similar to what TCP is doing.
Eh? Why would you need to invent a SOL_BLUETOOTH setting for this when
there is a standard "SOL_SOCKET, SO_SNDBUF" option that covers it already?
http://www.opengroup.org/onlinepubs/000095399/functions/setsockopt.html
regards,
iain
Hi Zhu,
> >> >> We tried to write a 64k data to rfcomm socket, but it will break
> >> >> before sending all of the data out. The problem is in function
> >> >> rfcomm_sock_sendmsg() in net/bluetooth/rfcomm/sock.c, it breaks after
> >> >> calling sock_alloc_send_skb().
> >> >>
> >> >> static int rfcomm_sock_sendmsg(...)
> >> >> {
> >> >> ...
> >> >> skb = sock_alloc_send_skb(sk, size + RFCOMM_SKB_RESERVE,
> >> >> msg->msg_flags & MSG_DONTWAIT, &err);
> >> >> if (!skb)
> >> >> break;
> >> >> ...
> >> >> }
> >> >>
> >> >> Looks the send buffer is not adequate. Then I increased the send
> >> >> buffer size in function rfcomm_sock_alloc(), build kernel and try
> >> >> again, this time the sendmsg can complete sending all the data.
> >> >>
> >> >> Can we use the setsockopt() method to change the socket's send/receive
> >> >> buffer size, just like the usual tcp/ip socket?
> >> >
> >> > yes we can. Send a patch for it and I am going to review it.
> >> >
> >> > Regards
> >> >
> >> > Marcel
> >> >
> >> >
> >> >
> >>
> >> Today I changed the send buffer size but found kernel become very
> >> unstable. It usually crash during sending rfcomm data. Do you know
> >> what's the reason?
> >>
> >> Below is what I changed in net/bluetooth/rfcomm/sock.c.
> >>
> >> in function rfcomm_sock_alloc(),
> >>
> >> change sk->sndbuf
> >> from
> >> sk->sk_sndbuf = RFCOMM_MAX_CREDITS * RFCOMM_DEFAULT_MTU * 10
> >> to
> >> sk->sk_sndbuf = RFCOMM_MAX_CREDITS * RFCOMM_DEFAULT_MTU * 20
> >
> > which kernel is this? There have been some fixes in the network stack
> > for this. Also I need oopses to see what might happen here.
> >
> > Regards
> >
> > Marcel
> >
> >
> >
>
> Yes, it's our kernel's problem. We used another version and it worked
> fine. Here the change in rfcomm_sock_alloc() is only for testing. What
> I'm doing now is adding a case for RFCOMM_SNDBUF in the function
> rfcomm_sock_setsockopt_old(), as below.
>
> case RFCOMM_SNDBUF:
> sk->sk_sndbuf = opt;
> break;
>
> I'm thinking to add a limitation for a maximum buffer size, but don't
> know what maximum size is appropriate here. Do you have any idea?
no that is bluntly wrong. Why do you think the function has _old in its
name. It clearly shows that we are going to deprecate it soon. If you do
this for RFCOMM, then it should also be done for L2CAP. So make sure you
use SOL_BLUETOOTH. And make it similar to what TCP is doing.
Regards
Marcel
Hi Marcel,
2009/8/28 Marcel Holtmann <[email protected]>:
> Hi Zhu,
>
>> >> We tried to write a 64k data to rfcomm socket, but it will break
>> >> before sending all of the data out. The problem is in function
>> >> rfcomm_sock_sendmsg() in net/bluetooth/rfcomm/sock.c, it breaks after
>> >> calling sock_alloc_send_skb().
>> >>
>> >> static int rfcomm_sock_sendmsg(...)
>> >> {
>> >> =A0 =A0...
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 skb =3D sock_alloc_send_skb(sk, size + RF=
COMM_SKB_RESERVE,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 msg->msg_=
flags & MSG_DONTWAIT, &err);
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!skb)
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
>> >> =A0 =A0...
>> >> }
>> >>
>> >> Looks the send buffer is not adequate. Then I increased the send
>> >> buffer size in function rfcomm_sock_alloc(), =A0build kernel and try
>> >> again, this time the sendmsg can complete sending all the data.
>> >>
>> >> Can we use the setsockopt() method to change the socket's send/receiv=
e
>> >> buffer size, just like the usual =A0tcp/ip socket?
>> >
>> > yes we can. Send a patch for it and I am going to review it.
>> >
>> > Regards
>> >
>> > Marcel
>> >
>> >
>> >
>>
>> Today I changed the send buffer size but found kernel become very
>> unstable. It usually crash during sending rfcomm data. Do you know
>> what's the reason?
>>
>> Below is what I changed in net/bluetooth/rfcomm/sock.c.
>>
>> in function rfcomm_sock_alloc(),
>>
>> change sk->sndbuf
>> from
>> sk->sk_sndbuf =3D RFCOMM_MAX_CREDITS * RFCOMM_DEFAULT_MTU * 10
>> to
>> sk->sk_sndbuf =3D RFCOMM_MAX_CREDITS * RFCOMM_DEFAULT_MTU * 20
>
> which kernel is this? There have been some fixes in the network stack
> for this. Also I need oopses to see what might happen here.
>
> Regards
>
> Marcel
>
>
>
Yes, it's our kernel's problem. We used another version and it worked
fine. Here the change in rfcomm_sock_alloc() is only for testing. What
I'm doing now is adding a case for RFCOMM_SNDBUF in the function
rfcomm_sock_setsockopt_old(), as below.
case RFCOMM_SNDBUF:
sk->sk_sndbuf =3D opt;
break;
I'm thinking to add a limitation for a maximum buffer size, but don't
know what maximum size is appropriate here. Do you have any idea?
Thanks,
Zhu Lan
Hi Zhu,
> >> We tried to write a 64k data to rfcomm socket, but it will break
> >> before sending all of the data out. The problem is in function
> >> rfcomm_sock_sendmsg() in net/bluetooth/rfcomm/sock.c, it breaks after
> >> calling sock_alloc_send_skb().
> >>
> >> static int rfcomm_sock_sendmsg(...)
> >> {
> >> ...
> >> skb = sock_alloc_send_skb(sk, size + RFCOMM_SKB_RESERVE,
> >> msg->msg_flags & MSG_DONTWAIT, &err);
> >> if (!skb)
> >> break;
> >> ...
> >> }
> >>
> >> Looks the send buffer is not adequate. Then I increased the send
> >> buffer size in function rfcomm_sock_alloc(), build kernel and try
> >> again, this time the sendmsg can complete sending all the data.
> >>
> >> Can we use the setsockopt() method to change the socket's send/receive
> >> buffer size, just like the usual tcp/ip socket?
> >
> > yes we can. Send a patch for it and I am going to review it.
> >
> > Regards
> >
> > Marcel
> >
> >
> >
>
> Today I changed the send buffer size but found kernel become very
> unstable. It usually crash during sending rfcomm data. Do you know
> what's the reason?
>
> Below is what I changed in net/bluetooth/rfcomm/sock.c.
>
> in function rfcomm_sock_alloc(),
>
> change sk->sndbuf
> from
> sk->sk_sndbuf = RFCOMM_MAX_CREDITS * RFCOMM_DEFAULT_MTU * 10
> to
> sk->sk_sndbuf = RFCOMM_MAX_CREDITS * RFCOMM_DEFAULT_MTU * 20
which kernel is this? There have been some fixes in the network stack
for this. Also I need oopses to see what might happen here.
Regards
Marcel
Hi Marcel,
2009/8/27 Marcel Holtmann <[email protected]>:
> Hi Zhu,
>
>> We tried to write a 64k data to rfcomm socket, but it will break
>> before sending all of the data out. The problem is in function
>> rfcomm_sock_sendmsg() in net/bluetooth/rfcomm/sock.c, it breaks after
>> calling sock_alloc_send_skb().
>>
>> static int rfcomm_sock_sendmsg(...)
>> {
>> =A0 =A0...
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 skb =3D sock_alloc_send_skb(sk, size + RFCOM=
M_SKB_RESERVE,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 msg->msg_fla=
gs & MSG_DONTWAIT, &err);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!skb)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
>> =A0 =A0...
>> }
>>
>> Looks the send buffer is not adequate. Then I increased the send
>> buffer size in function rfcomm_sock_alloc(), =A0build kernel and try
>> again, this time the sendmsg can complete sending all the data.
>>
>> Can we use the setsockopt() method to change the socket's send/receive
>> buffer size, just like the usual =A0tcp/ip socket?
>
> yes we can. Send a patch for it and I am going to review it.
>
> Regards
>
> Marcel
>
>
>
Today I changed the send buffer size but found kernel become very
unstable. It usually crash during sending rfcomm data. Do you know
what's the reason?
Below is what I changed in net/bluetooth/rfcomm/sock.c.
in function rfcomm_sock_alloc(),
change sk->sndbuf
from
sk->sk_sndbuf =3D RFCOMM_MAX_CREDITS * RFCOMM_DEFAULT_MTU * 10
to
sk->sk_sndbuf =3D RFCOMM_MAX_CREDITS * RFCOMM_DEFAULT_MTU * 20
Thanks,
Zhu Lan
Hi Zhu,
> We tried to write a 64k data to rfcomm socket, but it will break
> before sending all of the data out. The problem is in function
> rfcomm_sock_sendmsg() in net/bluetooth/rfcomm/sock.c, it breaks after
> calling sock_alloc_send_skb().
>
> static int rfcomm_sock_sendmsg(...)
> {
> ...
> skb = sock_alloc_send_skb(sk, size + RFCOMM_SKB_RESERVE,
> msg->msg_flags & MSG_DONTWAIT, &err);
> if (!skb)
> break;
> ...
> }
>
> Looks the send buffer is not adequate. Then I increased the send
> buffer size in function rfcomm_sock_alloc(), build kernel and try
> again, this time the sendmsg can complete sending all the data.
>
> Can we use the setsockopt() method to change the socket's send/receive
> buffer size, just like the usual tcp/ip socket?
yes we can. Send a patch for it and I am going to review it.
Regards
Marcel