Hello everyone,

Just wanted to check if any of you have had any problems connecting through passive FTP to dove.synchro.net when performing your DOVE-Net QWK polls? Especially if some of you are running Mystic BBS and its QWKPOLL utility for polling.

For me, I seem to encounter those problems when communicating with 71.95.196.34, not 71.95.196.36 (dove.synchro.net resolves to both those IPs):

Aug 15 06:52:48 QWKPOLL Startup (v1.12 A46 Linux/64 Compiled 2020/06/11 15:13:18)
Aug 15 06:52:48 Exchanging Mail for DOVE-Net
Aug 15 06:52:48 Exported @VERT.rep -> 0 msgs
Aug 15 06:52:48 Connecting via FTP to dove.synchro.net
Aug 15 06:52:48 R:220-Vertrauen (cvs.synchro.net)
Aug 15 06:52:48 Connected
Aug 15 06:52:48 Local IP is 188.149.129.150
Aug 15 06:52:48 S:USER SCBBS
Aug 15 06:52:49 R:331 User name okay, need password.
Aug 15 06:52:49 S:PASS <not shown>
Aug 15 06:52:49 R:230-Welcome!
Aug 15 06:52:49 S:TYPE I
Aug 15 06:52:49 R:200 All files sent in BINARY mode.
Aug 15 06:52:49 S:MODE S
Aug 15 06:52:49 R:200 STREAM mode.
Aug 15 06:52:49 Logged in as SCBBS
Aug 15 06:52:49 Downloading QWK packet
Aug 15 06:52:49 S:PASV
Aug 15 06:52:49 R:227 Entering Passive Mode (71,95,196,36,4,1)
Aug 15 06:52:50 S:RETR VERT.qwk
Aug 15 06:52:50 R:150 Opening BINARY mode data connection for file transfer. Aug 15 06:52:50 R:226 Download complete (21314 cps).
Aug 15 06:52:50 OK: VERT.qwk (10,657 bytes)
Aug 15 06:52:50 Importing QWK packet:
Aug 15 06:52:50 Imported 17 messages (0 failed)

Aug 15 06:52:58 QWKPOLL Startup (v1.12 A46 Linux/64 Compiled 2020/06/11 15:13:18) Aug 15 06:52:58 Exchanging Mail for DOVE-Net
Aug 15 06:52:58 Exported @VERT.rep -> 0 msgs
Aug 15 06:52:58 Connecting via FTP to dove.synchro.net
Aug 15 06:52:59 R:220-Vertrauen (vert.synchro.net)
Aug 15 06:52:59 Connected
Aug 15 06:52:59 Local IP is 188.149.129.150
Aug 15 06:52:59 S:USER SCBBS
Aug 15 06:52:59 R:331 User name okay, need password.
Aug 15 06:52:59 S:PASS <not shown>
Aug 15 06:52:59 R:230-Welcome!
Aug 15 06:52:59 S:TYPE I
Aug 15 06:53:00 R:200 All files sent in BINARY mode.
Aug 15 06:53:00 S:MODE S
Aug 15 06:53:00 R:200 STREAM mode.
Aug 15 06:53:00 Logged in as SCBBS
Aug 15 06:53:00 Downloading QWK packet
Aug 15 06:53:00 S:PASV
Aug 15 06:53:00 R:227 Entering Passive Mode (71,95,196,34,7,208)
Aug 15 06:53:00 S:RETR VERT.qwk
Aug 15 06:53:10 Unable to open data connection

I've tried debugging this using tcpdump earlier, but it just appears that it gets no response on the passive FTP port. I have double-checked that QWKPOLL connects to the correct port as per the PASV reply. It seems to be
consistent, i.e. I never succeed with the PASV connection to 71.95.196.34 for some reason, and 71.95.196.36 always works.

Other than that, things seem to be working just fine.

Many thanks in advance, and wishing you all a nice summer! :)

Best regards
Zip

--- Mystic BBS v1.12 A46 2020/08/11 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden

Re: Passive FTP problems?
By: Zip to All on Sat Aug 15 2020 08:29 am

Just wanted to check if any of you have had any problems connecting through passive FTP to dove.synchro.net when performing your DOVE-Net QWK polls?

Passive is the default mode of the Synchronet QNET-FTP scripts (qnet-ftp.src and qnet-ftp.js), so almost all of the QWKnet FTP transfers on Vertrauen are using passive FTP. And they're working. <shrug>

I don't know why you'd only have a problem with my Win10 server (vert.synchro.net). Sounds like maybe there's some difference in behavior (the passive port number?) which is triggering a problem in the Mystic FTP client code. You can use cvs.synchro.net instead of dove.synchro.net if you want to avoid my Win10 server, but that's more of a work-around than an actual solution.


digital man

Synchronet/BBS Terminology Definition #20:
DOCSIS = Data Over Cable Service Interface Specification
Norco, CA WX: 79.3øF, 53.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs

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

Hello Digital Man!

Thank you for your reply!

On 15 Aug 2020, Digital Man said the following...

qnet-ftp.js), so almost all of the QWKnet FTP transfers on Vertrauen are passive FTP. And they're working. <shrug>

Ah, yes, I thought so. :)

I see that when performing the RETR, .36 takes approximately 5 seconds to produce the "550 No QWK packet created" reply after ACKing the receipt of the RETR TCP packet, whereas .34 after 10 seconds still hasn't sent any reply back although it has ACKed the receipt of the RETR TCP packet:

[.36 example below]

00:00:01.582617 IP (tos 0x0, ttl 64, id 57482, offset 0, flags [DF], proto
TCP (6), length 67)
192.168.1.5.53524 > 71.95.196.36.21: Flags [P.], cksum 0xcd66 (incorrect

0xb88a), seq 51:66, ack 941, win 501, options [nop,nop,TS val 880616242

ecr 769876135], length 15: FTP, length: 15
RETR VERT.qwk
00:00:01.814724 IP (tos 0x0, ttl 51, id 54843, offset 0, flags [DF], proto
TCP (6), length 52)
71.95.196.36.21 > 192.168.1.5.53524: Flags [.], cksum 0x002e (correct),
seq 941, ack 66, win 227, options [nop,nop,TS val 769876241 ecr 880616242], length 0
00:00:06.772928 IP (tos 0x0, ttl 51, id 54844, offset 0, flags [DF], proto
TCP (6), length 97)
71.95.196.36.21 > 192.168.1.5.53524: Flags [P.], cksum 0x7538 (correct), seq 941:986, ack 66, win 227, options [nop,nop,TS val 769877480 ecr
880616242], length 45: FTP, length: 45
550 No QWK packet created (no new messages)

[.34 example below]

00:00:02.275149 IP (tos 0x0, ttl 64, id 7547, offset 0, flags [DF], proto
TCP (6), lengt
h 55)
192.168.1.5.56154 > 71.95.196.34.21: Flags [P.], cksum 0xcd58 (incorrect

0x7b40),

seq 51:66, ack 944, win 501, length 15: FTP, length: 15
RETR VERT.qwk
00:00:02.507122 IP (tos 0x0, ttl 115, id 44587, offset 0, flags [DF], proto TCP (6), len
gth 40)
71.95.196.34.21 > 192.168.1.5.56154: Flags [.], cksum 0xc02e (correct),
seq 944, ack
66, win 1026, length 0
00:00:12.289238 IP (tos 0x0, ttl 64, id 62468, offset 0, flags [DF], proto
TCP (6), length 40)
192.168.1.5.40204 > 71.95.196.34.2000: Flags [F.], cksum 0xcd49
(incorrect -> 0xf74e), seq 1, ack 1, win 502, length 0

Sorry for spamming you all with the very verbose dump excerpts -- but perhaps .34 simply takes longer time to gather all information for the reply than .36?

If so, I could ask g00r00 to raise the hard-coded QWKPOLL timeout of 10
seconds (or make it configurable).

Wishing you a nice weekend,

Best regards
Zip

--- Mystic BBS v1.12 A46 2020/08/11 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden

Re: Re: Passive FTP problems?
By: Zip to Digital Man on Sat Aug 15 2020 11:59 am

I see that when performing the RETR, .36 takes approximately 5 seconds to produce the "550 No QWK packet created" reply after ACKing the receipt of the RETR TCP packet, whereas .34 after 10 seconds still hasn't sent any reply back although it has ACKed the receipt of the RETR TCP packet:

I can't think of a reason why that delay time would be consistent in either case (.36 or .34) - there's only one thread that'll create (or try to create) QWK packets for all the FTP servers of the BBS. Its a serialized process (one packet at a time and there are usually one or more QWKnet nodes in the queue at any time) and that process (for each node) is definitely non-deterministic based on a lot of factors; it could take a lot longer than 10 seconds in *either* case (.36 or .34) to either create or fail to create a QWK packet for FTP-download.

If you're lucky, and there's no one else in the QWK-FTP queue (on Vertrauen) and there are no new messages in the DOVE-Net conferences, then yeah, the scan for new messages could be pretty consistent and it would be faster on .36 since that's the actual file server where the message bases are stored (and in general, the *nix builds of Synchronet run faster than the Windows builds).

digital man

This Is Spinal Tap quote #40:
Morty the Mime: Come on, don't talk back, mime is money, come on, move it. Norco, CA WX: 96.3øF, 33.0% humidity, 0 mph NE wind, 0.00 inches rain/24hrs

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

Hello Digital Man!

Thank you for your reply!

On 15 Aug 2020, Digital Man said the following...

I can't think of a reason why that delay time would be consistent in eithe case (.36 or .34) - there's only one thread that'll create (or try to crea

You're absolutely right -- as it is created "on demand" the times will vary. I'll ask g00r00 to raise that timeout in QWKPOLL; that should cure the "problem". :)

Thanks again! :)

Best regards
Zip

--- Mystic BBS v1.12 A46 2020/08/11 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden