Emulator

Seeing how Nintendo WFC games will be shutdown soon anyways, I don't think there's any need to fix this.

Well, we are deveolping our own MKWii server: http://forum.wii-homebrew.com/board42-kreativitaet/board329-mkw-server-project-english/

And having a working emulator would help testing.

Is there any source code on this?

Can't reproduce it anyways. Wireshark always shows me my computer's local IP. Maybe this is Linux/OSX exclusive?

Source code is not public yet.

Have you looked in the MKWii packet containing the string "localip0"? In the normal Wireshark columns (source and destination) there is the correct IP. But in the packet itself I see 10.0.1.30 on Ubuntu.

Tomorrow I can test with Windows.

Is this still happening on the latest development version?

The local IP address is hardcoded in Dolphin, not sure how you could be seeing your PC's actual local IP (unless it's a public IP and the game is using a loopback test to determine it).
10.0.1.30: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/IPC_HLE/WII_IPC_HLE_Device_net.cpp#L1227
192.168.1.150: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/IPC_HLE/WII_IPC_HLE_Device_net.cpp#L857

It can't be a public IP. The Wii (Dolphin) writes the local IP into a packet. There is no loopback test. So the only thing why he could see his "real" IP is because he looked at the sender / receiver of the packet and not at the parameter "localip0".

How does this affect your server implementation, given the remote server shouldn't care what the client's private IP is?

Well, it does not effect our server, but also the Nintendo server.

This local IP is used if two clients are behind the same router - which happens when testing locally. Then, the packets are directly sent to this IP w/o using NAT Negotiation - and when one of the Clients uses Dolphin, this fails because of the wrong IP.

This would also happen on the official server, but there nobody has found that out again because there nobody plays with one Wii and Dolphin the same time.

But for server testing (without a second player) this is important.

Sounds like an excellent reason for it to be fixed but I'm glad I don't have to write the code to decide which local IP to use (maybe just return all of them? IOS supports it in theory...)

Oh, so the wii network protocol is completely broken with a second level nat?

iirc there is a way to fetch the local ip of an opened socket, so we could just use the first one.

The "protocol" is never broken, with two Wiis it works in all cases.

When both Wiis are behind the same NAT, they communicate using their private IPs, for example 192.168.178.22. So, the Wii also sends its local IP to the server that it can send it to the other client. And if Dolphin sends a wrong IP, it won't get packets from the other Wii.

Well, that explains why I never could play Brawl with my Wii when I was testing the branch.

iirc there is a way to fetch the local ip of an opened socket, so we could just use the first one

The problem is the IOS call used to get the local IP (SOGetInterfaceOpt/option 0x4003) does not take a socket as argument and can be called when there are no active connections. But it is allowed to return a multiple number of IP sets (IP+netmask+broadcast address) so in theory it could return details for each local adapter found in the host (so you don't have to worry about figuring out which interface is used), assuming you're careful enough not to overrun the output buffer.
This also assumes the extra interfaces will show up in the mkwii packets as localip1, localip2 etc...

That bug does still exist in 4.0-6759 - is there any chance for this bug to get fixed?

If it's too complicated to make Dolphin recognize the right IP, maybe put a field in the configuration where the user can set his local IP? Dolphin still uses "192.168.1.150" and makes local network play unuseable ...