А то самое, о чем тут? Разруливание коллизий полудуплекса [радиоканала]...


Да так и называется - "TCP/IP over AX.25", или "TCP/IP через AX.25". В линуксе оно встроено в ядро. А для виндовс надо что-то там искать, качать и ставить. Одно из них то-ли FlexNet, то-ли NetFlex. Я сам этим никогда не пользовался, ибо не радиолюбитель. Просто знаю о существовании и о некоторых свойствах, да и то без 100%-ной гарантии.

В линуксе оно вот этим самым

НЕ занимается. А снаружи "You can use a physical Packet Modem (Terminal Node Controller = TNC)"

Берите
http://www.wattystuff.net/amateur/packet/w...owsprograms.htm
будете шипеть соундбластером.

Тогда, повторю вопрос - зачем тогда в спецификации есть разделы, посвященный коллизиям, полудуплексу и их разруливанию?

TNC естественно есть, но он в себе содержит (по крайней мере содержал лет так 15-20 назад) именно только сам модем - просто тупо преобразующий поток данных в модулированный НЧ сигнал без каких либо LAP*, коррекций ошибок, и прочего. И AX.25 работает сразу поверх этого.

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

Если бы я сам решал бы эту задачу с тем, что готовый софт на PC - обязательное условие - просто собрал бы свой переходник RS232-RS485 с разруливанием коллизий внутри этого переходника, и SLIP или PPP сверху этого.

Повторяю ответ - радиолюбители не различают уровни модели . И под AX.25 подразумевают "все разу" начиная с HDLC/SLIP и до
собственно AX.25. Как уже писал, в том-же Линуксе в AX.25 исходниках нет следов ни только разруливания коллизий, но и даже HDLC/SLIP уровня. Всем этим должен заниматься какой-то виртуальный или железный девайс.
В комплексных решениях типа виндозной шипелки в соундбластер совершенно очевидно реализовано ВСЕ, но оно не пригодно Автору. Практически оно ему и не надо, ибо это то-же самое, что написать простейшее приложение, о котором я писал несколькими постами выше. Причем при написании такого приложения АБСОЛЮТНО лишняя сущность ввиде AX.25 не используется и ее не требуется реализовывать на стороне контроллера (походу поиска халявы для PC об этом забыли ).


Именно так, только пропустили еще функцию определение занятости канала передачи, как это, например, делает PHY для Ethernet коаксиала. И собственно HDLC запихивающий байты получаемые из асинхронного потока в битовый синхронный. Впрочем, думаю, что радиолюбители скорее всего используют вариант с байтовым потоком, т.е. поминаемый ранее SLIP (в линуксе поддерживаются и SLIP и HDLC нижние уровни). Далее по тексту...

Ну HDLC-уровень (правильнее - уровень битового потока) там действительно лежит на модеме и на уарте - это просто пропуск старт- и стоп- бит от RS-232 в канал и прием их обратно. У автора HDLC-уровень не нужен, так как старт- и стоп- биты проходят по его каналу без изменения, формируются уартом с одной стороны, и вырезаются с другой - т.е. этот уровень, правильнее сказать, не не нужен, а уже реализован в его железе уартами.

SLIP-уровня там НЕТ вообще, и никогда не было. Выход модема, после убирания из него старт- и стоп-бит при помощи "железки" под названием UART идет сразу на уровень AX.25

Касаемо определения занятости канала - RS-232 сигнал CD - Carrier Detect - он мог использоваться в AX.25 (CSMA/CA), но он не гарантирует защиты от коллизий, а лишь уменьтшает их вероятность, и это опция. Два передатчика все равно могут свободно начать передавать в примерно одно время, сотворив коллизию.

А почему в линуксовом варианте AX.25 нет следов вот этого (нумерация пунктов другая, так как я из другой версии спецификации взял):

6.3.6.1. Collisions in a Half-Duplex Environment
Collisions of frames in a half-duplex environment are taken care of by the retry nature of the T1 timer and
retransmission count variable. No other special action is required.

я просто не в курсе. Значит они не реализовали этот T1 таймер, и нарушили спецификацию.

В 90-х это может и работало, а в Viste и Windows 7 SLIP-а больше нет. Ибо не поддерживает аутентификацию.
Более того SLIP-а нет даже в затасканом стеке lwIP !!!
Так что ставлю 1 против 10, что мужик будет делать на PPP.

Да ладно. А slipif.c тогда зачем?

О господи, ну пакетный, это уровень. Пакетный! И никакими "уартами" занающими только о байтах он реализован быть не может. Ну никак.

А вот SLIP, как раз и собирает из байтов пакеты. Посему два варианта, либо HDLC собирает из битов фреймы сразу, либо из битов
UART обирает байты из которых потом SLIP собирает пакеты.

Посторяю, ну не понимает AX.25 поток байтов. Ему фреймы подавать надо. Вот, как выглядит в линуксе к котрому Вы меня отослали,
передача на уровень AX.25

AX.25 получает ГОТОВЫЕ ФРЕЙМЫ а не байты.

Ну и незачем пользоваться этими вперед ногами рожденными уродцами. Была более-менее нормальная XP, в ней SLIP есть, и все остальное куда прямее и нормальнее.


Да пусть там SLIP есть, пусть нет, это не суть важно, SLIP-у совершенно по барабану, дуплекс там в канале или полудуплекс. Вполне возможно, что у них там подразумевается, что SLIP входит в состав AX.25, если это не так на самом деле... Я же говорю - я не на столько знаток всей спецификации, спорить не буду. Главное - что коллизии разруливает именно AX.25 задержанными ретрансмитами, а не SLIP, и не кто-то там еще ниже. Ну пусть будет TCP/IP->AX.25->SLIP->UART->канал->все_в_обратном_порядке - суть в AX.25 лишь в том, чтобы разрулить полудуплекс, работать по которому он обучен изначально.

В XP есть - проверил .

Ну и что, что нет - там буквально несколько десятков строчек написать.
Вот аж цельный UDP/IP в SLIP-е отдается в какой-то поделке 80x годов



Тфу, устал уже объяснять кто чем занимается. Имеющий разум да поймет, а остальное не столь важно.

Хорошо, соглашусь с вами. Я тоже устал. Признаю - спецификацию AX.25 писали идиоты. Коллизии она вопреки спецификации не разруливает. По полудуплексу вопреки спецификации не работает. Все радиоканалы, на которых она используется, только полнодупдексные. А если у кого-то и работает по полудуплексу, то коллизии разруливает некая потусторонняя сила в модеме, который сам по себе умеет лишь модулировать несущую входным цифровым сигналом, без какой либо его "интеллектуальной" обработки (типа древних модемов V.23 и V.24 без всяких там MNP и прочих LAP-ов).

Нет, просто Вы пытаетесь рассказать, что в изобилии имеются некие программы, которые реализует на железе UART ВСЕ уровни ДО AX.25 включительно. Возможно, но могу точно сказать, что найденные в интернете ссылки на некие любительские программы и уж совершенно точно (исходники доступны всем) поминаемая Вами поддержка в ядре Линукса AX.25 занимается только ВЕРХНИМ уровнем, т.е. собственно самим AX.25 и совсем не занимается самым нижним уровнем, который в том числе и исключает бОльшую часть коллизий, как минимум НЕ допуская начала передачи в занятый канал. Это совершенно обыденный и естественный подход со времен того-же Ethernet на коаксиале. По причине основного недопущения коллизий на нижних уровнях (в железе/драйвере), как уже давал ссылку, радиолюбители и прямо без проблем используют ICP/IP, который, на самом деле является протоколом выполняющий такие-же задачи как X.25, AX.25, TCP/IP и так-же не знающий ничего о коллизиях в канале.
С таким-же успехом (повторяюсь ), если Автор напишет драйверок (или железку приладит) который будет поддерживать halfduplex на UART-е, и натравит на него простейший SLIP, то у него прекрасно заработает TCP/IP.

В общем, наличие хардварного детектора занятости канала и его использование (CSMA/CA), это лишь опция. AX.25 успешно работает (работал в те дальние года) у народа на полудуплексе и без этого. Что касается других уровней - да не против я того же SLIPа (других уровней между голым AX.25 и опять же голым модемом нет), но повторю, на количество и природу происхождения коллизий, как и на вид ошибок в результате коллизии, наличие или отсутствие этого уровня (SLIP) никак не скажется. А вот что касается спецификаций - так TCP/IP, на сколько я знаю, вообще не содержит ни слова про коллизию, и ни слова про полудуплекс. А AX.25 - содержит, и указывает на конкретные действия. В чем и одно из коренных отличий одного от другого. О чем я тут столько времени и говорю.

И я тоже не знаю, на сколько какая реализация сейчас соответствует спецификации, и что там в нее входит. Но то, что "оно" работает на полудуплексе с "голым" модемом, не содержащим в себе ничего, кроме модема, и никаких потусторонних дополнительных разруливалок коллизий, и CSMA/CA там нет - точно, сам видел на заре пакетной связи.


PS. Короче мне совсем надоел наш спор непонятно о чем. Пусть человек сам прочитает спецификацию в части полудуплекса и коллизии, и решит все, что ему там надо. Я привел номер главы/раздела/пункта, где это искать.

Вот эти "конкретные действия" НИЧЕМ не отличаются (случайное значение таймаута не принципиально) от действий ЛЮБОГО протокола верхнено уровня при потере/не подтверждении фрейма. Вызваны эти потери коллизиями в канале или еще чем всем протоколам LAP*/AX.25/X.25/TCP по барабану. Описыватели AX.25 помянули одну из причин потерь явно. Вот и все "коренное отличие" . При массовых коллизиях неразруленных на нижних уровнях захлебнется/подвестится любой из помянутых протоколов.

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


А я это читаю, как "при коллизии достаточно этого действия, и применять дополнительных мер для их разруливания не требуется". Потому как описывать всякие возможные причины просто так, бесцельно, смысла нет.