-
exec/load/binkp.js
From
deuce@VERT to
CVS commit on Wed Mar 14 21:16:00 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".
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Wed Mar 14 21:59:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Wed Mar 14 22:17:00 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
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Thu Mar 15 11:21:00 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?)
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Thu Mar 15 11:39:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Thu Mar 15 12:32:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Thu Mar 15 14:35:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Thu Mar 15 14:39:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Thu Mar 15 15:08:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Thu Mar 15 15:30:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Sat Mar 17 17:42:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Sun Mar 18 19:06:00 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
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Mon Mar 19 06:47:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Mon Mar 19 06:49:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Mon Mar 19 06:55:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Mon Mar 19 07:05:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Mon Mar 19 07:12:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Mon Mar 19 07:49:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Mon Mar 19 12:01:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Mon Mar 19 13:10:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Mon Mar 19 16:47:00 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
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Fri Mar 23 12:27:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Sat Mar 24 09:57:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Sat Mar 24 10:01:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Sat Mar 24 10:09:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Sun Jul 8 10:50:00 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).
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Sun Jul 8 11:10:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Sun Jul 8 12:55:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
echicken@VERT to
CVS commit on Sun Sep 23 15:57:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Fri Nov 9 12:26:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Sun Jan 6 16:50:00 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).
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Sun Jan 6 18:17:00 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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Tue Apr 30 10: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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Fri May 24 22: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
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Sun May 26 15: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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Tue May 28 14: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"
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Fri Jun 14 10: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 ('')
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
deuce@VERT to
CVS commit on Tue Aug 6 02: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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Thu Apr 9 20: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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
Rob Swindell@VERT to
Git commit to main/sbbs/master on Wed Nov 25 17: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 this msg may contain spaces. Some mailers (e.g. Internet Rex), provide their version information 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 and
parse the protocol version number, which is apparently critical to the proper operation 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 and this will break the older Mystic/BinkP work-arounds in binkit.js. I dont' think we really need those workarounds any longer however. We'll soon see I guess.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
Deuce@VERT to
Git commit to main/sbbs/master on Wed Nov 25 18: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 for
broken, unfixable mailers that don't advertise protocol v1.1
correctly (ie: Irex)
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
Deuce@VERT to
Git commit to main/sbbs/master on Wed Nov 25 18:09:24 2020
-
From
Deuce@VERT to
Git commit to main/sbbs/master on Wed Nov 25 18:12:02 2020
-
From
Deuce@VERT to
Git commit to main/sbbs/master on Thu Nov 26 19: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 old
implementations do send empty frames as the last frame.".
It's certainly not allowed now, and any mailer which does it is
broken.
For zero-length data packets, it will be seen as a frame containing
zero data bytes which will also be logged as being after the file
if it comes after the file has already been completely transferred.
A zero-length command packet will abort with M_ERR, logging an error
regarding command number NaN or something like that.
This may fix #185 since attempting a recv() of zero bytes and
succeeding is the only way I can see for a zero second timeout to
have been logged in receving frame data. The software assumed that
receiving zero bytes was a timeout, but if that's what you asked for,
it's actually success.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
Deuce@VERT to
Git commit to main/sbbs/master on Thu Nov 26 20: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 in
zone files, but maybe I'll just do the single number thing... not
really sure yet.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
Deuce@VERT to
Git commit to main/sbbs/master on Wed Dec 2 07: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 possible
that the remote has sent data (ie: M_EOB) we would recv() after we
commit to ending the session. If the script terminates while there
is data to be read, this would result in sending a RST.
To prevent this, we call shutdown(sock, SHUT_WR) via setting is_writeable
to false (because that's how we roll), then recv() all data until the
remote closes the session, or the timeout passes.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
Deuce@VERT to
Git commit to main/sbbs/master on Thu Dec 3 14: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.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
Deuce@VERT to
Git commit to main/sbbs/master on Fri Dec 4 11:45:53 2020
-
From
Deuce@VERT to
Git commit to main/sbbs/master on Fri Dec 4 11:46:17 2020
-
From
Deuce@VERT to
Git commit to main/sbbs/master on Mon Dec 28 06:49:37 2020
-
From
Rob Swindell@VERT to
Git commit to main/sbbs/master on Sun Jan 3 12:57:37 2021
-
From
Rob Swindell@VERT 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 failures
My hub (1:218/700) is currently having what appears to be a TCP/IP
connectivity 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 of sendCmd() and sendData() where needed) and then noticed that failure to send
a file was not detected (the sending.file.position is advanced even if sendData() 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 is returning 0.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
Rob Swindell@VERT to
Git commit to main/sbbs/master on Mon Nov 28 12:18:49 2022
-
From
Rob Swindell@VERT 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 attempted
in commit f0127e9d457, but caused other issues. Thanks Deuce.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net