Hey Rob,
I was playing with FTN messages with attachments today and it didnt work completely...
I'm sending from:
SBBS/BINKIT 516:1/2 -> BINKD/HPT 516:516/0 -> SBBS/BINKIT 516:1/1
The message left 1/2 fine, 516/0 processed it fine and sent it to 1/1 (including the attachment).
However, when 1/1 went to import it, it was looking for the attachment in nonsecure, when in fact it was a secure transfer:
2020-07-18 17:25:29 Importing /opt/sbbs/fido/inbound/9e6eb2ff.pkt (Type 2e, 0.8KB) from 516:516/0 to 516:1/1
2020-07-18 17:25:29 MV ERROR: Source doesn't exist '/opt/sbbs/fido/nonsecure/test
2020-07-18 17:25:29 Deon George (516:1/2) To: alterego (516:1/1) Imported
(The attachment "test" is in /opt/sbbs/fido/inbound.)
From 1/1's POV, 516/0 is defined in sbbsecho.ini and thus should be a secure session - so it shouldnt be looking for attachments from that node in unsecure.
Right?
Re: Routed FTN messages with attachments
By: alterego to Digital Man on Sat Jul 18 2020 05:42 pm
Hey Rob,
I was playing with FTN messages with attachments today and it didnt work completely...
I'm sending from:
SBBS/BINKIT 516:1/2 -> BINKD/HPT 516:516/0 -> SBBS/BINKIT 516:1/1
The message left 1/2 fine, 516/0 processed it fine and sent it to 1/1 (including the attachment).
However, when 1/1 went to import it, it was looking for the attachment in nonsecure, when in fact it was a secure transfer:
2020-07-18 17:25:29 Importing /opt/sbbs/fido/inbound/9e6eb2ff.pkt (Type 2e, 0.8KB) from 516:516/0 to 516:1/1
2020-07-18 17:25:29 MV ERROR: Source doesn't exist '/opt/sbbs/fido/nonsecure/test
2020-07-18 17:25:29 Deon George (516:1/2) To: alterego (516:1/1) Imported
(The attachment "test" is in /opt/sbbs/fido/inbound.)
From 1/1's POV, 516/0 is defined in sbbsecho.ini and thus should be a secure session - so it shouldnt be looking for attachments from that node in unsecure.
Right?
Right. I'll experiment and see if I can reproduce (and then fix) the issue.
2020-07-18 17:25:29 MV ERROR: Source doesn't exist
'/opt/sbbs/fido/nonsecure/test
Right. I'll experiment and see if I can reproduce (and then fix) the issue.
And I tested it here and it worked fine:
And the attfile.txt was successfully moved to my data/user/0001.in directory and attached to the email.
What version of SBBSecho are you using?
having. Assuming you're willing to do some more testing?
Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 12:24 pm
2020-07-18 17:25:29 MV ERROR: Source doesn't exist
'/opt/sbbs/fido/nonsecure/test
Right. I'll experiment and see if I can reproduce (and then fix) the issue.
I wanted to suggest as well, that when you send attachments, that the attachment is renamed to something that is likely to be more unique, while it is transferring, but is downloadable with its original name.
I know this might be a long shot? IE: Other software may not know how to rename it back?
The scenario I was thinking might be a problem is if 2 people send 2 different attachments with the same name, that are in the fido/inbound at the same time. It seems that the second file coming in (with the same name) clobers the first?
(I had exactly that while testing this..)
Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 04:36 pm
And I tested it here and it worked fine:
And the attfile.txt was successfully moved to my data/user/0001.in directory and attached to the email.
Dont you hate it when that happens? :)
What version of SBBSecho are you using?
Fairly recent build: Built 10 days ago. (Running on a Pi)
SBBSecho v3.11-Linux (rev 3.173) - Synchronet FidoNet EchoMail Tosser
having. Assuming you're willing to do some more testing?
Yes, happy to.
And in case you need it - here is binkp:
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP BinkIT/2.39 invoked with options:
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP JSBinkP/1.123 inbound connection from 172.17.0.1:54306
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Peer version: binkd/1.1a-109/Linux binkp/1.1
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Will encrypt session.
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Remote addresses: 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Inbound session for: 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP CRAM-MD5 password match for 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Receiving file: /opt/sbbs/temp/9e6eb2ff.pkt (0.8KB)
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Received file: /opt/sbbs/temp/9e6eb2ff.pkt (0.8KB)
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Moving '/opt/sbbs/temp/9e6eb2ff.pkt' to '../fido/inbound/9e6eb2ff.pkt'.
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Receiving file: /opt/sbbs/temp/test (2960.3KB)
There should've been more log lines with regards to "test" (Received, Moving).
Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 08:28 pm
There should've been more log lines with regards to "test" (Received, Moving).
Yes, there was, strangely this session took all up 7 minutes to "complete":
(It took 7 mins to complete this binkit session - 17:22:08 to 17:29:24, and the 2 systems are on the same host... <wondering if that is related>?)
Here is the complete log:
$ sudo grep 0020 /var/log/messages|grep "Jul 18"|grep 17:2
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP connection accepted from: 172.17.0.1 port 54306
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP BinkIT/2.39 invoked with options:
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP JSBinkP/1.123 inbound connection from 172.17.0.1:54306
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Peer version: binkd/1.1a-109/Linux binkp/1.1
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Will encrypt session.
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Remote addresses: 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Inbound session for: 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP CRAM-MD5 password match for 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Receiving file: /opt/sbbs/temp/9e6eb2ff.pkt (0.8KB)
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Received file: /opt/sbbs/temp/9e6eb2ff.pkt (0.8KB)
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Moving '/opt/sbbs/temp/9e6eb2ff.pkt' to '../fido/inbound/9e6eb2ff.pkt'.
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Receiving file: /opt/sbbs/temp/test (2960.3KB)
Jul 18 17:25:37 p-1-1 synchronet: srvc 0020 BINKP Received file: /opt/sbbs/temp/test (2960.3KB)
Jul 18 17:25:37 p-1-1 synchronet: srvc 0020 BINKP Moving '/opt/sbbs/temp/test' to '../fido/inbound/test'.
Jul 18 17:29:24 p-1-1 synchronet: srvc 0020 BINKP service thread terminated (0 clients remain, 0 total, 409 served)
Jul 18 17:29:24 p-1-1 synchronet: srvc 0020 BINKP service thread terminated
(0 clients remain, 0 total, 409 served)
If you have SBBSecho running frequently and independantly of BinkIT, that could cause a race condition where the netmail message is processed while the attached file hasn't yet been full received.
If you send a smaller file, do you have the same problem?
Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 08:52 pm
Jul 18 17:29:24 p-1-1 synchronet: srvc 0020 BINKP service thread terminated
(0 clients remain, 0 total, 409 served)
If you have SBBSecho running frequently and independantly of BinkIT, that could cause a race condition where the netmail message is processed while the attached file hasn't yet been full received.
In this case, no, sbbsecho started 4 seconds after:
Jul 18 17:29:24 p-1-1 synchronet: srvc 0020 BINKP service thread terminated (0 clients remain, 0 total, 409 served)
Jul 18 17:29:25 p-1-1 synchronet: evnt DAILY Semaphore signaled for Timed Event: FIDOIN
Jul 18 17:29:25 p-1-1 synchronet: evnt FIDOIN Running native timed event: FIDOIN
Jul 18 17:29:31 p-1-1 synchronet: evnt FIDOIN Timed event: FIDOIN returned 0
sbbsecho.log
2020-07-18 17:25:29 Importing /opt/sbbs/fido/inbound/9e6eb2ff.pkt (Type 2e, 0.8KB) from 516:516/0 to 516:1/1
2020-07-18 17:25:29 MV ERROR: Source doesn't exist '/opt/sbbs/fido/nonsecure/test
2020-07-18 17:25:29 Deon George (516:1/2) To: alterego (516:1/1) Imported
If you send a smaller file, do you have the same problem?
Of it looking in insecure for the attachment? I'll try...
If you send a smaller file, do you have the same problem?
Well it first looks in the same directory as the packet (in this case, /opt/sbbs/fido/inbound), but that's not logged and *then* it looks in the other directory (e.g. your non-secure inbound). This is more clear with the newest commit which added a few more log messages.
It sounds like the file wasn't in the inbound at the time that SBBSecho looked.
The scenario I was thinking might be a problem is if 2 people send 2
different attachments with the same name, that are in the fido/inbound
at the same time. It seems that the second file coming in (with the
same name) clobers the first?
(I had exactly that while testing this..)
Yeah, file attachments in FidoNet were not very well designed.
| Sysop: | Chris Crash |
|---|---|
| Location: | Huntington Beach, CA. |
| Users: | 578 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 02:44:29 |
| Calls: | 10,736 |
| Files: | 5 |
| Messages: | 443,450 |