Yunus Shaikh 032dea0aab fix(libSceNet): read SO_RCVTIMEO and SO_SNDTIMEO as a timeval in sceNetSetsockopt ...

sceNetSetsockopt took the BSD timeout options, SO_SNDTIMEO (0x1005) and
SO_RCVTIMEO (0x1006), like Sony's 0x1105 and 0x1106: as an int of
microseconds read from the first four bytes. A caller passing a struct
timeval got tv_sec taken as microseconds, so {0, 100000} meant to wait
100 ms became 0 and disabled the timeout, and the receive blocked until
data came.

On the console 0x1006 takes a timeval, as FreeBSD 11.4's sosetopt does.
ProsperoLight (PPSA99002) gives it {0, 100000} through sceNetSetsockopt,
and its log from a console (firmware 12.20) shows Moonlight's receive
timing out every 100 ms before the first packet ("Received first video
packet after 400 ms"). Sony moved only these two timeval options to
0x1105 and 0x1106, as ints. On AnyPS5 the receive never times out, so
ProsperoLight's receive threads never wake when the PC stops sending and
LiStopConnection never returns: the stream screen freezes when a session
ends from the PC side. Steam Remote Play (PPSA99350) sets {0, 10000} the
same way and stays on "THE PC DID NOT ANSWER" when the PC doesn't reply.

0x1005 and 0x1006 now go through the timeval path that setsockopt() on a
libSceNet socket already uses (EINVAL for a value shorter than a timeval,
EDOM for a negative or out-of-range one). sceNetGetsockopt gives them
back as a timeval cut to the caller's length, as FreeBSD's sooptcopyout
does. 0x1105 and 0x1106 keep taking an int of microseconds.

2026-10-14 08:37:48 -07:00

..

CMakeLists.txt

fix(libs): allow socket receives into watched guest memory

2026-10-12 05:37:35 +02:00

Export.cpp

fix(libSceNet): read SO_RCVTIMEO and SO_SNDTIMEO as a timeval in sceNetSetsockopt

2026-10-14 08:37:48 -07:00