Tatsunoko vs Capcom support? Here's a pcap file to help maybe. #29
Comments
|
Have you tried playing Tatsunoko vs Capcom on our server? From what I can tell everything seems pretty standard in this packet dump, so it might work without any additional changes. If you've tried playing TvC on our server and it didn't work, could you please provide a pcap file of that, too? Thanks. |
|
Cool, I'll try it out. Looks like the DNS server is down at the moment. |
|
The DNS server is 75.127.5.215, not 75.127.5.21 |
|
Oh! sorry about that, it works now. |
|
nas.nintendowifi.net's POST /ac returns 404 on your server, https://www.cloudshark.org/captures/cb0be7af11db The shows on screen: """" """" From older records, this is what I got from the official servers. Note that until recently(?), http://nas.nintendowifi.net was accessible on port 80 so I was able to patch the game with riivolution to go there without SSL and watch all the NAS communication between the game and the official NAS server. You can still use the server via SSL at this moment: I should probably note that I'm not using your NoSSL patch because my Wii doesn't have the homebrew channel. I only put Riivolution on it via smashbros custom-stage exploit a long time ago... but I no longer have smashbros disc. So I use network-redirection to send all the UDP port 53 packets coming from my Wii to your DNS server and my TVC-specific noSSL patch to produce the pcap file I linked to above. If I were to alter my Wii's DNS settings in the WiiMenu it'll attempt the connection test which apparently will fail according to your wiki. |
|
Hello again, I guess I could start doing pullrequests to you folks, but just so you know... https://github.com/polaris-/dwc_network_server_emulator/blob/master/nas_server.py#L260 That line of code cannot handle how Tatsunoko-vs-Capcom does things. In the network capture I pasted above, note action=bG9naW4%2A ...that "%2A" is an equal-sign. So the first thing that should happen is a .replace('%2A','=') for all parameter values. |
|
Try if it works now. |
|
Same thing as before; 404. |
|
Are you sure you tried the right server just now? I don't see any hits in the logs for the NAS server for TvC. Edit: Oh wait, 404. I think I might see your connection in the error logs for Apache. I'll have to look into it more. |
|
Checking... |
|
I just noticed something weird about the packet capture you posted before. For some reason your game is trying to connect to nas.nintendowifi.net (which should still be a valid server), but I think there might be something weird going on with your game. Either the way you have everything configured or something. Anyway, I made the necessary changes to Apache that should allow you to connect now. |
|
Oh yes, you're right.... an unpatched TvC will actually go to naswii.nintendowifi.net ...I had to patch it to go to nas.nintendowifi.net because on that server, port 80 was open, so I sent the game there to watch all of its NAS communication unencrypted thus allowing me to have that capture log above. Trying..... this might be awhile, my Wii has issues from when Wii Connect24 Overheating issues toasted it. Every once in awhile it freezes up and it just decided that now would be one of those times. |
|
Okay, 200 OK response this time but the game complained with error code: 60000. https://www.cloudshark.org/captures/767c3fc3c9e2 One thing that immediately jumps out at me is your server's response content-length versus my logs of the official server |
|
60000 is a user profile error, delete your save and try again. |
|
https://www.cloudshark.org/captures/f7ea3ddab8f6 Okay, after removing my savedata and allowing the game to recreate it(game refuses to go online without creating savedata) the game moved further into the online process. The game showed "downloading data...", which is past the naswii server auth. But after awhile I get a generic "Communication error" with no error number. Normally during the "Downloading data..." phase, the game is doing the following for every profileid on my friends & rivals list after first fetching the profileid of my own savedata(XOR'ed "encryption"): I'm trying to see what the difference is between the pcap I just captured on your server versus the official server's pcap file I posted in my original comment that has me going online and completing a match against a random person online in FreePlayer mode. |
|
I'm not sure, but the emulation of gpcm.gs.nintendowifi.net doesn't quite match what the official server did for the game. But it could be that I no longer have buddies since erasing savedata Filtered packets of official server: Versus the emulation-server: Packet 69 of official server's response to \login\ differs from how the emulation-server responded in packet 49. Still looking for other stuff since I'm kinda thinking that if the game was able to reply the emulation-server(packet 65 in emulation-server capture) then the game isn't confused and still going forward. |
|
Ah, I see what the problem there is. I made a mistake in the code earlier when I added in the response for blk and bdy. I fixed it and updated the server. Try again whenever you can, please. |
|
Looking at your packet captures again, you actually have a lot more buddies than I could find a packet capture of before. I made an assumption before that seems to be incorrect, so that should be fixed now too! Thanks for the packet capture from the official server. :D That problem is now fixed, too. |
|
Heh, no problem. :) Let's see, now I get: Error 61010 Looks closer to official but not exactly. After \login, Gamespy responds with "\blk\0\list\final" Check out my python script's output(http://pastebin.com/raw.php?i=38uGiwY4) This script still works as of this moment. The pastebin will expire in 1 week. EDIT: tvcsecrets.gpcm_response code is... |
|
Oops. I've removed the id fields now. Those were copy/paste leftovers. :P Could you upload another packet capture of you using the altwfc server now if it still doesn't work? |
|
Generic "Communication Error" The response for \login\ on the official servers contains a \proof\ field =^/ ...that's kinda scary 'cuz I'm not entirely sure how to generate that. Checking Luigi Auriemma's docs... |
|
Ok... The file: gs_login_proof.h That's probably it. I'm testing it to see if I can produce the same proof hash as the ones in my various pcap files. And for TvC, anytime Luigi mentions user's password it's usually the decoded challenge that comes back from the action=login sent to the naswii EDIT: ....oh wait... https://github.com/polaris-/dwc_network_server_emulator/blob/master/gamespy/gs_utility.py#L93 Okay, trying... EDIT2: Hooray! That code really works. Just need that hash in a proof field in the response. |
|
Try again, please. I think I found the error (it was never sending the return data from the getpd command). |
|
Excellent. TvC now goes online all the way. Error 84020 while searching for an opponent. I'm going to need to find somebody out there so that 2 of us can be searching at the same time and actually find each other for an online fight. But still, even if I'm the only one online the official servers wouldn't error so I'll be examining the packets for differences. |
|
Another TVCplayer tried using the server with Brainslug debugging console enabled. Looking at it I noticed that it didn't appear the game was getting responses to opponent-search. Indeed... So for sure the emulation server should allow Luigi's program to work. |
|
Looks like you're working on it, I see the emulationServer beginning to reply to the gslist program and TvC no longer gives me 84020. It just searches forever(so far over 20mins). fyi, The WII freezes up if you send it too much data for a response. In the query, the game specifies the max result rows it can handle - the official servers obeyed that limit. See screenshot highlighting the byte in question. The byte I highlighted in green shows that TvC can only handle 6 records returned to it. Go over that(about 8 or 9 records) and the game freezes. Here's what mariokartwii looked like to gslist Also, the info that's in the list comes from what the game sends to the master server in a UDP packet. |
|
More Info, I don't see any code in this repo for encrypting/decrypting player search in TvC's format. Luigi's C code above is how it's done for TvC. That code is pretty complex and porting to python would be quite a task. As such, I went the route of using SWIG to turn that code into something python could use without calling popen2 to run the program in a separate process. The variable playerlist will now contain a big string in the output format of the mariokartwii query in my previous comment. There is also an encrypt method. The arbitrarykey value is generated by the game randomly for each query; In the screenshot provide previously that particular query's encryption key is ?@(pBYzU , starting at offset 0x00000021 . The key will always be eight bytes. If you jump to 53min-mark in my youtube video, you can see me explaining how this works with code examples and official server data: If you need any assistance, I can provide the files shown in that vid so you can compile your own python module to support this part of the game. |
|
All of the games use the EncTypeX code for the server list response. it's in gamespy/gs_utility.py. So that's not the issue, I think. I think the problem is that the filter is empty in the query. My server doesn't handle that properly I guess. If you specify a filter it works properly. |
|
Oh wow, that's quite a feat porting that C to python! Emulation-server is getting very close to supporting this game. Now the problem is that my Wii isn't returned in search results. When the opponent search begins the game tells master server new state info so other WIIs can find it as well. It's in packet # 164. I understand that the game filters itself out of the results with "dwc_pid != 2287" so it doesn't try to initiate a match with itself, but then I should be able find my WII with gslist using a different filter. After waiting at least 10 seconds go by while the game searches for opponents, and I left it to continue its search, I issued the following command with a custom filter that should have returned a record for my game. Once I verify that the above gslist command returns my WII as an available server, next will be actually starting an online battle and see how that goes. |
|
If you can get it to the point where it accepts packets from the natneg server then it should work I think. You're just barely a step away from getting it to work. All that's left is that natneg needs to give both clients packets so they can try connecting to each other. The next possible point of failure is that one or both of the clients do not have their network setup in a way that allows for the UDP ports to be opened as needed. If both clients can successfully communicate with each other then it should technically work, assuming the game doesn't disconnect you due to lag or something like that. |
|
okay, figured out how I solved the ICMP thing to capture the official servers. Even closer than yesterday, the two WIIs actually started talking to each other, just like the official-server pcap file, before getting generic "Communication error" after an abnormally long wait. Once again I'm comparing these pcap files to the official servers. EDIT: Just fyi, the IPaddress that begins with 50. in your server-logs is me. ...and both WIIs showed the message "Opponent found." So they're really both aware of what's happening. |
|
Hmm... potential difference. In the first pcap in my previous comment, packet # 335 to 349 . That little back 'n forth between my WII and the emulation-server that's a constant 115 byte UDP packets looks suspicious. In the official-server pcap, packet # 611 ...the UDP packet of 115 bytes is sent once by my WII and the natneg responds once with a 63 byte packet. After that it appears my WII just continues on to communicate directly with the other WII and the fight goes on. No more talk with the natneg servers. |
|
Alright. I've modified the server to respond properly during the 115 byte packet part. If the packet response is as expected and it still gives you a "communication error" then I think you should try playing with someone else since it's most likely a connection problem at that point. |
|
Closer, starting at packet # 273 Now I get opponent found and error 91010 at the exact time the Wii-to-Wii connection would have completed and both Wiis shown the player names of the match; e.g. "Bob vs. Alice". I see the change in the UDP packets to be a bit closer to the official-servers but the back-n-forth of 115-byte UDP packets still end up happening. It appears to me that the emulation-server's UDP reply, at packet # 274, is 62 bytes. One byte shorter than what is found in the official-server capture at packet # 612.... but then the emulation-server quickly follows it with a proper sized packet. It appears the WII asks again 2 more times or so.... then we're back to the 115 byte UDP exchange. Since this change altered what happened after "Opponent found" I'm feeling more confident that getting those UDP packets perfectly in sync with the official servers' pcap example will allow me to fight someone. |
|
I see the problem. I forgot to change the buffer sent to the client, even though I made the buffer. You'll have to wait for the server to come back up before it can be tested, though. :( |
|
Oh dear, Generic "Communication Error" after opponent found. Nothing jumps out at me as incorrect here, but I'll keep searching & trying... |
|
I think I see it. I had to decode the XOR data. The 2nd pcap file I mentioned, TCP stream starting at packet # 542 I don't see a reply to this getpd query. Also note that there's a 0x01 just before the "r" in record. That's normal, the game can ask for multiple things and it's delimited by 0x01. Here's an example of what the official servers did for this game. There's nothing about that record string that ties it to a profile id. I can take any other players record string and give it to any profileID; giving the target profileID all the online stats of the source profileID. |
|
I saw an exception at that point which stopped it from sending the response. I've tried fixing it. Please test the server again when you have a chance. |
|
I'm using python to test this. It appears that after I did a setpd to the profileID, getpd on the same id doesn't work anymore. I get socket timeout. The socket is set to wait 10 seconds. This probably is part of the reason we have to delete userdata everytime before going online. Before I got error 60000, but after removing the savedata from the official-server I just get a generic Communication error after a long wait unless I delete userdata. If I delete the userdata, the game will just do a setpd because it knows getpd can't have anything for a profileid that was just created. But if the game has userdata, it'll try to fetch the profileid's stats using getpd. The versus screen that comes after "Opponent found. Now connecting.." displays the player stats of both players, so the game needs getpd to work. |
|
Here's what it said when you did that: Did you not get that response? It should have been sent. You will only get a 60000 when the authorization step fails. I think that only applies to the profile server as well, not the gamestats server. So that's an unrelated problem. |
|
I did get a getpdr the first time, before I did a setpd... but after applying a setpd to a profileID, getpd no longer works for that ID. Also, I suspect that not sending back any record string will be a problem for the online match because that situation can never happen for the official servers. A new account would get a setpd applied to it at the beginning before reaching any of the online fighting options in the game's menu. I can upload my test code if that's needed. I've ran the test code a few times since this comment, so hopefully there's something on the server logs showing what's happening. |
|
Please upload your test code. |
And the module tvcsecrets is: |
|
Sorry about the typo in getpd That "dindex", ...the "d" should be removed. Even after fixing that, the timeout issue remains. EDIT: The setpd_cmd has the same typo. |
|
Oh wait.... the official game does "dindex"... how odd, I guess they're not typos then. |
|
It should work now. The problem was that TvC has a \ at the end of the data field, while all of the other games I've tested so far don't have a trailing . The trailing \ broke the parser so it wouldn't return the data. |
|
The test code still times out for me. I'll wait a bit; perhaps the server hasn't been restarted yet. |
|
Oh nevermind, it works. I forgot to put the extra "d" back into index for get/setpd. |
|
Hop on IRC if you want to get some test games going. I've got 2 people testing now. |
|
Great success, it works. Just did 2 matches in freebattle. Thank you for all the work.... if I find a bug somewhere else in the game I'll make a new ticket, but this issue is solved! 👍 |
|
Hello Polaris Yesterday I Tried to play TVC over Polaris, but didn´t get in it.........................have you made some changes or something in recent days??? That thing was awesome and working sharply, but no longer works?? Just want to know if Polaris will gonna be online anytime?? Or Nintendo banned you??? Thxs See ya Jonathan, JG |
|
There is no "Nintendo banned". None of this stuff is under Nintendo's control anymore. What happens when you try to go online? Error message? |
|
when I try to change settings to 75.127.5.215 don´t connect to anything!!! El Jueves, 21 de agosto, 2014 0:17:00, "smtddr @ youtube, twitter, twitch.tv, hackernews" notifications@github.com escribió: @jonydark |
|
...And the error message is? Step by step, what happens? Don't leave out any details. |
|
The server is down right now. Please be patient. |
|
OK I will. But honestly I don´t know what´s going on over Wiimmfi too who always is working and also TVC game is not working yet, at the time I get into "Wi- Fi Battle" and then "Downloading Data" it stays there and shows an error kind of: "error code 92070 Also I deleted my old FC but since 5 days is showing this error, the functionality and test I supposed have ended, so...............What the hell is going on?? Thank you!!! El Jueves, 21 de agosto, 2014 16:39:31, mm201 notifications@github.com escribió: The server is down right now. Please be patient. |
When my proxy server for TvC was running, a pcap file I used as research to figure out some things: https://www.cloudshark.org/captures/d94462c4f238 This is from the moment that the Wii goes online to finding an opponent in freeBattle mode I believe. Just thought I'd offer this up.
The text was updated successfully, but these errors were encountered: