Journal = crash client

[sahisahi]

Hello im using client 6.0.0.0 for some reason when a player open the journal client crash, it doesnt always happens, but most of the time, anyone knows what can be the issue? uo.cfg?

We use uosteam and uorazor in our server it happens with both programs, so i think it has to do with the uo version we are using/ client

This is what the event log from windows shows:



Faulting application name: client.exe, version: 6.0.0.0, time stamp: 0x4631a0fb
Faulting module name: client.exe, version: 6.0.0.0, time stamp: 0x4631a0fb
Exception code: 0xc0000005
Fault offset: 0x00113617
Faulting process id: 0x1280
Faulting application start time: 0x01d3f599b4b5a797
Faulting application path: C:\Ultima Online\client.exe
Faulting module path: C:\Ultima Online\client.exe
Report Id: dd8baa7f-619d-11e8-a87e-d050991a679e

 

[Juzzver]

there may be a problem with the client and incompatible data that the server sends to the old client. When the client is crushed, a log should be created in the root folder, I do not remember the name, it seems Packets.log, perhaps its contents may be useful.

 

[sahisahi]

So if 0xF0 is a movement packet why its crash the client when i open journal?

im using runuo 2.2 and client 6.0.0.0

Ive tried to use different 6.x clients, still same issue


Everytime someone crash it generates a line inside packets.log file similar to this one:


https://pastebin.com/Ku7L4SF6

there are some xmlspawner syntax also it shows some part of my players acc passwords

heres all i found about 0xF0

I saw a thread that talks about razornegotiator and packet 0xF0 so i disabled razornegotiator.cs, journal still crash.




Re: Blocking Razor

• Quote

Post by Korbedda » Fri Dec 14, 2012 4:07 pm

It works like this:
IF client uses Razor AND has the negotiate feature enabled, it will react to a 0xF0 packet from server. The packet is:
BYTE[1] 0xF0
BYTE[2] length (0x000C)
BYTE[1] 0xFE
BYTE[8] features to disable (for respective OR-ed values see this RunUO script)

If you have Razor running, it will prevent this packet from getting to the client (which crashes on unknown/malformed packets). But only if you have negotiating enabled, it will block respective features and answer with a 0xF0 packet. So you can never know whether the client uses Razor or not. You can only detect Razor with negotiating enabled and then block the features you do not want. But you will have to require all players to use Razor with negotiating enabled so you can disconnect all players who have not responded to the 0xF0 handshake. The problem is that you cannot tell whether the player uses Razor without negotiation or uses only the client (okay, if they do, they crash, but you probably want them to play ). The only way is to either make a custom client or at least a customized application through which to run UO. This application then could detect Razor client-side and tell the server whether to use the handshake.





Design State Detailed

Server sends to client design data: tiles and stairs in compression mode. OSI uses ZLib.dll with Z_DEFAULT_COMPRESSION compression level.

Flags = (((Size >> 4) & 0xF0) | ((Length >> 8) & 0xF)) )


0x4000: new movement packets 0xF0 -> 0xF2


MessagePump.cs

private bool CheckEncrypted(NetState ns, int packetID)
{
            if (!ns.SentFirstPacket && packetID != 0xF0 && packetID != 0xF1 && packetID != 0xCF && packetID != 0x80 && packetID != 0x91 && packetID != 0xA4 && packetID != 0xEF) {
                Console.WriteLine("Client: {0}: Encrypted client detected, disconnecting", ns);
                ns.Dispose();
                return true;
            }

Packet Name: Krrios client special
Last Modified: 2009-03-02 05:22:34
Modified By: Turley


Packet: 0xF0
Sent By: Server
Size: Variable


Packet Build
BYTE[2] len
BYTE[1] subcmd
BYTE[len - 4] data


Subcommand Build
N/A


Notes
Subcommand 0: Acknowledge login (1 byte (for 5 total))

BYTE[1] ack (0 = Rejected, unauthorized. 1 = Accepted, GM priviledges. 2 = Accepted, player priviledges)


Note: GM priviledges unlock movement rate configurations

@Voxpire i summon you!

Thanks

 

[Voxpire]

The packets.log won't help in this case because the crash is happening when the client receives a known packet from the server; packets.log is a client-to-server log file for logging unhandled packets.

As for the assistant handshake, even if you don't use feature negotiation and the handshake request is sent to an unassisted client, the client won't crash unless there's an issue with the server-side encryption support (if any required).

6.0.0.0 is likely very unstable, I couldn't begin to presume what is causing the journal crash, all I can do at this point is recommend dropping down to 5.0.9.1 because that version was one of the most stable (IMO) at the time.

 

[sahisahi]

I tried 5.0.9.1 it still crash, also every client from 6x to 7x, same issue