IP/Top: Fix GetAddrInfo written socket

[sepalani]

This is the kind of PR where I'm not really sure of what I'm doing. Lately, the Netflix Channel was having issue with SOConnect() after a SOGetAddrInfo() call complaining about the socket family which was 0x10 a very odd value. I checked and it seemed that value actually was ai_addrlen so by swapping them around Netflix stopped complaining.

Maybe someone can confirm/invalidate the fact that this PR is performing the intended behaviour. @shuffle2 ?

With that, I'm able to get Netflix to its loading screen.

Ready to be reviewed & tested.

[shuffle2]

Here is a bunch of the related IOS code: https://gist.github.com/shuffle2/6f443352dbc09bcfe264faea1fc052aa
This PR is specifically inverting the order of the first 2 bytes of what I called in_addr4.

While this PR is correcting the behavior, it's because Memory::Write_U16 swaps the data. So it looks dumb/confusing because IOS HLE is putting 2 unrelated u8 fields together, then writing as a swapped u16.
I think the PR should be changed to use just Memory::Write_U8 on each field.

Note that the gist also shows that canonical name can be returned, which dolphin also doesn't currently handle. You may also want to look for other such cases that we should be handling.

[sepalani]

@shuffle2
Done. I'll throw an eye on that gist and will probably implement that in another PR.

[shuffle2]

@sepalani um... Did you test that? It looks like you have inverted the order again compared to my gist...

[sepalani]

I did. It's still working with latest #5507
Did I do something wrong?

[shuffle2]

from the gist:

00000000 in_addr4        struc ; (sizeof=0x8, align=0x2, mappedto_29)
00000000 len             DCB ?
00000001 family          DCB ?
00000002 port            DCW ?
00000004 addr            DCB 4 dup(?)
00000008 in_addr4        ends

which IOS version is netflix using?

[sepalani]

IOS56 according to Dolphin gamelist.

[shuffle2]

I checked latest IOS56 (0000000100000038 v5662). Code/struct looks the same.

[shuffle2]

what is the actual netflix code that caused you to suspect something was wrong here?

[sepalani]

It was creating a socket with the family value 0x10 which is the same value as the len. That's why I thought they were swapped. I wonder if that's due to #5497.

[shuffle2]

yea...16 is not an accepted family value, so something else must've been up (but is fixed now?)

[sepalani]

It seems so, that's why it's weird. It was a blocking point but I highly suspect that PR #5497 fixed it.