EternityRO | SVN | Timeout on Account server

[Mushroom]

Well, everybody knows that EternityRO only connects with version 2.0.5 so I tried to discover what was the file that is making kore not to connect.
I know it's something in the Servertype8.pm that is is src/Network/Send, because when I use the 2.0.5 file it connects and using the SVN version it doesn't.
I don't understand Perl, so I don't think i can see what is wrong in the SVN file, but I will upload each file so developers who understand it can analyze and solve the problem.

EDIT: lol, it was easier than I thought o.O
In ServerType8.pm from SVN, it doesn't have this lines

Code: Select all

sub sendMasterLogin {
	my ($self, $username, $password, $master_version, $version) = @_;
	my $msg = pack("v1 V", hex($masterServer->{masterLogin_packet}) || 0x277, $version) .
		pack("a24", $username) .
		pack("a24", $password) .
		pack("C", $master_version) .
		pack("a15", join(".", unpack("C4", $self->{net}->serverAddress()))) .
		pack("C*", 0xAB, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0);
	$self->sendToServer($msg);
}

And in Openkore 2.0.5 we have.
I don't know why, but putting this lines in the ServerType8.pm from SVN makes me connect n EternityRO using the SVN version :X

[Technology]

Good find.
btw, look at the bottom of the topic:
http://bibian.ath.cx/openkore/viewtopic.php?t=36072
revision 6150

I believe that inheritance of subs is a bad idea in some cases.
ex. serverType 8 inherits from 0, and 8_x's inherit from 8, wich inherits from 0. See where this is going?
fixing one serverType destroys another in some cases, like with eternityRO now.
Because making changes in the lower level serverTypes also affect those that inherit from them.
Look at the sendMasterLogin sub in serverType0.pm, wtf is that if(serverType == 4) doing there?
There should be a sendMasterLogin sub in serverType4.pm instead.
Not to mention the problem with current naming convention: in perl: 8_x == 8 !!!

Does the serverType system need to be revised to a better model?

[EDIT]
What about a tree like serverType system?

serverType 0 is a basic serverType (the trunk)
serverType 8 is a deviation on 0 (a branch)
serverType 8_4 is a deviation on 8 (a twig)
serverType 8_4_1 would be a deviation on 8_4 (only differentiating in sendMasterLogin in eRO case)

a serverType that deviates allot from 0 could be another basic serverType (trunk)

(comparisions are just symbolic for the size of the files and to show how making changes in the trunk will affect the rest of the tree)

[Technology]

It would be usefull if people that can, go record the masterLogin packet and post it up here.
Use faulty login info btw.
username: abcd
password: 1234

EDIT:
The login packet that you are using (0277) seems older than the one they use in their client (01DD) wich btw is also old.
Since eA seems to be supporting all login packets, there is no need for the secureLogin, wich would be used with the 01DD login packet.

[Mushroom]

Code: Select all

DD 01 8C A9 00 00 61 62 63 64 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 81 DC 
9B DB 52 D0 4D C2 00 36 DB D8 31 3E D0 55 10 

[sli]

Inheritance is the whole point of uses classes to begin with. Consider the alternative: rewriting/copy & pasting all the code for every servertype regardless of whether or not it changed. It's simply much easier to only write code that differs in some way from code already written.

[Technology]

Mushroom, thanks for providing the masterLogin packet, i now know how it is build up and i'm able to reproduce the original masterLogin packet that the client uses. (password is MD5 hashed, but not salted)

Inheritance is good, for the exact reason that you stated Sli.
But it has proven to have its own problems.

The problem of inheritance
But it can be bad aswell, because when someone changes something within a class where other classes inherit from,
the class that inherits could be affected aswell.
This effect should be taken in consideration. That is why we should look for a better method.

Suggestion for a method that solves the problem
What about from now we start with a serverType that we call serverType 0 (or whatever name), wich fully supports the packetversion that is used by the kro client today.
When tomorrow a packet changes/gets added, we make serverType 1, wich inherits the packets that didn't change from serverType 0. (but we never change serverType 0)
And so on...

Ennumeration system
Maybe the ennumeration could be improved aswell, to match a date, kro sakexe version, ...
So that the user can figure out wich serverType to use more easily. (for example: don't you get the sakexe version when you crash the RO client? If so, that could be a way to figure out wich serverType to use or to branch on for your server)
The serverType should also hold information about the RO client that it is supposed to emulate.

Why?
- the sakexe's packetversion is what is generally used for all private servers and is like the base of all other serverTypes, it is like the mother of all other packetversions.
- we never have to change any packet in a class where other classes inherit from (wich causes problems obviously)
- if a server differs only slightly from kro (and thus on the latest serverType), we make a branch on that serverType and when that server updates to a newer packetversion (wich differs only slightly from a newer kro version), we make a new branch based on the newer kro version
- we don't lose support for older packetversions

serverType support outside of the serverType container
Something else that we should do is not having anything thats server related outside of the serverType container.
Its bad how it is now:
- in serverType0.pm, there is support for other serverTypes
- in receive.pm, there is support for packets with different lenghts based on the lenght their serverType uses, while this needs to be in Network\Receive\serverTypex.pm
- in receive.pm, there is a packet with the same packetswitch as another packet

[Kees]

This goes way beyond EternityRO and I'm glad people are still willing to put time on developing openkore.
Problem is that it's not worth botting on EternityRO anymore. They're using openkore to detect your bot, and no not with a 'flagging system' Bibian suggested. You get banned without even knowing what or who hit you.

[Mushroom]

If they are abussing of openkore's bug, shouldn't this bug be fixed?
Because.... using openkore to ban bots it's kind fun lol

[Technology]

Well atm, kore is using a different masterLogin packet than their client (and possibly other packets too), that could be a way to determine if you bot or not.
They might say its an intruisive system, but how many servers obfuscate their data, to distract botters from the real problem?
I don't think we should give up that easily just yet.
Closer emulation of the client = win.