Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix socket poll events values #542

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

DaniElectra
Copy link

@DaniElectra DaniElectra commented May 4, 2024

The write flags for poll events were wrong, 0x8 is used for POLLWRNORM / POLLOUT and 0x10 means POLLWRBAND. These values closely resemble the Wii sockets, though not all values are the same. The reverse engineered sysmodule shows that flags 0x4, 0x40 and 0x80 aren't returned in any code path, even though the sysmodule sets 0x40 and 0x80 along with 0x20 on the input events, which should mean error flags.

The values have been verified when reverse engineering the socket sysmodule, and has been tested with various applications:

  • mbedtls
  • curl
  • Luma3DS (gdb stub)
  • ftpd

@mtheall
Copy link
Contributor

mtheall commented May 4, 2024

This doesn't work for POLLPRI
When data comes over OOB then 0x01 and 0x02 are triggered but not 0x4

This means it breaks ftpd's transfer cancellation mechanism

The wiki says:
POLLPRI: Urgent data can be read.
but I have verified that 0x2 is triggered (not 0x4) when the TCP message has the URGENT flag set

0x08 and 0x10 are both set when the socket is writable, so I will assume those are POLLWRNORM(POLLOUT) and POLLWRBAND respectively as you have written

I haven't been able to find any situation that triggers 0x04, 0x20, 0x40, or 0x80

If 0x80 truly is POLLNVAL then libctru should totally prevent that because of the newlib/ctru fd translation. If it's not a valid ctru socket descriptor then it will fail to translate and return ENODEVICE (the whole poll() fails)

@mtheall
Copy link
Contributor

mtheall commented May 4, 2024

I think it would probably be acceptable if

#define POLLPRI (POLLRDBAND | 0x04)

@DaniElectra
Copy link
Author

Upon further inspection I can't find any path in the code that can trigger 0x04, 0x40, or 0x80. POLLNVAL is also 0x20 indeed, that is my bad.

The write flags are probably right, since when flag 0x10 is set, flag 0x8 is always set too. And on UDP the only revents returned are either 0x1 (POLLIN) or 0x9 (POLLIN | POLLWRBAND)

Surprisingly, the module adds 0xE0 on the input event flags even though there doesn't seem to be a path to trigger 0x40 or 0x80

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants