Страниц: 1 2 3 [4] 5
  Печать  
Автор Тема: TCP/IP over /dev/ser*  (Прочитано 44674 раз)
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #45 : Августа 13, 2002, 09:27:00 pm »


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

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

Сообщений: 73


Просмотр профиля
« Ответ #46 : Августа 13, 2002, 10:30:00 pm »


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


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

[ Это Сообщение было отредактировано: Evgeniy в 2002-08-13 19:31 ]
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #47 : Августа 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 ]
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #48 : Августа 13, 2002, 11:38:00 pm »

dmi - что за фигня: я правлю уже 5 раз предыдущее сообщение - собственно, заголовок функции (который и создаёт такую безумную ширину страницы) - и ничего не правится!

Может ты ему можешь что-то вправить?!
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #49 : Августа 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 - пока сплошное безумие...
Записан
vlad
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #50 : Октября 01, 2002, 04:11:00 pm »

А не пробывал ли кто запустить IP через usb???
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #51 : Октября 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... Лишь бы электрически передача точка-точка осуществлялась!
Записан
Landy
Jr. Member
**
Offline Offline

Сообщений: 65


Просмотр профиля WWW
« Ответ #52 : Октября 01, 2002, 06:09:00 pm »


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

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

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

Сообщений: 0


Просмотр профиля
« Ответ #53 : Октября 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!
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #54 : Октября 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 с сетевыми прогами делать нечего!
Записан
vlad
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #55 : Октября 01, 2002, 08:44:00 pm »


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

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

Сообщений: 42



Просмотр профиля
« Ответ #56 : Октября 01, 2002, 09:30:00 pm »


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

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

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

[ Это Сообщение было отредактировано: Olej в 2002-10-01 18:35 ]
Записан
Landy
Jr. Member
**
Offline Offline

Сообщений: 65


Просмотр профиля WWW
« Ответ #57 : Октября 02, 2002, 11:22:00 am »


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

Дык - на фтп лежит qnx.org.ru
Чего ждать-то?!
Записан
vlad
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #58 : Октября 02, 2002, 03:16:00 pm »


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

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

Сообщений: 65


Просмотр профиля WWW
« Ответ #59 : Октября 02, 2002, 04:29:00 pm »


vlad пишет:

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

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

Дык там образ подмонтирован - возьми что нужно из repository
Записан
Страниц: 1 2 3 [4] 5
  Печать  
 
Перейти в: