Валентин, искать. ну или просто фильтрануть пакеты с одинаковым id и например сроком жизни меньше 10(просто по ttl фильтр ничего интересного мне не показал или я не увидел), и посмотреть куда эти пакеты ходили, и зачем. И все таки обрисую картину, зачем я это хочу. loop detected есть, работает, туда сюда ходят loop пакеты. Но после установки нового оборудования подрядчиком где совершенно непонятна коммутация(в смете одно на деле другое, а доступа к устройствам нет, паролей нет и вообще нихрена нет) начались 5-10 секундные провалы. свичи не пингуются, вот тут родилось предположение что где то образуется петля и быстро устраняется. Чтобы найти петлю надо знать чем она отличается от других пакетов\кадров, нужно отличительное свойство по которому можно определить что вот это петля а это нет. На мой взгляд это один пакет(со своим id) который ходит туда сюда по петле из порта в порт и соответственно его ttl становится все меньше и меньше. Поэтому хочу понять можно ли и как их фильтровать\парсить таким образом. Поправьте если неправ насчет признаков петли.
Валентин, я вам конечно же благодарен за отзывчивость но, вы видимо не поняли вопрос, он заключается не в том как бороться с петлями, и не в том как я хочу это сделать(или как надо, тем более что stp протоколы использую, и петли он ищет и по видимому довольно быстро лечит), а в том как, чем и где можно фильтровать пакеты и кадры по идентификаторам.
Валентин, Идентификатор IP пакета - Поле Идентификатор пакета (IDENTIFICATION) занимает 2 байта и используется для распознавания пакетов, образовавшихся путем фрагментации исходного пакета. Все фрагменты должны иметь одинаковое значение этого поля. (своими словами получилось что то вроде масло масляное поэтому скопировал с первого в выдаче сайта ссыль: citforum.ru/nets/ip/glava_4.shtml)
У езернет фрейма это непонял к чему спрашиваете, скорее Transaction ID - DHCP запросов использовал бы, только как эти данные вытянуть парсером?
он включен, и есть подозрение что он хорошо работает, настолько хорошо, что похоже лупы все таки устраняет, но недавно в сеть подрядчиком были установлены свичи доступа к которым нет(только физически, проводки подёргать), после чего начали кратковременные(5-10 сек) провалы сети, отловить их пока не получается т.к. не всегда есть возможность их вообще заметить(думаю stp их ловит). Помимо всего прочего из свича в патч панель идут два кабеля которых в смете нет и разбирать пол, кабель каналы под полом, желания и возможности тоже нет, а просто высунуть и посмотреть кто из пользователей начнет кричать и материться - не буду, нельзя так делать, подключены системы которые должны нон-стоп работать.
Владислав Лысков, да в первом случае ругается на юникод, отрицать не буду. Но тем не менее даже с \\ перед Uninstall он не находит данный ключ. А с одним слэшем но другим названием ключа находит. Всетаки дело не в кодировке, как мне кажется.
Владислав Лысков, Не помогло.
P.s. в представленном выше коде у меня стоят [] скобки, но на самом деле там {}(это я танцевал с бубном в надежде что может все таки прокатит) и забыл поменять обратно.
Но при условии что если ключ после \Uninstall\ начинается не с "{" то это работает
