• BinkP Weirdness (Agency)

    From Avon@21:1/101 to g00r00 on Sun Jan 26 17:20:01 2020
    This one is just plain weird.

    When I get files from Frank for his SciNet network the BinkP server has conniptions and borks

    [snip]

    + 2020.01.24 14:52:24 BINKP > Connect on slot 1/8 (107.150.224.221)
    + 2020.01.24 14:52:24 BINKP 1-HostName host-107-150-224-221.dyn.295.ca
    + 2020.01.24 14:52:24 BINKP 1-Country Canada (CA)
    + 2020.01.24 14:52:24 BINKP 1-R: NUL SYS Diskshop BBS
    + 2020.01.24 14:52:24 BINKP 1-System Diskshop BBS
    + 2020.01.24 14:52:24 BINKP 1-S: NUL OPT TLS CRAM-MD5-a23c77119042e9a0ce9aa73116df040e
    + 2020.01.24 14:52:24 BINKP 1-R: NUL ZYZ Netsurge / Frank Linhares
    + 2020.01.24 14:52:24 BINKP 1-SysOp Netsurge / Frank Linhares
    + 2020.01.24 14:52:24 BINKP 1-S: NUL SYS Agency BBS
    + 2020.01.24 14:52:24 BINKP 1-S: NUL ZYZ Avon
    + 2020.01.24 14:52:24 BINKP 1-S: NUL TIME Fri, 24 Jan 2020 14:52:24 1300
    + 2020.01.24 14:52:24 BINKP 1-S: NUL VER Mystic/1.12A43 binkp/1.0
    + 2020.01.24 14:52:24 BINKP 1-S: NUL BUILD 2019/03/03 01:35:01 Windows/32
    + 2020.01.24 14:52:24 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.01.24 14:52:24 BINKP 1-R: NUL LOC Toronto, Canada
    + 2020.01.24 14:52:24 BINKP 1-Location Toronto, Canada
    + 2020.01.24 14:52:24 BINKP 1-R: NUL NDL 115200,TCP,BINKP
    + 2020.01.24 14:52:24 BINKP 1-Info NDL 115200,TCP,BINKP
    + 2020.01.24 14:52:24 BINKP 1-R: NUL TIME Thu, 23 Jan 2020 20:52:32 -0500
    + 2020.01.24 14:52:24 BINKP 1-Info TIME Thu, 23 Jan 2020 20:52:32 -0500
    + 2020.01.24 14:52:24 BINKP 1-R: NUL VER binkd/1.1a-99/Linux binkp/1.1
    + 2020.01.24 14:52:24 BINKP 1-Mailer binkd/1.1a-99/Linux binkp/1.1
    + 2020.01.24 14:52:24 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.01.24 14:52:24 BINKP 1-R: NUL OPT NDA EXTCMD CRYPT GZ BZ2
    + 2020.01.24 14:52:25 BINKP 1-R: NUL TRF 0 11658574
    + 2020.01.24 14:52:25 BINKP 1-Info TRF 0 11658574
    + 2020.01.24 14:52:25 BINKP 1-R: PWD
    + 2020.01.24 14:52:25 BINKP 1-Authenticating 77:1/100@scinet by CRAM-MD5
    + 2020.01.24 14:52:25 BINKP 1-S: OK secure
    + 2020.01.24 14:52:25 BINKP 1-Queued 0 files for 77:1/100@scinet
    + 2020.01.24 14:52:25 BINKP 1-S: NUL QSIZE 0 files 0 bytes
    + 2020.01.24 14:52:25 BINKP 1-S: EOB
    + 2020.01.24 14:52:25 BINKP 1-R: FILE sciibbs.zip 5816930 1579830722 0
    + 2020.01.24 14:52:25 BINKP 1-Receiving: sciibbs.zip (5,816,930 bytes)
    + 2020.01.24 14:52:43 BINKP 1-R: gif image

    [snip]

    followed in the logs by lots of garbage like aÑkU A'è3]å]ε°?ä╜U6/."∞47Ö╜Öuø∙/

    If you look at my echomail\in it's full of files when the session failed and new files were created.

    4/01/2020 01:52 a.m. 49,397 sciibbs.1.zip
    4/01/2020 01:52 a.m. 1,431,901 sciibbs.10.zip
    4/01/2020 01:52 a.m. 2,577,997 sciibbs.11.zip
    4/01/2020 01:52 a.m. 390,834 sciibbs.12.zip
    4/01/2020 01:52 a.m. 1,241,088 sciibbs.13.zip
    4/01/2020 01:52 a.m. 1,282,048 sciibbs.14.zip
    4/01/2020 01:52 a.m. 444,275 sciibbs.15.zip
    4/01/2020 01:52 a.m. 643,072 sciibbs.16.zip
    4/01/2020 01:52 a.m. 37,225 sciibbs.17.zip
    4/01/2020 01:52 a.m. 575,819 sciibbs.18.zip
    4/01/2020 01:52 a.m. 364,230 sciibbs.19.zip
    4/01/2020 01:52 a.m. 206,556 sciibbs.2.zip
    4/01/2020 01:52 a.m. 69,632 sciibbs.20.zip
    4/01/2020 01:52 a.m. 3,619,741 sciibbs.21.zip
    4/01/2020 01:52 a.m. 209,186 sciibbs.22.zip
    4/01/2020 01:52 a.m. 2,801,664 sciibbs.23.zip
    4/01/2020 01:52 a.m. 520,192 sciibbs.24.zip
    4/01/2020 01:52 a.m. 3,633,152 sciibbs.25.zip
    4/01/2020 01:52 a.m. 1,400,832 sciibbs.26.zip
    4/01/2020 01:52 a.m. 1,040,384 sciibbs.27.zip
    4/01/2020 01:52 a.m. 123,788 sciibbs.28.zip
    4/01/2020 01:52 a.m. 554,344 sciibbs.29.zip
    4/01/2020 01:52 a.m. 698,893 sciibbs.3.zip
    4/01/2020 01:52 a.m. 4,820,992 sciibbs.30.zip
    4/01/2020 01:52 a.m. 681,390 sciibbs.31.zip
    4/01/2020 01:52 a.m. 5,816,930 sciibbs.32.zip
    4/01/2020 01:52 a.m. 2,002,023 sciibbs.4.zip
    4/01/2020 01:52 a.m. 98,304 sciibbs.5.zip
    4/01/2020 01:52 a.m. 1,007,221 sciibbs.6.zip
    4/01/2020 01:52 a.m. 135,168 sciibbs.7.zip
    4/01/2020 01:52 a.m. 917,738 sciibbs.8.zip
    4/01/2020 01:52 a.m. 852,118 sciibbs.9.zip
    4/01/2020 01:52 a.m. 891,268 sciinfo.1.zip
    4/01/2020 01:52 a.m. 5,829,206 sciinfo.2.zip

    Seems for whatever reason this large file is not liked..

    I don't have issues with usual files coming in from othernets echomail or
    file areas... it's strange. I wondered if the size of the file could be in play?

    Here's the file as it stands on the HDD when it finally imports after many attempts and corruptions in the MIS log

    3/12/2019 04:27 p.m. <DIR> .
    3/12/2019 04:27 p.m. <DIR> ..
    3/12/2019 01:52 a.m. 5,829,075 sciinfo.zip
    1 File(s) 5,829,075 bytes

    and the MIS logs.. showing the successful session.

    [snip]

    + 2020.01.24 16:43:16 BINKP > Connect on slot 1/8 (107.150.224.221)
    + 2020.01.24 16:43:16 BINKP 1-HostName host-107-150-224-221.dyn.295.ca
    + 2020.01.24 16:43:16 BINKP 1-Country Canada (CA)
    + 2020.01.24 16:43:16 BINKP 1-R: NUL SYS Diskshop BBS
    + 2020.01.24 16:43:16 BINKP 1-System Diskshop BBS
    + 2020.01.24 16:43:16 BINKP 1-S: NUL OPT TLS CRAM-MD5-fd0c2dc48afd102adf38fe5cb499aa67
    + 2020.01.24 16:43:16 BINKP 1-R: NUL ZYZ Netsurge / Frank Linhares
    + 2020.01.24 16:43:16 BINKP 1-SysOp Netsurge / Frank Linhares
    + 2020.01.24 16:43:16 BINKP 1-S: NUL SYS Agency BBS
    + 2020.01.24 16:43:16 BINKP 1-S: NUL ZYZ Avon
    + 2020.01.24 16:43:16 BINKP 1-S: NUL TIME Fri, 24 Jan 2020 16:43:16 1300
    + 2020.01.24 16:43:16 BINKP 1-S: NUL VER Mystic/1.12A43 binkp/1.0
    + 2020.01.24 16:43:16 BINKP 1-S: NUL BUILD 2019/03/03 01:35:01 Windows/32
    + 2020.01.24 16:43:16 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.01.24 16:43:16 BINKP 1-R: NUL LOC Toronto, Canada
    + 2020.01.24 16:43:16 BINKP 1-Location Toronto, Canada
    + 2020.01.24 16:43:16 BINKP 1-R: NUL NDL 115200,TCP,BINKP
    + 2020.01.24 16:43:16 BINKP 1-Info NDL 115200,TCP,BINKP
    + 2020.01.24 16:43:16 BINKP 1-R: NUL TIME Thu, 23 Jan 2020 22:43:25 -0500
    + 2020.01.24 16:43:16 BINKP 1-Info TIME Thu, 23 Jan 2020 22:43:25 -0500
    + 2020.01.24 16:43:16 BINKP 1-R: NUL VER binkd/1.1a-99/Linux binkp/1.1
    + 2020.01.24 16:43:16 BINKP 1-Mailer binkd/1.1a-99/Linux binkp/1.1
    + 2020.01.24 16:43:16 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.01.24 16:43:16 BINKP 1-R: NUL OPT NDA EXTCMD CRYPT GZ BZ2
    + 2020.01.24 16:43:16 BINKP 1-R: NUL TRF 0 5841644
    + 2020.01.24 16:43:16 BINKP 1-Info TRF 0 5841644
    + 2020.01.24 16:43:16 BINKP 1-R: PWD
    + 2020.01.24 16:43:16 BINKP 1-Authenticating 77:1/100@scinet by CRAM-MD5
    + 2020.01.24 16:43:16 BINKP 1-S: OK secure
    + 2020.01.24 16:43:16 BINKP 1-Queued 0 files for 77:1/100@scinet
    + 2020.01.24 16:43:16 BINKP 1-S: NUL QSIZE 0 files 0 bytes
    + 2020.01.24 16:43:16 BINKP 1-S: EOB
    + 2020.01.24 16:43:16 BINKP 1-R: FILE sciinfo.zip 5829206 1579830722 0
    + 2020.01.24 16:43:16 BINKP 1-Renaming file sciinfo.zip to sciinfo.2.zip
    + 2020.01.24 16:43:16 BINKP 1-Receiving: sciinfo.2.zip (5,829,206 bytes)
    + 2020.01.24 16:43:31 BINKP 1-S: GOT sciinfo.zip 5829206 1579830722
    + 2020.01.24 16:43:31 BINKP 1-R: FILE 169ok6yg.tic 2257 1579830729 0
    + 2020.01.24 16:43:31 BINKP 1-Receiving: 169ok6yg.tic (2,257 bytes)
    + 2020.01.24 16:43:31 BINKP 1-S: GOT 169ok6yg.tic 2257 1579830729
    + 2020.01.24 16:43:31 BINKP 1-R: FILE scidiff.z24 731 1579830722 0
    + 2020.01.24 16:43:31 BINKP 1-Receiving: scidiff.z24 (731 bytes)
    + 2020.01.24 16:43:31 BINKP 1-S: GOT scidiff.z24 731 1579830722
    + 2020.01.24 16:43:31 BINKP 1-R: FILE scinet.z24 3933 1579830722 0
    + 2020.01.24 16:43:31 BINKP 1-Receiving: scinet.z24 (3,933 bytes)
    + 2020.01.24 16:43:31 BINKP 1-S: GOT scinet.z24 3933 1579830722
    + 2020.01.24 16:43:31 BINKP 1-R: FILE 169ok6rg.tic 1679 1579830722 0
    + 2020.01.24 16:43:31 BINKP 1-Receiving: 169ok6rg.tic (1,679 bytes)
    + 2020.01.24 16:43:31 BINKP 1-S: GOT 169ok6rg.tic 1679 1579830722
    + 2020.01.24 16:43:31 BINKP 1-R: FILE 169ok6tg.tic 1677 1579830724 0
    + 2020.01.24 16:43:31 BINKP 1-Receiving: 169ok6tg.tic (1,677 bytes)
    + 2020.01.24 16:43:31 BINKP 1-S: GOT 169ok6tg.tic 1677 1579830724
    + 2020.01.24 16:43:31 BINKP 1-R: FILE 169ok6vg.tic 2161 1579830726 0
    + 2020.01.24 16:43:31 BINKP 1-Receiving: 169ok6vg.tic (2,161 bytes)
    + 2020.01.24 16:43:31 BINKP 1-S: GOT 169ok6vg.tic 2161 1579830726
    + 2020.01.24 16:43:31 BINKP 1-R: EOB
    + 2020.01.24 16:43:31 BINKP 1-Session ended (0 sent, 7 rcvd, 0 skip)

    [snip]

    Just another bit of weirdness to add to the list. Sorry about that :)

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From StackFault@21:1/172 to Avon on Mon Jan 27 16:34:13 2020
    When I get files from Frank for his SciNet network the BinkP server has conniptions and borks

    If you look at my echomail\in it's full of files when the session failed and new files were created.

    4/01/2020 01:52 a.m. 49,397 sciibbs.1.zip
    4/01/2020 01:52 a.m. 1,431,901 sciibbs.10.zip

    Seems for whatever reason this large file is not liked..

    I'm still on A43 here running under Linux/64 and I get these files fine.
    Never had an issue with them so far, if that can help in tshooting.

    Cheers!

    |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 Avon@21:1/101 to StackFault on Tue Jan 28 12:55:22 2020
    On 27 Jan 2020 at 04:34p, StackFault pondered and said...

    I'm still on A43 here running under Linux/64 and I get these files fine. Never had an issue with them so far, if that can help in tshooting.

    Yep it's weird.. I'm not sure but perhaps it's OS specific, or something on
    my system. It's only those larger files it seems... well that's the only
    thing that large I get at the moment.. so yeah, figured perhaps it was
    related to size.. Hmm..

    --- 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 Mon Jan 27 19:02:29 2020
    4/01/2020 01:52 a.m. 49,397 sciibbs.1.zip
    4/01/2020 01:52 a.m. 1,431,901 sciibbs.10.zip

    Seems for whatever reason this large file is not liked..

    I'm still on A43 here running under Linux/64 and I get these files fine. Never had an issue with them so far, if that can help in tshooting.

    I just downloaded like 10 months of files from my Fidonet and Agoranet hub (it was something like 300 megs because I mistakenly left myself subbed to NASA images) and it worked well. He uses binkd.

    I have seen some quirks in the past, but binkp isnt something that has any
    sort of error correction. I think if a packet gets dropped for any reason
    then these occasional quirks should be expected. I see this specifically
    when I am operating my BBS by wireless only for example.

    That doesn't mean there isn't a real problem, but I haven't really seen anything consistent to go on.

    --- Mystic BBS v1.12 A44 2020/01/27 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Black Panther@21:1/186 to Avon on Mon Jan 27 19:01:08 2020
    On 28 Jan 2020, Avon said the following...

    Yep it's weird.. I'm not sure but perhaps it's OS specific, or something on my system. It's only those larger files it seems... well that's the only thing that large I get at the moment.. so yeah, figured perhaps it was related to size.. Hmm..

    If you like to test it, I could always drop a linux .iso file into the your filebox. ;)

    I've got a few that I've been looking at recently.


    ---

    Black Panther(RCS)
    Castle Rock BBS

    --- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
    * Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)
  • From Netsurge@21:4/154 to Avon on Mon Jan 27 21:58:06 2020
    Yep it's weird.. I'm not sure but perhaps it's OS specific, or something on my system. It's only those larger files it seems... well that's the only thing that large I get at the moment.. so yeah, figured perhaps it was related to size.. Hmm..

    I have checked with most of my downlinks and most of the nodes in Fidonet
    that get the Filegate fileecho that I distribute them on and no one else has had these issues. I wonder if it's a packet routing 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 StackFault@21:1/172 to Avon on Mon Jan 27 22:38:12 2020
    I'm still on A43 here running under Linux/64 and I get these files fi Never had an issue with them so far, if that can help in tshooting.

    Yep it's weird.. I'm not sure but perhaps it's OS specific, or something on my system. It's only those larger files it seems... well that's the only thing that large I get at the moment.. so yeah, figured perhaps it was related to size.. Hmm..

    I was reading g00r00's answer regarding error correction vs binkd and I was listening to Total FM this PM and noticed regular chops in the audio and it continuously had to buffer. Maybe this is not related but it may help
    to confirm the packet drop part. Maybe some network congestion or other
    errors. Just a thought...

    Cheers!

    |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 Avon@21:1/101 to Netsurge on Tue Jan 28 20:09:08 2020
    On 27 Jan 2020 at 09:58p, Netsurge pondered and said...

    I have checked with most of my downlinks and most of the nodes in Fidonet that get the Filegate fileecho that I distribute them on and no one else has had these issues. I wonder if it's a packet routing issue.

    Thanks for looking into it Frank, yeah I am totally stumped as to why. Once I update Agency to the new alpha it will be interesting to see if it continues.

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to StackFault on Tue Jan 28 20:11:53 2020
    On 27 Jan 2020 at 10:38p, StackFault pondered and said...

    I was reading g00r00's answer regarding error correction vs binkd and I was listening to Total FM this PM and noticed regular chops in the audio and it continuously had to buffer. Maybe this is not related but it may help to confirm the packet drop part. Maybe some network congestion or other errors. Just a thought...

    Well firstly thanks for listening.. it's appreciated :) Next, Hmm... I'm running a fibre 1000 down 500 up plan so hearing there's choppy audio is a worry. I wonder if it was the gear processing it? The again I am way way away here in little New Zealand which does happen to be about as far away as
    anyone who wants to get away from stuff can go :)

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From StackFault@21:1/172 to Avon on Tue Jan 28 06:53:29 2020
    I was reading g00r00's answer regarding error correction vs binkd and was listening to Total FM this PM and noticed regular chops in the au and it continuously had to buffer. Maybe this is not related but it m help to confirm the packet drop part. Maybe some network congestion o other errors. Just a thought...

    Well firstly thanks for listening.. it's appreciated :) Next, Hmm... I'm running a fibre 1000 down 500 up plan so hearing there's choppy audio is
    a worry. I wonder if it was the gear processing it? The again I am way
    way away here in little New Zealand which does happen to be about as far away as anyone who wants to get away from stuff can go :)

    I completely hear you on the "away" side, I am myself pretty away but it's a little less LOTR-ish around here :)

    Cheers!

    |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 Oli@21:1/151 to StackFault on Tue Jan 28 14:29:13 2020
    27 Jan 20 22:38, you wrote to Avon:

    I was reading g00r00's answer regarding error correction vs
    binkd and I was listening to Total FM this PM and noticed
    regular chops in the audio and it continuously had to buffer.
    Maybe this is not related but it may help to confirm the packet
    drop part. Maybe some network congestion or other errors. Just a thought...

    binkp uses TCP which "provides reliable, ordered, and error-checked delivery of
    a stream of octets (bytes) between applications" (quote from wikipedia). It is
    as reliable as email delivery or an http download. You normally don't have garbled text in emails or web pages, because of transmission errors.

    There is also the CRC extension for binkp, which provides another safeguard against transmission errors. I'm not sure which mailers do support it though. http://ftsc.org/docs/fts-1030.001

    Buffering issues with streaming media can be caused by all kinds of problems: on the server side, bad wifi connection in your local network, broadband provider, stupid middle boxes. bandwith, congestion, non existent net-neutrality and the protocol and streaming application that that is used ...

    You can have a internet connection that doesn't work very well for audio and video streaming, but still is 100% reliable with binkp.

    Where can I listen to Total FM?


    --- The Shitty Tosser v1.12 A44
    * Origin: Mystical Big Bug Systems (21:1/151)
  • From StackFault@21:1/172 to Oli on Tue Jan 28 10:01:29 2020
    binkp uses TCP which "provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications" (quote from wikipedia). It is as reliable as email delivery or an http download. You normally don't have garbled text in emails or web pages, because of transmission errors.

    Hehe don't worry, I know TCP quite well ;)

    However, it may have been caused by dropped connections, which TCP does not protect against.

    All in all, not looking for a network course here but just trying to provide input to help in the resolution... I'm pretty sure my network is good, don't worry ;)

    Cheers!

    |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 Oli@21:1/151 to StackFault on Tue Jan 28 16:54:46 2020
    28 Jan 20 10:01, you wrote to me:

    binkp uses TCP which "provides reliable, ordered, and
    error-checked delivery of a stream of octets (bytes) between
    applications" (quote from wikipedia). It is as reliable as
    email delivery or an http download. You normally don't have
    garbled text in emails or web pages, because of transmission
    errors.

    Hehe don't worry, I know TCP quite well ;)
    :)

    However, it may have been caused by dropped connections, which
    TCP does not protect against.

    A dropped connection shouldn't be a problem, because binkp sends the size of the file in advance. If the connection drops and not all bytes have been received, the client should recognize the file transfer as failed. If there are
    incomplete files caused by a dropped connection, we should consider the possibility of a bug in the server or client implementation. If it is caused by
    something else, it might be a bug too.

    I don't see any real flaw in the design of the binkp protocol that would causes
    this and never had any problems with corrupted files (only wrong time stamps).

    All in all, not looking for a network course here but just
    trying to provide input to help in the resolution... I'm pretty
    sure my network is good, don't worry ;)

    sorry for the "network course" ;)

    --- The Shitty Tosser v1.12 A44
    * Origin: 💩 (21:1/151)
  • From StackFault@21:1/172 to Oli on Tue Jan 28 11:20:26 2020
    However, it may have been caused by dropped connections, which
    TCP does not protect against.

    A dropped connection shouldn't be a problem, because binkp sends the
    size of the file in advance. If the connection drops and not all bytes have been received, the client should recognize the file transfer as failed. If there are incomplete files caused by a dropped connection, we should consider the possibility of a bug in the server or client implementation. If it is caused by something else, it might be a bug too.

    Well, I agree there must be a problem or a bug. Where I disagree is the fact you exclude some possibilities out of the equation right from the start based on "is not supposed to" or "should do xyz" in your explanation. This is not a good troubleshooting approach to the problem IMO.

    Every possibilities should be considered and analyzed, starting with the most probable and go down to the next and so on... do not exclude anything from
    the possibilities until you've actually tested it and never rely solely on documentation, RFC, FTSC or whatever acronym we can find on the Internet to skip a test (that is a personal mantra). Doubt everything until tested.

    The fact is that files are actually saved incomplete, therefore there is an issue. The process that receives the file from the network cannot do it's job completely, what remains to be answered is what between that piece of software and the network (or both maybe) is acting up.

    Cheers!

    |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 Oli@21:1/151 to StackFault on Tue Jan 28 18:11:18 2020
    28 Jan 20 11:20, you wrote to me:

    However, it may have been caused by dropped connections,
    which
    TCP does not protect against.

    A dropped connection shouldn't be a problem, because binkp
    sends the size of the file in advance. If the connection drops
    and not all bytes have been received, the client should
    recognize the file transfer as failed. If there are incomplete
    files caused by a dropped connection, we should consider the
    possibility of a bug in the server or client implementation. If
    it is caused by something else, it might be a bug too.

    Well, I agree there must be a problem or a bug. Where I disagree
    is the fact you exclude some possibilities out of the equation
    right from the start based on "is not supposed to" or "should do
    xyz" in your explanation. This is not a good troubleshooting
    approach to the problem IMO.

    It was mainly a response to the bullshit explanation that garbage in the log file and corrupted files are to be expected on droppped connections, because binkp has no error correction.

    Every possibilities should be considered and analyzed, starting
    with the most probable and go down to the next and so on...

    let's start with the most probable one: there is a bug in mystic bbs' binkp implementation.

    the next step would be to reproduce the problem on another system / connection with the same software. then test it with the same file between two binkd instances and also between two mystic bbs instances.

    alternatively: make a tcpdump while the error occcurs.

    --- The 💩 Tosser v1.12 A44
    * Origin: đŸĻ„đŸŒˆ (21:1/151)
  • From StackFault@21:1/172 to Oli on Tue Jan 28 15:20:24 2020
    It was mainly a response to the bullshit explanation that garbage in the log file and corrupted files are to be expected on droppped connections, because binkp has no error correction.

    Well, I'm not sure how garbage in the log files would appear if a problem is
    on the remote side. The cause for a logging garbage issue has to be
    on the "logging" side software, maybe a lack of output sanitization or some more serious problems like memory overwrite, buffer overflow, etc.

    According to the snippet here...

    "I think (from memory) just swapping out to BinkD sorted the issues Oli was reporting.. now I am back to using MUTIL for tossing but still BinkD at this stage."

    ... Avon is still using BinkD for the packet transfers. Netsurge is also running BinkD as far as I can tell. So if both are running BinkD, how can Mystic be the most probable cause in the failed transfers issues Avon is having, log garbage and what not? It looks to me that Mystic has nothing to do with this since it's not even in the path anywhere between the two. At this stage, we are not even close to tossing anyway. I may be mistaken tho and
    maybe something has not been said. Not taking party here, one way or another but just stating the facts as I know them.

    Anyway, I was just providing an observation to Avon so he is aware about the choppy audio I've experienced. Today it's running perfectly fine.

    On the other hand, I noticed your origin line is showing some kind of inconsistent behavior in between messages. Interestingly enough, the version appears to match a recent Mystic release but on previous messages, the actual name do not mention Mystic...

    --- The 💩 Tosser v1.12 A44
    * Origin: 🦄🌈 (21:1/151)

    Cheers!

    |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 Tue Jan 28 14:47:41 2020
    Well, I agree there must be a problem or a bug. Where I disagree is the fact you exclude some possibilities out of the equation right from the start based on "is not supposed to" or "should do xyz" in your explanation. This is not a good troubleshooting approach to the problem IMO.

    Yep, I know I am preaching to the choir here but TCP is only a small part of the equation. To try to make a statement that claims that it makes something bullet-proof is fundamentally short-sighted.

    Packet loss can happen, buffer overruns happen, wireless hiccups happen. These things can lead to timeouts or other scenarios that cause missed frames or dropped connections that appear randomly. It has caused plenty of online gaming rage sessions lol!

    When I was young my mom's poorly shielded microwave used to destroy my connection and corrupt everything I did. It was maddening to have a big file download destroyed at the last minute because she microwaved something lol.

    The fact is that files are actually saved incomplete, therefore there is an issue. The process that receives the file from the network cannot do it's job completely, what remains to be answered is what between that piece of software and the network (or both maybe) is acting up.

    If there is a problem with transmission that amounts to a bug then it should be consistent and reproducible. As far as I know that isn't the case here and with the frequency that Mystic sends file it would be a wide-spread issue.

    I think the first place to look might be what happens AFTER a file fails for legit reasons. This situation doesn't get much testing with the various BINKP clients because it requires a fail state to begin with, and Mystic also has several options surrounding this scenario that could be broken. I also seem to remember having to change that code because IREX or Taurus or something didn't behave properly and couldn't be fixed. That could have broke binkd.

    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.

    --- Mystic BBS v1.12 A44 2020/01/28 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From g00r00@21:1/108 to Oli on Tue Jan 28 14:59:26 2020
    let's start with the most probable one: there is a bug in mystic bbs' binkp implementation.

    If Mystic sends a hundreds of files a day for years on end and there was a massive bug with sending a file, it would be a wide-spread problem. But its not.

    I just downloaded 300mb of data from my BINKD uplink, the same one I have had for 10 years now without problems. It was a payload that included hundreds of files. Thats the average experience.

    Right now we have a single case of a file that failed and was resent.

    The reality is the things you claim are epic bugs or "probable" aren't based on logic; they're based on your ill-intentioned emotions. You're constantly trying to drum up problems and you cherry pick things to respond to or ignore with the obvious intent to be problematic.

    If you can find a reproducible issue, then do so. We would all appreciate having another positive person in the community. But it seems like you're starting to wear your welcome out with more people than just me at this point with your nonsense.

    --- Mystic BBS v1.12 A44 2020/01/28 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From g00r00@21:1/108 to StackFault on Tue Jan 28 15:44:36 2020
    Well, I'm not sure how garbage in the log files would appear if a
    problem is on the remote side. The cause for a logging garbage issue has to be on the "logging" side software, maybe a lack of output
    sanitization or some more serious problems like memory overwrite, buffer overflow, etc.

    If you're talking about Mystic the logging garbage is intentional. Mystic is dumping the entire data buffer because the frames were out of sync. The intention is that we can look at the logs and see what content was being sent to try to determine the issue.

    --- Mystic BBS v1.12 A44 2020/01/28 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Oli@21:1/151 to StackFault on Tue Jan 28 21:50:28 2020
    28 Jan 20 15:20, you wrote to me:

    It was mainly a response to the bullshit explanation that
    garbage in the log file and corrupted files are to be expected
    on droppped connections, because binkp has no error correction.

    Well, I'm not sure how garbage in the log files would appear if
    a problem is on the remote side. The cause for a logging garbage
    issue has to be on the "logging" side software, maybe a lack of
    output sanitization or some more serious problems like memory
    overwrite, buffer overflow, etc.

    According to the snippet here...

    "I think (from memory) just swapping out to BinkD sorted the
    issues Oli was reporting.. now I am back to using MUTIL for
    tossing but still BinkD at this stage."

    ... Avon is still using BinkD for the packet transfers. Netsurge
    is also running BinkD as far as I can tell. So if both are
    running BinkD, how can Mystic be the most probable cause in the
    failed transfers issues Avon is having, log garbage and what
    not? It looks to me that Mystic has nothing to do with this
    since it's not even in the path anywhere between the two.

    The log is clearly not from BinkD, which uses a different format. If you read the whole log you see that it is a session between BinkD and Mystic binkp. I assumed this is Mystic's log ... Or is there another reason why Avon is posting
    a message to g00r00 in the mystic echo?

    --- Garbage v1.12💩A44
    * Origin: đŸĻ„ 🌈 (21:1/151)
  • From StackFault@21:1/172 to g00r00 on Tue Jan 28 16:44:31 2020
    Yep, I know I am preaching to the choir here but TCP is only a small
    part of the equation. To try to make a statement that claims that it makes something bullet-proof is fundamentally short-sighted.

    Well, I guess this reply was not for me since I completely in agreement with what you are saying.

    Starting with an assumption the problem resides at a specific location,
    prevent you from being objective. I always try to look at all the options.

    Cheers!

    |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 StackFault@21:1/172 to g00r00 on Tue Jan 28 16:48:45 2020
    If you're talking about Mystic the logging garbage is intentional.
    Mystic is dumping the entire data buffer because the frames were out of sync. The intention is that we can look at the logs and see what
    content was being sent to try to determine the issue.

    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.

    Cheers!

    |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 StackFault@21:1/172 to Oli on Tue Jan 28 16:51:52 2020
    The log is clearly not from BinkD, which uses a different format. If you read the whole log you see that it is a session between BinkD and Mystic

    Agreed, I went back and you're right. Looking at g00r00's explanation is also giving valuable input on the reasons why.

    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.

    Cheers!

    |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 StackFault@21:1/172 to g00r00 on Tue Jan 28 17:10:12 2020
    If there is a problem with transmission that amounts to a bug then it should be consistent and reproducible. As far as I know that isn't the case here and with the frequency that Mystic sends file it would be a wide-spread issue.

    That's mostly why, when I noticed Avon's radio was chopping, that it might
    have been transport related and told him about it.

    Intermittent problems are the worst to troubleshoot.

    Cheers!

    |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 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)