• Connecting to mystic system doesn't work

    From Wilfred van Velzen@2:280/464 to All on Sat Jun 24 21:32:48 2017
    Hi All,

    When I try to connect to a particular "Mystic/1.12A34 binkp/1.0" system, all I get is this:

    + 24 Jun 20:57:40 [30502] call to ***
    24 Jun 20:57:40 [30502] trying ***...
    24 Jun 20:57:40 [30502] connected
    + 24 Jun 20:57:40 [30502] outgoing session with ***
    ? 24 Jun 20:57:41 [30502] recv: Connection reset by peer
    + 24 Jun 20:57:41 [30502] holding *** (2017/06/24 22:57:41)
    + 24 Jun 20:57:41 [30502] done (to ***, failed, S/R: 0/0 (0/0 bytes))
    24 Jun 20:57:41 [30502] session closed, quitting...

    Is this a known problem maybe? Or what could it be?

    When he polls mine it seems to work...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.12-B20170618
    * Origin: FMail development HQ (2:280/464)
  • From g00r00@1:129/215 to Wilfred van Velzen on Sat Jun 24 16:56:13 2017
    When I try to connect to a particular "Mystic/1.12A34 binkp/1.0" system, all I get is this:

    + 24 Jun 20:57:40 [30502] call to ***
    24 Jun 20:57:40 [30502] trying ***...
    24 Jun 20:57:40 [30502] connected
    + 24 Jun 20:57:40 [30502] outgoing session with ***
    ? 24 Jun 20:57:41 [30502] recv: Connection reset by peer
    + 24 Jun 20:57:41 [30502] holding *** (2017/06/24 22:57:41)

    Is this a known problem maybe? Or what could it be?

    There aren't any known issues with Mystic's BINKP at the moment.

    Are you able to get a log from that system from the Mystic side to see if
    it reports an error on its side?

    What software are you using? I know there is some issue with someone I know who has a BBBS system where his system keeps polling Mystic over and over
    (but Mystic connecting to him works fine).

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Sat Jun 24 19:51:26 2017

    On 2017 Jun 24 21:32:48, you wrote to All:

    When I try to connect to a particular "Mystic/1.12A34 binkp/1.0"
    system, all I get is this:

    + 24 Jun 20:57:40 [30502] call to ***
    24 Jun 20:57:40 [30502] trying ***...
    24 Jun 20:57:40 [30502] connected
    + 24 Jun 20:57:40 [30502] outgoing session with ***
    ? 24 Jun 20:57:41 [30502] recv: Connection reset by peer
    + 24 Jun 20:57:41 [30502] holding *** (2017/06/24 22:57:41)
    + 24 Jun 20:57:41 [30502] done (to ***, failed, S/R: 0/0 (0/0 bytes))
    24 Jun 20:57:41 [30502] session closed, quitting...

    Is this a known problem maybe? Or what could it be?

    When he polls mine it seems to work...

    which mystic system? i've seen netmail from you jambed up because the destination has the "require secure session" setting enabled... i've contacted that NC about said netmail but haven't heard anything back yet...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... You pretend to work, and we'll pretend to pay you.
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to g00r00 on Sat Jun 24 19:53:26 2017

    On 2017 Jun 24 16:56:12, you wrote to Wilfred van Velzen:

    When I try to connect to a particular "Mystic/1.12A34 binkp/1.0"
    system, all I get is this:

    + 24 Jun 20:57:40 [30502] call to ***
    24 Jun 20:57:40 [30502] trying ***...
    24 Jun 20:57:40 [30502] connected
    + 24 Jun 20:57:40 [30502] outgoing session with ***
    ? 24 Jun 20:57:41 [30502] recv: Connection reset by peer
    + 24 Jun 20:57:41 [30502] holding *** (2017/06/24 22:57:41)

    Is this a known problem maybe? Or what could it be?

    There aren't any known issues with Mystic's BINKP at the moment.

    no but ""require secure session"" seems to be getting in the way for some reason...

    Are you able to get a log from that system from the Mystic side to see
    if it reports an error on its side?

    What software are you using? I know there is some issue with someone
    I know who has a BBBS system where his system keeps polling Mystic
    over and over (but Mystic connecting to him works fine).

    i have binkd... in my case, the destination has "require secure session" enabled which is blocking general netmails from any system to connect to their's...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... I should have quit while I was not as far behind.
    ---
    * Origin: (1:3634/12.73)
  • From Paul Hayton@3:770/100 to Wilfred van Velzen on Sun Jun 25 13:59:34 2017
    On 06/24/17, Wilfred van Velzen pondered and said...

    Hi All,

    When I try to connect to a particular "Mystic/1.12A34 binkp/1.0" system, all I get is this:

    + 24 Jun 20:57:40 [30502] call to ***
    24 Jun 20:57:40 [30502] trying ***...
    24 Jun 20:57:40 [30502] connected
    + 24 Jun 20:57:40 [30502] outgoing session with ***
    ? 24 Jun 20:57:41 [30502] recv: Connection reset by peer
    + 24 Jun 20:57:41 [30502] holding *** (2017/06/24 22:57:41)
    + 24 Jun 20:57:41 [30502] done (to ***, failed, S/R: 0/0 (0/0 bytes))
    24 Jun 20:57:41 [30502] session closed, quitting...

    Is this a known problem maybe? Or what could it be?

    When he polls mine it seems to work...

    Check with the admin that your IP address has not ended up in badip.txt in
    the data dir of Mystic. If it has he should remove it and restart his MIS.

    If you are on a static IP let him know what it is and get him to add it to goodip.txt in the mystic data dir.. he may need to create the txt file from scratch.

    Best, Paul.

    --- Mystic BBS v1.12 A33 (Windows/32)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)
  • From Dan Richter@1:317/3 to Wilfred van Velzen on Sat Jun 24 23:12:36 2017
    On 06/24/17, Wilfred van Velzen said the following...

    When I try to connect to a particular "Mystic/1.12A34 binkp/1.0" system, all I get is this:

    + 24 Jun 20:57:40 [30502] outgoing session with ***
    ? 24 Jun 20:57:41 [30502] recv: Connection reset by peer
    + 24 Jun 20:57:41 [30502] holding *** (2017/06/24 22:57:41)
    + 24 Jun 20:57:41 [30502] done (to ***, failed, S/R: 0/0 (0/0 bytes))
    24 Jun 20:57:41 [30502] session closed, quitting...

    Is there any chance your IP is listed in their badip list? I've had that
    happen here when someone couldn't connect with me.


    ---

    Dan Richter
    aka Black Panther
    Sysop - Castle Rock BBS (RCS)
    telnet://castlerockbbs.com
    The sparrows are flying again...

    --- Mystic BBS v1.12 A34 (Windows/64)
    * Origin: Castle Rock BBS - castlerockbbs.com (1:317/3)
  • From g00r00@1:129/215 to Paul Hayton on Sun Jun 25 10:11:31 2017
    Check with the admin that your IP address has not ended up in badip.txt
    in the data dir of Mystic. If it has he should remove it and restart his MIS.

    Yep, this sounds like a likely scenario. If the SysOp has auto banning of IP's on after a certain # of connections within a certain time frame, then Mystic will simply print "BLOCKED" to the socket and disconnect.

    How BBBS handles that is unknown to me, but that would absolutely explain it.

    And BBBS does seem to have that issue where it endlessly pools according to someone on FSXNET, so that would explain how the IP was banned to begin with too.

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)
  • From Nicholas Boel@1:154/10 to mark lewis on Sun Jun 25 13:54:54 2017
    Hello mark,

    On Sat Jun 24 2017 19:53:26, mark lewis wrote to g00r00:

    i have binkd... in my case, the destination has "require secure
    session" enabled which is blocking general netmails from any system to connect to their's...

    Almost sounds like they have CRAM-MD5 enabled in the binkp server, rather than on a per-link basis.

    Regards,
    Nick

    ... "Не знаю. Я здесь только работаю."
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)
  • From mark lewis@1:3634/12.73 to Nicholas Boel on Sun Jun 25 15:22:14 2017
    On 2017 Jun 25 13:54:54, you wrote to me:

    i have binkd... in my case, the destination has "require secure
    session" enabled which is blocking general netmails from any system
    to connect to their's...

    Almost sounds like they have CRAM-MD5 enabled in the binkp server,
    rather than on a per-link basis.

    yeah, i forget what the setting is but it is set and no one can connect to them
    unless they already have a session set up... i understand the setting but it kinda puts the cart before the horse as when things change while an operator is
    sleeping (eg: a net host goes away), there's no way for others to drop them a netmail and let them know since they're blocking everyone by default...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... The Adventures Of WIN.INI The Pooh By W. Gates.
    ---
    * Origin: (1:3634/12.73)
  • From Nicholas Boel@1:154/10 to mark lewis on Sun Jun 25 14:40:26 2017
    Hello mark,

    On Sun Jun 25 2017 15:22:14, mark lewis wrote to Nicholas Boel:

    Almost sounds like they have CRAM-MD5 enabled in the binkp
    server, rather than on a per-link basis.

    yeah, i forget what the setting is but it is set and no one can
    connect to them unless they already have a session set up... i
    understand the setting but it kinda puts the cart before the horse as
    when things change while an operator is sleeping (eg: a net host goes away), there's no way for others to drop them a netmail and let them
    know since they're blocking everyone by default...

    Agreed. I totally understand the setting as well, but there have been quite a bit of people that don't since it was added, and this is usually the result until they can be contacted somehow.

    I believe this is the only thing I have ever asked to be removed from the config, since any and all times I've run into another system with it enabled, it has caused problems. I don't really think there is a need these days for forcing CRAM-MD5 100% of the time, since that makes it impossible to send general direct netmail. IMO, it should only be a per defined link setting, and not a global one.

    Maybe even having some huge colorful flashing pop-up when you enable it saying "Don't be stupid, enabling this won't allow any general connections from anyone
    besides defined links in your config!!!"

    ... or something. ;)

    Regards,
    Nick

    ... "Не знаю. Я здесь только работаю."
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)
  • From Wilfred van Velzen@2:280/464 to Paul Hayton on Sun Jun 25 23:11:39 2017
    Hi Paul,

    On 2017-06-25 13:59:34, you wrote to me:

    When I try to connect to a particular "Mystic/1.12A34 binkp/1.0"
    system, all I get is this:

    + 24 Jun 20:57:40 [30502] call to ***
    24 Jun 20:57:40 [30502] trying ***...
    24 Jun 20:57:40 [30502] connected
    + 24 Jun 20:57:40 [30502] outgoing session with ***
    ? 24 Jun 20:57:41 [30502] recv: Connection reset by peer
    + 24 Jun 20:57:41 [30502] holding *** (2017/06/24 22:57:41)
    + 24 Jun 20:57:41 [30502] done (to ***, failed, S/R: 0/0 (0/0 bytes))
    24 Jun 20:57:41 [30502] session closed, quitting...

    Is this a known problem maybe? Or what could it be?

    When he polls mine it seems to work...

    Check with the admin that your IP address has not ended up in badip.txt in the data dir of Mystic. If it has he should remove it and restart his MIS.

    Do you still get a tcp/ip connection when that's the case? See the "connected" above, and the 1 second delay before the "connection reset"...

    If you are on a static IP let him know what it is and get him to add
    it to goodip.txt in the mystic data dir.. he may need to create the
    txt file from scratch.

    I'll inform him about this. Thanks!

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.12-B20170618
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Dan Richter on Sun Jun 25 23:23:41 2017
    Hi Dan,

    On 2017-06-24 23:12:36, you wrote to me:

    When I try to connect to a particular "Mystic/1.12A34 binkp/1.0"
    system, all I get is this:

    + 24 Jun 20:57:40 [30502] outgoing session with ***
    ? 24 Jun 20:57:41 [30502] recv: Connection reset by peer
    + 24 Jun 20:57:41 [30502] holding *** (2017/06/24 22:57:41)
    + 24 Jun 20:57:41 [30502] done (to ***, failed, S/R: 0/0 (0/0 bytes))
    24 Jun 20:57:41 [30502] session closed, quitting...

    Is there any chance your IP is listed in their badip list? I've had that happen here when someone couldn't connect with me.

    I'll have the other system check that...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.12-B20170618
    * Origin: FMail development HQ (2:280/464)
  • From g00r00@1:129/215 to Wilfred van Velzen on Sun Jun 25 19:20:43 2017
    Do you still get a tcp/ip connection when that's the case? See the "connected" above, and the 1 second delay before the "connection
    reset"...

    Yes, it would still connect that is the only way it can get the incoming IP to check it against the database of bad IP addresses. So when a blocked IP tries to connect, they'll connect successfully then get a "BLOCKED" printed to the client before disconnecting shortly after.

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)
  • From Wilfred van Velzen@2:280/464 to g00r00 on Mon Jun 26 11:41:30 2017
    Hi g00r00,

    On 2017-06-25 19:20:43, you wrote to me:

    Do you still get a tcp/ip connection when that's the case? See the
    "connected" above, and the 1 second delay before the "connection
    reset"...

    Yes, it would still connect that is the only way it can get the incoming
    IP
    to check it against the database of bad IP addresses. So when a blocked
    IP
    tries to connect, they'll connect successfully then get a "BLOCKED"
    printed
    to the client before disconnecting shortly after.

    That doesn't show in the binkd log file. Maybe it's possible to change that so a more meaning full message appears in the binkd log file of the system that's trying to connect?

    Anyway, he had the Netherlands blocked in his badcountry.txt. Once that was removed the connection worked... :-/ ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.12-B20170618
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to mark lewis on Mon Jun 26 11:47:10 2017
    Hi mark,

    On 2017-06-24 19:51:26, you wrote to me:

    which mystic system? i've seen netmail from you jambed up because the destination has the "require secure session" setting enabled... i've contacted that NC about said netmail but haven't heard anything back
    yet...

    That was a different system I had issues with connecting directly. ;)

    Thanks for getting involved to fix this!

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.12-B20170618
    * Origin: FMail development HQ (2:280/464)
  • From Chad Adams@1:130/210 to All on Mon Jun 26 07:58:58 2017
    That looks like something is causing you to not connect. Your welcome to contact me and get a connection too LinuxNode which is latest mystic serving Fido. We can get it figure out.

    Message me if you want to test.

    On 16:32 24/06 , Wilfred van Velzen wrote:
    Hi All,

    When I try to connect to a particular "Mystic/1.12A34 binkp/1.0" system, all I >get is this:

    + 24 Jun 20:57:40 [30502] call to ***
    24 Jun 20:57:40 [30502] trying ***...
    24 Jun 20:57:40 [30502] connected
    + 24 Jun 20:57:40 [30502] outgoing session with ***
    ? 24 Jun 20:57:41 [30502] recv: Connection reset by peer
    + 24 Jun 20:57:41 [30502] holding *** (2017/06/24 22:57:41)
    + 24 Jun 20:57:41 [30502] done (to ***, failed, S/R: 0/0 (0/0 bytes))
    24 Jun 20:57:41 [30502] session closed, quitting...

    Is this a known problem maybe? Or what could it be?

    When he polls mine it seems to work...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.12-B20170618
    * Origin: FMail development HQ (2:280/464)


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

    --- Mystic BBS/NNTP v1.12 A33 (Linux/64)
    * Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (1:130/210)
  • From g00r00@1:129/215 to Wilfred van Velzen on Mon Jun 26 10:26:50 2017
    That doesn't show in the binkd log file. Maybe it's possible to change that so a more meaning full message appears in the binkd log file of the system that's trying to connect?

    Maybe, but I think that would be up to binkd to do so.

    Anyway, he had the Netherlands blocked in his badcountry.txt. Once that was removed the connection worked... :-/ ;)

    Well at least we got to the bottom of it now! I am glad its working for you.

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)
  • From Wilfred van Velzen@2:280/464 to Chad Adams on Mon Jun 26 18:25:56 2017
    Hi Chad,

    On 2017-06-26 07:58:58, you wrote to All:

    That looks like something is causing you to not connect. Your welcome
    to contact me and get a connection too LinuxNode which is latest
    mystic serving Fido. We can get it figure out.

    Message me if you want to test.

    I don't mind another link. ;)

    But the connection issue was already resolved. It was an IP range block in his mystic configuration. :-/ ;)


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.12-B20170618
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to g00r00 on Mon Jun 26 18:28:37 2017
    Hi g00r00,

    On 2017-06-26 10:26:50, you wrote to me:

    That doesn't show in the binkd log file. Maybe it's possible to
    change that so a more meaning full message appears in the binkd log
    file of the system that's trying to connect?

    Maybe, but I think that would be up to binkd to do so.

    Binkd only knows the binkp protocol. The "blocked" message is outside that protocol, so just garbage to it, which is ignored. (I suspect)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.12-B20170618
    * Origin: FMail development HQ (2:280/464)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Mon Jun 26 14:47:10 2017
    On 2017 Jun 26 11:47:10, you wrote to me:

    which mystic system? i've seen netmail from you jambed up because the
    destination has the "require secure session" setting enabled... i've
    contacted that NC about said netmail but haven't heard anything back
    yet...

    That was a different system I had issues with connecting directly. ;)

    yeah, i kinda guessed it was...

    Thanks for getting involved to fix this!

    still waiting on word back... hopefully the operator will wake up soon...

    sad that there aren't any netmail zonegates for his other networks so that one could send netmail through them to his system... zonegates were a GoodThing<tm>... granted, they were used for fidonet zones in the beginning but
    the concept works and worked great for othernets, too... sure, some of them may
    not want contact from "fidonet" but we're only talking about netmail here, not echos... route or deliver direct to the zonegate and let them handle delivery on the other side based on their network ops... it is crazy to have to join an othernet just to be able to let someone know of a problem on their system... that's playing othernet roulette just trying to find one that they may be active on...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Don't bother thinking - it just causes frustration.
    ---
    * Origin: (1:3634/12.73)
  • From Wilfred van Velzen@2:280/464 to mark lewis on Mon Jun 26 21:44:12 2017
    Hi mark,

    On 2017-06-26 14:47:10, you wrote to me:

    Thanks for getting involved to fix this!

    still waiting on word back... hopefully the operator will wake up soon...

    Are we talking about 1:123/0 here?

    sad that there aren't any netmail zonegates for his other networks so
    that one could send netmail through them to his system... zonegates
    were a GoodThing<tm>... granted, they were used for fidonet zones in
    the beginning but the concept works and worked great for othernets,
    too... sure, some of them may not want contact from "fidonet" but
    we're only talking about netmail here, not echos... route or deliver direct to the zonegate and let them handle delivery on the other side based on their network ops... it is crazy to have to join an othernet
    just to be able to let someone know of a problem on their system...
    that's playing othernet roulette just trying to find one that they may
    be active on...

    I don't see how that would have helped here. I couldn't deliver crash mail to this node (as a node of either net), because he disabled unsecure sessions. So I tried a routed netmail in fidonet, guessing he would have a secure connection
    setup with his Host.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.12-B20170618
    * Origin: FMail development HQ (2:280/464)
  • From Nicholas Boel@1:154/10 to g00r00 on Mon Jun 26 16:37:36 2017
    Hello g00r00,

    On Mon Jun 26 2017 10:26:50, g00r00 wrote to Wilfred van Velzen:

    That doesn't show in the binkd log file. Maybe it's possible to
    change that so a more meaning full message appears in the binkd
    log file of the system that's trying to connect?

    Maybe, but I think that would be up to binkd to do so.

    I think what he was trying to say, was that he was not notified by Mystic of being blocked in his connection logs, and you originally said it's supposed to do so.

    I also don't think I have ever seen "BLOCKED" in any Mystic connection, and there was a few times I got banned when someone has their connection filter on yet wanted me to crash mail to them. ;)

    Basically, it just says "connection reset by peer" or something in those lines,
    with no explanation as to why.

    Regards,
    Nick

    ... "Не знаю. Я здесь только работаю."
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)
  • From g00r00@1:129/215 to Wilfred van Velzen on Mon Jun 26 15:34:15 2017
    Maybe, but I think that would be up to binkd to do so.

    Binkd only knows the binkp protocol. The "blocked" message is outside
    that protocol, so just garbage to it, which is ignored. (I suspect)

    Yep I am well aware of that. But I thought you asked about changing it so a meaningful message appears in the BINKD log. I am not a binkd developer, so I can't change the way it logs anything! :)

    If your IP is blocked the connection is dropped when you try to connect. The way that binkd logs that is not up to me; I'm not sure there is anything I could do other than to not block it when its blocked.

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)
  • From g00r00@1:129/215 to Nicholas Boel on Mon Jun 26 17:43:40 2017
    I think what he was trying to say, was that he was not notified by
    Mystic of being blocked in his connection logs, and you originally said it's supposed to do so.

    Are you saying on the Mystic side? He's not using Mystic.

    Why would binkd say anything about being blocked? Its not the one doing the blocking.

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)
  • From Nicholas Boel@1:154/10 to g00r00 on Mon Jun 26 21:26:26 2017
    Hello g00r00,

    On Mon Jun 26 2017 17:43:40, g00r00 wrote to Nicholas Boel:

    Are you saying on the Mystic side? He's not using Mystic.

    I know this.

    Why would binkd say anything about being blocked? Its not the one
    doing the blocking.

    If Mystic is sending the text, shouldn't binkd log it? I mean, unless one of the binkd programmers had a feeling the future would bring a "BLOCKED" message and ultimately be programmed to ignore it..?

    I'm just kinda baffled that it wouldn't log something that another mailer sent to it.. regardless if it's not actually part of the protocol or not. And if binkd would actually display it if it were sent to it, I was just letting you know that I've never seen that blocked message either, so it either isn't logging it, or it isn't actually being sent by Mystic.

    Or is this something only visable on the Mystic side?

    Regards,
    Nick

    ... "Не знаю. Я здесь только работаю."
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Mon Jun 26 22:17:08 2017

    On 2017 Jun 26 21:44:12, you wrote to me:

    Thanks for getting involved to fix this!

    still waiting on word back... hopefully the operator will wake up
    soon...

    Are we talking about 1:123/0 here?

    no... /10... i just polled and got the same "rerror: unsecured session not allowed" response... the clock is ticking ;)

    sad that there aren't any netmail zonegates for his other networks so
    that one could send netmail through them to his system... zonegates
    were a GoodThing<tm>... granted, they were used for fidonet zones in
    the beginning but the concept works and worked great for othernets,
    too... sure, some of them may not want contact from "fidonet" but
    we're only talking about netmail here, not echos... route or deliver
    direct to the zonegate and let them handle delivery on the other side
    based on their network ops... it is crazy to have to join an othernet
    just to be able to let someone know of a problem on their system...
    that's playing othernet roulette just trying to find one that they
    may be active on...

    I don't see how that would have helped here. I couldn't deliver crash
    mail to this node (as a node of either net), because he disabled
    unsecure sessions. So I tried a routed netmail in fidonet, guessing he would have a secure connection setup with his Host.

    right but routed netmail via one of his other nets might very well work... especially if there's not a connection made to his NC who was just placed a few
    months ago and may still be trying to get connections with all his nodes since the previous NC stepped down pretty quickly...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Hint for Mom: Kids prefer hot dogs to duck a l'orange.
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to g00r00 on Mon Jun 26 22:26:34 2017

    On 2017 Jun 26 15:34:14, you wrote to Wilfred van Velzen:

    If your IP is blocked the connection is dropped when you try to
    connect. The way that binkd logs that is not up to me; I'm not sure
    there is anything I could do other than to not block it when its
    blocked.

    here's an idea... add some intelligence so that mystic might see if there's a mailer calling... if there is, then send a custom netmail reply telling them they are blocked... if it isn't a mailer, then just block... this should be easy to do and blocks could even be set to be limited by port instead of just the originating address... let's see what port they are connection to and then block or not... MMS! make mystic smarter! :) O:) :)

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... One day I woke up and discovered that I was in love with tripe.
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to g00r00 on Mon Jun 26 22:29:18 2017

    On 2017 Jun 26 17:43:40, you wrote to Nicholas Boel:

    I think what he was trying to say, was that he was not notified by
    Mystic of being blocked in his connection logs, and you originally
    said it's supposed to do so.

    Are you saying on the Mystic side? He's not using Mystic.

    Why would binkd say anything about being blocked? Its not the one
    doing the blocking.

    you said that mystic sent "BLOCKED" back to the connecting system... binkd cannot see that and records it as trash since it isn't in the binkd protocol...
    the original request was asking about some way to send binkd the blocked notice
    so that it would know what it was... attempting a connection and sending a netmail would be one way to notify the operator of the connecting system ;)

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Never let negative things fill your mind lest they take over your life.
    ---
    * Origin: (1:3634/12.73)
  • From robert wolfe@1:116/18 to mark lewis on Mon Jun 26 22:04:00 2017
    On 06-85-39, mark lewis said...

    here's an idea... add some intelligence so that mystic might see if there' mailer calling... if there is, then send a custom netmail reply telling th they are blocked... if it isn't a mailer, then just block... this should b easy to do and blocks could even be set to be limited by port instead of j the originating address... let's see what port they are connection to and block or not... MMS! make mystic smarter! :) O:) :)

    Or even some intelligence that will allow FTN transfers over telnet (like an in-built frontdoor). :)

    --- Mystic BBS v1.05/OS2
    * Origin: Neptune's Lair/2 * Olive Branch MS * os2bbs.org (1:116/18)
  • From Wilfred van Velzen@2:280/464 to g00r00 on Tue Jun 27 10:52:54 2017
    Hi g00r00,

    On 2017-06-26 15:34:15, you wrote to me:

    Binkd only knows the binkp protocol. The "blocked" message is outside
    that protocol, so just garbage to it, which is ignored. (I suspect)

    Yep I am well aware of that. But I thought you asked about changing it so a meaningful message appears in the BINKD log. I am not a binkd
    developer,
    so I can't change the way it logs anything! :)

    If your IP is blocked the connection is dropped when you try to connect.

    The tcp/ip connection is first made, then dropped. A "normal" firewall just wouldn't allow the connection to be made. That's were the confusion in the binkd log starts.

    The way that binkd logs that is not up to me; I'm not sure there is anything I could do other than to not block it when its blocked.

    What Mark said: Talk to the mailer a bit. There probably is a message in the protocol that can tell the mailer on the otherside it isn't allowed to connect.
    Like mystic does when it tells the otherside that unsecure sessions are not allowed.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.12-B20170618
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to mark lewis on Tue Jun 27 11:03:10 2017
    Hi mark,

    On 2017-06-26 22:17:08, you wrote to me:

    still waiting on word back... hopefully the operator will wake up
    soon...

    Are we talking about 1:123/0 here?

    no... /10... i just polled and got the same "rerror: unsecured session not allowed" response... the clock is ticking ;)

    I meant Ed was involved in fixing this. But I have established email contact with /10, so I could ask him to contact Ed to resolve this?

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.12-B20170618
    * Origin: FMail development HQ (2:280/464)
  • From Paul Hayton@3:770/100 to mark lewis on Tue Jun 27 21:47:00 2017
    On 06/26/17, mark lewis pondered and said...

    sad that there aren't any netmail zonegates for his other networks so
    that one could send netmail through them to his system... zonegates were
    a GoodThing<tm>... granted, they were used for fidonet zones in the beginning but the concept works and worked great for othernets, too... sure, some of them may not want contact from "fidonet" but we're only talking about netmail here, not echos... route or deliver direct to the zonegate and let them handle delivery on the other side based on their network ops... it is crazy to have to join an othernet just to be able
    to let someone know of a problem on their system... that's playing othernet roulette just trying to find one that they may be active on...

    Where do I find the software to run this? Sounds like an interesting thing to do for netmail between Zone 21 and others.

    --- Mystic BBS v1.12 A34 (Windows/32)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Tue Jun 27 10:11:50 2017

    On 2017 Jun 27 11:03:10, you wrote to me:

    still waiting on word back... hopefully the operator will wake up
    soon...

    Are we talking about 1:123/0 here?

    no... /10... i just polled and got the same "rerror: unsecured
    session not allowed" response... the clock is ticking ;)

    I meant Ed was involved in fixing this.

    yeah but i'm not sure what "this" is... are you talking about resolving the "rerror: Unsecured session not allowed" problem? if so, /10 can do that themselves without ed needing to tell him about it... since you have email contact with /10, you can let them know ;) then once /10 turns that option off,
    direct and routed netmail can be delivered there and his NC can contact him if/when necessary...

    But I have established email contact with /10, so I could ask him to contact Ed to resolve this?

    the main thing is for /10 to turn off that forced secure sessions option so that insecure sessions can take place for delivery of netmail from random systems... it is especially bad if it stays turned on and his NC cannot contact
    him... i would expect that the node would be removed from the nodelist after some time of the NC being unable to contact them and this not being resolved...
    tick tock tick tock tick tock...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... I want a girl, just like the girl, that married dear old Dad! ;*)
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Paul Hayton on Tue Jun 27 10:14:40 2017

    On 2017 Jun 27 21:47:00, you wrote to me:

    sad that there aren't any netmail zonegates for his other networks so
    that one could send netmail through them to his system... zonegates
    were a GoodThing<tm>... granted, they were used for fidonet zones in
    the beginning but the concept works and worked great for othernets,
    too... sure, some of them may not want contact from "fidonet" but
    we're only talking about netmail here, not echos... route or deliver
    direct to the zonegate and let them handle delivery on the other side
    based on their network ops... it is crazy to have to join an othernet
    just to be able to let someone know of a problem on their system...
    that's playing othernet roulette just trying to find one that they
    may be active on...

    Where do I find the software to run this? Sounds like an interesting
    thing to do for netmail between Zone 21 and others.

    technically speaking, it should be just a nodelist entry in both FTN nets and some routing statements... normal routing of netmails via your tosser (or smart
    dynamic mailer) should be able to handle it... the main thing being that Z21 netmails should be able to be routed or delivered directly to the Z21 gateway system and that system would then send the netmail on toward the Z21 destination... replies would come back through the Z21 gateway system to the fidonet side and make their way to the destination...

    there was a trick, of sorts, that was done at one time... mainly the message header contained the zonegate information and the control lines contained the actual destination but i'm not so sure that that needs to be done, these days... if everyone has their routing set up properly, then all Z21 netmail should be directed to the FIDO<->Z21 zonegate...

    there is, somewhere, a document written by randy bush (IIRC) that explains how zonegates worked when they were conceived... the real key is the ^aINTL line...
    FSC-0004 explains but i think it tends to confuse netmail and echomail as randy
    speaks of stripping seenbys which are an echomail thing and not in netmail... anyway, yeah, a smart router looks at the ^aINTL line and then packages the netmail for the proper next hop system based on the zones in the ^aINTL line...
    there are some other parts that can or maybe should be used, too... FSC-0035 also comes to mind... it uses something similar to the old UUCP format where the first line of the message body was

    TO: some user

    when that part would not fit in the alloted 36 character To field in the message header...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... "Nollaig Chridheil agus Bliadhna Mhath Ur." - Gaelic-Scot Christmas
    ---
    * Origin: (1:3634/12.73)
  • From g00r00@1:129/215 to Nicholas Boel on Tue Jun 27 10:50:39 2017
    I'm going to sort of direct this to all three of you so I don't repeat
    myself, please ignore whatever doesn't apply to you.

    If Mystic is sending the text, shouldn't binkd log it? I mean, unless

    I have nothing to do with binkd so I have no idea what it does. :)

    I would think it doesn't log anything except that the connection was lost because that is what happens. It connects and the connection is terminated by the server before anything related to BINKP happens because the IP is blocked.

    Or is this something only visable on the Mystic side?

    Mystic prints "BLOCKED" and disconnects by default. It can also replace that text with a .txt file which means the SysOp can display more (or nothing) if they want to. I don't like this feature personally, but some SysOps requested a way to print something to the client connection before the connection is refused.

    It may be that the text never makes it to binkd, or the Sysop doesn't send anything, or that it just doesn't do anything with it.

    PART 2: As far as server interaction, mentioned by some... :)

    I think there may be a fundamental misunderstanding of how blocking works. This is a "software firewall" that sits between a connection and the servers. It enforces IP blocking, blacklist DNS, blocking by country, auto IP banning rules, etc. A blocked IP never makes it to the BINKP (or any other) server for any sort of interaction nor should it under any circumstance.

    The point of a firewall is to prevent an IP from interacting with your system or server, and Mystic doesn't and isn't going to give a blocked IP an opportunity to send any data to any of its servers. If a firewall let a blocked IP access your system, then the firewall would be broken right?

    What if there was a BINKP handshake bug that caused your system to drop to a bash shell, and even though you blocked their IP, that person was still able to connect and continually exploit your system...

    This would only be possible if the firewall let a blocked IP in long enough to see if it tries to do a BINKP handshake. And why? So it can print a pretty little message to a client IP that you've already banned for trying to hack your system? No way.

    Allowing something like that just doesn't make sense, and it negates the
    entire purpose of having the software-based network security features.

    Anyway, I don't want to spend a lot of time discussing this stuff when I
    could be actually getting stuff done! :)

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)
  • From g00r00@1:129/215 to mark lewis on Tue Jun 27 10:51:46 2017
    here's an idea... add some intelligence so that mystic might see if there's a mailer calling... if there is, then send a custom netmail

    A new connection arrives you have an IP address and thats it. If its blocked, its blocked. There is no way to identify if the incoming connection would be a mailer that wanted to do BINKP unless you let the blocked IP into your servers.

    I replied to Nick with a little more detail if you want to hear more

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)
  • From Wilfred van Velzen@2:280/464 to mark lewis on Tue Jun 27 21:23:21 2017
    Hi mark,

    On 2017-06-27 10:11:50, you wrote to me:

    I meant Ed was involved in fixing this.

    yeah but i'm not sure what "this" is... are you talking about resolving
    the
    "rerror: Unsecured session not allowed" problem? if so, /10 can do that themselves without ed needing to tell him about it... since you have email contact with /10, you can let them know ;) then once /10 turns that option off, direct and routed netmail can be delivered there and his NC can contact him if/when necessary...

    I've just asked him to do that. Does anyone know the exact setting that needs to be changed? In case he asks?


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.12-B20170618
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to mark lewis on Tue Jun 27 22:44:22 2017
    Hi mark,

    On 2017-06-27 10:11:50, you wrote to me:

    it is especially bad if it stays turned on and his NC cannot contact him... i would expect that the node would be removed from the nodelist after some time of the NC being unable to contact them and this not
    being resolved... tick tock tick tock tick tock...

    /10 Asked me to give his e-mail address to /0. So I just crashmailed Ed this info. Now it's up to them to get a connection going... ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.12-B20170618
    * Origin: FMail development HQ (2:280/464)