It's the sed line. It turns
$this->bbcode_second_pass_code('', '
#if defined(SO_REUSEPORT)
setsockopt(..., SO_REUSEPORT, ...);
#endif
')
into
$this->bbcode_second_pass_code('', '
#if 0
...
')
which prevents netcat to add the SO_REUSEPORT option to the socket.
No PR because I don't know what the root of the problem is. The thing is, the SO_REUSEPORT option is actually useful, turning it off for everybody is probably a bad idea, especially since I don't know if it is supported by all other boards targeted by the ALARM effort. Also, on my board/kernel (beaglebone black/3.8.13-35-ARCH) the SO_REUSEPORT opt is defined in /usr/include/asm-generic/socket.h . I don't think it should be defined there to begin with, since it doesn't seem to be supported, so patching it in netcat is probably not a good long term solution.
Edit : I got a little more info.
So SO_REUSEPORT was introduced in the kernel at 3.9 (
link to the changelog). My kernel is 3.8., so I don't have it, but for some inexplicable reason, my core/linux-api-headers is version 3.16.2-1, and hence includes the SO_REUSEPORT definition in /usr/include/asm/socket.h . Really, the problem wasn't with netcat, but with a mismatch between my kernel version and my linux-api-headers version.
So to sum it up :
* People using the binary openbsd-netcat from pacman and running the core/linux-am33x-legacy kernel (or any kernel < 3.9) will have the problem. They can try and recompile their binary with the repo PKGBUILD.
* People running a kernel version < 3.9 and linux-api-headers > 3.9 will compile a wrong binary from the repo PKGBUILD. They can recompile their binary with my modified PKGBUILD (or just switch to gnu-netcat, which doesn't support SO_REUSEPORT at all).
* Everybody else should be fine.