Hi Luiz, On Fri, 2017-11-24 at 17:10 +0200, Luiz Augusto von Dentz wrote: > Hi Steve, > > On Fri, Nov 24, 2017 at 4:39 PM, Steve Brown <sbrown@xxxxxxxxxxxx> > wrote: > > If the first command output in a new connection exceeds 20 bytes, > > mesh_gatt_write sets the SAR to FIRST as the write_mtu is initially > > 0 > > and the default is GATT_MTU-3 (20). > > > > When pipe_write gets called, a new larger write_mtu has been set, > > but > > the SAR is still set to FIRST. It's assumed that data->gatt_len > > > max_len. However, it's not which causes lots of bogus output. > > > > I've added code to reset the SAR and length in acquire_write_reply > > in > > case write_mtu might have changed. > > > > This seems to work, but I'm sure there is a better way. > > > > Steve > > > Ive never really liked the idea of putting the SAR byte into data but > it was required due to use of WriteValue, now perhaps we can even > remove that since AcquireWrite is stable the sar byte can be set in > an > independent variable in pipe_write so we can move this logic there. > > > Have you had a chance to review my changes to gatt.c? http://www.spinics.net/lists/linux-bluetooth/msg72981.html I removed the WriteValue code and moved the sar logic to pipe_write as you requested. The latter fixed the bug I reported. If you have no additional comments, let me know and I'll submit it as a patch. I'm working on some additional commands for meshctl and they won't work without the bug fixed. Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
