• all nodes busy with a37 prealpha

    From h7@21:1/155 to All on Saturday, December 30, 2017 10:20:59

    i have a problem with busy nodes with a37 prealpha. nodespy shows the lines
    are busy but mystic's mis says that they're all waiting for call. i have to manually kick the ghosts at least once a day (2-5 ghost nodes in 12h).

    any workaround to this, except delete chat1-5.dat from data directory with
    cron like once every two hours? running mystic/x64 here.

    to proof to that i'm not making shit up:

    http://ascii.graphics/mysticmis.png

    my blocked ip filelist is now over 300k.

    |08\ |07H7|08 of |07Blocktronics/dIVINE sTYLERS!/aCCESSiON/TRSi/Break!Ascii |08\ |07Haciend bbs sysop |08(|15telnet://haciend.com|08)|07

    --- Mystic BBS v1.12 A37 2017/12/23 (Linux/64)
    * Origin: Haciend.com | Scandinavian demoscene bbssince 1996 (21:1/155)
  • From h7@21:1/155 to g00r00 on Thursday, January 04, 2018 16:18:30

    seems that part of the problem is that the country blocking does not work.

    nodespy sees the ghost users "logging in" but they dont appear in the WFC screen. Im starting to wonder if the WFC differs from daemon mode in that sense?

    I set up a system password that the telnet scanners fail all the time (prompt that says "type bbs to access the bbs" and expects bbs there. now it seems
    that the ghost nodes dont appear.

    the country blocking doesnt stick to logs at all, i dont have errors related
    to iplocation.bin in data/ or for the country ban textfile that matter either.


    -Antti


    i have a problem with busy nodes with a37 prealpha. nodespy shows the lines are busy but mystic's mis says that they're all waiting for call.
    i have to manually kick the ghosts at least once a day (2-5 ghost nodes
    in 12h).

    any workaround to this, except delete chat1-5.dat from data directory
    with cron like once every two hours? running mystic/x64 here.

    to proof to that i'm not making shit up:

    http://ascii.graphics/mysticmis.png

    my blocked ip filelist is now over 300k.

    |08\ |07H7|08 of |07Blocktronics/dIVINE sTYLERS!/aCCESSiON/TRSi/Break!Ascii |08\ |07Haciend bbs sysop |08(|15telnet://haciend.com|08)|07

    --- Mystic BBS v1.12 A37 2017/12/23 (Linux/64)
    * Origin: Haciend.com | Scandinavian demoscene bbssince 1996 (21:1/155)
  • From h7@21:1/155 to h7 on Thursday, January 04, 2018 20:37:24

    replying to myself here, but apparently i didnt have the good sense to copy over the iplocation.txt from the fresh install (and it didnt say that in upgrade.txt), so i just renamed my badcountry.txt to iplocation.txt.

    i didnt notice the change in the file contents (3 digit vs 2 digit country codes and format) either until chatting with esc who sent me his file (i was suspecting something odd with my own file) and also i was suspecting that the server vs daemon modes are different somehow.

    the ghost nodes still do exist, that im sure of. they'll just not be that
    much of a nuisance now.

    bughunting:
    i noticed that using a system password prompt (like just type BBS to continue or so) does help. the scanners get stuck there and are kicked out and a ghost node "logging in" mode is not created.

    so maybe a short notice of changed contents and copy that shit over -kind of
    a message would have done the trick :)


    H7


    seems that part of the problem is that the country blocking does not
    work.

    nodespy sees the ghost users "logging in" but they dont appear in the WFC screen. Im starting to wonder if the WFC differs from daemon mode in that sense?

    I set up a system password that the telnet scanners fail all the time (prompt that says "type bbs to access the bbs" and expects bbs there.
    now it seems that the ghost nodes dont appear.

    the country blocking doesnt stick to logs at all, i dont have errors related to iplocation.bin in data/ or for the country ban textfile that matter either.


    -Antti


    i have a problem with busy nodes with a37 prealpha. nodespy shows the lines are busy but mystic's mis says that they're all waiting for cal i have to manually kick the ghosts at least once a day (2-5 ghost nod in 12h).

    any workaround to this, except delete chat1-5.dat from data directory with cron like once every two hours? running mystic/x64 here.

    to proof to that i'm not making shit up:

    http://ascii.graphics/mysticmis.png

    my blocked ip filelist is now over 300k.

    |08\ |07H7|08 of |07Blocktronics/dIVINE sTYLERS!/aCCESSiON/TRSi/Break!Ascii |08\ |07Haciend bbs sysop |08(|15telnet://haciend.com|08)|07

    --- Mystic BBS v1.12 A37 2017/12/23 (Linux/64)
    * Origin: Haciend.com | Scandinavian demoscene bbssince 1996 (21:1/155)
  • From dream master@21:1/163 to h7 on Thursday, January 04, 2018 14:27:04
    On 12/30/17, h7 said the following...
    i have a problem with busy nodes with a37 prealpha. nodespy shows the lines are busy but mystic's mis says that they're all waiting for call.
    i have to manually kick the ghosts at least once a day (2-5 ghost nodes
    in 12h).

    official A38 is out now see if it corrects your issue.

    |08 .|05ú|13ù|15Dr|07e|08am Ma|07st|15er|13ù|05ú|08.
    |08 øù|05ú|13ùø |13øù|05ú|08ùø
    |11 DoRE|03!|11ACiDiC|03!|11Demonic |08[|15dreamland|09.|15darktech|09.|15org|08]

    --- Mystic BBS v1.12 A38 2018/01/01 (Windows/64)
    * Origin: |08--[|15!|07dreamland BBS dreamland.darktech.org (21:1/163)
  • From esc@21:2/142 to h7 on Friday, January 05, 2018 05:56:42
    bughunting:
    i noticed that using a system password prompt (like just type BBS to continue or so) does help. the scanners get stuck there and are kicked
    out and a ghost node "logging in" mode is not created.

    Actually, you raise a good point here. There was a thread on reddit.com/r/bbs some time ago about setting up a telnet honeypot. IOT botnets spam our BBSes constantly - and we are often chasing our tails blocking IP ranges. While
    this is effective, we suffer a slight perf hit when we implement this, particularly so if we do so at an iptables level.

    I have a proposal. :) But first, explanation of how these IOT botnets work:

    1 - They portscan for unencrypted telnet (i.e., using a nonstandard port is useless)
    2 - They connect and attempt entries from a list of standard admin/password type combos one would expect with a Smart TV or some random IOT device (sometimes even cisco routers)
    3 - They push a buffer of a handful of commands which result in the end
    device becoming part of the botnet

    My proposal is this, and I'm hoping g00r00 sees it - additionally, I think we should consider this for all BBSes moving forward, and try to surface these types of conversations outside the scope of being mystic only:

    We should have a sysop-configurable option to enable a login "Press <escape> twice to continue" akin to old FrontDoor and Intermail answering services. We can put a 5 second timer (sysop configurable) that will just kick a user
    after the five seconds elapse. Ta-da, no more hung nodes.

    Please, before someone chimes in with some reason why we don't need more security, this isn't an argument for security. IOT botnets aren't targeting telnet bulletin boards, they just don't know how to disambiguate a vulnerable server from a telnet BBS. So, we should step up our game in finding ways to block these things from tying up our nodes.

    --- Mystic BBS v1.12 A38 2018/01/01 (Linux/32)
    * Origin: lo fidelity bbs (21:2/142)
  • From g00r00@21:1/108 to esc on Friday, January 05, 2018 03:29:08
    My proposal is this, and I'm hoping g00r00 sees it - additionally, I
    think we should consider this for all BBSes moving forward, and try to surface these types of conversations outside the scope of being mystic only:

    We should have a sysop-configurable option to enable a login "Press <escape> twice to continue" akin to old FrontDoor and Intermail
    answering services. We can put a 5 second timer (sysop configurable)
    that will just kick a user after the five seconds elapse. Ta-da, no more hung nodes.

    I think you can do this with startup.mps in a few lines of code if you want to. Its designed for oddball stuff like that :P I could probably whip something up in a few minutes for you.

    Although I am confused by the hung nodes. If you have hung nodes there is a bigger problem. Did you disable inactivity timeout? Some of them will sit there all day if you turn off the mechanism to time them out.

    I DDOS MIS on Linux with a 50 node BBS that gets pushed to over 500,000 connections without a single leak, crash or ghost node. I also haven't had an unexplained ghost user in a very long time on my own BBS (unless something crashes when I'm developing which is explainable)... But I also run on non-standard ports so it doesn't get beat on. Those two scenarios do not seem to produce stuck nodes for me for some reason.

    I need to put a BBS up on a laptop and just let it sit for a while.

    I personally think the best idea is to just identify and resolve the issue! :)

    --- Mystic BBS v1.12 A39 2018/01/04 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From esc@21:2/142 to g00r00 on Friday, January 05, 2018 09:27:10
    I think you can do this with startup.mps in a few lines of code if you want to. Its designed for oddball stuff like that :P I could probably whip something up in a few minutes for you.

    No need, I've already whipped up something of my own for this reason :)

    Although I am confused by the hung nodes. If you have hung nodes there
    is a bigger problem. Did you disable inactivity timeout? Some of them will sit there all day if you turn off the mechanism to time them out.

    After country blocking and implementing IP blocking and various other options available in mystic -cfg, I don't have this issue. But initially I did quite
    a bit. But, I also enabled a system password, so it could be a false negative...I recall having pretty significant problems with hung nodes, with all default timeout settings.

    I DDOS MIS on Linux with a 50 node BBS that gets pushed to over 500,000 connections without a single leak, crash or ghost node. I also haven't had an unexplained ghost user in a very long time on my own BBS (unless something crashes when I'm developing which is explainable)... But I
    also run on non-standard ports so it doesn't get beat on. Those two scenarios do not seem to produce stuck nodes for me for some reason.

    Is there a firewall somewhere or a load balancer that is picking up too many attempted connections? Dunno, it seems hit or miss. My daydream bbs goes from happy to totally hung at seemingly random times. I have far less implemented there to prevent botnet stuff, though.

    On both BBSes I have pretty aggressive psad and other IPS/IDS in place.

    I personally think the best idea is to just identify and resolve the issue! :)

    Botnets! :P

    --- Mystic BBS v1.12 A38 2018/01/01 (Linux/32)
    * Origin: lo fidelity bbs (21:2/142)
  • From Nugax@21:1/107 to All on Friday, January 05, 2018 08:20:23
    I am for the ESC to continue.

    But if I put this in startup.mps, doesn't that still tie up the node? It just it does dump the user after inactivity? I'm going to write an mpl in a few
    and test it. Two wrong keys and it drops conenection.

    Might be nice. Let's see

    On 21:29 04/01 , g00r00 wrote:
    My proposal is this, and I'm hoping g00r00 sees it - additionally, I think we should consider this for all BBSes moving forward, and try to surface these types of conversations outside the scope of being mystic only:

    We should have a sysop-configurable option to enable a login "Press <escape> twice to continue" akin to old FrontDoor and Intermail
    answering services. We can put a 5 second timer (sysop configurable)
    that will just kick a user after the five seconds elapse. Ta-da, no more hung nodes.

    I think you can do this with startup.mps in a few lines of code if you want to.
    Its designed for oddball stuff like that :P I could probably whip something up
    in a few minutes for you.

    Although I am confused by the hung nodes. If you have hung nodes there is a >bigger problem. Did you disable inactivity timeout? Some of them will sit >there all day if you turn off the mechanism to time them out.

    I DDOS MIS on Linux with a 50 node BBS that gets pushed to over 500,000 >connections without a single leak, crash or ghost node. I also haven't had an >unexplained ghost user in a very long time on my own BBS (unless something >crashes when I'm developing which is explainable)... But I also run on >non-standard ports so it doesn't get beat on. Those two scenarios do not seem >to produce stuck nodes for me for some reason.

    I need to put a BBS up on a laptop and just let it sit for a while.

    I personally think the best idea is to just identify and resolve the issue! :)

    --- Mystic BBS v1.12 A39 2018/01/04 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)


    --
    yrNews Usenet Reader for iOS
    http://appstore.com/yrNewsUsenetReader

    --- Mystic BBS/NNTP v1.12 A38 2018/01/01 (Linux/64)
    * Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)
  • From g00r00@21:1/108 to esc on Friday, January 05, 2018 12:37:31
    After country blocking and implementing IP blocking and various other options available in mystic -cfg, I don't have this issue. But initially
    I did quite a bit. But, I also enabled a system password, so it could be
    a false negative...I recall having pretty significant problems with hung nodes, with all default timeout settings.

    Are you talking about the current version when you talk about these nodes or was this with earlier versions that had known issues? I know for a bit you were still using an older version and a copy of MIS that had known issues.

    I am going to get the latest copy of A39 installed on Linux/64 Ubuntu today and open it up to get hit by the bots. I usually also run a System Password, so it may just be that I always had the "perfect combination" of settings to not see this issue on my own BBS.

    I may also open the HTTP server just to try to get the load to be a little higher on MIS as well, but I don't know if people scan HTTP in the same way as telnet.

    --- Mystic BBS v1.12 A39 2018/01/05 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From esc@21:2/142 to g00r00 on Saturday, January 06, 2018 06:42:40
    Are you talking about the current version when you talk about these
    nodes or was this with earlier versions that had known issues? I know
    for a bit you were still using an older version and a copy of MIS that
    had known issues.

    It was with a37 prealpha, early December version. Linux 32 bit, if it makes a difference.

    I am going to get the latest copy of A39 installed on Linux/64 Ubuntu today and open it up to get hit by the bots. I usually also run a
    System Password, so it may just be that I always had the "perfect combination" of settings to not see this issue on my own BBS.

    Yeah, I can't be sure if enabling a system password is what did the trick for me. But country blocking and aggressively blocking spam IPs seems to be
    working well enough.

    I may also open the HTTP server just to try to get the load to be a
    little higher on MIS as well, but I don't know if people scan HTTP in
    the same way as telnet.

    They do scan for http, but they scan for endpoints, whereas with telnet they just try to login with BS credentials.

    --- Mystic BBS v1.12 A38 2018/01/01 (Linux/32)
    * Origin: lo fidelity bbs (21:2/142)
  • From g00r00@21:1/108 to esc on Saturday, January 06, 2018 16:05:54
    I may also open the HTTP server just to try to get the load to be a little higher on MIS as well, but I don't know if people scan HTTP in the same way as telnet.

    They do scan for http, but they scan for endpoints, whereas with telnet they just try to login with BS credentials.

    Gotcha. In the case of Mystic's HTTP server if it doesn't have a webroot defined it just shows a "This webserver is not configured" page, so I'll leave it at that and any endpoint they scan for will just result in the same page.

    Hopefully I'll get that setup today and I can leave it up for a while.

    --- Mystic BBS v1.12 A39 2018/01/06 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From esc@21:2/142 to g00r00 on Sunday, January 07, 2018 00:04:01
    Mystic has an http server? :D

    I had no idea. I don't see it in the list. I'm just using standard old nginx. :P

    --- Mystic BBS v1.12 A38 2018/01/01 (Linux/32)
    * Origin: lo fidelity bbs (21:2/142)
  • From g00r00@21:1/108 to esc on Sunday, January 07, 2018 00:40:40
    Mystic has an http server? :D

    I had no idea. I don't see it in the list. I'm just using standard old nginx. :P

    It has a very basic web server that can host up html files but I keep it disabled because I ran out of space in the servers.dat file. It doesn't support FastCGI so its probably not super useful (yet) and there is not BBS-like interface for the web side.

    Now that MIS is pretty stable, I will probably enable http and Sendmail soon, as early as A39 (sendmail is actually in A38 it will start up but you can't do anything with it yet).

    There is also a scripted server option so you can write your own servers in Python although this is totally broken and has never been at a place where it actually works well.

    I have so many ideas and plans its just a matter of time until I can bring everything together.

    --- Mystic BBS v1.12 A39 2018/01/06 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From h7@21:1/155 to esc on Friday, January 05, 2018 08:18:40

    We should have a sysop-configurable option to enable a login "Press <escape> twice to continue" akin to old FrontDoor and Intermail
    answering services. We can put a 5 second timer (sysop configurable)
    that will just kick a user after the five seconds elapse. Ta-da, no more hung nodes.

    the hung nodes -thing is also something mystic itself should take care of. i dont know why it doesn't. if i have the time today, i'll set up a recorder
    for some few hundred megs of traffic to see how mystic behaves (or tries to behave or doesnt) when trying to break up the connection. the timeout values that are set in the config clearly do not work.

    but yes, the "press escape twice" thing is a good suggestion. i wonder if it could be done with a a simple MPX as well (with my skills no way, but..)

    Please, before someone chimes in with some reason why we don't need more security, this isn't an argument for security. IOT botnets aren't targeting telnet bulletin boards, they just don't know how to
    disambiguate a vulnerable server from a telnet BBS. So, we should step
    up our game in finding ways to block these things from tying up our
    nodes.

    hey, just run your telnet in another port! ..

    im guessing also that the telnet scanning folks do not even know about the
    bbs scene, and if they knew they wouldnt care haha.

    |08\ |07H7|08 of |07Blocktronics/dIVINE sTYLERS!/aCCESSiON/TRSi/Break!Ascii |08\ |07Haciend bbs sysop |08(|15telnet://haciend.com|08)|07

    --- Mystic BBS v1.12 A37 2017/12/23 (Linux/64)
    * Origin: Haciend.com | Scandinavian demoscene bbssince 1996 (21:1/155)
  • From h7@21:1/155 to g00r00 on Saturday, January 06, 2018 17:51:11
    I think you can do this with startup.mps in a few lines of code if you

    !! thats what i thought.

    Although I am confused by the hung nodes. If you have hung nodes there
    is a bigger problem. Did you disable inactivity timeout? Some of them will sit there all day if you turn off the mechanism to time them out.

    nope, i have inactivity timer set to a low value. the funny thing is that the server doesnt think the node is busy, but nodespy sees it.

    connections without a single leak, crash or ghost node. I also haven't had an unexplained ghost user in a very long time on my own BBS (unless something crashes when I'm developing which is explainable)... But I
    also run on non-standard ports so it doesn't get beat on. Those two scenarios do not seem to produce stuck nodes for me for some reason.

    i got two ghost users and their respective chat.dat files. the other one was clearly something that didnt belong. i also took a pcap, seems that the connection is reset but .. the bbs doesn't notice that the connection is dropped. as far as i can tell looking at the packets & their bits.

    |08\ |07H7|08 of |07Blocktronics/dIVINE sTYLERS!/aCCESSiON/TRSi/Break!Ascii |08\ |07Haciend bbs sysop |08(|15telnet://haciend.com|08)|07

    --- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
    * Origin: Haciend.com | Scandinavian demoscene bbssince 1996 (21:1/155)
  • From h7@21:1/155 to g00r00 on Saturday, January 06, 2018 17:53:06
    Are you talking about the current version when you talk about these
    nodes or was this with earlier versions that had known issues? I know
    for a bit you were still using an older version and a copy of MIS that
    had known issues.

    i had one of the pre-alphas from a37. with the a38 i havent had the problem since i now have the country blocking thing working for me again.

    the system password did really fix things, at least for me. its a perfect combination like you said.

    |08\ |07H7|08 of |07Blocktronics/dIVINE sTYLERS!/aCCESSiON/TRSi/Break!Ascii |08\ |07Haciend bbs sysop |08(|15telnet://haciend.com|08)|07

    --- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
    * Origin: Haciend.com | Scandinavian demoscene bbssince 1996 (21:1/155)
  • From Nugax@21:1/107 to All on Monday, January 08, 2018 07:18:02
    I'm writing an mpl now

    On 02:18 05/01 , h7 wrote:
    We should have a sysop-configurable option to enable a login "Press <escape> twice to continue" akin to old FrontDoor and Intermail
    answering services. We can put a 5 second timer (sysop configurable)
    that will just kick a user after the five seconds elapse. Ta-da, no more hung nodes.

    the hung nodes -thing is also something mystic itself should take care of. i >dont know why it doesn't. if i have the time today, i'll set up a recorder >for some few hundred megs of traffic to see how mystic behaves (or tries to >behave or doesnt) when trying to break up the connection. the timeout values >that are set in the config clearly do not work.

    but yes, the "press escape twice" thing is a good suggestion. i wonder if it >could be done with a a simple MPX as well (with my skills no way, but..)

    Please, before someone chimes in with some reason why we don't need more security, this isn't an argument for security. IOT botnets aren't targeting telnet bulletin boards, they just don't know how to disambiguate a vulnerable server from a telnet BBS. So, we should step
    up our game in finding ways to block these things from tying up our nodes.

    hey, just run your telnet in another port! ..

    im guessing also that the telnet scanning folks do not even know about the >bbs scene, and if they knew they wouldnt care haha.

    |08\ |07H7|08 of |07Blocktronics/dIVINE sTYLERS!/aCCESSiON/TRSi/Break!Ascii >|08\ |07Haciend bbs sysop |08(|15telnet://haciend.com|08)|07

    --- Mystic BBS v1.12 A37 2017/12/23 (Linux/64)
    * Origin: Haciend.com | Scandinavian demoscene bbssince 1996 (21:1/155)


    --
    yrNews Usenet Reader for iOS
    http://appstore.com/yrNewsUsenetReader

    --- Mystic BBS/NNTP v1.12 A38 2018/01/01 (Linux/64)
    * Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)
  • From g00r00@21:1/108 to h7 on Monday, January 08, 2018 15:20:46
    the hung nodes -thing is also something mystic itself should take care
    of. i dont know why it doesn't. if i have the time today, i'll set up a recorder for some few hundred megs of traffic to see how mystic behaves (or tries to behave or doesnt) when trying to break up the connection.
    the timeout values that are set in the config clearly do not work.

    I left a Linux/64 system up all weekend on 23 with no blocking and Nodespy up with auto-snoop. Just like the last time I did this test for A38, there were zero stuck nodes, zero crashes, no problems at all.

    This is without any system password set, just the typical login prompt.

    I need to find a way to get a stuck node for me to be able to fix it, and for whatever reason I just cannot seem to do it. Anything you can figure out
    would be very appreciated.

    It sounds like MIS is detecting the connection reset, but its just unable to stop the node process for some reason. I wonder what the node process could be doing? Are you able ps -A and see the stuck node and strace it?

    I'll see if I can clear out my iptables block list and then put it up again this weekend. Part of the problem is that I was running it with an IPBlock event last time I had it up (a few weeks ago), so I ended up auto-blocking a TON of the botnet with iptables.

    This past weekend I barely got hit compared to usual. Figures the one time I WANT them to spam the shit out of me, they don't lol.

    --- Mystic BBS v1.12 A39 2018/01/08 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From esc@21:2/142 to g00r00 on Monday, January 08, 2018 23:26:19
    I need to find a way to get a stuck node for me to be able to fix it,
    and for whatever reason I just cannot seem to do it. Anything you can figure out would be very appreciated.

    I could probably spin up a DO VM and reproduce this for you. Any way you can hit me up directly? I'll give you login credentials to ssh to the server.

    --- Mystic BBS v1.12 A38 2018/01/01 (Linux/32)
    * Origin: lo fidelity bbs (21:2/142)
  • From h7@21:1/155 to g00r00 on Tuesday, January 09, 2018 16:00:11
    I left a Linux/64 system up all weekend on 23 with no blocking and
    Nodespy up with auto-snoop. Just like the last time I did this test for A38, there were zero stuck nodes, zero crashes, no problems at all.

    damn :)

    It sounds like MIS is detecting the connection reset, but its just
    unable to stop the node process for some reason. I wonder what the node process could be doing? Are you able ps -A and see the stuck node and strace it?

    sure. i've been having less hung nodes lately but i'll do it when i get one next time. shouldnt take more than a day or two.

    I'll see if I can clear out my iptables block list and then put it up again this weekend. Part of the problem is that I was running it with
    an IPBlock event last time I had it up (a few weeks ago), so I ended up auto-blocking a TON of the botnet with iptables.

    This past weekend I barely got hit compared to usual. Figures the one time I WANT them to spam the shit out of me, they don't lol.

    yeah, for some reason things got a bit more quiet. i think in my end its a combination fo

    |08\ |07H7|08 of |07Blocktronics/dIVINE sTYLERS!/aCCESSiON/TRSi/Break!Ascii |08\ |07Haciend bbs sysop |08(|15telnet://haciend.com|08)|07

    --- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
    * Origin: Haciend.com | Scandinavian demoscene bbssince 1996 (21:1/155)