Feature lwip broadcast

[WillyKaze]

Description

Implement to SO_BROADCAST socket option and provide a UDPSocket::set_broadcast(bool) method.

sock.set_broadcast(true); // Enable reception of broadcast packets

Fix #3395.

Status

READY

[0xc0170]

Any tests for this addition?

cc @geky @kjbracey-arm

[geky]

This looks good. Raises the question of what other commonly used option should we lift up into the C++ interface.

Is this an alternative to #3482?

[geky]

Would you be able to add the appropriate doxygen documentation to this function? You can use the neighboring function's documentation as a template
https://github.com/ARMmbed/mbed-os/blob/master/features/netsocket/Socket.h#L109-L120

[WillyKaze]

Of course, I'll add the documentation.

[WillyKaze]

@geky, I'm also interested in multicast socket options but i'm not familiar with it. also SO_REUSEADDR would be great.

No test for this addition.

[geky]

Thanks for adding the docs, it looks great 👍

[0xc0170]

@WillyKaze Please rebase

@kjbracey-arm Can you have a look?

[0xc0170]

@WillyKaze bump

[kjbracey]

The "receive broadcast" thing is non-standard, and is (to my knowledge) specific to lwIP built with a specific build flag. The POSIX option SO_BROADCAST only controls ability to /transmit/ broadcasts.

I would argue that having SO_BROADCAST control reception is a bug rather than a feature, and lwIP has to be configured with that BROADCAST_RECV build option off to be used by the abstraction layer. Other stacks will not implement a receive block. So this doesn't totally replace #3482.

If this were reworded to be "transmit broadcasts", it could be fine, but some stack adaptation could permit you to send broadcasts even without this being called. That's the sort of thing that leads to annoying bugs - you find out later that some other stack you didn't test with needs this called.

At a minimum I'd like the documentation to make clear that some stacks may ignore the option/call - or do we require all stacks to implement a broadcast block? (Can they definitely do this, if autoconfigured? Can we assume things like the ESP8266 know the netmask?)

A counter-suggestion would be for there to be no special requirement for broadcast transmission - it should just always be permitted by NSAPI, and the abstraction implementations do whatever to make that work (eg calling setsockopt(SO_BROADCAST) if necessary).

Note that IPv6 does not require any special option to permit all-hosts-multicast. So the use of SO_BROADCAST by IPv4 feels a little legacy. But I guess the counter-argument is that IPv4 broadcast addresses aren't obviously distinct from unicast ones so it's easier to broadcast by mistake.

[WillyKaze]

@0xc0170 I'm having troubles rebasing the branch. Do you have a reference tutorial (other than git-scm).

EDIT: I have found a solution.

[kjbracey]

I'm feeling we should be going with a derivative of #3482 rather than this - see discussion there.

[geky]

It looks like this is being superseeded by #3482, which provides a simpler solution in regards to user interface.

Let us know if #3482 does not work for you and feel free to reopen if we should reconsider this pr.