Просмотровщики IP пакетов ПКСЛ и ПКЛШ., Инструмент для изучения прохождения пакетов в компьютере |
Здравствуйте, гость ( Вход | Регистрация )
Просмотровщики IP пакетов ПКСЛ и ПКЛШ., Инструмент для изучения прохождения пакетов в компьютере |
WFox |
24.10.2012, 14:39
Сообщение
#21
|
Активный участник Группа: Пользователи Сообщений: 242 Регистрация: 11.10.2006 Пользователь №: 231 |
оставлял пинг на ночь ночью в 2.32 было пропадание связи именно на "лабораторном" блоке примерно на 2 минуты остальные при этом не пропали... в cmd уже ничего не видно, но судя по вайршарку шли безответные пакеты и по пингу... удивительно, но не было таких частых пропаданий связи как обычно... провайдеры разные в диспетчерской АДСЛ, а в лаборатории Ваймакс... Ну допустим это был технологический разрыв связи провайдером ваймакса для подсчета трафика (как правило раз в сутки устраивают). И еще как бы поступил я: 1. Сбросил бы DIR-100 на заводские настройки (кнопочкой) 2. Настроил LAN и WAN 3. На вкладке Advanced в разделе Port Forwarding сделал бы 2 записи: Код 1. Name = LB_"ID блока"_Data, IP Adress = внутрисетевой адрес ЛБ (должен принадлежать LAN), Public Port = 44300 ~ 44300, Traffic Type = UDP, обязательно галку поставить 1. Name = LB_"ID блока"_Voice, IP Adress = внутрисетевой адрес ЛБ (должен принадлежать LAN), Public Port = 44301 ~ 44301, Traffic Type = UDP, обязательно галку поставить Раздел FIREWALL & DMZ 1.Enable DoS Prevention - галка 2.Enable DMZ Host - нет галки Раздел ADVANCED NETWORK 1. Enable UPnP - галка 2. Enable WAN Ping Respond - галка 3. Enable NAT - галка На вкладке MAINTENANCE раздел LOG SETTINGS все галки в разделе LOG TYPE Еще забыл на вкладке SETUP раздел DATA AND TIME настроил бы, что бы в логах роутера проще разбираться было бы. Ну и дальше бы мониторил на реальном канале. в cmd уже ничего не видно при использовании ключа -t, пинг прерывается по ctrl+c, а далее внизу предоставляется статистика. |
Молодой |
26.10.2012, 17:14
Сообщение
#22
|
Активный участник Группа: Пользователи Сообщений: 157 Регистрация: 28.3.2007 Из: Казань Пользователь №: 989 |
проверил все настройки и убрал DMZ, раз вы его так настоятельно рекомендуете убрать...
связь пропала все равно, но по "лабораторному" не успел поймать момент, вернее так, попробовал пинг, пинг пошел хороший сразу и тут же связь появилась... а по другому блоку отфильтровал в вайршарке до того как связь поднять - безответные пакеты... как только открыл конфигуратор - пошел обмен т.е. я так понимаю любое обращение не МПультовское, будь то пинг или конфигуратор поднимают связь с блоком кстати, сейчас посмотрел два блока которые были на связи, на них связь пропала вместе с другими, но потом появилась при появлении событий на лифте (не закрыта дверь кабины), т.е. ЛБ по своей инициативе связь поднимает... -------------------- лучше семь раз подняться пешком, чем один раз застрять в лифте
(1-ая заповедь аварийщика) |
WFox |
26.10.2012, 20:43
Сообщение
#23
|
Активный участник Группа: Пользователи Сообщений: 242 Регистрация: 11.10.2006 Пользователь №: 231 |
проверил все настройки и убрал DMZ, раз вы его так настоятельно рекомендуете убрать... связь пропала все равно, но по "лабораторному" не успел поймать момент, вернее так, попробовал пинг, пинг пошел хороший сразу и тут же связь появилась... а по другому блоку отфильтровал в вайршарке до того как связь поднять - безответные пакеты... как только открыл конфигуратор - пошел обмен т.е. я так понимаю любое обращение не МПультовское, будь то пинг или конфигуратор поднимают связь с блоком кстати, сейчас посмотрел два блока которые были на связи, на них связь пропала вместе с другими, но потом появилась при появлении событий на лифте (не закрыта дверь кабины), т.е. ЛБ по своей инициативе связь поднимает... Может косяк в настройках роутера, на dir-100, на пример, есть три режима работы WAN интерфейса 1. Always-on - Включен всегда 2. Manua - ручное 3. Connect-on demand - соединение появляется когда есть пакеты на передачу. Я всегда ставлю Always-on. Если не страшно, то могу подключится удаленно и посмотреть настройки пишите в личку. |
revit |
26.10.2012, 21:01
Сообщение
#24
|
Активист Группа: Пользователи Сообщений: 6 658 Регистрация: 7.2.2006 Из: г. Ростов-на-Дону Пользователь №: 3 |
кстати, сейчас посмотрел два блока которые были на связи, на них связь пропала вместе с другими, но потом появилась при появлении событий на лифте (не закрыта дверь кабины), т.е. ЛБ по своей инициативе связь поднимает... На скрине идет обращение к ЛБ а тот не отвечает. Потом Лб инициирует свои пакеты с динамического порта 17хх на 4200 и комп на них отвечает с такого же. Это видимо момент восстановления после разрыва связи. Но вот непонятка -вообще то рукопожатие начинатся с голосового порта, а тут сразу цифровой. Портфорвардинг в роутере на компе точно настроен на оба 44200 и 201? А почему на 191 IP два ЛБ с одинаковыми парами портов? -------------------- Я не понял Вашего вопроса, но я Вам на него отвечу.....
Лень-психоматический признак исправности выработанного за годы эволюции механизма интуитивного распознавания безсмысленности выполняемой задачи. |
Молодой |
29.10.2012, 10:49
Сообщение
#25
|
Активный участник Группа: Пользователи Сообщений: 157 Регистрация: 28.3.2007 Из: Казань Пользователь №: 989 |
А почему на 191 IP два ЛБ с одинаковыми парами портов? эти лифты сдавали с одним блоком и сейчас блоков там вообще нет, сдали и сняли. Когда будем запускать уже настрою. -------------------- лучше семь раз подняться пешком, чем один раз застрять в лифте
(1-ая заповедь аварийщика) |
Молодой |
29.10.2012, 11:11
Сообщение
#26
|
Активный участник Группа: Пользователи Сообщений: 157 Регистрация: 28.3.2007 Из: Казань Пользователь №: 989 |
странно, но за выходные лифты ни разу не пропали со связи...
сейчас переписал правила форвардинга, убрал все лишние записи (на порты блоков проброс не нужен на компе я так понимаю?) и UDP только везде оставил вот что получилось: DMZ- убран... -------------------- лучше семь раз подняться пешком, чем один раз застрять в лифте
(1-ая заповедь аварийщика) |
Молодой |
17.12.2012, 17:51
Сообщение
#27
|
Активный участник Группа: Пользователи Сообщений: 157 Регистрация: 28.3.2007 Из: Казань Пользователь №: 989 |
Здравствуйте!
я снова по поводу ПКЛШ короче выяснил, что связь пропадает тогда, когда в конфигурации ЛБ автоматически меняется порт данных. После восстановления нужного значения связь восстанавливается. Как исключить автоматическую замену портов?? -------------------- лучше семь раз подняться пешком, чем один раз застрять в лифте
(1-ая заповедь аварийщика) |
revit |
17.12.2012, 21:17
Сообщение
#28
|
Активист Группа: Пользователи Сообщений: 6 658 Регистрация: 7.2.2006 Из: г. Ростов-на-Дону Пользователь №: 3 |
...короче выяснил, что связь пропадает тогда, когда в конфигурации ЛБ автоматически меняется порт данных. После восстановления нужного значения связь восстанавливается. Это ты о порте который пишется в таблице связей ПКСЛ в столбце "динамический IP:порт"?Как исключить автоматическую замену портов?? -------------------- Я не понял Вашего вопроса, но я Вам на него отвечу.....
Лень-психоматический признак исправности выработанного за годы эволюции механизма интуитивного распознавания безсмысленности выполняемой задачи. |
Андрей Ефименко |
18.12.2012, 7:40
Сообщение
#29
|
Активист Группа: Администраторы Сообщений: 2 718 Регистрация: 8.2.2006 Пользователь №: 4 |
Здравствуйте! я снова по поводу ПКЛШ короче выяснил, что связь пропадает тогда, когда в конфигурации ЛБ автоматически меняется порт данных. После восстановления нужного значения связь восстанавливается. Как исключить автоматическую замену портов?? В описании связи с ЛБ есть параметр "Связь с ЛБ только по указанному статическому IP адресу". При его указании пакеты, пришедшие с других IP адресов, игнорируются, а в направлении ЛБ пакету уходят на указанный UDP порт, вне зависимости от того, с какого порта приходят пакеты от ЛБ. |
vlasoff |
19.2.2014, 14:43
Сообщение
#30
|
Активный участник Группа: Пользователи Сообщений: 321 Регистрация: 21.2.2006 Из: Иваново Пользователь №: 9 |
Андрей Владимирович, а можно слепить какую-нибудь легковесную программулину для проверки канала связи со стороны ЛБ 6 Pro ?
Возникают ситуации когда сложно объяснить системному администратору Заказчика на объекте, что это не ты тупой, а он облажался с пробросом портов на внутренний IP. Тыкаешь ноут к тому хвосту, что вывели для ЛБ, запускаешь софтинку, вписываешь IP диспетчерской и видишь, что обмен не прет из-за непроходимости по портам UDP? Можно конечно и более громоздкие инструменты использовать, но мы же стремимся к более дружественному интерфейсу и более удобному обслуживанию? А уж все более серьезное оставим для более серьезных случаев |
Van Gog |
19.2.2014, 14:52
Сообщение
#31
|
Активист Группа: Пользователи Сообщений: 657 Регистрация: 28.4.2006 Пользователь №: 27 |
Андрей Владимирович, а можно слепить какую-нибудь легковесную программулину для проверки канала связи со стороны ЛБ 6 Pro ? Возникают ситуации когда сложно объяснить системному администратору Заказчика на объекте, что это не ты тупой, а он облажался с пробросом портов на внутренний IP. Тыкаешь ноут к тому хвосту, что вывели для ЛБ, запускаешь софтинку, вписываешь IP диспетчерской и видишь, что обмен не прет из-за непроходимости по портам UDP? Можно конечно и более громоздкие инструменты использовать, но мы же стремимся к более дружественному интерфейсу и более удобному обслуживанию? А уж все более серьезное оставим для более серьезных случаев Идея очень хорошая, поддерживаю! А если она ещё и весь маршрут покажет, вообще цены не будет . -------------------- Теория - это когда всё знаешь, но ничего не работает. Практика - это когда всё работает, но ты не знаешь почему. Мы совмещаем теорию и практику - ничего не работает, и никто не знает почему!
********** Высшая математика в жизни помогла только один раз... - когда ключи в сортир уронил... интеграл из проволоки сделал. ********** "Знание некоторых принципов легко возмещает незнание некоторых фактов" (Клод Адриа́н Гельве́ций (фр. Claude Adrien Helvétius; 1715 — 1771) — французский писатель и философ-материалист). ********** Опыт приходит сразу после того, как он был нужен... |
revit |
19.2.2014, 17:53
Сообщение
#32
|
Активист Группа: Пользователи Сообщений: 6 658 Регистрация: 7.2.2006 Из: г. Ростов-на-Дону Пользователь №: 3 |
О подобной программулине много лет назад у меня был разговор с Андреем Владимировичем, только для ксл/моно, когда еще не было LKDSDrv.
Полезный был бы инструмент для прошки... Но к сожалению, догадываюсь что он ответит. С другой стороны сейчас особой потребности и не испытываю-наверное потому что появился опыт и стало хватать штатных средств. -------------------- Я не понял Вашего вопроса, но я Вам на него отвечу.....
Лень-психоматический признак исправности выработанного за годы эволюции механизма интуитивного распознавания безсмысленности выполняемой задачи. |
Андрей Ефименко |
20.2.2014, 8:45
Сообщение
#33
|
Активист Группа: Администраторы Сообщений: 2 718 Регистрация: 8.2.2006 Пользователь №: 4 |
Андрей Владимирович, а можно слепить какую-нибудь легковесную программулину для проверки канала связи со стороны ЛБ 6 Pro ? Возникают ситуации когда сложно объяснить системному администратору Заказчика на объекте, что это не ты тупой, а он облажался с пробросом портов на внутренний IP. Тыкаешь ноут к тому хвосту, что вывели для ЛБ, запускаешь софтинку, вписываешь IP диспетчерской и видишь, что обмен не прет из-за непроходимости по портам UDP? Можно конечно и более громоздкие инструменты использовать, но мы же стремимся к более дружественному интерфейсу и более удобному обслуживанию? А уж все более серьезное оставим для более серьезных случаев В папке Развернутого дистрибутива есть приложение TstSocket.exe Оно позволяет проверять прохождение UDP пакетов по заданным портам. В группе полей "сервер" задаем UDP порт, на который будут приниматься пакеты В группе полей "клиент" задаем IP, UDP порт и сообщение, которое хотим послать. Есть два компьютера и нужно проверить прохождение пакетов по порту 46000. 1) запускаем на обоих компьютерах TstSocket.exe. 2) на обоих компьютеров в группе полей "сервер UDP" в поле "порт" указываем 46000 и нажимаем "инициировать". Если ошибко нет, то разрешается кнопка "послать" в группе полей "клиент UDP (через WinSock)" 3) на компьютере клиенте в группе полей "клиент UDP (через WinSock)" вводим IP компьютера сервера, порт 46000 и сообщение, нажимаем "послать" На компьютере - севере должно появиться сообщение. |
revit |
20.2.2014, 15:09
Сообщение
#34
|
Активист Группа: Пользователи Сообщений: 6 658 Регистрация: 7.2.2006 Из: г. Ростов-на-Дону Пользователь №: 3 |
На компьютере - севере должно появиться сообщение. Т.е предполагается использование программы удаленного доступа, чтобы увидеть ответ ? -------------------- Я не понял Вашего вопроса, но я Вам на него отвечу.....
Лень-психоматический признак исправности выработанного за годы эволюции механизма интуитивного распознавания безсмысленности выполняемой задачи. |
Андрей Ефименко |
21.2.2014, 8:21
Сообщение
#35
|
Активист Группа: Администраторы Сообщений: 2 718 Регистрация: 8.2.2006 Пользователь №: 4 |
Т.е предполагается использование программы удаленного доступа, чтобы увидеть ответ ? Нет, сообщение появляется в программе TstSocket, запущенной на компьютере-сервере. Приложение TstSocket никак не связаны с ПО ДК "Обь". Единственно - группа полей "Клиент Ethernet" позволяет проверить отправку пакетов через протокол LKDSProt. а не TCP/IP |
revit |
28.2.2014, 14:17
Сообщение
#36
|
Активист Группа: Пользователи Сообщений: 6 658 Регистрация: 7.2.2006 Из: г. Ростов-на-Дону Пользователь №: 3 |
Есть два компьютера и нужно проверить прохождение пакетов по порту 46000. 1) запускаем на обоих компьютерах TstSocket.exe. 2) на обоих компьютеров в группе полей "сервер UDP" в поле "порт" указываем 46000 и нажимаем "инициировать". Если ошибко нет, то разрешается кнопка "послать" в группе полей "клиент UDP (через WinSock)" 3) на компьютере клиенте в группе полей "клиент UDP (через WinSock)" вводим IP компьютера сервера, порт 46000 и сообщение, нажимаем "послать" На компьютере - севере должно появиться сообщение. Я наверное что то недопонимаю... но как эту процедуру сделать одному на двух компьютерах? Допустим я нахожусь на удаленной точке с ноутбуком и мне нужно проверить проходимость пакетов до компьютера-сервера (диспетчерского)? P.S. Вот прям сейчас у меня ситуация когда из одной подсети заказчика прошка работает, а два моно не вяжутся, хотя я вижу входящие пакеты с них на диспетчерском компе.Казалось бы -ничего сложного , но вот незадача-их спец уверяет что у него нет никаких ограничений во внутренней подсети. -------------------- Я не понял Вашего вопроса, но я Вам на него отвечу.....
Лень-психоматический признак исправности выработанного за годы эволюции механизма интуитивного распознавания безсмысленности выполняемой задачи. |
Андрей Ефименко |
28.2.2014, 14:43
Сообщение
#37
|
Активист Группа: Администраторы Сообщений: 2 718 Регистрация: 8.2.2006 Пользователь №: 4 |
Я наверное что то недопонимаю... но как эту процедуру сделать одному на двух компьютерах? Допустим я нахожусь на удаленной точке с ноутбуком и мне нужно проверить проходимость пакетов до компьютера-сервера (диспетчерского)? P.S. Вот прям сейчас у меня ситуация когда из одной подсети заказчика прошка работает, а два моно не вяжутся, хотя я вижу входящие пакеты с них на диспетчерском компе.Казалось бы -ничего сложного , но вот незадача-их спец уверяет что у него нет никаких ограничений во внутренней подсети. Действительно, нужно это делать вдвоем. На компьютере-сервере (диспетчерская) запускается TstSocket В ноутбуке на удаленной точке запускается TstSocket. Посылаем сообщение из ноутбука на IP и порт сервера, смотрим на сервере от какого IP и порта пришло сообщение. Посылаем из сервера на эти IP:порт ответное сообщение. Смотрим на ноутбуке ответное сообщение. Для ознакомление TstSocket можно запустить два экземпляра TstSocket на одном компьютере. Собственные порты нужно указать только различные и посылать сообщения от одного экземпляра - другому. |
revit |
28.2.2014, 15:25
Сообщение
#38
|
Активист Группа: Пользователи Сообщений: 6 658 Регистрация: 7.2.2006 Из: г. Ростов-на-Дону Пользователь №: 3 |
Посылаем сообщение из ноутбука на IP и порт сервера, смотрим на сервере от какого IP и порта пришло сообщение. Посылаем из сервера на эти IP:порт ответное сообщение. Смотрим на ноутбуке ответное сообщение. предполагается использование программы удаленного доступа, чтобы увидеть ответ -------------------- Я не понял Вашего вопроса, но я Вам на него отвечу.....
Лень-психоматический признак исправности выработанного за годы эволюции механизма интуитивного распознавания безсмысленности выполняемой задачи. |
Евгений Пухальский |
28.10.2014, 18:25
Сообщение
#39
|
Участник Группа: Пользователи Сообщений: 59 Регистрация: 13.4.2011 Пользователь №: 6 489 |
>>Действительно, нужно это делать вдвоем.
На самом деле, нет. Отлично получается, если вылазить через RDP, тогда - расположился себе у клиента в подсети - и тести, как со своего бука - так и со стороны сервера! Отличная прога. Пользовался аналогичной. Еще бы и под TCP... Вообще мечта админа-наладчика)))) Кстати. Тут случайно)))) получилось одно весьма интересное исследование, тестил я короче, прохождение пакетов через NAT. В прямом направлении - изнутри серой сети - допустим, исходящий порт 5000, после прохождения через NAT он становится произвольно другим, напр. 21323. И чтобы получить пакет на 5000 серый порт, надо послать пакет через WAN на порт 21323. Все логично. Данный маршрут создается автоматически, и живет какое-то время. Я задался вопросом - СКОЛЬКО? При первом рассмотрении, это зависит от самого NATа. Если это роутер типа ДЛИНК-ТПЛИНК - то в принципе, минут 5-10 маршрут живет точно. Т.е можно послать изнутри несколько пакетов - и замолчать минут на 5-10, затем послать пакет на порт 21323, и автоматический проброс все еще окажется жив! Т.е пакет придет на порт 5000. А в более ближайшем рассмотрении... Давно знал, и писал об этом тут, что в дефолтовом режиме - 3G и 4G операторы блокируют входящий доступ на IP-шник снаружи. Т.е ситуация - в ноуте такой свисток, ты реально в WAN-е светишься под тем адресом, который присвоен на адаптере изнутри (т.е номер IP - не транслируется), но допустим, на 80-й порт зайти нереально (у меня апач на буке крутится), да и на любой другой предустановленный - тоже. Никакой ДМЗ и его модификации - соотв. не работают тоже! По Казахстану - это общая особенность работы GSM и CDMA операторов без исключения. А чтобы был доступ к порту - надо подключать доп. сервисы у оператора. Но ведь работать в инете как-то получается! Для того он и нужен, этот свисток! И вот, благодаря программке аналогичной выложенной, получилось это выяснить. Оказалось, что при прохождении через АПН GSM-сети, маскируется реальный исходящий порт. Т.е IP остается без изменений, а порт - транслируется! Не исключаю ситуацию, что это разновидность NATа, и даже, возможно присвоение одного-и того же WAN IP-шника нескольким компам одновременно, без трансляции адреса, но с трансляцией портов. Нам, это в данный момент не интересно. Важно то, что время жизни такого маршрута - порядка 60-90 сек. Т.е если условно говоря, посылать пакеты раз в 30-40 секунд, то маршрут сохраняется на неопределенное время. ПРОДОЛЖЕНИЕ СЛЕДУЕТ |
revit |
28.10.2014, 19:19
Сообщение
#40
|
Активист Группа: Пользователи Сообщений: 6 658 Регистрация: 7.2.2006 Из: г. Ростов-на-Дону Пользователь №: 3 |
А в более ближайшем рассмотрении... Давно знал, и писал об этом тут, что в дефолтовом режиме - 3G и 4G операторы блокируют входящий доступ на IP-шник снаружи. Оказалось, что при прохождении через АПН GSM-сети, маскируется реальный исходящий порт. -------------------- Я не понял Вашего вопроса, но я Вам на него отвечу.....
Лень-психоматический признак исправности выработанного за годы эволюции механизма интуитивного распознавания безсмысленности выполняемой задачи. |
Текстовая версия | Сейчас: 29.3.2024, 8:39 |