Эмуляция сети
 

Ну, снаружи эмулятора я могу WinPcap подключить, а какое железо внутри эмулировать? Надеюсь, не на уровне электрических сигналов Tx/Rx витой пары? :)
Хотя, WinPcap позволяет только слушать, надо будет ещё какой-то пакетный фильтр найти, с возможностью отправки...

---------- Post added at 18:37 ---------- Previous post was at 18:08 ----------

Есть ещё TAP win32 driver из OpenVPN, но с ним тоже разбираться надо. К тому-же, этот драйвер ещё сначала инсталлировать надо.

Эмулируй любой чип, реализующий MAC+PHY. В его типовом включении (только чтобы без всяких ДМА, т.к. на реале такое не полетит). Здесь самое сложное не чип эмулировать или какие-то конкретные порты (а посему не сложно и другие аналогичные чипы эмулировать когда один любой отладишь), а движок самого эмулятора, реализующий физику LAYER2 и ниже. Ведь надо "выпустить" твой виртуальный адаптер эмулятора во внешнюю сеть, чтобы оно нормально коммуницировало с прочим сетевым оборудованием. Чтобы Z80-код IP-стека, выполняемый в эмуляторе, нормально обменивался с прочими хостами в реальной сети.
И да, WinPcap не годится. Полгода назад когда я это обдумывал, ничего более подходящего чем TAP от OpenVPN мне не придумывалось (чтобы уже не всё писать самому, что совершенно неподъемно, а использовать что-то готовое).

Я с TAP от OpenVPN не разбирался, но по-моему он как раз и реализует "физику LAYER2 и ниже", раз уж это виртуальный сетевой адаптер. Как я полагаю, он позволяет отправлять и принимать "сырые" пакеты. А это именно то, что и будет считано/передано через порты "виртуального" чипа внутри эмулятора.

Да. Только всю эту "физику" надо правильно настроить (тот самый виртуальный коммутатор TAP-адаптеров, который надо не только сам настроить, но еще и настроить для него роутер во внешнюю - реальную - сеть). Также надо API, через которое ты с этим адаптером будешь общаться из эмулятора - под NT и ее клонами работать с устройствами такого класса можно только из драйвера, никак не из приложений. То есть нужен драйвер. Я там тому назад предлагал для этого пользоваться драйвером NDIS (конкретно - уже готовый ndisprot, пример использования есть).

Таким образом, как минимум нужна методичка объясняющая назначение всех этих подсистем, и как все это инсталлировать и настраивать, т.к. пользователи, просящие "раскрасить дебугер" сами до этого никогда не допрут. В понятном виде. Я на что уж сам писатель... был..., но твои конфиги до сих пор не осилил. :)

И вот уже всю эту кучу надо увязать в концепции эмулятора и попутно съэмулировать "точку входа" в это безобразие в виде какого-нить Ethernet-чипа в типовом включении (что-нить простое типа RTL8019as или DP8390D).

Т.е. вырисовывается задачка не скажу что грандиозная, но внушает... :)
Сложная, но нужная... Как то так....

Насколько я понял, ndisprot позволяет отправлять и принимать данные непосредственно через имеющуюся сетевую карту (правда, не совсем понятно, как будет обрабатываться входящий траффик по IP - будет он передан только обработчику протокола IP или же обеим обработчикам, и можно ли установить два обработчика протокола IP). Правда, в таком случае у нас не получится соедениться с программами, работающими на том-же компьютере, что и эмулятор. Можно, конечно, установить loopback-адаптер, но будет ли это работать, сказать сложно.

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

Вобщем, всё зависит от того, что мы хотим: чтобы эмулятор работал с программами и сервисами на том-же компьютере, или чтобы эмулируемый компьютер взаимодействовал с другими компьютерами в сети.

Я, правда, не совсем понимаю, как это сделано в VMware - там гостевая ОС может работать и с хостом, и с другими компьютерами в сети.

Я себе представлял так:

[Эмулятор->NDIS]->[[TAP1<-бридж->TAP2]->router->realEth]->внешняя сетка

Здесь адаптеры TAP1, TAP1 и виртуальный свитч (бридж) образуют IP-подсеть 1. Наш PC работает роутером из подсети 1 в подсеть 2 куда входит реальный адаптер realEth. Соответственно:
- на адаптере TAP1 кодом Z80 эмулятора через NDIS устанавливается МАС и настраивается IP из сетки1.
- На адаптере realEth средствами Винды настраивается IP из сетки2
- на адаптере TAP2 средствами Винды настраивается IP из сетки1 (типовой случай с РС-роутером, который смотрит двумя адаптерами - TAP2 и realEth - в две сетки)

Как я понимаю, TAP-адаптеры никак не привязаны к IP (LAYER3), они эмулируют на уровне MAC (LAYER2). Хочешь, можно вообще на них IP не поднимать, а поднять что-то другое. Соответственно, в адаптер TAP1 мы можем из эмулятора через NDIS дуть голыми пакетами, которые полностью программно формируются стеком IP, реализованным на Z80 (т.е. они не голые на самом деле, а содержат все нужные структуры для IP). И нормально получать ответы в виде голых же пакетов LAYER2 (это нам обеспечит виртуальный свитч - ему достаточно знать МАС-и TAP1 и TAP2 чтобы понимать что от кого и кому слать).

Сейчас ковыряю, наделал ТАР-ов, пока не понятно что к чему. При создании бриджа ТАР-ы (до того отдельные девайсы со своими MAC) перестают енумероваться по-отдельности, вместо них енумеруется только бридж с единственным MAC-ом. Надо подумать отчего так... :)

Как-то сложно ты всё представляешь :)
На мой взгляд есть 2 варианта:
1. эмулятор -> ndisprot.sys -> NDIS -> минидрайвер реальной карты -> внешняя сеть
2. программы на локальном PC <- winsock <- tcpip.sys <- NDIS <- tap0801.sys <- эмулятор

В первом случае, для взаимодействия с программами на локальном PC нужен loopback-адаптер.
То есть получится так: эмулятор -> ndisprot.sys -> NDIS -> loopback-адаптер -> NDIS -> tcpip.sys -> winsock -> программы на локальном PC

Во втором случае, для выхода во внешнюю сеть нужен сервис, который будет осуществлять роутинг (на уровне IP) между реальной сетевой картой и tap0801.sys
То есть так: эмулятор -> tap0801.sys -> NDIS -> tcpip.sys -> router service -> tcpip.sys -> NDIS -> минидрайвер реальной карты -> внешняя сеть

В первом случае на этом физическом адаптере возможна или работа эмулятора, или работа всех прочих IP-программ Винды. Потому что NDIS - это то что "раньше" всего стека IP, доступ к LAYER2 минуя весь стек IP. В параллель два стека (эмуляторский и виндовый) на одном физическом (или виртуальном) приборе канального уровня (MAC) работать не могут.

Второй случай невозможен, потому что через NDIS (не через TAP, TAP это уже ниже NDIS, это сам адаптер, как я понимаю, к которому доступ должен быть через драйвер - NDIS в нашем случае) ты опять же выведешь пакет в канальный уровень. Оттуда этот пакет может быть передан только на другой адаптер. Этот другой адаптер, получив пакет LAYER2, уже "дернет вверх" всю цепочку уровней протокола IP (LAYER3 и выше - TCP/UDP). И вот на этом, другом адаптере уже может жить router, потому что router - это понятие уровня LAYER3.

loopback-интерфейс вообще никогда не пропускает пакеты на уровень LAYER2 (куда мы ходим при помощи NDIS). Пакеты разворачиваются "сами на себя" на уровне LAYER3.

Есть подозрение, что если к сетевой карте привязаны два протокола, то входящие пакеты NDIS будет дублировать для обоих обработчиков протокола. А обработчики должны "отвечать" только на "свои" пакеты.

Я не понял, так ты разобрался, как работать с TAP-драйвером? Или всё-таки нет?

По моему ты путаешь loopback-интерфейс и localhost с адресом 127.0.0.1. Обращения к localhost действительно обрабатываются на уровне tcpip.sys, а loopback-интерфейс выглядит для системы как сетевая карта, которая возвращает все посланные пакеты обратно.

Пока нет.
Но других путей не вижу.
Все виртуалки на РС (которые по сути - эмуляторы) работают с сеткой через TAP или его проприетарный аналог.

---------- Post added at 23:29 ---------- Previous post was at 22:11 ----------

Дык никто не понимает. Надо разбираться. :)

---------- Post added 15.02.2011 at 00:46 ---------- Previous post was 14.02.2011 at 23:29 ----------

Некоторые приемы работы с TAP прогуглил. Ничего особенного - открыл, читаешь/пишешь. :)
http://www.rsdn.ru/forum/network/3842938.flat.aspx
http://www.rsdn.ru/forum/winapi/2724711.aspx

А вообще, все сразу посылают в исходники OpenVPN - дескать "иди и смотри".

А сама концепция пока не ясна. Неясно главным образом почему при объединении в бридж, и реальные адаптеры и TAP-ы перестают энумероваться (например из NDIS по ndisprotQueryBinding, да везде - даже по ipconfig, т.е. по GetAdaptersInfo) .

Ну, тоесть в man-ax на OpenVPN конечно написано, что в Винде после объединения в бридж адаптеры теряют идентичность, и "сущность адаптера" остается только у бриджа, но нафига это так сделано и как это уложить в башке - пока не понятно. Что самое интересное, в Линухе виртуальные адаптеры после объединения в бридж никуда не деваются, как это происходит в Винде.

Поэтому, хотя с бриджем было бы и проще (если бы оно работало как я представляю себе), но схема по прочтении людей по ссылкам похоже вырисовывается такая (несколько отличается от того что я сочинял двумя постами ранее):

Как видим, никакого NDIS.
А РС, на котором будет работать эмулятор, сам будет роутить из сети где находится TAP1 в сеть реального адаптера, надо только галку поставить где надо. Или не ставить, если выход во внешнюю сеть не нужен - тогда взаимодействующий IP-софт (telnet, к примеру) просто запускаем на своем же РС - там же где и эмулятор, натравив его на TAP1.
При этом TAP1 не обслуживается двумя стеками. "IP-стек кода на Z80" транслируется на выходе эмулятора в вызовы WinAPI, которые просто являются симметричной ответной частью для IP-стека Винды (имитирую ответные-парные "отправки и прием пакета" в/из эмулятор).