[dborth]

a PR was recently submitted to me - dborth/libsmb2#2

the problem - net_recvfrom and net_sendto are neither bound nor gracefully handle large sizes.

looks like others have hit this before so I pulled the working fix from dacotaco (devkitPro/libogc@f4dbfca)

[Extrems]

I don't believe this memory copy is required to begin with, certainly not from/to MEM2. I'll have to check for MEM1.

[TeleTubby666]

Thanks for picking this up. I reported the original issue in
dborth/libsmb2#2 (real Wii, Samba 4, SMB2/3). I read through the diff and
have two observations:

1. Splitting into blocks fixes the IPC_ENOMEM (-22) on large requests, which
   was one of the two problems I saw. The other was a hang right after the
   TCP connect: libsmb2's read loop expects EAGAIN when no data is pending
   on a non-blocking socket, but net_read() -> net_recvfrom() with flags 0
   did not give me that. I worked around it by calling net_select() with a
   zero timeout first and returning EAGAIN if nothing is readable. This
   patch doesn't change that behaviour, so I'd expect the hang to remain.

2. In the new loop, if len > maxblocksize and the first block comes back
   full, the loop calls recvfrom again immediately. If no more data is
   pending, that call either blocks or returns -EAGAIN, and since
   ret = received overwrites the count, the data already read is lost.
   Returning the bytes read so far (when ret > 0) would avoid that. The same
   applies to net_sendto if a later block fails.

I haven't tested this PR build on hardware yet. Since dborth/libsmb2#2 was
closed in favour of this, I'd suggest keeping the EAGAIN/readability check
in mind until it's confirmed that the hang is gone with this change alone.
I'll report back with test results on hardware as soon as I'm home on
Friday.

[TeleTubby666]

Quick update: I tested a build with this PR (libogc2 PR 31) and an unmodified
dborth/libsmb2 on a Wii and a WiiU in vWii mode. It still hangs at
"connecting to network share", the same as without any fix. So the block
splitting alone doesn't resolve the connect hang, which is consistent with
my earlier reading of the diff.

For reference, dborth/libsmb2#2 is closed, but it contains the
net_select()/EAGAIN workaround that does fix the hang on my hardware
(together with the 8 KB cap), so it might still be worth keeping that part
in mind: dborth/libsmb2#2

I don't have a debug log from the hang yet. If it would help, I can build
with debug output and post it.

[TeleTubby666]

Update with hardware results: I tested this PR (libogc2 PR 31) with an
unmodified dborth/libsmb2 on a real Wii. It still hangs on connect. I added
trace logging around net_read() on the SMB socket (line written before and
after each call). Excerpt:

net_read(len=4) calling -> = 4
net_read(len=64) calling -> = 64
net_read(len=74) calling -> = 74
...
net_read(len=16) calling -> = 16
net_read(len=4) calling (no result for ~55 s)

So all PDUs of the connect are received correctly, and then the extra read
that libsmb2 does at the end (it reads until EAGAIN) blocks in
net_read()/net_recvfrom() instead of returning -EAGAIN, even though the
socket is non-blocking. Block splitting doesn't change that.

What worked for me (dborth/libsmb2#2): call net_select() with a zero timeout
before net_read() and return -EAGAIN if nothing is readable. It would be
nicer to fix this in libogc2 itself (net_recvfrom() on a non-blocking
socket should return -EAGAIN when no data is pending), but I don't know
whether IOS reports that or whether the flags need to be passed on. Happy
to test patches.

[dborth]

f0a7627 fixed this, I'm closing this PR.

I helped @TeleTubby666 to track this remaining problem down. that one was a libsmb2 issue - it was pulling in the wrong header so FIONBIO was wrong - so depending on the build the socket wasn't non-blocking. submitted upstream to sahlberg/libsmb2#495

[Extrems]

Technically I wasn't done with this, but I suppose the outcome is the same.

That header doesn't come from the toolchain, but rather from libwiisocket, which I would've preferred you to use.

[TeleTubby666]

Some data from real Wii hardware that may be relevant for deciding on this PR.

I originally reported the "can't list a large directory" problem (dborth/libsmb2#2), and I attributed it to the 64 KB net heap. It turned out that the main cause was different: libsmb2's FIONBIO value did not match libogc2's net_ioctl(), so the socket stayed blocking. That is fixed now in sahlberg/libsmb2#495.

With that fix, I retested using libogc2 master as of Oct 19 (f8f62e1, without this PR) and the same share. The directory that previously failed ("Nintendo - Super Nintendo Entertainment System/", it produced a 65424-byte read request in an earlier trace) now opens without problems.

So for my use case this PR does not seem to be needed any more. I cannot say if there are other cases (very large replies or writes) that still need the transfer split. The trace for this run does not show the read sizes, so it is not a proof.

Not tested: GameCube and plain libogc.