This has been happening for the longest time. Not sure what the issue is? Noticed it the other day in a week old fidopoll.log
Apr 16 13:55:53 VER Mystic/1.12A31 binkp/1.0
Apr 16 13:55:53 Recv: ADR 9:91/26@SurvNet 21:2/103@FSXNet
Apr 16 13:55:53 Sent: PWD CRAM-MD5-0799055af7f674e2ec9c2f1a15ea8c24
Apr 16 13:55:53 Authorization State: 5 HH:0 NH:1
Apr 16 13:55:53 Recv: OK secure
Apr 16 13:55:53 Authorization State: 5 HH:1 NH:0
Apr 16 13:55:53 State RxS:1 TxS:1 HH:0 NH:1
Apr 16 13:55:53 Sending A713MG8N.TIC (941 bytes)
Apr 16 13:55:53 Sent: FILE A713MG8N.TIC 941 1491527246 0
Apr 16 13:55:54 State RxS:1 TxS:2 HH:0 NH:1
Apr 16 13:55:54 Sent: Data 941
Apr 16 13:55:54 Recv: EOB
Apr 16 13:55:54 State RxS:1 TxS:3 HH:1 NH:0
Apr 16 13:55:54 Invalid data frame
Apr 16 13:55:54 Recv: EOB secure6@SurvNet 21:2/103@FSXNet234423416aee12
Apr 16 13:55:54 State RxS:3 TxS:3 HH:0 NH:1
Apr 16 13:55:54 Remote disconnect
Apr 16 13:55:54 Session complete (0 sent, 0 rcvd, 0 skip)
{snip}
WTF does secure6@SurvNet mean? I've never seen this before now. Anyway, the reason for The Sending A713MG8N.TIC seems to have caused the Invalid data frame. When this happens the node boxes start to full up with files that
never get sent out. This is the only node out of many having issues that is a mystic system. *shrug* I'm also a mystic system .. hehe *shrug* lol (:

--- Mystic BBS v1.12 A31 (Windows)
* Origin: flupH | fluph.darktech.org (21:1/105)

On 04/16/17, Skuz pondered and said...

Noticed it the other day in a week old fidopoll.log
Apr 16 13:55:53 VER Mystic/1.12A31 binkp/1.0
Apr 16 13:55:53 Recv: ADR 9:91/26@SurvNet 21:2/103@FSXNet
Apr 16 13:55:53 Sent: PWD CRAM-MD5-0799055af7f674e2ec9c2f1a15ea8c24
Apr 16 13:55:53 Authorization State: 5 HH:0 NH:1
Apr 16 13:55:53 Recv: OK secure
Apr 16 13:55:53 Authorization State: 5 HH:1 NH:0
Apr 16 13:55:53 State RxS:1 TxS:1 HH:0 NH:1

for what it's worth I'd ask Kevin to change his domain names to lower case

Apr 16 13:55:53 Sending A713MG8N.TIC (941 bytes)
Apr 16 13:55:53 Sent: FILE A713MG8N.TIC 941 1491527246 0
Apr 16 13:55:54 State RxS:1 TxS:2 HH:0 NH:1
Apr 16 13:55:54 Sent: Data 941
Apr 16 13:55:54 Recv: EOB
Apr 16 13:55:54 State RxS:1 TxS:3 HH:1 NH:0
Apr 16 13:55:54 Invalid data frame
Apr 16 13:55:54 Recv: EOB secure6@SurvNet 21:2/103@FSXNet234423416aee12 Apr 16 13:55:54 State RxS:3 TxS:3 HH:0 NH:1
Apr 16 13:55:54 Remote disconnect

So this is from 21?2/103 right? I'd say he has that tic file in his inbound
and needs to delete it before you try sending it again. The error you see is quite likely related to the reason the remote disconnect is also occurring.
He should also take a look at how his Mystic system is processing incoming files and if there are any in his badfile dir.

Best, Paul

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

17 Apr 17 10:54, you wrote to me:

for what it's worth I'd ask Kevin to change his domain names to lower
case

I've already told Kevin weeks ago that i follow the old school rule-of-thumb that the network domain names should match in lower case letters. Even though when i said this too Pequtio he replied, "That really doesn't matter" and never

follows that why of thinking. He seems to never have any problems processing mail either. Never-the-less, I don't think mystic cares what the CASE/case is as long it is spelled right. g00r00 might have something else to say about it. That's probably not going to happen anytime soon.. *shrug* What ever his reasons for leaving HIS Mystic support people ONLY he know for sure. I degress

Apr 16 13:55:53 Sending A713MG8N.TIC (941 bytes)
Apr 16 13:55:54 Invalid data frame
Apr 16 13:55:54 Recv: EOB secure6@SurvNet 21:2/103@FSXNet
Apr 16 13:55:54 State RxS:3 TxS:3
HH:0 NH:1 Apr 16 13:55:54 Remote disconnect

So this is from 21?2/103 right? I'd say he has that tic file in his inbound and needs to delete it before you try sending it again. The
error you see is quite likely related to the reason the remote
disconnect is also occurring. He should also take a look at how his
Mystic system is processing incoming files and if there are any in his badfile dir.

Yes Kevin (The Alchemist) bbs name : Resistance Pride system OS : Ubuntu is a member of 2 networks 9:91/26@survnet and 21:2/103@fsxnet the above log was my system fidopoll 9:91/26 so you see above after the Invalid data frame next line

seems to overwrite EOB secure causing the aka 9:91/26@survnet in the log to be not a real address. I do agree that he may have that same TIC in his inbound. I've seem mystic fail to send many files, that will sit in the inbound with (0-bytes) because they fail and abort the connection. Even when a system op config mystic to Skip/Rename these files. I feel there is still issues with mystic transfer of data with other systems. Out of all the other system that connect here the most stable is Binkd/binkp. It hardly never fails the send many files in just one session. It's rare to see it having to resend again. Well Mystic is struggling to just send 1-file at a time, that is on a good day.

I'm not bias or putting down any bbs software.. just stating the facts as I see

them... Just the fact.. ma'am.. Alot depends on how mystic -cfg is setup.

--- GoldED+/W32-MSVC 1.1.5-b20160201
* Origin: flupH * fluph.darktech.org (1:275/91)

On 04/16/17, Skuz pondered and said...

for what it's worth I'd ask Kevin to change his domain names to lower case

I've already told Kevin weeks ago that i follow the old school rule-of-thumb that the network domain names should match in lower case letters. Even though when i said this too Pequtio he replied, "That
really doesn't matter" and never
follows that why of thinking. He seems to never have any problems processing mail either. Never-the-less, I don't think mystic cares what the CASE/case is as long it is spelled right. g00r00 might have

Well there were some issues that had been picked up a few alphas ago with Mystic systems exceeding a certain number of AKAs having issues with polling. But that one was debugged by Solaris and I and g00r00 fixed it. I think case can matter, depending on the systems involved in the exchange. As such I
always advocate keeping things lowercase.

the CASE/case is as long it is spelled right. g00r00 might have
something else to say about it. That's probably not going to happen anytime soon.. *shrug* What ever his reasons for leaving HIS Mystic support people ONLY he know for sure. I degress

I have had contact with him last month, fair to say he's got a lot on his plate. While his capacity to support Mystic at the pace we saw earlier is not there. I'm told by him he has not lost interest. I remain optimistic that in time we will see some further developments. For now I'm just boxing on with
the Wiki, supporting others etc :)

Yes Kevin (The Alchemist) bbs name : Resistance Pride system OS : Ubuntu is a member of 2 networks 9:91/26@survnet and 21:2/103@fsxnet the above log was my system fidopoll 9:91/26 so you see above after the Invalid
data frame next line
seems to overwrite EOB secure causing the aka 9:91/26@survnet in the log to be not a real address. I do agree that he may have that same TIC in

I'm not convinced the logging is causing the error. Rather the .tic file is
in his inbound and is the root cause of this time - that's my best guess at
the moment :)

his inbound. I've seem mystic fail to send many files, that will sit in the inbound with (0-bytes) because they fail and abort the connection. Even when a system op config mystic to Skip/Rename these files. I feel there is still issues with mystic transfer of data with other systems.

I think OS may play a part here also. I have had 1-2 recent errors using
MIS2 under Windows 7 where a packet from Tony 1/109 has been locked by MIS2 after it arrived via IPv6 and MUTIL has been able to toss it in several
times, the second and subsequent times as DUPES.

Binkd/binkp. It hardly never fails the send many files in just one session. It's rare to see it having to resend again. Well Mystic is

Agreed. I really don't use FTP much for echomail/netmail so can't comment
about that. Have used DIRECTORY before and it's works well.

session. It's rare to see it having to resend again. Well Mystic is struggling to just send 1-file at a time, that is on a good day.
I'm not bias or putting down any bbs software.. just stating the facts
as I see
them... Just the fact.. ma'am.. Alot depends on how mystic -cfg is setup.

So you're saying your seeing repeated problems with BinkP transfers with this node as you describe above?

Best, Paul

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 04/17/17, Avon said the following...

I think case can matter, depending on the systems involved in the exchange. As such I always advocate keeping things lowercase.

Agreed, it's to bad .. most system ops just type whatever looks cool to them. With two mystic systems, it would seen processing one networks msg mixed case seems to be the more often then not.

I have had contact with him last month, fair to say he's got a lot on his plate. While his capacity to support Mystic at the pace we saw earlier
is not there. I'm told by him he has not lost interest. I remain optimistic that in time we will see some further developments. For now
I'm just boxing on with the Wiki, supporting others etc :)

I remember those days when I had 3 jobs because of obligations, the love of love money needed to live a certain life style. Would keep anyone busy with a lot on his plate. It can be hard to weight the pros and cons of exactly what makes a person most happy in life. For me at this stage, it's simple.. Family and friends. Thank goodness, the days of being a workaholic slave for the system are long gone over here. Alcoholiday can be any day, no pun intended. What a nice name for a board (:

I'm not convinced the logging is causing the error. Rather the .tic file

I'm not saying any of the logging caused any error, just pointing out that
the logging is flawed. .TIC files in the /inbound that are not processed or renamed or moved are pretty much the problem. IMO

So you're saying your seeing repeated problems with BinkP transfers with this node as you describe above?

Yes, since he joined survnet several weeks ago. I've always noticed Mystic
have problems with transfers of multipliable files here. Even to myself on another Mystic system or point system Box with another OS. The first file transfer alway going smooth, second file fails, but remains in the system /inbound as zero-bytes. Hence the reconnecting to finish all file transfers successful. This is not good and causes the receiving system to just keep renaming file after file until all files are transfered. In other words, if there are 10 files, TEN separate connection are made over time. Because only one file gets sent at time, the reason why this been the case dates way back
to when I first brought it up to g00r00 last spring. The issue was never address and just ignored by everyone who read the public post. Sadly it have been to long and i never saved the post. But is was on point and quite long. For all I know maybe everyone skipped reading anything about the transfer
issue of mystic failing to send multitude of file in just one secession with another mystic system. Way back then mystic was on version 1.12a9 and today
the problem still exist here anyway. Hatched files from file boxes are not effected...(except) for Kavin system. This only happens with mail packet/bundles 85% of the time they fail. Sorry for a long winded reply.

--- Mystic BBS v1.12 A31 (Windows)
* Origin: flupH | fluph.darktech.org (21:1/105)

On 04/17/17, Skuz pondered and said...

Agreed, it's to bad .. most system ops just type whatever looks cool to them. With two mystic systems, it would seen processing one networks msg mixed case seems to be the more often then not.

It's hard to say for sure if it is a contributing factor but at least keeping it all lowercase standardises things and (for me) removes one possible niggle.

I remember those days when I had 3 jobs because of obligations, the love of love money needed to live a certain life style. Would keep anyone
busy with a lot on his plate. It can be hard to weight the pros and cons of exactly what makes a person most happy in life. For me at this stage, it's simple.. Family and friends. Thank goodness, the days of being a workaholic slave for the system are long gone over here. Alcoholiday can be any day, no pun intended. What a nice name for a board (:

Heh... I see what you did there. Must pop over and visit. Hopped on to
Cyberia and Black Flag the other day Fluph and Alcoholiday are next up :)

I agree with your thoughts, I'm still at the stage of working with kids at school but those years are numbered.

I'm not saying any of the logging caused any error, just pointing out
that the logging is flawed. .TIC files in the /inbound that are not processed or renamed or moved are pretty much the problem. IMO

Gotcha.

So you're saying your seeing repeated problems with BinkP transfers w this node as you describe above?

Yes, since he joined survnet several weeks ago. I've always noticed
Mystic have problems with transfers of multipliable files here. Even to myself on another Mystic system or point system Box with another OS. The first file transfer alway going smooth, second file fails, but remains
in the system /inbound as zero-bytes. Hence the reconnecting to finish
all file transfers successful. This is not good and causes the receiving system to just keep renaming file after file until all files are transfered. In other words, if there are 10 files, TEN separate

I should like to repro that but may take some time to set up a test scenario. I'd also like to understand how your files are being sent (fidopoll?) and
what the config setting are at your Mystic end for the sending and receiving systems you're reporting issues with.

in the system /inbound as zero-bytes. Hence the reconnecting to finish
all file transfers successful. This is not good and causes the receiving system to just keep renaming file after file until all files are transfered. In other words, if there are 10 files, TEN separate
connection are made over time. Because only one file gets sent at time, the reason why this been the case dates way back to when I first brought it up to g00r00 last spring. The issue was never address and just
ignored by everyone who read the public post. Sadly it have been to long and i never saved the post. But is was on point and quite long. For all
I know maybe everyone skipped reading anything about the transfer issue
of mystic failing to send multitude of file in just one secession with another mystic system. Way back then mystic was on version 1.12a9 and today the problem still exist here anyway. Hatched files from file boxes are not effected...(except) for Kavin system. This only happens with
mail packet/bundles 85% of the time they fail. Sorry for a long winded rep

OK so this issue is really about BinkP receiving multiple echomail packets in one session and getting hung up with the 2nd and subsequent packets during a single session? Just asking this to be clear that's what you are saying is
the problem as you see it? Sounds like file box stuff is not a problem.

Long winded replies are fine! :)

Best, Paul

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

for what it's worth I'd ask Kevin to change his domain names to lower
case

I did and it didn't change a thing.

disconnect is also occurring. He should also take a look at how his
Mystic system is processing incoming files and if there are any in his badfile dir.

So I did some digging, and both mutil and fidopoll were reporting busy nodes both for FSXNet and for SurvNet.

I eventually did a "./fidopoll killbusy" after fighting with it for a bit, and I *THINK* things have started flowing again.

-*- The Alchemist -*-
-*- Resistance Pride BBS -*-
-*- resistancepride.sytes.net -*

--- Mystic BBS v1.12 A31 (Linux)
* Origin: Resistance Pride BBS (21:2/103)

On 04/17/17, The Alchemist said the following...

I eventually did a "./fidopoll killbusy" after fighting with it for a
bit, and I *THINK* things have started flowing again.

I created a script to poll:
#!/bin/bash
# poll
./fidopoll killbusy #make sure
rm -rf /mystic/semaphore/fidopoll.bsy #blindly kill it
./fidopoll 21:1/100
./mutil mailin.ini
./mutil mailout.ini

That seems to always work and clears any errors that appear. You just add whatever other systems you want to poll after fsxnet (21:1/100) as another fidopoll. When I just did fidopoll without the killbusy & rm random stuff often hung it after a few days. This way it never hangs and always works. I have it setup in the Message areas as E - Extrapoll so anyone can get the latest with a quick command (and force a message they just wrote to send).

--- Mystic BBS v1.12 A31 (Raspberry Pi)
* Origin: Mystic Pi BBS bcw142.zapto.org (21:1/145)

On 04/18/17, bcw142 pondered and said...

On 04/17/17, The Alchemist said the following...

I eventually did a "./fidopoll killbusy" after fighting with it for a bit, and I *THINK* things have started flowing again.

I created a script to poll:
#!/bin/bash
# poll
./fidopoll killbusy #make sure
rm -rf /mystic/semaphore/fidopoll.bsy #blindly kill it
./fidopoll 21:1/100

I would take this a tad further since running the kilbusy is not always
needed.

if [ -f /mystic/semaphore/fidopoll.bsy ]; then
./fidopoll killbusy
fi

Also -rf is not needed unless you plan to remove an actual folder that is not empty, simple rm /mystic/semaphore/fidopoll.bsy will work.

But I would suggest the if statement to check if the file exists then run the process this way you are not running anything you do not need.

Cheers!
Pequito

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 04/19/17, Pequito pondered and said...

I would take this a tad further since running the kilbusy is not always needed.

Hey good sir... nice to see you active in these here parts of the digital bad lands :) Hope you're doing well.

Best, Paul

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 04/19/17, Pequito said the following...

On 04/18/17, bcw142 pondered and said...

I created a script to poll:
#!/bin/bash # poll
./fidopoll killbusy #make sure
rm -rf /mystic/semaphore/fidopoll.bsy #blindly kill it

I would take this a tad further since running the kilbusy is not always needed.

if [ -f /mystic/semaphore/fidopoll.bsy ]; then
./fidopoll killbusy
fi

Also -rf is not needed unless you plan to remove an actual folder that
is not empty, simple rm /mystic/semaphore/fidopoll.bsy will work.

Likely true on both points, revised the script just now to:
#!/bin/bash
# poll
#echo "Checking for fidopoll.bsy semaphore"
if [ -f /mystic/semaphore/fidopoll.bsy ]; then
./fidopoll killbusy && rm /mystic/semaphore/fidopoll.bsy
fi
/mystic/fidopoll 21:1/100
/mystic/mutil mailin.ini
/mystic/mutil /mystic/mailout

--- Mystic BBS v1.12 A31 (Raspberry Pi)
* Origin: Mystic Pi BBS bcw142.zapto.org (21:1/145)

On 04/19/17, Avon pondered and said...

On 04/19/17, Pequito pondered and said...

I would take this a tad further since running the kilbusy is not alwa needed.

Hey good sir... nice to see you active in these here parts of the
digital bad lands :) Hope you're doing well.

Things are moving along but still work in progress with things on my end and prob will be for most part of the year. I will be popping in here and there.

Cheers!
Pequito

--- Mystic BBS v1.12 A32 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

again. Well Mystic is struggling to just send 1-file at a time, that is
on a good day. I'm not bias or putting down any bbs software.. just stating the facts as I see them... Just the fact.. ma'am.. Alot depends on

Can you give more detail?

What is the other system using to connect to you? Is it IREX?

--- Mystic BBS v1.12 A32 (Windows)
* Origin: flupH | fluph.darktech.org (21:1/105)

On 05/06/17, g00r00 said the following...

again. Well Mystic is struggling to just send 1-file at a time, that on a good day. I'm not bias or putting down any bbs software.. just

Can you give more detail?
What is the other system using to connect to you? Is it IREX?

Yes I can give some details and have sent log files too Avon in the passed. There is only 2 mystic system here the main hub 1:275/91 and 1:275/94
the /94 calls /91 with fidopoll 1:275/91 that has lots of files waiting.
May 06 14:42:33 Polling BINKP node 1:275/91
May 06 14:42:33 Connecting to fluph.zapto.org
May 06 14:42:33 Connected
May 06 14:42:33 Authorization State: 1 HH:0 NH:1
May 06 14:42:33 Sent: NUL SYS flupH
May 06 14:42:33 Sent: NUL ZYZ Leslie Given
May 06 14:42:33 Sent: NUL VER Mystic/1.12A31 binkp/1.0
May 06 14:42:33 Sent: ADR 1:275/94@fidonet 46:1/102.1@agoranet 21:1/105.1@fsxnet 911:1304/10@zeronet 44:100/2.10@dorenet 9:91/1.1@survnet 77:1/172.1@scinet 411:411/8.1@combatnt
May 06 14:42:34 Authorization State: 2 HH:0 NH:1
May 06 14:42:38 Recv: NUL OPT CRAM-MD5-457e19a1642236104131ae01791a91e8
May 06 14:42:38 Authorization State: 2 HH:1 NH:0
May 06 14:42:38 OPT CRAM-MD5-457e19a1642236104131ae01791a91e8
May 06 14:42:38 Received challenge (457e19a1642236104131ae01791a91e8)
May 06 14:42:38 Authorization State: 2 HH:0 NH:1
May 06 14:42:38 Recv: NUL SYS flupH
May 06 14:42:38 Authorization State: 2 HH:1 NH:0
May 06 14:42:38 SYS flupH
May 06 14:42:38 Recv: NUL ZYZ Leslie Given
May 06 14:42:38 ZYZ Leslie Given
May 06 14:42:38 Recv: NUL VER Mystic/1.12A32 binkp/1.0
May 06 14:42:38 VER Mystic/1.12A32 binkp/1.0
May 06 14:42:38 Recv: ADR 1:275/91@fidonet 46:1/102@agoranet 21:1/105@fsxnet 911:1304/0@zeronet 44:100/2@dorenet 9:91/1@survnet 9:91/0@survnet 77:1/172@scinet 411:411/8@combatnt
May 06 14:42:38 Sent: PWD CRAM-MD5-07931e09c9551590049c5ec4807c5db1
May 06 14:42:38 Authorization State: 5 HH:0 NH:1
May 06 14:42:38 Recv: OK secure
May 06 14:42:38 Authorization State: 5 HH:1 NH:0
May 06 14:42:38 State RxS:1 TxS:1 HH:0 NH:1
May 06 14:42:38 Sent: EOB
May 06 14:42:38 State RxS:1 TxS:4 HH:0 NH:1
May 06 14:42:38 Recv: FILE 00000001.we0 4706 1493774282 0
May 06 14:42:38 State RxS:1 TxS:4 HH:1 NH:0
May 06 14:42:38 Receiving 00000001.we0 (4,706 bytes)
May 06 14:42:39 State RxS:2 TxS:4 HH:0 NH:1
May 06 14:42:39 Recv: Data 4,706/4,706
May 06 14:42:39 State RxS:2 TxS:4 HH:1 NH:0
May 06 14:42:39 Received Rx Data 4706
May 06 14:42:39 Sent: GOT 00000001.we0 4706 1493774282
May 06 14:42:39 State RxS:1 TxS:4 HH:0 NH:1
May 06 14:42:39 Recv: FILE 00000001.th0 4716 1493860724 0
May 06 14:42:39 State RxS:1 TxS:4 HH:1 NH:0
May 06 14:42:39 Receiving 00000001.th0 (4,716 bytes)
May 06 14:42:39 Invalid data frame
May 06 14:42:39 Recv: FILE 00000001.th0 4716 1493860724 001ca6ae0.pktSDg ¬ ød`i {snip} there is a lot is data code displayed in the log here. Ending in May 06 14:42:39 State RxS:2 TxS:4 HH:0 NH:1
May 06 14:42:39 Remote disconnect
May 06 14:42:39 Session complete (0 sent, 1 rcvd, 0 skip) ----------------------------------------------------------
On the /91 binkp_server.log showing the connection.
May 06 14:48:42 0 Connect: 192.168.1.1 (Unknown)
May 06 14:48:42 1 SYS flupH
May 06 14:48:42 1 ZYZ Leslie Given
May 06 14:48:42 1 VER Mystic/1.12A31 binkp/1.0
May 06 14:48:42 1 ADR 1:275/94@fidonet 46:1/102.1@agoranet 21:1/105.1@fsxnet 91 1:1304/10@zeronet 44:100/2.10@dorenet 9:91/1.1@survnet
May 06 14:48:42 1 Authenticating 411:411/8.1@combatnt by CRAM-MD5
May 06 14:48:42 1 Password accepted
May 06 14:48:42 1 Queuing for 411:411/8.1@combatnt by CRAM-MD5
May 06 14:48:42 1 Password accepted
May 06 14:48:42 1 Queued 3 files for 411:411/8.1
May 06 14:48:42 1 Sending 00000001.th0 (4,716 bytes)
May 06 14:48:43 1 Sending 00000001.fr0 (7,460 bytes)
May 06 14:48:43 1 Remote disconnect
May 06 14:48:43 1 Session complete (1 sent, 0 rcvd, 0 skip) -----------------------------------------------------------
In closing, file 00000001.we0 where good and processed. 00000001.th0 failed file 00000001.fr0 (7,460 bytes) failed and was on /94 inbound as 0 bytes. I'll email you the fidopoll.log with the {snipped} out data code missing from this message post. The other 4 systems are all DOS boards using IREX as frontends they also poll and receive just one file at a time. With the 2nd file having
0 bytes because it also fails with a invalid data frame. I know IREX as problem that is why I stopped using it as my main hub system months ago. I'd just like to get passed this sending just one file at a time thing.

--- Mystic BBS v1.12 A32 (Windows)
* Origin: flupH | fluph.darktech.org (21:1/105)