CrossTalk/azul
5
Fork 2
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions

3rd party Mac client testing (Adium and Mercury Messenger) #3

New issue
Open
opened 2026-07-01 02:01:53 -05:00 by CursedSilicon · 4 comments
CursedSilicon commented 2026-07-01 02:01:53 -05:00
Copy link

Hi team,

Tested some more MSN Messenger clients for Mac. Same setup as Issue #1.

Adium clients 1.0.6, 1.3.10, 1.4.5 and 1.5.10 all hang when connecting.

"Mercury Messenger" a Java based MSN client also hangs when connecting via MSNP11 mode. MSNP13 and MSNP14 are also offered but trigger a Java exception during connection.

Wireshark logs for all clients are attached below.

Hi team, Tested some more MSN Messenger clients for Mac. Same setup as [Issue #1](https://git.ugnet.gay/CrossTalk/azul/issues/2). Adium clients 1.0.6, 1.3.10, 1.4.5 and 1.5.10 all hang when connecting. "Mercury Messenger" a Java based MSN client also hangs when connecting via MSNP11 mode. MSNP13 and MSNP14 are also offered but trigger a Java exception during connection. Wireshark logs for all clients are attached below.
Adium 1.0.6 failure.txt
11 KiB
Adium 1.3.10 failure.txt
18 KiB
Adium 1.4.5 failure.txt
18 KiB
Adium 1.5.10 failure.txt
17 KiB
CursedSilicon commented 2026-07-01 02:02:57 -05:00
Author
Copy link

NOTE: Due to file type restrictions, the attached files will need to be renamed back to .pcapng to be opened in Wireshark

NOTE: Due to file type restrictions, the attached files will need to be renamed back to `.pcapng` to be opened in Wireshark
Doridian commented 2026-08-28 19:37:26 -05:00
Copy link

Digging into the Adium 1.0.6 failuere (I would assume similar failure modes on the other traces here).

The trace shows the USR TWN auth, and the response from the server. The client then contacts the "passport" server over HTTPS, which seems to fail, or get stuck.

Screenshot_20260828_160506

The first possible cause that instinctively pops to mind is HTTP keepalive being performed by the server without the client supporting it fully. And it then gets stuck with a dangling connection it expected the server to close.

Will run my own VM to trace down more soon, probably maybe ideally.

Digging into the Adium 1.0.6 failuere (I would assume similar failure modes on the other traces here). The trace shows the `USR TWN` auth, and the response from the server. The client then contacts the "passport" server over HTTPS, which seems to fail, or get stuck. ![Screenshot_20260828_160506](/attachments/c61f7e5f-bbcf-4baf-a35e-d80b450218fc) The first possible cause that instinctively pops to mind is HTTP keepalive being performed by the server without the client supporting it fully. And it then gets stuck with a dangling connection it expected the server to close. Will run my own VM to trace down more soon, probably maybe ideally.
Screenshot_20260828_160506.png
164 KiB
Doridian commented 2026-08-29 11:28:59 -05:00
Copy link

One issue is these old clients seem to be unable to do SNI, and also do not support the Host header, either. So, the azul listener must be the default host on 443 for the IP used for nexus.passport.com.

But even after this, auth now just gets stuck after the /rdr/pprdr.asp step,. instead of during, so more digging!

One issue is these old clients seem to be unable to do SNI, and also do not support the `Host` header, either. So, the azul listener must be the default host on 443 for the IP used for nexus.passport.com. But even after this, auth now just gets stuck after the `/rdr/pprdr.asp` step,. instead of during, so more digging!
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
prod
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
CrossTalk/azul#3
No description provided.