PING удаленного компьютера через Ethernet средствами ПЛК

[Alber]

Если точнее, то я хочу ПЛК 100 пинговать компьютер с виндой
что надо ип вбить понятно а в какой форме и как недопонимаю и что с портом делать (какой вбивать)

[Alber]

web_stat:=1;
sock_adr.sin_addr:=16#0A00065F;
(*IP Адрес опрашиваемого устройства {создается сокет на опрашивающем устройстве}*)
sock_adr.sin_family:=SOCKET_AF_INET;
(*Стек протоколов TCP/IP*)
sock_adr.sin_port:=16#0800;
(*Старший байт- Тип ICMP пакета {08 - Ping} младший байт- код ICMP пакета { 0- Ping}*)
sock_adr1.sin_addr:=16#0A000626;
(*То же самое для функции чтения {в принципе не важно}*)
sock_adr1.sin_family:=SOCKET_AF_INET;
sock_adr1.sin_port:=16#1111;
my_BUFs:='qwertyuiopasdfghjklzxcvbnm123456';
----------------------------------------------------------------------------------
это из примера, а что править!:
вот это sock_adr.sin_addr:=16#0A00065F; тогда как переводить
и вот это sock_adr.sin_port:=16#0800; а здесь 137 как перевести
а это тоже на что то править или не надо sock_adr1.sin_addr:=16#0A000626;
sock_adr1.sin_port:=16#1111;

[Alber]

кажется ясно: надо 16# отбрасывать и без точек в HEXe
но вот в порту стоит впереди 0 тогда 137 будет 0089 или 89 просто!

[Alber]

sock_adr1.sin_addr:=16#0A000626;
sock_adr1.sin_port:=16#1111;
с этим не совсем ясно

[Alber]

все изменил, но ни одного положительного запроса!
(*Время ожидания истекло считываем данные*)
IF FIND(my_BUFr,'pasd')<>0 THEN
suces:=suces+1;
(*Сравниваем переданные и принятые данные в случае идентичности увеличиваем счетчик удачного Ping*)
ELSE
faul:=faul+1;
(*В противном случае увеличиваем счетчик неудачного Ping запроса*)

растет бесконечно faul:=faul+1; а suces:=suces+1; все время равно 0 куда копать!?
Правда есть еще такой параметр как sock_adr.sin_family:=SOCKET_AF_INET; - что он дает? равен 2, может его поменять, а на что тогда?

[sgmj]

Не буду плодить темы напишу здесь. Задача та же - пинговать ПК с ОВЕНа (ПЛК110).

Как основу брал этот же пример.

Есть несколько вопросов и проблем:
1) Я правильно понимаю, что ICMP использует датаграммы (тип коммуникации SOCKET_DGRAM) и общая схема работы клиента на датаграммах такова:
1.1. создаем TCB структуру SOCKADDRESS для сервера (машины, которую будем пинговать) с нужными настройками (serv.sin_addr:= SERV_IP, serv.sin_family:=SOCKET_AF_INEТ, serv.sin_port := ICMP_TYPE_CODE)
1.2. создаем TCB структура SOCKADDRESS для клиента (ПЛК) с такими же настройками, за исключением адреса (client.sin_addr:= PLC_IP, client.sin_family:=SOCKET_AF_INEТ, client.sin_port := ICMP_TYPE_CODE)
1.3. заполняем буфер проверочными данными для отправки (например, 32 байта символов sBuf :STRING := 'abcdefghijklmnopqrstuvwabcdefghi')
1.4. делаем вызов сокета, получаем дескриптор ( sock := SysSockCreate(SOCKET_AF_INET, SOCKET_DGRAM, SOCKET_IPPROTO_ICMP) )
1.5. связываем сокет с адресом клиента ( bindClient := SysSockBind(sock, ADR(client), SIZEOF(client)) )
1.6. пишем буфер в сокет ( bufSend := SysSockSendTo(sock, ADR(sBuffer), 32, 0, ADR(serv), SIZEOF(serv)) )
1.7. дальше пишем в буфер приема rBuf ( recv:=SysSockRecvFrom(sock,ADR(rBuf),32,0,ADR(clie nt),SIZEOF(client)) ), выждав какой то таймаут
1.8. сравниваем содержимое переданного с принятым
?
2) Одиночный пакет с ПЛК уходит нормально, доходит до ПК, WireShark его видит. На первый взгляд с пакетом все ОК - тип 08 (эхо-запрос) , код 00. Но почему то я вижу коды 61("а") и 62 ("b") в качестве идентификатора ICMP пакета и коды 63 64 ("с" "d") в качестве порядкового номера. Это почему так? Я думал, что вся эта возня с структурами SOCKADRESS как раз и должна отделить всякие заголовки от данных из буфера.
2015-04-08 18-03-12 Скриншот экрана (2).png
3) Самая большая проблема сейчас - как видно с того же скрина WireShark`а ПК не хочет слать в ответ ICMP пакет. В чем дело???
4) как работает SysSockRecvFrom? Он может сколько угодно ждать ответа, проверяя буфера сокета на предмет пришедших данных при каждом цикле работы ПЛК?

[Филоненко Владислав]

Пример пинга во вложении.

[sgmj]

Пример пинга во вложении.

Не работает (см. скриншоты). Пакеты на ПК приходят, но ПК на них не отвечает.
адрес ПЛК110-24: 10.8.11.230 (16#0A080BE6)
адрес пингуемого ПК с Windows 7: 10.8.11.104 ( 16#0A080B68)
2015-04-09 10-49-09 Скриншот экрана.png2015-04-09 10-49-53 Скриншот экрана.png

[Yegor]

Вот мой рабочий пинг. ПЛК160 — 10.0.6.10, ПК — 10.0.6.9.

ping.png

3) Самая большая проблема сейчас - как видно с того же скрина WireShark`а ПК не хочет слать в ответ ICMP пакет. В чем дело???

Фаервол?

4) как работает SysSockRecvFrom? Он может сколько угодно ждать ответа, проверяя буфера сокета на предмет пришедших данных при каждом цикле работы ПЛК?

Как и многие другие «поточные» функции, она тут же возвращает число прочитанных байт, даже если это число равняется нулю. Очень удобно на самом деле (см. мой пример). Если, скажем, в примере от Владислава зачем-то делается задержка после отправки запроса, то я легко обхожусь без неё как раз за счёт моментального возврата SysSockRecvFrom.

[sgmj]

Вот мой рабочий пинг. ПЛК160 — 10.0.6.10, ПК — 10.0.6.9.

ping.png

Фаервол?Как и многие другие «поточные» функции, она тут же возвращает число прочитанных байт, даже если это число равняется нулю. Очень удобно на самом деле (см. мой пример). Если, скажем, в примере от Владислава зачем-то делается задержка после отправки запроса, то я легко обхожусь без неё как раз за счёт моментального возврата SysSockRecvFrom.

Спасибо большое за пример - хорошо структурирован. Что значит "поточные"? SysSockRecvFrom - аналог обычной recvfrom как я понимаю. Работает на дейтаграммах, без установления соединения. У Владислава сделана задержка (как я понял) для того, чтобы с учетом задержки ответа не вызывать в каждом цикле ПЛК SysSockRecvFrom.
Но Ваш вариант в общем мне больше нравится. Но ПК все равно не отвечает (см.скрин) - если это файерволл ПК, то почему обычный пинг с ПК на ПЛК проходит*. И кстати, Вас не смущает, что первые четыре байта (30 31) (32 33) приходят в поле идентификатора и порядкового номера?2015-04-09 12-43-40 Скриншот экрана.png2015-04-09 12-42-57 Скриншот экрана.png