1. Forum
  2. FidoNet Russia
  3. SU.HAMRADIO

  • Fidonet-over-ax25

    From Nil A@2:5015/46 to Sergey Anokhin on Wed Feb 11 03:38:22 2026
    * Originally in ru.fidonet.today
    * Crossposted in su.hamradio
    Hello, Sergey!

    Wednesday February 11 2026 02:11, from Sergey Anokhin -> Nil A:

    запили хоть для бинкд поддержку ax25 "искаропки" )))
    у там на малинке какой-нить, там и ком порт есть и tnc kiss и всякая лабуба.

    есколько вопросов. а какой скорости собрался гонять ax25? Я супер давно экспериментировал с драйвером для звуковухи под линукс, и через гарнитурный разъём СиБишки (Алан-48+) гоняли с другом 1200 скорость. Возможно на двойке 2400 можно так погонять. Всё что быстрее, там модуляции требуют лезть в станцию, чтобы напрямую с детектора приёмника снимать сигнал.

    Фидо софт спроектирован модульно, т.е. редактор отдельно, тоссер отдельно, мыллер тоже. Вместо мыллера, ты можешь бандлы носить на дискетах. Всё что тебе нужно - передать файлы. Что, радиософт, всё что "в комплекте" к ax25 идёт, не умеет очередь файлов передать и принять? Дело в том, что в ax25 тебе нужно будет по-любому выставить какие-то позывные, у вызывающей и вызываемой стороны, а тут ещё фидошные "позывные" следующим слоем?

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

    Интернетчики (Гугловцы), например, QUIC (Quick UDP Internet Connections) изобрели не зря, что стало основой для HTTP/3. UDP пакеты, а не TCP - сильно похоже как на радио, нажал на передачу, выпленул, дошло/недошло, переповторим, но не будет заморачиваться установлением соединения. И сразу в пакете и авторизация и zero-rtt, т.е. сразу же и полезная нагрузка.

    Для передачи по-радио, где скорости маленькие, а время на переключение передачи долгое, вообще надо постараться одним включением и себя аутентифицировать, и кому что хочешь сказать, тут же .pkt сунуть, который лежал на отдачу. А вы всё хотите натягивать сову на бинкп.

    "Корочь, сегодня слушал подкаст о философии про лень, говорят, что
    Фома Аквинский причислил лень к смертным грехам от того, что у людей "суетная душа"

    [...] (оффтоп конечно, извините заранее)

    Лень - это эволюционное достижение человека, когда можно не тратить калории, а просто забить - если не потребовалось, то и хорошо, значит не сильно и нужно было.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Nil A@2:5015/46 to Sergey Anokhin on Wed Feb 11 04:02:42 2026
    * Originally in ru.fidonet.today
    * Crossposted in su.hamradio
    Hello, Sergey!

    Wednesday February 11 2026 02:19, from Sergey Anokhin -> Nil A:

    Есть утилитка от сорялиса на голом си, она делает tcp/ip over ax25,
    tap интерфейс подымает. Даже считай ядерные фичи ax25 не нужны.

    Да - этот способ с минимальным поднятием пятой точки. Я написал в пред.письме, что бедненькое радио на 1200/2400/4800 скорости, да ещё с таким временем переключения, и ты ещё хочешь навернуть слоёный пирог
    1. AFSK/FSK (физический уровень нужен)
    2. KISS/AX.25
    3. IPv4
    4. TCP
    5. Binkp

    У тебя только на обмен фтн-адресами, паролями, именами бандлов - уйдёт 20 переключений передачи туда-сюда, и минуты 2 на скорости 2400.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Andrei Kopanchuk@2:5058/108.2 to Nil A on Wed Feb 11 15:51:36 2026
    Привет, Nil

    11 фев 26, Nil A пишет к Sergey Anokhin:

    Wednesday February 11 2026 02:19, from Sergey Anokhin -> Nil A:

    Есть утилитка от сорялиса на голом си, она делает tcp/ip over
    ax25, tap интерфейс подымает. Даже считай ядерные фичи ax25 не
    нужны.

    Да - этот способ с минимальным поднятием пятой точки. Я написал в пред.письме, что бедненькое радио на 1200/2400/4800 скорости, да ещё с таким временем переключения, и ты ещё хочешь навернуть слоёный
    пирог 1. AFSK/FSK (физический уровень нужен) 2. KISS/AX.25 3. IPv4 4.
    TCP 5. Binkp

    У тебя только на обмен фтн-адресами, паролями, именами бандлов - уйдёт
    20 переключений передачи туда-сюда, и минуты 2 на скорости 2400.

    Вообще, оптимальный вариант - это что-то вроде FBB протокола, по которому работают BBS-ки и Winlink. Станции между собой обмениваются, по очереди, бандлами (для BBS обычно штук 5), упакованными LZH архиватором.


    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: Продам вечный двигатель. Гарантия 12 месяцев. (2:5058/108.2)
  • From Sergey Anokhin@2:5034/10.910 to Andrei Kopanchuk on Wed Feb 11 20:34:05 2026
    Да - этот способ с минимальным поднятием пятой точки. Я написал в пред.письме, что бедненькое
    радио на 1200/2400/4800 скорости, да ещё с таким временем переключения, и ты ещё хочешь
    навернуть слоёный пирог 1. AFSK/FSK (физический уровень нужен) 2. KISS/AX.25 3. IPv4 4. TCP
    5. Binkp У тебя только на обмен фтн-адресами, паролями, именами бандлов - уйдёт 20
    переключений передачи туда-сюда, и минуты 2 на скорости 2400.
    Вообще, оптимальный вариант - это что-то вроде FBB протокола, по которому работают BBS-ки и
    Winlink. Станции между собой обмениваются, по очереди, бандлами (для BBS обычно штук 5),
    упакованными LZH архиватором.

    А ты ведь как то оптимизировал binkp для работы по радиоканалу?

    --
    С наилучшими пожеланиями! Опубликовано ХотДогом с планеты Ведроид
    --- ХотДог/2.14.5/Android
    * Origin: Android device, Milky Way (2:5034/10.910)
  • From Andrei Kopanchuk@2:5058/108.2 to Sergey Anokhin on Wed Feb 11 21:13:44 2026
    Привет, Sergey

    11 фев 26, Sergey Anokhin пишет к Andrei Kopanchuk:

    Вообще, оптимальный вариант - это что-то вроде FBB протокола, по
    которому работают BBS-ки и Winlink. Станции между собой
    обмениваются, по очереди, бандлами (для BBS обычно штук 5),
    упакованными LZH архиватором.

    А ты ведь как то оптимизировал binkp для работы по радиоканалу?

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

    Если хочется качественно, то лучше брать за основу симплексные протоколы, такие как FBB.


    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: Дальше едешь - больше клуджей. (2:5058/108.2)
  • From Nil A@2:5015/46 to Andrei Kopanchuk on Thu Feb 26 22:55:32 2026
    Hello, Andrei!

    Wednesday February 11 2026 21:13, from Andrei Kopanchuk -> Sergey Anokhin:

    А ты ведь как то оптимизировал binkp для работы по радиоканалу?

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

    Я тут поболтал с Чатовым (chatgpt/gemini/..) на эту тему - умный чел (в смысле бот).

    Во-первых, для тестов можно погонять AX.25 между двумя линуксами, просто в виртуалках, и звуковуху виртуальную пробросить по IP, либо через PulseAudio Networking, либо ALSA c snd_aloop + JACK, т.е. вообще в песочнице. Для контроля звук можно ещё зароутить на хост, и послушать через звуковуху, или в анализатор.

    Во-вторых, точно выкинуть AX25 + TCP/IP + Binkd - это просто огроменный оверхед.

    В-третьих, тогда уж использовать модемный EMSI/ZModem протокол, через stdin/stdout как-то запустить qico или ifcico - тогда оверхед радио<->ax25_сессия<->EMSI... но дричканий RX/TX будет дофигища тоже. Короче, так тоже лучше не делать.

    Правильный способ - из ax.25 использовать не Connected Mode, а UI Frames (Unnumbered Information), и пакеты, подтверждение, ретрансляция - это всё самому из своего протокола контролировать.

    По факту, надо написать свой мейлер, или добавить "новый протокол" в Binkd, который откроет сокет `socket(AF_AX25, SOCK_DGRAM, 0);`, почти как UDP получается. Взять библиотечку libax25, подготовить позывной `ax25_aton("N0CALL-1", &addr.fsa_ax25.sax25_call);`, добавить некий HELLO в стиле FTN, тут же какие у нас есть бандлы и пр, и всё это отправить одним `sendto(fd, buffer, len, ...`, а на приёмной стороне принять `recvfrom(fd, buffer, sizeof(buffer), ...`. Понятно, что paclen типа 128 байт дефолт, но можно увеличить, например на 256 - на 1200 это будет в эфире 2 секунды. Без подтверждения приёма, можно, например, 7 пакетов отправлять. Присылать только какие фрагменты не прошли. Короче, прямо по самому минимуму приём/передача, и сразу в первом же пакете и сессия, и аутентификация, и данные, и поехали.

    Протокол можно сделать также парольным и не парольным, всё в фидошном стиле. Парольную сессию можно делать в открытом виде, но с подписью пакетов по hmac, или вообще целиком отправки шифровать (но тогда нарушается правила HAM например). Отдельно обмениваться ключами, или каким-то парольным челленджем как в бинкп - не надо, т.к. это долго, много переключений TX/RX. У нас есть пароль у обоих сторон, можно сделать Pre-Shared Key (PSK) на его основе, если время и соль замешать ещё - часы на обоих компах должны быть плюс/минус минуты одинаковые. Фсё! Если нет почты - один пакет туда, один обратно. Если есть pkt, то несколько пакетов туда, и один обратно, и всё парольное, или даже зашифрованное.

    Всё сводится к разработке собственного протокола, и собственного мейлера, который Binkley-style outbound умеет читать. Собственный протокол сначала можно опробовать на UDP, заодно ещё один протокол появится :-) потом на AX.25 сокет просто перевести, с настройками размера покета, таймаута, и пр.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Sergey Anokhin@2:5034/10.910 to Nil A on Fri Feb 27 09:28:46 2026
    Hello, Nil A.
    On 26.02.2026 22:55 you wrote:

    Всё сводится к разработке собственного протокола, и собственного мейлера, который
    Binkley-style outbound умеет читать. Собственный протокол сначала можно опробовать на UDP,
    заодно ещё один протокол появится :-) потом на AX.25 сокет просто перевести, с настройками
    размера покета, таймаута, и пр.

    Так может claude премимум нашиткодит на голанге и дело в шляпе?

    --
    С наилучшими пожеланиями! Опубликовано ХотДогом с планеты Ведроид
    --- ХотДог/2.14.5/Android
    * Origin: Android device, Milky Way (2:5034/10.910)
  • From Nil A@2:5015/46 to Sergey Anokhin on Fri Feb 27 17:19:38 2026
    Hello, Sergey!

    Friday February 27 2026 09:28, from Sergey Anokhin -> Nil A:

    Всё сводится к разработке собственного протокола, и собственного
    мейлера, который Binkley-style outbound умеет читать.
    Так может claude премимум нашиткодит на голанге и дело в шляпе?

    Когда ты беседуешь с ИИ, он сразу бросается писать код - тут хлебом не корми, только результат получится "на авось". Да, если на самой крутой и дорогой модели клода попросить написать, то успехом будет считаться, если код собирается, и даже что-то разово куда-то передаёт, и может даже принимает! о хочется же бОльшего.

    Кстати, почему на гоу? Потому что ты его знаешь и можешь немного понять получающийся код? ИИ лучше всего владеет Python и JS, если что. Писать лучше на C/C++, чтобы потом на какой-нибудь малинке можно было запускать, если захочется.

    Правильнее, сначала потребовать от ИИ составить требования к новому протоколу - чтобы передавалось по-фидошному SYS/ZYZ/LOC/.. список что имеется, и сама отправка сразу. апример, не надо договариваться об АКА, какие есть, что показывать в ответ - звонящий точно знает кому он на какой адрес звОнит, и сразу может передать бандлы с подписью из пароля на линк. Также, обговорить протокол текстовый, или бинарный, или лучше переиспользовать готовые ProtoBuf/FlatBuffers/Cap'nProto чтобы не велосипедить. После требования, надо чтобы появился формальный документ протокола, по которому хоть ИИ, хоть человек уже может закодить, на любом языке программирования.

    Про реализацию надо прежде чем писать обговорить - какой конфиг файл, что аутбайнд у нас Binkley-style, что есть директории с парольной и непарольной сессией, вот это всё.

    И тогда уже можно просить писать! И просить писать тесты, и их гнать тут же. Только так может что-то получится осмысленное на выходе. Собственно, любой софт просто человеком так и пишется. ИИ тут не исключение ниразу, и требовать от него волшебства тоже не корректно.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Andrei Kopanchuk@2:5058/108.2 to Nil A on Fri Feb 27 19:51:08 2026
    Привет, Nil

    26 фев 26, Nil A пишет к Andrei Kopanchuk:

    Правильный способ - из ax.25 использовать не Connected Mode, а UI
    Frames (Unnumbered Information), и пакеты, подтверждение, ретрансляция
    - это всё самому из своего протокола контролировать.

    А чем Connected Mode не устраивает?

    1200 это будет в эфире 2 секунды. Без подтверждения приёма, можно, например, 7 пакетов отправлять. Присылать только какие фрагменты не прошли.

    Connected Mode тоже так умеет, не на всех модемах, правда. Hекоторые модемы умееют копировать часть пакетов в специальный буффер и перезапрашивать только те, которые нужно. Восстанавливать можно как покадрово, так и снова перепосылать пачку, как настроишь. Все зависит от качества канала, на КВ покадрово более оптимально, и пачки, обычно, по 2-3 пакета.

    Всё сводится к разработке собственного протокола, и собственного
    мейлера, который Binkley-style outbound умеет читать. Собственный
    протокол сначала можно опробовать на UDP, заодно ещё один протокол появится :-) потом на AX.25 сокет просто перевести, с настройками
    размера покета, таймаута, и пр.

    Вот, как раз, FBB протокол, автоматизировал передачу файлов, причем даже с сетевым уровнем.


    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: Дальше едешь - больше клуджей. (2:5058/108.2)
  • From Nil A@2:5015/46 to Andrei Kopanchuk on Fri Feb 27 22:12:26 2026
    Hello, Andrei!

    Friday February 27 2026 19:51, from Andrei Kopanchuk -> Nil A:

    Правильный способ - из ax.25 использовать не Connected Mode, а UI
    А чем Connected Mode не устраивает?

    Оверхед лишний, как в плане дричканья TX/RX, так и отправки самих байтов со скоростью 1200 бод.
    Connected Mode - это хендшейк ax.25, по типу как TCP, только тут 2-пакета, а не 3 как в TCP.

    Тебе надо сказать, Я станция A с фидо адресом 1:1/1, у меня есть бандл для станции B с адресом 2:2/2.
    1. A->B SABM, хендшейк
    2. B->A UA, хендшейк подтверждаю
    3. A->B I(0,0) I-информационный пакет с номером последовательности 0, Я FTN адрес 1:/1/1....
    ...

    Используя UI-режим, можно не делать SAMB+UA включений.

    Без подтверждения приёма, можно, например, 7 пакетов отправлять.
    Connected Mode тоже так умеет, не на всех модемах, правда.

    Да, когда мы используем UI, то подтверждения и перепосылку приходится делать вручную.
    Под модемом мы понимаем не TNC, а KISS программный тут, он умеет.

    Проблема Connected Mode ещё в том, что если какие-то проблемы, то мы пытаемся на уровне FTN-сессии решить, ещё какие-то CRC, подтверждения и пр. При этом уровень Connected Mode тоже этим занимается, и мы может тайм-ауты выставить, но как-то более гибко повлиять на "застрявшее" соединение не можем.

    Если нам просто поток данных с гарантированной доставкой надо отправлять, как телеграмму, или как на BBS зайти - Connected Mode в самый раз.
    Если мы _уже_ свой протокол обмена пишем, где договариваемся о FTN-сессии, передаче файлов, и т.д. то нам сподручнее решать проблемы связи низкого уровня, и при этом оперативнее, т.к. у нас чуть больше знаний о текущем соединении на таком прикладном уровне.

    Всё сводится к разработке собственного протокола, и собственного
    мейлера, который Binkley-style outbound умеет читать.
    Вот, как раз, FBB протокол, автоматизировал передачу файлов, причем
    даже с сетевым уровнем.

    у так и прикрутили бы "нативную" отправку файлов к FTN-делам, чем натягивать binkd на сову, зачёркнуто, на ax.25.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5-b20250409
    * Origin: Gemini can make mistakes, so double-check it (2:5015/46)
  • From Sergey Anohin@2:5034/10.1 to Nil A on Fri Feb 27 22:33:24 2026
    Hello, Nil!

    Кстати, почему на гоу? Потому что ты его знаешь и можешь немного понять получающийся код? ИИ лучше всего владеет Python и JS, если что. Писать лучше на C/C++, чтобы потом на какой-нибудь малинке можно было запускать, если захочется.

    у ты говорил что на с/с++ ему тяжело, примеров ему мало, а гоу хайповый и шустрый. у питон в целом пойдет тоже. у го бинарь как скомпилишь там везде и будет запускаться, хотя вроде и питон в бинарь ведь компилить можно.

    Правильнее, сначала потребовать от ИИ составить требования к новому протоколу - чтобы передавалось по-фидошному SYS/ZYZ/LOC/.. список что имеется, и сама отправка сразу. апример, не надо договариваться об АКА, какие есть, что показывать в ответ - звонящий точно знает кому он на какой адрес звОнит, и сразу может передать бандлы с подписью из пароля на линк. Также, обговорить протокол текстовый, или бинарный, или лучше переиспользовать готовые ProtoBuf/FlatBuffers/Cap'nProto чтобы не велосипедить. После требования, надо чтобы появился формальный документ протокола, по которому хоть ИИ, хоть человек уже может закодить, на любом языке программирования.
    Про реализацию надо прежде чем писать обговорить - какой конфиг файл, что аутбайнд у нас Binkley-style, что есть директории с парольной и непарольной сессией, вот это всё.

    у все так, грамотный промт 80% успеха. Сначала пусть протокол придумает, потом пишет, покормить всякие стандарты ему.

    И тогда уже можно просить писать! И просить писать тесты, и их гнать тут же. Только так может что-то получится осмысленное на выходе. Собственно, любой софт просто человеком так и пишется. ИИ тут не исключение ниразу, и требовать от него волшебства тоже не корректно.

    Так а кто сказал что с первой итерации все шик будет

    С наилучшими пожеланиями, Sergey Anohin.

    --- wfido
    * Origin: https://5034.ru/wfido (2:5034/10.1)
  • From Andrei Kopanchuk@2:5058/108.2 to Nil A on Sat Feb 28 01:05:46 2026
    Привет, Nil

    27 фев 26, Nil A пишет к Andrei Kopanchuk:

    А чем Connected Mode не устраивает?

    Оверхед лишний, как в плане дричканья TX/RX, так и отправки самих
    байтов со скоростью 1200 бод. Connected Mode - это хендшейк ax.25, по
    типу как TCP, только тут 2-пакета, а не 3 как в TCP.

    Дык, стандартная процедура LAPB/LAPM, для установления канала, как и завершение по DISC. Это позволяет качественно отследить начало и конец сессии. В случае UI пришлось бы дополнительно следить за этим. Да и пару лишних кадров на целую сессию особо погоды не строят.

    Да, когда мы используем UI, то подтверждения и перепосылку приходится делать вручную. Под модемом мы понимаем не TNC, а KISS программный
    тут, он умеет.

    KISS режим, в отличии от HOST, не умеет следить за физическим состоянием канала, например за состоянием DCD, и за данными в буфере передачи, из этого выплывают кривые тайминги и прочее. Есть конечно дополнение в виде KISS ACKMODE, но не все модемы и софт это поддерживают.

    Проблема Connected Mode ещё в том, что если какие-то проблемы, то мы пытаемся на уровне FTN-сессии решить, ещё какие-то CRC, подтверждения
    и пр. При этом уровень Connected Mode тоже этим занимается, и мы может тайм-ауты выставить, но как-то более гибко повлиять на "застрявшее" соединение не можем.

    Вообще, даже ZMODEM был адаптирован для LAPM каналов, таких как V.42. Правда, тайминги рассчитаны, как минимум, для 9600 линков. Hо я согласен, что двойной контроль потока - это лишнее. Для пакета в основном использовали YAPP, вроде как тот же FBB протокол на нем основан.

    Если нам просто поток данных с гарантированной доставкой надо
    отправлять, как телеграмму, или как на BBS зайти - Connected Mode в
    самый раз. Если мы _уже_ свой протокол обмена пишем, где
    договариваемся о FTN-сессии, передаче файлов, и т.д. то нам сподручнее решать проблемы связи низкого уровня, и при этом оперативнее, т.к. у
    нас чуть больше знаний о текущем соединении на таком прикладном
    уровне.

    Тут не совсем понял, HOST Connected Mode имеет самое полное представление о состоянии линка и может возвращать состояние буфера прикладному ПО, для контроля потока.

    Вот, как раз, FBB протокол, автоматизировал передачу файлов,
    причем даже с сетевым уровнем.

    Hу так и прикрутили бы "нативную" отправку файлов к FTN-делам, чем натягивать binkd на сову, зачёркнуто, на ax.25.

    Да, собственно и через FBB можно это сделать, даже на уровне скриптов. Hо она вроде как не умела файлы напрямую отправлять, только упакованные в сообщения, в виде UUE или 7+, которые потом дожиаются LZH, почти до того же состояния, что и оригинальный архив.


    ---
    * Origin: Продам вечный двигатель. Гарантия 12 месяцев. (2:5058/108.2)