FTP по RS-485, Реально ли? Опции

[skripach]

Может не совсем Ethernet но всё же...
Задача передавать файлы, удалять файлы, просматривать директории на SD-карте которая вставлена в "железку".
Связь с "железкой" осуществляется по существующим каналам (PC->RS-232->RS-485->"железка").
Вопрос реально ли сделать подобие FTP сервера но по RS-485.
Очень хотелось бы для PC ничего не создавать, а пользоваться стандартным FTP-клиентом.

[SysRq]

А если ошибка в канале битовая... Начнутся перезапросы, перепосылки пакетов...

Это loopback. Я сам себе сервер, сам себе клиент. По полудуплексному каналу я предлагаю гонять только протокол верхнего уровня.

Без проблем, но его придется написать...

Обработку TFTP (или HTTP) запросов в железе. На ПК софта полно.

[zltigo]

Обработку TFTP (или HTTP) запросов в железе. На ПК софта полно.

Вы опять о чем-то, чего не понимаете,говорить пытаетесь

(HDLC, к сведению, является несущей PPP)

Нет, они идеологически похожи по формированию фреймов, но один в другом не нуждаются. Тем более, что как уже поминал, HDLC это биториентированный протокол и в нем байториентированный UART не нуждается.

[AlexandrY]

Слаб я в идеологии... Это враги из Freescale называют физический уровнь PPP как HDLC.
Да и другие как сговорились все этот уровень HDLC называют.

А так согласен HDLC это битовый протокол.
У нас одна уважаемая фирма даже собственный придумала формат тоннеля IP поверх FrameRelay с битовым HDLC и через свои спутниковые каналы качает с огромной скоростью.

Нет, они идеологически похожи по формированию фреймов, но один в другом не нуждаются. Тем более, что как уже поминал, HDLC это биториентированный протокол и в нем байториентированный UART не нуждается.

[zltigo]

Да и другие как сговорились все этот уровень HDLC называют.

Для битовых потоков это так и есть - классика жанра. Тот-же X.25 лежит в таком случае поверх HDLC+LAPB(вот эту сладкую парочку
уровня Data Link и могут называть как придется)->MLP->X.25

спецификации AX.25 ?

Про AX.25 не занимался, не знаю. Ну а X.25, как и многое другое, писал собственноручно - чего там нет, так это разруливания halfduplex.
Скажу одно, что после уровня LAP* заниматься разрешением коллизий уже изрядно поздно . Одиночные битые фреймы они хоть и на самом верху на IP уровне отсеиваться и переповторяться могут, но не массовые потери.

[AlexandrY]

Боюсь мужику все равно придется поверх X.25 лепить PPP.
А то кто будет проводить назначение сетевых адресов, DNS-ов, шлюзов?

Ну а X.25, как и многое другое, писал собственноручно.
Скажу одно, что после уровня LAP* заниматься разрешением коллизий уже изрядно поздно . Одиночные битые фреймы они хоть и на самом верху на IP уровне отсеиваться и переповторяться могут, но не массовые потери.

[SM]

Боюсь мужику все равно придется поверх X.25 лепить PPP.

Что-то это масло масляное - TCP/IP over AX.25 over PPP

А то кто будет проводить назначение сетевых адресов, DNS-ов, шлюзов?

Дык это уже всякие там DHCP/BOOTP и тому подобное, это выше, чем TCP/IP, да и фиксированно прописать можно, и без DNS вообще (это тут только с жиру беситься - доменные имена вводить в 485-ой сети). А какие-то фиксированные адреса в RS-485 сети наверное уже и так есть... Которые видимо в AX.25 вид "позывной+SSID" придется переделать.

Про AX.25 не занимался, не знаю. Ну а X.25, как и многое другое, писал собственноручно - чего там нет, так это разруливания halfduplex.

Блин, сорри, досадная опечатка вышла, букву пропустил... В этом сообщении http://electronix.ru/forum/index.php?showt...st&p=698806 - все три раза должно быть AX.25

[AlexandrY]

Маразм крепчал...
DHCP используют вообще-то только при наличии уровня LLC-MAC. Хотя можно в принципе наверно предложить коллеге эмулировать LLC и МАС поверх RS485.

...Дык это уже всякие там DHCP/BOOTP и тому подобное, это выше, чем TCP/IP, да и фиксированно прописать можно, и без DNS вообще...

[SM]

при наличии уровня LLC-MAC.

Что за новости? Это где еще такое в RFC-2131 написано? UDP+броадкасты есть - значит и DHCP реализуем, и совершенно все равно, что там ниже, MAC или не MAC.
Да и реализуется он (DHCP) "одной левой", если уж человек на FTP позарился. Хотя в контексте - фиксированные айпишники всем, и вперед.

Короче - если TCP/IP over AX.25 встроен в ядро ОС на PC, то и какой-то протокол преобразования IP-адресов в AX.25 адреса (по аналогии с изернетовским ARP) тоже там есть. Дело за малым - поднять AX.25 и TCP/IP over AX.25 в девайсе.

[zltigo]

AX.25.

Да успокойтесь Вы с AX.25 - ну он уже по любому работает с ГОТОВЫМИ фреймами и если будет тупо ими кидатся, то просто может и ни один не дойти. Нужно коллизии разруливать на байтово-фреймовом уровне пока навстречу идет фрейм свое буферизировать и не передавать. А при конфликте встречных фреймовых маркеров должно быть понятие уступающего слейва. И уж потом, если разрулили не 100% коллизий качественно, например, по причине упрощения разруливателя, то это тогда битое на IP вывалится и подчистится.

[SM]

Да успокойтесь Вы с AX.25 - ну он уже по любому работает с ГОТОВЫМИ фреймами и если будет тупо ими кидатся, то просто может и ни один не дойти.

Да не успокоюсь. Решение какое-никакое, а готовое, и соответствующее поставленной задаче - без какого либо самописного софта на PC. Пользуются им многие, то что Вы их не знаете, этого не отменяет. Про то, что на PC win никто не говорил (или, если я пропустил, извиняюсь). Да и для win полно готовых решений для "TCP/IP через AX.25", только они не встроены в систему, а требуют установки. Что касается "тупо кидается" - он не "тупо кидается", а с рандомной задержкой, т.е. "тупо как Ethernet". Вообще в пакетном радио другого способа разрешения коллизий, кроме как в AX.25, просто нет, и все пакеты доходят, несмотря на Ваши сомнения. Тут уж "может не дойти, может дойти" - непрофессионально, давайте или не гадать вообще, или измеренные (или рассчитанные) результаты "сколько может не дойти при каком уровне коллизий", и почему. Я руководствуюсь лишь практическими результатами пользователей, которые используют AX.25 по назначению, а именно поверх полудуплексного радиоканала, где коллизий и помех куда больше, чем в RS-485 кабеле.

[zltigo]

Я руководствуюсь лишь практическими результатами пользователей, которые используют AX.25 по назначению, а именно поверх полудуплексного радиоканала, где коллизий и помех куда больше, чем в RS-485 кабеле.

Теперь просьба подумать не отличаются-ли у радиолюбителей протоколы верхнего уровня от желаемого Автором FTP/TCP. C определенностью полагаю, что там протоколы/процедуры верхнего уровня сами по себе ПОЛУДУПЛЕКСНЫЕ и AX.25 в этом случае занимается разрешением потерь, равно, как и редких случайных коллизий канале, которые НИКАК не отличает от потерь вообще. Они действительно могут быть разрешены - выше я говорил, что и в "драйвере" для простоты можно и не гарантировать разрешения всех коллизий - верхний уровень сможет расхлебать последствия редких коллизий.
В FTP/TCP halfduplex не пахнет и коллизии будут ГАРАНТИРОВАННЫЕ и неразрешимые. Чего-нибудь будет пролезать разве только чудом и изредка.

P.S.
Посмотрел какую-то радиолюбительскую статью. В общем, по крайней мере в ней, буквы AX.25 вольно трактуются более, чем широко и к ним заодно валится в одну кучу Data Link уровень на котором действительно ожидаемо поминается контроль за занятостью канала передачи. Посмотрел исходники Линукса - то, что там написано не ведает, точнее не делает НИКАКИХ различий между simplex и duplex каналами. switch() везде присутствует, но они строго везде запаралелены. Пример:

Код

void ax25_kick(ax25_cb *ax25)
{
.....
        switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {
        case AX25_PROTO_STD_SIMPLEX:
        case AX25_PROTO_STD_DUPLEX:
            ax25_send_iframe(ax25, skbn, (last) ? AX25_POLLON : AX25_POLLOFF);
            break;

В конце концов все передается железному уровню одинаково - dev_queue_xmit(skb) и нехай там некий dev разбирается, как передать.

[SM]

Теперь просьба подумать не отличаются-ли у радиолюбителей протоколы верхнего уровня от желаемого Автором FTP/TCP.

не отличаются. Так как протокол верхнего уровня и есть TCP/IP. И я об этом уже писал - "TCP/IP over AX.25" - реализация этого в готовом виде имеется и для windows.

[zltigo]

....не отличаются. Так как протокол верхнего уровня и есть TCP/IP

Если следовать банальной логике, то обертывать TCP/IP в AX.25 незачем, ибо делают одно и то-же.
Единственная причина изложена здесь:
http://www.a27.ru/information/bulleten/199...paketnoe-radio/

AX.25 рассматривается как фактически стандартный протокол для использования в любительской радиосвязи и даже признается многими странами как легальный вид работы. Однако есть и другие стандарты. Любителями некоторых регионов используется TCP/IP. Часто используются специальные протоколы пакетного радио встраиваются внутрь пакетного формата AX.25. Это делается для обеспечения соответствия правилам, требующим, чтобы пакетные радиопередачи были в форме AX.25. Однако детали такого встраивания могут отличаться в различных странах.

Так-что TCP/IP через AX.25 это только один из частных случаев. Насколько я могу понимать родное использование AX.25 радиолюбителями это
посылка текстовых сообщений - чат, в стиле вопрос - ответ.

[SM]

Если следовать банальной логике, то обертывать TCP/IP в AX.25 незачем, ибо делают одно и то-же.

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

А как это готовое называется и где можно взять.

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

[zltigo]

В линуксе оно встроено в ядро.

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

разруливания коллизий полудуплекса радиоканала

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

А как это готовое называется и где можно взять.

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

[SM]

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

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

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

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

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

[zltigo]

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

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

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

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

И AX.25 работает сразу поверх этого.

[SM]

Повторяю ответ - радиолюбители не различают уровни модели . И под AX.25 подразумевают "все разу" начиная с HDLC/SLIP и до собственно AX.25. Как уже писал, в том-же Линуксе в AX.25 исходниках нет следов ни только разруливания коллизий, но и даже HDLC/SLIP уровня.

Ну 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 таймер, и нарушили спецификацию.

[zltigo]

...а уже реализован в его железе уартами.

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

SLIP-уровня там НЕТ вообще, и никогда не было.

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

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

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

Код

/*
*    Receive an AX.25 frame via a SLIP interface.
*/
int ax25_kiss_rcv(struct sk_buff *skb, struct net_device *dev,
          struct packet_type *ptype, struct net_device *orig_dev)
{
    skb->sk = NULL;        /* Initially we don't know who it's for */
    skb->destructor = NULL;    /* Who initializes this, dammit?! */

    if (!net_eq(dev_net(dev), &init_net)) {
        kfree_skb(skb);
        return 0;
    }

    if ((*skb->data & 0x0F) != 0) {
        kfree_skb(skb);    /* Not a KISS data frame */
        return 0;
    }

    skb_pull(skb, AX25_KISS_HEADER_LEN);    /* Remove the KISS byte */

    return ax25_rcv(skb, dev, (ax25_address *)dev->dev_addr, ptype);
}

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