[SM 0]

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

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

 

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

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

[zltigo 1]

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

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

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

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

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

Берите :) :) :)

http://www.wattystuff.net/amateur/packet/w...owsprograms.htm

будете шипеть соундбластером.

[SM 0]

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

 

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

 

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

 

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

 

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

[zltigo 1]

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

Повторяю ответ - радиолюбители не различают уровни модели :(. И под 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 0]

Повторяю ответ - радиолюбители не различают уровни модели :(. И под 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 таймер, и нарушили спецификацию.

[AlexandrY 3]

В 90-х это может и работало, а в Viste и Windows 7 SLIP-а больше нет. Ибо не поддерживает аутентификацию.

Более того SLIP-а нет даже в затасканом стеке lwIP !!!

Так что ставлю 1 против 10, что мужик будет делать на PPP.

 

Да никак не надо! Это далекооо от FTP клиента. FTP->IP->Ethernet Adapter->SLIP/PPP->RS232 Driver. Это ШТАТНАЯ фича Виндозного Dialup клиента. Только нажать на иконку "New Connection" и сказать, что надо. Для RS232 уже все уже прикручно до нас. На рубеже 90x лично пользовался широко :).

[aaarrr 69]

Более того SLIP-а нет даже в затасканом стеке lwIP !!!

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

[zltigo 1]

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

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

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 получает ГОТОВЫЕ ФРЕЙМЫ а не байты.

[SM 0]

а в Viste и Windows 7 SLIP-а больше нет.

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

 

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

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

[zltigo 1]

В 90-х это может и работало, а в Viste и Windows 7 SLIP-а больше нет.

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

Более того SLIP-а нет даже в затасканом стеке lwIP !!!

Так что ставлю 1 против 10, что мужик будет делать на PPP.

Ну и что, что нет - там буквально несколько десятков строчек написать.

Вот аж цельный UDP/IP в SLIP-е отдается в какой-то поделке 80x годов

 

#define FR_END		0xC0
#define FR_ESC		0xDB
#define T_FR_END	0xDC
#define T_FR_ESC	0xDD
//---------------------------------------------------------------------------
void sendframe( )
{

int len = 0;

DWORD out_bl;
BYTE *ao_ptr = (BYTE *)&ao;
BYTE *so_ptr = slip_obuff;

int usize = sizeof(udp_Header)+sizeof(cmd_Header)+len;
int fsize = sizeof(in_Header)+usize;
int ssize = 0;						// SLIP frame size

//	ao.iph.ver		= 4;
//	ao.iph.hdrlen	= 5;
//	ao.iph.tos		= 0x00;
ao.iph.length	= htons( fsize );
ao.iph.identification =  ++ident_flag;
//	ao.iph.frag_ofs		= 0x0000;
//	ao.iph.ttl		= 125;
//	ao.iph.proto	= 17;
//	ao.iph.checksum = 0xFFFF;
//	ao.iph.destination	= htonl(0xC0A802C8);
//	ao.iph.source		= htonl(0xC0A802C9);
ao.iph.checksum		= ~inchksum( ao_ptr, ao.iph.hdrlen * 4 );

//	ao.udp.dstPort	= htons( 9023 );
//	ao.udp.srcPort	= htons( 9023 );
ao.udp.length	= htons( usize );
//	ao.udp.checksum = 0x0000;

ao.hdr.ptype	= CP_ALARM;

*(so_ptr++) = FR_END;
while( fsize-- )
{	if( *ao_ptr == FR_END )
	{	*(so_ptr++) = FR_ESC;
		*so_ptr = T_FR_END;
		ssize++;
	}
	else if( *ao_ptr == FR_ESC )
	{	*(so_ptr++) = FR_ESC;
		*so_ptr = T_FR_ESC;
		ssize++;
	}
	else
		*so_ptr = *ao_ptr;
	ssize++;
	so_ptr++;
	ao_ptr++;
}
*so_ptr = FR_END;
ssize += 2;		// Double FR_END

WriteFile( hCom, slip_obuff, ssize, &out_bl, NULL );
}

Главное - что коллизии разруливает именно AX.25

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

[SM 0]

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

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

[zltigo 1]

Хорошо, соглашусь с вами. Я тоже устал. Признаю - спецификацию AX.25 писали идиоты.

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

С таким-же успехом (повторяюсь :( ), если Автор напишет драйверок (или железку приладит) который будет поддерживать halfduplex на UART-е, и натравит на него простейший SLIP, то у него прекрасно заработает TCP/IP.

[SM 0]

По причине основного недопущения коллизий на нижних уровнях (в железе/драйвере),

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

 

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

 

 

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

[zltigo 1]

А AX.25 - содержит, и указывает на конкретные действия. В чем и одно из коренных отличий одного от другого.

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

[SM 0]

При массовых коллизиях неразруленных на нижних уровнях захлебнется/подвестится любой из помянутых протоколов.

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

 

Описыватели AX.25 помянули одну из причин потерь явно.

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