binkd unexpectedly closes the connection

[wvvelzen]

First a little background: Since a couple of months my Fido system generates a file with the same name 3 or 4 times a day, and hatches this file to my point system. So when my point doesn't poll for a couple of days, there are multiple lines in the .flo file for the same file. Since this is the case it seems to trigger a possible bug in binkp connections.

Here's the log where it's happening on the system side (I'm leaving out some lines which I think are not relevant):

+ 24 Mar 08:22:24 [2751] incoming session with ***
- 24 Mar 08:22:24 [2751] SYS Wilfreds Point System

- 24 Mar 08:22:24 [2751] TIME Mon, 24 Mar 2025 08:22:29 +0100
- 24 Mar 08:22:24 [2751] VER binkd/1.1a-113/Win64 binkp/1.1

- 24 Mar 08:22:24 [2751] OPT NDA EXTCMD CRYPT GZ BZ2
+ 24 Mar 08:22:24 [2751] Remote supports asymmetric ND mode
+ 24 Mar 08:22:24 [2751] Remote supports EXTCMD mode
+ 24 Mar 08:22:24 [2751] Remote requests CRYPT mode
+ 24 Mar 08:22:24 [2751] Remote supports GZ mode
+ 24 Mar 08:22:24 [2751] Remote supports BZ2 mode
- 24 Mar 08:22:24 [2751] TRF 0 0
+ 24 Mar 08:22:24 [2751] Remote has 0b of mail and 0b of files for us
+ 24 Mar 08:22:24 [2751] pwd protected session (MD5)
- 24 Mar 08:22:24 [2751] session in CRYPT mode

+ 24 Mar 08:22:25 [2751] sending /home/fido/fileareas/zadaily/zadaily.081 as zadaily.081 (118379)
  24 Mar 08:22:25 [2751] bzip2 mode is on for zadaily.081
+ 24 Mar 08:22:25 [2751] remote already has zadaily.081
+ 24 Mar 08:22:25 [2751] sending /home/fido/tic/nb20u8l8.tic as nb20u8l8.tic (436)
+ 24 Mar 08:22:25 [2751] sent: /home/fido/tic/nb1z3an8.tic (436, 436.00 CPS, 2:280/464.112@fidonet)
  24 Mar 08:22:25 [2751] Compressed 100788 bytes to 29470 for nb20u8l8.tic, ratio 29.2%

Here's the first odd thing: It reports compressing a file, that was much smaller: 436 bytes, then it reports, that wouldn't get compressed because of it's size anyway. And there isn't a "bzip mode is on" line for it anyway.

+ 24 Mar 08:22:25 [2751] sending /home/fido/fileareas/zadaily/zadaily.082 as zadaily.082 (118394)
  24 Mar 08:22:25 [2751] bzip2 mode is on for zadaily.082

  24 Mar 08:22:26 [2751] Compressed 118394 bytes to 34714 for zadaily.082, ratio 29.3%
+ 24 Mar 08:22:26 [2751] sending /home/fido/tic/nb20xey8.tic as nb20xey8.tic (436)

+ 24 Mar 08:22:26 [2751] sending /home/fido/tic/nb20xkt9.tic as nb20xkt9.tic (902)
+ 24 Mar 08:22:26 [2751] sending /home/fido/fileareas/zadaily/zadaily.082 as zadaily.082 (118394)
  24 Mar 08:22:26 [2751] bzip2 mode is on for zadaily.082

+ 24 Mar 08:22:26 [2751] sent: /home/fido/fileareas/zadaily/zadaily.081 (118379, 118379.00 CPS, 2:280/464.112@fidonet)
? 24 Mar 08:22:26 [2751] recv: Connection reset by peer
+ 24 Mar 08:22:26 [2751] done (from 2:280/464.112@fidonet, failed, S/R: 34/0 (989324/0 bytes))
  24 Mar 08:22:26 [2751] Purge compress buffers
  24 Mar 08:22:26 [2751] session closed, quitting...

And there is the unexpected close of the connection.

And some lines from the log of the same session from the point system:

  24 Mar 08:22:29 [8724] BEGIN standalone, binkd/1.1a-113/Win64 -pP 2:280/464 \com\binkd\binkd.cfg
...
- 24 Mar 08:22:32 [10912] receiving zadaily.081 (118379 byte(s), off 0)
  24 Mar 08:22:32 [10912] bzip2 mode is on for zadaily.081
  24 Mar 08:22:32 [10912] File zadaily.081 compressed size 34725 bytes, compress ratio 29.3%
+ 24 Mar 08:22:32 [10912] zadaily.081 -> c:\com\inbound\zadaily.081
+ 24 Mar 08:22:32 [10912] rcvd: zadaily.081 (118379, 118379.00 CPS, 2:280/464@fidonet)
+ 24 Mar 08:22:32 [10912] already have zadaily.081 (c:\com\inbound\zadaily.081, 118379 byte(s))
- 24 Mar 08:22:32 [10912] receiving nb20u8l8.tic (436 byte(s), off 0)
? 24 Mar 08:22:32 [10912] rcvd 3660 extra bytes!
+ 24 Mar 08:22:32 [10912] done (to 2:280/464@fidonet, failed, S/R: 0/34 (0/989324 bytes))
  24 Mar 08:22:32 [10912] restoring poll with `d' flavour
? 24 Mar 08:22:32 [10912] receiving of nb20u8l8.tic interrupted at 4096
  24 Mar 08:22:32 [10912] session closed, quitting...

So this reproduces. I can probably create, if needed, a data set (upload files, and .flo file) that reproduces it every time...

[CkNoSFeRaTU]

This was reported in RU.BINKD back in the 2018 but was never fixed.
I'm using the following patches on my node. The 0005_stop_compression_after_skips.patch one is for mentioned issue.

[wvvelzen]

My browser complains about the links you gave. The https certificates are for ns1.ganjanetwork.ru not for fido.g0x.ru !? :-(

Why not create a pull request for them here?

[CkNoSFeRaTU]

My browser complains about the links you gave. The https certificates are for ns1.ganjanetwork.ru not for fido.g0x.ru !? :-(

IDK what your browser is but this can only happen if your browser doesn't send SNI and it is pretty mandatory for over 20 years already... Are you using some paranoid privacy settings like SNI disallow/ECH-only? Because I doubt there are any browser left which supports modern TLS versions but doesn't support SNI extension nowadays...

Why not create a pull request for them here?

I don't see much point in that. Last PR took 1,5 years of silence to be merged. Any binkd development is pretty much ceased in 2020 and also @pgul seems no longer active in fidonet either.

P.S. You can reach me via netmail at 2:5019/40@fidonet if you still have troubles accessing patches or have other related questions.

[wvvelzen]

My browser complains about the links you gave. The https certificates are for ns1.ganjanetwork.ru not for fido.g0x.ru !? :-(

IDK what your browser is but this can only happen if your browser doesn't send SNI and it is pretty mandatory for over 20 years already... Are you using some paranoid privacy settings like SNI disallow/ECH-only? Because I doubt there are any browser left which supports modern TLS versions but doesn't support SNI extension nowadays...

I'm not a certificate/TLS expert, so I don't know what this all means. I'm using Firefox 134, which was released this year, and I'm not aware I changed any security settings

Why not create a pull request for them here?

I don't see much point in that. Last PR took 1,5 years of silence to be merged. Any binkd development is pretty much ceased in 2020 and also @pgul seems no longer active in fidonet either.

Then create a fork and start your own release...

P.S. You can reach me via netmail at 2:5019/40@fidonet if you still have troubles accessing patches or have other related questions.

I could ignore the security warning in Firefox if I choose to, but I didn't. ;-)

[CkNoSFeRaTU]

I'm not a certificate/TLS expert, so I don't know what this all means.

If you are interested then I can explain. Single IP-address could serve multiple sites with different domains and single certificates for multiple domains aren't generally a norm. So back in SSL days mechanism was devised where client browser in the first packet to server (named Client Hello) will announce to which domain it wants to connect. It was done with optional SNI (Server Name Identification) extension which with time became pretty much mandatory to modern internet due to convinience and IPv4-address space exhaution. This extension just inserts field which contains desired by client domain name in plain-text in this packet. Server than receive that information and sends correct certificate which corresponds to the requested domain. If that information is absent than the server can't do anything aside from terminating connection or sending pre-configured default ceritificate. And that certificate usually valid only for one domain as server isn't psychic and couldn't otherwise know to which domain you want to connect during encryption handshake stage.

Also for a couple of last years there are efforts to migrate to ECH (Encrypted Client Hello) so in-transit systems couldn't eavesdrop such plain-text information and e.g. implement censorship. But aside from big CDN services like Cloudflare it is not very widespread as most of software still doesn't support it, including core cryptography libraries like openssl.

I'm using Firefox 134, which was released this year, and I'm not aware I changed any security settings

If you are specifically aren't going out of your way to disable SNI than I don't know why it isn't working for you. This site is working for ~20 years already and you are the first with this problem. :-) Nothing I can do from my end. I even did ssllabs test and all seems to be in order (you can click there on any ip-address and see the report yourself).

Then create a fork and start your own release...

Don't want to maintain my own fork either as I'm not really interested in developing binkd. I've just fixed some issues I encountered myself over the last years. Like small compiling fixes for modern compiler versions, crashes on config reloads and a couple of annoying protocol implementation bugs.

I could ignore the security warning in Firefox if I choose to, but I didn't. ;-)

Well, here is that patch:

0005_stop_compression_after_skips.patch

diff --git a/protocol.c b/protocol.c
index 677cb44..ce070db 100644
--- a/protocol.c
+++ b/protocol.c
@@ -2369,6 +2369,7 @@ static int SKIP (STATE *state, char *args, int sz, BINKD_CONFIG *config)
         return 0;
       }
       Log (2, "%s skipped by remote", state->out.netname);
+      z_send_stop(state);
       TF_ZERO (&state->out);
     }
     ND_set_status("", &state->ND_addr, state, config);
@@ -2418,6 +2419,7 @@ static int GOT (STATE *state, char *args, int sz, BINKD_CONFIG *config)
     if (!tfile_cmp (&state->out, argv[0], fsize, ftime))
     {
       Log (2, "remote already has %s", state->out.netname);
+      z_send_stop(state);
       if (state->out.f)
       {
         fclose (state->out.f);