I narrowed down the problem a little bit by executing the streaming_client command manually. I found the command and parameters by using the following strace:

$ strace -f -s999999 -o strace.log -e trace=clone,execve steam

This led me to:

$ /home/john5788/.local/share/Steam/ubuntu12_32/streaming_client --gameid 518030 --server 192.168.1.101:27031 --windowed --quality 2 --bitrate 50000 --captureres 0x0 bc85f0b599b2e{truncated}

When I execute that command, I see this:

/home/john5788/.local/share/Steam/ubuntu12_32/streaming_client: error while loading shared libraries: libtier0_s.so: cannot open shared object file: No such file or directory

I am using STEAM_RUNTIME, is this library missing from the latest update?

Edit:

There were a few missing libraries:

$ ldd steamclient.so  | grep not
	libtier0_s.so => not found  
	libvstdlib_s.so => not found  
	libopenal.so.1 => not found  
	libudev.so.0 => not found

So I included them manually with LD_LIBRARY_PATH by finding out where each of these missing libraries were and executed the same command again:

Edit: Disregard above comments about missing libraries. I understand now that opening streaming_client by itself on the command line will cause this problem because the environment was not setup by the steam.sh script. Loading the libraries manually like this is necessary in order to execute streaming_client to trace the actual error.

$ export LD_LIBRARY_PATH=/home/john5788/.local/share/Steam/ubuntu12_32/:/home/john5788/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/

$ /home/john5788/.local/share/Steam/ubuntu12_32/streaming_client --gameid 518030 --server 192.168.1.101:27031 --windowed --quality 2 --bitrate 50000 --captureres 0x0 bc85f0b599b2e{truncated}

Installing breakpad exception handler for appid(streaming_client)/version(20180724182646)
Installing breakpad exception handler for appid(streaming_client)/version(1.0)
Initializing player
Refresh rate: 144.00
Effective rate: 143.75
Video size: 1920x1080, output size: 1920x1080
Video rect: 1920x1080 at 0,0
Texture rect: 1920x1080 at 0,0
Initialized player
Server available at address: 192.168.1.101:27031
Connecting to server at address: 192.168.1.101:27031
Couldn't create socket: ��^

Tracing the streaming_client command to figure out why it cannot create a socket:

7972  write(1, "Initialized player\n", 19) = 19
7972  gettid()                          = 7972
7972  gettid()                          = 7972
7972  write(1, "Server available at address: 192.168.1.101:27031\n", 49) = 49
7972  gettid()                          = 7972
7972  gettid()                          = 7972
7972  gettid()                          = 7972
7972  write(1, "Connecting to server at address: 192.168.1.101:27031\n", 53) = 53
7972  socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP) = -1 EAFNOSUPPORT (Address family not supported by protocol)
7972  gettid()                          = 7972
7972  write(1, "Couldn't create socket: \272\4c\364\n", 29) = 29
7972  exit_group(1)                     = ?
7975  <... ppoll resumed> <unfinished ...>) = ?
7975  +++ exited with 1 +++
7972  +++ exited with 1 +++

It looks like streaming_client is trying to open an IPv6 socket when it shouldn't? I don't have IPv6 support in my kernel. There should be a check for this instead of blindly opening the socket this way.

Although I understand it is possible to map an IPv4 destination with an IPv6 address, according to FreeBSD, it's not recommended: https://www.unix.com/man-page/FreeBSD/4/inet6/

By default, FreeBSD does not route IPv4 traffic to AF_INET6 sockets. The default behavior intentionally violates RFC2553 for security reasons. Listen to two sockets if you want to accept both IPv4 and IPv6 traffic. IPv4 traffic may be routed with certain per-socket/per-node configuration, however, it is not recommended to do so. Consult ip6(4) for details.

Notifying @slouken and @kisak-valve to take a look at the debugging and to hopefully get a fix in place. As far as I know there are at least 3 other occurrences of this from other people on Reddit and the Steam forums.

Would this be the same issue going the other way? The July timing seems about right where my in home streaming stopped working. Only in my case I am running linux as the host and a Steam Link as the client (Also tried from the android Steam Link app). As soon as I try to connect, Steam on the host crashes with a "Couldn't create socket" message. I have tried all combinations of having ipv6 enabled/disabled on the host with beta and standard steam. If you need me to gather any more information let me know.

After a long time of abstinence, today I tried to give my steamlink a chance - and I ran into the same issue as mentioned by https://github.com/ValveSoftware/steam-for-linux/issues/5578#issuecomment-408328577.

My host (Linux, Ubuntu 18.04.1 LTS) with a custom kernel and IPv6 disabled (not built in into the kernel because of reasons!) failed to serve. The error is the same: "Couldn't create socket: <random_special_chars>". Steam istself is latest beta (on Linux).

The streaming_client seems to brute-force open a IPv6 socket even if the kernel/system does not support it as @john5788 figured out. Is anyone at valve looking into that issue? Or do I have to introduce IPv6 now? :)

And, as a side note, I tried: https://www.reddit.com/r/archlinux/comments/99o83p/disabling_ipv6_breaks_steam_inhome_streaming/
This seems to help "a bit" (steam link can connect) but later failes with:
[...]
Bind to [::]:27050 failed: �����
[...]

Hello @john5788, are you still experiencing this issue on an up to date system?

Friendly side note that I'm a moderator for Valve's issue trackers and not a Valve developer myself.

My personal fix was to recompile my kernel with IPv6 support enabled, although I don't even use it.