Посмотрел ещё раз логи.
Похоже дело в несоответствии 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. "оглупление стека делать не будем"
Ответить с цитированием