continuum upgrade is busted
expected behavior:
log in on .39pr1: Your version of Continuum blah blah you need to upgrade. [yes/no?] yes: download upgrade.exe and run. no: allowed in the zone anyway, unless unauthorized (not sure the exact capability needed.)
actual behavior:
log in on .39pr1: Unauthorized: This server does not yet support your version of Continuum. Until this server is upgraded blah blah you suck [Ok]. Authorized: No prompt, allowed entry.
Also if upgrade.exe is downloaded (as 1.4.4 will do) it seems to send it with no file name, possibly crashing Continuum.
Comments (5)
-
Account Deleted -
reporter - changed status to open
Makes sense, a lot of other stuff had that exact problem when the global #pragma pack(1) was removed from the asss headers. Any idea about update.exe? It might just be a wine problem, but I know I'm not the only one who has had Continuum suddenly exit when downloading the file.
-
Account Deleted Fixing the alignment fixes the version bug for me. Logging into an unfixed ASSS will periodically work properly (when the client interprets the garbage byte as a higher version than itself) and other times do as you report (when the garbage byte is lower).
Re update.exe: Continuum is supposed to terminate immediately after it downloads and executes the update. And the server is supposed to send the update with no file name (an S2C_INCOMING (0x10) with NULL for filename). If it has a name, then it will still be downloaded, but Continuum will not execute it. The download dialogue will show progress on named files, but will sit there waiting for an S2C_INCOMINGFILE (0x10) that is unnamed -- which it saves as "ContinuumUpdate.exe" and then executes.
Also, the client will accept nasty named files -- like "profile.dat" -- and will overwrite anything precious in the Continuum folder with that name.
-
reporter Well, it's not news that Continuum's file transfer stuff is a little boneheaded. Judging by what you said though, it perhaps is a Wine problem where the update does not start, but everything else up to that point sounds correct.
-
Account Deleted - changed status to resolved
Applied patch in Wiki macro error: Changeset 3f84a34cf382 not found..
- Log in to comment
Continuum login response (s2c game packet 0x34) is sent sloppy inside src/core/core.c/SendLoginResponse. It needs to be byte aligned. On the wire, it ends up as 8 bytes instead of 7. Since this is how the server reports cont version and cont exe checksum, it may cause funky version bugs (since it includes a garbage byte).
The packet, which asss calls S2C_CONTVERSION, contains u8 type = 0x34 (packet id), u16 cont_version = 0x28 (40), u32 checksum = 0xc9b61486 (crc32 of con40.exe). Which would properly go to the wire as
but because SendLoginResponse does not byte align it, it slurps in a wildcard byte
Hard to say how cont is handling this, but it may cause some of the nastiness you're seeing.
Fix is simple: wrap the struct definition at line 769 with