QNX.ORG.RU

Разработка => Встраиваемые системы => Тема начата: Sergey от Апреля 05, 2002, 05:52:00 pm



Название: TCP/IP over /dev/ser*
Отправлено: 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 ]


Название: TCP/IP over /dev/ser*
Отправлено: Sergey от Апреля 08, 2002, 01:11:00 am
Это так, чтоб заглянули
[addsig]


Название: TCP/IP over /dev/ser*
Отправлено: wind_alex от Апреля 08, 2002, 03:00:00 am
На сколько я понимаю тема выросла из "пром. интерф.".
Я предыдущих темах я об этом и говорил - MAC devn-fd нужен
как входной фильтр. А пинг не возвращается потому что не
прописана маршрутизация и вообще не ясна топология


Название: TCP/IP over /dev/ser*
Отправлено: olej от Апреля 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?


Название: TCP/IP over /dev/ser*
Отправлено: Sergey от Апреля 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 ]


Название: TCP/IP over /dev/ser*
Отправлено: olej от Апреля 24, 2002, 05:07:00 am

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

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


Название: TCP/IP over /dev/ser*
Отправлено: ed1k от Апреля 24, 2002, 08:43:00 am

Olej пишет:

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

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


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


Название: TCP/IP over /dev/ser*
Отправлено: lestat от Апреля 24, 2002, 09:28:00 am

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

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


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

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


Название: TCP/IP over /dev/ser*
Отправлено: Sergey от Апреля 26, 2002, 07:01:00 am
Некаких sunc_ов дажет неделаю.
Отстреливаю  cat /dev/ser1 > ping.bin  по  Ctrl +C
И все. Открываю и ковыряю.
[addsig]


Название: TCP/IP over /dev/ser*
Отправлено: dmi от Апреля 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 стек говорит, что пакеты некорректны


Название: TCP/IP over /dev/ser*
Отправлено: dmi от Апреля 26, 2002, 12:49:00 pm

Olej пишет:

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


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



Название: TCP/IP over /dev/ser*
Отправлено: olej от Июля 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 ]


Название: TCP/IP over /dev/ser*
Отправлено: olej от Июля 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), и который ему и должен быть "до лампочки".


Название: TCP/IP over /dev/ser*
Отправлено: lestat от Июля 29, 2002, 03:40:00 pm

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

флаг HDLC фрэйма


Название: TCP/IP over /dev/ser*
Отправлено: olej от Июля 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 - работает! Сколько он крови моей попил...


Название: TCP/IP over /dev/ser*
Отправлено: olej от Июля 29, 2002, 04:02:00 pm
И теперь, оглядываясь на сделанное, можно подвести некоторые промежуточные итоги.

1.Если кому нужно организовать взаимодействие по /dev/ser 2-мя крмпами, не пудрите мозги, для этого оптимально используется PPP, не надо ничего мудрить. Тем более, что эффективность такого обмена будет заведомо выше, чем с любыми механизмами, подобными devn-fd.so или что-то такое. Почему?

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

1.2.pppd в QNX реализации (или это BSD или OSF реализация?), похоже, делает уплотнение или исключение избыточной информации из IP-пакета, я пока не берусь утверждать, мне много непонятно, но вот dump одного ICMP пакета, пересылаемого по "ping 20.0.0.2" по PPP:

0x00: 1F 0D E8 78 08 1F 3B 0A | 18 0B 08 08 C9 89 18 D8
0x10: 7C 4C 09 18 18 39 39 5A | 5A 7B 7B 5A 5A 7B 7B 18
0x20: 18 39 39 18 18 39 39 5A | 5A 7B 7B BA FF 0D

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

0x0000 4500 0054 3836 0000 ff01 5b70 1400 0001
0x0010 1400 0002 0800 8113 2c00 0000 68a2 413d
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
0x0050 3435 3637                              

Пока это всё предварительно, но посмотрите 0x2E (+/-один, может я не совсем там обрезал) байт вместо 0x54. С этим ещё нужно разобраться. Как я получил этот PPP пакет (дамп) - если кто захочет повторить и покопаться? Это не совсем очевидно: ppp соединение устанавливается только с 2-х концов одновременно, его нельзя надурить как devn-fd.so, посылая пакеты "в никуда", tcpdump не работает с установленным интерфейсом ppp0... Получал я ppp пакеты так:
-устанавливаю ppp-соединение по всем правилам, с 2-х сторон, согласованные режимы и скорость...
-убиваю на одной стороне pppd по kill;
-некоторое время могу посылать пакеты на "живой" интерфейс (пока pppd не почувствует, что канала не стало, ну по ping это длится до бесконечности);
-на конце "убитого" pppd можно канализировать поступающие ppp-пакеты в файл: cp /dev/ser1 file.

1.3.можно открывать несколько PPPx для соответствующих /dev/serx - там кто-то об таком спрашивал, можно создать дублирующие линии между одной парой хостов: по /dev/ser1 & /dev/ser2, по идее - можно на эти PPP каналы надстроить qnet, если, конечно, кому-то удасться доподлинно запустить qnet с bind=ip - пока это только разговоры...

2.Теперь об devn-fd.so. Это совсем другая история - здесь пытаются программно моделировать MAC-уровень и обработку MAC-адресов. Эта модель имеет хоть какие либо реальныее основания для применения, когда электрически на канале находятся несколько устройств с отличающимися MAC адресами. Это физически вполне реализуемо в стандарте RS-485 (умельцы от электроники делают это и нестандартно используя RS-232, но это годится только как макет). Кстати, есть простейшие адаптеры RS-232<->RS-485, т.е. различия только электрические: дифференциальный сигнал по 1-й паре, а программист может рассматривать такой канал абсолютно как привычный /dev/ser (RS-232), на котором висит "много" (>2) хостов.

2.1.Формат (протокол) MAC-уровня. Может быть произвольный, разработчик может его выдумывать абсолютно произвольно, важно, что в MAC-заголовке должны обязательно содержаться 2 MAC-адреса - источник и получатель (я там выше спрашивал - какой их порядок. Это опрометчивый вопрос - любой! Это может быть формализован Ethernet MAC-формат, TokenRing MAC-формат и т.д. ... а здесь - devn-fd.so посылает и devn-fd.so принимает). Раз уж они у нас есть, рассмотрим дампы MAC-пакетов посланные devn-fd.so, и перехваченные на ответном /dev/ser.

Вот дамп ARP-запроса (его я ещё не приводил):

0x00: FF FF FF FF FF FF 00 60 | 00 00 00 02 08 06 00 01
0x10: 08 00 06 04 00 01 00 60 | 00 00 00 02 14 00 00 01
0x20: 00 00 00 00 00 00 14 00 | 00 01

А вот дамп ping-запроса (его я уже несколько раз рисовал, только не путайте - иногда он фигурирует как MAC-пакет, как здесь, а иногда, как IP/ICMP-пакет - тогда всё тоже, но начиная с 14-го байта):

0x00: 00 60 00 00 00 04 00 60 | 00 00 00 02 08 00 45 00
0x10: 00 54 38 36 00 00 FF 01 | 5B 70 14 00 00 01 14 00
0x20: 00 02 08 00 81 13 2C 00 | 00 00 68 A2 41 3D B1 09
0x30: 05 00 08 09 0A 0B 0C 0D | oE 0F 10 11 12 13 14 15
0x40: 16 17 18 19 1A 1B 1C 1D | 1E 1F 20 21 22 23 24 25
0x50: 26 27 28 29 2A 2B 2C 2D | 2E 2F 30 31 32 33 34 35
0x60: 36 37                                            

Вот это и есть формат MAC-пакетов, используемый devn-fd.so - первые 14 байт - это MAC-заголовок:
- 6 байт - адрес получателя;
- 6 байт - адрес источника;
- 2 байт - это, похоже, "тип сервиса", у ARP (который является чисто пакетом MAC-уровня, не IP) - он 0806, у IP (я не думаю, что этот MAC-уровень мог бы различать что-то "под" IP: ICMP, UDP, TCP) - 0800. Хорошо видно, как ARP-запрос посылается по широковещательному MAC-адресу FF:FF:FF:FF:FF:FF, и это всё работает (напомню, работает на последовательной байтовой линии /dev/ser, которая ни сном ни духом не знает ни о MAC-адресации, ни о широковещании, и, тем более, об IP - всю эту обработку берёт на себя devn-fd.so).

Мне кажется, что беда devn-fd.so в том, что QSSL в этом своём формате MAC-пакета упустила одну очень важную вещь, без которой всё это не может устойчиво работать в принципе: длину (то-ли всего MAC-пакета, то-ли последующего за MAC-заголовком тела пакета, не важно), но об этом - чуть попозже.

2.2.Было бы очень хорошо, если бы в качестве MAC-формата QSSL пошла по пути использования чего-то более стандартного, того же ModBus, о котором много упоминали здесь в форуме, и который является фактически стандартом (одним из) передачи уровня MAC, и физическая модель обмена RS-485 как раз и опирается на некоторую подобную модель MAC. Но так QSSL не сделала, и сейчас посмотрим, что ж из этого получается.

2.3.Что делает devn-fd.so? И что делает не так? Делает что-то вроде следующего:

int fd=open( "device", ... );
while( true ){
  читать MAC-пакет;
  if( MAC.dst == собственный MAc || MAC.dst == широковещание ) {
     выделить пакет, инкапсулированный в MAK;
     обработать в зависимости от типа пакета;
  }
}

А как сделано "читать MAC-пакет"? По поведению - несомненно что-то вроде:
read( fd, MAC_buf, mtu );
- поскольку mtu он знает, он его сам может даже устанавливать при запуске (может ли? что-то к QSSL никакого доверия нет...).

Почему это работает. Потому, что QSSL определили devn-fd.so в документации как-то так (как помню, под рукой нет, но смысл точный): "интерфейс обмена с устройствами, представленными файловыми дескрипторами", да и само имя devn-fd.so - об том же говорит. Вот эти "файловые дескрипторы" QSSL и подвели: отлаживались они, почти наверняка, на файле, в который "ручками" вогнали MAC-пакет ... и в этом случае всё работает. Я уже писал, что для QSSL такое понятие, как "программа тестирования" - пустой звук (поймите меня правильно, программа тестирования - не утверждённая гербовыми печатями, а в голове, когда вся последовательность тестов должна прогоняться в полном объёме и с самого начала при внесении любых изменений в код). Работает - "ура" - и в поставку.

Что происходит с /dev/ser? Выписанный выше read() - возвращается при поступлении 1-го же байта в /dev/ser - вот вам пакет, и тут же отбраковывается, и так ... while( true ). И, в общем, всё правильно - на момент read() - в буфере только 1 байт, а следующий ... прийдёт скоро - это в файле - всё в порядке, весь MAC-пакет целиком лежит!

2.4.Чем ему можно помочь? Я уже писал - установить stty или другим средством параметры ввода для /dev/ser в raw-моде, когда минимальная порция ввода (блок) будет равен mtu, и тайм-аут, равный времени считывания mtu-байт на той скорости, на которую настроен /dev/ser.

Будет это работать? Почти: любой пакет, короче mtu будет буферизироваться, и поступать на обработку по истечении тайм-аута. Будет это хорошо? Нет, это будет очень плохо: приём пакета, обычная длина которых редко >100 байт будет занимать время mtu=1500 байт (и всё это ещё в черепашьем масштабе времени скоростей /dev/ser). Будет это надёжно? Нет, не будет, по 2-м причинам:
-если после короткого пакета последует ещё один, с интервалом меньше времени передачи mtu байт - то они сольются, в лучшем случае 2-й пакет потеряется;
-если какой-то пакет будет сегментирован (например 2-й пакет в предыдущем пункте), то синхронизация на начало пакета не будет восстановлена никогда!

2.5.Как делу помочь? Идея devn-fd.so - заманчивая, задумана красиво, да реализована кривыми ручками. Попользовать его, чтоб посмотреть как оно работает - можно. Использовать в приложениях, тем более критических - ни в коем разе.

Тут затык принципиальный, он даже не в особенностях чтения /dev/ser (или /dev/par и т.д.), а в том, что это устройства потоковые байтовые (в отличии от Ethernet адаптера, который знает формат MAC-пакета и ориентирован на приём пакета). Эти устройства не могут определить границу пакета, а не зная длины пакета, программный обработчик MAC не может его выделить. Здесь нужно или дополнять MAC-заголовок длиной, или (альтернативно) - использовать разделитель-ограничитель пакетов в потоке (Скажете - там любой байт может быть в потоке, нечего использовать как разделитель? Не страшно - можно использовать технику экранирования, выделить для этого 2 символа - экран и разделитель - и предобрабатывать при передаче. Так, кстати, где-то на аппаратном MAC-уровне делают, не помню, чтоб не FDDI).

Я пока не вижу другого пути исправления ситуации, как взять и переписать. Если бы были исходники devn-fd.so - там работы на 2 дня. Никто не смотрел: в сорсах на исходном CD, или в Network DDK - нет???

А переделать нужно бы вот что:

- поменять формат заголовка MAC так, чтоб он обязательно содержал актуальную длину инкапсулированного в MAC пакета, а заодно, раз уж менять, привести его к соответствию одному из стандартов, применяемых в пром-интерфейсах;

- чтение переделать как-то так:

while( true ){
  читать заголовок MAC-пакета;
  if( MAC.dst != собственный MAc && MAC.dst != широковещание ) continue;
  int nPkgLen = <актуальная длина пакета>;
  установить тайм-аут приёма = передаче пакета такой длины;
  if( read( ,, nPkgLen ) <= 0 ) continue;
  обработать в зависимости от типа пакета;
}

Здесь read хоть тоже в каких-то случаях искажения пакета может его пропустить, так хоть синхронизация на начало пакета будет каждый раз восстанавливаться. Кстати, эта схема чтения в тосности соответствует схеме MsgReceive()-MsgRead(), везде применяемой и описываемой QSSL для чтения сообщений от микроядра, а здесь ... Но чтение сообщений в системе, наверное, эксперт писал, а devn-fd.so - студент...

P.S.Появилась тут ещё идея, это больше из задрочек, или кому быстро нужно результат получить: сделать перед /dev/ser промежуточное потоковое устройство (какой-нибудь /dev/sep), которое при отправке пакета допишет перед ним его длину, а при считывании - прочитает длину, сосчитает указанной длины пакет, и только после этого вернёт его по read(). Коротко и сердито, маленький такой ресурс менеджер, который знает только 2 операции: write() & read(). А devn-fd.so уже к нему монтировать. При этом фактически и произойдёт автоматом изменение MAC-формата в такой:
- 2 байта - длина пакета;
- 6 байт - адрес получателя;
- 6 байт - адрес источника;
... ну а дальше - всё как и было ...
В "плюсах" такого решения могло бы быть то, что этот драйвер /dev/sep мог бы без труда навешиваться на любой (по номеру) /dev/ser, /dev/par, да и на любую другую линию побайтовой потоковой передачи, например, на какую-то вашу совсем уж необычную самоделку (инфракрасную там линию передачи или ещё что).


[ Это Сообщение было отредактировано: Olej в 2002-07-29 13:28 ]


Название: TCP/IP over /dev/ser*
Отправлено: lestat от Июля 29, 2002, 04:25:00 pm

1.2.pppd в QNX реализации (или это BSD или OSF реализация?),

AFAIK BSD - отпочковавшаяся от ранней OSF 2.3.5. В BSD все снесли в ядро для netgraph а в linux начали городить клиентскую часть ...

похоже, делает уплотнение или исключение избыточной информации из IP-пакета, я пока не берусь утверждать, мне много непонятно, но вот dump одного ICMP пакета, пересылаемого по "ping 20.0.0.2" по PPP:

vj по умолчанию включена, надо указать опцию -vj для отключения компрессии заголовков ...


Название: TCP/IP over /dev/ser*
Отправлено: DigiMind от Июля 30, 2002, 06:01:00 pm

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

Ну наконец-то! Мои поздравления .
Черт. Читал взахлеб, как хороший детектив .
И это огорчает... Почему вместо нормального пользования системой приходится заниматься банальным хаком? Эх..


Название: TCP/IP over /dev/ser*
Отправлено: olej от Июля 30, 2002, 08:16:00 pm

DigiMind пишет:
И это огорчает... Почему вместо нормального пользования системой приходится заниматься банальным хаком? Эх..

Нет худа без добра!
Подумалось мне, что вот такая прослоечка между devn-fd.so & /dev/ser (читай: любое потоковое устройство) - это не так уж и худо, т.е. только и исключительно для /dev/ser - это чрезмерно и наворот, а вот для более широкого класса устройств - даже дополнительная функциональность. Попробую за выходные сделать...


Название: TCP/IP over /dev/ser*
Отправлено: dmi от Июля 31, 2002, 05:26:00 am
Шаман!
Я до этого не дошел... Остановился где-то на [!ether] и даже не подумал, что дело может быть в этом.

Олег, огромная просьба: можешь оформить это в виде статьи или публикации в FAQ. Важность материала, я думаю, осознаешь сам


Название: TCP/IP over /dev/ser*
Отправлено: olej от Июля 31, 2002, 01:20:00 pm

dmi пишет:
Олег, огромная просьба: можешь оформить это в виде статьи или публикации в FAQ. Важность материала, я думаю, осознаешь сам

Чуть позже: я хочу как-то довести это до ума (оно ведь "уже намазывается"), а потом уже всё разом...

А ещё мне вспомнилось сообщение dmi, кажется, что QSSL в приватной беседе "обещали посмотреть devn-fd.so, запустить через него qnet для убедительности, и показать..." - это не точно, но смысл я, кажется, не переврал. Ну как мне нравятся всё больше эти ... из QSSL. "Конкретные пацаны ... типа...": у них devn-fd.so принципиально в таком виде работать не может, ну ладно, они об этом могут и не знать, но то, что к реализации qnet FLEET bind over IP они ЕЩЁ НЕ ПРИСТУПАЛИ (см. где-то в форуме новость от dmi) - об этом они должны хотя бы догадываться???


Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 02, 2002, 02:20:00 pm
Киньте в меня кто-то спецификацией ModBus или его URL ... для этих дел.


Название: TCP/IP over /dev/ser*
Отправлено: ed1k от Августа 02, 2002, 04:49:00 pm

Olej пишет:
Киньте в меня кто-то спецификацией ModBus или его URL ... для этих дел.


Нафига он тебе?
http://www.modicon.com/techpubs/toc7.html
Если есть вопросы по протоколу - спрашивай в аське/мыле. Комплетели офтопик в QNX форуме.



Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 02, 2002, 09:13:00 pm

ed1k пишет:
Нафига он тебе?
http://www.modicon.com/techpubs/toc7.html

Раз уже протокол devn-fd.so перекручивать - хотел посмотреть, нельзя ли его перекрутить приближённо к ModBus: они функционально для одного и того же (я же обещал там кому-то за выходные перекрутить, а выходные уже подошли...). Спасибо, посмотрел. В прямую - нельзя: devn-fd.so использует 6-ти байтные MAC-адреса, а ModBus - 1 байтовый адрес получателя (а адрес источника вообще не использует). Но одна там интересная фича обнаружилась: ModBus в RTU Message Frame моде (бинарной) для разделения пакетов (в чём и есть проблема devn-fd.so) использует не передачу длины тела пакета, и не байты разграничители, а: временную задержку (паузу в трафике) не менее 3.5 периодов передачи байта (требуют "не менее", а реально везде ставят 4 периода). Интересно... К тем, кто этим занимается и ковыряется: какие могут быть соображения?




Название: TCP/IP over /dev/ser*
Отправлено: lestat от Августа 02, 2002, 09:23:00 pm

Раз уже протокол devn-fd.so перекручивать - хотел посмотреть, нельзя ли его перекрутить приближённо к ModBus

Кстати на сколько я могу себе представить внутренности devn-fd - он очень простой, как показывает практика 70% кода драйвера аппаратно-зависимая, остальное - это оформление точек входов, callback'ов и т.п. мелочей. Остается совсем мало. QNX в плане общения между драйверами через точки входа в файловую систему вроде проще чем какая-нибудь из известных ОС. Остается только написать хороший обработчик последовательно порта и можно городить свой драйвер.


Название: TCP/IP over /dev/ser*
Отправлено: DigiMind от Августа 04, 2002, 10:14:00 pm

Интересно... К тем, кто этим занимается и ковыряется: какие могут быть соображения?

Все равно не понятно, зачем городить туда ModBus.


Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 05, 2002, 01:16:00 pm

DigiMind пишет:
Все равно не понятно, зачем городить туда ModBus.

Формат пакетов MAC может быть любым, так? Если его всё равно перекраивать, то почему бы не перекроить под что-то специфицированное? Посмотрел - ни под что подобное ModBus выкроить формат пакетов MAC не годится. Всё, вопросов нет.

А по поводу соображений, что я спрашивал: есть 3 варианта выделить (ограничить, "огородить") пакет MAC-уровня в байтовом потоке /dev/ser:
1.включением поля явного спецификатора длины в пакет;
2.использование символа разграничителя (с экранированием) конца пакета;
3.исвользование гарантированной временной паузы в потоке (время передачи 4-х байт) для ограничения пакета - вот это я позаимствовал из ModBus (так что не зря время потерял).

По 1-му варианту пробное решение у меня почти готово, и в отладке. А вопрос, кому интересно, такой - как каждый из вариантов видится из соображений устойчивости к ошибкам, и, особенно - к потере синхронизации: сбою к определению места начала очередного MAC-пакета?
 


Название: TCP/IP over /dev/ser*
Отправлено: DigiMind от Августа 05, 2002, 02:14:00 pm

1.включением поля явного спецификатора длины в пакет;
2.использование символа разграничителя (с экранированием) конца пакета;
3.исвользование гарантированной временной паузы в потоке (время передачи 4-х байт) для ограничения пакета - вот это я позаимствовал из ModBus (так что не зря время потерял).

По 1-му варианту пробное решение у меня почти готово, и в отладке. А вопрос, кому интересно, такой - как каждый из вариантов видится из соображений устойчивости к ошибкам, и, особенно - к потере синхронизации: сбою к определению места начала очередного MAC-пакета?

Был бы специалистом в данной теме, обязательно высказался бы развернуто.
А так, только чайниковское имхо .
Могу сказать, что п.3 мне совсем не нравится.
На скорости 115200 время передачи символа составляет <100 мкс. Уж кому как не тебе знать тему измерения времени в QNX .
Опыт возни с ModBus'ом показал, что протоколы с синхронизацией по времени, мне не нравятся.


Название: TCP/IP over /dev/ser*
Отправлено: ed1k от Августа 05, 2002, 08:37:00 pm

DigiMind пишет:
 Olej пишет
...
3.исвользование гарантированной временной паузы в потоке (время передачи 4-х байт) для ограничения пакета - вот это я позаимствовал из ModBus (так что не зря время потерял).
...
Был бы специалистом в данной теме, обязательно высказался бы развернуто.
А так, только чайниковское имхо .
Могу сказать, что п.3 мне совсем не нравится.
На скорости 115200 время передачи символа составляет <100 мкс. Уж кому как не тебе знать тему измерения времени в QNX .
Опыт возни с ModBus'ом показал, что протоколы с синхронизацией по времени, мне не нравятся.

А мне выбирать не приходиться. В данный момент ковыряю (но на нашем железе, очень далеко от qnx и pc) следующее при приеме пакета:
1) запрещаю передачу на линию
2) приняв байт cntr=3 и передаю байт на той же скорости (но не в люнию, как понятно, я надеюсь)
3) в обработчике прерывания "передача SCI закончилась" смотрю флаг, если идет прием пакета:
cntr--;
if (cntr==0) {
         посылаю сообщение обработчику пакетов, что пакет принят;
          выход из обработчика;
  }
  else {
         посылаю байт-пустышку;
          выход из обработчика;
  }

иначе (то есть если передача пакета) - все как обычно и передача в линию разрешена, выгрузил буфер и будь здоров.
Работает, так как модбас запрос/ответный по природе - вначале приходит запрос от мастера, потом идет ответ от слэйва. И так как у нас дальше RS485 - направление передачи тоже моя забота. Удачи.
По синхронному интерфейсу мы все же толкаем длину пакета в заголовке - проще и надежней ИМО. Но модбас пакет оказывается внутри нашего пакета с фирменным лого





Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 07, 2002, 04:35:00 pm

я там выше писал:
P.S.Появилась тут ещё идея ... сделать перед /dev/ser промежуточное потоковое устройство (какой-нибудь /dev/sep), которое при отправке пакета допишет перед ним его длину, а при считывании - прочитает длину, сосчитает указанной длины пакет, и только после этого вернёт его по read().

Занялся я сейчас этим делом, почти готово, сделаю - покажу. Спасибо 2-м предыдущим корреспондентам за советы - если не прямо, то косвеноо они подсказали любопытные соображения.

Но пока я ковыряюсь с devn-fd.so, тут попутно вылезли такие соображения, которыми я счёл нужным тут-же поделиться. Итак:

1.Как только заработает "примочка" к /dev/ser (или, точнее, к devn-fd.so - сама примочка, т.е. маленький ресурс менеджер /dev/sip - он уже примонтируется к devn-fd.so, но ещё не вылизаны вопросы тестирования и анализа передаваемых пакетов) - то, подумалось: ничего не видно, что препятствовало бы запуску qnet поверх канала devn-fd.so через /dev/ser, ведь это канал не только IP, но и MAC уровня. Что никак нельзя сделать с PPP, который тунель только IP, и до тех пор, пока QSSL не сделает bind=ip (или кто из нас быстрее сделает?) - это невозможно.

Что это даёт:
- возможность "поковыряться" с qnet тем, у кого нет сетевого оборудования вообще (автономные, домашние компьютеры...) - организуя связь между /dev/ser1 & /dev/ser2 (см.ниже);
- изучить такие свойства qnet, о которых так сладко поют QSSL, как: устойчивость, перераспределение трафика, восстановление соединения... без использования специального макета и обрудования (2 Ethernet карты). Достаточно соединить 2 компа по 2-м сериальным линиям: /dev/ser1-/dev/ser1 & /dev/ser1-/dev/ser1 и всё ... поехали, можно получить тестовые результаты;

2.В развитие соображения использовать локальный компьютер для сетевой отладки (или написания и отладки сетевых приложений без живой сети), подумалось: а чего бы не попользовать для этого и PPP (кроме FLEET, конечно - только IP). Сделал. Очень коротко, кому интересно - можете повторить:

2.1.Для начала, приведу общеизвестную распайку 3-х проводного нуль-модемного кабеля (бывают ещё 5-ти и 7-ми), чтоб не искать:
DB9 - DB9
2   -  3
3   -  2
5   -  5
(для DB25 "5" заменяем на "7").
2.2.Соединили проверили:
#cp XXX /dev/ser1
#cat /dev/ser2
2.3.Проверим скорость:
#stty 115200 < /dev/ser1
#stty 115200 < /dev/ser2
делаем достаточно длинный файл XXX, можете воспользоваться для любого (лучше символьного) файла:
#cat XXX >> XXX
^C
- только "вовремя" давите ^C - файл растёт экспоненциально . Дальше:
#time cp XXX /dev/ser1
#cat /dev/ser2
У меня для файла 15156 байт время (общее, как видно будет дальше - может это и неправильно: нужно юзеровское брать, см. ниже) - 1.270 сек. - т.е. вот вам и сетка на ~13Kb/s - для отладки вполне годится.
2.4.Строим серверный (это очень условно) интерфейс ppp0:
#pppd /dev/ser1 passive 19.0.0.1:0.0.0.0 netmask 255.255.255.0 updetach
2.5.Строим 2 клиентских интерфейса ppp1, ppp2:
#pppd /dev/ser2 19.0.0.2:19.0.0.1 netmask 255.255.255.0 updetach
#pppd /dev/ser2 19.0.0.3:19.0.0.1 netmask 255.255.255.0 updetach
2.6.
#ifconfig -a
..............
#ping 19.0.0.1
#ping 19.0.0.2
#ping 19.0.0.3
..............
2.7.А таперь на них - telnet:
#inetd
#telnet 19.0.0.2
.....
#mqc
..... вот вам "медленный" старт ...
2.8.Вот
#time cat XXX
- меня озадачивает - времена меньше, чем по direct connect ...?


[ Это Сообщение было отредактировано: Olej в 2002-08-07 15:04 ]


Название: TCP/IP over /dev/ser*
Отправлено: DigiMind от Августа 07, 2002, 06:28:00 pm

2.8.Вот
#time cat XXX
- меня озадачивает - времена меньше, чем по direct connect ...?

Эээ.. Компрессия?


Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 07, 2002, 06:50:00 pm

DigiMind пишет:
Эээ.. Компрессия?

Может быть, отчасти, но я сильно грешу на то, что в выводе time нужно "значащим" считать не "real"-время, а "user". Хотя там тоже проблемы: если на низких уровнях "переть поток в порт" - там все времена будут юзеровские, то когда включается в работу целая цепочка драйверов (ресурс менеджеров) - там большая часть может отвалиться в "system"...


Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 12, 2002, 02:46:00 pm
Сделал я таки ресурс менеджер /dev/sip - который цепляется к /dev/ser, и превращает потоковую байтовую передачу в пакетную. Т.е. например, можно:
#cp xxx /dev/sip1     ;на 1-м компе
#cat /dev/sip1 > xxx  ;на 2-м компе
... всё ОК, кроме того они мне "помогают" - сообщают: "read request - 4096 bytes" и т.д.

Цепляю теперь уже этот драйвер к devn-fd.so:
#mount -Tio-net -ofd=/dev/sip1,mac=006000000004 devn.fd.so
#ifconfig en1 20.0.0.2/24
#arp -s 20.0.0.1 00:60:00:00:00:02
... на обоих компах, естественно, на 2-м что-то похожее, даже arp принудительно прописал, чтоб всё начало "играть" с IP не посылая ARP..., ну и, конечно, всё необходимое для tcpdump делаю.

О бля-я-я-я...

После монтирование: "read request - 1498 bytes" (размер,может, я чуть-чуть и переврал - по памяти пишу - но запрашивается IP пакет со станд. MTU...) всё ОК. Но после ping tcpdump видит отправляемые пакеты ..., а драйвер /dev/sip по запросам write() - не видит ничего ... молчит как партизан в гестапо!

Возник вопрос: так какой ещё операцией кроме write() они из devn-fd.so могут "проталкивать" данные в примонтированный "файловый дескриптор" (так они сами называют)... devctl()? Зачем?

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


Название: TCP/IP over /dev/ser*
Отправлено: dmi от Августа 12, 2002, 07:20:00 pm

Olej пишет:
выходные перекрутить, а выходные уже подошли...). Спасибо, посмотрел. В прямую - нельзя: devn-fd.so использует 6-ти байтные MAC-адреса, а ModBus - 1 байтовый адрес получателя (а адрес источника вообще не использует).

Что-то я совсем ничего не понял ? Что во что ты хочешь завернуть и чем это намазать ? При чем тогда devn-fd ? modbus rtu/ascii использует чистую физику серийного шнурка, без TCP и т.д. Modbus TCP - это уже из другой сказки...


Но одна там интересная фича обнаружилась: ModBus в RTU Message Frame моде (бинарной) для разделения пакетов (в чём и есть проблема devn-fd.so) использует не передачу длины тела пакета, и не байты разграничители, а: временную задержку (паузу в трафике) не менее 3.5 периодов передачи байта (требуют "не менее", а реально везде ставят 4 периода). Интересно... К тем, кто этим занимается и ковыряется: какие могут быть соображения?


На практике делается select() при чтении. Не знаю, из чего расчитывается таймаут, но для 57600 он равен 8333 us. (из моих расчетов получается, что ~7000 вполне достаточно - теоретически).
По срабатыванию select() считается, что пакет пришел и проверяется его CRC.

У меня ни разу не было ситуации, когда я бы отправлял пакеты чаще, чем 5-15 раз в секунду. Так уж ли это критично ?

А вообще, если не хочется (или специфика не позволяет) мучаться с таймаутами, то можно использовать MODBUS ASCII.


Название: TCP/IP over /dev/ser*
Отправлено: dmi от Августа 12, 2002, 07:27:00 pm

Olej пишет:

После монтирование: "read request - 1498 bytes" (размер,может, я чуть-чуть и переврал - по памяти пишу - но запрашивается IP пакет со станд. MTU...) всё ОК. Но после ping tcpdump видит отправляемые пакеты ..., а драйвер /dev/sip по запросам write() - не видит ничего ... молчит как партизан в гестапо!

Возник вопрос: так какой ещё операцией кроме write() они из devn-fd.so могут "проталкивать" данные в примонтированный "файловый дескриптор" (так они сами называют)... devctl()? Зачем?

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


1492 наверно. А не пишет, потому как не может сделать devctl() на /dev/sip - установка четности/длины байта и т.д.-tcgetattr() &tcsetattr().Могу поковырять его, сказать, что оно вызывает.

По идее можно просто сделать один обработчик, который на все значения будет отвечать 0 (т.е. EOK), а не ENOTSUP  (возвращается по умолчанию).


Название: TCP/IP over /dev/ser*
Отправлено: dmi от Августа 12, 2002, 07:34:00 pm

Olej пишет:
#cat XXX >> XXX


Я аж икнул


Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 12, 2002, 07:39:00 pm

dmi пишет:

Olej пишет:
#cat XXX >> XXX

Я аж икнул

Понравилось? Хорошая команда ... если зазевать, то быстро заполняет любой винчестер ... под крышку



Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 12, 2002, 07:41:00 pm

dmi пишет:
1492 наверно. А не пишет, потому как не может сделать devctl() на /dev/sip - установка четности/длины байта и т.д.-tcgetattr() &tcsetattr().Могу поковырять его, сказать, что оно вызывает.

По идее можно просто сделать один обработчик, который на все значения будет отвечать 0 (т.е. EOK), а не ENOTSUP  (возвращается по умолчанию).

1492 - да, наверное. По поводу того, что это devctl() установочный - хорошая мысль, свежая. Но он ведь и передавать данные (записывать) потом может по devctl()?


Название: TCP/IP over /dev/ser*
Отправлено: dmi от Августа 13, 2002, 01:51:00 pm

Olej пишет:

dmi пишет:
1492 наверно. А не пишет, потому как не может сделать devctl() на /dev/sip - установка четности/длины байта и т.д.-tcgetattr() &tcsetattr().Могу поковырять его, сказать, что оно вызывает.

По идее можно просто сделать один обработчик, который на все значения будет отвечать 0 (т.е. EOK), а не ENOTSUP  (возвращается по умолчанию).

1492 - да, наверное. По поводу того, что это devctl() установочный - хорошая мысль, свежая. Но он ведь и передавать данные (записывать) потом может по devctl()?


devctl() генерит PulseMsg(), т.е. несет 4 байта информации. Думаю, лучше писать через write...


Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 13, 2002, 03:55:00 pm

dmi пишет:
devctl() генерит PulseMsg(), т.е. несет 4 байта информации. Думаю, лучше писать через write...

Тут у меня же затык не в том "как лучще", а в том, как (каким вызовом) devn-fd.so передаёт данные примонтированному к нему последовательному устройству (было /sev/ser, потом /dev/sop, но это может быть и заурядный файловый дескриптор). По write( fd, ...) - он этого, гад, не делает (чем им write не угодил) ... , а как?

[ Это Сообщение было отредактировано: Olej в 2002-08-13 13:03 ]


Название: TCP/IP over /dev/ser*
Отправлено: dmi от Августа 13, 2002, 04:50:00 pm

Olej пишет:

dmi пишет:
devctl() генерит PulseMsg(), т.е. несет 4 байта информации. Думаю, лучше писать через write...

Тут у меня же затык не в том "как лучще", а в том, как (каким вызовом) devn-fd.so передаёт данные примонтированному к нему последовательному устройству (было /sev/ser, потом /dev/sop, но это может быть и заурядный файловый дескриптор). По write( fd, ...) - он этого, гад, не делает (чем им write не угодил) ... , а как?


У меня есть подозрение, что сначала он пытается сделать devctl() на этот fd, который завершается аварийно ( a.e. tcsetattr() failed ). Так что надо писать обработчики _этих_ devctl().


Название: TCP/IP over /dev/ser*
Отправлено: dmi от Августа 13, 2002, 04:51:00 pm

Olej пишет:

dmi пишет:
devctl() генерит PulseMsg(), т.е. несет 4 байта информации. Думаю, лучше писать через write...

Тут у меня же затык не в том "как лучще", а в том, как (каким вызовом) devn-fd.so передаёт данные примонтированному к нему последовательному устройству (было /sev/ser, потом /dev/sop, но это может быть и заурядный файловый дескриптор). По write( fd, ...) - он этого, гад, не делает (чем им write не угодил) ... , а как?


У меня есть подозрение, что сначала он пытается сделать devctl() на этот fd, который завершается аварийно ( a.e. tcsetattr() failed ). И до write() конечно же не доходит (зачем писать, если порт отключен ?). Так что надо писать обработчики _этих_ devctl().


Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 13, 2002, 05:46:00 pm

dmi пишет:
У меня есть подозрение, что сначала он пытается сделать devctl() на этот fd, который завершается аварийно ( a.e. tcsetattr() failed ). И до write() конечно же не доходит (зачем писать, если порт отключен ?). Так что надо писать обработчики _этих_ devctl().

Это правильное соображение, и я его проверю, только какого он хрена делает devctl() на этот, в общем случае - файловый дескриптор? Что он от него хочет. Ведь про порт, про /dev/ser - это мы придумали возиться, а у них, в общем виде, там может быть что угодно: файл, /dev/par, наконец какие-то собственные "шнурки"...


Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 13, 2002, 06:09:00 pm
Чего я ещё вцепился "как блоха в собачью шерсть" в devn-fd.so, а точнее в связку io-net - devn-fd.so - /dev/sip - /dev/ser, так это то, что "продолбив" ЭТО я смогу с помощью devn-fd.so гнать TCP/IP через любую среду передачи, через любые "шнурки", самопальные или стандартизированные, например:
- USB кабель "комп-комп" - есть такие, стоимостью "от производителя" около $10 - там микросхема хаба "в кабле", т.е. это и не совсем кабель, а там - до 12 Мбит/сек.
- LPT кабель, мы по нему в режиме EPP гнали 650 Кбайт/сек - в некоторых, именно встраиваемых, приложениях это может быть любопытно;
- наконец, больше всего меня интересует fireware: IEEE-1394A - 400Mbit/sec & IEEE-1394B - 3.2Hbit/sec - но по нему ничего нет (т.е. есть полно - путнего описания нет), сам IEEE-1394A - к нему не доберёшься - сам IEEE его рассылает около ~$100. Может кто видел?  


Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 13, 2002, 09:12:00 pm
Стал переписывать ресурс менеджера /dev/sip так, чтоб он поддерживал devctl() - ну, хотя бы, для начала, чтоб я мог видеть эти вызовы:
....
Could not find library libbfd-2.10.1.so
... ну ни фига себе - где он ещё это взял?


Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 13, 2002, 09:27:00 pm

Olej пишет:
Could not find library libbfd-2.10.1.so

А может это просто QCC "сдурел" от нехватки ему памяти: 64М - 1 окно HELP, 7 окон Opera ... но в Win у меня и 27 - не редкость. В свапе есть свои прелести...


Название: TCP/IP over /dev/ser*
Отправлено: Evgeniy от Августа 13, 2002, 10:30:00 pm

......
В свапе есть свои прелести...


- особенно на инструментальной машине

[ Это Сообщение было отредактировано: Evgeniy в 2002-08-13 19:31 ]


Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 13, 2002, 10:58:00 pm
Переписал /dev/sip ...влепил туда обработчик dvctl ("по Кёртену" )
static int pack_devctl( resmgr_context_t *ctp,
io_devctl_t *msg,
RESMGR_OCB_T *ocb ) {

// это - код devctl
cout << "devctl request: " << msg->i.dcmd << endl;
   int status = iofunc_devctl_default( ctp, msg, ocb );
cout << "devctl result: " << status << endl;
   if( status != _RESMGR_DEFAULT ) return status;
   memset( &msg->o, 0, sizeof( msg->o ) );
   SETIOV( ctp->iov, &msg->o, sizeof( msg->o ) );
   return _RESMGR_NPARTS( 1 );
};

Теперь пускаем эту дрянь:
#stty 115200 </dev/ser1

/root/FD/1.05 # devc-sip
/dev/ser1   =>   /dev/sip1
Channel device: /dev/ser1
- вот он стартонул ... и молчит

/dev # ls  /dev/s*
/dev/ser1      /dev/ser2      /dev/sip1      /dev/slog

#mount -Tio-net nfm-bpf.so

Вот оно:
#mount -Tio-net -ofd=/dev/sip1,mac=006000000002 devn-fd.so

А это то, что выплюнул мой ресурс менеджер в момент mount (начальный вывод - это повтор, потому как с экрана копирую):

/root/FD/1.06 # devc-sip
/dev/ser1   =>   /dev/sip1
Channel device: /dev/ser1
devctl request: 1184629771
devctl result: -2147483647
read request: 1514

Всё, пошёл в *.h (кстати - какой .h?) разбираться, что это за 1184629771 и -2147483647 ...


[ Это Сообщение было отредактировано: Olej в 2002-08-13 20:26 ]

[ Это Сообщение было отредактировано: Olej в 2002-08-13 20:33 ]

[ Это Сообщение было отредактировано: Olej в 2002-08-13 20:35 ]


Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 13, 2002, 11:38:00 pm
dmi - что за фигня: я правлю уже 5 раз предыдущее сообщение - собственно, заголовок функции (который и создаёт такую безумную ширину страницы) - и ничего не правится!

Может ты ему можешь что-то вправить?!


Название: TCP/IP over /dev/ser*
Отправлено: olej от Августа 19, 2002, 04:27:00 pm
Кто хочет - может попробовать devn-fd.so в работе (хотя это и не оптимальный режим использования). Итак, поскольку с надстройкой к /dev/ser происходят некоторые задержки в связи с запросами dvctl() из devn-fd.so к /dev/ser, и разбираться там будет муторно и требует времени, сдеал я себе программку smt - устанавливающая численные значения MIN & TIME.Я её текст помещу прямо здесь, чтоб не плодить ... кому будет интересно - скопируйте с экрана:

#include <stdlib.h>
#include <iostream.h>
#include <stdio.h>
#include <termios.h>
#include <fcntl.h>
#include <string.h>

int main( int argc, char *argv[] ) {
   char dev[ 80 ] = "/dev/ser1";
   int c, m = 1, t = 0;
   while( ( c = getopt( argc, argv, "hu:m:t:" ) ) != -1 ) {
       switch( c ) {
           case 'u': strcpy( dev + 8, optarg ); break;
           case 'm': m = atoi( optarg ); break;
           case 't':  t = atoi( optarg ); break;
           case 'h':
               cerr << argv[ 0 ]
                    << " [-u<serial number>]|[-m<min read>]|"
                    << "[-t<read timeout>]|[-h]" << endl;
               exit(  EXIT_SUCCESS );
           case '?': exit( EXIT_FAILURE );
       }
   };
   cout << "Device: " << dev << endl;
   int fd = open( dev, O_RDWR );
   if( fd < 0 ) perror( "device error: " ), exit( EXIT_FAILURE );
   if( isatty( fd ) == 0 )
      perror( "not terminal: " ), exit( EXIT_FAILURE );
   struct termios newtio;
   if( tcgetattr( fd, &newtio ) !=0 )
      perror( "TERMIOS error: " ), exit( EXIT_FAILURE );
   newtio.c_cc[ VMIN ] = m;
   newtio.c_cc[ VTIME ] = t;
   cout << "Set MIN=" << m << " TIME=" << t << endl;
   if( tcflush( fd, TCIOFLUSH ) != 0 )
      perror( "Flush error: " ), exit( EXIT_FAILURE );
   if( tcsetattr( fd, TCSANOW, &newtio ) != 0 )
      perror( "TERMIOS error: " ), exit( EXIT_FAILURE );
   close( fd );
   return EXIT_SUCCESS;
};

Т.е., запуская её, например, так:
#smt -u2 m3 t4
- устанавливаем на /dev/ser2 - min=3, time=4.

Теперь, имея такую цацку:

1.соединяем 2 компа 3-х проводным нуль-модемом: /dev/ser1 <-> /dev/ser1
2.на 1-м выполняем предустановочный скрипт:
umount /dev/io-net/en1
mount -Tio-net nfm-bpf.so
mount -Tio-net -ofd=/dev/ser1,mac=006000000004 devn-fd.so
ifconfig en1 20.0.0.2/24
arp -s 20.0.0.1 00:60:00:00:00:02
ifconfig -a
arp -a
smt -m255 -t1
3.на втором, соответственно:
umount /dev/io-net/en1
mount -Tio-net nfm-bpf.so
mount -Tio-net -ofd=/dev/ser1,mac=006000000002 devn-fd.so
ifconfig en1 20.0.0.1/24
arp -s 20.0.0.2 00:60:00:00:00:04
ifconfig -a
arp -a
smt -m255 -t1
Т.е. - созданы интерфейсы en1 - en1 - симметрично конфигурированные друг на друга (обратите внимание - я принудительно прописал каждому arp партнёра - но это перестраховка, будет работать и без этого).
4.в отдельном окне pterm каждого компа запускаю tcpdump для мониторинга потока:
#tcpdump -ien1 -X
5.всё ... со второго на 1-й:
#ping 20.0.0.2

Вот, чтоб не быть голословным, вывод ping прямо с экрана:

/root/FD/106 # 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=301 ms
64 bytes from 20.0.0.2: icmp_seq=1 ttl=255 time=297 ms
64 bytes from 20.0.0.2: icmp_seq=2 ttl=255 time=295 ms
64 bytes from 20.0.0.2: icmp_seq=3 ttl=255 time=292 ms
64 bytes from 20.0.0.2: icmp_seq=4 ttl=255 time=289 ms
64 bytes from 20.0.0.2: icmp_seq=5 ttl=255 time=287 ms
64 bytes from 20.0.0.2: icmp_seq=6 ttl=255 time=285 ms
64 bytes from 20.0.0.2: icmp_seq=7 ttl=255 time=283 ms
64 bytes from 20.0.0.2: icmp_seq=8 ttl=255 time=281 ms
64 bytes from 20.0.0.2: icmp_seq=9 ttl=255 time=279 ms
64 bytes from 20.0.0.2: icmp_seq=10 ttl=255 time=277 ms
64 bytes from 20.0.0.2: icmp_seq=11 ttl=255 time=275 ms
64 bytes from 20.0.0.2: icmp_seq=12 ttl=255 time=273 ms

--- 20.0.0.2 ping statistics ---
13 packets transmitted, 13 packets received, 0% packet loss
round-trip min/avg/max = 273/285/301 ms

Скорость /-Сev/ser стоит исходная для QNX 6.2 - 57600.
Вот - пару пакетов того что видел tcpdump на отправляющем компе:

13:26:10.4294967292 20.0.0.1 > 20.0.0.2: icmp: echo request
0x0000   4500 0054 003d 0000 ff01 9369 1400 0001        E..T.=.....i....
0x0010   1400 0002 0800 f924 2890 000c 4e76 5f3d        .......$(...Nv_=
0x0020   3388 0a00 0809 0a0b 0c0d 0e0f 1011 1213        3...............
0x0030   1415 1617 1819                                 ......
13:26:10.4294966545 20.0.0.2 > 20.0.0.1: icmp: echo reply
0x0000   4500 0054 0145 0000 ff01 9261 1400 0002        E..T.E.....a....
0x0010   1400 0001 0000 0125 2890 000c 4e76 5f3d        .......%(...Nv_=
0x0020   3388 0a00 0809 0a0b 0c0d 0e0f 1011 1213        3...............

А вот - ещё пару пакетов того что видел tcpdump на приёмном компе:

13:28:54.000144 20.0.0.1 > 20.0.0.2: icmp: echo request
0x0000   4500 0054 003d 0000 ff01 9369 1400 0001        E..T.=.....i....
0x0010   1400 0002 0800 f924 2890 000c 4e76 5f3d        .......$(...Nv_=
0x0020   3388 0a00 0809 0a0b 0c0d 0e0f 1011 1213        3...............
0x0030   1415 1617 1819                                 ......
13:28:54.000144 20.0.0.2 > 20.0.0.1: icmp: echo reply
0x0000   4500 0054 0145 0000 ff01 9261 1400 0002        E..T.E.....a....
0x0010   1400 0001 0000 0125 2890 000c 4e76 5f3d        .......%(...Nv_=
0x0020   3388 0a00 0809 0a0b 0c0d 0e0f 1011 1213        3...............

Но это ещё что, это фигня... Делаем дальше на обоих компах:
/root/FD/1.06 # mount -Tio-net npm-qnet.so
Далее:
/ # ls /net
home    rtp
- через сериальный шнурок пошли MAC-пакеты, несущие FLEET (qnet)! (Кстати, напоминаю - не пытайтесь смотреть содержимое /net - mqc - но это уже особенность текущего релиза mqc...).

Вот пару пакетов прихваченные tcpdump отправляющего компа:

14:00:07.000031 0.0.0.0 > 0.0.0.0:  ip-proto-106 44
0x0000   4500 0040 0000 0000 ff6a bb54 0000 0000        E..@.....j.T....
0x0010   0000 0000 1102 002c ae53 5b70 0000 0000        .......,.S[p....
0x0020   0000 0000 0000 0000 0014 0700 686f 6d65        ............home
0x0030   006c 6f74 2e6b                                 .lot.k
14:00:25.000206 0.0.0.0 > 0.0.0.0:  ip-proto-106 43
0x0000   4500 003f 0000 0000 ff6a bb55 0000 0000        E..?.....j.U....
0x0010   0000 0000 1102 002b f7f5 918e 0000 0000        .......+........
0x0020   0000 0000 0000 0000 0013 1200 7274 7000        ............rtp.
0x0030   6c6f 742e 6b68                                 lot.kh

Обратите внимание на фрагмент "ip-proto-106" в выводе tcpdump - он не знает такого IP (!!!) протокола, поэтому пишет так, но мы то знаем, вот последняя строчка файла /etc/protocols:

qnet    106     QNET            # QNX Network protocol

Интересно? Но как по мне, так ещё интереснее то, что  tcpdump видит (но не понимает IP-пакеты), а как же с обещанным тем, что npm-qnet.so по молчанию монтируется с bind=en, и обменивается на уровне MAC-пакетов??? Кстати, в /dev/io-net я вижу интерфейс именно qnet-en!

И ещё обратите внимание, идентифицируя qnet-пакеты как ip-proto-106 tcpdump, как он понимает, для адресов даёт "0.0.0.0 > 0.0.0.0:" - но это-же ещё один вид широковещания - адрес всей сети... Может то, что QSSL называют bind=en и есть не MAC-адресация, а IP-широковещание на сетку?

Вот перезагрузивши компьютеры и исключив из стартовых скриптов принудительное прописывание соответствий arp - я привожу вывод tcpdump на интерфейсе пингующей машины: отчётливо видно 2 (отправляемый и принимаемый) MAC-пакета разрешения через ARP адреса получателя, и затем 2 IP-пакета - отправленный и полученный ICMP. Видно различие форматов MAC vs IP.

/root/FD/1.06 # tcpdump -ien1 -X -s0
tcpdump: listening on en1
15:19:00.4294967129 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                  ............
15:19:00.4294967129 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                  ...`........
15:19:00.000110 20.0.0.1 > 20.0.0.2: icmp: echo request
0x0000   4500 0054 0015 0000 ff01 9391 1400 0001        E..T............
0x0010   1400 0002 0800 4b27 28f0 0000 0392 5f3d        ......K'(....._=
0x0020   3016 0600 0809 0a0b 0c0d 0e0f 1011 1213        0...............
0x0030   1415 1617 1819                                 ......
15:19:00.000111 20.0.0.2 > 20.0.0.1: icmp: echo reply
0x0000   4500 0054 0157 0000 ff01 924f 1400 0002        E..T.W.....O....
0x0010   1400 0001 0000 5327 28f0 0000 0392 5f3d        ......S'(....._=
0x0020   3016 0600 0809 0a0b 0c0d 0e0f 1011 1213        0...............
0x0030   1415 1617 1819                                 ......

А вот начало сессии telnet через подобный канал (на ответной машине не забудьте telnetd). Как-то у меня начально это не получалось. По крайней мере - это работало после перезапуска devc-ser8250 с большим размером буфера:
#slay devc-ser8250
#devc-ser8250 -C1580 -f3f8,4
- но я и до сейчас не уверен в необходимости этого.
И ещё одно, при запуске telnet я заметил по tcpdump, что пакеты "секутся",
что естественно при длине >255, т.к. больше min мы не можем установить для
/dev/ser, поэтому я пока монтирую devn-fd.so так:
#mount -Tio-net -ofd=/dev/ser1,mac=006000000004,mtu=254 devn-fd.so  

/root/FD/1.06 # telnet  20.0.0.1
Trying 20.0.0.1...
Connected to 20.0.0.1.
Escape character is '^]'.
login: root
Password:
Sun Aug 18 17:56:56 2002 on /dev/ttyp3
Last login: Sun Aug 18 17:41:30 2002 on /dev/ttyp3
edit the file .profile if you want to change your environment.
To start the Photon windowing environment, type "ph".
# cd /
# ls
.            .diskroot    boot         lib          sbin
..           .inodes      dev          opt          tmp
.altboot     .swapfile    etc          pkgs         usr
.bitmap      armle        fs           proc         var
.boot        bin          home         root         x86
....

Далее через telnet я запускал mqc на удалённом хосте - медленно, но всё работает, файлы копируются, удаляются ... tcpdump скролингует как сошедши с ума ... веселье. Особенно меня повеселило копирование из локального буфера обмена в файл, открытый по F4 в окошке mqc на удалённой: обновление экрана редактирования не успевает, и при копировании выглядит как "впересыпку" байты из старого и нового содержимого. Последующее открывание по F3 показывает, что всё копировалось ОК.

Как видите, уровни MAC & IP уже работают (пусть неоптимально), а вот с FLEET - пока сплошное безумие...


Название: TCP/IP over /dev/ser*
Отправлено: vlad от Октября 01, 2002, 04:11:00 pm
А не пробывал ли кто запустить IP через usb???


Название: TCP/IP over /dev/ser*
Отправлено: olej от Октября 01, 2002, 04:51:00 pm

vlad пишет:
А не пробывал ли кто запустить IP через usb???

Для этого нужно сперва просто электрически компы соединить по USB (мы ж между компами собираемся обмениваться IP, не с периферией?). А этого просто так делать нельзя (электронщики говорят, что так и компы пожечь просто можно? там и разъёмы разные на USB кабле поэтому, а кабели асть вида ... какого A-B, A-A как-то оно у них так называется...).

Для такого соединения есть м/сх специальные - USB коннекторы, я тип не помню, кому надо - посмотрю напишу, ~$10 что ли ... Те кабели, которые предлагаются для соединений USB-USB они как-раз эту м/сх и содержат, залитую в кабель.

А после того, как будет канал USB-USB, то к нему и нужно приложить devn-fd.so (только правильный ) с двух концов. Почему я и говорю, что побороть devn-fd.so - это сила: фиг с ними, с /dev/ser, его можно к любой линии (последовательной или нет) приатачивать, хоть к самопалке ущербной, хоть к FastWare... Лишь бы электрически передача точка-точка осуществлялась!


Название: TCP/IP over /dev/ser*
Отправлено: Landy от Октября 01, 2002, 06:09:00 pm

А этого просто так делать нельзя (электронщики говорят, что так и компы пожечь просто можно? там и разъёмы разные на USB кабле поэтому, а кабели асть вида ... какого A-B, A-A как-то оно у них так называется...).

Для такого соединения есть м/сх специальные - USB коннекторы, я тип не помню, кому надо - посмотрю напишу, ~$10 что ли ... Те кабели, которые предлагаются для соединений USB-USB они как-раз эту м/сх и содержат, залитую в кабель.

А кто-нить пробовал разбирать переходники PS2-USB?
Стоят кажись бакса 4, дык вот нет там ни хрена - только четыре провода
И меня мучает вопрос А-А А-В ... - может втюхивают так же?


Название: TCP/IP over /dev/ser*
Отправлено: vlad от Октября 01, 2002, 06:36:00 pm
Ясно: насчет usb пока рано говорить.

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

Так в том ведь и дело, что исходников то devn-fd нема
И что настораживает - так это то, что QSSL по сути отказалась от этого драйвера, а использовать его от предыдущих версий вроде как не совсем корректно (о совместимости 6.x версий можно легенды слагать ). Тем более, что в 6.2 PE стэк TCP/IP значительно расширен.

И вопрос, может быть, несколько чайниковый:
много раз на форуме видел упоминание утилиты tcpdump, однако ни в 6.1, ни в 6.2 я ее найти не смог (А очень надо!)
Olej, подскажи pls!


Название: TCP/IP over /dev/ser*
Отправлено: olej от Октября 01, 2002, 07:53:00 pm

vlad пишет:
Так в том ведь и дело, что исходников то devn-fd нема

Во-первых, есть NET DDK - и этого достаточно, чтоб разобравшись с техникой передачи переписать по-новой свой;

Но раньше того, во-вторых, чтоб не перекраивать всё, можно написать такую "обёртку" - ресурс менеджер (который и монтируется к devn-fd.so), который по своим операциям read/write "пакетирует" данные (write - посылает впереди пакета его длину, а read - принимает длину, а потом "ловит" пакет этой длины..., а все операции выполняют далее через /dev/ser), и, как оказалось, обрабатывает devctl, который выдаётся при монтировании, и или сам на него отвечает, или ретранслирует к /dev/ser и модифицирует на возврате...

Я всё, кроме последнего devctl, уже сделал, не помню до какой степени, но описал в теме. А если не успел описать, то черновики остались...

А потом наступил цейтнот ...

И что настораживает - так это то, что QSSL по сути отказалась от этого драйвера, а использовать его от предыдущих версий вроде как не совсем корректно (о совместимости 6.x версий можно легенды слагать ). Тем более, что в 6.2 PE стэк TCP/IP значительно расширен.

На счёт "отказались", так это я совсем не уверен.
На счёт предыдущих версий: dmi утверждал, что в 4.ХХ ЭТО работало. А в 6.ХХ ОНО было мёртвым отродясь, от 6.0!
А на счёт стека PE, так он, по идее, изменён только в расширении части IPv6, а POSIX стандарты на IP-стек - это вотчина не QSSL ... и не им его менять.

И вопрос, может быть, несколько чайниковый:
много раз на форуме видел упоминание утилиты tcpdump, однако ни в 6.1, ни в 6.2 я ее найти не смог (А очень надо!)

В 6.1 tcpdump - это был совсем сторонний продукт, который нужно было доставать и ставить (вместе обязательно!!! с BPF-фильтром nfm-bpf.so). В 6.2 - это всё есть на тех 2-х родных CD - ищи. Нужно поставить BPF & tcpdump. Смотри... У тебя должен появиться /lib/dll/nfm-bpf.so, пробуешь tcpdump - он матерится, что нет BPF, а мы тогда:
#mount -Tio-net nfm-bpf.so
#tcpdump -x -X -ien0 ... там очень много опций, см. man tcpdump ...

Без tcpdump с сетевыми прогами делать нечего!


Название: TCP/IP over /dev/ser*
Отправлено: vlad от Октября 01, 2002, 08:44:00 pm

В 6.1 tcpdump - это был совсем сторонний продукт, который нужно было доставать и ставить (вместе обязательно!!! с BPF-фильтром nfm-bpf.so). В 6.2 - это всё есть на тех 2-х родных CD - ищи.

Понял! К сожалению 6.2 у меня только один диск. 2-й со сторонним sw SWD, к сожалению, не раздовало Придется ждать пока начальство раскошелится на PE.


Название: TCP/IP over /dev/ser*
Отправлено: olej от Октября 01, 2002, 09:30:00 pm

vlad пишет:
Понял! К сожалению 6.2 у меня только один диск. 2-й со сторонним sw SWD, к сожалению, не раздовало Придется ждать пока начальство раскошелится на PE.

А чего ж было к dmi не подойти там же, в Питере? Хотя и мэйлом, возможно - не поздно ...

P.S.Вспомнил: кстати, мне "первый" BPF именно он подарил мылом.

[ Это Сообщение было отредактировано: Olej в 2002-10-01 18:35 ]


Название: TCP/IP over /dev/ser*
Отправлено: Landy от Октября 02, 2002, 11:22:00 am

Понял! К сожалению 6.2 у меня только один диск. 2-й со сторонним sw SWD, к сожалению, не раздовало Придется ждать пока начальство раскошелится на PE.

Дык - на фтп лежит qnx.org.ru
Чего ждать-то?!


Название: TCP/IP over /dev/ser*
Отправлено: vlad от Октября 02, 2002, 03:16:00 pm

Landy пишет:
Дык - на фтп лежит qnx.org.ru
Чего ждать-то?!

Дык не по dail-up же скачивать Меня шеф потом убъет за такую трату денег.


Название: TCP/IP over /dev/ser*
Отправлено: Landy от Октября 02, 2002, 04:29:00 pm

vlad пишет:

Landy пишет:
Дык - на фтп лежит qnx.org.ru
Чего ждать-то?!

Дык не по dail-up же скачивать Меня шеф потом убъет за такую трату денег.

Дык там образ подмонтирован - возьми что нужно из repository


Название: TCP/IP over /dev/ser*
Отправлено: wind_alex от Октября 03, 2002, 02:26:00 pm

Olej пишет:
...
На счёт "отказались", так это я совсем не уверен.
На счёт предыдущих версий: dmi утверждал, что в 4.ХХ ЭТО работало. А в 6.ХХ ОНО было мёртвым отродясь, от 6.0! ....



Точно, точно сам проверял на 4.25 - все работает и даже очень не плохо.

P.S. 4.25 вообще была значительно более устойчивой(может быть это относится только к Photon )


Название: TCP/IP over /dev/ser*
Отправлено: olej от Октября 03, 2002, 04:40:00 pm

wind_alex пишет:
P.S. 4.25 вообще была значительно более устойчивой(может быть это относится только к Photon )

Я вот, разглядывая всё это (вообще структуру системы) по документации, думаю, что "с чего бы это?"... При эволюции 4.ХХ в 6.ХХ у них есть ряд принципиально концептуальных изменений, но, вроде, нет таких, которые вели бы к потере устойчивости ...

Мне, пока, кажется, что это всё-таки "эффекты сырости" 6.ХХ ...

[ Это Сообщение было отредактировано: Olej в 2002-10-03 16:16 ]


Название: TCP/IP over /dev/ser*
Отправлено: dmi от Октября 04, 2002, 08:58:00 pm

Olej пишет:
Я вот, разглядывая всё это (вообще структуру системы) по документации, думаю, что "с чего бы это?"... При эволюции 4.ХХ в 6.ХХ у них есть ряд принципиально концептуальных изменений, но, вроде, нет таких, которые вели бы к потере устойчивости ...

Мне, пока, кажется, что это всё-таки "эффекты сырости" 6.ХХ ...



Добавились: треды, динамические библиотеки, менеджеры ресурсов. Этого более чем достаточно, чтобы обеспечить головной болью специалистов службы техподдержки, RnD и QnA
И если бы не десяток лет развития neutrino до выхода 6.0, картина была бы самая удручающая.
Несомненно, это эффекты сырости. Но такой четкости работы, как в 4.25 в 6.x мы уже не увидим. По крайней мере в десктопной инсталляции.
В целефой системе засчет этого все получается намного лучше и проще, чем в 4.2x. Хотя, опять же, от рук завсисит.


Название: TCP/IP over /dev/ser*
Отправлено: olej от Октября 04, 2002, 10:15:00 pm

dmi пишет:
Добавились: треды, динамические библиотеки, менеджеры ресурсов. Этого более чем достаточно, чтобы обеспечить головной болью специалистов службы техподдержки, RnD и QnA

Я об этом и говорил:

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

- динамические библиотеки - это вопрос рационального использования ресурсов, но никак принципиально на систему не влияет;

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


Название: TCP/IP over /dev/ser*
Отправлено: dmi от Октября 04, 2002, 10:44:00 pm

Olej пишет:

Я об этом и говорил:

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


Это изначально было заложено в Neutrino, и нареканий никогда на это не слышал.  Серьезных по крайней мере. Про SMP молчу


- динамические библиотеки - это вопрос рационального использования ресурсов, но никак принципиально на систему не влияет;

Это может влиять на скорость и стабильность работы.


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

Как раз они изменились больше всего с Neutrino 2.0 (не путать с QNX RTOS 2.0 )

И, пожалуй, самое главное изменение - это Photon 2.0.x. В Neutrino поставлялся Photon 1.14.


Название: TCP/IP over /dev/ser*
Отправлено: dmi от Октября 15, 2002, 12:24:00 am
devn-ser (замена devn-fd для /dev/serX) почти готов. Кто хочет потестировать - пишите dmi@qnx.org.ru


Название: TCP/IP over /dev/ser*
Отправлено: Gregory от Октября 18, 2002, 04:46:00 pm
Olej, а у вас нульмодемный шнурок трехпроводной или используются все сигналы RS232 ?


Название: TCP/IP over /dev/ser*
Отправлено: olej от Октября 18, 2002, 07:15:00 pm

Gregory пишет:
Olej, а у вас нульмодемный шнурок трехпроводной или используются все сигналы RS232 ?

Я пробовал и то и другое (3-мя прость висящими проводами у меня соединены /dev/ser1 & /dev/ser2 на одном компе, а для соединения 2-х я "по-чесному" использовал "магазинный" нуль-модемный кабель, хотя кто его знает, какое: 3-х, 5-ти или 7-ми проводное там у них соединение...). Как я понимаю, если простая передача потоком через /dev/ser:
#cp xxx /dev/ser1
#cat /dev/ser2
- идёт, то соединение есть, и не должно ни на что влиять. По 3-х проводной линии - есть!


Название: TCP/IP over /dev/ser*
Отправлено: Gregory от Октября 18, 2002, 07:49:00 pm
У меня тоже 3х проводной. Но как мне кажется то что я наблюдаю не соответсвует скорости 57600 бпс.
Как вобще можно посмтореть скорость передачи информации?
cp -V кажет тока проценты..
А... Есть предположение попробовать time cp //1/xxx //2/yyy/
Пойду проверять.


Название: TCP/IP over /dev/ser*
Отправлено: dmi от Октября 18, 2002, 08:17:00 pm
Тут немного открывается "истина": devn-fd писался для то-ли автоответчиков, то-ли для факсов. Суть в том, что он не поддерживает пакетную передачу данных.
В 6.2.1 будет новая версия devn-fd.so с поддержкой передачи пакетных данных. Т.е., возможно, по нему будет работать даже qnet.
Используется вроде бы механизмы из PPP.

В QNX4 вы никогда не увидите ничего похожего на 56К - увидите либо больше, либо меньше. Во-первых используется HDLC для передачи пакетных данных ( как это то по-русски называется -bit/byte stuffing ? ). Во вторых используется компрессия при передаче данных.
Так что там-то как раз все более чем просто хорошо. И FLEET (qnet для QNX4) работает...


Название: TCP/IP over /dev/ser*
Отправлено: Gregory от Октября 19, 2002, 03:13:00 am
Вот, проверил.
cp -V всетаки показывает скорость в kb/s. Эт я не туда смотрел.
А time показало, что файл размером 960кб копировался с узла1 на узел2
187 с. Итого 960*1024*8/127=42055. Плюс наверное расход на всякие CRC и заголовки пакетов. Вобщем зря я переживал.