Страниц: [1] 2 3 ... 5
  Печать  
Автор Тема: TCP/IP over /dev/ser*  (Прочитано 38375 раз)
Sergey
Гость
« : Апреля 05, 2002, 05:52:00 pm »

Привет всем.
Я изменил сообщение (я там гнал,извиняюсь:)

Дело в том, что если направить на одной машине io-net через devn-fd на /dev/ser* и запустить пинг, а на другой машине сделать cat /dev/ser* то на экране мы увидим пакеты размером 42байта примерно следующего содержания:
FF FF FF FF FF FF 01 23 45 67 89 AB 08 06 00 01 08 00 06 04 00 01 01 23 45 64 89 AB C0 A8 64 01 00 00 00 00 00 00 C0 A8 64 02
Вот.
машина с которой запускал пинг:
mac=0123456789AB
en0:192.168.100.1
У другой:
mac=0123456789AC
en0:192.168.100.2

Обратите внимание, в пинге два раза указан мак-адрес машины отправителя. Щас под рукой у меня нет формата пинга, попозже гляну.

P.S. ping назад не возвращается

Пока все.

P.S.s. да, у кого есть QNX 6.2 бросьте мне devn-fd плизз. Ну чтоб время зря не терять. Вдруг это он виноват.


[ Это Сообщение было отредактировано: Sergey в 2002-04-07 21:35 ]
Записан
Sergey
Гость
« Ответ #1 : Апреля 08, 2002, 01:11:00 am »

Это так, чтоб заглянули
[addsig]
Записан
wind_alex
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #2 : Апреля 08, 2002, 03:00:00 am »

На сколько я понимаю тема выросла из "пром. интерф.".
Я предыдущих темах я об этом и говорил - MAC devn-fd нужен
как входной фильтр. А пинг не возвращается потому что не
прописана маршрутизация и вообще не ясна топология
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #3 : Апреля 15, 2002, 02:40:00 pm »


Sergey пишет:
Дело в том, что если направить на одной машине io-net через devn-fd на /dev/ser* и запустить пинг, а на другой машине сделать cat /dev/ser* то на экране мы увидим пакеты размером 42байта примерно следующего содержания:
FF FF FF FF FF FF 01 23 45 67 89 AB 08 06 00 01 08 00 06 04 00 01 01 23 45 64 89 AB C0 A8 64 01 00 00 00 00 00 00 C0 A8 64 02
Вот.
машина с которой запускал пинг:
mac=0123456789AB
en0:192.168.100.1
У другой:
mac=0123456789AC
en0:192.168.100.2

1.Подробнее - чем и как смотрели пакеты "размером 42байта" на /dev/ser* (пакеты то бинарные, на экране - мусор)?
2.Как ставился mac на интерфейсах? И проверялся ли (что выставлен), например ifconfig?
Записан
Sergey
Гость
« Ответ #4 : Апреля 21, 2002, 01:54:00 pm »

Привет.
Уезжал в Красноярск к жене на защиту диплома, защитила на отлично

1.Подробнее - чем и как смотрели пакеты "размером 42байта" на /dev/ser* (пакеты то бинарные, на экране - мусор)?


cat /dev/ser1 > ping.bin
Кидаю несколько пингов и ковыряю ping.bin.

2.Как ставился mac на интерфейсах? И проверялся ли (что выставлен), например ifconfig?


io-net -d fd fd=/dev/ser1,mac=0123456789AB -P .......
ifconfig проверял, криминала невидел но что конкретно щас нескажу, попозже.



_________________
С уважением,
        Sergey.

[ Это Сообщение было отредактировано: Sergey в 2002-04-21 10:55 ]
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #5 : Апреля 24, 2002, 05:07:00 am »


Sergey пишет:
cat /dev/ser1 > ping.bin
Кидаю несколько пингов и ковыряю ping.bin.

Это первое, что приходит на ум, и я это делал, но у меня не получается, и вот почему: поток в ping.bin буферизуется, а как его сбросить (flush) в файл. Т.е. закрыть (close) этот файл? Иначе - он 0-длины! Подробнее pls.
Записан
ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« Ответ #6 : Апреля 24, 2002, 08:43:00 am »


Olej пишет:

Sergey пишет:
cat /dev/ser1 > ping.bin
Кидаю несколько пингов и ковыряю ping.bin.

Это первое, что приходит на ум, и я это делал, но у меня не получается, и вот почему: поток в ping.bin буферизуется, а как его сбросить (flush) в файл. Т.е. закрыть (close) этот файл? Иначе - он 0-длины! Подробнее pls.


sync и ждать секунд пять. Но сомневаюсь, что в этом проблема.
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #7 : Апреля 24, 2002, 09:28:00 am »


ed1k пишет:
sync и ждать секунд пять. Но сомневаюсь, что в этом проблема.

Можно пять раз sync и ждать одну секунду, один хрен Открой этот нулевой файл в другой консоли - там будет инфа, если хоть что-то было туда записано ...


[ Это Сообщение было отредактировано: lestat в 2002-04-24 06:32 ]

[ Это Сообщение было отредактировано: lestat в 2002-04-24 06:35 ]
Записан

Sergey
Гость
« Ответ #8 : Апреля 26, 2002, 07:01:00 am »

Некаких sunc_ов дажет неделаю.
Отстреливаю  cat /dev/ser1 > ping.bin  по  Ctrl +C
И все. Открываю и ковыряю.
[addsig]
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #9 : Апреля 26, 2002, 12:42:00 pm »


Sergey пишет:
Привет всем.
Я изменил сообщение (я там гнал,извиняюсь:)

Дело в том, что если направить на одной машине io-net через devn-fd на /dev/ser* и запустить пинг, а на другой машине сделать cat /dev/ser* то на экране мы увидим пакеты размером 42байта примерно следующего содержания:
FF FF FF FF FF FF 01 23 45 67 89 AB 08 06 00 01 08 00 06 04 00 01 01 23 45 64 89 AB C0 A8 64 01 00 00 00 00 00 00 C0 A8 64 02
Вот.
машина с которой запускал пинг:
mac=0123456789AB
en0:192.168.100.1
У другой:
mac=0123456789AC
en0:192.168.100.2

Обратите внимание, в пинге два раза указан мак-адрес машины отправителя. Щас под рукой у меня нет формата пинга, попозже гляну.



Это IMHO не ping, это ARPA. Расшифровывается примерно так:
01:23:45:67:89:AB | ARPA Broadcast : 42 | 192.168.0.1 who has IP 192.168.0.X tell 192.168.0.1
Широковещательные ARPA запросы как раз и занимали у меня 42 байта.

ping определить очень просто - ping -p 4141414141414141414 -c 10 10.xx.xx.xx

Во-первых, МАС должен начинаться с нулевого байта, т.е 00:12:34:56:...
Во-вторых, IP партнера по соединению должен быть прописан в ARP :
arp -s PARTNER_IP PARTNER_MAC
( Иначе он его не видит, на 'arp -a' говорит 10.0.0.5 (incomplete) ).

У меня все равно пока ничего не получилось - пакетики с завидным упорством отбрасываются io-net.
Пока разбираюсь. Напишу как что-нибудь получится.

P.S. Запросы на соединения, SYNC, ICMP и т.д. уже вижу в /dev/ser, но TCP стек говорит, что пакеты некорректны
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #10 : Апреля 26, 2002, 12:49:00 pm »


Olej пишет:

1.Подробнее - чем и как смотрели пакеты "размером 42байта" на /dev/ser* (пакеты то бинарные, на экране - мусор)?


cat < /dev/ser1 > /tmp/1.bin
^C
spatch /tmp/1.bin

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

Сообщений: 42



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

Итак, далее об IP over /dev/ser. Я не захотел менять тему, чтоб всё было хоть как-то в одном месте, и буду продолжать писать сюда.

Поскольку с использованием devn-fd.so пока не смогли разобраться ни здесь в форуме, ни сама QSSL, а мне нужен был IP через /dev/ser между 2-мя компами, то я его крутанул через тунель PPP. Вот как это выглядело:

Соединение делалось практически симметричным, но для определённости назовём комп "1" - сервером (только в том смысле, что на нём скрипт мы запускаем раньше по времени, и он ожидает "2"). Скрипты на каждом из компов практически одинаковые:

№1:
slay pppd
pppd /dev/ser1 115200 19.0.0.1:0.0.0.0 netmask 255.255.255.0
defaultroute updetach debug passive

№2:
slay pppd
pppd /dev/ser1 115200 19.0.0.2:0.0.0.0 netmask 255.255.255.0
defaultroute updetach debug

Вот то "passive" только и отличает серверную сторону канала: pppd на этом конце выполняет 10 попыток установления связи, после чего переходит в режим пассивного прослушивания канала и ожидания. Без него pppd после этих 10-ти попыток (порядка 30 сек.) - завершается. Кстати, изменить это число попыток (10) или время ожидания (30) я не смог никакими параметрами.

Адреса из подсетки 19.0/24 выбраны произвольно, из соображений чистоты эксперимента - на моих компьютерах никогда такая подсетка не использовалась.

Всё это можно видеть (и наладить связь) по отладочному выводу pppd в syslog. Для этого создаём файл:
#touch /etc/syslog.conf  
и прописываем в него 2 строчки:
*.*       /var/log/syslog
*.*       /dev/console
- (части строк разделяются TAB, а не пробелами), после этого вывод pppd в системный журнал направляется в /var/log/syslog (это его обычное месторасположение, кстати, его нужно создать: touch /var/log/syslog) и на консоль. После чего запустить:
#syslogd

После такого старта pppd начинается процедура (с 2-х сторон) обмена и установления PPP-соединения (если вы устанавливаете с "debug" и активизирован вывод в системный журнал, как написано выше - вы можете это наблюдать). При успешном завершении установления соединения у вас появляется новый файл интерфейса /dev/io-net/ip_ppp (это не совсем обычный интерфейс, в сравнении с /dev/io-net/ip_en0, например, вы не сможете его убрать командой "umount /dev/io/net/ppp0" или подобной - для удаления интерфейса используйте "slay pppd" или "kill pid", где pid - найдёте в файле /var/run/ppp0.pid, ещё об одной особенности - ниже, в конце).

После этого можно:
№1:
#ping 19.0.0.2 - OK

№2:
#ping 19.0.0.1 - OK

Смотрим таблицу роутинга ("netstat -r" или "route show"), вот она на одном из компов:

Routing tables

Internet:
Destination        Gateway            Flags  Refs  Use    Mtu  Interface
default            19.0.0.2           UG       0     0   1500  ppp0
19.0.0.1           19.0.0.1           UH       0     0  33220  lo0
19.0.0.2           19.0.0.1           UH       1     0   1500  ppp0
localhost.localdom localhost.localdom UH       0     0  33220  lo0

- примечательно, что соответствующие строки добавлены самим pppd (происходит это только после фактического установления канала - для этого и параметр "updetach". Кстати, роутинг по умолчанию - параметр "defaultroute" - на серверной стороне устанавливать обычно не следует, это чаще делается только с клиентской стороны).

Кстати, IP-адреса и локального и удалённого концов канала можно задать на одной стороне (напр. серверной, когда каналов PPP несколько, и нужно в одном месте поддерживать порядок):
№1:
slay pppd
pppd /dev/ser1 115200 19.0.0.1:19.0.0.2 netmask 255.255.255.0
defaultroute updetach debug passive

№2:
slay pppd
pppd /dev/ser1 115200 defaultroute updetach debug

- где 19.0.0.1:19.0.0.2 - локальный и удалённый IP-адреса (с позиции компа №1 -сервера, естественно), они ними обменяются при установлении PPP-канала, это хорошо видно по выводу в syslog. Можно вообще не устанавливать адреса явно, но мне кажется всегда удобнее знать и устанавливать свои адреса.

Я думаю, что по эффективности такой (более традиционный) канал ничуть не ниже devn-fd.so (когда и если мы этот devn-fd.so раздолбеним), думаю, что и повыше - после обмена по установлению канала, там в PPP только очень небольшой заголовок приписывается спереди IP, и mtu можно установить до 15000 (при больших значениях "pppd: memory fault...". Вот времена отклика ping для разных скоростей /dev/ser, устанавливаемых в тех же скриптах установления канала:

115200 - 15-16ms
9600   - ~185ms
1200   - ~1482ms

При скоростях < 1200 установить PPP не удаётся (?). Все эти цифры - в Photon, дисперсия очень маленькая, и практически не плывёт при дёргании окон Photon или запуске нагруженных GUI-приложений. Цифры достаточно строго пропорциональны скорости обмена по /dev/ser. Времена несколько большие, в сравнении с прямой вычисленной задержкой при передаче по /dev/ser, но это - задержка полного распространения в 2 стороны с 4-х кратной обработкой пакетов стеком IP (на передаче и на приёме). В актив, в сравнении с прямой передачей, можете отнести - весь механизм надёжности, подтверждений, повторов передачи и прочие прелести TCP/IP.

Окончательная проверка (на клиенте):
#telnet 19.0.0.1
....
#ls
#mqc
- очень весело наблюдать "медленный" старт mqc через канал на скорости 1200...

Если канал нужно устанавливать через модем, команда запуска pppd может быть что-то вроде:

#pppd /dev/ser1 115200 19.0.0.2:0.0.0.0 netmask 255.255.255.0
defaultroute updetach debug connect "/usr/bin/chat -vvv -f /etc/chat"

- это для справки, на вскидку, то что я успел попользовать, /etc/chat нужно естественно, создать и прописать ... см. HELP (кстати, если /etc/chat - пустой, то эта команда отрабатывается как без connect..., на прямом соединении, для совместимости может пригодиться).

P.S. pid запущенного pppd записывается в файл /var/run/ppp0.pid - иногда может оказаться полезным;

P.P.S. очень хотелось мне поверх этого IP интерфейса (/dev/io-net/ip_ppp) пустить qnet:
#mount -Tio-net -obind=ip_ppp npm-qnet.so
- монтирование отрабатывает (причём, я к этому времени специально размонтировал интерфейс en0 реальной сетевой платы), но в /net - нет ожидаемых хостов, хотя то-же самое, похоже, при всяком монтировании qnet с bind=ip. Кто-нибудь пробовал реально qnet поверх IP запустить с 2-мя или более хостами? (Там нынешний, идущий в поставке 6.2 mqc, в свою очередь, с задрочками: при самом традиционном qnet через en он в /net не входит, а тотчас переустанавливается в /root, но проверьте "ls /net" - всё ОК, так что - аккуратнее, в прежнем mqc этого не было).

P.P.P.S. очень неприятная неожиданность: невозможность использования tcpdump для интерфейса ppp0 (то же самое и для lo0):
#mount -Tio-net /lib/dll/nfm-bpf.so
#tcpdump -ien0
- всё ОК, listen en0...
#tcpdump -ippp0
#tcpdump -ilo0
... сообщение ... "нет такого интерфейса".
Т.е. сетевой снифер перехватывает пакеты только с реальных интерфейсов (с канального уровня), а с "фиктивных", созданных ... и т.д. - увы. А это значит, что его не получится использовать для анализа трафика devn-fd.so?

Что ещё интересно, это когда идёт пинг с №1 на №2 (пример в самом начале), если сделать на компе №2 (и на №1, наверное, тоже):
#cat /dev/ser1
- ping продолжается, но cat выбрасывает 1 байт на каждый ping - 0x7E...,
т.е. это - то, что мы видим уже как-то "сверх" PPP...?


[ Это Сообщение было отредактировано: Olej в 2002-07-29 12:12 ]
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



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

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

1. Для начала проверим, после загрузки, комп №1:
#ifconfig -a

lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33220
   inet 127.0.0.1 netmask 0xff000000
en0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
   address: 00:60:52:07:4f:4b
   inet 18.0.0.15 netmask 0xffffff00 broadcast 18.0.0.255

- один Ethernet интерфейс родной (он нам не будет нужен)

#netstat -r

Routing tables
Internet:
Destination        Gateway            Flags  Refs  Use    Mtu  Interface
18/24              link#2             UC       0     0   1500  en0
localhost.localdom localhost.localdom UH       0     0  33220  lo0

2. Делаю на комп №1 (все параметры -o - строго через запятую и без пробелов):

#mount -Tio-net -ofd=/dev/ser1,mac=006000000002,verbose devn-fd.so

смотрим что получилось:

#ifconfig -a

lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33220
   inet 127.0.0.1 netmask 0xff000000
en0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
   address: 00:60:52:07:4f:4b
   inet 18.0.0.15 netmask 0xffffff00 broadcast 18.0.0.255
en1: flags=842<BROADCAST,RUNNING,SIMPLEX> mtu 1500
   address: 00:60:00:00:00:02

- ожидаемый интерфейс создан, MAC - всё в порядке, MAC выбран достаточно произвольно (см. там где-то обсуждение в форуме). Мне так думается, что с MAC-ами всё в порядке: вы там увидите дальше, что отправляя пакет IP только по его адресу 20.0.0.2, оно там находит интерфейс en1 - знает куда пакет толкать, по 2-м IP вставляет MAc-и и т.д.

#ifconfig en1 20.0.0.1/24
#ifconfig -a

lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33220
   inet 127.0.0.1 netmask 0xff000000
en0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
   address: 00:60:52:07:4f:4b
   inet 18.0.0.15 netmask 0xffffff00 broadcast 18.0.0.255
en1: flags=843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1500
   address: 00:60:00:00:00:02
   inet 20.0.0.1 netmask 0xffffff00 broadcast 20.0.0.255

- интерфейс сконфигурирован на нужный нам IP, будем пользоваться подсеткой 20.0.0.0/255.255.255.0 - такой у меня заведомо раньше не было.

#netstat -r

Routing tables
Internet:
Destination        Gateway            Flags  Refs  Use    Mtu  Interface
18/24              link#2             UC       0     0   1500  en0
20/24              link#3             UC       0     0   1500  en1
localhost.localdom localhost.localdom UH       0     0  33220  lo0


Обращаю внимание - нужный роутинг после mount ... devn-fd прописался сам - нам не возникает нужды его добавлять.

На 2-м компе - всё аналогично, только MAC=006000000004, IP=20.0.0.2

3. Я там выше писал об tcpdump, что ...

А это значит, что его не получится использовать для анализа трафика devn-fd.so?

Это ошибка. С tcpdump - всё получается и работает:

#mount -Tio-net nfm-bpf.so
#tcpdump -ien1

... всё, ОК, прослушивается интерфейс... с lo0 & ppp0 он не хочет работать, наверное, потому, что распознаёт как-то, что они не являются интерфейсами (или не имеют реального интерфейса) канального уровня?

4. Итак, начинаем пинговать комп с tcpdump (20.0.0.2) из 20.0.0.1 (всего 2 посылки, и так вывода много ...):

#ping -c2 20.0.0.2

- вот что видел tcpdump (т.е. пока - фигня всё что он видел...):

16:11:38.000141 [|ether]
16:11:38.000141 [|ether]
16:11:38.000141 [|ether]
16:11:38.000141 [|ether]
16:11:38.000142 [|ether]
16:11:38.000142 [|ether]
16:11:38.000142 [|ether]
16:11:38.000142 [|ether]
16:11:38.000142 [|ether]
16:11:38.000142 [|ether]
16:11:38.000142 [|ether]
... ну и так далее ...
16:11:39.000076 [|ether]
16:11:39.000076 [|ether]
16:11:39.000076 [|ether]
16:11:39.000076 [|ether]

42 packets received by filter
0 packets dropped by kernel

Как я понимаю, всё слева - временные штампы, включая и .хххххх. Т.е.можно говорить о том, что IP (ICMP) точно ушли c 20.0.0.1, прошли по линии /dev/ser1 - /dev/ser1, поступили на выход devn-fd.so и были как-то (но как?) приняты фильтром.

Я вот тут подумал: а не искажает ли нам само содержимое байтов в IP-пакете дисциплина терминальной линии /dev/ser (+raw, +edit ...) - ведь там некоторые численные значения байт воспринимаются как управляющие и т.д. Я слелал маленький эксперимент - принудительно поменял скорость на одной из сторон линии:

#stty 115200 < /dev/ser1

- всё, tcpdump не принимает ни одного пакета, восстанавливаем скорость -есть приём фильтром.

Но данные (как видно выше - искажённые) передавались, т.е. фильтр не принимал пакетов нормальной IP-структуры. Точно так-же, значит, любой из параметров дисциплины линии /dev/ser может быть принудительно установлен
"посторонним" stty (или согласованно на двух концах), и этот параметр
будет искажать поток IP?

Вот мои параметры /dev/com в эксперименте:

#stty < /dev/ser1

Name:  /dev/ser1
Type:  serial
Opens: 2
+raw +echoe +echoke +echoctl +imaxbel +onlcr
+ihflow +ohflow
intr=^C  quit=^ erase=^?  kill=^U   eof=^D start=^Q  stop=^S  susp=^Z
lnext=^V   min=01  time=00   pr1=^[   pr2=5B  left=44 right=43    up=41
down=42   ins=40   del=50  home=48   end=59
par=none bits=8 stopb=1 baud=9600 rows=0,0

- хотя режим +raw, как видите, должен быть бы сырой поток, или не так?

P.S.У нас ещё какой-то задроченный релиз tcpdump (кстати, 3.6), который заметно отличается по своему поведению (ключам) от его описания в составе этого же (6.2) релиза системы: "man tcpdump" (которое - man - BSD) ... Что-то всё у них через задницу!

5. Начал смотреть дальше - это уже дописывается через достаточно продолжительное время - запустил tcpdump и параллельно на исходящей машине, делающей ping ...

#tcpdump -ien1 -x -X host 20.0.0.1 and host 20.0.0.2

... ба-ба:

17:14:15.4294967236 arp who-has 20.0.0.2 tell 20.0.0.1
0x0000    0001 0800 0604 0001 0060 0000 0002 1400
0x0010    0001 0000 0000 0000 1400 0002
17:14:36.4294966597 arp who-has 20.0.0.2 tell 20.0.0.1
0x0000    0001 0800 0604 0001 0060 0000 0002 1400
0x0010    0001 0000 0000 0000 1400 0002
17:14:37.4294966524 arp who-has 20.0.0.2 tell 20.0.0.1
0x0000    0001 0800 0604 0001 0060 0000 0002 1400
0x0010    0001 0000 0000 0000 1400 0002
.............

т.е. все пакеты, исходящие с пингующей машины - это запросы разрешения ARP - у неё нет MAC для IP 20.0.0.2 и она просит его по сети..., а ответов - нет, ping ещё и не начинался, и заканчивается по недоступности хоста...

6. Пока некогда разбираться, кто кому не возвращает ARP, но есть доступный способ дело поправить по-простому - дописать таблицу ARP, делаем на каждом компе:

#arp -s 20.0.0.1 00:60:00:00:00:02
#arp -s 20.0.0.2 00:60:00:00:00:04

и проверяем:

#arp -an

...ОК! (Кстати, для решения этих проблем, возможно, у модулей io-net есть такой параметр - external_arp, кажется, можно будет с ним поиграться).

7. Запускаю после этого ping и tcpdump на пингующей машине (и на приёмной, но там ничего интересного). И что мы видим?

# tcpdump -ien1 -x -X src 20.0.0.1

tcpdump: listening on en1
18:31:46.4294967147 20.0.0.1 > 20.0.0.2: icmp: echo request
0x0000    4500 0054 0141 0000 ff01 9265 1400 0001   E..T.A.....e....
0x0010    1400 0002 0800 b63e 2c60 0000 bc6b 413d   .......>,`...kA=
0x0020    20b5 0c00 0809 0a0b 0c0d 0e0f 1011 1213   ................
0x0030    1415 1617 1819                            ......
18:31:47.4294967077 20.0.0.1 > 20.0.0.2: icmp: echo request
0x0000    4500 0054 0142 0000 ff01 9264 1400 0001   E..T.B.....d....
0x0010    1400 0002 0800 f722 2c60 0001 bd6b 413d   .......",`...kA=
0x0020    decf 0c00 0809 0a0b 0c0d 0e0f 1011 1213   ................
0x0030    1415 1617 1819                            ......
..............
52 packets received by filter
0 packets dropped by kernel

И то-же самое - со встречной, (но уже с чётким ограничением фильтра вывода tcpdump строго по именам-адресам хостов отправителя и получателя):

# tcpdump -ien1 -x -X src host 20.0.0.2 and dst host 20.0.0.1

tcpdump: listening on en1
18:49:10.000426 20.0.0.2 > 20.0.0.1: icmp: echo request
0x0000    4500 0054 00e6 0000 ff01 92c0 1400 0002   E..T............
0x0010    1400 0001 0800 5586 2a40 0000 fe6f 413d   ......U.*@...oA=
0x0020    4889 0500 0809 0a0b 0c0d 0e0f 1011 1213   H...............
0x0030    1415 1617 1819                            ......
18:49:11.000352 20.0.0.2 > 20.0.0.1: icmp: echo request
0x0000    4500 0054 00e7 0000 ff01 92bf 1400 0002   E..T............
0x0010    1400 0001 0800 367a 2a40 0001 ff6f 413d   ......6z*@...oA=
0x0020    6694 0500 0809 0a0b 0c0d 0e0f 1011 1213   f...............
0x0030    1415 1617 1819                            ......
..............
11 packets received by filter
0 packets dropped by kernel

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

16:11:38.000141 [|ether]

- я этого не понимаю, но предполагаю, что tcpdump видит ethernet пакеты,
которые не может идентифицировать как IP??? Но! Обратите внимание на строгое соответствие - одному ping-у - один полученный "раздолбённый" пакет(я вижу по синхронности вывода на другом конце).

Это всё было при запуске:
#tcpdump -ien1 -x -X

а вот при запуске на том-же хосте в тех-же условиях (пакеты фильтруются по адресу получателя):
#tcpdump -ien1 -x -X dst host 20.0.0.2

- полное молчание - не видит tcpdump ни одного пакета, который можно принять за IP, направленный по адресу 20.0.0.2!

8.Всё это ещё более укрепляет в мысли, что IP пакет курочится на приёмном драйвере (?) /dev/ser, когда какие-то байты принимаются за управляющие(там 0-левых байт, к примеру, полно), прекращение потока - возобновление потока, ... и прочая там херня, пакеты на IP не похожи. И на приёмном ли
драйвере? А если на передающем (tcpdump то пакет при передаче раньше
/dev/ser видит...).

Может у кого есть какие соображения, я уже ни ... не понимаю.

9.Подумалось - а почему никаких фокусов на PPP-канале? Где-то я, кажется,
читал, что PPP, зная с каким каналом работает, управляющие символы экранирует, но может это я его с чем-то и спутал?

10.Экспериментируем дальше: раз для ping (с установленной собственной таблицей arp) компу ничего больше не надо - отправляет ping в никуда, а на другом конце этого "никуда" - /dev/ser1 другого компа, вот и подсмотрим, что получает это "никуда"... На 1-м компе делаем скриптик, переустанавливающий io-net подсистему:

slay io-net
io-net -drtl duplex=1,speed=10 -ptcpip
mount -Tio-net -ofd=/dev/ser1,mac=006000000002,verbose devn-fd.so
ifconfig -a
mount -Tio-net nfm-bpf.so
ifconfig en0 18.0.0.15/24
ifconfig en1 20.0.0.1/24
ifconfig -a
netstat -r
arp -s 20.0.0.1 00:60:00:00:00:02
arp -s 20.0.0.2 00:60:00:00:00:04
arp -an

на 2-м:
#cat /dev/ser1

на первом выполняем (с 2-х разных pterm):

#ping -c1 20.0.0.2

PING 20.0.0.2 (20.0.0.2): 56 data bytes
--- 20.0.0.2 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss


#tcpdump -ien1 -x -s120 src host 20.0.0.2

22:25:40.000574 20.0.0.1 > 20.0.0.2: icmp: echo request
0x0000    4500 0054 3836 0000 ff01 5b70 1400 0001   E..T86....[p....
0x0010    1400 0002 0800 8113 2c00 0000 68a2 413d   ........,...h.A=
0x0020    b109 0500 0809 0a0b 0c0d 0e0f 1011 1213   ................
0x0030    1415 1617 1819 1a1b 1c1d 1e1f 2021 2223   .............!"#
0x0040       2425 2627 2829 2a2b 2c2d 2e2f 3031 3233   $%&'()*+,-./0123
0x0050       3435 3637                                 4567

... на обоих компах выполняем sync для уверенности в сбросе буферов (это я здесь в тексте рисую консольные варианты комад, реально я перенаправляю все потоки вывода в файлы), и вот это получаем на 2-м то, что сыпалось с выхода /dev/ser1 (переведено в hex):

00: 00 60 00 00 00 04 00 60 | 00 00 00 02 08 00 45 00 ..............E.
10: 00 54 38 36 00 00 FF 01 | 5B 70 14 00 00 01 14 00 .T86....[p
20: 00 02 08 00 81 13 2C 00 | 00 00 68 A2 41 3D B1 09           h.A=
30: 05 00 08 09 0A 0B 0C 0D | oE 0F 10 11 12 13 14 15
40: 16 17 18 19 1A 1B 1C 1D | 1E 1F 20 21 22 23 24 25 ...........!"#$%
50: 26 27 28 29 2A 2B 2C 2D | 2E 2F 30 31 32 33 34 35 &'()*+,-./012345
60: 36 37                                             67

- в символьной части дампа я оставил только некоторые байты, дающие совпадение (сдвиг) с пакетом, который фиксировал на отправке tcpdump. Хорошее совпадение? Со сдвигом на 14 байт: первые 12 байт в пакете, поступившем на приёмный /dev/ser1 - MAC-получателя = 006000000004, MAC-отправителя = 006000000002, и ещё 2 байта <08> <00> - это что? В Ethernet MAC это называется "type code" - поле типа Ethernet-кадра. Для IP он равен 0800. А дальше - в точности отосланный IP-пакет, в котором, в свою чередь:

-"смещение" - "данные":

-0х00 - 4-версия ip_v, 5-длина заголовка в 32-бит словах, 20 байт без опций IP, т.е до 0х14-0800 - с этого места заканчивается IP-заголовок и начинается ICMP-сообщение;
-0х01 - 00 - тип сервиса;
-0х02 - полная длина пакета в байтах - 0х54;
-0x08 - время существования - 0xFF;
-0x09 - протокол;
-0х0А - контрольная сумма заголовка - 5B70
-0x0C - IP-адрес отправителя: 0x1400 0001 = 20.0.0.1;
-0x10 - IP-адрес получателя: 0x1400 0002 = 20.0.0.2;
-0x14 - 08 - тип ICMP "эхо-запрос";
-0х15 - 00 - код ICMP
-0x16 - контрольная сумма ICMP - 8113;
... и т.д.

Чего я не вижу после тела IP-пакета - это завершающего checksum пакета MAC-уровня.

Всё-таки, пакеты и MAC и IP "оно" умеет составлять. Ещё раз посмотрим структуру пакета, принятого на /dev/ser:
MAC-заголовок - 14 байт;
IP-заголовок - 20 байт;
ICMP-заголовок - 4 байта;
тело ICMP-сообщения .....

В остальных деталях ещё предстоит разобраться: где-же этот полученный от /dev/ser1 MAC-пакет теряется на пути к стерегущему его tcpdump? Похоже таки да - между devm-fd.so и io-net...

P.S.Тут перед самой отправкой у меня возникло сомнение, но нет под рукой где подсмотреть: а почему в IP-пакете адреса стоят в порядке "адрес источника"-"адрес назначения" (и это правильно для IP), а в MAC пакете - наоборот: "адрес назначения"-"адрес источника"? Это правильно? Не перетасовал ли devn-fd.so MAC-адреса? Тогда приёмная сторона явно не увидит IP-пакета, а увидит "чужой" MAC-пакет, не со своим адресом (который он и называет ether), и который ему и должен быть "до лампочки".
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


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


- ping продолжается, но cat выбрасывает 1 байт на каждый ping - 0x7E...,
т.е. это - то, что мы видим уже как-то "сверх" PPP...?

флаг HDLC фрэйма
Записан

olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #14 : Июля 29, 2002, 03:45:00 pm »

Таки я его сучку "сделал"!!!

Итак, всё по-порядку - это может быть немного занудно, но нужно для понимания того, что там происходит в devn-fd.so, чтоб этот путь можно было повторить и настроить (там с настройками не до конца ясно, сейчас увидите...).

1.Если с 1-го компа можно пинговаться в "никукда", а на втором просто подсмотреть, что в это "никуда" едет (п.10 в предыдущем сообщении), то можно ж и наоборот: на 2-м (условно будем их нумеровать) установить devn-fd.so и tcpdump - и ждать MAC-пакетов с ser-линии. А в это время на первом (здесь devn-fd.so должен быть категорически не установлен) - просто гнать в ser-линию содержимое из файла:
#cp file /dev/ser1
- например ранее сохранённый MAC-пакет, который фиксировался как исходящий при ping. Подспудная мысль состояла в том, чтоб в MAC-пакете поменять адрес получателя и отправителя (дикая идея, описанная в конце прошлого
сообщения), и подсунуть это. Сказано - сделано.

... И тут началось ... Вижу я на приёмном tcpdump нечто то, что и раньше:
16:11:38.000142 [|ether]
16:11:38.000142 [|ether]
16:11:38.000142 [|ether]
16:11:38.000142 [|ether]
16:11:38.000142 [|ether]
........................
- но самое интересное - в конце:
98 packets received by filter

Что такое 98? Это в точности длина MAC-пакета, нарисованного в предыдущем сообщении! Т.е. devn-fd.so, читая с /dev/ser1 "не различает" 1 пакет линой
98 байт и 98 пакетов по 1 байту. Для проверки создаю файл длины 3, содержащий "123" и отправляю в /dev/ser, имеем:
3 packets received by filter

2.Всё ясно, devn-fd.so, выполняя что-то вроде read(fd,buf,buflen), где fd - файловый дескриптор последовательностного устройства с которым он монтировался, получает возврат с результатом 1 по приходу 1-го байта на /dev/ser и связано это как-то с особенностями и режимами чтения с /dev/ser - устройство специфическое (терминальная линия) и режимов там - тьма. Делаем (хотелось бы):
#stty min=100 time=10 < /dev/ser1
- ошибка, оказывается параметры min & time, значения которых по HELP -number, можно установить только так, например:
#stty min=z time=0 < /dev/ser1
или даже так:
#stty min=" " time=" " < /dev/ser1
(там кавычки должны быть - одиночные, но я боюсь редактора форума).

Что вы думаете будет установлено ("stts -a < /dev/ser1") второй командой? Правильно - численные значения кодов символов, стоящих после равенства! Это ещё один пример (ох сколько их уже!!!), что QSSL, похоже, понятий типа "комплексное тестирование" или "программа и методика тестирования" - не слышали. Похоже - попробовали на отдельных частных случаях, и "по-идее" работает - и ладно: так и с командой "on", и с самим devn-fd.so, и, похоже, с bind FLEET через IP... Какая-то халявность у них во всём ... может слишком много там пива пьют, в городе Канате?

Для начала я установил min=0x61 (min=9) & time=0x20 (time=" ") (кстати, min - это минимальное число символов ввода в raw-моде терминальной линии, и изначально установлено в 01, см. вывод stty в предыдущем сообщении, а time - тайм-аут ввода). И повтороно гоню на принимающий tcpdump в чистом виде тот MAC-пакет, который описал в предыдущем сообщении (ping с 20.0.0.1) - tcpdump выводит содержимое(ура!) 2-х(почему?!) принятых пакетов:

0x0000 4500 0054 00e6 0000 ff01 92c0 1400 0002        E..T............
0x0010 1400 0001 0800 5586 2a40 0000 fe6f 413d        ......U.*@...oA=
0x0020 4889 0500 0809 0a0b 0c0d 0e                    H..........

0x0000 0f10 1112 1314 1516 1718 19                    ................

Это же - в точности посланный ping-пакет с удалённым(!) MAC-заголовком (т.е. находит он своего адресата), разделённый на 2 пакета. В заголовках идентификации пока tcpdump ничего не прописывает - структура ни одного из пакетов ему не известна и ни о чём не говорит (ещё бы!).

Ладно, установим min=0x7A (min=z) - всё, tcpdump принимает полностью ping-пакет, идентифицирует его словами: 20.0.0.1->20.0.0.2 icmp: echo request, и ещё один, тоже полностью, пакет на интерфейсе (это уже исходящий), идентифицируемый: arp who-has 20.0.0.1 tell 20.0.0.2 - это он уже и отвечать хочет и запрашивает ARP-разрешение (он ведь, дурачёк, не догадывается, что там - на другом конце просто никого нет!).
 
3.Всё - собираем всё в полной конфигурации: 1-й (посылающий) комп конфигурируем полностью с devn-fd.so (но arp я ему, как писал выше, принудительно прописывать не стал).
#ping -c1 20.0.0.2

На 20.0.0.1 tcpdump фиксирует 5 полных пакетов (я не привожу дампы, только текстовую идентификацию, как tcpdump из распознал - этого достаточно, метки времени тоже убраны):

arp who-has 20.0.0.2 tell 20.0.0.1
arp reply 20.0.0.2 is-at 0:60:0:0:0:4
ff:ff:ff:ff:0:60 802.1b-gsap > 14:0:0:2:ff:ff null I(s=4,r=3,C) len=28
arp who-has 20.0.0.2 tell 20.0.0.1
arp reply 20.0.0.2 is-at 0:60:0:0:0:4

- среди них нет ping-пакетов и посланный ping завершается "хост недоступен". Правильно - ведь мы по stty "научили" принимать 2-й (слушающий) комп, вот он и принял arp-запрос, и ответил на него правильным MAC-адресом ... но посылавший 1-й у нас ещё "глухой". Делаем на нём тот же бред: stty min=z time=0 < /dev/ser1, и ping. Вот первый исторический результат ping-а через devn-fd.so, скопированный с экрана:

/root/FD # ping 20.0.0.2
PING 20.0.0.2 (20.0.0.2): 56 data bytes
64 bytes from 20.0.0.2: icmp_seq=0 ttl=255 time=2641 ms

--- 20.0.0.2 ping statistics ---
13 packets transmitted, 1 packets received, 92% packet loss
round-trip min/avg/max = 2641/2641/2641 ms

И соответствующий ему вывод tcpdump на отвечающем компе:

# tcpdump -ien1 -x -X

tcpdump: listening on en1
18:24:05.000255 20.0.0.1 > 20.0.0.2: icmp: echo request
0x0000   4500 0054 196b 0000 ff01 7a3b 1400 0001        E..T.k....z;....
0x0010   1400 0002 0800 20bc 29a0 0000 1cbc 423d        ........).....B=
0x0020   62a7 0100 0809 0a0b 0c0d 0e0f 1011 1213        b...............
0x0030   1415 1617 1819                                 ......
18:24:05.000255 20.0.0.2 > 20.0.0.1: icmp: echo reply
0x0000   4500 0054 0452 0000 ff01 8f54 1400 0002        E..T.R.....T....
0x0010   1400 0001 0000 28bc 29a0 0000 1cbc 423d        ......(.).....B=
0x0020   62a7 0100 0809 0a0b 0c0d 0e0f 1011 1213        b...............
0x0030   1415 1617 1819                                 ......

Всё работает - и arp-разрешение MAC по сети тоже! Почему плохо работает? Из 13-ти посланных ICMP-пакетов подтверждение пришло только на 1 (первый). Потому, что первый блин всегда должен быть комом - остальные пакеты ICMP сегментируются, значения min нужно больше 0x7A, а кто знает букву с кодом больше z? Вот они QSSL-евы штучки-дрючки...

В подтверждение сегментации - вот дамп одного из сеансов tcpdump, здесь правда, сегментирован arp-ответ:

# tcpdump -ien1 -x -X

tcpdump: listening on en1
18:32:49.4294966663 arp who-has 20.0.0.2 tell 20.0.0.1
0x0000   0001 0800 0604 0001 0060 0000 0002 1400        .........`......
0x0010   0001 0000 0000 0000 1400 0002 ffff ffff        ................
0x0020   ffff 0060 0000 0002 0806 0001 0800 0604        ...`............
0x0030   0001 0060 0000                                 ...`..
18:32:49.4294966663 arp reply 20.0.0.2 is-at 0:60:0:0:0:4
0x0000   0001 0800 0604 0002 0060 0000 0004 1400        .........`......
0x0010   0002 0060 0000 0002 1400 0001                  ...`........
18:32:54.4294967162 truncated-ip - 1 bytes missing!
20.0.0.1 > 20.0.0.2: icmp: echo request
0x0000   4500 0054 196e 0000 ff01 7a38 1400 0001        E..T.n....z8....
0x0010   1400 0002 0800 1ac7 2950 0001 4cbe 423d        ........)P..L.B=
0x0020   2ee9 0b00 0809 0a0b 0c0d 0e0f 1011 1213        ................
0x0030   1415 1617 1819                                 ......
18:32:57.4294967240 [|ether]

4 packets received by filter
0 packets dropped by kernel

4.Дальше - запускаю на 20.0.0.1 (предварительно запустив на 20.0.0.2 inetd):
#telnet 20.0.0.2
- начинается активный обмен (по tcpdump на обоих концах), диалог активизации telnet - до logon, после чего обмен сбивается из-за сегментации пакетов (видно по выводу tcpdump)... Одним словом: "уже намазывается, но запах ещё сохраняется...".

Но диагноз того, почему до сих пор не удавалось пустить devn-fd.so через /dev/ser - понятен: нужно заставить читающий devn-fd.so читать целый пакет целиком, а не завершать чтение по полученному фрагменту. На вскидку: min должно бы быть равным (или чуть больше) mtu=1500, а time - время передачи такого максимального пакета (длины mtu) на выбранной скорости обмена через /dev/ser (в каких там кстати единицах time?). Как эти значения установить (не прибегая к программному способу через terminfo)?

Почти наверняка существуют и другие, более простые и изящные, варианты заставить /dev/ser читаться в "блочном", "по-пакетном" режиме - описано
первое, что в голову пришло. Кто больше?

Но devn-fd.so таки через /dev/ser - работает! Сколько он крови моей попил...
Записан
Страниц: [1] 2 3 ... 5
  Печать  
 
Перейти в: