Hello, All!

I was really encouraged by the "Dutch team" to improve my little testing script and to my fear, I realized that once I stepped onto the road covered with yellow bricks, I have to follow it to the end.

As I've found that it makes no sense to trust the information from the nodelist, it became clear to me that I have to test whether the nodes are actually responding on their advertised hostnames and IP addresses before making any assumptions about where they are actually located.

So, I've implemented a very simple BinkP and ifcico protocol tester in Python, rewrote the script and now I have the following results:

PS. The numbers are still not perfect! Beware of bugs!
Please do not shoot the pianist. He is doing his best.
The output is still full of my internal debug data.

============================================================
FidoNet Node IP Geolocation Analysis Report ============================================================

SUMMARY STATISTICS
----------------------------------------
Total nodes analyzed: 1002
Nodes with IP connectivity: 925 (92.3%)

NOTE: The following statistics are based on nodelist data and DNS lookups,
not actual connectivity tests. See 'Protocol Connectivity Summary' below
for operational node statistics from actual connection tests.

IP Version Distribution (from nodelist + DNS):
IPv4 only: 704 (70.3%)
IPv6 only: 3 (0.3%)
Dual stack: 218 (21.8%)

DNS Resolution:
Nodes with hostnames: 945
Successful IPv4 resolutions: 881
Failed IPv4 resolutions: 83
Successful IPv6 resolutions: 223
Failed IPv6 resolutions: 741

Protocol Connectivity Summary:
BINKP: 668 operational nodes
IPv4 only: 488 (73.1%)
IPv6 only: 2 (0.3%)
Dual stack: 178 (26.6%)
IFCICO: 67 operational nodes
IPv4 only: 46 (68.7%)
Dual stack: 21 (31.3%)
FTP: 33 operational nodes
IPv4 only: 25 (75.8%)
Dual stack: 8 (24.2%)
VMODEM: 12 operational nodes
IPv4 only: 11 (91.7%)
Dual stack: 1 (8.3%)
TELNET: 52 operational nodes
IPv4 only: 42 (80.8%)
Dual stack: 10 (19.2%)

BINKP Connectivity:
Nodes tested: 910
Operational nodes: 668
Operational rate: 73.4%

IFCICO Connectivity:
Nodes tested: 95
Operational nodes: 67
Operational rate: 70.5%

FTP Connectivity:
Nodes tested: 49
Operational nodes: 33
Operational rate: 67.3%

VMODEM Connectivity:
Nodes tested: 18
Operational nodes: 12
Operational rate: 66.7%

TELNET Connectivity:
Nodes tested: 138
Operational nodes: 52
Operational rate: 37.7%

IP Address Classification:
public: 945 (Public IP (accessible from internet))
reserved: 2 (Reserved IP (RFC 6598 CGN, special use - not publicly routable))

Geographic Distribution (Top 15 Countries):
RU: 262 nodes (26.1%) - Russia
US: 257 nodes (25.6%) - United States
DE: 76 nodes (7.6%) - Germany
CA: 50 nodes (5.0%) - Canada
NL: 28 nodes (2.8%) - The Netherlands
UA: 28 nodes (2.8%) - Ukraine
GB: 26 nodes (2.6%) - United Kingdom
SE: 15 nodes (1.5%) - Sweden
CZ: 15 nodes (1.5%) - Czechia
FI: 14 nodes (1.4%) - Finland
BE: 14 nodes (1.4%) - Belgium
IT: 13 nodes (1.3%) - Italy
AU: 13 nodes (1.3%) - Australia
NZ: 13 nodes (1.3%) - New Zealand
AT: 11 nodes (1.1%) - Austria

Top Hosting Providers:
Spectrum: 39 nodes (4.2%)
Deutsche Telekom Ag: 26 nodes (2.8%)
OVH: 22 nodes (2.4%)
Verizon Business: 18 nodes (1.9%)
Hetzner: 15 nodes (1.6%)
Comcast Cable Communications Holdings, Inc: 13 nodes (1.4%)
Byfly Mogilev Static: 12 nodes (1.3%)
Comcast Cable Communications, Llc: 11 nodes (1.2%)
Mci Communications Services, Inc. D/b/a Verizon Business: 9 nodes (1.0%)
DigitalOcean: 9 nodes (1.0%)

Top Autonomous Systems (ASN):
AS7922 Comcast Cable Communications, LLC: 47 nodes (5.1%)
AS701 Verizon Business: 29 nodes (3.1%)
AS3320 Deutsche Telekom AG: 26 nodes (2.8%)
AS12389 PJSC Rostelecom: 26 nodes (2.8%)
AS16276 OVH SAS: 25 nodes (2.7%)
AS7018 AT&T Enterprises, LLC: 19 nodes (2.1%)
AS3209 Vodafone GmbH: 17 nodes (1.8%)
AS24940 Hetzner Online GmbH: 16 nodes (1.7%)
AS14061 DigitalOcean, LLC: 15 nodes (1.6%)
AS6697 Republican Unitary Telecommunication Enterprise Beltelecom: 14 nodes (1.5%)

Nodes with IPs in Multiple Countries: 3
2:280/5555 (Nieuw_Schnoord): NL, DE
2:5020/113 (Minas_Anor): US, RU
2:5080/102 (Grumbler): GB, RU

ACTUAL PROTOCOL CONNECTIVITY RESULTS =============================================
Based on actual connection tests to operational nodes

Node Reachability Analysis:
Total nodes with internet connectivity: 1002
Fully operational: 604 (60.3% of all internet nodes) - working on ALL advertised protocols
Partially operational: 80 (8.0% of all internet nodes) - working on SOME advertised protocols
Non-operational: 309 (30.8% of all internet nodes) - no working protocols
No protocol flags: 9 (0.9% of all internet nodes) - no testable protocols advertised

Protocol Summary:
BINKP: 668/978 operational (68.3% success rate)
IFCICO: 67/100 operational (67.0% success rate)
FTP: 33/52 operational (63.5% success rate)
VMODEM: 12/21 operational (57.1% success rate)
TELNET: 52/144 operational (36.1% success rate)

IP Version Distribution (operational nodes only):
IPv4 only: 612 (73.6%)
IPv6 only: 2 (0.2%)
Dual stack: 218 (26.2%)


Best regards,
dp.

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

Hello Dmitry!

06 Aug 25 02:20, you wrote to All:

How did you test? I mean I see no record in log.

BINKP Connectivity:
Nodes tested: 910
Operational nodes: 668
Operational rate: 73.4%

In different words: what we can expect and how often?

Karel

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

Hello Dmitry,

On Wednesday August 06 2025 02:20, you wrote to All:

So, I've implemented a very simple BinkP and ifcico protocol tester in Python, rewrote the script and now I have the following results:

Is this you testing?

17:28 [2576] incoming from 2603:c020:c00f:4d7e:568b:b18b:254d:7497 (55586)
17:28 [2936] incoming session with 2603:c020:c00f:4d7e:568b:b18b:254d:7497
17:28 [2936] VER NodelistDB-BinkpClient/1.0 binkp/1.0
17:28 [2936] SYS NodelistDB Analytics
17:28 [2936] TIME Wed, 06 Aug 2025 15:28:14 +0000
17:28 [2936] addr: 2:5001/5001@fidonet
17:28 [2936] recv: connection closed by foreign host
17:28 [2936] done (from 2:5001/5001@fidonet, failed, S/R: 0/0 (0/0 bytes))
17:28 [2936] session closed, quitting...



Cheers, Michiel

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

Hello, Karel!

Wednesday August 06 2025 09:15, you wrote to me:

How did you test? I mean I see no record in log.

Searching for: 2:423/39

=== FOUND 2 ENTRIES ===

BINKP Cache:
Key: 2a13:7c81:f2:0:f1d0:2:423:39
Timestamp: 2025-08-05 22:19:50
Expected FidoNet Address: 2:423/39
Node Address: 2:423/39@fidonet 42:42/39@paranoidnet
Presented Addresses: 2:423/39, 42:42/39@paranoidnet
Full Data: {
"success": true,
"response_time_ms": 55,
"banner": null,
"error": null,
"port": 24554,
"node_address": "2:423/39@fidonet 42:42/39@paranoidnet",
"node_addresses": [
"2:423/39",
"42:42/39@paranoidnet"
],
"system_name": "Plast DATA",
"location": "Tachov, Czech Republic",
"sysop_name": "Karel Kral",
"version": "binkd/1.1a-115/Linux binkp/1.1",
"time": "Wed, 6 Aug 2025 00:15:07 +0200",
"capabilities": [
"CRAM-MD5-8e6f1e74c53072cac12d1707b4aeafee",
"NDL:115200,TCP,BINKP"
],
"expected_address": "2:423/39",
"address_validated": true,
"validation_error": null,
"ipv6_tested": true,
"ipv6_available": true,
"ipv4_fallback_used": false
}

BINKP Cache:
Key: 206.168.213.251
Timestamp: 2025-08-05 22:46:50
Expected FidoNet Address: 2:423/39
Node Address: 2:423/39@fidonet 42:42/39@paranoidnet
Presented Addresses: 2:423/39, 42:42/39@paranoidnet
Full Data: {
"success": true,
"response_time_ms": 56,
"banner": null,
"error": null,
"port": 24554,
"node_address": "2:423/39@fidonet 42:42/39@paranoidnet",
"node_addresses": [
"2:423/39",
"42:42/39@paranoidnet"
],
"system_name": "Plast DATA",
"location": "Tachov, Czech Republic",
"sysop_name": "Karel Kral",
"version": "binkd/1.1a-115/Linux binkp/1.1",
"time": "Wed, 6 Aug 2025 00:44:54 +0200",
"capabilities": [
"CRAM-MD5-4c6b94c1aab70bc767c529a192517bee",
"NDL:115200,TCP,BINKP"
],
"expected_address": "2:423/39",
"address_validated": true,
"validation_error": null,
"ipv6_tested": false,
"ipv6_available": null,
"ipv4_fallback_used": false
}

BINKP Connectivity:
Nodes tested: 910
Operational nodes: 668
Operational rate: 73.4%

In different words: what we can expect and how often?

I am thinking about integrating this check into https://nodelist.fidonet.cc/ and launching it weekly.

Best regards,
dp.

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

Hello, Michiel!

Wednesday August 06 2025 17:32, you wrote to me:

So, I've implemented a very simple BinkP and ifcico protocol
tester in Python, rewrote the script and now I have the following
results:

Is this you testing?

17:28 [2576] incoming from 2603:c020:c00f:4d7e:568b:b18b:254d:7497 (55586) 17:28 [2936] incoming session with 2603:c020:c00f:4d7e:568b:b18b:254d:7497 17:28 [2936] VER NodelistDB-BinkpClient/1.0 binkp/1.0 17:28 [2936] SYS NodelistDB
Analytics 17:28 [2936] TIME Wed, 06 Aug 2025 15:28:14 +0000 17:28
[2936] addr: 2:5001/5001@fidonet 17:28 [2936] recv: connection closed
by foreign host 17:28 [2936] done (from 2:5001/5001@fidonet, failed,
S/R: 0/0 (0/0 bytes)) 17:28 [2936] session closed, quitting...

Yes!

Also created very long report (131 kb):

FidoNet Nodes with Connectivity Problems =============================================
Generated: 2025-08-06 15:37:50
Total problem nodes: 382

Problem Categories:
DNS resolution problems only: 74
Protocol connectivity problems only: 297
Configuration problems only: 4
Multiple problem types: 6

Node: 1:1/110
System: Seans_Elist_Maintainer
Sysop: Sean_Dennis
Location: Johnson_City_TN_USA
Hostnames: bbs.outpostbbs.net
Protocols: INA, IBN, IFC, IFT, ITN
Flags: XX, PING, TRACE
Problems:
- bbs.outpostbbs.net: IFCICO failed: Connection timeout
- bbs.outpostbbs.net: TELNET failed: Connection timeout

Node: 1:13/2
System: Election_Coodinator
Sysop: Robert_Wolfe
Location: Buffalo_NY
Hostnames: wc4.winserver.org
Protocols: INA, IBN, IFT
Flags: CM
Problems:
- DNS resolution failed for hostname 'wc4.winserver.org' - no IPv4 or IPv6 address found
- All 1 hostname(s) failed DNS resolution - node completely unreachable via hostnames
- Node is completely unreachable - relies only on hostnames and all DNS resolutions failed
- Has protocol flags (IBN, IFT) but protocols not tested due to DNS resolution failures

....
....
....
Node: 4:902/27
System: Momia_BBS
Sysop: Manuel_Adorni
Location: La_Plata_BA
Hostnames: momiabbs.no-ip.info
Protocols: IBN
Flags: CM, XA
Problems:
- momiabbs.no-ip.info: BINKP failed: BINKP handshake failed
- All tested protocols failed - no working connectivity

Enhanced Diagnostics
====================
IPv6-related issues: 114
Timeout issues: 140
Banner issues: 0
Validation issues: 0




Best regards,
dp.

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

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

\%/@rd

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

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)