А что на форумах Симы говорят?Цитата:
Сообщение от Серджиус
Вид для печати
А что на форумах Симы говорят?Цитата:
Сообщение от Серджиус
По поводу чего? Как конфигурируется сеть в NetPro? Так это я и так знаю, как бы не впервой :D, кроме того у меня есть пример проекта с обменом по МодбасТСР от сименса (в смысле пример от них). Я его запускал у себя (у меня контроллер тот же, что и в семена проекте) - результат, я думаю, понятен. Короче проект семена и мой работают с овеном одинаково.Цитата:
А что на форумах Симы говорят?
По поводу ретрансмиссий. Явно это не нормально.Цитата:
Сообщение от Серджиус
Ну тут напрашивается вывод, что это генерирует сам Ethernet CP.Цитата:
По поводу ретрансмиссий. Явно это не нормально.
Тут дело такое: Если используется Ethernet CP, то связь конфигурируется через NetPro, и контроллер сам пытается ее установить вне зависимости от того, используются ли функции для работы с сетью (т.е. от меня это не зависит). А вот если используется Open TCP/IP Communication, тогда я в программе сам определяю когда мне надо законнектиться и когда отключиться. Вот например сейчас я немного изменил программу (функции связи не вызываются), гляжу NetPro онлайн - соединение установлено! Стало быть для Ethernet CP это нормально.
Я конечно напишу на форум про это дело, как ответят, отпишусь.
Владислав, а вы считаете, что у меня все коммуникационники нерабочие?Цитата:
По поводу ретрансмиссий. Явно это не нормально.
Я подозреваю, что попытки переподключится по 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 пакеты.
Посмотрел ещё раз логи.
Похоже дело в несоответствии 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. "оглупление стека делать не будем"
Развернул на ноуте МодбасТСР клиента и подключил к нему S7-400. Записал лог. Ретрансмиссий нет.Вложение 38378Цитата:
Что можно сделать?
1. Убрать петлю, если удастся понять где она.
Думаю, что все дело в сетевке моего компа. А проблема подключения S7-400 к новому ПЛК, который я цеплял напрямую разными паткордами, существует. Как с этим быть?
Вопрос лога поднимается опять. Хочется увидеть что с обменом. Как-то надо снять лог.Цитата:
Сообщение от Серджиус
Завтра попробую снять лог, но придется опять через шлюз. А то Wireshark ничего кроме арпа не фиксирует.Цитата:
Сообщение от Филоненко Владислав
Сегодня снял лог через шлюз.
Вложение 38384
Что-то разработчики молчат :(
Не было меня в пятницу.Цитата:
Сообщение от Серджиус
Ну что я могу сказать? При связи с М02 ретрансмиссии никуда не делись. И опять пропадают ответы от М02.
Не сложно будет назначить такой же IP ноуту и заместо S7 через ту же конфигурацию сети послать запрос к ModBus Slave ПЛК?
Где ретрансмиссии? Уменьшения TTL нет. Может это просто повторный запрос?Цитата:
Сообщение от Филоненко Владислав
Скорее М02 сбрасывает соединение.
Готово. Вложение 38401Цитата:
Сообщение от Филоненко Владислав
хм.С ноутбуком связь есть. всё хорошо.
Разница видна в ширине окна.
У S7 ширина окна равна 0, т.е. данные s7 принимать не может.
Поэтому ПЛК их и не шлёт, ждет кгда придёт пачка с окном>0. И рвет соединение по таймауту
Windows сообщает при SYNC окно 65535 - это нормально, нормально было бы любое число от 64 байт.
http://www.freepascal.ru/forum/viewt...p?f=13&t=24743
Не шлёт -- не вопрос.Цитата:
Сообщение от Филоненко Владислав
Почему М02 на SYN не отвечает-то? Вы что, считаете, что SYN+ACK это данные?
Видно же по трейсу со старым ПЛК110, что после получения ACK'а S7 сигнализирует окно 2048.
Window=0 , т.е. передавать нельзя, теоретически. Старый имеет упрощённый стек и такое не обрабатывает.Цитата:
Сообщение от Владимир Ситников
Конечно, SYN+ASK это данные. 64 байта, это не я думаю, а RFC
Уважаемый, вы путаете.Цитата:
Сообщение от Филоненко Владислав
Ссылку в студию!Цитата:
Сообщение от Филоненко Владислав
Вложение 38406
Цитата:
Сообщение от RFC793
В RFC 793 есть и про "zero window probe" (хотя, и фрагмент выше явно разрешает нормальную работу TCP соединения с receive window=0):
Переводя на русский, даже когда receive window=0, то всё равно допускается отправлять туда тестовый байт, чтобы проверить "а не изменилось ли окно".Цитата:
Сообщение от RFC793
Вот пример: https://github.com/tass-belgium/picotcp/issues/126
Вот кусочек комментария
//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?
Владимир, даже в Вашем примере прямо сразу видно, что соединение установлено и потом уже win стал ==0. Это нормальная ситуация.Цитата:
Сообщение от Владимир Ситников
А мы обсуждаем win при SYN
Не использовал, но, скорее всего, этот инструмент может такое: https://github.com/secdev/scapyЦитата:
Проверить так ли это я не могу, т.к. нет устройства, генерирующего SYN с win=0. Есть ли программы-эмуляторы, где можно принудительно заставить формировать такой SYN?
Этот пример относился к тому, что TCP клиенту **допускается** отправлять данные, даже когда server сигнализирует о нулевом receive window.Цитата:
Сообщение от Филоненко Владислав
Иными словами, нет запретов в духе "ни в коем случае нельзя отправлять данные в соединение с receive window=0".
Если честно, то не понимаю какая такая разница в какой момент receive window стало равно 0. Чем так разительно отличается нулевое окно, возникшее между делом от нулевого окна на этапе старта соединения?
Вы постоянно пишете ASK, это ошибка. Должно быть ACK (от acknowledge). Сути оно не меняет, но давайте всё-таки придерживаться общеупотребимой терминологии?Цитата:
Сообщение от Филоненко Владислав
Владислав, я понимая так, что лучше ОВЕН не покупать на объекты, которые чуть больше, чем деревянные счеты? А то хотели купить штук 10.
Наоборот, с деревянными счетами не работает, а так нормально.
//it might happen that we do not
// send back a SYN/ACK for very old stacks that send a zero window size in SYN.
Есть здравый смысл не отвечать на SYN+window=0?Цитата:
Сообщение от Филоненко Владислав
Прошивка с исправлением появилась?