encryption/decryption, or rather packet issue

Elfu

I have strange problem with encryption/decryption.
Sometimes (seriously total random with/without razor | with/without uosteam ect. | with EC client/classic client) on client login, server hangs "him" on veryfication and from that point no other client can log in - need to restart whole server.

Other than that everything works perfectly - no exeption, no nothing.
If players are online when it happens they can still play as if nothing happens - everything works exept no new clients can login till server restart.

Im using now newest 7.0.45 / 4.0.45 [EC] client. I think it doesn't happen with older clients versions like 5.x.x.x classic ect. but cant be sure becouse its so random.

I can't give you even any code to look at cose there are no exeptions and all works fine till it happens (and even then no exeption ect.).

Using wireshark/spyuo i tried to identify "bad packets" with some effect but its really hard thing to do in so rare and random occurrence of problem.

Anyone had any similiar problems ? Any advices ?
 
Last edited:
By "him" do you mean that this happens on the same user logging in - like someone is sending bad packets, but only that one user, or do you think it happens on multiple different people during log in?
 
also there is an question if windows/linux-mono builds of the same server are "comparable" in terms of this problem :
just minute ago i was able to make it hangs few times in row on my locale machine (windows) when i was using newest razor (1.0.14.7 razor build) and had 2 uo-razor clients running,
1. I login on first account with client no. 1.
2. Then when I was trying login on other account with client no. 2 it hanged on verification and from that point no other client could login.

I tried this exact process with uosteam instead razor and everything was ok (but it didn't prove that it can't occure with uosteam).

On linux-mono build its rare even when i try exact same process with razor.

What I know now for sure is that with 2 razor-clients from the same machine and server on locale machine(windows) it happens more or less 80% times.... and that make no sense becouse in theory razor shouldnt send any of his own/other packets than simple uo client, right ?

Might it be razor related issue with newest clients ? Maybe something with .NetFramework ?
I really have no clue WTF right now ...
 
Last edited:
Since this is the first time I have heard this happen and because it resembles it so much I am going to go ahead and say this is a firewall issue. Do you have a firewall setup on your PC? Also, there may be a firewall on your router.

Firewalls on routers are usually not worth using as they are fluff that the manufacturer adds as a selling point. Unless you have a top of the range router that is.
 
its not firewall issue or rather if it is its really bizzare cose client is connecting i see it in log. ->
INFO - Client: 127.0.0.1: Connected. [2 Online]

but i see it hangs on veryficatio screen

In core there are files Listener.cs and NetState.cs and now im pretty sure that issue is related with do {}while loop in
Receive_Start() in NetState.cs or Accept_Start() in Listener.cs

somehow it never leaves the loop and it gives me idea that might be related to mono/framework bugs... or system configuration ect.
 
Last edited:
Elfu said:
I have strange problem with encryption/decryption.
Sometimes (seriously total random with/without razor | with/without uosteam ect. | with EC client/classic client) on client login, server hangs "him" on veryfication and from that point no other client can log in - need to restart whole server.

Other than that everything works perfectly - no exeption, no nothing.
If players are online when it happens they can still play as if nothing happens - everything works exept no new clients can login till server restart.

Im using now newest 7.0.45 / 4.0.45 [EC] client. I think it doesn't happen with older clients versions like 5.x.x.x classic ect. but cant be sure becouse its so random.

I can't give you even any code to look at cose there are no exeptions and all works fine till it happens (and even then no exeption ect.).

Using wireshark/spyuo i tried to identify "bad packets" with some effect but its really hard thing to do in so rare and random occurrence of problem.

Anyone had any similiar problems ? Any advices ?
Click to expand...
I too have seen this happen several times in the past. I just chalked it up to a network issue (bottleneck somewhere, etc). Restarting the server fixed the issue though and it hasn't happened for quite some time (years now).
 
This can occur when using a client version that has a unique encryption key that for whatever reason razor (or whatever 3rd party client decryption you are using) doesn't actually work. Ive seen this happen on quite a few random versions of UO, usually patching to the next version causes it to go away.
 
The_Real_Jeff said:
This can occur when using a client version that has a unique encryption key that for whatever reason razor (or whatever 3rd party client decryption you are using) doesn't actually work. Ive seen this happen on quite a few random versions of UO, usually patching to the next version causes it to go away.
Click to expand...
Thanks Jeff, for your insight :)
 
;] Thx Jeff. You were right - I forced all players to patch to max 7.0.45.0 (by setting min version) and problem solved. Some cliens in versions between 7.0.30 and 7.0.44.x were responslible for that strange issue - still dont know why but since noone will login with "bad version" anymore I won't loose my sleep over it :p
 
It's because the encryption key is at a specific address, razor looks for it at this address and sometimes when compiling native applications the addresses, or searches to find that specific address can come up short. The UO client now (since like 6.0.+ something) has used a encryption key based on the version number, but no decryption algorithms have been created or modified to work in this manner. Probably because for the most part the old methods work fine ;)
 
You must log in or register to reply here.
Back