Заливка сегмента нодлиста

Alexey Fayans написал(а) к Dmitriy Romanov в Oct 24 22:34:13 по местному времени:

Нello Dmitriy!

On Wed, 09 Oct 2024 21:07 +0200, you wrote to me:

AF>> Только в binkp хендшейк начинает отвечающая сторона, сразу
AF>> предъявляя все ака, что крайне тупо, но так уж сделали.
DR> А тут уже от реализации зависит.

В спецификации binkp написано, что вызываемая сторона должна начать хендшейк. Поэтму любой софт, реализующий протокол binkp, будет работать именно так и никак иначе. Если кто-то сделает по-другому, то ни один стандартный клиент не будет с такой реализцией работать.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707

Dmitriy Romanov написал(а) к Alexey Fayans в Oct 24 07:42:28 по местному времени:

Приветики, Alexey!


Писал как-то Alexey Fayans к Dmitriy Romanov примерно 09 Окт 24 в 22:34
А я смотрю и фигею.


AF>>> Только в binkp хендшейк начинает отвечающая сторона, сразу
AF>>> предъявляя все ака, что крайне тупо, но так уж сделали.
DR>> А тут уже от реализации зависит.

AF> В спецификации binkp написано, что вызываемая сторона должна начать
AF> хендшейк. Поэтму любой софт, реализующий протокол binkp, будет работать
AF> именно так и никак иначе. Если кто-то сделает по-другому, то ни один
AF> стандартный клиент не будет с такой реализцией работать.
классический binkd не дожидается, пока вызывающий представится. Можешь проверить экспериментально, подцепившись
телнетом на соответствующий порт большинства узлов.

На сем разрешите письмо закончить. Elec (RA2FDR)
--- NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603

Dmitriy Romanov написал(а) к Alexey Fayans в Oct 24 07:45:14 по местному времени:

Приветики, Alexey!


Писал как-то Alexey Fayans к Vladislav Muschinskikh примерно 09 Окт 24 в 22:09
А я смотрю и фигею.


AK>>>> аналогично сделано и в binkp - вызывающий предьявляет свои АКА и
AK>>>> параметры, вызываемый отдает свои на основании принятых.
AF>>> Только в binkp хендшейк начинает отвечающая сторона, сразу
AF>>> предъявляя все ака, что крайне тупо, но так уж сделали.
VM>> А почему тогда возникает ситуация, когда вызывающая сторона получает
VM>> от вызываемой сообщения о том что такой-то ака на удалённой системе
VM>> busy or not available? (я не настоящий сварщик, просто интересно)
AF> Это нужно в исходники смотреть, я не задавался таким вопросом.
А какая разница вызывающей стороне? Если предъявленный основной адрес busy, то сессия не состоится. Если один из AKA -
то принимающая сторона просто исключает его из обработки и ведет себя так, как будто этот ака не предъявлен.

На сем разрешите письмо закончить. Elec (RA2FDR)
--- NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603

Alexey Fayans написал(а) к Dmitriy Romanov в Oct 24 09:14:09 по местному времени:

Нello Dmitriy!

On Thu, 10 Oct 2024 07:42 +0200, you wrote to me:

AF>> В спецификации binkp написано, что вызываемая сторона должна
AF>> начать хендшейк. Поэтму любой софт, реализующий протокол binkp,
AF>> будет работать именно так и никак иначе. Если кто-то сделает
AF>> по-другому, то ни один стандартный клиент не будет с такой
AF>> реализцией работать.
DR> классический binkd не дожидается, пока вызывающий представится.

Я именно об этом и пишу. Потому что в классическом (и единственном) binkp представляется ВЫЗЫВАЕМВЫЙ, а не вызывающий. И пока вызываемый не представится (не начнёт хендшейк), сессия не начнётся.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707

Dmitriy Romanov написал(а) к Alexey Fayans в Oct 24 19:45:16 по местному времени:

Приветики, Alexey!


Писал как-то Alexey Fayans к Dmitriy Romanov примерно 10 Окт 24 в 09:14
А я смотрю и фигею.


AF>>> В спецификации binkp написано, что вызываемая сторона должна
AF>>> начать хендшейк. Поэтму любой софт, реализующий протокол binkp,
AF>>> будет работать именно так и никак иначе. Если кто-то сделает
AF>>> по-другому, то ни один стандартный клиент не будет с такой
AF>>> реализцией работать.
DR>> классический binkd не дожидается, пока вызывающий представится.

AF> Я именно об этом и пишу. Потому что в классическом (и единственном) binkp
AF> представляется ВЫЗЫВАЕМВЫЙ, а не вызывающий. И пока вызываемый не
AF> представится (не начнёт хендшейк), сессия не начнётся.
Это не везде так. Мне среди линков встречались и другие мейлеры, которые вели себя по-другому. Они не представлялись
первыми на входящей сессии, а ждали, когда представится вызыывающий.

На сем разрешите письмо закончить. Elec (RA2FDR)
--- NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603

Alexey Khromov написал(а) к Dmitriy Romanov в Oct 24 21:24:27 по местному времени:

Здраствуйте, Dmitriy!

10 окт 24 19:45, Dmitriy Romanov -> Alexey Fayans:

AF>>>> В спецификации binkp написано, что вызываемая сторона должна
AF>>>> начать хендшейк. Поэтму любой софт, реализующий протокол binkp,
AF>>>> будет работать именно так и никак иначе. Если кто-то сделает
AF>>>> по-другому, то ни один стандартный клиент не будет с такой
AF>>>> реализцией работать.
DR>>> классический binkd не дожидается, пока вызывающий представится.

AF>> Я именно об этом и пишу. Потому что в классическом (и
AF>> единственном) binkp представляется ВЫЗЫВАЕМВЫЙ, а не вызывающий.
AF>> И пока вызываемый не представится (не начнёт хендшейк), сессия не
AF>> начнётся.

DR> Это не везде так. Мне среди линков встречались и другие мейлеры,
DR> которые вели себя по-другому. Они не представлялись первыми на
DR> входящей сессии, а ждали, когда представится вызыывающий.

Посмотрел логи bforce - фаза 0: MD5-челендж, фаза 1: обмен заголовками, заканчивается у обоих (и вызывающего, и вызываемого) посылкой своего AKA, фаза 3: проверка пароля сессии. Технически несложно дождаться АКА вызывающего, чтобы собрать свой АКА и это, как я правильно понял, вполне соответствует спецификации. Важно не кто что начинает (без MD5-челенджа не будет и обмена NUL,SYS,ZYZ и ADR).

Alexey Khromov
--- GoldED+/LNX 1.1.5-b20240309

Alexey Fayans написал(а) к Dmitriy Romanov в Oct 24 12:22:53 по местному времени:

Нello Dmitriy!

On Thu, 10 Oct 2024 19:45 +0200, you wrote to me:

AF>> Я именно об этом и пишу. Потому что в классическом (и
AF>> единственном) binkp представляется ВЫЗЫВАЕМВЫЙ, а не вызывающий.
AF>> И пока вызываемый не представится (не начнёт хендшейк), сессия не
AF>> начнётся.
DR> Это не везде так. Мне среди линков встречались и другие мейлеры,
DR> которые вели себя по-другому. Они не представлялись первыми на
DR> входящей сессии, а ждали, когда представится вызыывающий.

Значит это были не binkp мейлеры.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707

Alexey Fayans написал(а) к Alexey Khromov в Oct 24 12:51:01 по местному времени:

Нello Alexey!

On Thu, 10 Oct 2024 21:24 +0300, you wrote to Dmitriy Romanov:

AK> Посмотрел логи bforce - фаза 0: MD5-челендж, фаза 1: обмен
AK> заголовками, заканчивается у обоих (и вызывающего, и вызываемого)
AK> посылкой своего AKA, фаза 3: проверка пароля сессии. Технически
AK> несложно дождаться АКА вызывающего, чтобы собрать свой АКА и это, как
AK> я правильно понял, вполне соответствует спецификации.

Не знаю, что там bforce пишет в логи, но по факту вот что твой bforce выдал сразу после того, как я к нему подключился телнетом и ничего не отправил:

=== Start of Windows Clipboard ===
$ telnet fido.zxalexis.ru 24554
Trying 176.125.138.4...
Connected to fido.zxalexis.ru.
Escape character is '^]'.
▒"OPT CRAM-MD5-13c8032144ece6f30867▒SYS Vyborg Station▒ZYZ Alexey Khromov▒
LOC Vyborg▒PНN 7-813-787-68-72▒0NDL V34,MO,TUD,ICM,IBN,IFC,INA:fido.zxalexis.ru▒TIME 2024/10/11 12:46:14▒,VER binkleyforce/0.25.3/linux-gnu binkp/1.1▒2:5030/723@fidonet^]
telnet> quit
Connection closed.
=== End of Windows Clipboard ===

В этой простыне в том числе и твой адрес. Были бы прописаны ака - тоже были бы предъявлены сразу.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707

Alexey Khromov написал(а) к Alexey Fayans в Oct 24 14:12:07 по местному времени:

Здраствуйте, Alexey!

11 окт 24 12:51, Alexey Fayans -> Alexey Khromov:

AF> выдал сразу после того, как я к нему подключился телнетом и ничего не
AF> отправил:
AF> В этой простыне в том числе и твой адрес. Были бы прописаны ака - тоже
AF> были бы предъявлены сразу.

Именно. Читаем стандарт binkp1.0 и пропозал binkp1.1 :

======================================================
http://ftsc.org/docs/fts-1026.001

Binkp uses only one synchronization point during session startup,
that is password exchange.

Session setup stage: MADR (MUST be sent by both sides), MPWD
(MUST NOT be sent by the Answering side), M_OK (MUST NOT be sent
by the Originating side).
These commands MUST NOT be sent during the file transfer stage.

+----------------------------------------------------------------+
| Originating side | Answering side |
|--------------------------------+-------------------------------|
| MNUL "SYS ..." | MNUL "SYS ..." |
| MNUL "ZYZ ..." | MNUL "ZYZ ..." |
| MNUL "LOC ..." | MNUL "LOC ..." |
| MNUL "VER ..." | MNUL "VER ..." |
| MNUL "OPT ..." | MNUL "OPT ..." |
| MADR "1:1/1.1@fidonet" | MADR "2:2/2.2@fidonet" |
| M_PWD "password" | (waiting for a password from |
| | remote) |
|--------------------------------+-------------------------------|
| (waiting for password | M_OK "secure" |
| acknowledgement) | |
|--------------------------------+-------------------------------|
| (got MOK) | MFILE "file2 200 42342434 0" |
|--------------------------------+-------------------------------|
| M_FILE "file1 100 423424244 0" | data |
|--------------------------------+-------------------------------|
| data | data |
|--------------------------------+-------------------------------|

http://ftsc.org/docs/fts-1027.001

1.7 Example of Frame Exchange During CRAM Authentication
--------------------------------------------------------

Originating :
send MNUL and MADR messages
wait for first MNUL and/or MADR message

Answering :
send M_NUL "OPT xx xx CRAM-MD5-f0315b074d728d483d6887d0182fc328"
send M_ADR message
and other messages
wait for M_PWD
Note: xx means other optional extensions thay are supported.



BinkP 1.1
http://ftsc.org/docs/fsp-1024.000

NOTE: Modify the table slightly to show one of the sides goes into
waiting after receiving M_EOB. Not showing this is confusing.

+-----------------------------------------------------------------+
| Originating side | Answering side |
|--------------------------------+--------------------------------|
| MNUL "SYS ..." | MNUL "SYS ..." |
| MNUL "ZYZ ..." | MNUL "ZYZ ..." |
| MNUL "LOC ..." | MNUL "LOC ..." |
| MNUL "VER ..." | MNUL "VER ..." |
| MNUL "OPT ..." | MNUL "OPT ..." |
| MADR "1:1/1.1@fidonet" | MADR "2:2/2.2@fidonet" |
| M_PWD "password" | (waiting for a password from |
| | remote) |
|--------------------------------+--------------------------------|
| (waiting for password | MOK "" (or MERR "Bad |
| acknowledgement) | password") |
|--------------------------------+--------------------------------|

======================================================================

Как видишь, в стандарте не определено ожидание M_ADR одной из сторон - только синхронизация на сверке пароля, о чем явно указано в FTS.
Однако, технически возможно* и *не противоречит стандарту, если в мейлер добавить выдачу своего адреса только после представления вызывающей стороны, о чем я ранее и написал.


Alexey Khromov
--- GoldED+/LNX 1.1.5-b20240309