Re: [RFC] network: Reply to extensions at connection setup

[Marcel Holtmann <marcel@holtmann.org>]

Hi Frederic,

>         > TP/BNEP/CTRL/BV-19-C is about extension in the
>         BNEP_SETUP_CONN_REQ
>         > control message. BNEP_SETUP_CONN_REQ is handled by
>         bluetoothd before
>         > giving control to kernel.  Current bluez do not reply at all
>         if an
>         > extension is added to BNEP_SETUP_CONN_REQ. This patch fixes
>         it by
>         > sending COMMAND_NOT_UNDERSTOOD reply.
>         
>  
>         
>         is this really a good idea to just decline all extensions
>         here?
>         
>         What happens to the filter setup done via these commands.
>         Don't we need
>         to process them inside the kernel to actually setup the
>         filters.
>  
> I have chosen to decline the extension because they are marked as not
> supported in all qualification listings that I have seen.

may that is the reason for it. Nevertheless no reason for us not to
support it.

> Processing extensions in the kernel is of course better, but both
> kernel and 
> userspace needs changing, which is usually a much longer process. If
> preferred,
> I can do so.

I am fine with doing this as a first step. Since essentially if we run
on an older kernel, we need to do that anyway. We need to fallback
gracefully.

However I do like to see a plan for adding a new ioctl() to BNEP support
that allows us to include leftover unprocessed extensions.

Please consider Luiz comments since the patch is not really clean. We
need to make this more readable. Especially when it gets more complex
and becomes a fallback case.

Regards

Marcel