Hello, Karel!

Thursday August 07 2025 22:20, you wrote to me:

I've terminated the session after getting all the
required information from your software. It's not a
fully functional client, just a basic tester written
in python from scratch in 1 evening.

I feel that more from category abuse then someting else. But maybe I

So, is calling your node with the binkp protocol considered abuse? Or only if you see "failed" in the log?

am alone with that opinion a majority agrees on acceptance that
"testing".

If not, I put fail2ban back on that.

It's up to you. In this case Czech Republic will have even fewer active nodes in statistics.

Best regards,
dp.

--- GoldED+/OSX 1.1.5-b20250409
* Origin: All is good in St. John's Wood (2:5001/100.1)

Hi Dmitry.

06 Aug 25 17:32, Michiel van der Vlist wrote to you:

Is this you testing?

I find your tests at my 2:221/* nodes other than 2:221/360. Is it because of the non-standard binkp port in this node?

] incoming session with 141.147.64.254
] VER NodelistDB-BinkpClient/1.0 binkp/1.0
] SYS NodelistDB Analytics
] TIME Tue, 05 Aug 2025 22:44:34 +0000
] addr: 2:5001/5001@fidonet
] recv: connection closed by foreign host
] done (from 2:5001/5001@fidonet, failed, S/R: 0/0 (0/0 bytes))
] session closed, quitting...
] rc(541863)=0

'Tommi

---
* Origin: nntps://news.fidonet.fi (2:221/360)

Hello Dmitry!

07 Aug 25 23:56, you wrote to me:

So, is calling your node with the binkp protocol considered abuse? Or
only if you see "failed" in the log?

Failed is the trigger.

It's up to you. In this case Czech Republic will have even fewer
active nodes in statistics.

What I am saying: I am OK with any kind of improvements - but it should be somehow communicated and also "approved" (accepted). Checked some FTS related to binkp and not sure if your broken client (put it like this) is against some of specifications.

And again in general I keep fingers crossed for you. I just missed: why we are doing (clarified), how we are doing (clarified step by step), how exceptions are handled (can I influence result later, still missing), etc.

Karel

--- GoldED+/LNX 1.1.5-b20240209
* Origin: Plast DATA (2:423/39)

Hello, Karel!

Friday August 08 2025 09:45, you wrote to me:

So, is calling your node with the binkp protocol considered
abuse? Or only if you see "failed" in the log?

Failed is the trigger.

Could you please cite any document where it is stated that a binkp session must not end with the status "failed"?
Otherwise, I will assume that my client is the greatest creation of mankind in the 21st century.

Best regards,
dp.

--- GoldED+/OSX 1.1.5-b20250409
* Origin: All is good in St. John's Wood (2:5001/100.1)

Hi Dmitry.

08 Aug 25 11:25:42, you wrote to Karel Kral:

Otherwise, I will assume that my client is the greatest creation of mankind in the 21st century.

Sure. :)

The one by Stas Mishchenkov can behave. ;)

=== Cut ===
08 Aug 11:46:10 [942639] incoming from 2001:470:79c5::24 (34842)
08 Aug 11:46:10 [1246931] incoming session with 2001:470:79c5::24
08 Aug 11:46:10 [1246931] SYS WTF
08 Aug 11:46:11 [1246931] ZYZ Sysop
08 Aug 11:46:11 [1246931] LOC Somewhere
08 Aug 11:46:11 [1246931] NDL PING
08 Aug 11:46:11 [1246931] TIME Fri 8 Aug 2025 11:46:10 0300
08 Aug 11:46:11 [1246931] VER Call_Robot/v.0.9.6.0/linux binkp/1.0
08 Aug 11:46:11 [1246931] addr: 2:22/9999@fidonet
08 Aug 11:46:11 [1246931] - our 2001:41d0:701:1100::942 360
08 Aug 11:46:11 [1246931] TRF 0 0
08 Aug 11:46:11 [1246931] Remote has 0b of mail and 0b of files for us
08 Aug 11:46:11 [1246931] done (from 2:22/9999@fidonet, OK, S/R: 0/0 (0/0 bytes))
08 Aug 11:46:11 [1246931] session closed, quitting...
08 Aug 11:46:11 [942639] rc(1246931)=0
08 Aug 11:46:11 [942639] incoming from 37.136.167.169 (38690)
08 Aug 11:46:11 [1246933] incoming session with 37.136.167.169
08 Aug 11:46:11 [1246933] SYS WTF
08 Aug 11:46:11 [1246933] ZYZ Sysop
08 Aug 11:46:11 [1246933] LOC Somewhere
08 Aug 11:46:11 [1246933] NDL PING
08 Aug 11:46:11 [1246933] TIME Fri 8 Aug 2025 11:46:10 0300
08 Aug 11:46:11 [1246933] VER Call_Robot/v.0.9.6.0/linux binkp/1.0
08 Aug 11:46:11 [1246933] addr: 2:22/9999@fidonet
08 Aug 11:46:11 [1246933] - our 51.38.115.207 360
08 Aug 11:46:11 [1246933] TRF 0 0
08 Aug 11:46:11 [1246933] Remote has 0b of mail and 0b of files for us
08 Aug 11:46:11 [1246933] done (from 2:22/9999@fidonet, OK, S/R: 0/0 (0/0 bytes))
08 Aug 11:46:11 [1246933] session closed, quitting...
08 Aug 11:46:11 [942639] rc(1246933)=0
=== Cut ===

'Tommi

---
* Origin: Point One (2:221/1.1)

Re: New results. Much better but still not perfect.
By: Dmitry Protasoff to Karel Kral on Fri Aug 08 2025 11:25 am

Howdy,

Could you please cite any document where it is stated that a binkp session must not end with the status "failed"?
Otherwise, I will assume that my client is the greatest creation of mankind in the 21st century.

You could problably send an EOB before your disconnected and then disconnect and the other side wouldnt then think it was a failed session?


...ëîåï
--- SBBSecho 3.27-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

Hello Dmitry!

08 Aug 25 11:25, you wrote to me:

Could you please cite any document where it is stated that a binkp
session must not end with the status "failed"? Otherwise, I will
assume that my client is the greatest creation of mankind in the 21st century.

Why somebody even could think that "failed" is good result?

Even more that one command above can do the job (like other wrote to you).

Karel

--- GoldED+/LNX 1.1.5-b20240209
* Origin: Plast DATA (2:423/39)

Hello Dmitry!

08 Aug 25 11:25, you wrote to me:

"failed"? Otherwise, I will assume that my client is
the greatest creation of mankind in the 21st century.

Idea: why not to put that behind zabbix/nagios?

acknowledgement, planned maintenance, all that modern things could be adopted.

To move from archive-nodelist to real and realistics overview of "actual status".

"Did not get echomail? Let us see... hm, my uplink has an incident, but he acknowledged fix time next week..."

Karel

--- GoldED+/LNX 1.1.5-b20240209
* Origin: Plast DATA (2:423/39)