-
exec/load/binkp.js
From
deuce@1:103/705 to
CVS commit on Thu Mar 1 15:05:17 2018
exec/load binkp.js 1.70 1.71
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv10844/load
Modified Files:
binkp.js
Log Message:
Set sentempty if we send an eob while senteob is true.
May fix infinite M_EOB ping-pong on some v1.1 connections.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Thu Mar 1 18:17:59 2018
exec/load binkp.js 1.71 1.72
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv29878
Modified Files:
binkp.js
Log Message:
For outgoing connections, if there is a password, and the remote accepts it, mark the session as secure. Works around Radius/4.010/21.01.2005,13:56(Final-Release)/Win32
not sending the reccomended M_OK argument.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Tue Mar 6 21:04:59 2018
exec/load binkp.js 1.72 1.73
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv1807/load
Modified Files:
binkp.js
Log Message:
Send M_ERR instead of M_OK when a link's password doesn't match.
I'm probably doing something wrong here, since I didn't write this code (particularly if there are multiple advertised addresses in the session
which we have configured links for) - but this should at least give Al something to test.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Tue Mar 6 23:47:48 2018
exec/load binkp.js 1.73 1.74
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv20760/load
Modified Files:
binkp.js
Log Message:
Work around issue with Internet Rex 2.29 Win32 (binkp/1.1)
Does not support CRAM-MD5 challenges longer than 16 bytes (32 hex chars)
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Tue Mar 6 23:49:43 2018
exec/load binkp.js 1.74 1.75
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv21073/load
Modified Files:
binkp.js
Log Message:
Added some helpful log messages when starting/finishing the transfer of
files (sending or receiving).
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Fri Mar 9 17:10:23 2018
exec/load binkp.js 1.75 1.76
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv11402/load
Modified Files:
binkp.js
Log Message:
Inlcude more more version details in the log output (so I can stop having
to ask sysops after they've already pasted log output into a help request). Also, include the sbbs version in the BinkP "VER" message excahanged with
the BinkP peer.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Sat Mar 10 12:14:02 2018
exec/load binkp.js 1.76 1.77
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv11366/load
Modified Files:
binkp.js
Log Message:
Allow the default CRAM challenge length (16 bytes) to be overridden
(e.g. for experimental purposes) via binkit.ini:
cram_challenge_length = <length in bytes>
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Sat Mar 10 17:36:17 2018
exec/load binkp.js 1.77 1.78
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv30675
Modified Files:
binkp.js
Log Message:
Log the peer mailer version report with a LOG_INFO level message.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Wed Mar 14 11:23:34 2018
exec/load binkp.js 1.78 1.79
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv4249/load
Modified Files:
binkp.js
Log Message:
Add TLS support to binkp.
The *first* packet from the answering side *must* be an M_NUL "OPT TLS".
If this is the case, the originating size responds with an M_NUL "OPT TLS". After this, the answering system performs a server TLS handshake, and the originating system performs a client TLS handshake.
OPT CRYPT is not used in this case (ie: not crypt over TLS)
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Wed Mar 14 16:31:52 2018
exec/load binkp.js 1.79 1.80
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv6697
Modified Files:
binkp.js
Log Message:
Remove magical return type of auth callback.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Wed Mar 14 16:41:11 2018
exec/load binkp.js 1.80 1.81
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv7825
Modified Files:
binkp.js
Log Message:
Copy the comment about VER Internet Rex 2.29 Win32 (binkp/1.1) to where
the challenge length is set and add a TODO comment there.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Thu Mar 15 01:16:10 2018
exec/load binkp.js 1.81 1.82
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv3897
Modified Files:
binkp.js
Log Message:
We need to send M_NUL "OPT TLS" before M_NUL "OPT CRYPT".
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Thu Mar 15 01:59:54 2018
exec/load binkp.js 1.82 1.83
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv8552
Modified Files:
binkp.js
Log Message:
Since we're supporting TLS now, use the sock.recv() timeout parameter instead of poll()ing for each byte.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Thu Mar 15 02:17:14 2018
exec/load binkp.js 1.83 1.84
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv10472
Modified Files:
binkp.js
Log Message:
Don't use a separate OPT line for TLS, it seems to mess up Radius/4.010/21.01.2005,13:56(Final-Release)/Win32
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Thu Mar 15 15:21:09 2018
exec/load binkp.js 1.84 1.85
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv30624/load
Modified Files:
binkp.js
Log Message:
Fix handling of timeouts vs. errors... they're not the same, so don't treat them that way. Also, ensure there's a timeout on the second byte of the
packet header since we toss out the first byte if the second byte times out (they should pretty much always be in the same packet, but why take the risk?)
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Thu Mar 15 15:39:04 2018
exec/load binkp.js 1.85 1.86
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv32581/load
Modified Files:
binkp.js
Log Message:
Add a new send_chunks() method which will deal with short send() calls.
We can't rely on our send buffers being infinite anymore.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Thu Mar 15 16:32:15 2018
exec/load binkp.js 1.86 1.87
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv4584/load
Modified Files:
binkp.js
Log Message:
Push an M_SKIP into the failed_sent_files() from the pending_ack array, not from the currently sending file, since the pending ack should always be there, but sending often won't be. Also, log a warning when pending_ack isn't empty and we get an M_EOB.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Thu Mar 15 18:35:51 2018
exec/load binkp.js 1.87 1.88
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv21088/load
Modified Files:
binkp.js
Log Message:
Add some temporary debug logspam.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Thu Mar 15 18:39:03 2018
exec/load binkp.js 1.88 1.89
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv21475/load
Modified Files:
binkp.js
Log Message:
Terminate string.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Thu Mar 15 19:08:34 2018
exec/load binkp.js 1.89 1.90
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv24625/load
Modified Files:
binkp.js
Log Message:
Overhaul EOB handling... just count them, and reset both to zero on non-EOB
in either direction.
For v1.0, a single EOB in both directions terminates the session and for
v1.1, two EOBs in both directions terminates.
This should greatly simplify the overly complicated senteob/sentempty/goteob/ gotempty logic and completely eliminate loops. Biggest risk with this change is issues with v1.0 servers.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Thu Mar 15 19:30:01 2018
exec/load binkp.js 1.90 1.91
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv26747/load
Modified Files:
binkp.js
Log Message:
Fixes for v1.0 mode...
1) Don't reset eob counts for sent or got.
2) Ensure M_GET is never sent in v1.0 mode.
3) Only send one M_EOB in v1.0 mode, even if we add to the list with M_GET
This should cover all the bases, but FREQ may be non-conformant.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Sat Mar 17 21:42:04 2018
exec/load binkp.js 1.91 1.92
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv24456
Modified Files:
binkp.js
Log Message:
TLS is apparently causing issues, remove it since nobody else supports it anyway.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Sun Mar 18 23:06:01 2018
exec/load binkp.js 1.92 1.93
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv27765/load
Modified Files:
binkp.js
Log Message:
Pass the timeout argument to the data recv() call
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Mon Mar 19 10:47:14 2018
exec/load binkp.js 1.93 1.94
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv27129/load
Modified Files:
binkp.js
Log Message:
No need to send M_EOB while receiving a file, it'll settle out at the end.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Mon Mar 19 10:49:28 2018
exec/load binkp.js 1.94 1.95
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv27321/load
Modified Files:
binkp.js
Log Message:
For v1.1 connections, send two EOBs before raising the timeout. It seems that Radius/4.010/21.01.2005,13:56(Final-Release)/Win32 will not send an M_EOB
until it receives two from the remote.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Mon Mar 19 10:55:04 2018
exec/load binkp.js 1.95 1.96
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv27882/load
Modified Files:
binkp.js
Log Message:
Add comment (pending testing), and fix bug in last commit.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Mon Mar 19 11:05:49 2018
exec/load binkp.js 1.96 1.97
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv29069/load
Modified Files:
binkp.js
Log Message:
Don't send a second M_EOB until we get an M_EOB from the remote.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Mon Mar 19 11:12:28 2018
exec/load binkp.js 1.97 1.98
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv29871/load
Modified Files:
binkp.js
Log Message:
Only use reset_eob() to reset eob counts. Don't reset the EOB counts except for in file transfer related times.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Mon Mar 19 11:49:37 2018
exec/load binkp.js 1.98 1.99
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv1286
Modified Files:
binkp.js
Log Message:
More log details with regards to timeouts and successful authentication.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Mon Mar 19 16:01:24 2018
exec/load binkp.js 1.99 1.100
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv28809/load
Modified Files:
binkp.js
Log Message:
On a recv() of zero bytes, check if the socket is still connected.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Mon Mar 19 17:10:17 2018
exec/load binkp.js 1.100 1.101
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv17152/load
Modified Files:
binkp.js
Log Message:
Inspired by revision 1.36, only reset senteob when we add a file. Appears
to work around Radius hang. Also, in v2 mode, when we're close()ing, try
to send two M_EOB to help work around weird/broken remotes.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Mon Mar 19 20:47:02 2018
exec/load binkp.js 1.101 1.102
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv10087
Modified Files:
binkp.js
Log Message:
Fix line 1196: ReferenceError: reset_eob is not defined
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Fri Mar 23 16:27:47 2018
exec/load binkp.js 1.102 1.103
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv23847
Modified Files:
binkp.js
Log Message:
Raise the log-level severity (from DEBUG to NOTICE) when sending any M_ERR messages. There's a lot of places in this script where we just send a
(somewhat explanatory) M_ERR string, but don't log anything locally unless debug-level logging is enabled, now we'll at least log those messages with
a bit higher severity.
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Sat Mar 24 13:57:32 2018
exec/load binkp.js 1.103 1.104
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv32126/load
Modified Files:
binkp.js
Log Message:
Attept to work around Mystic CRAM+CRYPT issue.
--- SBBSecho 3.03-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Sat Mar 24 14:01:35 2018
exec/load binkp.js 1.104 1.105
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv32701/load
Modified Files:
binkp.js
Log Message:
Add comment in binkp about why we detect Mystic as well.
--- SBBSecho 3.03-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Sat Mar 24 14:09:18 2018
exec/load binkp.js 1.105 1.106
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv1118/load
Modified Files:
binkp.js
Log Message:
Store the remote software version in the BinkP object, don't do special
stuff in binkp.js, only the protocol. BinkIT now does the Mystic check.
--- SBBSecho 3.03-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Sun Jul 8 14:50:17 2018
exec/load binkp.js 1.106 1.107
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv31064
Modified Files:
binkp.js
Log Message:
More log output around connecting to a node.
I suspect that connect() may be blocking and causing Al's reported issue
(A BinkIT poll never returns from the script and goes into some kind of infinite busy loop).
--- SBBSecho 3.05-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Sun Jul 8 15:10:39 2018
exec/load binkp.js 1.107 1.108
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv545
Modified Files:
binkp.js
Log Message:
Fix what appears to be a few potential infinite loops where
recvFrame() is being called in a loop and only breaking on specific
conditions or if recvFrame returned undefined. Problem is, on timeout, recvFrame returns null (and when using === comparision, undefined !== null). Also added more debug output around sends where I suspect there might be another potential infinite loop.
--- SBBSecho 3.05-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Sun Jul 8 16:55:18 2018
exec/load binkp.js 1.108 1.109
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv11895
Modified Files:
binkp.js
Log Message:
Fix potential infinite loop in send_chunks(), some versions of Socket.send() can return false on error, which is >= 0, so this will just add 0 to the
length and keep on looping forever in that case.
--- SBBSecho 3.05-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
echicken@1:103/705 to
CVS commit on Sun Sep 23 19:57:24 2018
exec/load binkp.js 1.110 1.111
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv27619
Modified Files:
binkp.js
Log Message:
Can't be the current 'sending' file if we ain't sending no file.
--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Fri Nov 9 17:26:47 2018
exec/load binkp.js 1.111 1.112
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv5423
Modified Files:
binkp.js
Log Message:
Log the 'remote_addrs' value with each log message of LOG_ERR severity
(yeah, those should all be LOG_ERR, not LOG_ERROR - oh well) since LOG_ERR messages go to the data/error.log and including this information is helpful
to sysops that monitor this file and use it to help find/debug issues.
--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Sun Jan 6 21:50:44 2019
exec/load binkp.js 1.112 1.113
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv16347
Modified Files:
binkp.js
Log Message:
3 new BinkP properties:
.remote_operator (the value of the 'ZYZ' message, if received) .remote_capabilities (the value of the 'NDL' message, if received) .remote_info[], an associative array of any/all *other* M_NUL BinkP
commands/messages (e.g. bp.remote_info['TIME'] contains the remote TIME
message arguments, if such a message was received).
--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Sun Jan 6 23:17:35 2019
exec/load binkp.js 1.113 1.114
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv26978
Modified Files:
binkp.js
Log Message:
New BinkP properties:
.connect_host
.connect_port
.connect_error
Allows the application (binkit.js) to log detailed BinkP.connect() failures.
--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Tue Apr 30 14:41:12 2019
exec/load binkp.js 1.114 1.115
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv17754
Modified Files:
binkp.js
Log Message:
Lower the log level of teh "Timed out receiving packet data" log message from ERROR to WARNING - for Ragnarok.
--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Sat May 25 02:59:02 2019
exec/load binkp.js 1.115 1.116
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv23631
Modified Files:
binkp.js
Log Message:
When connecting a linked-node configured for PlainAuthOnly:
- don't advertise support for encryption (by sending an "OPT CRYPT" message)
- don't complain (send "Encryption requires CRAM-MD5" M_ERR) if the remote
doesn't support CRAM-MD5
--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Sun May 26 19:08:59 2019
exec/load binkp.js 1.116 1.117
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv18909
Modified Files:
binkp.js
Log Message:
If plain_auth_only (PlainAuthOnly) is true, then we won't be encrypting.
--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Tue May 28 18:09:23 2019
exec/load binkp.js 1.117 1.118
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv12179
Modified Files:
binkp.js
Log Message:
Better error message (consistent with binkit.js):
"CRAM-MD5 authentication required" instead of "MD5 required"
--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Fri Jun 14 14:08:53 2019
exec/load binkp.js 1.118 1.119
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv27843/load
Modified Files:
binkp.js
Log Message:
Since Revision 1.36 of load/fidocfg.js (Jan-8-2019), a blank/unconfigured
BinkP session password ("SessionPwd") in sbbsecho.ini would cause BinkIT/BinkP to behave as though a session password was specified. The reason for the change to fidocfg.js (specifying a default value for "SessionPwd" as a blank string) was to force the return value to a string so that numeric passwords were not returned as numbers but rather strings.
The binkit.js and binkp.js code assumed that a blank password would be 'undefined' and not a blank string.
This commit changes binkit.js and binkp.js to treat all of the following session password values as "no password" with respect to BinkP:
- false
- undefined
- blank string ('')
--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
deuce@1:103/705 to
CVS commit on Tue Aug 6 06:32:21 2019
exec/load binkp.js 1.120 1.121
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv22124/load
Modified Files:
binkp.js
Log Message:
Use ConnectedSocket class to support outgoing IPv6 connections.
--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
rswindell@1:103/705 to
CVS commit on Fri Apr 10 00:01:25 2020
exec/load binkp.js 1.122 1.123
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv22684
Modified Files:
binkp.js
Log Message:
When a file fails to open, log the error value, e.g. this:
Error 24 opening '../fido/outbound/5e7a2520.pkt'. Not sending.
instead of this:
Unable to open '../fido/outbound/5e7ab832.pkt'. Not sending.
Error 24 is "too many open files", btw. Another problem to solve.
--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
Rob Swindell@1:103/705 to
Git commit to main/sbbs/master on Wed Nov 25 22:01:38 2020
https://gitlab.synchro.net/main/sbbs/-/commit/d1566e7d7b3a9e013f244cea
Modified Files:
exec/load/binkp.js
Log Message:
Don't assume the BinkP VER message contains 3-space-delimited fields.According to both FTS-1026 and FSP-1024, the "mailer version" portion of thismsg may contain spaces. Some mailers (e.g. Internet Rex), provide their versioninformation with spaces, e.g. "Internet Rex 2.67 beta 1a OS/2 (binkp/1.1)",which also include a non-conformant protocol version indicator: " (binkp/1.1)" instead of " binkp/1.1".Additionally, only require that "binkp/" exist in the string, to find andparse the protocol version number, which is apparently critical to the properoperation of the protocol. This should resolve
issue #185 reported by altere.I'm also storing the entire VER response in the binkp.remote_ver property andthis will break the older Mystic/BinkP work-arounds in binkit.js. I dont' thinkwe really need those workarounds any longer however. We'll soon see I guess.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
Deuce@1:103/705 to
Git commit to main/sbbs/master on Wed Nov 25 23:00:10 2020
https://gitlab.synchro.net/main/sbbs/-/commit/b846192f8b436fac248fd9d9
Modified Files:
exec/load/binkp.js
Log Message:
Just parse VER using /^VER (.*) ([^ ]*?)$/This restores the meaning of remote_ver and still has a hack forbroken, unfixable mailers that don't advertise protocol v1.1correctly (ie: Irex)
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
Deuce@1:103/705 to
Git commit to main/sbbs/master on Wed Nov 25 23:09:24 2020
-
From
Deuce@1:103/705 to
Git commit to main/sbbs/master on Wed Nov 25 23:12:02 2020
-
From
Deuce@1:103/705 to
Git commit to main/sbbs/master on Fri Nov 27 00:45:41 2020
https://gitlab.synchro.net/main/sbbs/-/commit/d218c8de9ff3cd359f101409
Modified Files:
exec/load/binkp.js
Log Message:
"Handle" frames with a data length of zero.These frames were already not allowed in the binkp/1.0 protocol,and it is mentioned in the spec (issued in 2005) as "Some oldimplementations do send empty frames as the last frame.".It's
certainly not allowed now, and any mailer which does it isbroken.For zero-length data packets, it will be seen as a frame containingzero data bytes which will also be logged as being after the fileif it comes after the file has
already been completely transferred.A zero-length command packet will abort with M_ERR, logging an errorregarding command number NaN or something like that.This may fix #185 since attempting a recv() of zero bytes andsucceeding is
the only way I can see for a zero second timeout tohave been logged in receving
frame data. The software assumed thatreceiving zero bytes was a timeout, but if that's what you asked for,it's actually success.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
Deuce@1:103/705 to
Git commit to main/sbbs/master on Fri Nov 27 01:02:50 2020
https://gitlab.synchro.net/main/sbbs/-/commit/f6cc52385b146eb2def3ad21
Modified Files:
exec/load/binkp.js
Log Message:
Apparently we're editing file revisions like cavemen now.Call this one "2"Flashbacks to manually editing zone files here.I may end up going with YYYYMMDD numbers like I sometimes did inzone files, but maybe I'll just do the single number thing... notreally sure yet.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
Deuce@1:103/705 to
Git commit to main/sbbs/master on Wed Dec 2 12:49:20 2020
https://gitlab.synchro.net/main/sbbs/-/commit/a0b4a7cf8e4e1b79e75805ed
Modified Files:
exec/load/binkp.js
Log Message:
Perform super-graceful shutdown of the socket on success.This should guard against a RST being sent on success. It's possiblethat the remote has sent data (ie: M_EOB) we would recv() after wecommit to ending the session. If the script terminates while thereis data to be read, this would result in sending a
RST.To prevent this, we call shutdown(sock, SHUT_WR) via setting is_writeableto
false (because that's how we roll), then recv() all data until theremote closes
the session, or the timeout passes.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
Deuce@1:103/705 to
Git commit to main/sbbs/master on Thu Dec 3 19:40:33 2020
https://gitlab.synchro.net/main/sbbs/-/commit/4322be29d519e065d4ba114a
Modified Files:
exec/load/binkp.js
Log Message:
Fix this.sock is undefined error.Not sure how we get a successful shutdown after closing the socket,but the issue was reported by altere as happening in the wild.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
Deuce@1:103/705 to
Git commit to main/sbbs/master on Fri Dec 4 16:45:53 2020
-
From
Deuce@1:103/705 to
Git commit to main/sbbs/master on Fri Dec 4 16:46:17 2020
-
From
Deuce@1:103/705 to
Git commit to main/sbbs/master on Mon Dec 28 11:49:37 2020
-
From
Rob Swindell@1:103/705 to
Git commit to main/sbbs/master on Sun Jan 3 17:57:37 2021
-
From
Rob Swindell@1:103/705 to
Git commit to main/sbbs/master on Fri Nov 4 10:24:17 2022
https://gitlab.synchro.net/main/sbbs/-/commit/4dd32231f18bcb4f67833c36
Modified Files:
exec/load/binkp.js
Log Message:
Resolve undetected or infinitely-retried socket-send failuresMy hub (1:218/700)
is currently having what appears to be a TCP/IPconnectivity issue that was resulting in infinite "Send failure"log messages and "We got an M_EOB, but there are still N files pending M_GOT"log messages.I first added better socket-send failure detection (checking return value ofsendCmd() and sendData()
where needed) and then noticed that failure to senda file was not detected (the
sending.file.position is advanced even ifsendData() fails), so now handling that condition too.Also added more diagnostics around socket-send failures (is socket writable?)in this particular case, the socket is not writable and socket-send isreturning 0.
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
-
From
Rob Swindell@1:103/705 to
Git commit to main/sbbs/master on Mon Nov 28 12:18:49 2022
-
From
Rob Swindell@1:103/705 to
Git commit to main/sbbs/master on Mon Nov 28 12:57:49 2022
https://gitlab.synchro.net/main/sbbs/-/commit/0ea1ce1d2600b79a77d41b7e
Modified Files:
exec/load/binkp.js
Log Message:
Use socket.poll() to check socket for writability before send()This is the real
fix for infinite-wait on send() problem that was attemptedin commit f0127e9d457, but caused other issues. Thanks Deuce.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)