Hi everyone, I'm having trouble establishing a BinkP session when my target is a MysticBBS.

The connection always terminates with an EOF (End of Connection). However, if the hub sends me a packet via crash, it works without any problems. Does anyone recognize this issue?

My system is a custom development, but it adheres to all BinkP protocol standards.

Here is a transcript of the connection:

10:01:53.806 SEND M_NUL VER NullModem-BinkP/0.32.3-dev binkp/1.1
10:01:53.806 SEND M_ADR 23:1/107@sysopnet
10:01:54.001 RECV M_NUL OPT CRAM-MD5-***
10:01:54.001 RECV M_NUL SYS Pweck's Retreat BBS
10:01:54.001 RECV M_NUL LOC Omaha, NE
10:01:54.001 RECV M_NUL ZYZ Dean Lodge
10:01:54.001 RECV M_NUL TIME Tue, 29 Sep 2026 05:01:49 -0500
10:01:54.001 RECV M_NUL VER Mystic/1.12A48 binkp/1.0
10:01:54.001 RECV M_NUL BUILD 2023/01/15 12:54:18 Linux/64
10:01:54.001 RECV M_ADR 21:3/113@fsxnet 316:36/32@whispnet 80:774/12@retronet 25:1/109@metronet 954:200/67@hobbynet 618:200/52@micronet 1337:3/130@tqwnet 46:10/167@agoranet 314:413/12@pinet 44:100/30@DoRENET 1:220/6@fidonet 23:1/1@sysopnet 7:130/1@realms 86:200/58@nixnet 3323:1/7@cheese
10:01:54.001 SEND M_PWD ***

Has anyone also such Problems?
Sorry Dean, i can reproduce it with your System...

Greetings Mike

--- NullModem BBS v0.32.3-dev
* Origin: Maiks Place BBS (23:1/107)

On September 29 2026, SwissMaik wrote:

Hi everyone, I'm having trouble establishing a BinkP session when my target is a MysticBBS.

The connection always terminates with an EOF (End of Connection).
However, if the hub sends me a packet via crash, it works without any problems. Does anyone recognize this issue?

My system is a custom development, but it adheres to all BinkP
protocol standards.

Here is a transcript of the connection:

10:01:53.806 SEND M_NUL VER NullModem-BinkP/0.32.3-dev binkp/1.1 10:01:53.806 SEND M_ADR 23:1/107@sysopnet
10:01:54.001 RECV M_NUL OPT CRAM-MD5-***
10:01:54.001 RECV M_NUL SYS Pweck's Retreat BBS
10:01:54.001 RECV M_NUL LOC Omaha, NE
10:01:54.001 RECV M_NUL ZYZ Dean Lodge
10:01:54.001 RECV M_NUL TIME Tue, 29 Sep 2026 05:01:49 -0500
10:01:54.001 RECV M_NUL VER Mystic/1.12A48 binkp/1.0
10:01:54.001 RECV M_NUL BUILD 2023/01/15 12:54:18 Linux/64
10:01:54.001 RECV M_ADR 21:3/113@fsxnet 316:36/32@whispnet 80:774/12@retronet 25:1/109@metronet 954:200/67@hobbynet 618:200/52@micronet 1337:3/130@tqwnet 46:10/167@agoranet
314:413/12@pinet 44:100/30@DoRENET 1:220/6@fidonet 23:1/1@sysopnet 7:130/1@realms 86:200/58@nixnet 3323:1/7@cheese
10:01:54.001 SEND M_PWD ***

Has anyone also such Problems?
Sorry Dean, i can reproduce it with your System...

Greetings Mike

--- NullModem BBS v0.32.3-dev
* Origin: Maiks Place BBS (23:1/107)

The failure breaks down to two specific details in the transcript:
1. Protocol Version Mismatch:
The client advertises binkp/1.1.
Mystic responds with Mystic/1.12A48 binkp/1.0.
Mystic BBSs internal BinkP daemon is strictly a BinkP/1.0 implementation.
2. Premature / Plaintext M_PWD:
Mystic advertises M_NUL OPT CRAM-MD5-... challenge data.
Immediately upon receiving this, the custom client sends SEND M_PWD *** (plaintext password) rather than responding to the CRAM challenge with an M_PWD CRAM-MD5-... digest.
When Mystic receives an unexpected, plain M_PWD or a frame sequencing it cannot parse while waiting for the cryptographic response, it drops the socket immediately, causing the remote client to see an unexpected EOF.
(Conversely, inbound crash polling from the hub works because Mystic handles authentication differently when it initiates the outbound session or relies on standard 1.0 logic).
How to fix it
Authenticate via CRAM-MD5: Update the custom client so that when OPT CRAM-MD5-... is received, it properly hashes the challenge with the pre-shared secret and returns the digest in M_PWD.
Downgrade handshake to binkp/1.0: Have the client advertise binkp/1.0 instead of binkp/1.1 when connecting to Mystic nodes to prevent version-negotiation quirks.

... The Adventure BBS (HTTPS://BBS.OURBIRDHOUSE.CA)

--- BinktermPHP v1.10.7
* Origin: The Adventure BBS (23:1/106)

On 9/29/2026 6:04 AM, Swissmaik wrote to All:

Hi everyone, I'm having trouble establishing a BinkP session when my target is
a MysticBBS.

The connection always terminates with an EOF (End of Connection). However, if
the hub sends me a packet via crash, it works without any problems. Does anyone
recognize this issue?

My system is a custom development, but it adheres to all BinkP protocol standards.

Here is a transcript of the connection:

10:01:53.806 SEND M_NUL VER NullModem-BinkP/0.32.3-dev binkp/1.1 10:01:53.806 SEND M_ADR 23:1/107@sysopnet
10:01:54.001 RECV M_NUL OPT CRAM-MD5-***

I see the asterisks next to CRAM-MD5
Do you have it on or off? Maybe try changing that setting and try again.
It's worth a try.

Mike Dippel

--- Platinum Xpress/Win/WINServer v10.0gr17
* Origin: The Hobby Line! BBS (23:250/11)

Hi Mike,

Thanks! The asterisks were only me masking the challenge in the post.
CRAM-MD5 is offered by the hub, and my mailer answers with a CRAM-MD5
digest, which Mystic accepts -- a wrong digest gets an explicit
"Bad address or password" instead of the silent hang-up.

But testing with plaintext is a good idea to rule CRAM out. I'll try
that and report back.

Greetings Mike

--- NullModem BBS v0.33.0-dev
* Origin: Maiks Place BBS (23:1/107)

Hi TheWebExpert,

Thanks for looking into it! Two notes though:

- The "***" was just my log masking every M_PWD. I've changed the log
so it now shows which kind was sent: the frame really is
"CRAM-MD5-<digest>", not a plaintext password. A deliberately wrong
digest gets an explicit "M_ERR Bad address or password" from Mystic;
the correct one is accepted, and then the hub silently drops the
connection.
- binkp/1.1 in VER only advertises capability; per FSP-1024 both sides
fall back to the lower version, and my mailer does. I also tried
advertising binkp/1.0 -- no difference.

Fresh transcript from today:

13:26:02.673 SEND M_NUL VER NullModem-BinkP/0.32.5-dev binkp/1.1
13:26:02.673 SEND M_ADR 23:1/107@sysopnet
13:26:02.862 RECV M_NUL OPT CRAM-MD5-***
13:26:02.862 RECV M_NUL SYS Pweck's Retreat BBS
13:26:02.862 RECV M_NUL LOC Omaha, NE
13:26:02.862 RECV M_NUL ZYZ Dean Lodge
13:26:02.862 RECV M_NUL TIME Tue, 29 Sep 2026 08:26:15 -0500
13:26:02.862 RECV M_NUL VER Mystic/1.12A48 binkp/1.0
13:26:02.862 RECV M_NUL BUILD 2023/01/15 12:54:18 Linux/64
13:26:02.862 RECV M_ADR 21:3/113@fsxnet 316:36/32@whispnet
[...] 23:1/1@sysopnet [...]
13:26:02.862 SEND M_PWD CRAM-MD5-***

connection closed by the remote side (EOF)

So auth seems to succeed and Mystic hangs up right after.

Dean, if you find a minute: could you check your Mystic log (mis.log /
binkp log) around 08:26 your time today, Sep 29, for 23:1/107? Whatever
Mystic says right after the password check would help a lot.

Greetings Mike

--- NullModem BBS v0.33.0-dev
* Origin: Maiks Place BBS (23:1/107)

Hi Mike,

Good idea, thanks -- I tried it. With CRAM-MD5 disabled on my side
(plaintext password) the result is exactly the same: Mystic sends its
banner and address list, receives my M_PWD, and drops the connection
without an M_OK or M_ERR. A wrong password, on the other hand, gets an
explicit "M_ERR Bad address or password". So the login itself seems
to be accepted, with or without CRAM, and Mystic hangs up right after.

Dean, two fresh attempts from 23:1/107 today (Sep 29, your time):
08:26 (CRAM-MD5) and 08:37 (plaintext). If you could look at your
Mystic log around those times, whatever it says right after the
password check would probably explain it.

Greetings Mike

--- NullModem BBS v0.33.0-dev
* Origin: Maiks Place BBS (23:1/107)

Dean, two fresh attempts from 23:1/107 today (Sep 29, your time):
08:26 (CRAM-MD5) and 08:37 (plaintext). If you could look at your
Mystic log around those times, whatever it says right after the
password check would probably explain it.

+ 2026.09.29 08:26:15 BINKP 1-R: PWD
+ 2026.09.29 08:26:15 BINKP 1-Client did not send address
+ 2026.09.29 08:26:15 BINKP 1-Client shutting down

+ 2026.09.29 08:37:47 BINKP 1-R: PWD
+ 2026.09.29 08:37:47 BINKP 1-Client did not send address
+ 2026.09.29 08:37:47 BINKP 1-Client shutting down

pweck
sysopnet 23:1/1
bbs.pwecksretreat.com:2332

... Unzip... expand... What kind of pervert came up with this?

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Pweck's Retreat (23:1/1)

Hi all,

a short write-up of a BinkP problem I chased for a while, in case
someone else writing or running a mailer runs into it.

Symptom: polling two Mystic hubs (1.12A48 and A49) from my own
mailer (NullModem BBS, written in Go) failed most of the time with
a plain EOF right after sending M_PWD. No M_ERR, no M_OK - the hub
accepted the connection, read our password, and hung up. Sometimes
a session went through, which made it look like flakiness on the
hub side.

It wasn't. A wrong password got a proper "M_ERR Bad address or
password", so authentication was fine. CRAM vs. plaintext made no
difference either. What settled it was binkd: with the same
credentials it got M_OK every time, so I compared the frames line
by line.

Cause: my mailer sent only one M_NUL line before M_ADR - "VER".
Mystic 1.12 silently drops the session if VER is the only M_NUL
line. Add any one more (SYS, ZYZ, LOC or TIME) and it answers
M_OK, consistently, on both hubs. My "occasional successes" came
from a test button that happened to send SYS and ZYZ.
Fix on my side: always send TIME and SYS as well. Since then every
poll to both hubs completes.

A second Mystic quirk, in the other direction: when a Mystic hub
calls you, it may send M_GOT for your file right after its own
M_FILE, before that file's data frames. A strict receiver that
rejects command frames in the middle of a transfer will abort the
session - and you never get mail from that hub while you have
something queued for it. FTS-1026 allows commands between data
frames, so the receiver should handle them (I now defer them until
the file is done).

Lesson learned: if a hub "randomly" hangs up on you, compare your
session against binkd before blaming the other side.

Greetings
Mike

--- NullModem BBS v0.61.0
* Origin: Maiks Place BBS (23:1/107)