Связь с контроллером ПЛК110-24.30.Р-М(М02) по ModbusТСР [Архив]

Серджиус

08.08.2018, 13:19

Добрый день.
У меня на руках есть 2 контроллера: ПЛК110-24.30.Р-М(М02) и ПЛК110-24.30.Р-М(старая версия). Есть задача прикрутить ПЛК110-24.30.Р-М(М02) к контроллеру сименс S7-315 по ModbusТСР. На сименсе накидал функциональный блок для связи по ModbusТСР, сконфигурировал соединение, прогрузил и подключил к нему ПЛК110-24.30.Р-М(старая версия). На ПЛК110 тоже все сконфигурировал и прогрузил. Все заработало! Меняю ПЛК110-24.30.Р-М(старая версия) на ПЛК110-24.30.Р-М(М02), конфигурирую его, прогружаю. Не устанавливается связь между ним и сименс S7-315. Обратно меняю, все прекрасно работает. Запустил анализатор траффика и вижу, что когда S7-315 отправляет ARP-запрос новому ПЛК110, он на него не отвечает, а со старым ПЛК110 таких проблем нет.
Вопрос: Возможно ли вообще связать ПЛК110-24.30.Р-М(М02) с сименсом по ModbusТСР? Или это вообще невозможно?

Евгений Дударев

08.08.2018, 13:26

1. Укажите версии встроенного ПО для ПЛК110 М02.
2. Связь устанавливаете через конфигурацию ПЛК или через биб-ку для работы через"сокеты"?

Серджиус

08.08.2018, 13:34

Версия 0.3.52, но недавно приехал еще один с более новой версией. Его я тоже пробовал, он также не пошел (версия 0.3.67).
Связь конфигурирую в разделе "Конфигурация ПЛК", т.е. добавляю Modbus Slave и TCP.

Трофимов Артем

08.08.2018, 13:40

рекоммендую обновить ПЛК до актуальных прошивок 0.3.73
http://www.owen.ru/catalog/codesys_v2/73292499

Евгений Дударев

08.08.2018, 14:03

С точки зрения настроек через конфигурацию для обмена по ТСР - разницы между новым и старым ПЛК нет.
Обновитесь на последнюю версию встроенного ПО для начала всё-таки. Если связь не появится, то приложите проект для проверки.

Серджиус

08.08.2018, 14:21

Обновил версию, связи так и нет. Проект для проверки какой нужен? На новый ПЛК или на STEP7 тоже надо?

Трофимов Артем

08.08.2018, 14:29

а с любого ОРС сервера поднимается связь с ПЛК? IP адрес на новом ПЛК установлен нужный для сети S7?

Евгений Дударев

08.08.2018, 14:33

Серджиус

08.08.2018, 14:36

Адреса разумеется правильные. Связь с ОРС я не пробовал, но я описывал ModbusТСР на C#, с моей прогой связь работает.

Серджиус

08.08.2018, 14:42

Вот проект. 38303

Евгений Дударев

08.08.2018, 15:02

Проект абсолютно верный, ошибок нет.
В плк110 и плк110м02 может быть реализован различный стек TCP/ip. Подожём мнения разработчиков.

IVM

08.08.2018, 15:04

Проект для ПЛК110 нужен.
Также поддерживаю идею опросить ПЛК110 при помощи ОРС сервера (например, Master OPC) - если связь будет, то придётся глубже капать касательно вопроса с Siemens...

При чем тут Siemens если обмен между Siemens и ПЛК110-24.30.Р-М идет.Тут проблема с ПЛК110-24.30.Р-М[М02].

Серджиус

08.08.2018, 16:38

Серджиус

08.08.2018, 16:56

Кстати, вот еще фишка! Запускаю анализатор трафика у себя на компе, и выкидываю ARP-запрос от адреса сетевки моего компа - ПЛК отвечает. Меняю Адреса в этом пакете запроса на адреса коммуникационника сименса - и все глухо! Ответа в сеть он не выкидывает! Что за фантастика? Как такое может быть? Просто не понимаю!!!

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

09.08.2018, 08:34

Я совсем забыл, еще я пробовал связаться с этим плк из WinCC Flexible, который установлен на компьютере - связь есть. Работает нормально. Вообще смешно конечно, но возникает такое ощущение, будто у этого плк есть файервол с фильтром по МАС адресам :)

Фильтр по MAC есть на некоторых свичах.
Нужен лог обмена, так гадать можно до посинения, тем более что с некоторыми мастерами связь есть.

Серджиус

09.08.2018, 08:53

Сегодня попробовал настроить связь через шлюз (шлюз - мой комп с 2 сетевками) - со старым контроллером связь есть, а с новым нет. Контроллеры в сети ведут себя по-разному. Так что дело не в МАС адресах. А то что на счет ARP, то видимо Wireshark регистрировать не успевает.

_Алексей_

09.08.2018, 13:46

Может разработчики версии [М02] ПЛК110, подскажут в чем тут дело или они очень далеко?:D

Евгений Дударев

09.08.2018, 14:05

Фильтр по MAC есть на некоторых свичах.
Нужен лог обмена, так гадать можно до посинения, тем более что с некоторыми мастерами связь есть.

Лог обмена хочется увидеть всё-таки... желательно для "старого" и "нового".

Серджиус

09.08.2018, 14:38

Пытаюсь загрузить сюда архив, а мне пишет:
Logs.rar - Загрузка файла прошла неудачно.
Размер 5,19 Мб.

Серджиус

09.08.2018, 14:42

https://yadi.sk/d/CAC6JaK53a4sVL
Логи тут

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

09.08.2018, 15:02

О, ну как так можно, обращаться к ПЛК, находящемуся в другой подсети и надеяться на ответ? Какие маски выставлены? Приведите IP в одну подсеть
И кольцо в сети в логах видится, дикие ретрансмисии с огромной скоростью.

Оба, по факту, не работают.

Серджиус

09.08.2018, 16:16

Контроллер Овен - 10.2.28.126/23, адрес шлюза 10.2.28.125. Шлюз с одной стороны 10,2,28,125/23, с другой 192.168.10.1/24. Сименс - 192.168.10.45/24, адрес шлюза 192.168.10.1.
Со старым есть связь, а с новым нет связи!!!
Я конечно могу выставить как положено в одну подсеть, но тогда в логах будет так: со старым кое-что будет записываться, а с новым будет только постоянное ARP-request от сименса.
Это я просматривал и на wireshark, и на iris network traffic analyzer.

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

09.08.2018, 19:39

Вас не смутило, что на 1 нормальный пакет 200 ретрансмиссий? ПЛК М02 просто отсеивает часть пакетов, что не успевает обработать и поэтому связи нет.
На старых ПЛК (без ОС), обрабатывались все пакеты, нельзя было отфильтровать избыточные, это приводило с торможению основной программы.

Для начала установите связь без шлюза, и устраните закольцовывание

Серджиус

10.08.2018, 13:25

Для начала установите связь без шлюза
Изначально я так и делал, только я как правило пакетов не вижу, поэтому решил пропустить через шлюз, чтобы мог перехватить их.

и устраните закольцовывание
Не могу понять откуда оно может взяться.38335
Посмотрел сегодня логи - да, это реально непонятки.
Восстановил все обратно, работает все как и было: со старым есть связь, с новым нет связи.
Я конечно выложил бы лог изначальной схемы, но к сожалению перехватываю только ARP пакеты, смотреть нечего :(
На следующей неделе попробую связать Овен с S7-400, а то для 300 нет другого коммуникационника.

_Pavel_

10.08.2018, 15:08

ПЛК М02 просто отсеивает часть пакетов, что не успевает обработать и поэтому связи нет.
На старых ПЛК (без ОС), обрабатывались все пакеты, нельзя было отфильтровать избыточные, это приводило с торможению основной программы.

Владислав, правильно ли я понимаю что ПЛК-110М02 может отбросить часть пакетов идущих к нему по TCP/IP и пользователь (сокет) об этом не узнает? Соединение не будет разорвано?

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

11.08.2018, 20:01

Владислав, правильно ли я понимаю что ПЛК-110М02 может отбросить часть пакетов идущих к нему по TCP/IP и пользователь (сокет) об этом не узнает? Соединение не будет разорвано?

В ПЛК аппаратно выставлено прореживание пакетов на уровне, ЕМНИП, 2000 пакетов в секунду.
Соединение при пропаже 1 пакета не рвется.

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

13.08.2018, 08:28

Вот я наверно тупой, но каким боком это именно к TCP ?

Я не могу дистанционно оценивать интеллектуальный уровень. Однако TCP пакеты это подмножество пакетов Ethernet

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

13.08.2018, 12:30

Когда малыш не ест кашу, то мамаше без разницы сколько каши окажется на полу. Нужное кол-во каши всё равно будет в животике. С TCP тоже самое.
Соббсно и спросил - каким боком к TCP ?

Как объяснить то, попроще.

Вот есть стена, это соединение TCP/IP, каждый кирпич - пакет.
Вынимаем один кирпич - стена стоит.
Вынимаем каждый 10-й - стоит.
Вынимаем каждый 2-й - шатается, но стоит.
Вынимаем 9 из 10 - всё, завалило кирпичами.

Так и тут.

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

13.08.2018, 13:50

Ну не позорьтесь, тов. Валенок. От одного пропуска TCP не валится.
А вот почему в человека такие дикие ретрансмисии - это вопрос вопросов

Серджиус

13.08.2018, 18:24

2000 пакетов в секунду
Это конечно великолепно, а что если потребуется подсоединить еще один МодбасТСР мастер, но на другой порт. Т.е. в конфигурации ПЛК делаю еще один МодбасСлейв (ну скажем порт 503) и цепляюсь до него. Ограничение пакетов может обрезать все это дело?
Кстати про закольцованность: может я чего упустил, но в каком месте она может быть? Я ведь так и не понял... (схему собранной сети выслал). Неужели нет вариантов?
ЗЫ
Сегодня скидал проект на сименс S7-315-2PN/DP (у него ethernet на борту, связь через Open TCP/IP Communication), работают оба варианта ОВЕНа. Там прогу мою на семена пришлось маленько переделывать, но вот теперь даже и не знаю, дело в том коммуникационнике, с которым изначально работал, или так он и должен работать (тогда связь с новым ПЛК М02 - облом).

Серджиус

13.08.2018, 18:52

Вообще задание было связать с S7-315-2PN/DP со всеми прелестями, но этих ПЛК М02 должно быть штук 5-7, которых пока нет. Если каждый из них отсеивает пакеты, то какая гарантия, что связь будет со всеми 5-7, если они какие-то пакеты будут откидывать?

_Pavel_

13.08.2018, 22:10

Как объяснить то, попроще.

Вот есть стена, это соединение TCP/IP, каждый кирпич - пакет.
Вынимаем один кирпич - стена стоит.
Вынимаем каждый 10-й - стоит.
Вынимаем каждый 2-й - шатается, но стоит.
Вынимаем 9 из 10 - всё, завалило кирпичами.

Так и тут.

Владислав, может я туплю, но развейте пожалуйста, мои сомнения и опасения за реализацию протокола TCP в ПЛК 110М02:
Правильно я вас понял, если в ПЛК придёт 2000 пакетов за секунду, то 2001-ый пакет будет отброшен аппаратно и об этом никак не узнает ни тот кто этот пакет передавал, ни на борту ПЛК, то есть свойство протокола TCP - гарантированность доставки и последовательности пакетов будет нарушено?

_Pavel_

14.08.2018, 08:57

)))
Юзер же получает только непрерывные последовательные серии пакетов. Т.е. несмотря на возможное наличие в системном буфере уже 2002...2100-ого - юзер об этом не знает и знать не может. Как только система получит 2001-й то тут же передаст юзеру сразу 2001..2100й.
.

Спасибо! )) Я собственно так и думал, просто Владислав как-то невнятно разьяснил этот момент. Создалось ощущение, что при определённом потоке TCP станет не TCP :) Уфф....

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

14.08.2018, 10:19

Это конечно великолепно, а что если потребуется подсоединить еще один МодбасТСР мастер, но на другой порт. Т.е. в конфигурации ПЛК делаю еще один МодбасСлейв (ну скажем порт 503) и цепляюсь до него. Ограничение пакетов может обрезать все это дело?
Кстати про закольцованность: может я чего упустил, но в каком месте она может быть? Я ведь так и не понял... (схему собранной сети выслал). Неужели нет вариантов?
ЗЫ
Сегодня скидал проект на сименс S7-315-2PN/DP (у него ethernet на борту, связь через Open TCP/IP Communication), работают оба варианта ОВЕНа. Там прогу мою на семена пришлось маленько переделывать, но вот теперь даже и не знаю, дело в том коммуникационнике, с которым изначально работал, или так он и должен работать (тогда связь с новым ПЛК М02 - облом).

2000 пакетов в секунду - это over_много. В обычной ситуации прореживание никогда не срабатывает.

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

14.08.2018, 10:21

Владислав, может я туплю, но развейте пожалуйста, мои сомнения и опасения за реализацию протокола TCP в ПЛК 110М02:
Правильно я вас понял, если в ПЛК придёт 2000 пакетов за секунду, то 2001-ый пакет будет отброшен аппаратно и об этом никак не узнает ни тот кто этот пакет передавал, ни на борту ПЛК, то есть свойство протокола TCP - гарантированность доставки и последовательности пакетов будет нарушено?

Свойство протокола TCP достигается не отсутствием потерь пакетов в сети (что происходит практически всегда), а повторами.
А вот если будет теряться больше определённого % пакетов (для указанных окон и таймаутов), то связи не будет.

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

14.08.2018, 10:24

))) Гарантированность доставки и последовательности в TCP это не "зуб даю все пакеты придут", а "долбиться запросами хоть отдельно, хоть в составе с чем-то, пока не будет подтверждений на всё что отправлено".

Юзер же получает только непрерывные последовательные серии пакетов. Т.е. несмотря на возможное наличие в системном буфере уже 2002...2100-ого - юзер об этом не знает и знать не может. Как только система получит 2001-й то тут же передаст юзеру сразу 2001..2100й.

Именно поэтому отбрасывание 2001-ого и кучи других для TCP - по барабану. Да хоть ограничение в 1 пакет в секунду. Просто будет о-о-о-о-чень ме-е-е-едленный ка-а-а-нал.

И что значит отбрасывание ? Если переполнен системный буфер (фрагментацией или юзер не забрал) то система получателя отпишется отправителю - "мужик, не гони, покури покедова"

И именно поэтому и просил Филоненко объяснить - каким макаром именно на TCP может влиять отбрасывание каких-то там пакетов. Пока непонятно каким боком стены без кирпичей.

И опять великая паника. От незнания.
То тумблеры сами выключались, теперь всё пропало в Ethernet.
Делать спецверсию стека TCP/IP, имени тов. Валенка?

Серджиус

14.08.2018, 14:25

Сегодня скидал проект на сименс S7-315-2PN/DP (у него ethernet на борту, связь через Open TCP/IP Communication), работают оба варианта ОВЕНа.
Сегодня попробовал заменить коммуникационник на 300 сименс (нашел такой же, но чуть постарше, рабочий 100%) результат не изменился - со старым есть связь, с новым нет. Собрал корзину S7-400 с коммуникационником и запустил - результат остался прежним.
Отсюда напрашивается вывод:
Если вдруг понадобится подключить ПЛК110М02 через МодбасТСР к сименсу 300 или 400 через коммуникационник Ethernet CP, то ничего хорошего ждать не стоит. А если к сименсу с езернетом на борту (типа S7-315-2PN/DP, связь через Open TCP/IP Communication), то м.б. и поедет.

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

15.08.2018, 09:16

У кого ? У Вас ? И всё из-за нескольких кирпичей ?

Как TCP падает без нескольких кирпичей - да. Не знаю. Это великая тайна.

))) Так это вы же регулярно и делаете. Очередные прошивки. С очередными траблами.

Не, ну со очередными прошивками стараетесь конечно. Но все как-то им г-на Филоненко получается.

http://www.owen.ru/forum/showthread.php?t=28065
Супер-тумблер. Не, потом канешна спецверсия с очередной прошивкой ))

У меня пропало ? Чего-то попутали. Это у Вас 2001-й кирпич украли

Видимо, сильно подгорело, тов. Валенок, раз переходите на личности и абсцентную лексику. И зачем мы ПЛК приделывали губы Валенка?

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

15.08.2018, 09:19

Сегодня попробовал заменить коммуникационник на 300 сименс (нашел такой же, но чуть постарше, рабочий 100%) результат не изменился - со старым есть связь, с новым нет. Собрал корзину S7-400 с коммуникационником и запустил - результат остался прежним.
Отсюда напрашивается вывод:
Если вдруг понадобится подключить ПЛК110М02 через МодбасТСР к сименсу 300 или 400 через коммуникационник Ethernet CP, то ничего хорошего ждать не стоит. А если к сименсу с езернетом на борту (типа S7-315-2PN/DP, связь через Open TCP/IP Communication), то м.б. и поедет.

т.е. пакеты генерит Ethernet CP? А если между ним и ПЛК поставить обычный свитч?
Нет ли у Ethernet CP какой-либо настройки ретрансмиссий? Возможно он ждет такой же Ethernet CP, к-й обязан отвечать через 100 мкс? А раз нет ответа, то снова и снова посылки?

Серджиус

15.08.2018, 09:38

т.е. пакеты генерит Ethernet CP?
выходит так

А если между ним и ПЛК поставить обычный свитч?
делал через свитч, без него напрямую обычным патч-кордом, напрямую обычным кросс-патч-кордом

Нет ли у Ethernet CP какой-либо настройки ретрансмиссий?
Нет. Такого даже близко нет.

Возможно он ждет такой же Ethernet CP, к-й обязан отвечать через 100 мкс?
В конфигурации сети (NetPro) у меня сконфигурировано соединение с любой станцией (любая - т.е любая, лишь бы совпадал ИП и был открыт 502 порт) по ТСР 502 порт и ИП 192.168.10.40

А раз нет ответа, то снова и снова посылки?
логично

ЗЫ
Сегодня получил ПЛК100, с S7-400 связь есть.

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

15.08.2018, 09:50

выходит так

делал через свитч, без него напрямую обычным патч-кордом, напрямую обычным кросс-патч-кордом

А что на форумах Симы говорят?

Серджиус

15.08.2018, 10:34

А что на форумах Симы говорят?
По поводу чего? Как конфигурируется сеть в NetPro? Так это я и так знаю, как бы не впервой :D, кроме того у меня есть пример проекта с обменом по МодбасТСР от сименса (в смысле пример от них). Я его запускал у себя (у меня контроллер тот же, что и в семена проекте) - результат, я думаю, понятен. Короче проект семена и мой работают с овеном одинаково.

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

15.08.2018, 12:51

По поводу чего? Как конфигурируется сеть в NetPro? Так это я и так знаю, как бы не впервой :D, кроме того у меня есть пример проекта с обменом по МодбасТСР от сименса (в смысле пример от них). Я его запускал у себя (у меня контроллер тот же, что и в семена проекте) - результат, я думаю, понятен. Короче проект семена и мой работают с овеном одинаково.

По поводу ретрансмиссий. Явно это не нормально.

Серджиус

15.08.2018, 13:32

По поводу ретрансмиссий. Явно это не нормально.
Ну тут напрашивается вывод, что это генерирует сам Ethernet CP.
Тут дело такое: Если используется Ethernet CP, то связь конфигурируется через NetPro, и контроллер сам пытается ее установить вне зависимости от того, используются ли функции для работы с сетью (т.е. от меня это не зависит). А вот если используется Open TCP/IP Communication, тогда я в программе сам определяю когда мне надо законнектиться и когда отключиться. Вот например сейчас я немного изменил программу (функции связи не вызываются), гляжу NetPro онлайн - соединение установлено! Стало быть для Ethernet CP это нормально.
Я конечно напишу на форум про это дело, как ответят, отпишусь.

Серджиус

15.08.2018, 13:54

По поводу ретрансмиссий. Явно это не нормально.
Владислав, а вы считаете, что у меня все коммуникационники нерабочие?

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

16.08.2018, 08:56

Я подозреваю, что попытки переподключится по 3 раза за мс - это ЖЖЖ неспроста. Обычное Ethernet устройство так себя не ведет, таймаут на ретрансмиссию от 200 до 30000 мс.
Значит CP работает в режиме RealtimeEthernet, когда весь канал отдан по сути под одно соединение и можно ожидать (при соотв. аппаратной поддержке) времени ответа на уровне десятков мкс.

The standard CP 343-1 is used to connect the SIMATIC S7-300 to Industrial Ethernet In addition to communication with other Ethernet stations (т.е. как slave?), the CP as PROFINET IO controller or as IO device connects distributed I/O modules.
Как мы видим, CP может работать и как средство доступа к IO, где важна скорость ответа и как устройство доступа к обычным TCP/IP устройствам.
Однако режимы работы явно различаются.
P.S. Почитал про CP модули - они же для IndustrialEthernet сделаны, про обычный Ethernet не нашёл. Там совсем другие тайминги.
P.P.S. Стек на старых ПЛК весьма ограниченный, возможно он эти ретрансмиссии вообще игнорирует, т.к. у него в принципе нет окна и не надо обрабатывать out-of-order пакеты.

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

16.08.2018, 09:27

Посмотрел ещё раз логи.
Похоже дело в несоответствии CP стандарту TCP/IP соединения.

По стандарту, после посылки Syn клиент должен дождаться SYN,ASK, послать в ответ ASK и после этого начать обмен.

В реальности, после посылки SYN, CP, не дожидаясь ASK, начинает слать SYN снова и снова, уменьшая TTL при каждой посылке.
Стек старого ПЛК настолько тупой, что не реагирует на нарушение стандарта и всё же высылает SYN,ASK на каждый SYN, и обмен, со скрипом идёт.
Более продвинутый стек фиксирует нарушение и не выдаёт SYN,ASK 118 раз, а при достижении TTL=1 ретрансмиссии прекращаются (что логично, пакет на следующем гапе умер).
И спустя паузу, не видя ASK (а пакет потерялся) ПЛК резетит соединение.

Что ясно.
1. Где-то есть петля, из-за которой пакеты раз за разом возвращаются с уменьшающимся TTL.
2. Пока в сети идут ретрансмиссии, ответ с ПЛК в принципе не доходит (что в старом, что в новом), он "теряется" где-то по пути.
3. Т.о. ответ SYN,ASK от нового ПЛК теряется, SYN,ASK от старого ПЛК в силу простоты стека дублируется 118 раз и 118-й таки может достичь адресата, т.к. ретрансмисии заканчиваются "естественным" образом
4. Запросы от сименса доходят до ПЛК и он генерит ответ, но ответ "затирается" штормом ретрансмиссий
5. Ответ ПЛК в петлю не попадает (что позволяет предположить, что петля программная, в CP)

Что можно сделать?
1. Убрать петлю, если удастся понять где она.
2. Снизить TTL до 1 - тогда ретрансмиссий не будет, а пакеты вс1 еще смогут при локальном соединении достичь ПЛК и вернуться.

P.S. "оглупление стека делать не будем"

Серджиус

16.08.2018, 13:07

Что можно сделать?
1. Убрать петлю, если удастся понять где она.
Развернул на ноуте МодбасТСР клиента и подключил к нему S7-400. Записал лог. Ретрансмиссий нет.38378
Думаю, что все дело в сетевке моего компа. А проблема подключения S7-400 к новому ПЛК, который я цеплял напрямую разными паткордами, существует. Как с этим быть?

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

16.08.2018, 14:38

Развернул на ноуте МодбасТСР клиента и подключил к нему S7-400. Записал лог. Ретрансмиссий нет.38378
Думаю, что все дело в сетевке моего компа. А проблема подключения S7-400 к новому ПЛК, который я цеплял напрямую разными паткордами, существует. Как с этим быть?

Вопрос лога поднимается опять. Хочется увидеть что с обменом. Как-то надо снять лог.

Серджиус

16.08.2018, 17:13

Вопрос лога поднимается опять. Хочется увидеть что с обменом. Как-то надо снять лог.

Завтра попробую снять лог, но придется опять через шлюз. А то Wireshark ничего кроме арпа не фиксирует.

Серджиус

17.08.2018, 09:54

Сегодня снял лог через шлюз.
38384

Серджиус

17.08.2018, 18:33

Что-то разработчики молчат :(

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

20.08.2018, 09:10

Что-то разработчики молчат :(
Не было меня в пятницу.
Ну что я могу сказать? При связи с М02 ретрансмиссии никуда не делись. И опять пропадают ответы от М02.
Не сложно будет назначить такой же IP ноуту и заместо S7 через ту же конфигурацию сети послать запрос к ModBus Slave ПЛК?

Серджиус

20.08.2018, 11:57

Ну что я могу сказать? При связи с М02 ретрансмиссии никуда не делись. И опять пропадают ответы от М02.
Где ретрансмиссии? Уменьшения TTL нет. Может это просто повторный запрос?
Скорее М02 сбрасывает соединение.

Не сложно будет назначить такой же IP ноуту и заместо S7 через ту же конфигурацию сети послать запрос к ModBus Slave ПЛК?
Готово. 38401

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

20.08.2018, 12:22

хм.С ноутбуком связь есть. всё хорошо.
Разница видна в ширине окна.
У S7 ширина окна равна 0, т.е. данные s7 принимать не может.
Поэтому ПЛК их и не шлёт, ждет кгда придёт пачка с окном>0. И рвет соединение по таймауту
Windows сообщает при SYNC окно 65535 - это нормально, нормально было бы любое число от 64 байт.

http://www.freepascal.ru/forum/viewtopic.php?f=13&t=24743

Владимир Ситников

20.08.2018, 13:00

У S7 ширина окна равна 0, т.е. данные s7 принимать не может.
Поэтому ПЛК их и не шлёт, ждет кгда придёт пачка с окном>0. И рвет соединение по таймауту

Не шлёт -- не вопрос.
Почему М02 на SYN не отвечает-то? Вы что, считаете, что SYN+ACK это данные?

Видно же по трейсу со старым ПЛК110, что после получения ACK'а S7 сигнализирует окно 2048.

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

20.08.2018, 13:57

Не шлёт -- не вопрос.
Почему М02 на SYN не отвечает-то? Вы что, считаете, что SYN+ACK это данные?

Видно же по трейсу со старым ПЛК110, что после получения ACK'а S7 сигнализирует окно 2048.

Window=0 , т.е. передавать нельзя, теоретически. Старый имеет упрощённый стек и такое не обрабатывает.
Конечно, SYN+ASK это данные. 64 байта, это не я думаю, а RFC

Владимир Ситников

20.08.2018, 15:14

Window=0 , т.е. передавать нельзя, теоретически
Уважаемый, вы путаете.

это не я думаю, а RFC
Ссылку в студию!

38406

Note that when the receive window is zero no segments should be
acceptable except ACK segments. Thus, it is be possible for a TCP to
maintain a zero receive window while transmitting data and receiving
ACKs. However, even when the receive window is zero, a TCP must
process the RST and URG fields of all incoming segments.

В RFC 793 есть и про "zero window probe" (хотя, и фрагмент выше явно разрешает нормальную работу TCP соединения с receive window=0):

The segment sent to probe a zero window may also begin a break up
of transmitted data into smaller and smaller segments. If a
segment containing a single data octet sent to probe a zero window
is accepted, it consumes one octet of the window now available.
If the sending TCP simply sends as much as it can whenever the
window is non zero, the transmitted data will be broken into
alternating big and small segments. As time goes on, occasional
pauses in the receiver making window allocation available will
Переводя на русский, даже когда receive window=0, то всё равно допускается отправлять туда тестовый байт, чтобы проверить "а не изменилось ли окно".
Вот пример: https://github.com/tass-belgium/picotcp/issues/126

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

21.08.2018, 09:24

Вот кусочек комментария
//it might happen that we do not
// send back a SYN/ACK for very old stacks that send a zero window size in SYN.

т.о. стек, вероятно, не посылает ASK при размере окна==0.
Является ли это 100% верным или нужно действовать иначе, но имеющийся стек может вести себя так.
Проверить так ли это я не могу, т.к. нет устройства, генерирующего SYN с win=0. Есть ли программы-эмуляторы, где можно принудительно заставить формировать такой SYN?

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

21.08.2018, 09:25

Уважаемый, вы путаете.

В RFC 793 есть и про "zero window probe" (хотя, и фрагмент выше явно разрешает нормальную работу TCP соединения с receive window=0):

Переводя на русский, даже когда receive window=0, то всё равно допускается отправлять туда тестовый байт, чтобы проверить "а не изменилось ли окно".
Вот пример: https://github.com/tass-belgium/picotcp/issues/126

Владимир, даже в Вашем примере прямо сразу видно, что соединение установлено и потом уже win стал ==0. Это нормальная ситуация.
А мы обсуждаем win при SYN

Владимир Ситников

21.08.2018, 10:20

Проверить так ли это я не могу, т.к. нет устройства, генерирующего SYN с win=0. Есть ли программы-эмуляторы, где можно принудительно заставить формировать такой SYN?
Не использовал, но, скорее всего, этот инструмент может такое: https://github.com/secdev/scapy

Владимир Ситников

21.08.2018, 10:23

Владимир, даже в Вашем примере прямо сразу видно, что соединение установлено и потом уже win стал ==0. Это нормальная ситуация.
А мы обсуждаем win при SYN

Этот пример относился к тому, что TCP клиенту **допускается** отправлять данные, даже когда server сигнализирует о нулевом receive window.
Иными словами, нет запретов в духе "ни в коем случае нельзя отправлять данные в соединение с receive window=0".

Если честно, то не понимаю какая такая разница в какой момент receive window стало равно 0. Чем так разительно отличается нулевое окно, возникшее между делом от нулевого окна на этапе старта соединения?