• Re: BinkP Weirdness (Agency)

    From Avon@21:1/101 to StackFault on Wed Jan 29 11:55:29 2020
    On 28 Jan 2020 at 04:51p, StackFault pondered and said...

    I have most likely assumed Avon was running BinkD on both the hub and Agency, he might be running BinkD only on the Hub and Agency still runs Mystic BinkP.

    You're correct Agency is running Mystic BinkP and the 1/100 HUB is using
    BinkD at the moment. Because the MIS logs roll over so quick I may not have anything I can share until the next time it happens.. but it does seem to happen each time these files are sent.

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to StackFault on Tue Jan 28 18:25:06 2020
    If that is intentional for debugging purposes, this is fine by me. That may be a good idea to dump these debug packet in a separate file since they can break log processing tools (like one I'm using for my setup). That way you have the debug data AND the main log file remains clean.
    Just my 2c.

    The debug logging for BINKP and socket error message is only temporary. I don't think it changes the format of the log, it just adds additional lines. The only time it would balloon like that is when it receives jibberish from the remote BinkP client so it shouldn't happen regularly. Really I am too lazy to separate it right now ;)

    Ignore that troll trying to make issues. This is the same guy who is changing message "To" fields from g00r00 to p00p and message tear lines to "Garbage v1.12" lol Dude is here for the wrong reasons and has legit issues, sadly.

    If Avon can reproduce an actual transfer issue regularly then we can diagnose it, but until that happens there isn't much I can do do. I don't seem to have any problems on my own BBS with my binkd uplinks so that path has been a bust.

    --- Mystic BBS v1.12 A44 2020/01/28 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From StackFault@21:1/172 to g00r00 on Tue Jan 28 22:13:37 2020
    The debug logging for BINKP and socket error message is only temporary.
    I don't think it changes the format of the log, it just adds additional lines. The only time it would balloon like that is when it receives jibberish from the remote BinkP client so it shouldn't happen regularly. Really I am too lazy to separate it right now ;)

    Hahaha, priorities hey :)

    Ignore that troll trying to make issues. This is the same guy who is changing message "To" fields from g00r00 to p00p and message tear lines
    to "Garbage v1.12" lol Dude is here for the wrong reasons and has legit issues, sadly.

    Yeah, I figured, I didn't really followed all the threads in there but since
    he replied directly to a message I sent to Avon, he became on my reading list temporarily. Anyway, I think you have the good attitude ;)

    If Avon can reproduce an actual transfer issue regularly then we can diagnose it, but until that happens there isn't much I can do do. I
    don't seem to have any problems on my own BBS with my binkd uplinks so that path has been a bust.

    Seeing one of his replies, apparently it happens at regular interval from the same source, so maybe there will be a way to reproduce to pinpoint where the issue is.

    |15 ▀ ▐ |15StackFault |08<|03.|11.|15P|11h|03EN|11o|15M|11.|03.|08>
    |11 ▌ ▀ |11The Bottomless Abyss BBS
    |03 ▀ ▌▀ |03ssh|08.|072222 |08/ |03telnet|08.|072023 |08/ |03https
    |08 ▄■▐ |08bbs|07.|08bottomlessabyss|07.|08net

    --- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
    * Origin: The Bottomless Abyss BBS * bbs.bottomlessabyss.net (21:1/172)
  • From g00r00@21:1/108 to StackFault on Wed Jan 29 01:35:35 2020
    Seeing one of his replies, apparently it happens at regular interval
    from the same source, so maybe there will be a way to reproduce to pinpoint where the issue is.

    That would be great if so! I did set up binkd today and spent some time sending a 700 megabyte ISO back and forth between Mystic MIS and a BBS with binkd.

    I even killed MIS randomly a couple of times throughout, but it handled it as expected every time the next time binkd connected. I am using a really old binkd though from 2011. I did a quick Google and it wasn't clear where to download current builds based on the results I saw.

    --- Mystic BBS v1.12 A44 2020/01/29 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Avon@21:1/101 to g00r00 on Wed Jan 29 20:47:55 2020
    On 29 Jan 2020 at 01:35a, g00r00 pondered and said...

    That would be great if so! I did set up binkd today and spent some time sending a 700 megabyte ISO back and forth between Mystic MIS and a BBS with binkd.

    I have found the mis.1.txt file contains one example of the error and also another in my fidopoll to Frank. So it happens both ways between these two systems.

    I've sent you two log files so you can see them :)

    If you wouldn't mind uncommenting some of that 'logging options' code for the various servers that would be helpful. I am rather limited in A43 as to how many mis logs I can keep when they are limited to 1MB each and the Windows build just keeps four then wipes over them..

    I was wondering if there is some debug code logging still on for node logging? I have a 15 gig node1 log and suspect SSH style connections may be the cause? Just a guess. It's so big I can't look into it to find out.

    [snip]

    25/01/2020 11:23 a.m. 17,583 chat.log
    29/01/2020 12:55 a.m. 4,243 errors.log
    29/01/2020 08:31 p.m. 64,191,571 fidopoll.log
    29/01/2020 08:27 p.m. 1,048,630 mis.1.log
    29/01/2020 03:00 a.m. 1,048,628 mis.2.log
    28/01/2020 12:13 p.m. 1,048,597 mis.3.log
    27/01/2020 08:13 p.m. 1,063,908 mis.4.log
    29/01/2020 08:32 p.m. 7,052 mis.log
    29/01/2020 08:31 p.m. 270,366,737 mutil.log
    29/01/2020 08:29 p.m. 15,703,332,542 node1.log
    29/01/2020 07:26 p.m. 4,780,003 node2.log
    29/01/2020 05:02 p.m. 696,352 node3.log
    29/01/2020 02:16 p.m. 204,406 node4.log
    22/01/2020 02:14 p.m. 134,537 node5.log
    20/01/2020 10:20 a.m. 3,239 node6.log
    20/01/2020 10:20 a.m. 1,379 node7.log
    08/12/2019 10:37 p.m. 420 node8.log

    [snip]

    Best, Paul

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Oli@21:1/151 to Avon on Wed Jan 29 09:47:55 2020
    29 Jan 20 11:55, you wrote to StackFault:

    You're correct Agency is running Mystic BinkP and the 1/100 HUB
    is using BinkD at the moment. Because the MIS logs roll over so
    quick I may not have anything I can share until the next time it
    happens.. but it does seem to happen each time these files are
    sent.

    Can you upload one of the files or put it in the outbound for my node? (or maybe there us another option to get it).

    --- Garbage v1.12💩A44
    * Origin: đŸĻ„ 🌈 (21:1/151)
  • From g00r00@21:1/108 to Avon on Wed Jan 29 11:51:03 2020
    I have found the mis.1.txt file contains one example of the error and
    also another in my fidopoll to Frank. So it happens both ways between these two systems.

    The logs I saw (correct me if I'm wrong) were all A43 right?

    I noticed the binkp debug logging isn't on and also A43 is very old is there any way we can test with the latest?

    I would suggest you remove the node logs and if they're building on a current Jan 29 version then lets look into it.

    --- Mystic BBS v1.12 A44 2020/01/29 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Netsurge@21:4/154 to g00r00 on Wed Jan 29 12:47:18 2020
    But really, unless someone has something reproducible its hard to enact
    on it as anything outside of a connection hiccup. I get these reports from time to time and we've never pinpointed any issue.

    I agree. This problem is localized to Avon and myself only. I have plenty of other Mystic downlinks that get the same file just fine. That leads me to believe it is a TCP issue, albeit routing or packet loss, hard to pinpoint unless Avon and I do some extensive testing which is what I might just do.

    |15frank |08// |15netsurge
    |07disksh0p|08!|07bbs |08% |07bbs.diskshop.ca |08% |07mystic goodness |11SciNet |03ftn hq |08% |07https://scinet-ftn.org

    --- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
    * Origin: % disksh0p!bbs % bbs.diskshop.ca % SciNet ftn hq % (21:4/154)
  • From Avon@21:1/101 to g00r00 on Thu Jan 30 08:25:10 2020
    On 29 Jan 2020 at 11:51a, g00r00 pondered and said...

    The logs I saw (correct me if I'm wrong) were all A43 right?

    Yep that's the build still running here at Agency.

    I noticed the binkp debug logging isn't on and also A43 is very old is there any way we can test with the latest?

    I can take the plunge and upgrade the BBS tonight - stand by caller (written
    at 8.25am Thur)

    I would suggest you remove the node logs and if they're building on a current Jan 29 version then lets look into it.

    Yep will do. It's not the first time I have discovered it. By the time I do it's always too late to look into them :)

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to Netsurge on Wed Jan 29 13:49:46 2020
    I agree. This problem is localized to Avon and myself only. I have
    plenty of other Mystic downlinks that get the same file just fine. That leads me to believe it is a TCP issue, albeit routing or packet loss,
    hard to pinpoint unless Avon and I do some extensive testing which is
    what I might just do.

    Thanks I would appreciate another set of eyes on it. I have enabled the intense binkP logging in the A44 pre-releases that may or may not help (assuming Avon has the means to capture it)

    I can't seem to reproduce anything locally between Mystic/BinkD and also my Fido/Agoranet uplink is BinkD and I think its been years since we've had any issues.

    I appreciate the help! I was actually wondering if there could be something with the actual file but I guess not since you mentioned its fine with other connections.

    --- Mystic BBS v1.12 A44 2020/01/29 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Avon@21:1/101 to Netsurge on Thu Jan 30 12:49:48 2020
    On 29 Jan 2020 at 12:47p, Netsurge pondered and said...

    I agree. This problem is localized to Avon and myself only. I have
    plenty of other Mystic downlinks that get the same file just fine. That leads me to believe it is a TCP issue, albeit routing or packet loss,
    hard to pinpoint unless Avon and I do some extensive testing which is
    what I might just do.

    Thanks sir :) I'm going to try to update Agency tonight to the latest A44
    build at which time it will be interesting to see how get on when the next round of files are sent out. Can you let me know how many days until that happens? I can then keep an eye out for them.

    Best, Paul

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Vk3jed@21:1/109 to g00r00 on Thu Jan 30 12:04:00 2020
    On 01-29-20 13:49, g00r00 wrote to Netsurge <=-

    I can't seem to reproduce anything locally between Mystic/BinkD and
    also my Fido/Agoranet uplink is BinkD and I think its been years since we've had any issues.

    A bug has just been found in binkd that may or may not be relevant. From what I recall, memory is being freed before being read, and if malloc() is being aggressive about reusing newely freed memory, then things get corrupted. This may also be the issue I struck with Avon's system a while back. I had to take a number of measures to work around the problems including hardcoding the IPv4:port for the hub, and avoiding both IPv6 (the latency of Paul's HE tunnel triggered issues too) and DNS lookups.

    I appreciate the help! I was actually wondering if there could be something with the actual file but I guess not since you mentioned its fine with other connections.

    And in my case, binkd works fine with all other Mystic systems that I connect to. Might be worth investigating the binkd side. There was mention of this today in the Fidonet BINKD echo, as a delayed response to a series of posts I made last year, when I was having issues with 1/100.


    ... We have just enough religion to hate, but not enough to love - J. Swift
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From g00r00@21:1/108 to Avon on Wed Jan 29 20:42:13 2020
    Thanks sir :) I'm going to try to update Agency tonight to the latest A44 build at which time it will be interesting to see how get on when the
    next round of files are sent out. Can you let me know how many days
    until that happens? I can then keep an eye out for them.

    Fingers crossed. :) Sorry if the newer stuff causes any additional issues
    but lets hope there is some progress somewhere.

    --- Mystic BBS v1.12 A44 2020/01/29 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From g00r00@21:1/108 to Vk3jed on Wed Jan 29 21:13:18 2020
    A bug has just been found in binkd that may or may not be relevant.
    From what I recall, memory is being freed before being read, and if malloc() is being aggressive about reusing newely freed memory, then things get corrupted. This may also be the issue I struck with Avon's

    This is good to know. It certainly could be a non-Mystic issue. There were a handful of those over the years from MBSE, IREX, and all of the Taurus line of mailers.

    --- Mystic BBS v1.12 A44 2020/01/29 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From ryan@21:1/168 to Vk3jed on Wed Jan 29 22:12:34 2020
    [snip]

    I'm not much of a Pascal guy but does Pascal have malloc()?

    --- Mystic BBS v1.12 A44 2020/01/16 (Linux/64)
    * Origin: monterey bbs (21:1/168)
  • From Avon@21:1/101 to g00r00 on Thu Jan 30 21:42:01 2020
    On 29 Jan 2020 at 08:42p, g00r00 pondered and said...

    Fingers crossed. :) Sorry if the newer stuff causes any additional
    issues but lets hope there is some progress somewhere.

    The issue I found was that the upgrade would not move the text, menu and scripts dir over to the default theme. I had to manually doing it. The BBS seems to be working OK and I am hopeful the rest worked alright. Time will
    tell and I have a backup.

    The upgrade reported

    c:\bbs\mystic>upgrade

    Mystic BBS Data File Updater v1.12 A44
    Copyright (C) 1997-2020 By James Coyle

    Current data file version.....: v1.12 A40
    Latest data file revision is..: v1.12 A44

    - Converting theme data (c:\bbs\mystic\:c:\bbs\mystic\data\)

    - Converting: default
    - Copy theme files (may take a few minutes)
    - Updating theme profile and prompts
    - Removing old text/menu/script files

    Updating Base configuration to 1.12 : Success

    Complete!

    NOTE: Steps from UPGRADE.TXT must also be followed. You may need to perform
    additional steps depending on the version you are upgrading from.

    c:\bbs\mystic>

    Note I run the bbs from a subdir not c:\mystic so I am wondering if that was the issue for the failed dir moves?

    --- Mystic BBS v1.12 A44 2020/01/29 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Oli@21:1/151 to Vk3jed on Thu Jan 30 09:10:32 2020
    30 Jan 20 12:04, you wrote to g00r00:

    A bug has just been found in binkd that may or may not be
    relevant.

    It's only about node entries with a non-standard port number, I don't think it's related. But we still should ask the question, is it only happening with systems that listen on a non-standard port number? Or test it: just apply the patch and see if it's still happening.

    Here is the link to the pull request:

    https://github.com/pgul/binkd/pull/16


    --- Penis Flattener v1.12 A44
    * Origin: đŸĻ„ 🌈 (21:1/151)
  • From Vk3jed@21:1/109 to g00r00 on Thu Jan 30 21:40:00 2020
    On 01-29-20 21:13, g00r00 wrote to Vk3jed <=-

    A bug has just been found in binkd that may or may not be relevant.
    From what I recall, memory is being freed before being read, and if malloc() is being aggressive about reusing newely freed memory, then things get corrupted. This may also be the issue I struck with Avon's

    This is good to know. It certainly could be a non-Mystic issue. There were a handful of those over the years from MBSE, IREX, and all of the Taurus line of mailers.

    Well, I'll try a patched binkd and switch back to a standard configuration and see if I can get mailer sessions happening again that way.


    ... A sine curve goes off to infinity or at least the end of the blackboard. === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From Vk3jed@21:1/109 to ryan on Thu Jan 30 21:41:00 2020
    On 01-29-20 22:12, ryan wrote to Vk3jed <=-

    [snip]

    I'm not much of a Pascal guy but does Pascal have malloc()?

    No idea for sure. :)


    ... Did anybody listen to the boring parts of the evidence?
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From Vk3jed@21:1/109 to Oli on Thu Jan 30 21:42:00 2020
    On 01-30-20 09:10, Oli wrote to Vk3jed <=-

    30 Jan 20 12:04, you wrote to g00r00:

    A bug has just been found in binkd that may or may not be
    relevant.

    It's only about node entries with a non-standard port number, I don't think it's related. But we still should ask the question, is it only happening with systems that listen on a non-standard port number? Or
    test it: just apply the patch and see if it's still happening.

    That would explain the issue I had with 1/100. :)

    Here is the link to the pull request:

    https://github.com/pgul/binkd/pull/16

    Thanks. :)


    ... Bachelors don't have Mother-in-laws.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From Oli@21:1/151 to Vk3jed on Thu Jan 30 14:49:54 2020
    30 Jan 20 21:42, you wrote to me:

    A bug has just been found in binkd that may or may not be
    relevant.

    It's only about node entries with a non-standard port number, I
    don't think it's related. But we still should ask the question,
    is it only happening with systems that listen on a non-standard
    port number? Or test it: just apply the patch and see if it's
    still happening.

    That would explain the issue I had with 1/100. :)

    Just to avoid stupid rumors about binkd:

    The bug caused an error on non-standard port number and the connection failed. The issue that was reported didn't mention successful connections and failed / incomplete file transfers.

    Here is the link to the pull request:

    https://github.com/pgul/binkd/pull/16

    The patch has been committed and is in master now.

    --- Penis Flattener v1.12 A44
    * Origin: đŸĻ„ 🌈 (21:1/151)
  • From maskreet@21:1/114 to Avon on Thu Jan 30 10:33:42 2020
    On 30 Jan 2020, Avon said the following...

    The issue I found was that the upgrade would not move the text, menu and scripts dir over to the default theme. I had to manually doing it. The
    BBS seems to be working OK and I am hopeful the rest worked alright.
    Time will tell and I have a backup.

    Nope, I had the same issue. Took me a little bit of poking around to see what the issue was, maybe I was missing a step in the upgrade doc. My BBS is actually located at /mystic, and it still didn't move anything. I was also
    kind of confused why running upgrade wasn't actually upgrading anything. Once
    I moved the prompts.dat to the data dir it finally let me upgrade the data files, but I still had to move my text and menus directories.

    Wait, the scripts dir has to move there too?

    --- Mystic BBS v1.12 A44 2020/01/29 (Linux/64)
    * Origin: throwbackbbs.com -\- meriden, ct -\- (21:1/114)
  • From g00r00@21:1/108 to Avon on Thu Jan 30 10:44:11 2020
    The issue I found was that the upgrade would not move the text, menu and scripts dir over to the default theme. I had to manually doing it. The
    BBS seems to be working OK and I am hopeful the rest worked alright.
    Time will tell and I have a backup.

    Ahh crap I was working on changing it from a move to a copy and I think I
    got interrupted. I'll take a look at that right away!

    --- Mystic BBS v1.12 A44 2020/01/29 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Avon@21:1/101 to g00r00 on Fri Jan 31 09:15:30 2020
    On 30 Jan 2020 at 10:44a, g00r00 pondered and said...

    Ahh crap I was working on changing it from a move to a copy and I think I got interrupted. I'll take a look at that right away!

    No probs, that's why we do this stuff - to iron out the kinks :)

    --- Mystic BBS v1.12 A44 2020/01/29 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to g00r00 on Fri Jan 31 20:40:26 2020
    On 29 Jan 2020 at 01:49p, g00r00 pondered and said...

    I agree. This problem is localized to Avon and myself only. I have plenty of other Mystic downlinks that get the same file just fine. Th leads me to believe it is a TCP issue, albeit routing or packet loss, hard to pinpoint unless Avon and I do some extensive testing which is what I might just do.

    Thanks I would appreciate another set of eyes on it. I have enabled the intense binkP logging in the A44 pre-releases that may or may not help (assuming Avon has the means to capture it)

    I can't seem to reproduce anything locally between Mystic/BinkD and also my Fido/Agoranet uplink is BinkD and I think its been years since we've had any issues.

    OK while I still have this A44 running I can report I have encountered the
    same issue again. Will send you the MIS and FIDOPOLL logs separately.

    It's worse this time with 99 versions of parts of the same file in my inbound

    [snip]

    31/01/2020 01:52 a.m. 989,144 sciibbs.91.zip
    31/01/2020 01:52 a.m. 810,212 sciibbs.92.zip
    31/01/2020 01:52 a.m. 135,168 sciibbs.93.zip
    31/01/2020 01:52 a.m. 121,865 sciibbs.94.zip
    31/01/2020 01:52 a.m. 3,495,379 sciibbs.95.zip
    31/01/2020 01:52 a.m. 96,173 sciibbs.96.zip
    31/01/2020 01:52 a.m. 167,022 sciibbs.97.zip
    31/01/2020 01:52 a.m. 10,342 sciibbs.98.zip
    31/01/2020 01:52 a.m. 88,730 sciibbs.99.zip
    31/01/2020 02:59 p.m. 63,128 sciibbs.zip
    30/01/2020 09:00 p.m. <DIR> temp
    30/01/2020 09:00 p.m. <DIR> unsec
    100 File(s) 48,414,270 bytes

    [snip]

    Best, Paul

    --- Mystic BBS v1.12 A44 2020/01/29 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Vk3jed@21:1/109 to Oli on Fri Jan 31 16:31:00 2020
    On 01-30-20 14:49, Oli wrote to Vk3jed <=-

    Just to avoid stupid rumors about binkd:

    The bug caused an error on non-standard port number and the connection failed. The issue that was reported didn't mention successful
    connections and failed / incomplete file transfers.

    Well with 1/100, I'd get a successful start to the handshake, but then at some stage it would time out and fail. 1/100 does use a non standard port.


    ... "I went insane trying to take a close up picture of the horizon!"
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From Netsurge@21:4/154 to g00r00 on Wed Feb 5 22:33:42 2020
    I appreciate the help! I was actually wondering if there could be something with the actual file but I guess not since you mentioned its fine with other connections.

    I think if the binkp protocol has some form of error correction this wouldn't be an issue. I have 30+ downlinks and Avon is the only one with the issue.

    We will get to the bottom of this.

    |15frank |08// |15netsurge
    |07disksh0p|08!|07bbs |08% |07bbs.diskshop.ca |08% |07mystic goodness |11SciNet |03ftn hq |08% |07https://scinet-ftn.org

    --- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
    * Origin: % disksh0p!bbs % bbs.diskshop.ca % SciNet ftn hq % (21:4/154)
  • From Netsurge@21:4/154 to Avon on Wed Feb 5 22:35:12 2020
    Thanks sir :) I'm going to try to update Agency tonight to the latest A44 build at which time it will be interesting to see how get on when the
    next round of files are sent out. Can you let me know how many days
    until that happens? I can then keep an eye out for them.

    I'm a bit behind on mail due to our reno. The info pack gets hatched out
    every Friday.

    I'd like to put some time aside and do some testing between you and me, directly. Some trace routing and a few other packet tests, just to see if we can nail down this issue.

    |15frank |08// |15netsurge
    |07disksh0p|08!|07bbs |08% |07bbs.diskshop.ca |08% |07mystic goodness |11SciNet |03ftn hq |08% |07https://scinet-ftn.org

    --- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
    * Origin: % disksh0p!bbs % bbs.diskshop.ca % SciNet ftn hq % (21:4/154)
  • From Avon@21:1/101 to Netsurge on Thu Feb 6 19:14:53 2020
    On 05 Feb 2020 at 10:35p, Netsurge pondered and said...

    I'd like to put some time aside and do some testing between you and me, directly. Some trace routing and a few other packet tests, just to see
    if we can nail down this issue.

    Sure thing. I know g00r00 did find a few niggles with things so I have
    updated to the final release of 1.12 A44 so let's see how we get on this week.

    --- Mystic BBS v1.12 A44 2020/02/04 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to Netsurge on Thu Feb 6 13:10:46 2020
    I appreciate the help! I was actually wondering if there could be something with the actual file but I guess not since you mentioned it fine with other connections.

    I think if the binkp protocol has some form of error correction this wouldn't be an issue. I have 30+ downlinks and Avon is the only one with the issue.

    Hopefully it has been resolved now with the A44 upgrade, let me know if you still see any trouble since Feb 5th or so. I know Avon will be on the
    lookout as well.

    --- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Avon@21:1/101 to Netsurge on Sun Feb 9 10:28:45 2020
    On 05 Feb 2020 at 10:35p, Netsurge pondered and said...

    I'd like to put some time aside and do some testing between you and me, directly. Some trace routing and a few other packet tests, just to see
    if we can nail down this issue.

    Looks like the shift to 1.12 A44 has fixed the issue for me. All files came
    in first time with no additional partial files created in the echomail in folder. Things are looking much better,

    Here's the session log

    [snip]

    + 2020.02.07 14:52:29 BINKP > Connect on slot 1/8 (45.72.177.237)
    + 2020.02.07 14:52:29 BINKP 1-HostName bbs.diskshop.ca
    + 2020.02.07 14:52:29 BINKP 1-Country Canada (CA)
    + 2020.02.07 14:52:29 BINKP 1-R: NUL SYS Diskshop BBS
    + 2020.02.07 14:52:29 BINKP 1-System Diskshop BBS
    + 2020.02.07 14:52:29 BINKP 1-S: NUL OPT TLS CRAM-MD5-33ca49527dc317a2de1dc8888e3db8f3
    + 2020.02.07 14:52:29 BINKP 1-R: NUL ZYZ Netsurge / Frank Linhares
    + 2020.02.07 14:52:29 BINKP 1-SysOp Netsurge / Frank Linhares
    + 2020.02.07 14:52:29 BINKP 1-S: NUL SYS Agency BBS
    + 2020.02.07 14:52:29 BINKP 1-S: NUL ZYZ Avon
    + 2020.02.07 14:52:29 BINKP 1-S: NUL TIME Fri, 07 Feb 2020 14:52:29 +1300
    + 2020.02.07 14:52:29 BINKP 1-S: NUL VER Mystic/1.12A44 binkp/1.0
    + 2020.02.07 14:52:29 BINKP 1-S: NUL BUILD 2020/02/04 22:48:23 Windows/32
    + 2020.02.07 14:52:29 BINKP 1-S: ADR 46:3/203@agoranet 39:970/1@amiganet 3:770/100@fidonet 21:1/101@fsxnet 44:100/14@dorenet 77:3/102@scinet
    + 2020.02.07 14:52:29 BINKP 1-R: NUL LOC Toronto, Canada
    + 2020.02.07 14:52:29 BINKP 1-Location Toronto, Canada
    + 2020.02.07 14:52:29 BINKP 1-R: NUL NDL 115200,TCP,BINKP
    + 2020.02.07 14:52:29 BINKP 1-Info NDL 115200,TCP,BINKP
    + 2020.02.07 14:52:29 BINKP 1-R: NUL TIME Thu, 6 Feb 2020 20:52:19 -0500
    + 2020.02.07 14:52:29 BINKP 1-Info TIME Thu, 6 Feb 2020 20:52:19 -0500
    + 2020.02.07 14:52:29 BINKP 1-R: NUL VER binkd/1.1a-99/Linux binkp/1.1
    + 2020.02.07 14:52:29 BINKP 1-Mailer binkd/1.1a-99/Linux binkp/1.1
    + 2020.02.07 14:52:29 BINKP 1-R: ADR 1:229/101@fidonet 1:12/0@fidonet 1:12/1@fidonet 911:1905/0@zeronet 911:1905/1@zeronet 21:4/154@fsxnet 39:905/0@amiganet 39:905/100@amiganet 46:10/103@agoranet 77:77/0@scinet 77:1/0@scinet 77:2/0@scinet 77:3/0@scinet 77:1/100@scinet
    + 2020.02.07 14:52:29 BINKP 1-R: NUL OPT NDA EXTCMD CRYPT GZ BZ2
    + 2020.02.07 14:52:29 BINKP 1-R: NUL TRF 0 11658753
    + 2020.02.07 14:52:29 BINKP 1-Info TRF 0 11658753
    + 2020.02.07 14:52:29 BINKP 1-R: PWD
    + 2020.02.07 14:52:29 BINKP 1-Authenticating 77:1/100@scinet by CRAM-MD5
    + 2020.02.07 14:52:29 BINKP 1-S: OK secure
    + 2020.02.07 14:52:29 BINKP 1-Queued 0 files for 77:1/100@scinet
    + 2020.02.07 14:52:29 BINKP 1-S: NUL QSIZE 0 files 0 bytes
    + 2020.02.07 14:52:29 BINKP 1-S: EOB
    + 2020.02.07 14:52:30 BINKP 1-R: FILE sciibbs.zip 5816930 1581040322 0
    + 2020.02.07 14:52:30 BINKP 1-Receiving: sciibbs.zip (5,816,930 bytes)
    + 2020.02.07 14:57:31 BINKP 1-S: GOT sciibbs.zip 5816930 1581040322
    + 2020.02.07 14:57:31 BINKP 1-R: FILE scinet.z38 3975 1581040322 0
    + 2020.02.07 14:57:31 BINKP 1-Receiving: scinet.z38 (3,975 bytes)
    + 2020.02.07 14:57:31 BINKP 1-S: GOT scinet.z38 3975 1581040322
    + 2020.02.07 14:57:31 BINKP 1-R: FILE 16aehivg.tic 2161 1581040326 0
    + 2020.02.07 14:57:31 BINKP 1-Receiving: 16aehivg.tic (2,161 bytes)
    + 2020.02.07 14:57:31 BINKP 1-S: GOT 16aehivg.tic 2161 1581040326
    + 2020.02.07 14:57:31 BINKP 1-R: FILE sciinfo.zip 5829248 1581040322 0
    + 2020.02.07 14:57:31 BINKP 1-Receiving: sciinfo.zip (5,829,248 bytes)
    + 2020.02.07 15:01:45 BINKP 1-S: GOT sciinfo.zip 5829248 1581040322
    + 2020.02.07 15:01:45 BINKP 1-R: FILE 16aehiyg.tic 2257 1581040329 0
    + 2020.02.07 15:01:45 BINKP 1-Receiving: 16aehiyg.tic (2,257 bytes)
    + 2020.02.07 15:01:45 BINKP 1-S: GOT 16aehiyg.tic 2257 1581040329
    + 2020.02.07 15:01:45 BINKP 1-R: FILE scidiff.z38 826 1581040322 0
    + 2020.02.07 15:01:45 BINKP 1-Receiving: scidiff.z38 (826 bytes)
    + 2020.02.07 15:01:45 BINKP 1-S: GOT scidiff.z38 826 1581040322
    + 2020.02.07 15:01:45 BINKP 1-R: FILE 16aehitg.tic 1677 1581040324 0
    + 2020.02.07 15:01:45 BINKP 1-Receiving: 16aehitg.tic (1,677 bytes)
    + 2020.02.07 15:01:45 BINKP 1-S: GOT 16aehitg.tic 1677 1581040324
    + 2020.02.07 15:01:45 BINKP 1-R: FILE 16aehirg.tic 1679 1581040322 0
    + 2020.02.07 15:01:45 BINKP 1-Receiving: 16aehirg.tic (1,679 bytes)
    + 2020.02.07 15:01:45 BINKP 1-S: GOT 16aehirg.tic 1679 1581040322
    + 2020.02.07 15:01:47 BINKP 1-R: EOB
    + 2020.02.07 15:01:47 BINKP 1-Session ended (0 sent, 8 rcvd, 0 skip)

    [snip]

    Best, Paul

    --- Mystic BBS v1.12 A44 2020/02/04 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)