Mudlet: La connexion à Nanvaent n'affiche pas l'écran de connexion

J'ai essayé de me reconnecter plusieurs fois de suite, et j'ai reçu le message activé MXP, puis un court délai, puis l'écran de connexion sans problème. Je l'ai fait environ 30 fois.

Ensuite, j'ai fermé et redémarré mudlet, et maintenant il n'affiche que le message d'activation MXP exactement comme décrit. Ensuite, j'ai essayé la même chose sur un autre ordinateur, cette fois en fermant simplement le profil, et la même chose ... l'avant-dernier essai a fonctionné, puis recharger le profil et la dernière fois cela ne fonctionne pas. J'ai enregistré les données qui sont passées (je me suis connecté via un proxy pour les enregistrer), et les deux côtés ont envoyé des données identiques la dernière fois et l'avant-dernière fois.

Le dernier paquet du serveur ressemble à un désordre sur les deux tentatives finales. Mais cela ressemblait toujours à un écran de connexion sur mudlet lors du dernier essai avant de recharger le profil. Je pense qu'ils ne négocient aucune compression, puis le serveur commence à compresser à ce moment-là, et peut-être que mudlet avait une raison de comprendre la compression avant de recharger le profil?

J'obtiens les mêmes problèmes décrits ci-dessus, mais je ne sais pas comment vous obtenir plus de données sur les raisons pour lesquelles cela se produit. J'ai trouvé nanvaent via MUDRammer sur mon téléphone et je voulais voir à quoi il ressemblait sur un client MUD de bureau moderne.

Les développeurs de Mudlet Core pensent-ils que l'une de ces négociations serait un problème pour Mudlet? Je ne vois plus de paramètre à désactiver qui pourrait aider ici.

#config telnet debug
#CONFIG {TELNET} HAS BEEN SET TO {DEBUG}.
#session nan nanvaent.org 23
#TRYING TO CONNECT 'nan' TO 'nanvaent.org' PORT '23'.

#SESSION 'nan' CONNECTED TO 'nanvaent.org' PORT '23'
RCVD IAC DO TERMINAL TYPE
SENT IAC WILL TERMINAL TYPE
RCVD IAC DO NAWS
SENT IAC WILL NAWS
SENT IAC SB NAWS 0 202 0 56
RCVD IAC WILL MCCP2
SENT IAC DO MCCP2
RCVD IAC DO MXP
SENT IAC WONT MXP
RCVD IAC WILL MSSP
SENT IAC DO MSSP
RCVD IAC WILL ZMP
SENT IAC DONT ZMP
RCVD IAC DO NEW-ENVIRON
SENT IAC WILL NEW-ENVIRON
RCVD IAC SB TERMINAL TYPE
SENT IAC SB TTYPE TINTIN++
RCVD IAC SB MCCP2
MCCP2: INITIALIZED
RCVD IAC SB MSSP
RCVD IAC SB MSSP VAR NAME                 VAL Nanvaent
RCVD IAC SB MSSP VAR PLAYERS              VAL 10
RCVD IAC SB MSSP VAR UPTIME               VAL 1588875912
RCVD IAC SB MSSP IAC SE
RCVD IAC SB MCCP1

 [===--------------===] E-mail : [email protected] [===--------------===]

                                 /\     
                                /  \                  __
                               / /\ \                /  \
                              / /  \ \               \  /
                             / /    \ \              / /
  ____________ ____  _____  /_/_  ___\ \ ____  _____/ /____________ _________
 (___________ /    \ \___ \/    \/  \ \ \___ \/  _  \/    \__   __/__________)
     (________\  \  \/  _  \  \  \   \ \/  _  \  ___/\  \  \ \  \ _______)
         (_____\__\_/\_____/\__\_/\____/\_____/\____/ \__\_/  \_/____)
                        / /              \ \    / /
                       / /                \ \  / /
  Use 'guest' if      /  \                 \ \/ / 
  you just want to    \__/                  \  /  
  look around.                               \/   

   telnet nanvaent.org                                  http://nanvaent.org/
 [===--------------===] E-mail : [email protected] [===--------------===]

Your rights may be disclaimed. Please type "help rights" after login.
PLEASE use the 'bug' command to log bugs you find.

@SlySven a mentionné qu'il pourrait regarder ça.

J'ai réussi à entrer (en tant qu'invité) en:

• désactivation de MCCP1 / 2 (option "Forcer la compression désactivée")
• la désactivation de MXP (option «Forcer la négociation MXP») ne semble pas être le problème
• la désactivation de GA (option "Forcer l'interprétation du signal telnet GA désactivée") ne semble pas nécessaire
• l'attente uniquement de LineFeeds ("fins de ligne UNIX strictes") ne semble pas nécessaire

MSDP et GMCP ont été activés bien que seul le premier ait été négocié et vraisemblablement utilisé.

• BTW les messages de débogage dans ce cas incluent:

Server sent telnet IAC DO TTYPE (24)
We ARE willing to enable telnet option TERMINAL_TYPE
WE send telnet IAC WILL TTYPE (24)
Server sent telnet IAC DO NAWS (31)
We ARE willing to enable telnet option NAWS
WE send telnet IAC WILL NAWS (31)
Server sent telnet IAC WILL MCCP2 (86)
WE send telnet IAC DONT MCCP2 (86)
Rejecting MCCP v1, because v2 has already been negotiated or FORCE COMPRESSION OFF is set to ON.
Server sent telnet IAC DO MXP (91)
We are NOT WILLING to enable this telnet option.
WE send telnet IAC WONT MXP (91)
Server sent telnet IAC WILL MSSP (70)
WE send telnet IAC DO MSSP (70)
MSSP enabled
Server sent telnet IAC WILL ZENITH (93)
WE send telnet IAC DONT ZENITH (93)
Server sent telnet IAC DO NEW_ENVIRONMENT_OPTION (39)
We are NOT WILLING to enable this telnet option.
WE send telnet IAC WONT NEW_ENVIRONMENT_OPTION (39)
Server sent telnet IAC WILL MCCP (85)
WE send telnet IAC DONT MCCP (85)
Rejecting MCCP v1, because v2 has already been negotiated or FORCE COMPRESSION OFF is set to ON.
MCCP version 1 starting sequence

Donc, ce premier message de rejet est faux ...

Dans le jeu, vous voudrez émettre les commandes termdetect off et term xterm car il ne semble pas reconnaître Mudlet xxx tant que client qu'il connaît et le dumb par défaut est pratiquement dépourvu de toute couleur / mise en forme. De plus, un examen de la liste who quand j'y étais indique qu'ils utilisent UTF-8 comme encodage de leur serveur (l'un des joueurs avait inséré un U + 202E {Right-to-Left Override } pour tenter d'écrire leur nom à l'envers - mais comme Mudlet n'est pas (encore) capable d'afficher du texte BiDi, il a juste montré le texte tel qu'il a été écrit - bien que mon analyseur de texte ait signalé sa présence dans le texte même si code juste étouffé dessus).

Fait intéressant, ils utilisent le mode clignotant (clignotant) pour que le piratage de Vadim pour faire apparaître que l' ITALIQUE apparaisse là-haut ...

Il semble donc que la négociation MCCP2 échoue - et que je vais devoir me rapprocher de certains octets que j'ai stockés dans un enregistrement de ce processus et voir si je peux comprendre ce qui se passe ...

Également lié à MCCPv1 à Nanvaent: # 3056

Cette:
disabling MCCP1/2 ("Force Compression off" option)
travaillé pour moi. Merci. Je ne savais même pas quoi faire pour tester.

J'ai une rediffusion de Mudlet n'acceptant pas la séquence de démarrage MCCP2 et j'ai décodé les octets de l'enregistrement jusqu'au point où MCCP2 est censé être démarré:

"ÿý" = 255 253 024
IAC DO TTYPE

"ÿýÿûVÿý[ÿûFÿû]ÿý'" = 255 253 031   255 251 086   255 253 091   255 251 070   255 251 093   255 253 039
IAC DO NAWS IAC WILL MCCP2 IAC DO MXP IAC WILL MSSP IAC WILL ZMP IAC DO NEWENV

"ÿúÿð" = 255 250 024 001 255 240
IAC SB TTYPE SEND IAC SE

"ÿúVÿðxÚúÿË" = 255 250 086 255 240 | .....
IAC SB MCCP2 IAC SE | ...

Cependant, en y répondant (dans une version temporaire de la branche de développement actuelle qui pré-stockait tous les morceaux de données de relecture), j'ai remarqué que le code d'activation MCCP1 / 2 (les octets décodés de la dernière ligne) n'était pas atteint dans le débogueur . Je vais donc regarder de plus près le chemin d'exécution tout en répondant à ce qui précède ....: mag_right:

Eh bien, c'est tout simplement bizarre - avec MCCP 2 (ou probablement 1) activé - les données sont envoyées à Mudlet comme il se doit - mais elles ne parviennent

Pour info, je ne peux plus me connecter à nanvaent.org en utilisant une combinaison des paramètres ci-dessus. Pas sûr de ce qui se passe.