OoegOleg (23.05.2025 16:39, просмотров: 3) ответил IBAH на Кто в этом вашем Ethernet понимает, объясните темному. Гоняю Модбас
через UDP, через W5500. Все ОК, таймауты со стороны мастера
миллисекунды, кроме первого пакета после перезагрузки W5500! Время
ответа на первый пакет после программного сброса (через бит RST
регистра MR) 250мс (со стороны мастера), а после включения питания
или аппаратного сброса (ногой RST) 350мс. Это какая-то особенность
Эзернета? Можно ли это победить? Или забить?-
- Всем спасибо! прояснилось... Но все равно не понятно откуда разница
в 100мс при различный методах сброса. По ДШ: программный сброс
очищает только внутренние регистры, а аппаратный также сбрасывает
физический интерфейс. - IBAH(23.05.2025 17:27)
- Если вы уронили линк , а на коммутаторе настроен классический Spanning three и порт не в режиме edge , так траффик может и 30 секунд не ходить - OlegPowerC(23.05.2025 17:41)
- Физике надо время чтобы прочухаться после сброса: прочувствовать
линк, обкашлять с партнером скорость и дуплекс. Небыстрое это дело. - LightElf(23.05.2025 17:36)
- Ну это понятно, W5500 сигнал линк до полсекунды выставляет - IBAH(23.05.2025 18:15)
- Нихуя не понял, но очень интересно! у W5500 есть опция "Включить
режим форсирования ARP. В режиме форсирования ARP принудительно
отправляется запрос ARP при каждой отправке данных." Поможет? - IBAH(23.05.2025 16:50)
- Нет :-) усугубит , не рассчитывайте что первая датаграмма улетит
мгновенно. Можете перед первой посылкой послать что угодно - хоть
icmp, хоть левый udp. И тогда адрес разрешиться до вашей полезной
посылки - OoegOleg(23.05.2025 17:07,
) - Можно попробовать на компе сделать статическую запись в таблице ARP и посмотреть, будет ли изменение. "arp -s IP MAC". - SciFi(23.05.2025 17:05)
- Обмен по Ethernet идет на базе MAC-адресов. А обмен по UDP идет на
базе IP адресов. Выяснением соответствия MAC <-> IP
занимается протокол ARP. После сброса процессора таблица ARP пуста.
Поэтому первый UDP пакет не может быть отправлен сразу - сначала
должен пройти обмен адресами по ARP. Это первый момент. Второй
момент заключается в том, что свичам для работы нужно знать на
каком порту у них какой MAC сидит. Свич узнает MAC адреса путем
прослушивания трафика. LightElf(149 знак., 23.05.2025 17:04)
- Коммутатор первый фрейм предназначенный неизученнуму маку пошлет во
все порты этого vlan, это называется юникаст флуд - OoegOleg(23.05.2025 17:09, )
- Это зависит от настроек свича. В описанной ситуации никакого
юникастового пакета никуда не пойдет - сначала уйдет ARP запрос
бродкастом, из него свич узнает MAC отправителя, потом на ARP
придет ответ и только потом уйдет UDP пакет. По наблюдениям, первый
ARP запрос после подключения не через все свичи проходит, иногда
только второй запрос реально пересылается свичем. - LightElf(23.05.2025 17:18 - 17:34)
- Пример обмена через коммутатор IBAH(939 знак., 26.05.2025 11:56)
- Не знаю как у wiznet, но хорошо бы ещё при старте посылать gratuitous ARP (ARP ответ без запроса, броадкастовый), чтобы и свичи быстрее просрались и компухтер сразу узнал о появлении девайса. - LightElf(26.05.2025 14:27)
- Настораживают "Len=8". Это размер данных в пакете? Не забываем, что
размер ethernet пакета должен быть не менее 64 байт вместе с
заголовком. Иначе можно наткнуться на грабли... - Гyдвин(26.05.2025 12:10)
- Это размер данных в пакете UDP. Модбас-запрос 01 03 00 00 00 0b 04 0d - IBAH(26.05.2025 12:24)
- По-моему, идеальный обмен. Образцово-показательный, я бы сказал. - Nikolay_Po(26.05.2025 12:00)
- я прекрасно знаю это, я к тому что даже отсутствие MAC адреса
назначения (например потому что устройство получатель ничего не
посылало и истек таймаут) не будет проблемой , поэтому к
коммутатору тут вопросов вобще нет. Тут исключительно вопрос к ARP.
Можно было бы создать статичискую запись ARP но в Wiznet этого не
сделать - OoegOleg(23.05.2025 17:23, )
- А дошло! задерживается не пакет от компа до W5500, а пакет от W5500
до компа! комп хранит ARP таблицу , а W5500 очищает её при сбросе. Возможно комп хранит таблицу энергонезависимо, я комп
перезагружал, эффект задержки первого пакета не проявляется. - IBAH(23.05.2025 17:34)
- Wireshark поставьте на пк и все увидите - OlegPowerC(23.05.2025 17:44)
- А дошло! задерживается не пакет от компа до W5500, а пакет от W5500
до компа! комп хранит ARP таблицу , а W5500 очищает её при сбросе. Возможно комп хранит таблицу энергонезависимо, я комп
перезагружал, эффект задержки первого пакета не проявляется. - IBAH(23.05.2025 17:34)
- Пример обмена через коммутатор IBAH(939 знак., 26.05.2025 11:56)
- Это зависит от настроек свича. В описанной ситуации никакого
юникастового пакета никуда не пойдет - сначала уйдет ARP запрос
бродкастом, из него свич узнает MAC отправителя, потом на ARP
придет ответ и только потом уйдет UDP пакет. По наблюдениям, первый
ARP запрос после подключения не через все свичи проходит, иногда
только второй запрос реально пересылается свичем. - LightElf(23.05.2025 17:18 - 17:34)
- Коммутатор первый фрейм предназначенный неизученнуму маку пошлет во
все порты этого vlan, это называется юникаст флуд - OoegOleg(23.05.2025 17:09,
- Не поможет. Всё дело в первом разе. Сначала посылается пакет ARP,
ждет ответа от удаленного узла, чтобы получить его MAC - один раз,
а уже потом передает ваши IP пакеты. - ecomp42(23.05.2025 17:02, )
- Нет :-) усугубит , не рассчитывайте что первая датаграмма улетит
мгновенно. Можете перед первой посылкой послать что угодно - хоть
icmp, хоть левый udp. И тогда адрес разрешиться до вашей полезной
посылки - OoegOleg(23.05.2025 17:07,
- Всем спасибо! прояснилось... Но все равно не понятно откуда разница
в 100мс при различный методах сброса. По ДШ: программный сброс
очищает только внутренние регистры, а аппаратный также сбрасывает
физический интерфейс. - IBAH(23.05.2025 17:27)