You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When formatting screenname with an AIM client running 4.1 or 3.5, it appears successful but the client is disconnected due to a FLAPFrameSignoff.
Deployment Environment
Retro AIM Server Version: dev, c9edc69 . Also tried release binary of 0.11.0.
Installation Method: cross-built from source on MacOS targeting Linux/x86_64
Client(s) Used: AIM 4.1.2010 on XP, AIM 3.5.1808
Other Relevant Details:
Steps to Reproduce
Sign on with AIM 4.1.2010, or 3.5.1808
Format the screenname
Observe that it appears successful - you get the success dialog box, but buddies will see it sign off and the server logs/pcap show the client disconnecting.
In a few cases I wouldn't even get the format screenname dialog box.
Expected Behavior
I do not expect the client to disconnect. Formatting works on client versions 4.2 or newer.
Actual Behavior
Client disconnects
Troubleshooting Data
In the trace logs I can see the AdminInfoChangeRequest come in and the server replies with the AdminInfoChangeReply which appears to cause the sign off. Perhaps the client is expecting something else in the response? I did try a change where the response does not include wire.AdminTLVScreenNameFormatted TLV but that did not fix the issue, the client appears to hang in that case.
Subject of the Issue
When formatting screenname with an AIM client running 4.1 or 3.5, it appears successful but the client is disconnected due to a FLAPFrameSignoff.
Deployment Environment
Steps to Reproduce
In a few cases I wouldn't even get the format screenname dialog box.
Expected Behavior
I do not expect the client to disconnect. Formatting works on client versions 4.2 or newer.
Actual Behavior
Client disconnects
Troubleshooting Data
In the trace logs I can see the
AdminInfoChangeRequest
come in and the server replies with theAdminInfoChangeReply
which appears to cause the sign off. Perhaps the client is expecting something else in the response? I did try a change where the response does not includewire.AdminTLVScreenNameFormatted
TLV but that did not fix the issue, the client appears to hang in that case.The text was updated successfully, but these errors were encountered: