Crossfire Forum

I am using debian stable, with the server version 1.6.0 installed. I have been using the debian crossfire-client-gtk package (version 1.7.0), but this client would eat up all the memory and bring my X session to a grinding halt if I played on more than a map or two without closing and restarting the client. Looking at bug reports, it seemed this problem would be resolved by upgrading the client. However, I ran into a problem, as explained below.

I downloaded and compiled the most recent client (1.9.0), producing both the basic x11 and GTK versions. The GTK client starts normally, but could not connect to the 1.6.0 server, with the following errors:

[ INFO ] (common::VersionCmd) Playing on server type Crossfire Server
ReadPacket got an error.: Connection reset by peer
[ INFO ] (gtk::event_loop) gtk_main exited, returning from event_loop

The server log gives the following:

. . .
Get SetupCmd:: extendedTextInfos 1
SendBack SetupCmd:: setup extendedTextInfos 1
Bad command from client (toggleextendedtext)
Waiting for connections...

Rather than handling the unknown command gracefully, the connection seems to be terminated (not sure if by the server or client). However, the x11 client DOES NOT have this problem- it connects to the server without problems.

I downloaded the 1.8.0 client and found the same: the GTK client fails to connect (with the same errors), while the x11 client works fine.

Is this a bug that the GTK client appears not to be backward compatible (while the x11 client is)?

erm, i would say theres a bug in the x11 client... id upgrade your server, might be less trouble...

actually this appears to be an effective (as opposed to intended or planned) break in the protocol.

extended text was introduced somewhere between 1.7 and 1.8 to allow clients to better format text messages sent to the server, this can be seen in the new look login dialogues, and when applying signs and notices that support it.

however, it appears that the 1.6 servers don't like the commands used to negotiate this feature. - because no one really uses these servers anymore, this problem has gone unnoticed.

cfclient has never supported extended texts, so it doesn't try and negotiate them.

It isn't quite clear what the 'proper' solution to this issue is, other than to not run such an out-of-date server. - debian stable generally won't change the packages in use, and there are a great many clients out there that have this issue.

The only ways I can see to do it are:
1) add a new setup flag to tell whether to send the negotiation packets - but this would break existing servers.
2) change the protocol version numbers and drop connections with a proper explanation (but this wouldn't work with clients up 'til now)
3) stop all servers earlier than 1.7 from using the metaserver (although this doesn't address the issue of a local server as in this case)
4) write a small patch to crossfire 1.6 to fix the problem - but debian stable won't take it

from a technical point of view, 4) is the correct solution, I'm just not sure it can be implemented.

I went back and tried version 1.7.1 of the client. This worked fine and did not have the apparent memory leak problems of the 1.7.0 version in debian stable. My problem is solved, since I am fine using the older version of the server (I'm not a linux guru and am not sure how nice a self install of the server will play with debian).

I will note here for anyone interested that I first tried installing the client package from debian testing (now version 1.9.0) on my debian stable system. Unfortunately, the testing package requires a newer version of libc6 than available under stable; upgrading libc6 to the version in testing led to several other incompatibilities, such as with base-config (the configuration program for installing debian, maybe not so necessary to keep now that debian is already installed). To avoid this issue, I went with building my own client, leading to the issue in this thread. Funny, though, is that the 1.9 client builds fine on my system with the older version of libc6.

Just FYI, I did notice something that appears not to work in the build process for the 1.7 and 1.8 clients. For the configuration when compiling the client, I included an option --program-suffix=-1.7 (or similar) so I could have multiple client versions to compare. This option seems to be ignored for 1.7 and 1.8 (yielding cfclient and gcfclient only), but works correctly for 1.9 (yielding cfclient-1.9 and gcfclient-1.9). I am completely fine with this bug being ignored since probably very few people would want to use one of these older clients (and with this particular option); you probably much prefer to be working on the newest version of the game than making backfixes (I would too).

CS wrote:I went back and tried version 1.7.1 of the client. This worked fine and did not have the apparent memory leak problems of the 1.7.0 version in debian stable. My problem is solved, since I am fine using the older version of the server (I'm not a linux guru and am not sure how nice a self install of the server will play with debian).

As I understand it, they do some special hacks in /etc/init.d to make crossfire a thing that can be run by the startup scripts. - other than that, I think it is fairly standard (but then I do not use debian)

CS wrote: I will note here for anyone interested that I first tried installing the client package from debian testing (now version 1.9.0) on my debian stable system. Unfortunately, the testing package requires a newer version of libc6 than available under stable; upgrading libc6 to the version in testing led to several other incompatibilities, such as with base-config (the configuration program for installing debian, maybe not so necessary to keep now that debian is already installed). To avoid this issue, I went with building my own client, leading to the issue in this thread. Funny, though, is that the 1.9 client builds fine on my system with the older version of libc6.

I think that is more a debian/glibc issue than anything else, there are no strict limits of glibc versions for crossfire, although some stupidly old versions are doubtless broken (although if you are using slackware 4 to compile on nowadays, then I think you probably /deserve/ to have breakage.) However, the glibc ABI has changed at various times, and you may well have two versions either side of a compatibility break.

CS wrote: Just FYI, I did notice something that appears not to work in the build process for the 1.7 and 1.8 clients. For the configuration when compiling the client, I included an option --program-suffix=-1.7 (or similar) so I could have multiple client versions to compare. This option seems to be ignored for 1.7 and 1.8 (yielding cfclient and gcfclient only), but works correctly for 1.9 (yielding cfclient-1.9 and gcfclient-1.9). I am completely fine with this bug being ignored since probably very few people would want to use one of these older clients (and with this particular option); you probably much prefer to be working on the newest version of the game than making backfixes (I would too).

The autoconf/automake stuff was fixed by mwedel in the client tree soon after the 1.8 release, presumably that all came in then.

Whilst I suppose the autoconf changes could be moved across and a new release made with relative ease, it would have the distinct disadvantage of encouraging players to actually /use/ them; it is generally far better to keep everyone fairly up to date (except debian, but debian is speshul in that respect )