Hello, Ward!

Wednesday August 06 2025 18:59, you wrote to me:

- momiabbs.no-ip.info: BINKP failed: BINKP handshake failed
- All tested protocols failed - no working connectivity

He's the spokesperson of the Argentinan president, has abandoned
Fidonet a longtime ago.

Overall, the situation with connectivity is pretty bad.



Best regards,
dp.

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

Hello Dmitry,

On Wednesday August 06 2025 20:11, you wrote to Ward Dossche:

He's the spokesperson of the Argentinan president, has abandoned
Fidonet a longtime ago.

So his node should be removed from the nodelist.

Overall, the situation with connectivity is pretty bad.

In the POTS age it probably wasn't much better. Maybe it was even worse. In the POTS age it was not doable to test every node in the nodelist for connectivity. For starters, it would have cost a fortune. It would also have taken much too long. A full scan would have taken over a week.

Nowadays it is a matter of minutes and the cost is zero. Scanning the nodelist every day is no problem. It is no longer possible to hide connectivity issues.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hello, Michiel!

Wednesday August 06 2025 22:06, you wrote to me:

Overall, the situation with connectivity is pretty bad.

In the POTS age it probably wasn't much better. Maybe it was even
worse. In the POTS age it was not doable to test every node in the nodelist for connectivity. For starters, it would have cost a fortune.
It would also have taken much too long. A full scan would have taken
over a week.

I have a plan to actualy DIAL (!) every node in the nodelist ;) It's not very expensive and probably many POTS nodes are dead anyway (?).
In Russia, we've got a really nice guy, 2:5020/8912, with a multiline POTS node who is dialing every node with a modem in Russia to check if they're still alive :)

Nowadays it is a matter of minutes and the cost is zero. Scanning the nodelist every day is no problem. It is no longer possible to hide connectivity issues.

This test will be integrated into my server software, but right now, it's just a mess of python code, too terrible to share :(
After that, I'll write an article for Fidonews ;)

I'm doing night shifts with our baby girl 3 nights a week because she's going through a sleep regression right now. While I'm not ready for any serious work after 10pm,
my brain still has enough resources to write some simple code and AI is ready to help with things I'm too lazy to study myself ;)

Best regards,
dp.

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

Hello Michiel!

06 Aug 25 22:06, you wrote to Dmitry Protasoff:

Overall, the situation with connectivity is pretty bad.

In the POTS age it probably wasn't much better. Maybe it was even
worse. In the POTS age it was not doable to test every node in the nodelist for connectivity. For starters, it would have cost a fortune.
It would also have taken much too long. A full scan would have taken
over a week.

Did do that for the ABNlist .. (Checking the Dutch BBS Lists)
In NL we did check monthly the status of those in the list.
I have done it alone but also sometimes with the help of.. And yes it was costing ...

Nowadays it is a matter of minutes and the cost is zero. Scanning the nodelist every day is no problem. It is no longer possible to hide connectivity issues.

Yep ..


Dennis


... Security through obscurity works... until it doesn't.
--- GoldED+/LNX 1.1.5-b20250408
* Origin: ---- BOFH: Problem solved, user deleted. (2:280/2060)

Hello Dmitry!

06 Aug 25 18:50, you wrote to me:

"success": true,
"response_time_ms": 55,

Interesting. I see you as failed.

+ 05 Aug 14:25:52 [107202] done (from 2:5001/5001@fidonet, failed, S/R: 0/0 (0/0 bytes))

Why so?

Karel

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

Hello, Karel!

Thursday August 07 2025 09:06, you wrote to me:

"success": true,
"response_time_ms": 55,

Interesting. I see you as failed.

+ 05 Aug 14:25:52 [107202] done (from 2:5001/5001@fidonet, failed,
S/R: 0/0 (0/0 bytes))

Why so?

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.

Best regards,
dp.

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

Hello Dmitry,

On Thursday August 07 2025 00:54, you wrote to me:

In the POTS age it probably wasn't much better. Maybe it was even
worse. In the POTS age it was not doable to test every node in
the nodelist for connectivity. For starters, it would have cost a
fortune. It would also have taken much too long. A full scan
would have taken over a week.

I have a plan to actualy DIAL (!) every node in the nodelist ;) It's
not very expensive and probably many POTS nodes are dead anyway

In the high times of Fidonet with 30.000+ nodes and very expensive international calls, it was definitely not doable. Even calling just one's own region was very expensive.

Nowadays with VOIP it is a different storie.

(?). In Russia, we've got a really nice guy, 2:5020/8912, with a
multiline POTS node who is dialing every node with a modem in Russia
to check if they're still alive :)

And what are the results? How many POTS nodes still alive? How many dead?

BTW, one must be carefull with such things. The number may have expired and be given to some old lady the you will keep out of sleep.

BTW2 Here in The Greater Netherlands Fido over POTS is definitely gone. Has been for a decade.

Nowadays it is a matter of minutes and the cost is zero. Scanning
the nodelist every day is no problem. It is no longer possible to
hide connectivity issues.

This test will be integrated into my server software, but right now,
it's just a mess of python code, too terrible to share :( After that,
I'll write an article for Fidonews ;)

Looking forward to it...

I'm doing night shifts with our baby girl 3 nights a week because
she's going through a sleep regression right now.

Oh boy! ;-)


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Dmitry,

Overall, the situation with connectivity is pretty bad.

I do not doubt that. Long gone are the times when this could be handled via the *C-chain.

\%/@rd

--- DB4 - 20230201
* Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)

Michiel,

Nowadays it is a matter of minutes and the cost is zero. Scanning the nodelist every day is no problem. It is no longer possible to hide connectivity issues.

I fully know I will regret having said this, but we can still ignore it.

\%/@rd

--- DB4 - 20230201
* Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)

Hello, Michiel!

Thursday August 07 2025 14:52, you wrote to me:

I have a plan to actualy DIAL (!) every node in the nodelist ;)
It's not very expensive and probably many POTS nodes are dead
anyway

In the high times of Fidonet with 30.000+ nodes and very expensive international calls, it was definitely not doable. Even calling just
one's own region was very expensive.

Nowadays with VOIP it is a different storie.

We are living in wonderful times ;)

(?). In Russia, we've got a really nice guy, 2:5020/8912, with a
multiline POTS node who is dialing every node with a modem in
Russia to check if they're still alive :)

And what are the results? How many POTS nodes still alive? How many
dead?

Since he started this process, a lot of information has been corrected in the nodelist.

BTW, one must be carefull with such things. The number may have
expired and be given to some old lady the you will keep out of sleep.

ZMH is in Russia during office hours. That was a big problem back in the XXth century.
So lady probably already feeding the pigeons on the street ;)

Best regards,
dp.

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

Hello Dmitry!

07 Aug 25 13:15, 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 am alone with that opinion a majority agrees on acceptance that "testing".

If not, I put fail2ban back on that.

Karel

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

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)