Страниц: [1] 2 3
  Печать  
Автор Тема: TCP/IP через послед. порт в QNX 6.x - реально или нет?  (Прочитано 29730 раз)
fedorden
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« : Марта 27, 2002, 05:28:00 am »

Есть две машины с QNX6.x - нужно наладить обмен информацией через СОМ-порты по TCP/IP. Как такое сотворить (если это возможно)?
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #1 : Марта 27, 2002, 06:56:00 am »


fedorden пишет:
Есть две машины с QNX6.x - нужно наладить обмен информацией через СОМ-порты по TCP/IP. Как такое сотворить (если это возможно)?

То, что принципиально это возможно - не вопрос, "да". Как?

Нужен протокол, канализирующий IP через последовательное соединение, это - SLIP & PPP. Если io-net запускать не указывая девайс (ключ -d), то это устанавливает интерфейс ppp. И в качестве клиента и в качестве сервера может использоваться pppd при соответствующей конфигурации (это из HELP, как я его понял ).

Для конфигурации ppp придётся сильно повозиться, см. конфиг-файлы:
/etc/ppp/options.ser2 (это если интерфейс - ser2...),
/etc/ppp/pap-secrets,
/etc/ppp/chap-secrets,
/etc/ppp/ip-up,
....
Описания этого добра в HELP разделах "io-net", "pppd", "/etc/autoconnect" (это всё можно использовать как ключевые слова в поиске).

Если одолеете - опишите, пожалуйста. Вопрос интересный!

 
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #2 : Марта 27, 2002, 09:31:00 am »


fedorden пишет:
Есть две машины с QNX6.x - нужно наладить обмен информацией через СОМ-порты по TCP/IP. Как такое сотворить (если это возможно)?


$ use /lib/dll/devn-fd.so
devn-fd.so FD interface driver.

Syntax:
 io-net -d fd [option[,option ...]] ... &

Options (to override autodetected defaults):
 fd=device           Device to read/write packet data.
 mac=XXXXXXXXXXXX    MAC address of the controller. No default.
 wait                Wait for the device to be inserted.
 verbose             Be verbose.

Examples:
 # Start io-net using the FD driver and the full TCP/IP stack:
 io-net -d fd fd=/dev/ser1,mac=0123456789AB -p tcpip
 ifconfig en0 10.184
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #3 : Марта 27, 2002, 11:16:00 am »


dmi пишет:
Syntax:
 io-net -d fd [option[,option ...]] ... &

Options (to override autodetected defaults):
 fd=device           Device to read/write packet data.
 mac=XXXXXXXXXXXX    MAC address of the controller. No default.
 wait                Wait for the device to be inserted.
 verbose             Be verbose.

Examples:
 # Start io-net using the FD driver and the full TCP/IP stack:
 io-net -d fd fd=/dev/ser1,mac=0123456789AB -p tcpip
 ifconfig en0 10.184

А что в этом случае (последовательной линии точка-точка) должен обозначать адрес MAC, как мы его должны толковать?
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #4 : Марта 27, 2002, 12:21:00 pm »


А что в этом случае (последовательной линии точка-точка) должен обозначать адрес MAC, как мы его должны толковать?


А это не будет точка-точка( Point-to Point Protocol, ppp ), это будет обычная одноранговая TCP/IP  сеть( в случае двух машин, конечно же). А MAC нужен для корректной работы модуля протокола tcpip


[ Это Сообщение было отредактировано: dmi в 2002-03-27 09:22 ]
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #5 : Марта 27, 2002, 04:01:00 pm »

dmi пишет:
А это не будет точка-точка( Point-to Point Protocol, ppp ), это будет обычная одноранговая TCP/IP  сеть( в случае двух машин, конечно же). А MAC нужен для корректной работы модуля протокола tcpip

Прошу прощения, может это уже - назойливость, но вопрос становится просто интригующим:

-т.е. к сериал линии можно подключить несколько компов?
-и как это должно выглядеть электрически?
-и кто при обмене будет выступать master, кто slave, или симметрично...?
-и кто будет интерпретировать MAC-адреса (ведь в ethernet, arknet, ... это делает аппаратура сетевого адаптера)?
-и как этот "кто" будет делать "это"?

Если "нет" (первый вопрос), то зачем им MAC? И опять же: кто их интерпретирует?

... я совсем запутался, вопросы множаться, "несть им числа"!
Записан
wind_alex
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #6 : Марта 28, 2002, 03:01:00 am »

нет к одной линии нельзя подключить несколько
компов, но ничего не мешает вам соединить
их последовательно (com1(pc1) -> com1(pc2),com2(pc2) -> com1(pc3)) и т.д.
Только MAC адреса на com1(pc2) и com2(pc2) должны быть
разными, причем во всей сети (адреса не должны повторятся).
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #7 : Марта 28, 2002, 05:16:00 am »


-т.е. к сериал линии можно подключить несколько компов?
-и как это должно выглядеть электрически?
-и кто при обмене будет выступать master, кто slave, или симметрично...?


к одному последовательному порту можно подключать только одно устройство by design. Но, поскольку портов обычно много, компов можно навешать массу. Для каждого надо выделить свой МАС, чтобы с другими сетвыми адаптерами не путать.(в пределах сети МАС должен быть уникален, иначе финиш - петля).


-и кто будет интерпретировать MAC-адреса (ведь в ethernet, arknet, ... это делает аппаратура сетевого адаптера)?


Не только. Все-таки в стеке TCP тоже фигурирет MAC, на самом нижнем уровне(прием/доставка). Для этого и нужно.


Если "нет" (первый вопрос), то зачем им MAC? И опять же: кто их интерпретирует?


Это получается виртуальное сетевое устройство, обладающее всеми параметрами физического. Таким образом, машину можно подключить к локальной сети без сетевой карты. Это RAW протокол. Одно, кстати, из отличительных особенностей QNX.
К тому же, на этом устройстве ( а это может быть не только COM- порт, а LPT, да даже просто UNIX - сокет, или менеджер ресурсов, ЧТО УГОДНО!!!) можно поднять и Qnet (а он без MAC не работает ) и TCP и тот же PPP ( а нафига? PPP хорош для дальнобойных модемных соединений, где потери сигнала высокие ).

Да, кстати, немного грустный момент: похоже, что в поставкe 6.1 devn-fd.so не включен. У меня стоит 6.2бета, там я его сразу и нашел. Кому надо - пишите, пришлю. Есть версия и для 6.1, но в ее работоспособности я не уверен.

Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #8 : Марта 28, 2002, 05:18:00 am »

да даже просто UNIX - сокет, или менеджер ресурсов, ЧТО УГОДНО!!!)


Тут я погорячился. UNIX-сокет это быть не может. Любое символьное устройство.
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #9 : Марта 28, 2002, 05:42:00 am »


wind_alex пишет:
нет к одной линии нельзя подключить несколько
компов, но ничего не мешает вам соединить
их последовательно (com1(pc1) -> com1(pc2),com2(pc2) -> com1(pc3)) и т.д.
Только MAC адреса на com1(pc2) и com2(pc2) должны быть
разными, причем во всей сети (адреса не должны повторятся).

С MAC адресами (уникальность) это понятно.

Мне непонятно вот что:

МАС адрес - это адрес канального уровня, который передаётся (!) в пакете уровня канала (и, скорее всего, 2 MAC - источника и получателя). Формат канального пакета  должен определяться протоколом уровня передачи по каналу. К примеру, для Ethernet - это IEEE802.X.

Если в обсуждаемом варианте используется MAC, то:

- это не RS232 (я имею в виду именно RS232, как протокол на линии передачи, в отличии от интерфейса ser со стороны OS)?
- где описан (или упоминается) этот протокол канального уровня?
- кто (!) добавлет (удаляет) заголовки (MAC адреса и др.) при передаче (приёме)?
- в такой "цепочке" на каждом узле должен прописываться статический routing?

Например, в 802.Х - это должно выполнятся оборудованием MAC-уровня. В вашем случае - это функции программного обеспечения? драйвера? какого? devn-fd.so?

В HELP по devn-fd.so сказано - "интерфейс файл-дескрипторного устройства" (file descriptor interface driver), т.е. драйвер, использующий (любые?) устройства I/O (POSIX: open, read, write, ...)для передачи пакетов. Какой формат этих пакетов?

Это всё становится очень важно не в контексте первоначального вопроса, а для embedded систем!

А как это всё будет работать с serial мультипортовками? И, кстати, кто подскажет, как такая мультипортовка отображается в пространство имён?
 
Далее. Это всё относилось к RS232 (на линии). А если на линии RS485? Он (протокольно, кроме физического уровня) ничем не отличается от RS232. Более того, есть аппаратные трансмиттеры, цепляющиеся на стандартный выход RS232 и работающие в линию в RS485. А на линии RS485 может висеть много (! до 32) корреспондентов - каждый (на своём хосте) видимый как ser со своим MAC. Что тогда мешает devn-fd.so на каждом хосте работать со своим ser?

А если этот RS485 реализован на 4-х, 8-ми и т.д. канальной MOXA? То что мешает и роутить пакеты между 4-мя, 8-ю и т.д ветками RS485.

Так дальше пойдёт, мы и до CAN интерфейса доберёмся !
Записан
Pkun
Участник
*
Offline Offline

Сообщений: 1


Просмотр профиля
« Ответ #10 : Марта 28, 2002, 07:38:00 am »

Я не буду спорить, что в данном случае RS232 требует некоего "мнимого" MAC-адреса. Может и требует... Но не может быть, чтобы tcp/ip стек был завязан на MAC-адресах. MAC-адрес это принадлежность исключительно IEEE 802.x, т.е. Ethernet.
TCP/IP протоколы - протоколы более высокого уровня и им по-большому счету плевать на то, что делается в Ethernet. Для отслеживания получателя и отправителя у них есть свои IP адреса.
Кроме Ethernet есть и другие сети. Что ж, для них модуль tcp/ip перестанет работать вовсе?

А вот через RAW сокет действительно можно получать принятый пакет целиком. Вместе с MAC-адресами и т.д.
Записан
ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« Ответ #11 : Марта 28, 2002, 07:57:00 am »


Olej пишет:
Так дальше пойдёт, мы и до CAN интерфейса доберёмся !


Это все пробовать надо. Никто ж не гарантирует, что оно все так складно работать будет. И причем здесь CAN? Карточки для pc/pc104 есть с CAN коннектором (и контроллером), драйвера под QNX тоже вроде бы есть (про RTP не уверен)... Видел в и-нете... Денег, думаю, много стоит... )
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #12 : Марта 28, 2002, 09:56:00 am »

Я повторяюсь : MAC нужен для QNET. Думаю, QNET намного предпочтительней TCP/IP.
Вот, для тех кто не читал, статья: http://qnx.org.ru/docs/qnxnet.html
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #13 : Марта 28, 2002, 10:20:00 am »


Pkun пишет:
Я не буду спорить, что в данном случае RS232 требует некоего "мнимого" MAC-адреса. Может и требует... Но не может быть, чтобы tcp/ip стек был завязан на MAC-адресах. MAC-адрес это принадлежность исключительно IEEE 802.x, т.е. Ethernet.
TCP/IP протоколы - протоколы более высокого уровня и им по-большому счету плевать на то, что делается в Ethernet. Для отслеживания получателя и отправителя у них есть свои IP адреса. А вот через RAW сокет действительно можно получать принятый пакет целиком. Вместе с MAC-адресами и т.д.

Я об этом и говорил: только фиктивно MAC для последовательной линии не нужен, для этого есть IP. Если MAC нужен фиктивно и только для привязки к IP в командах установки типа:
io-net -d fd fd=/dev/ser1,mac=0123456789AB -p tcpip
ifconfig en0 10.184
- то это сильно мудрёно (избыточно), можно было сделать и попроще. Вот если MAC (или Mac-и источника и приёмника) передаются в линию в кадре RAW протокола - тогда всё естественно и понятно.

Кстати, небольшое уточнение, MAC-адрес - это не принадлежность исключительно IEEE802.X, это - принадлежность любого протокола канального уровня (в зависимости от вида сети: ArcNet, TokenRing, FDDI, Cambrige Ring ...). Обычно (почти всегда) это адрес, который распознаётся аппаратурой, реализующей канальный (MAC) уровень 7-ми уровневой модели ANSI. Но ничто не мешало бы, в принципе, добавлять/удалять заголовок с MAC и программному слою, тому же devn-fd.so (если MAC-и реально присутствуют в пакете передачи).

dm пишет:
Это RAW протокол. Одно, кстати, из отличительных особенностей QNX.

Оба вы упоминаете протокол RAW. Где есть его описание, или что-то об нём?
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #14 : Марта 28, 2002, 11:09:00 am »


Я об этом и говорил: только фиктивно MAC для последовательной линии не нужен, для этого есть IP.


Давай проведем экскурс в железо, потому что меня начал утомлять данный thread:

Чем отличается сетевая плата от последовательного интерфейса ? С точки зрения протоколов ? - ничем ! Производители сетевой платы просто сделали тебе услугу и сами сгенерили (из своих диапазонов) MAC. В случае же последовательного интерфейса - MAC задаешь ты сам. Тут я надеюсь споров не возникнет ?

Идем дальше. По своей природе стек IP не базируется на привязках к канальному адресу. Но существуют маппинги MAC-IP (ARP и RARP протоколы, эти протоколы лежат на одном уровне с IP).

Для того, чтобы стек IP работал по последовательному интерфейсу, самому интерфейсу нужно задать MAC. Для сведения: при поднятии PPP интерфейса обе стороны генерят себе MAC из свободного диапазона + время + некий рандом (это как должно быть).


Если MAC нужен фиктивно и только для привязки к IP в командах установки типа:
io-net -d fd fd=/dev/ser1,mac=0123456789AB -p tcpip
ifconfig en0 10.184
- то это сильно мудрёно (избыточно), можно было сделать и попроще.


Как проще ?


Вот если MAC (или Mac-и источника и приёмника) передаются в линию в кадре RAW протокола - тогда всё естественно и понятно.


Так и есть.


TokenRing, FDDI, Cambrige Ring ...). Обычно (почти всегда) это адрес, который распознаётся аппаратурой, реализующей канальный (MAC) уровень 7-ми уровневой модели ANSI.


Тут немного не так. Аппаратура получает все пакеты от всех (такова природа, за редким исключением) Есть т.н. promiscous mode в котором ты получаешь все пакеты от всех. Так вот услуга по распознаванию MAC - это всего-лишь услуга, а не обязанность аппаратуры канального уровня.


Но ничто не мешало бы, в принципе, добавлять/удалять заголовок с MAC и программному слою, тому же devn-fd.so (если MAC-и реально присутствуют в пакете передачи).


При составлении IEEE802.x фрэйма MAC адреса заполняются не канальным уровнем, а прикладным.


Оба вы упоминаете протокол RAW. Где есть его описание, или что-то об нём?


Про packet driver'а слышал в DOS'е ? Это интерфейс для RAW протокола, по сути RAW это есть твой IEEE 802.xy.

Попробуй почитать про Berkley packet filter (xBSD). там все очень хорошо описано.

P.S. на сайте www.ietf.org бесплатно пишут и раздают RFC )) Качаем, читаем, учим.

Записан

Страниц: [1] 2 3
  Печать  
 
Перейти в: