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

Сообщений: 42



Просмотр профиля
« Ответ #15 : Марта 28, 2002, 02:57:00 pm »


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

Прежде всего "я скорблю вместе с вами". Если ты так быстро устаёшь, то может - болен, и сходил бы ... отдохнул?

Этот ответ весь написан не по существу; он определённо не предназначался для того, чтобы внести ясность в предмет; содержит массу неточностей; наконец, из принципа "просто очень хотелось что-то сказать". И именно поэтому - заслуживает детального ответа.


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

Всем!

1.Не всякая среда передачи реализует все 7 уровней модели взаимодействия открытых систем ISO / OSI. Все регламентируемые стандартами последовательные протоколы RS232, RS422, RS423, RS485 ... определяют только стандарты физического уровня (открываем стандарты - смотрим: ни слова об уровне канала).

2.Все "сетевые" стандарты: Ethernet (RFC-894, RFC-895, RFC-948, RFC-1042), Token Ring (RFC-1112, RFC-1230, RFC-1231, RFC-1469, RFC-1513 ), FDDI (RFC-1103, RFC-1188, RFC-1329, RFC-1390) отличает то, что это протоколы группового разделения среды передачи. Они обязаны регламентировать "процедуру доступа" к среде передачи, т.е. полностью реализовывать канальный уровень (потому он ещё и называется уровнем соединения), и индивидуально идентифицировать MAC адреса.

3.Даже в тех достаточно редких случаях, когда "последовательный" интерфейс не владеет монопольно средой передачи: RS485 - до 32 устройств на линии, сам RS485 прототокол никак не регламентирует ни канальный уровень, ни механизм адресации канального уровня (MAC-адреса), оставляя их полностью на усмотрение реализатора.

4.Любой (!) механизм канального уровня для последовательных протоколов может быть только принятой в той или иной OS программной моделью канального уровня, никак не предопределяемой каким либо стандартом обмена.

5.В противоположность этому, в любой среде коллективного доступа канальный уровень и MAC-адресация регламентированы стандартом обмена и не может быть модифицирована.

Так что аналогии ... несколько притянуты, не правда ли?

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

Идём.

Стек IP не привязывается к адресам канального уровня, но пользуется ними, используя ARP & RARP (RFC-826, RFC-903, RFC-1027), которые уж никак не лежат на одном уровне с IP! Хотя бы из простого рассмотрения форматов ARP/RARP пакетов в сети, которые являются в чистом виде специфическими Ethernet-кадрами (или Token Ring & FDDI, соответственно). И, поскольку формат адреса в 3-х названных системах различается, то и форматы таблиц (кэшей) ARP различаются: какая уж тут независимость от канального уровня!


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

Для сведения: возможно обе стороны PPP и генерят себе что-то, что они называют MAC адресами, но при обмене по каналу эти адреса не фигурируют. Это определяется стандартами протоколов инкапсуляции IP: как SLIP (RFC-1055, RFC-1144), так и PPP (RFC-1134, RFC-1171, RFC-1172, RFC-1331, RFC-1332, RFC-1547, RFC-1548, RFC-1661). Вот полный формат передаваемого PPP-кадра:

Flag           - 1 байт - всегда '01111110'
Address     - 1 байт - всегда '11111111'
Control       - 1 байт - всегда '00000011'
Protocol     - 16 бит - 0x0021 для IP
Information - var -
FCS          - 32 бит -
Flag          - 1 байт - всегда '01111110'

И дословно фраза из RFC: "PPP не присваивает индивидуальных адресов станциям".


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

Так и есть.

Но ни один из инкапсулирующих IP для сериальных линий протоколов (RFC стандартизованных) этого не делает.


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

Тут действительно "не так", но не немного. Если аппаратурой мы называем входной трансформатор Ethernet, или, на худой конец, приёмный буфер "в лёт" физического уровня, то, действительно - каждый адаптер получает пакеты от каждого ("такова природа", как было сказано, и я бы даже добавил "электромагнетизма"). Но если в качестве аппаратуры мы рассматриваем всё, что за приёмным буфером (а это существенно большая часть "аппаратуры"), то ни один пакет не проскочит далее, если его адрес получателя отличается от MAC-адреса адаптера (за исключением единственного широковещательного адреса: 6 раз по FF).

Кстати, я по первому образованию радио-физик, и занимался разработкой схемотехники сетевых адаптеров во ВНИИ РТ г.Москва, так что про аппаратуру ты мне можешь "резать правду матку", не смущайся - я пойму.

Дальнейшее изложение, по моему, просто приближается по своему накалу к вершинам теософской мысли раннего средневнковья: "сколько демонов разместяться на одном конце иглы?". Распознавание МАС-адреса можно считать хоть услугой, хоть обязанностью, хоть сервисом ... чем ещё? канального уровня. Но если это делает оборудование - то оно реализует протокол канального уровня, требуемый RFC, а если не делает - то у тебя просто нет канального уровня, нет стандарта и нет протокола!


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

Здесь мне к слову вспомнился анекдот, когда студентка на экзамене описывала половой член: "ну ... в длину - 50 сантиметров, в диаметре - 10, а внутри - кость!". Професор в задумчивости чешет затылок: "Ну... с длиной вам просто повезло, с диаметром - показалось, а вот на счёт кости - тут вы просто ошибаетесь".

Так вот - тут ты просто перепутал: MAC-адреса Ethernet-кадра заполняет только канальный уровень (и никакой уровень выше об них вообще ничего не знает), а прикладной уровень (ну, не совсем прикладной, а транспортный) - так это он порты TCP/UDP заполняет.


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

Уже почитал, спасибо. Как и весь цитируемый ответ этот материал не имеет никакого отношения к рассматриваемому вопросу.


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

Да как-то читали и читаем. Только когда дают ссылку на RFC (по крайней мере, когда это делается с намерением подсказать источник, а не попонтоваться) то указывают номер RFC, сам то ты хоть знаешь их число?

И последнее...
Нет, последнее не буду, разве что о-о-о-о-чень меня разозлишь.
Записан
Sergey
Гость
« Ответ #16 : Марта 28, 2002, 05:00:00 pm »

Записан
Sergey
Гость
« Ответ #17 : Марта 28, 2002, 05:23:00 pm »

Извините,но мне тоже интересно.
Olej- когда кончаются аргументы-сжимаются кулаки.
У нас задача пропихнуть IP по последовательному порту.
IP можно завернуть в PPP-SLIP и бросить в порт. Все.
Но если как предлагает dmi (прийду с работы попробую)
то надо сэмитировать сетевую карточку. ARP ни кто не отменял.
Пакет нельзя просто кинуть в порт, а есть там кто на другом
конце и он-ли ето... IP-адрес - это логический адрес.
В локальной сети все машины должны иметь уникальный Физический адрес: MAC, независимо две машины или больше. ARP сопоставляет
IP -> MAC.
Для этого он нам и нужен(MAC-адрес).А 232, 485 да хоть токовая петля, это всего-лиш железо.

[addsig]
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



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

OFF-TOPIC


Sergey пишет:
Olej- когда кончаются аргументы-сжимаются кулаки.

Это не совсем так. У нас на qnx.org.ru никогда (сколько я помню) не было а-ля линуксовой тусовки: либо предлагай информацию конкретно по вопросу, либо ... пойди отдохни. Если тенденции тусовки возобладают - тогда этому сайту, в том виде, в котором он существовал, конец. Мне лично он такой не нужен. Я как-то в программинге 25 лет прожил, и дальше ..."Бог не выдаст свинья не съест". А такого (редкого на общем фоне)  конструктивного и расположенного к взаимному сотрудничеству сайта - жалко.

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

Сообщений: 469



Просмотр профиля
« Ответ #19 : Марта 28, 2002, 06:25:00 pm »

Sergey: если будут проблемы(весьма вероятно) или результаты(тоже весьма вероятно) - опишите здесь. Будем работать над занесением этой информации в нашу "копилку"


Olej- когда кончаются аргументы-сжимаются кулаки.

А причем тут Olej ? Первым не выдержал Майк

[ Это Сообщение было отредактировано: dmi в 2002-03-28 15:27 ]
Записан
Evgeniy
Jr. Member
**
Offline Offline

Сообщений: 73


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

Уважаемые господа!
Попробую внести некоторую, как мне кажется, ясность в общетеоретическую часть [надеюсь еще] обсуждения .

Дело в том, что для TCP/IP стека (полного стека протоколов, включая сюда и ARP) физическое оборудование и программный драйвер устройства функционально неразделимы - надеюсь, что это для всех очевидно. Под драйвером здесь я понимаю всю цепочку драйверов псевлоустройств и физического устройства, к которой обращаются модули стека протокола как к "физическому" устройству - в данном случае оконечной частью этой цепочки для TCP/IP будет модуль devn-fd.so

Для нормального, а не фрагментарного функционирования всего стека необходимо наличие MAC-адреса, предоставляемого КОМПЛЕКСОМ "устройство + физический драйвер + все программные прослойки, маскирующие реальное устройство".
И совершенно не важно где там внутри и как он будет сформирован. Единственное трбование заключается в том, чтобы на всех машинах, подключенных к общей сети передачи (в данном случае на соединении точка-точка через RS-232) работали согласованные версии этой связки "устройство + драйвер +...".
И я не вижу никакой крамолы в том, что в QNX devn-fd может (проверка покаже может ли) эмулировать для стека поведение сетевого адаптера на RS-232. Единственное чего в этом случае нельзя ожидать (и требовать), что такое соединение будет работоспособно для связи "QNX-NotQNX".

Так что, если devn-fd работает таким образом, то можно только порадоваться за разработчиков QNX, нашедших, как мне кажется, очень элегантное решение для обеспечения прозрачной работы TCP/IP на практически произвольном связном оборудовании
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #21 : Марта 29, 2002, 05:23:00 am »


Стек IP не привязывается к адресам канального уровня, но пользуется ними, используя ARP & RARP (RFC-826, RFC-903, RFC-1027), которые уж никак не лежат на одном уровне с IP! Хотя бы из простого рассмотрения форматов ARP/RARP пакетов в сети, которые являются в чистом виде специфическими Ethernet-кадрами


Ты надеюсь понял, что сам ответил на свой же запрос: ARP - это специфический ethernet frame, IP - тоже специфический фрэйм.
Если не веришь, то открой /etc/protcols и смотри, ну что есть там арп, нет ? Какая жалость.


(или Token Ring & FDDI, соответственно). И, поскольку формат адреса в 3-х названных системах различается, то и форматы таблиц (кэшей) ARP различаются: какая уж тут независимость от канального уровня!


ARP - это объединение группы под одним имененем. Для каждой физики свой тип пакета.


Flag           - 1 байт - всегда '01111110'
Address     - 1 байт - всегда '11111111'
Control       - 1 байт - всегда '00000011'
Protocol     - 16 бит - 0x0021 для IP
Information - var -
FCS          - 32 бит -
Flag          - 1 байт - всегда '01111110'

И дословно фраза из RFC: "PPP не присваивает индивидуальных адресов станциям".


Ты право меня умиляешь    А тебе известно, что PPP - это урезанный SDLC(HDLC). Все пакеты заворачиваются в PPP фрэймы для транспортировки. В заголовке и не может быть MAC. А твой Flag это 0x7E - есть вообще аппаратно реализованный флаг начала стрима и конец стрима.


Так вот - тут ты просто перепутал: MAC-адреса Ethernet-кадра заполняет только канальный уровень (и никакой уровень выше об них вообще ничего не знает), а прикладной уровень (ну, не совсем прикладной, а транспортный) - так это он порты TCP/UDP заполняет.


А я тебе и не говорил, что IP уровен заполняет MAC   И перестань говорить все время про модели OSI. Это мне напоминает про институтские годы, там все время это в голову забивали, но правда - она другая. Я тебе могу привести множество систем, которые просто ложить хотели на 7 моделей. Взять тот же PPP Или нет, еще круче PPP over Ethernet ? А где твои модели ?


Уже почитал, спасибо. Как и весь цитируемый ответ этот материал не имеет никакого отношения к рассматриваемому вопросу.


Жаль, что ты так и не понял ...


Да как-то читали и читаем. Только когда дают ссылку на RFC (по крайней мере, когда это делается с намерением подсказать источник, а не попонтоваться) то указывают номер RFC, сам то ты хоть знаешь их число?


Мне весь разговор с тобой напоминает спор о бананах с теми кто их ел.

Ты уж меня извини, но я просто реализовывал IP, PPP, SDLC, BSC(1-3) и знаю все не из теории. А вот количество RFC номеров, я не знаю, прости меня ламера не успеваю я их считать, не в количестве крутость, а в знании хотя бы малого количества.

P.S. И пожалуйста не упоминай больше про 7 моделей ОСИ, потому что я уже и так вдоволь посмеялся
Записан

wind_alex
Участник
*
Offline Offline

Сообщений: 0


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

Я вчера хотел кинуть ответ в форум, но не получилось.
TCP/IP на MAC адрес наплевать.
На сколько я понял из документации по Network DDK,
сетка в QNX работает так:
send(TCP/IP)-> стек TCP/IP ->io-net ->[фильтр]-> драйвер
сетевой карты или любого устройства,понимающего
формат пакета -> собственно отправка.
Так вот devn-fd MAC нужен только для того, чтобы не
обрабатывать весь трафик, проходящий через управляемое им
устройство(пример с RS4..). Это не более чем фильтр
на приеме. Именно так работает MTP уровень телефонной сигнализации ОКС №7(SS7).
Записан
DigiMind
Гость
« Ответ #23 : Марта 29, 2002, 06:42:00 am »

Да. Особые иконки напротив тредов очень помогают в идентификации "горячих" тредов .
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


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


Я вчера хотел кинуть ответ в форум, но не получилось.
TCP/IP на MAC адрес наплевать.


TCP/IP - да, но он не может существовать без канала. В твоем рисунке, маком занимается io-net. Оно и есть согласующее звено между MAC и IP address.


send(TCP/IP)-> стек TCP/IP ->io-net ->[фильтр]-> драйвер
сетевой карты или любого устройства,понимающего
формат пакета -> собственно отправка.



Так вот devn-fd MAC нужен только для того, чтобы не
обрабатывать весь трафик, проходящий через управляемое им
устройство(пример с RS4..). Это не более чем фильтр
на приеме. Именно так работает MTP уровень телефонной сигнализации ОКС №7(SS7).


Спору нет, но не только фильтр, а еще и для того, чтобы осуществлять правильный роутинг между интерфейсами.

Например такая схема:

Computer имеет devn-* (ethernet) (10.32.0.1) и devn-fd (10.32.1.1) и внешняя сеть от каждого устройства.

Данные приходят с 10.32.0.2 -> 10.32.0.1, forwarding btw interfaces -> 10.32.1.1 -> 10.32.1.2

Связующее звено есть такое IP <-> MAC <-> interface, т.е. MAC есть ничто иное, как связка интерфейса устройства и IP адреса.

Можно конечно обойтись грубо и во внутренних таблицах связывать напрямую IP <-> if. Но некоторые лакомые кусочки, например proxyarp в PPP не будет работать при такой схеме. А мне, например, такая штучка нравиться. Если к примеру добавить в выше указанную схему еще и dial-up, то можно заставить форвардить пакеты, эмулируя ethernet и к примеру использовать драйвер devn-fd для эмуляции гомогенных сетей, т.е. dial-up будет выглядить как часть внутренней сети.


Записан

Pkun
Участник
*
Offline Offline

Сообщений: 1


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

Если еще интересно про raw сокеты, то смотрите в man там где про PF_INET и т.д. Объявляется это дело таким образом
s = socket(PF_PACKET,SOCK_RAW,htons(ETH_P_ALL));

получается пакетный драйвер. Из него можно читать и писать в него Ethernet-пакеты.
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



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


Pkun пишет:
Если еще интересно про raw сокеты, то смотрите в man там где про PF_INET и т.д. Объявляется это дело таким образом
s = socket(PF_PACKET,SOCK_RAW,htons(ETH_P_ALL));


Это работает только при подключенном модуле npm-bpf.so из пакета IPFilter.
У меня он вышибает io-net ( с драйвером rtl )
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #27 : Марта 29, 2002, 08:30:00 am »


Pkun пишет:
Если еще интересно про raw сокеты, то смотрите в man там где про PF_INET и т.д. Объявляется это дело таким образом
s = socket(PF_PACKET,SOCK_RAW,htons(ETH_P_ALL));

Это работает только при подключенном модуле npm-bpf.so из пакета IPFilter.
У меня он вышибает io-net ( с драйвером rtl )


В rtl'ках плохо, вернее криво реализован promiscous mode в сетевухах. (Кстати если сетевая 8139A, а не 8139C, то там очень много аппаратных ошибок). Кстати MAC можно менять во время работы через bpf, правда не знаю, на сколько QSSL качественно перетащила код из BSD bpf и оставили ли они там эту возможность.
Записан

DigiMind
Гость
« Ответ #28 : Марта 29, 2002, 08:46:00 am »


правда не знаю, на сколько QSSL качественно перетащила код из BSD bpf и оставили ли они там эту возможность.

Куда и что перетащила? IPFilter разве "by QSSL"?
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


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


DigiMind пишет:

правда не знаю, на сколько QSSL качественно перетащила код из BSD bpf и оставили ли они там эту возможность.

Куда и что перетащила? IPFilter разве "by QSSL"?


QSSL взяла код NetBSD и перетащила весь стек протоколов от туда, включая и bpf ...
Записан

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