Re: [RFC]Mesh: meshctl configuration output fails in gatt.c:pipe_write

[Steve Brown <sbrown@cortland.com>]

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@cortland.com>
> 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