src/sbbs3 ftpsrvr.c 1.497 1.498
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv1115

Modified Files:
ftpsrvr.c
Log Message:
Increase the size of the buffer used to format the download notification short messages (telegrams) from 128 to 256 bytes to resolve observed truncation of download notification messages like this:
"Guns N Roses - Hotel Brawl Jam (Live).mp3 was FTP-downloaded by Guest [89.245.6.
199]
You were awarded 2,057,356 cred"


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/sbbs3 ftpsrvr.c 1.498 1.499
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv30088

Modified Files:
ftpsrvr.c
Log Message:
Log the user name or IP address in more places.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/sbbs3 ftpsrvr.c 1.500 1.501
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv23645

Modified Files:
ftpsrvr.c
Log Message:
More file existence/length checks, with only a WARNING log level (not error) since some QWKnet nodes apparently like to start concurrent QWK packet downloads and inevitably one finishes first, deleting the file, and the second transfer logs and error. Examples:
8/14 08:10:06p 2296 <EPHRAM> downloading QWK packet (1320 bytes) in passive mode
8/14 08:10:06p 3792 <EPHRAM> downloading QWK packet (1320 bytes) in passive mode
8/14 08:10:06p 2296 <EPHRAM> DATA Transfer successful: 1320 bytes sent in 0 seconds (2640 cps)
8/14 08:10:06p 3792 <EPHRAM> !DATA ERROR 2 (No such file or directory) line 1376 opening s:\sbbs\data\file/0888.qwk
8/14 11:28:55p 2576 <POTOGOLD> downloading QWK packet (27129 bytes) in passive mode
8/14 11:28:55p 2576 <POTOGOLD> DATA Transfer successful: 27129 bytes sent in 0 seconds (54258 cps)
8/14 11:28:55p 1924 <POTOGOLD> downloading QWK packet (4294967295 bytes) in passive mode
8/14 11:28:56p 1924 <POTOGOLD> !DATA ERROR 2 (No such file or directory) line 1376 opening s:\sbbs\data\file/0168.qwk

Also some more 64-bit file length support (flength returns an off_t now, not a ulong).
And ftell() returns a long (not a ulong).



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/10477fe29378aebb82b8efd2
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Create the pack*.now with fmutex() to prevent simultaneous QWK packs

Probably only a problem on Vertrauen, but some QWKnet nodes, for some unknown reason, like to FTP-connect multiple times concurrently and request to download a QWK packet. This creates a race condition where the QWK packet gets created/downloaded/deleted before the second FTP connection can successfully download the same file, thus logging an error "opening file " on the server (VERT). So if the pack*.now file already exists, reject the download request. "What are doing?" is what I really want to ask these nodes, but better just throw them an error response and quietly move on.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/31d07482c7dc81b1af72e495
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Remove 3 second delay before disconnecting when max clients reached

This seems to be misguided and would only increase the chances of a DoS-type attack on TCP session resources.

A second 3-second delay upon malloc failure is also removed.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/dcb003099daa5b03e53542d4
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Log messages indicating AUTH TLS success or failure and set client prot

Set the client protocol to "FTPS" upon successful TLS startup in the control connection (response to the AUTH TLS command from the client). Log some messages indicating FTPS was attempted or successful.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/51ce7e6f71c2009c1804679f
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Attempt to fix issue #799

receive_thread() needs to use the control session correctly for
TLS connections.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/17912ca377006ca652483b1e
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
IP addresses are logged (most) everywhere else in square brackets

There are still places where it could be logged in <> (if username is not yet known).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/ffba326dad6263eedc29ed94
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Fix the "ERROR x getting data user y" log message (usernum was 0).

Add the errno value to help root-cause.

We really should be using safe_strerror() everywhere.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/569efded81398f71ad35f70b
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Use safe_strerror() in place of strerror() - everything multithreaded should

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/6fc2a6b6ff98fab8f98bf955
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
A little beautification of errno logging

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/8b4d02103bb4a63ffcc360f3
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Correct initialization of fmutex_t so the file descriptor is -1

For some reason, MSVC was initializing the time_t (second element of the struct) to -1, not the int fd (the first element), which was initialized to
0. Weird.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: src/sbbs3/ftpsrvr.c
By: Rob Swindell (on Windows 11) to Git commit to main/sbbs/master on Mon Nov 18 2024 01:50 am

For some reason, MSVC was initializing the time_t (second element of the struct) to -1, not the int fd (the first element), which was initialized to 0. Weird.

Actually, this assessment was wrong. fmutex_open() was memsetting the fmutex_t to zero.
--
digital man (rob)

Synchronet/BBS Terminology Definition #88:
UART = Universal Asynchronous Receiver/Transmitter
Norco, CA WX: 61.5øF, 38.0% humidity, 2 mph W wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/44147ffd5adc1105b4e8600e
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Change terminate_server to correct type expected by xpms_add* functions

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/1c365418fbab2a23d603d0d1
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Addrss some new MSVC warnings

Check sscanf() result
Don't use deprecated function: inet_addr()

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/b4a4a524160fb705bd740506
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Ignore MKD/XMKD commands from users (pretend successful)

For non-Guest users (without the 'U' restriction), if the FTP client
sends the MKD or XMKD command, just return the proper succcess result
and do nothing (don't log as a hack attempt or return a syntax error
result).

Some FTP clients (e.g. Reolink Doorbell camera) just always try to
blindly create a directory before uploading files, but if that command
fails (as we would), the upload is aborted. So pretend to create the
diretory whether it already exists or not, just so the client will
proceed with the upload.

For G or U restricted users, treat (log) as hack-attempt, as before.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/fe48a444e23d7594abfeef1b
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Lower severity of repeated log messages about low disk space

"!Insufficient free disk space (%s bytes) to allow upload"

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/162b3c708802379e759f9593
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Eliminate unnecessary dir_op() wrapper for user_is_dirop()

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/d38690513b9294dc948a5310
Modified Files:
src/sbbs3/ftpsrvr.c
Log Message:
Allow uploaders to remove files (via FTP) files that they uploaded

... by comparing the uploader name to their user alias (how it's done in the terminal server).

Fixes issue #952

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net