Страниц: [1] 2
  Печать  
Автор Тема: devn-fd  (Прочитано 11723 раз)
wind_alex
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« : Июня 06, 2002, 05:43:00 pm »

А не видел ли кто исходников subj?
Если видели может доведем до ума?

Достал этот драйвер в себе. Все работает, а информация не перекачивается. На всякий случай мой скрипт запуска

io-net -d rtl lan=0 -d fd fd=/dev/ser2,lan-1,mac=a2b2c2d2e2f2,wait -p tcpip forward -pqnet &
sleep 1
ifconfig en0 10.168.10.100 up
ifconfig en1 193.110.8.10 up

В /dev/io-net появляются en0 и en1, но пинг не идет, хотя статистика
утверждает что пакеты отправлены. У кого-нибудь nfp-bpf.so от
6.0 монтируется к io-net? у меня попытка монтирования приводит
к убиению io-net.

Может кто знает что-то аналогичное от BSD, естественно с исходниками?


Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #1 : Июня 06, 2002, 07:57:00 pm »


На всякий случай мой скрипт запуска

А на другой стороне какой скрипт ?

В /dev/io-net появляются en0 и en1, но пинг не идет, хотя статистика
утверждает что пакеты отправлены.

Пинг откуда куда не идет ?

у меня попытка монтирования приводит к убиению io-net.

А ты что хотел ?

Давай полную информацию а не куски ...
Записан

lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #2 : Июня 07, 2002, 03:54:00 pm »

Тут вот вспомнилось, по поводу ужасных MAC адресов, которые подсовываются драйверу devn-fd, вот пару цитат из стандарта:

Note that the first byte of the source address is always even (since the least significant bit, or first bit on the wire indicates that the address is a group address).

The destination address is a valid source address, except for an address which has the lowest bit of the first byte set to '1'. These addresses, including the all 1's broadcast address FF:FF:FF:FF:FF:FF and the set of multicast addresses, are point-to-multipoint addresses and can never appear as the source address in an Ethernet frame.

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


00000C  Cisco
00000E  Fujitsu
00000F  NeXT
000010  Sytek
00001D  Cabletron
000020  DIAB (Data Intdustrier AB)
000022  Visual Technology
00002A  TRW
000032  GPT Limited (reassigned from GEC Computers Ltd)
00005A  S & Koch
00005E  IANA
000065  Network General
00006B  MIPS
000077  MIPS
00007A  Ardent
000089  Cayman Systems  Gatorbox
000093  Proteon
00009F  Ameristar Technology
0000A2  Wellfleet
0000A3  Network Application Technology
0000A6  Network General (internal assignment, not for products)
0000A7  NCD             X-terminals
0000A9  Network Systems
0000AA  Xerox           Xerox machines
0000B3  CIMLinc
0000B7  Dove            Fastnet
0000BC  Allen-Bradley
0000C0  Western Digital
0000C5  Farallon phone net card
0000C6  HP Intelligent Networks Operation (formerly Eon Systems)
0000C8  Altos
0000C9  Emulex          Terminal Servers
0000D7  Dartmouth College (NED Router)
0000D8  3Com? Novell?   PS/2
0000DD  Gould
0000DE  Unigraph
0000E2  Acer Counterpoint
0000EF  Alantec
0000FD  High Level Hardvare (Orion, UK)
000102  BBN             BBN internal usage (not registered)
0020AF  3COM Huh?
001700  Kabel
008064  Wyse Technology / Link Technologies
00802B  IMAC Huh?
00802D  Xylogics, Inc.  Annex terminal servers
00808C  Frontier Software Development
0080C2  IEEE 802.1 Committee
0080D3  Shiva
00AA00  Intel
00DD00  Ungermann-Bass
00DD01  Ungermann-Bass
020701  Racal InterLan
020406  BBN             BBN internal usage (not registered)
026086  Satelcom MegaPac (UK)
02608C  3Com            IBM PC; Imagen; Valid; Cisco
02CF1F  CMC             Masscomp; Silicon Graphics; Prime EXL
080002  3Com (Formerly Bridge)
080003  ACC (Advanced Computer Communications)
080005  Symbolics       Symbolics LISP machines
080008  BBN
080009  Hewlett-Packard
08000A  Nestar Systems
08000B  Unisys
080011  Tektronix, Inc.
080014  Excelan         BBN Butterfly, Masscomp, Silicon Graphics
080017  NSC
08001A  Data General
08001B  Data General
08001E  Apollo
080020  Sun             Sun machines
080022  NBI
080025  CDC
080026  Norsk Data (Nord)
080027  PCS Computer Systems GmbH
080028  TI              Explorer
08002B  DEC
08002E  Metaphor
08002F  Prime Computer  Prime 50-Series LHC300
080036  Intergraph      CAE stations
080037  Fujitsu-Xerox
080038  Bull
080039  Spider Systems
080041  DCA Digital Comm. Assoc.
080045  Huh?? (maybe Xylogics, but they claim not to know this number)
080046  Sony
080047  Sequent
080049  Univation
08004C  Encore
08004E  BICC
080056  Stanford University
080058  Huh?             DECsystem-20
08005A  IBM
080067  Comdesign
080068  Ridge
080069  Silicon Graphics
08006E  Concurrent      Masscomp
080075  DDE (Danish Data Elektronik A/S)
08007C  Vitalink        TransLAN III
080080  XIOS
080086  Imagen/QMS
080087  Xyplex          terminal servers
080089  Kinetics        AppleTalk-Ethernet interface
08008B  Pyramid
08008D  XyVision        XyVision machines
080090  Retix Inc       Bridges
484453  HDS Huh?
800010  AT&T
AA0000  DEC             obsolete
AA0001  DEC             obsolete
AA0002  DEC             obsolete
AA0003  DEC             Global physical address for some DEC machines
AA0004  DEC             Local logical address for systems running DECNET

Записан

olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #3 : Июня 07, 2002, 04:29:00 pm »


wind_alex пишет:
А не видел ли кто исходников subj?
Если видели может доведем до ума?

Вопрос настолько актуален, что готов отложить остальное и заняться subj!

io-net -d rtl lan=0 -d fd fd=/dev/ser2,lan-1,mac=a2b2c2d2e2f2,wait -p tcpip forward -pqnet &
sleep 1
ifconfig en0 10.168.10.100 up
ifconfig en1 193.110.8.10 up

А теперь посмотри, кажется:
ifconfig -a
netstat -i
- цель, посмотреть MAC установленный интерфейсу. Похоже, что независимо от параметра mac=... там стоит одно фиксированное значение, или?
- далее, чего я не понимаю из написанного выше - как ip адреса которые мы видим попали интерфейсам? если бы ... -p tcpip if=en1:10.168.10 - именно так, и адрес и подсеть (маска), то понятно

В /dev/io-net появляются en0 и en1, но пинг не идет, хотя статистика
утверждает что пакеты отправлены.

Мы проделывали и обсуждали это в форуме раньше, и ни у кого - не шёл. И не может идти, я об этом напишу ниже.

У кого-нибудь nfp-bpf.so от 6.0 монтируется к io-net? у меня попытка монтирования приводит к убиению io-net.

Я не знаю, что такое "nfp-bpf.so от 6.0", но думаю, что имеется в виду Беркли пакетный фильтр для сетевого сниффера. Я для этой цели поставил tcpdump с этого форума (не без подсказок dmi, потому что *.qpr не ставится, и ставил я его разархивируя ручками), может nfp-bpf - jgbcrf? И BPF и сниффер и запускаются и работают, например так:
mount -T io-net /lib/dll/nfm-bpf.so
tcpdump -l -e -vvv -t | tee /tmp/sniff.dat

Как я понимаю из того, что написано, вы соединяете 2 компа /dev/ser2 <-> /dev/ser2? Простое прохождение байт по линии проверяли?:
cat XXX > /dev/ser2 - на 1-м компе
cat /dev/ser2 - на другом
... как вариант.

Запущены ли соответствующие (с согласованными параметрами) io-net, devn-fd ... на ОБОИХ компах. Если "да", то хотелось бы видеть команды на каждом, если "нет" - то кто же вам будет отвечать?

Это были вопросы для уточнения, а теперь по существу:

На это соображение натолкнул HEX пакет, который нарисовал в форуме Sergey, а dmi раскопал, что это (на приёмном конце - пакет ARP!!!).

Сделайте:
netstat -i
netstat -rn

я не знаю как эта хреновина будет выглядеть в форуме, но вот мой вывод, конечно сейчас без всяких fd, они сняты:

Name  Mtu   Network       Address              Ipkts Ierrs    Opkts Oerrs  Coll
lo0   32976 <Link>                               131     0      131     0     0
lo0   32976 loopback      localhost.localdo      131     0      131     0     0
en0   1500  <Link>        00:60:52:07:4f:4b      290     0      119     0     0
en0   1500  18/24         rtp.lot.kharkov.u      290     0      119     0     0

Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use    Mtu  Interface
default            18.0.0.110         UG          0        0      -  en0
18/24              18.0.0.15          U           1      113      -  en0
18.0.0.15          18.0.0.15          UH          0        0      -  lo0
127.0.0.1          127.0.0.1          UH          2      131      -  lo0


никакой ping (ни ICMP ни IP) не будут работать на вашем /ser - /ser канале, до тех пор, пока вы ручками не пропишете строчку в таблице маршрутизации, соответствующую этой подсетке (IP который вы определяли выше). Иначе (это было у всех, кто над этим бодался раньше, а таких уже немало) в моей например таблице - ВСЕ (в том числе и новой подсетки) пакеты пулять на default интерфейс (у меня 18/24) - и ... в мусор. Ваши ping не "не возвращаются", как я понимаю, они просто не идут в линию, а отправляются на default Etherner интерфейсв и там умирают.
Записан
DigiMind
Гость
« Ответ #4 : Июня 07, 2002, 04:45:00 pm »


никакой ping (ни ICMP ни IP) не будут работать на вашем /ser - /ser канале, до тех пор, пока вы ручками не пропишете строчку в таблице маршрутизации, соответствующую этой подсетке (IP который вы определяли выше). Иначе (это было у всех, кто над этим бодался раньше, а таких уже немало) в моей например таблице - ВСЕ (в том числе и новой подсетки) пакеты пулять на default интерфейс (у меня 18/24) - и ... в мусор. Ваши ping не "не возвращаются", как я понимаю, они просто не идут в линию, а отправляются на default Etherner интерфейсв и там умирают.

Я когда пробовал - добавлял роутинг прямо на соеседнюю машину "route add -host ...".
"Мeртвi бджоли не гудуть" ;(
Записан
wind_alex
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #5 : Июня 07, 2002, 06:21:00 pm »


lestat пишет:
Тут вот вспомнилось, по поводу ужасных MAC адресов, которые подсовываются драйверу devn-fd, вот пару цитат из стандарта:

Note that the first byte of the source address is always even (since the least significant bit, or first bit on the wire indicates that the address is a group address).

The destination address is a valid source address, except for an address which has the lowest bit of the first byte set to '1'. These addresses, including the all 1's broadcast address FF:FF:FF:FF:FF:FF and the set of multicast addresses, are point-to-multipoint addresses and can never appear as the source address in an Ethernet frame.
...


это очень похоже на правду, буду экспериментировать.
Насчет netstat -i давал netstat -a -n -i -r. принтаута сейчас нет под
рукой, но там все нормально.

Роутинг прописывается в файле /etc/net.cfg прогой под фотоном - ака network menager кажется. Настройки на машинах одинаковые, различие
только в IP адресах, использую приведенный скрипт.
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #6 : Июня 07, 2002, 06:24:00 pm »


DigiMind пишет:
Я когда пробовал - добавлял роутинг прямо на соеседнюю машину "route add -host ...".
"Мeртвi бджоли не гудуть" ;(

Т.е. собственно путь продвижения я вижу один: ставить tcpdump с двух концов (для чего я его и ставил и испытывал, как писал выше), сниффить пакеты с двух концов, и анализировать HEX-содержимое.

Иначе - мы в который раз топчемся на месте: очередной экспериментатор ставит то-же самое, и заканчивается ровно на том, что ... "не пролазит". Что не пролазит? Давайте дампы заголовков пакетов (или целиком пакетов) - и будем смотреть!
Записан
DigiMind
Гость
« Ответ #7 : Июня 07, 2002, 06:32:00 pm »


Т.е. собственно путь продвижения я вижу один: ставить tcpdump с двух концов (для чего я его и ставил и испытывал, как писал выше), сниффить пакеты с двух концов, и анализировать HEX-содержимое.

Иначе - мы в который раз топчемся на месте: очередной экспериментатор ставит то-же самое, и заканчивается ровно на том, что ... "не пролазит". Что не пролазит? Давайте дампы заголовков пакетов (или целиком пакетов) - и будем смотреть!

На каком участке? Мне показалось, что пакеты "пропадают" на уастке devn-fd->TCP/IP стек (я уже писал).
Записан
wind_alex
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #8 : Июня 07, 2002, 06:41:00 pm »


...
У кого-нибудь nfp-bpf.so от 6.0 монтируется к io-net? у меня попытка монтирования приводит к убиению io-net.

Я не знаю, что такое "nfp-bpf.so от 6.0", но думаю, что имеется в виду Беркли пакетный фильтр для сетевого сниффера. Я для этой цели поставил tcpdump с этого форума (не без подсказок dmi, потому что *.qpr не ставится, и ставил я его разархивируя ручками), может nfp-bpf - jgbcrf? И BPF и сниффер и запускаются и работают, например так:
mount -T io-net /lib/dll/nfm-bpf.so
tcpdump -l -e -vvv -t | tee /tmp/sniff.dat
...
[/quote]

именно про него и говорю, может разные версии? У меня
tcpdump-3.4-x86-public.qpr.
команда mount на tcpdump именно такая: mount -T io-net /lib/dll/nfm-bpf.so
Странно у меня поставился нормально??

ipfilter работает нормально,
включаю его так: mount -T io-net /lib/dll/nfm-ipfilter.so

В чем траблы?

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

Сообщений: 42



Просмотр профиля
« Ответ #9 : Июня 07, 2002, 08:43:00 pm »


wind_alex пишет:
В чем траблы?

Нет никаких траблов, просто у тебя первоначально было записано nfp-bpf.so (это наверное описка) - у меня - nfm-bpf.so. Всё, проехали.
Теперь, договорившись, что tcpdump-результаты у всех доступные - давайте смотреть форматы заголовков.
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #10 : Июня 07, 2002, 09:48:00 pm »


DigiMind пишет:
На каком участке? Мне показалось, что пакеты "пропадают" на уастке devn-fd->TCP/IP стек (я уже писал).

Давайте посмотрим, мы имеем цепочку (от 1-го компа до 2-го), может и не совсем так:
1-й комп
io-net -> стек -> devn-fd -> nfm-bpf -> /dev/ser -> линия ...
2-й комп
... линия -> /dev/ser -> nfm-bpf -> devn-fd -> стек -> io-net
- nfm-bpf конечно не является элементом, сквозь который проходит поток данных, но я его там показал как место подключения, он должен бы был выглядеть таким "тройничком" на tcpdump, но из меня плохой художник.

Если бы связь полностью (!) рвалась на участке devn-fd->TCP/IP (по крайней мере в двух направлениях), то Sergey не мог бы видеть на приёмном /dev/ser пакеты, которые dmi идентифицирует как ARP! (см. Встраиваемые системы > > TCP/IP over /dev/ser* - это очень важная информация).
Записан
wind_alex
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #11 : Июня 10, 2002, 12:18:00 pm »

из моих экспериментов ничего не вышло, но напрашиваются несколько выводов:

1) subj имеет много недокументированных опций настройки
  (одна из них   -r xxxxx - скорость утройсва на которое устанавливаем,
   добыта из use Net.fd).

2) ping не проходит из-за того, что в порт вообще ничего не передается,
  (достаточно дать cat -u /dev/ser1) на двух компах.

3) Olej немного не прав в своем рисунке nfm-bpf.so располагается
  между стеком TCP/IP и драйвером devn-fd и, следовательно, видит
  данные которыми обменивается стек и драйвер, но он не видит
  уходят ли эти данные дальше в линию.

4) у subj, похоже, все в порядке с приемом потому что
  запуск Net.fd, поднятие интерфейса и подача ping на
  тестовую машину приводят к появлению данных после devn-fd.
  Правда это не приводит более ни к чему.
  (cat -u /dev/ser1 показывает наличие приема данных)

Так что если хотим что-то из него получить то выходов 2:
1) посмотреть исходники (не реально)
2) запросить в QSSL настоящие опции драйвера, а не те которые
   он показывает.
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #12 : Июня 10, 2002, 03:38:00 pm »


wind_alex пишет:
3) Olej немного не прав в своем рисунке nfm-bpf.so располагается
  между стеком TCP/IP и драйвером devn-fd и, следовательно, видит
  данные которыми обменивается стек и драйвер, но он не видит
  уходят ли эти данные дальше в линию.

Это точно - относительно места перехвата пакетов?
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #13 : Июня 10, 2002, 03:39:00 pm »


wind_alex пишет:
3) Olej немного не прав в своем рисунке nfm-bpf.so располагается
  между стеком TCP/IP и драйвером devn-fd и, следовательно, видит
  данные которыми обменивается стек и драйвер, но он не видит
  уходят ли эти данные дальше в линию.

Это точно - относительно места перехвата пакетов?
Записан
wind_alex
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #14 : Июня 10, 2002, 07:04:00 pm »



Это точно - относительно места перехвата пакетов?



Мне так показалось и в DDK так написано
Записан
Страниц: [1] 2
  Печать  
 
Перейти в: