i think we've stumbled upon a bug when interacting with binkd and no session level password...

i have a connection with a node that sends this when my binkd connects out to them...

OPT CRAM-MD5-411eaac235d14fa531bd059150ddac9e CRYPT
[...]
VER BinkIT/2.17,JSBinkP/1.114,sbbs3.17c/Linux binkp/1.1

my binkd reports this...

rerror: Password mismatch


when they connect inbound, they are sending this...

OPT CRYPT
[...]
VER BinkIT/2.17,JSBinkP/1.114,sbbs3.17c/Linux binkp/1.1

my binkd reports this...

unexpected password digest from the remote


there is only a tic password set in echocfg... no other passwords are set between the two systems...

i tried setting -nomd on their node line but since they are requesting CRYPT, we cannot talk... binkd does not have, that i can find, an option to turn off CRYPT per node... i'm aware that binkit.js is v2.25 and binkp.js v1.118 and there has been some recent work done in this area of the code...

with the above versions, i'm thinking that we're missing something since we seem to be setting CRYPT even when there is no session level password defined... i don't know if having that node update to the latest binkp.js and/or binkit.js will fix this particular problem with requesting CRYPT when there is no session level password set, though...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I am curious, Do all Microsoft programmers do drugs?
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: possible CRYPT bug with no session password
By: mark lewis to all on Thu Jun 13 2019 09:44 pm

i think we've stumbled upon a bug when interacting with binkd and no

session
level password...

i have a connection with a node that sends this when my binkd connects

out
to them...

OPT CRAM-MD5-411eaac235d14fa531bd059150ddac9e CRYPT
[...]
VER BinkIT/2.17,JSBinkP/1.114,sbbs3.17c/Linux binkp/1.1

my binkd reports this...

rerror: Password mismatch

when they connect inbound, they are sending this...

OPT CRYPT
[...]
VER BinkIT/2.17,JSBinkP/1.114,sbbs3.17c/Linux binkp/1.1

That means the remote BinkIT system has a session password configured for your node. From binkp.js 1.114 ('-' is the same as a blank/no password):

if (password !== '-')
this.sendCmd(this.command.M_NUL, "OPT CRYPT");

my binkd reports this...

unexpected password digest from the remote

there is only a tic password set in echocfg... no other passwords are

set
between the two systems...

How do you know? according to the information you provided, it certainly seems the remote system has a session password configured.

i tried setting -nomd on their node line but since they are requesting CRYPT, we cannot talk... binkd does not have, that i can find, an option to turn off CRYPT per node...

Setting a blank password in BinkIT will stop the CRYPT option for outbound connections. The only way to disable it for inbound connections is the new global plain-text-only option.

i'm aware that binkit.js is v2.25 and binkp.js
v1.118 and there has been some recent work done in this area of the code...

All about disabling CRAM-MD5 and encryption because my uplink was having issues that couldn't be easily debugged when those features were used.

with the above versions, i'm thinking that we're missing something since we seem to be setting CRYPT even when there is no session level password defined...

I don't think so.

i don't know if having that node update to the latest binkp.js
and/or binkit.js will fix this particular problem with requesting CRYPT when there is no session level password set, though...

Shouldn't make any difference in that regard (for outbound connections from BinkIT).

digital man

Synchronet "Real Fact" #8:
Synchronet was originally intended as a replacement for WWIV BBS software. Norco, CA WX: 59.8øF, 88.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

On 2019 Jun 13 22:34:52, you wrote to me:

when they connect inbound, they are sending this...

OPT CRYPT
[...]
VER BinkIT/2.17,JSBinkP/1.114,sbbs3.17c/Linux binkp/1.1

That means the remote BinkIT system has a session password configured for your node. From binkp.js 1.114 ('-' is the same as a blank/no password):

if (!this.plain_auth_only && password !== '-')
this.sendCmd(this.command.M_NUL, "OPT CRYPT");

are you saying that if there is no session level password, we should have a '-'
in the session password field in echocfg??

i actually had nothing in the password field in my echocfg and then also in my binkd.conf... i've since added a '-' to my binkd.conf after reviewing my old configuration from my dead/defnuct system...

there is only a tic password set in echocfg... no other passwords are
set between the two systems...

How do you know? according to the information you provided, it certainly seems the remote system has a session password configured.

they posted me a copy of my entry in their sbbsecho.ini file... it looked exactly like the one i have for them...

----->8 snip 8<-----
[node:XXXXXXXXXXXXXXXXXX]
Name = XXXXXXXXXXXX
Comment =
Archive = None
PacketType = 2+
PacketPwd =
AreaFix = false
AreaFixPwd =
SessionPwd =
TicFilePwd = XXXXXXXX
Inbox =
Outbox =
Passive = false
Direct = true
Notify = false
Keys =
Status = Normal
LocalAddress = XXXXXXXXXXXX
GroupHub =
BinkpHost =
BinkpPort = 24554
BinkpPoll = false
BinkpPlainAuthOnly = false
BinkpAllowPlainAuth = true
BinkpAllowPlainText = true
BinkpSourceAddress = XXXXXXXXXXXXXXXXX
----->8 snip 8<-----

i tried setting -nomd on their node line but since they are requesting
CRYPT, we cannot talk... binkd does not have, that i can find, an option
to turn off CRYPT per node...

Setting a blank password in BinkIT will stop the CRYPT option for outbound connections. The only way to disable it for inbound connections is the new global plain-text-only option.

ahhh, ok... i wasn't sure how that worked... granted, i've not been into the code in several weeks...

i'm aware that binkit.js is v2.25 and binkp.js v1.118 and there has
been some recent work done in this area of the code...

All about disabling CRAM-MD5 and encryption because my uplink was
having issues that couldn't be easily debugged when those features
were used.

i know that feeling... especially when CRYPT is used and the conversation is encrypted so you can't tell what's being sent/received when capturing the raw network packets...

with the above versions, i'm thinking that we're missing something
since we seem to be setting CRYPT even when there is no session level
password defined...

I don't think so.

i don't understand what's happening, then...

i don't know if having that node update to the latest binkp.js and/or
binkit.js will fix this particular problem with requesting CRYPT when
there is no session level password set, though...

Shouldn't make any difference in that regard (for outbound connections from BinkIT).

hummm...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... !edis gnorw eht morf siht ta gnikool era uoY
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

On 2019 Jun 14 10:47:04, I wrote to you:

That means the remote BinkIT system has a session password configured
for your node. From binkp.js 1.114 ('-' is the same as a blank/no
password):

if (!this.plain_auth_only && password !== '-')
this.sendCmd(this.command.M_NUL, "OPT CRYPT");

are you saying that if there is no session level password, we should have

a

'-' in the session password field in echocfg??

of course that was wrong but if one was put in there, it should work the same... i've glanced over the code and i note that if the password is undefined, it is set to '-'... is it possible that maybe the password is not just undefined but it is blank?

if (password === undefined)
password = '-';
if (password === '-')
this.require_md5 = false;

should

this.wont_crypt = true;
this.require_crypt = false;

be set up there where "this.require_md5 = false" is set instead of being set further down? then checking additional values would prevent "OPT CRYPT" from being sent as well??

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I am celibate by choice - not mine, mind you.
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: possible CRYPT bug with no session password
By: mark lewis to Digital Man on Fri Jun 14 2019 10:47 am

On 2019 Jun 13 22:34:52, you wrote to me:

when they connect inbound, they are sending this...

OPT CRYPT
[...]
VER BinkIT/2.17,JSBinkP/1.114,sbbs3.17c/Linux binkp/1.1

That means the remote BinkIT system has a session password configured for your node. From binkp.js 1.114 ('-' is the same as a blank/no password):

if (!this.plain_auth_only && password !== '-')
this.sendCmd(this.command.M_NUL, "OPT CRYPT");

are you saying that if there is no session level password, we should have a '-' in the session password field in echocfg??

No. The BinkP protocol processes a blank password as '-' and the binkit/binkp script automatically converts blank passwords to '-' and compares as such.

i actually had nothing in the password field in my echocfg

That would be correct.

and then also in
my binkd.conf... i've since added a '-' to my binkd.conf after reviewing my old configuration from my dead/defnuct system...

binkd requires the '-' if you have other fields following the password.

there is only a tic password set in echocfg... no other passwords are
set between the two systems...

How do you know? according to the information you provided, it certainly seems the remote system has a session password configured.

they posted me a copy of my entry in their sbbsecho.ini file... it looked exactly like the one i have for them...

----->8 snip 8<-----
[node:XXXXXXXXXXXXXXXXXX]
Name = XXXXXXXXXXXX
Comment =
Archive = None
PacketType = 2+
PacketPwd =
AreaFix = false
AreaFixPwd =
SessionPwd =
TicFilePwd = XXXXXXXX
Inbox =
Outbox =
Passive = false
Direct = true
Notify = false
Keys =
Status = Normal
LocalAddress = XXXXXXXXXXXX
GroupHub =
BinkpHost =
BinkpPort = 24554
BinkpPoll = false
BinkpPlainAuthOnly = false
BinkpAllowPlainAuth = true
BinkpAllowPlainText = true
BinkpSourceAddress = XXXXXXXXXXXXXXXXX

Perhaps they made a copy/past error.

----->8 snip 8<-----

i tried setting -nomd on their node line but since they are requesting
CRYPT, we cannot talk... binkd does not have, that i can find, an option
to turn off CRYPT per node...

Setting a blank password in BinkIT will stop the CRYPT option for outbound connections. The only way to disable it for inbound connections is the new global plain-text-only option.

ahhh, ok... i wasn't sure how that worked... granted, i've not been into the code in several weeks...

i'm aware that binkit.js is v2.25 and binkp.js v1.118 and there has
been some recent work done in this area of the code...

All about disabling CRAM-MD5 and encryption because my uplink was having issues that couldn't be easily debugged when those features
were used.

i know that feeling... especially when CRYPT is used and the conversation is encrypted so you can't tell what's being sent/received when capturing the raw network packets...

with the above versions, i'm thinking that we're missing something
since we seem to be setting CRYPT even when there is no session level
password defined...

I don't think so.

i don't understand what's happening, then...

i don't know if having that node update to the latest binkp.js and/or
binkit.js will fix this particular problem with requesting CRYPT when
there is no session level password set, though...

Shouldn't make any difference in that regard (for outbound connections from BinkIT).

hummm...

Uh huh.

digital man

This Is Spinal Tap quote #16:
David St. Hubbins: I believe virtually everything I read...
Norco, CA WX: 72.2øF, 59.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: possible CRYPT bug with no session password
By: mark lewis to Digital Man on Fri Jun 14 2019 12:12 pm

On 2019 Jun 14 10:47:04, I wrote to you:

That means the remote BinkIT system has a session password configured
for your node. From binkp.js 1.114 ('-' is the same as a blank/no
password):

if (!this.plain_auth_only && password !== '-')
this.sendCmd(this.command.M_NUL, "OPT CRYPT");

are you saying that if there is no session level password, we should have

a

'-' in the session password field in echocfg??

of course that was wrong but if one was put in there, it should work the same... i've glanced over the code and i note that if the password is undefined, it is set to '-'... is it possible that maybe the password is not just undefined but it is blank?

Yes, I think that's exactly what's happening:
this.node[sec].pass = f.iniGetValue(section, 'SessionPwd', '');

This line (from fidocfg.js) would set the password to a blank string by default (not undefined).

if (password === undefined)
password = '-';
if (password === '-')
this.require_md5 = false;

should

this.wont_crypt = true;
this.require_crypt = false;

be set up there where "this.require_md5 = false" is set instead of being set further down? then checking additional values would prevent "OPT CRYPT" from being sent as well??

No, I think that part is right. Just because you don't *require* CRAM-MD5 doesn't mean you won't allow it (and to allow it, you must send the OPT CRYPT msg).

The blank vs. undefined password thing does seem like a problem though.

digital man

This Is Spinal Tap quote #9:
David St. Hubbins: I mean, it's not your job to be as confused as Nigel.
Norco, CA WX: 73.0øF, 59.0% humidity, 3 mph ENE wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: possible CRYPT bug with no session password
By: Digital Man to mark lewis on Fri Jun 14 2019 01:50 pm

Re: possible CRYPT bug with no session password
By: mark lewis to Digital Man on Fri Jun 14 2019 12:12 pm

On 2019 Jun 14 10:47:04, I wrote to you:

That means the remote BinkIT system has a session password configured
for your node. From binkp.js 1.114 ('-' is the same as a blank/no
password):

if (!this.plain_auth_only && password !== '-')
this.sendCmd(this.command.M_NUL, "OPT CRYPT");

are you saying that if there is no session level password, we should have

a

'-' in the session password field in echocfg??

of course that was wrong but if one was put in there, it should work the same... i've glanced over the code and i note that if the password is undefined, it is set to '-'... is it possible that maybe the password is not just undefined but it is blank?

Yes, I think that's exactly what's happening:
this.node[sec].pass = f.iniGetValue(section, 'SessionPwd', '');

This line (from fidocfg.js) would set the password to a blank string by default (not undefined).

Should be fixed now. Thanks for the bug report,

digital man

Synchronet "Real Fact" #15:
SBBSecho was introduced (replacing SBBSFIDO) for Synchronet v2 in 1994.
Norco, CA WX: 73.3øF, 59.0% humidity, 9 mph NE wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

How do you know? according to the information you provided, it certainly seems >he remote system has a session password configured.

Uuuummmm.... he took my word for it as I showed him some of the fields I am showing you now. :)

[node:1:3634/12@fidonet]
Name =
Comment =
Archive =
PacketType = 2+
PacketPwd =
AreaFix = true
AreaFixPwd =
SessionPwd =
TicFilePwd = password (also tried with this field BLANK)
Inbox =
Outbox =
Passive = false
Direct = true
Notify = false
Keys = FIDO
Status = Normal
GroupHub =
BinkpHost = sestar.synchro.net
BinkpPort = 24554
BinkpPoll = true
BinkpAllowPlainAuth = true
BinkpAllowPlainText = true
BinkpPlainAuthOnly = false
BinkpSourceAddress =

I checked and this is the only entry for his node in my sbbsecho.ini file.

Thanks!

---
þ SLMR 2.1a þ Nothing is so smiple that it can't get screwed up.
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Re: possible CRYPT bug with n
By: Dumas Walker to DIGITAL MAN on Fri Jun 14 2019 05:14 pm

How do you know? according to the information you provided, it certainly seems >he remote system has a session password configured.

Uuuummmm.... he took my word for it as I showed him some of the fields I am showing you now. :)

[node:1:3634/12@fidonet]
Name =
Comment =
Archive =
PacketType = 2+
PacketPwd =
AreaFix = true
AreaFixPwd =
SessionPwd =
TicFilePwd = password (also tried with this field BLANK)
Inbox =
Outbox =
Passive = false
Direct = true
Notify = false
Keys = FIDO
Status = Normal
GroupHub =
BinkpHost = sestar.synchro.net
BinkpPort = 24554
BinkpPoll = true
BinkpAllowPlainAuth = true
BinkpAllowPlainText = true
BinkpPlainAuthOnly = false
BinkpSourceAddress =

I checked and this is the only entry for his node in my sbbsecho.ini file.

Thanks. Get the latest exec/binkit.js and load/binkp.js from CVS and see if that fixes you up.

digital man

Synchronet "Real Fact" #28:
Rob Swindell's first computer was a Commodore VIC-20 (1980).
Norco, CA WX: 75.3øF, 58.0% humidity, 6 mph NE wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

On 2019 Jun 14 13:42:06, you wrote to me:

are you saying that if there is no session level password, we should
have a '-' in the session password field in echocfg??

No. The BinkP protocol processes a blank password as '-' and the binkit/binkp script automatically converts blank passwords to '-' and compares as such.

yeah, i saw that later...

i actually had nothing in the password field in my echocfg

That would be correct.

ok...

and then also in
my binkd.conf... i've since added a '-' to my binkd.conf after reviewing
my old configuration from my dead/defnuct system...

binkd requires the '-' if you have other fields following the password.

right... i do not have any additional fields after the password field in my conf file... i put the '-' in anyway, just in case but it made no difference...
i'm now waiting on the remote to put an actual session level password in their echocfg so we can see if that fixes the problem...

Perhaps they made a copy/past error.

it is possible ;)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Anything free is worth what you pay for it.
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

On 2019 Jun 14 13:50:10, you wrote to me:

of course that was wrong but if one was put in there, it should work the
same... i've glanced over the code and i note that if the password is
undefined, it is set to '-'... is it possible that maybe the password is
not just undefined but it is blank?

Yes, I think that's exactly what's happening:
this.node[sec].pass = f.iniGetValue(section, 'SessionPwd', '');

This line (from fidocfg.js) would set the password to a blank string by default (not undefined).

ahhhhhhhh...

be set up there where "this.require_md5 = false" is set instead of being
set further down? then checking additional values would prevent "OPT
CRYPT" from being sent as well??

No, I think that part is right. Just because you don't *require* CRAM-MD5 doesn't mean you won't allow it (and to allow it, you must send the OPT CRYPT msg).

ummm, what? to allow CRAM-MD5 you must also send CRYPT? i don't see that... to have/allow CRYPT, you have to do CRAM-MD5, yes... maybe i'm reading that wrongly?

The blank vs. undefined password thing does seem like a problem
though.

it is something to play with... [time passes] hehehe, i see you've already prodded cvs with some updates... we'll see what we can do about checking them out... i'll have to see if i can get the operator of that other system to update his .js files...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... One Tequila, Two Tequila, Three Tequila, Floor
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

On 2019 Jun 14 14:15:52, you wrote to me:

This line (from fidocfg.js) would set the password to a blank string by
default (not undefined).

Should be fixed now. Thanks for the bug report,

you're quite welcome :)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... He recently graduated from the Boone's Farm School of Wine!
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: possible CRYPT bug with no session password
By: mark lewis to Digital Man on Sat Jun 15 2019 11:23 am

On 2019 Jun 14 13:50:10, you wrote to me:

of course that was wrong but if one was put in there, it should work the
same... i've glanced over the code and i note that if the password is
undefined, it is set to '-'... is it possible that maybe the password is
not just undefined but it is blank?

Yes, I think that's exactly what's happening:
this.node[sec].pass = f.iniGetValue(section, 'SessionPwd', '');

This line (from fidocfg.js) would set the password to a blank string by default (not undefined).

ahhhhhhhh...

be set up there where "this.require_md5 = false" is set instead of being
set further down? then checking additional values would prevent "OPT
CRYPT" from being sent as well??

No, I think that part is right. Just because you don't *require* CRAM-MD5 doesn't mean you won't allow it (and to allow it, you must send the OPT CRYPT msg).

ummm, what? to allow CRAM-MD5 you must also send CRYPT? i don't see that... to have/allow CRYPT, you have to do CRAM-MD5, yes... maybe i'm reading that wrongly?

There's no configuration setting in echofg/sbbsecho.ini which enables support for CRAM-MD5 authentication (outbound) and disables support for encryption. A setting could be added but, since you can already disable both encryption and CRAM-MD5 (together), I'm not sure there's a need.

digital man

Synchronet/BBS Terminology Definition #9:
BSO = Binkley Style Outbound
Norco, CA WX: 76.7øF, 58.0% humidity, 11 mph ESE wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

On 2019 Jun 15 17:11:38, you wrote to me:

ummm, what? to allow CRAM-MD5 you must also send CRYPT? i don't see
that... to have/allow CRYPT, you have to do CRAM-MD5, yes... maybe i'm
reading that wrongly?

There's no configuration setting in echofg/sbbsecho.ini which enables support for CRAM-MD5 authentication (outbound) and disables support
for encryption. A setting could be added but, since you can already disable both encryption and CRAM-MD5 (together), I'm not sure there's
a need.

i'm not sure, either... i like the idea of using CRAM-MD5 for the authentication exchange...

CRYPTing the entire conversation is not really necessary but some like that, too... i guess they're transiting CC numbers, state secrets or similar...

while they are coupled together in that CRYPT needs CRAM-MD5 to have a secure transaction, one should not have to run CRYPT if they don't want to...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... The only way round is through. - Robert Frost
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: possible CRYPT bug with no session password
By: mark lewis to Digital Man on Sun Jun 16 2019 10:23 am

On 2019 Jun 15 17:11:38, you wrote to me:

ummm, what? to allow CRAM-MD5 you must also send CRYPT? i don't see
that... to have/allow CRYPT, you have to do CRAM-MD5, yes... maybe i'm
reading that wrongly?

There's no configuration setting in echofg/sbbsecho.ini which enables support for CRAM-MD5 authentication (outbound) and disables support
for encryption. A setting could be added but, since you can already disable both encryption and CRAM-MD5 (together), I'm not sure there's
a need.

i'm not sure, either...

If/when someone wants it, I'll add it to the todo list. :-)

digital man

Synchronet "Real Fact" #33:
The Synchronet web user interface was contributed by Robert Couture, Runemaster.
Norco, CA WX: 77.5øF, 60.0% humidity, 8 mph E wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

On 2019 Jun 16 14:30:54, you wrote to me:

support for CRAM-MD5 authentication (outbound) and disables support
for encryption. A setting could be added but, since you can already
disable both encryption and CRAM-MD5 (together), I'm not sure

there's

a need.

i'm not sure, either...

If/when someone wants it, I'll add it to the todo list. :-)

please? thank you :)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Since we're both going to Hell anyway, maybe we should carpool?
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Thanks. Get the latest exec/binkit.js and load/binkp.js from CVS and see if tha
fixes you up.

OK, I did a wget/rename on both of those. We will see what happens.
Thanks!!!

---
þ SLMR 2.1a þ Unable to locate Coffee -- Operator Halted!
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

On 2019 Jun 16 19:43:00, Dumas Walker wrote to you:

Thanks. Get the latest exec/binkit.js and load/binkp.js from CVS and see
if tha fixes you up.

OK, I did a wget/rename on both of those. We will see what happens.

it is working between our systems now... thanks for the fix! :)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I may be dumb, but I'm not THAT stupid! ;*)
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net