Windows Просмотровщики IP пакетов ПКСЛ и ПКЛШ.

[WFox]

оставлял пинг на ночь
ночью в 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, а далее внизу предоставляется статистика.

 

[Молодой]

проверил все настройки и убрал DMZ, раз вы его так настоятельно рекомендуете убрать...
связь пропала все равно, но по "лабораторному" не успел поймать момент, вернее так, попробовал пинг, пинг пошел хороший сразу и тут же связь появилась...
а по другому блоку отфильтровал в вайршарке до того как связь поднять - безответные пакеты...
как только открыл конфигуратор - пошел обмен

т.е. я так понимаю любое обращение не МПультовское, будь то пинг или конфигуратор поднимают связь с блоком

кстати, сейчас посмотрел два блока которые были на связи, на них связь пропала вместе с другими, но потом появилась при появлении событий на лифте (не закрыта дверь кабины), т.е. ЛБ по своей инициативе связь поднимает...

 

[WFox]

проверил все настройки и убрал DMZ, раз вы его так настоятельно рекомендуете убрать...
связь пропала все равно, но по "лабораторному" не успел поймать момент, вернее так, попробовал пинг, пинг пошел хороший сразу и тут же связь появилась...
а по другому блоку отфильтровал в вайршарке до того как связь поднять - безответные пакеты...
как только открыл конфигуратор - пошел обмен
Вложение IPB #510
т.е. я так понимаю любое обращение не МПультовское, будь то пинг или конфигуратор поднимают связь с блоком

кстати, сейчас посмотрел два блока которые были на связи, на них связь пропала вместе с другими, но потом появилась при появлении событий на лифте (не закрыта дверь кабины), т.е. ЛБ по своей инициативе связь поднимает...

Может косяк в настройках роутера, на dir-100, на пример, есть три режима работы WAN интерфейса
1. Always-on - Включен всегда
2. Manua - ручное
3. Connect-on demand - соединение появляется когда есть пакеты на передачу.

Я всегда ставлю Always-on.

Если не страшно, то могу подключится удаленно и посмотреть настройки пишите в личку.

 

[revit]

кстати, сейчас посмотрел два блока которые были на связи, на них связь пропала вместе с другими, но потом появилась при появлении событий на лифте (не закрыта дверь кабины), т.е. ЛБ по своей инициативе связь поднимает...

На скрине идет обращение к ЛБ а тот не отвечает. Потом Лб инициирует свои пакеты с динамического порта 17хх на 4200 и комп на них отвечает с такого же. Это видимо момент восстановления после разрыва связи. Но вот непонятка -вообще то рукопожатие начинатся с голосового порта, а тут сразу цифровой.
Портфорвардинг в роутере на компе точно настроен на оба 44200 и 201?

А почему на 191 IP два ЛБ с одинаковыми парами портов?

 

[Молодой]

А почему на 191 IP два ЛБ с одинаковыми парами портов?

эти лифты сдавали с одним блоком и сейчас блоков там вообще нет, сдали и сняли.
Когда будем запускать уже настрою.

 

[Молодой]

странно, но за выходные лифты ни разу не пропали со связи...
сейчас переписал правила форвардинга, убрал все лишние записи (на порты блоков проброс не нужен на компе я так понимаю?) и UDP только везде оставил
вот что получилось:

DMZ- убран...

 

[Молодой]

Здравствуйте!
я снова по поводу ПКЛШ
короче выяснил, что связь пропадает тогда, когда в конфигурации ЛБ автоматически меняется порт данных. После восстановления нужного значения связь восстанавливается.
Как исключить автоматическую замену портов??

 

[revit]

...короче выяснил, что связь пропадает тогда, когда в конфигурации ЛБ автоматически меняется порт данных. После восстановления нужного значения связь восстанавливается.
Как исключить автоматическую замену портов??

Это ты о порте который пишется в таблице связей ПКСЛ в столбце "динамический IP:порт"?

 

[Andi]

Здравствуйте!
я снова по поводу ПКЛШ
короче выяснил, что связь пропадает тогда, когда в конфигурации ЛБ автоматически меняется порт данных. После восстановления нужного значения связь восстанавливается.
Как исключить автоматическую замену портов??

В описании связи с ЛБ есть параметр "Связь с ЛБ только по указанному статическому IP адресу". При его указании пакеты, пришедшие с других IP адресов, игнорируются, а в направлении ЛБ пакету уходят на указанный UDP порт, вне зависимости от того, с какого порта приходят пакеты от ЛБ.

 

[vlasoff]

Андрей Владимирович, а можно слепить какую-нибудь легковесную программулину для проверки канала связи со стороны ЛБ 6 Pro ?
Возникают ситуации когда сложно объяснить системному администратору Заказчика на объекте, что это не ты тупой, а он облажался с пробросом портов на внутренний IP. Тыкаешь ноут к тому хвосту, что вывели для ЛБ, запускаешь софтинку, вписываешь IP диспетчерской и видишь, что обмен не прет из-за непроходимости по портам UDP? Можно конечно и более громоздкие инструменты использовать, но мы же стремимся к более дружественному интерфейсу и более удобному обслуживанию? А уж все более серьезное оставим для более серьезных случаев

 

[Vincent Van Gog]

Андрей Владимирович, а можно слепить какую-нибудь легковесную программулину для проверки канала связи со стороны ЛБ 6 Pro ?
Возникают ситуации когда сложно объяснить системному администратору Заказчика на объекте, что это не ты тупой, а он облажался с пробросом портов на внутренний IP. Тыкаешь ноут к тому хвосту, что вывели для ЛБ, запускаешь софтинку, вписываешь IP диспетчерской и видишь, что обмен не прет из-за непроходимости по портам UDP? Можно конечно и более громоздкие инструменты использовать, но мы же стремимся к более дружественному интерфейсу и более удобному обслуживанию? А уж все более серьезное оставим для более серьезных случаев

Идея очень хорошая, поддерживаю! А если она ещё и весь маршрут покажет, вообще цены не будет .

 

[revit]

О подобной программулине много лет назад у меня был разговор с Андреем Владимировичем, только для ксл/моно, когда еще не было LKDSDrv.
Полезный был бы инструмент для прошки... Но к сожалению, догадываюсь что он ответит.
С другой стороны сейчас особой потребности и не испытываю-наверное потому что появился опыт и стало хватать штатных средств.

 

[Andi]

Андрей Владимирович, а можно слепить какую-нибудь легковесную программулину для проверки канала связи со стороны ЛБ 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]

На компьютере - севере должно появиться сообщение.

Т.е предполагается использование программы удаленного доступа, чтобы увидеть ответ ?

 

[Andi]

Т.е предполагается использование программы удаленного доступа, чтобы увидеть ответ ?

Нет, сообщение появляется в программе TstSocket, запущенной на компьютере-сервере.
Приложение TstSocket никак не связаны с ПО ДК "Обь".

Единственно - группа полей "Клиент Ethernet" позволяет проверить отправку пакетов через протокол LKDSProt. а не TCP/IP

 

[revit]

Есть два компьютера и нужно проверить прохождение пакетов по порту 46000.

1) запускаем на обоих компьютерах TstSocket.exe.
2) на обоих компьютеров в группе полей "сервер UDP" в поле "порт" указываем 46000 и нажимаем "инициировать". Если ошибко нет, то разрешается кнопка "послать" в группе полей "клиент UDP (через WinSock)"
3) на компьютере клиенте в группе полей "клиент UDP (через WinSock)" вводим IP компьютера сервера, порт 46000 и сообщение, нажимаем "послать"
На компьютере - севере должно появиться сообщение.

Я наверное что то недопонимаю... но как эту процедуру сделать одному на двух компьютерах?
Допустим я нахожусь на удаленной точке с ноутбуком и мне нужно проверить проходимость пакетов до компьютера-сервера (диспетчерского)?
P.S. Вот прям сейчас у меня ситуация когда из одной подсети заказчика прошка работает, а два моно не вяжутся, хотя я вижу входящие пакеты с них на диспетчерском компе.Казалось бы -ничего сложного , но вот незадача-их спец уверяет что у него нет никаких ограничений во внутренней подсети.

 

[Andi]

Я наверное что то недопонимаю... но как эту процедуру сделать одному на двух компьютерах?
Допустим я нахожусь на удаленной точке с ноутбуком и мне нужно проверить проходимость пакетов до компьютера-сервера (диспетчерского)?
P.S. Вот прям сейчас у меня ситуация когда из одной подсети заказчика прошка работает, а два моно не вяжутся, хотя я вижу входящие пакеты с них на диспетчерском компе.Казалось бы -ничего сложного , но вот незадача-их спец уверяет что у него нет никаких ограничений во внутренней подсети.

Действительно, нужно это делать вдвоем.

На компьютере-сервере (диспетчерская) запускается TstSocket

В ноутбуке на удаленной точке запускается TstSocket.

Посылаем сообщение из ноутбука на IP и порт сервера, смотрим на сервере от какого IP и порта пришло сообщение. Посылаем из сервера на эти IP:порт ответное сообщение. Смотрим на ноутбуке ответное сообщение.

Для ознакомление TstSocket можно запустить два экземпляра TstSocket на одном компьютере. Собственные порты нужно указать только различные и посылать сообщения от одного экземпляра - другому.

 

[revit]

Посылаем сообщение из ноутбука на IP и порт сервера, смотрим на сервере от какого IP и порта пришло сообщение. Посылаем из сервера на эти IP:порт ответное сообщение. Смотрим на ноутбуке ответное сообщение.

Вот и получается что для одного

предполагается использование программы удаленного доступа, чтобы увидеть ответ

 

[evpu]

>>Действительно, нужно это делать вдвоем.

На самом деле, нет. Отлично получается, если вылазить через 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]

А в более ближайшем рассмотрении... Давно знал, и писал об этом тут, что в дефолтовом режиме - 3G и 4G операторы блокируют входящий доступ на IP-шник снаружи.

Если так то это делается в целях защиты от несанкционированного трафика. У нашего Скайлинка такого нет. Внешний адрес выделяется и ограничений входящих нет. У джиэсэмщиков там да есть замороки, но с ними я не эксперементировал.

Оказалось, что при прохождении через АПН GSM-сети, маскируется реальный исходящий порт.

Ну дык это большинство современных натов делает в роутерах, а не только у опсосов.