Heckfy

Интересно, с точки зрения практики применения Central Manager. Если связь между IP-устройствами через GPRS установлена, то думаю, что нет на этом этапе значения какие IP-адрес WAN используются, тем более TCP тоже не блокируются (для тестирования сессии и серые годятся). Так COM-порт все-таки уже есть в ОС, связь по IP/TCP имеется? А через простой терминал (Hyper, Putty, Realterm или т.п.), не используя ваше приложение и неизвестные прочие, открывающие ваш COM-порт - получается протестировать передачу данных? А не пробовали ли использовать TCP Server/Client, а не RealCOM? По своему опыту знаю, что драйвера моксы не все программы понимают. Я иногда, если программа не позволяет делать соединение по TCP, а только через COM пробрасываю TCP на виртуальный COM, допустим через утилиту Tibbo VSP.

В целях испытания правильности настроек соединения попробуйте со стороны клиента командой telnet подключиться к TCP-порту сервера. Используйте для соединения внешний IP-адрес моксы, той что со стороны сервера. Отрубите перед этим ваше клиентское приложение и firewall. Для успешного соединения пытайтесь правильно настроить Virtual Server или же Reverse RealCom. Если соединение устойчиво не происходит или же передача данных не проходит, обрывается, то возможно время отклика (ping) в сети GPRS велико - больше 1000...2000 ms, что может быть критичным для вашего приложения, а при худших более 4000 ms может вообще блокироваться в сети.

Всё зависит от конкретных условий. Учтите их и характеристику диаграммы направленности антенн. См. теорию http://m.habrahabr.ru/post/158273/ См. практику http://wi-life.ru/treningi/wi-fi-3/praktikum/oshibki-pri-razvertyvanii-setej-wi-fi У вас небольшое расстояние, в типовом случае достаточно будет штырьевой на точке доступа, а на клиенте можно установить узконаправленную. Вам нужно, чтобы диаграммы антенн перекрывались, их максимумы ближе сходились. Штырьевая антенна дает самый широкий угол (в горизонтальной плоскости 360 град), попасть издалека в него проще, если узконаправленная антенна своей диаграммой достанет до него. Однако, у штырьевой при всей ширине угла радиус действия близкий, при больших расстояниях может быть недостаточен, возможен случай замены на узконаправленную. И в таком случае надо понимать, что радиосвязь сузится до пространства точка-точка, т.е. точке доступа будет доступен клиент по узкой радиолинии между их узконаправленными антеннами. Полагаю, что 2-е узконаправленные - это не ваш случай. Диаграмма направленности узконаправленной антенны более уязвима из-за возможных препятствий распространения по месту установки, может всем узким углом поглатиться или отразиться в другое направление. В случае широконаправленной (штырьевой) антенны засчет ширины угла в ближнем радиусе действия такое препятствие успешнее преодолевается. Большая зависимость от условий по месту установки. К тому же не следует исключать влияния радиопомех. См. по вышеуказанной ссылке практический материал. Для случая установки в помещениях, местах с препятствиями распространения радиоволн, искажающими диаграммы направленности с поглащением и переотражением можете попробовать сделать оценку на сайте у dlink'а через его расчетный инструмент, см. http://dlink.ru/tools/wi-fi/

Galina, мало исходных данных. К тому же, какой смысл применять столь серьезный (IP68, низких температур) и дорогостоящий аппарат для того, чтобы преодолеть 200 м, если вы собираетесь применять внешнюю антенну? Если ваши устройства находятся в прямой видимости, нет препятствий в зоне прямой видимости, есть свободные каналы (отсутствуют радиопомехи, либо другие wi-fi точки малочисленны), то многие калькуляторы из интернета (не заглядывая в учебник) на расстоянии 200 м показывают возможность уверенной радиосвязи при тех параметрах мощности и чувствительности выбранной вами модели, если с той и другой стороны аналогичная. Можно найти несколько калькуляторов в Google Play, в интернете типа http://www.wmd.ru/calc.html#tab-calc-fresnel. Лучше конечно взглянуть в учебник, теорию, посмотреть справочники. Однако, если вы не уверены в исходных данных, то советую не тратить деньги, взять дешевенький Dlink типа 300-ого, на нём люди через ж/б стены без всяких антенн 150 м получали легко, не будет дотягиваться или нужна более прямая видимость - попробуйте выставить наружу антенну. Если с антенной и настройкой каналов не выйдет, то не судьба, помехи сильнее. По частотам: если не ошибаюсь wi-fi на 5 ГГц - дальше бьет, чем на 2,4 ГГц, менее распространен, меньше вероятность наткнутся на помехи в каналах. Но я не думаю, что это ваш случай.

Александр_ru, как ваши успехи? Александр, ввиду того, что с обеих сторон, за модемами находятся ваши маршрутизаторы и есть моё предположение, что маршрутизаторы обладают функциями по крайней мере с одной стороны VPN-клиента, а с другой VPN-сервера по широкораспространенному протоколу L2TP/PPTP, то предлагаю следующее: - Поднять L2TP/PPTP между маршрутизаторами, пробросив через модем средствами Virtual Server порт TCP=1723 до маршрутизатора с VPN-сервером.

Александр, вы не сможете получить "свою" сеть, вам модемы не дадут, за ними ваши маршрутизаторы сродни коммутаторам, которые находятся за шлюзами модемов. В модемах не настраивается таблица маршрутизации, нет NAT, это убогие гетвеи типа Firewall, в них хранятся маршруты только как ходить во внешнюю сеть и возможно во внутреннюю через внутренний и внешний интерфейс соответственно. Вы не сможете указать в модеме маршрут, ссылающийся на гетвей внешнего интерфейса противоположного модема, чтобы пройти в его внутреннюю подсеть, а без него путешествие IP-пакета от вашего за ним маршрутизатора получится безадресным на выходе модема. И это не зависит какую сеть сделает "вашей" оператор, публичную или частную. Она может стать лишь тогда действительно вашей и только в случае выделяемой им частной сети, если ваши внешние интерфейсы будут маршрутизируемыми гетвеями, интерфейсами ваших коммутаторов или маршрутизаторов. И другой случай, если оператор соизволит указать маршруты для "вашей" сети, ваших внешних интерфейсов, на своём оборудовании. И возможен случай, если оператор даст вам виртуальную частую сеть, VPN, но уже на базе L2TP/PPTP (не путать с IPSec, это разные вещи), и этот сценарий реалистичен для соединения, если вашими маршрутизаторами за модемами поддерживается L2TP/PPTP-клиент.

Александр_ru, не слишком ли много манипуляций, VPN, да к ней маршрутизация? Вам оператор выделил частную сеть. И если он может устроить для вас маршрутизацию в ней, то может этого достаточно? Стоило бы проверить для модемов. Если маршрутизацию оператор не делает, то поднятый VPN на базе IPSec со стороны оператора вам ничего не даст. По базовому сценарию Операторы предлагают IPSec-шлюз в частную сеть со стороны публичной (интернета), а с другой стороны прокидывают кабель до вашего оборудования и для доступа в вашу сеть, отличную от частной, на вашей стороне поднимается NAT. Допустим, вы договорились не на базовый сценарий и IPSec-шлюз вам устраивает Оператор в частной сети, а с другой стороны не тянете проводную связь, применяете сотовую связь и соединяетесь посредством модема G3150. То вы натыкаетесь без маршрутизации на "грабли" - на модеме не возможно поднять NAT - это не маршрутизатор. Александр_ru, в любом случае отпишитесь на форум о том что удалось сделать и что сделал Оператор, чтобы вам обеспечить связь. Александр_ru, вы бы схему что ли предоставили на форум, а то вы бьётесь с задачей, а может всё решаться проще на базе проброса TCP/UDP-портов при помощи Virtual Server модемов.

Уважаемый, для сети оператора у вас 2-е разные сети, как бы вы не считали. Интерфейсы ваших модемов, находящиеся в его сети, являются шлюзами в его назначенную вам частную сеть. И вы эту сеть никак не перепрыгните без согласия оператора. Согласие - это если оператор на своей стороне пропишет маршруты в вашу подсеть, обозначив шлюзами в вашу сеть внешние интерфейсы модемов и для этого ему нужна информация о вашей сети. Однако, это маловероятно, что оператор ради вас пойдёт на настройку маршрутизации на своём оборудовании. Как заметили здесь уважаемые модераторы, вероятнее всего построить самостоятельно VPN-туннель (IPSec). Но для этого вам потребуется с одной из сторон поставить маршрутизатор с возможностью организации на его внешнем интерфейсе, на том что глядит в сеть оператора, IPSec-gateway. Так как вы находитесь в частной сети оператора сотовой связи, то вам потребуется либо заказать услугу у оператора сотовой связи и протянуть до вашего маршрутизатора кабель, либо поставить маршрутизатор с сотовым интерфейсом. Если выбираете 2-ой вариант, то советую брать не меньше, чем 3G. Кстати говоря, G3150 работают только с GPRS/EDGE. И если бы вам удалось на них смаршрутизироваться, то не факт, что у вас была бы устойчивая связь. Задержки GPRS/EDGE в сетях наших операторов сотовой связи большие, не менее 465 мс, это в регионах, а в Москве и тем больше, не менее 2000 мс, что в итоге удвоив в вашем случае легко можете получить " время установления соединения истекло".

Уважаемый, Хочу сразу заметить, что понятие "моста" в вашей задаче не применимо, с точки зрения сетевых технологий и того что вы хотите некорректно. С точки зрения сетевых технологий вы имеете 2-е подсети и чтобы из одной подсети по интернет протоколу (IP) попасть в другую вам потребуется маршрутизация или VPN-туннель. Однако, с тем и другим у вас засада, так как вы ни с одной из сторон не имеете маршрутизатора, способного стать шлюзом в вашу подсеть.

Зачем какой-то драйвер вам? Задача видится абсолютно стандартной: Есть преобразователь интерфейса RS232/485-WiFi, из последовательного порта в TCP/IP: Moxa NPort W2150A К последовательному порту которого подключены весы, которые выдают уже в этот порт по своему протоколу данные или могут их выдать по принятому запросу. Планшет на Андроиде ваш терминал, которым вы подключаетесь по WiFi к точке доступа преобразователя интерфейса. Осталось на преобразователе установить для последовательного порта режим TCP Server Mode, который позволит открыть TCP-порт, указываемый вами в его установках, в режиме сервера для соединений и передачи данных последовательного порта. Затем на планшете ставите программу TCP-клиента (типа https://play.google.com/store/apps/details?id=com.sollae.eztcpclient) и с помощью её цепляетесь по IP-адресу интерфейса WLAN WiFi точки доступа вашего преобразователя к настроенному вами TCP-серверу (его ТСР-порту). И вуаля, с помощью терминала программы вы сможете общаться с устройством, если только знаете его протокол конечно. Остальным: типа JAVA-программы или Андроид-приложения для опроса весов, если указанных не выпускает производить весов, можете самостоятельно заняться сами.

Господа, У нас решилась проблема неустойчивости связи по GPRS. В данный момент время передачи данных устойчиво находиться в пределах 500-800 мс, без заметных сбоев, что позволяет приемлемо решать задачу опроса удаленного контроллера. До наступления этого момента отсылалось официальное письмо о проблеме в МТС, и хотя ответа на него не последовало видимо в МТС согласились с нашими доводами и втихую исправили. Мы не претендуем на разъяснение ситуации от МТС, нас удовлетворяет просто полученный положительный результат. А то, что оператор сотовой связи внёс исправления - в этом уверены наши специалисты, непосредственно занимающиеся решением задачи по установлению опроса контроллера через канал GPRS, зафиксировавшие на данный момент качественное улучшение передачи данных в канале GPRS, по времени, а также оцененного по протоколу состояния связи, отсутствия ошибок и сбоев связи. К тому же наши специалисты не исключают, что ситуацию также в целом улучшило применение ими (параллельно с действиями оператора сотовой связи) функции модемов как то GuaranLink. Работа этой функции была зафиксирована, испытана и оценена положительно.

Александр, Вы имеете ввиду указание "The OnCell G3100 functions as a router to achieve Ethernet to cellular connectivity. All Ethernet devices connected to the OnCell’s LAN port are hidden from public view via the OnCell’s NAT function." Трудно догадаться по этому неочевидному указанию, что идёт речь о включенном по умолчанию NAT в IP-gateway OnCell, а не про функции Virtual Server. Александр, исходя из вышеуказанного не следует, что VPN-клиент и тем более VPN-сервер спрятаны за NAT. В рассматриваемом соединении очевидно лишь то, что G31x0 спрятан за NATом оператора сотовой связи. Но со стороны G31x0 нет VPN-gateway (VPN-сервера), то какой смысл в его сторону устраивать NAT-T? И при этом VPN-сервер на маршрутизаторе не за NATом (имеет публичный IP-адрес), а то что вы устроили на нём свой NAT, это не делает доступ к внешнему интерфейсу через него. И где здесь тогда смысл в NAT-T? Александр, о каких роутерах вы рассуждаете? В нашей рассматриваемой схеме всего лишь один маршрутизатор. И тогда уж будьте добры предоставить таблицы маршрутизации с G31x0 и маршрутизатора. И всё таки, Александр, у меня есть большая просьба к вам о пробросе VPN-туннеля между G31x0, их локальными сетями. За одним G31x0 из которых, имеющем публичный внешний адрес, ПК с ОС WINDOWS, на базе которой развернут сервер IPSec (VPN-gateway для туннеля). А на другом G31x0, имеющем частный адрес за NATом оператора сотовой связи, используется его встроенный VPN-client для туннеля. При этом как раз более актуальным видется использование NAT-T на VPN-клиенте для его возможности преодолеть NAT противоположного G31x0, за которым находится IPSec-сервер на базе ОС WINDOWS.

Возьмите новую документацию с moxa.com и изучите прежде чем создавать бесполезную тему. 1) OnCell G3150 и G3151 оба не поддерживают 3G. Поддерживают 3G модели с суффиксом а названии "HSPA". 2) Главное отличие (возможно и единственное) в том, что G3150 поддерживает протокол IPSec, имея на борту VPN-клиента. А это очень существенно, позволяет прокинуть туннель до вашей локальной сети сквозь сеть оператора\интернет.

Александр, Спасибо, за наглядное пособие. У меня нет оснований не доверять вашему протоколу. Однако, выполнение команд tracert и pathping, а также в начале ping с маршрутизатора обладали бы большей наглядностью, при том, что если бы был зафиксирован Overview модема. Александр, вы всё равно не ответили на мои вопросы: Где на модеме включается NAT, исходя из вашей инструкции? И верно ли я понял, что смысл включения NAT-T на модеме в том, что вы использовали NAT, а не маршрутизацию на маршрутизаторе? A в чём смысл включения NAT-T на маршрутизаторе? При всём при этом, Char, мне остаёться признать, что нам надо продолжать работать над своими ошибками. И от меня есть просьба в адрес Александра: Александр, усильте решение, сделайте без NAT, и для случая, если у нас нет маршрутизатора, а с двух сторон модемы OnCell G3150, за одним из которых (где ранее рассматривался маршрутизатор) ПК на базе ОС Windows, а за другим котроллер типа ПК без возможности поднятия своего VPN-клиента.

Наконец-то вы обозначили конечную задачу. Замечу следующее: 1) То что вы называете "сервером опроса", как я понял находящийся на стороне маршрутизатора циски, является на самом деле TCP/UDP-клиентом. А за модемом моксы соответственно находится TCP/UDP-сервер, который вы называете "клиентом". Где для совершения соединения само собой вам требуется указать TCP/UDP-клиенту адрес и порт TCP/UDP-сервера. 2) Вы пытались "серверу опроса" дать для соединения непосредственно адрес TCP/UDP-сервера (в вашем понимании "клиента"), находящегося за модемом. Но, чтобы сделать возможным прохождение из интернета IP-пакетов до модема, находящегося за NATом оператора, вам потребовалось прокинуть VPN-туннель между модемом моксы и маршрутизатором циски. Однако, вы не учли, что IPSec-туннель позволяет лишь получить канал между двумя конечными точками, в вашем случае между внешними интерфейсами моксы и циски. При котором вам гарантируется лишь прохождение пакетов адресованных на конечные точки с них самих или же с указанных в фильтрах IPSec локальных сетей. Прохождение пакетов адресованных в локальные сети, разрешенные в фильтрах IPSec, возможно, если интерфейсы конечных точек туннеля являются шлюзами этих локальных сетей. Насчёт циски, являющейся маршрутизатором - нет вопросов, на ней возможна маршрутизация и NAT. А вот насчёт модема моксы - возник вопрос, на который господин Солуянов дал инструкцию, которая фактически говорит о том, что внешний интерфейс модема при VPN-туннеле является шлюзом в его локальную сеть. У вас не получилось подтвердить это, у меня тоже, как и у многих специалистов этого форума, при этом господин Солуянов молчит, в ответ на запрос не даёт протокол испытаний и ни чем не подтверждает заявленное в его инструкции. На данный момент времени, применяя модем моксы и VPN-туннель, максимум мы можем добиться лишь прохождения пакетов до внешнего интерфейса модема из локальной сети циски, в т.ч. вашего "сервера опроса", и обратно. Решение: 3) В т.ч., согласно вышеизложенному, я не согласен с вашим замечанием, о том, что вы не можете указать вашему "серверу опроса" (TCP/UDP-клиенту) динамический адрес внешнего интерфейса модема моксы. Да, внешний адрес у вашего модема динамический. Однако, он доступен за счёт VPN-туннеля, того, что был вами ранее поднят. Проброс TCP/UDP-порта с вашего "клиента" (TCP/UDP-сервера) средствами Virtual Server моксы на её внешний интерфейс позволил бы соедининиться по этому адресу вашему "серверу опроса". Осталось бы решить вопрос: А что делать с динамичностью адреса, как восстановить соединение, опрос при смене адреса в случае разрыва сотовой связи, в т.ч. при перезагрузке модема? Есть такая функция в модемах моксы, как то Auto IP Report, способная с интервалом 1-99 мин. высылать сообщение о внешнем адресе модема на указанный в её настройках UDP-порт и адрес. По функции существует описание формата сообщения, а также ПО OnCell Search Utility, способное принимать сообщение и выводить информацию. Помимо этого у модема есть возможность работать с ПО OnCell Central Manager\Server, которое можно установить на вашем "сервере опроса", если он работает под ОС Windows. Указанная функция и ПО позволяют получать информацию от модема о его текущем внешнем адресе. Если бы вы смогли научившись снимать её и автоматом прописывать в настройках соединения вашего "сервера опроса" с перезапуском его, то динамический адрес модема не был бы вам помехой. К сожалению, производитель модема не развил идею использования функции Auto IP Report до "коробочной версии" в виде не просто юзерской утилиты, а виртуального сетевого интерфейса, так чтобы мы имели дело не просто с туннелем, а с интерфейсами аналогичными, что в VPN при протоколах PPTP/L2TP. Поэтому реализация этой идеи возможно остаётся за вами. В общем, это и есть первое решение вашей задачи. 4) Однако, первое решение уже заходит в рамки программирования вашего "сервера опроса", реализации программной замены его настроек соединения. Что может вами быть не осилено. Поэтому второе решение предлагаю более простым, но о модеме придется забыть, пока господин Солуянов не докажет обратное. VPN-туннель + маршрутизация. Где остается лишь заменить модем на маршрутизатор. И тут есть 2-а варианта замены модема: а) 3G-маршрутизатор с VPN-клиентом IPSec. Здесь может быть рассмотрен вариант Moxa OnCell 5104-HSPA и т.п. Сначала советую проконсультироваться у техподдержки моксы, взять у них на тестирование. Но уверен, что по идее у вас на нём должно выйти задуманное. б) 3G-маршрутизатор с VPN-клиентом PPTP/L2TP. Кстати, который выйдет гораздо дешевле, чем маршрутизатор с IPSec. На роль которого подойдёт ваш подопытный TP-Link+3G-USB-модем. Где для построения VPN, VPN-сервер с протоколом PPTP/L2TP поднимаете на циске, если она умеет. Если нет, то пробрасываете на её внешний интерфейс порт (TCP=1723 для PPTP или TCP/UDP=1701 для L2TP) VPN-сервера, развернутого на вашем "сервере опроса", и строете VPN на нём. Пардон, циска-маршрутизатор, можно без проброса, через NAT; или поверх туннеля IPSec, если вы его построете в случае возможно способного на это вашего "клиента". А вот в случае не маршрутизатора, допустим модема, пробос точно потребовался бы.

Char, Вы только всё усложнили. У вас есть циска с впн-сервером на борту с одной стороны, с другой стороны была мокса с впн-клиентом,выходящим в интернет через внешний интерфейс. И по логам у вас всё было ОК, впн поднят. Как минимум вы могли при поднятом впн отпинговать внешний интерфейс циски, а при настроенном нат-т отпинговать находящийся за натом оператора внешний интерфейс моксы. Где при поднятом впн айписек (согласовании протоколов) между внешними интерфейсами моксы и циски, попытки сетевого опроса (в т.ч. пинга) с прочих интерфейсов в сети не прошедших согласование протоколов должны терпеть неудачу. А теперь вы развернули моксу, её внутренний интерфейс, через тот что впн-клиент моксы в интернет не ходит, в сторону тп-линка, выходящего в интернет, где циска. И ясен пень, что впна у вас теперь нет, так как вы пытаетесь его поднять через внутренний интерфейс моксы, не предназначенный для впн.

Char, а давайте попросим господина, предоставившего эту чудную инструкцию выполнить последний её абзац: "Для проверки доступности сетей на противоположный концах VPN-тоннеля используйте команду Ping." Я бы с удовольствием убедился бы в своей неправоте, если бы ему удалось сделать ping в локальную сеть модема, что из примера 192.168.127.0/24, извне с маршрутизатора. К тому же у меня есть вопрос к этому господину по его инструкции: А где в модеме G3110 устанавливается NAT в enabled? С маршрутизатором всё ясно, там есть NAT, и к тому же как и в модеме для VPN-протокола можем включить NAT-T, для хождения его через удаленный NAT. Но в модемах NATа, как в маршрутизаторе нет. В модеме есть только частный случай NATа в виде Virtual Server (PAT или DNAT, или как в циске PNAT) работающий на уровне транспортного, выше сетевого уровня, протокола в отличии от NAT. А без возможности работы на сетевом уровне, я не вижу возможности работы ping (ICMP).

1) Нет, не понимаете. Я вам посоветовал взять не "выделенную точку доступа", а частную сеть, выделяемую оператором, как правило по корпоративным тарифам, где он даст для доступа к ней частную APN. Это ради удобства в ваших экспериментах. Я бы не стал это советовать, если бы вы не пытались с помощью сетевых протоколов IP, ICMP проникнуть в локальную сеть модема. 2) Насчёт VPN вы заблуждаетесь. Заблуждаетесь в 2-х вещах: насчёт VPN-функций модема и насчёт протокола IPSec. Судя по логам вашего модема, вы уже подняли VPN-туннель. Просто вы не понимаете, что он даёт и как это работает на самом деле, поэтому не можете им воспользоваться.

Char, стесняюсь спросить: А куда вы пингуете с циски? В локальную подсеть за модем G3150 что ли? И при этом имеете публичный статический адрес на маршрутизаторе циски, а на модеме динамический за NATом оператора сотовой связи? И думаете, что маршрутизаторы внешней сети, находящиеся между вашим маршрутизатором и модемом, узнают каким-то образом маршруты в ваши локальные подсети? Я не вижу вашу задачу выполнимой, если вы хотите получить доступ в свои локальные подсети при таких условиях. Однако, если вы переведете маршрутизатор и модем в выделенную подсеть оператором, в виде частного APN, желательно со статическими адресами, то задача видется более решаемой. Но, к сожалению, может оказаться так, что модем всё равно не даст извне проникнуть в свою локальную подсеть, даже если вы пропишете верно маршрутизацию. В модеме невозможно прописать маршруты, настройки VPN-туннеля не дают маршрутизации. В добавок полагаю, что если оператор укажет шлюзы на внешних интерфейсах для хождения пакетов в ваши подсети, то модем может тоже не пропустить. При ваших исходных: Советую сначала провести простое тестирование соединения, отложить в сторону моксу и вместо неё взять простой 3G-модем-dongle, подключив его к серверу IPSec. На сервере сможете и с маршрутизацией прояснить ситуацию, если надумаете перевести ваш маршрутизатор и модем в одну подсеть. Заодно убедитесь, что поднятый VPN без маршрутизации не даёт доступа в локальные подсети. См. мой пост http://www.moxa.ru/forum/index.php?/topic/2480-g3150-%d0%b2-%d0%ba%d0%b0%d1%87%d0%b5%d1%81%d1%82%d0%b2%d0%b5-%d0%bc%d0%b0%d1%80%d1%88%d1%80%d1%83%d1%82%d0%b8%d0%b7%d0%b0%d1%82%d0%be%d1%80%d0%b0/

Пришёл ответ от МТС на наш уточняющий неофициальный запрос-просьбу ------------------------------------------------------------------------------------------------------------------------------------------------- > От: Андрей А Шамаев/Kostroma/Central/MTS/RU > Кому: Игорь С Кириллов/Tver/Central/MTS/RU@MTS/RU, > Копия: Дмитрий С Самойлов/MTS/RU@MTS/RU > Дата: 04.02.2014 16:45 > Тема: >>: > > Добрый день! > > Абонента интересует следующий вопрос, мы можем помочь? > > С уважением, > Шамаев Андрей Анатольевич > специалист ОРКК > Филиал ОАО "МТС" г. Ярославль > ----- Переслано: Андрей А Шамаев/Kostroma/Central/MTS/RU дата: 04. > 02.2014 16:36 -----> > От: Нас > Кому: МТС - artem.lukoyanov@*.mts.ru, Андрей А Шамаев > Дата: 29.01.2014 13:19 > Тема: > > Доброго времени суток! > > Интересует следующий вопрос. > > На данный момент организована защищённая частная сеть ***.msk с пулом адресов *.*.*.0/24 для обеспечения безопасной связи между двумя устройствами. > Для корректной работы оборудования необходимо сократить время задержки отклика в сети оператора, так как оборудование работает нестабильно. > Возможно ли это реализовать? > > Проблемное прохождение пакетов ICMP (ping) в сети выделенной оператором: > первый пакет 3500 мс, остальные в лучшем по 800 мс, но проблема когда задержка больше 2000 мс и с провалами в time out. > > Соответствие шкалы показателя RSSI с мощностью сигнала на приёме: > У нас проблема не в скорости передачи данных или её ограничении, у нас проблема вообще в передаче данных так таковой, её осуществимости в конечное время при уверенном радиоприёме в зоне покрытия оператора. У нас проблема выхода этого времени передачи данных за пределы работы IP (интернет-протокола), ICMP с получением ошибки time out (время для установления соединения истекло) при зарегистрированных оборудованием показателях уверенного радиоприёма. И как следствие этому у нас наблюдается проблема установления связи ПО с удаленным оборудованием при работе протоколов TCP/IP в канале передачи данных [контроллер-Ethernet IEEE802.3-IPмодем]-GPRS-оборудование оператора связи APN-GPRS-[iPмодем-Ethernet IEEE802.3-сервер]. Где на участке GPRS-оборудование оператора связи APN-GPRS наблюдаются задержки сигнала более 800-2500 мс и по истечении неопределенного времени уходящие в ошибку соединения по интернет-протоколу в time out. > > Поэтому есть огромная просьба специалистам оператора связи помочь нам и обеспечить на базе своего оборудования минимальные задержки сигнала (передачи данных) на своём участке канала GPRS-оборудование оператора связи APN-GPRS. При этом необходимо сделать надежным указанный участок канала, так чтобы задержка передачи данных в нём не была зависимой от побочной нагрузки на оборудование оператора и не выходила за пределы 1000 мс. > > Если это невозможно, то просим дать раскрытый ответ по технической проблеме и юридический ответ с точки зрения выполнения договора по обеспечению качества представленной услуги. Считаем, что при прохождении данных через участок канала GPRS-оборудование оператора связи APN-GPRS, предоставленный оператором связи при уверенном радиоприёме оборудованием абонента не должно возникать ошибки интернет- протокола в виде time out. Просим исправить и уменьшить задержку сигнала, сделать надежным (без сбоев в виде time out, возникающих вероятно из-за перегрузки оборудования оператора) канал или дать квалифицированный ответ, рекомендации по устранению проблемы. > > > С уважением, ………. ------------------------------------------------------------------------------------------------------------------------------------ Игорь С Кириллов/Tver/Central/MTS/RU написано 04.02.2014 16:51:05: > От: Игорь С Кириллов/Tver/Central/MTS/RU > Кому: Андрей А Шамаев/Kostroma/Central/MTS/RU@MTS/RU, > Дата: 04.02.2014 16:51 > Здравствуйте! > Это ping 2G, он реально не меньше 456 ms, в 3G пинг значительно ниже > - от 70 до 150 ms. > > С уважением, > Кириллов Игорь > Ведущий специалист Отдела привлечения клиентов бизнес-рынка > Департамент по работе с бизнес-рынком, Макро-регион "Центр" > ОАО "Мобильные ТелеСистемы" > ______________________________ __________________________________ > От: Андрей А Шамаев/Kostroma/Central/MTS/RU Кому: Игорь С Кириллов/Tver/Central/MTS/RU@MTS/RU, 04.02.201416:54 То есть абоненту, что посоветовать? С уважением, Шамаев Андрей Анатольевич специалист ОРКК Филиал ОАО "МТС" г. Ярославль -------------------------------------------------------------------------------------- От: Андрей А Шамаев/Kostroma/Central/MTS/RU Кому: Артем А Лукоянов/Yaroslavl/Central/MTS/RU@MTS/RU, Дата: 04.02.201417:00 С уважением, Шамаев Андрей Анатольевич специалист ОРКК Филиал ОАО "МТС" г. Ярославль l--- Переслано: Андрей А Шамаев/Kostroma/Central/MTS/RU дата: 04.02.2014 16:59 ----- От: Игорь С Кириллов/Tver/Central/MTS/RU Кому: Андрей А Шамаев/Kostroma/Central/MTS/RU@MTS/RU, Дата: 04.02.201416:56 Здравствуйте! Сначала надо выяснить в какой сети он работает - 2G или 3G. Если в 3G, то вопрос решаемый, если 2G - то вряд ли. С уважением, Кириллов Игорь Ведущий специалист Отдела привлечения клиентов бизнес-рынка Департамент по работе с бизнес-рынком, Макро-регион "Центр" ОАО "Мобильные ТелеСистемы" ______________________________ __________________________________ -------------------------------------------------------------------------------------- От кого: Артем А Лукоянов <Artem.*@*.mts.ru> Кому: Нам Копия: Андрей А Шамаев <*@*.mts.ru> Дата: Вторник, 4 февраля 2014, 17:15 +04:00 Добрый день! Судя по ответу ниже, все зависит от того, в какой сети Вы работаете - 2g или 3g. Если в 3G, то вопрос решаемый, если 2G - то вряд ли. С уважением, Лукоянов Артем Отдел по работе с корпоративными клиентами Филиал ОАО "МТС" в г. Ярославль --------------------------------------------------------------------------------------- Мои комментарии по переписке: Господа, добрый день. Из ответов МТС я понял, что господа Лукоянов А. и Шамаев А. - это менеджеры-попугаи, которые не знают своего товара (услуги) и к тому же делают неправильные выводы из указаний специалистов, игнорируют законные просьбы (требования) Заказчика. Которые не в состоянии откликнуться на просьбы Заказчика и предоставить хотя бы квалифицированный технически-обоснованный ответ, так как не обладают элементарными (на уровне стандартов) техническими знаниями в области той услуги, что представляют. Единственно адекватный человек из МТС по этой переписке - это Кириллов Игорь, который приводит достижимые значения по задержке сигнала для их сети GPRS и 3G. Так вот, господа, мы ждём от них официального ответа на официальное письмо и в случае отказа переходим от просьб к требованиям. Основываясь на ответе Кириллова Игоря, где он указывает, что для GPRS достижима задержка 456 мс - это нам подходит. Нам подходит задержка передачи данных 500-800 мс, но только без перебоев базовой станции оператора сотовой связи в виде time out. Перебои базовой станции в обслуживании нашего канала недопустимы!

Те же самые грабли и в новой версии 1.14 выпущенной 16 декабря 2013 г. http://www.moxa.com/..._id=5&type=soft Новее нет.

Добрый день. Вот вам доказательства. По скриншотам вы сами увидите ошибку программы. Утилиту версии 1.12 была загружена с сайта moxa.com 2 декабря 2013 г. P.S.: Новую версию 1.14 выпущенную 16 декабря 2013 г. не пробовал, к тому времени модемы OnCell G3150 уже были установлены на объекте.

Добрый день, публикую очередные новости про нелегкую GPRS в России, надеюсь, что будет полезно всем. Вот наш вопрос и ответ на него специалиста от оператора связи: ...................................... Дата: 22.01.2014 16:05 Тема: Ограничение скорости передачи данных в защищенной частной сети (GPRS) Андрей, добрый день! Интересует следующий вопрос. На данный момент организована защищённая частная сеть *****.msk с пулом адресо в 192.*.*.*/24 для обеспечения безопасной связи между двумя устройствами. Для корректной работы оборудования необходимо сократить время задержки отклика в сети оператора, так как оборудование работает нестабильно. Возможно ли это реализовать? Дата: Среда, 22 января 2014, 17:17 +04:00 Тема: Ограничение скорости передачи данных в защищенной частной сети (GPRS) Добрый день! От тех. блока последовал ответ на Ваш вопрос Работа устройств проверялась в зоне уверенного приема? Если там будет все ок, мы, как пакетная кора помочь не сможем, т.к радиочасть не наша ЗО. То есть если создать зону более уверенного приёма то это может изменить ситуацию, если приём и так уверенный то мы уже повлиять на скорость не сможем. С уважением, Шамаев Андрей Анатольевич специалист ОРКК Филиал ОАО "МТС" г. Ярославль e-mail: shaa@kostroma.mts.ru IP:99243 моб. +79159162886 раб. (4942) 650006 ........................... И вот несколько моих комментариев по нашему вопросу и на него ответу: 1) Не я задавал вопрос. Над проблемой трудятся с нашей стороны 2-а инженера-пусконаладчика, которые непосредственно ведут работы по настройке модемов на объекте. Я же инженер-проектировщик, но так как трудящиеся начали мне звонить с объекта и утверждать, что в модемах "пинга нет" - мне пришлось им доказать обратное, основываясь от природы прямых руках и 200+ самостоятельно изученных страниц мануала. 2) Каковы бы не были мои старания, но к сожалению другим людям свою голову не приложишь. 2-а месяца я трудился над горе-инженерами, удалось им втолковать на самостоятельно продемонстрированном мною примере настроек и они смогли поднять соединение на объекте с помощью Virtual Server модемов. Слава всевышнему, свершилось. К сожалению, не смог я донести до них теоретические знания, однако практика не подвела, но хоть так. 3) Вопрос наш поэтому задан коряво. Я просил инженеров доработать вопрос содинения, сделав его устойчивым, локализовал проблему связи, поднятия опроса контроллер-GPRS-ПО. Однако, думаю, что они спустят всё на тормозах, как и VPN, который они должны были согласно ТЗ поднять, но не сделали этого, как бы я их не пинал по этому вопросу, разжёвывая всю теорию. 4) Я переписал тему и вопрос и отослал инженерам, чтобы они переслали и не бросали диалог с оператором связи.

Здравствуй, господа специалисты, администраторы оного форума! Задаю вам вопросы, молчите. Рассчитываете на то, что потребители сами порешают вопросы, а вы в конце напишите "спасибо за новости!"? Какой-то странный вы форум ведёте...Ну да ладно, бог с вами...Вот вам новости: Вашему маркетингу и вам бесполезно задавать вопросы касательно сотовой связи так таковой и её адекватности в моксовых устройствах, поэтому решили поработать с сотовым оператором над вопросом GPRS. В данный момент времени специалист из МТС, что настраивал нам выделенную подсеть, дал ответ при телефонном разговоре о невозможности уменьшения времени отклика в его сети. Честно говоря, меня это удивило, так как всё происходит в пределах одного города и скорее всего в пределах одной базовой станции и вряд ли оператор использует спутниковые каналы в нашем случае. Задаюсь вопросом: Если спутниковые каналы не используются, то какие могут быть проблемы оператора в настройке своего оборудования? Запросили официальный ответ по нашему вопросу, уменьшению времени отклика GPRS, специалист обещал ответить. Вот такие новости.

Вот вообще мне не понятна ситуация с VPN в Moxa OnCell G3110/G3150. Не понятна потому что на самом деле Moxa эти устройства вообще представляет как шлюзы (Getaway), а не модемы. См. http://www.moxa.com/product/OnCell_G3110_G3150.htm, где устройство называется "Industrial quad-band GSM/GPRS/EDGE IP gateways with VPN". Модемами я их и сам называю, так как пока не вижу функции полноценного шлюза в них. Хотя с точки зрения Moxa модемами у них являются другие устройства, такие как OnCell G2111/OnCell G2151I. Заслуживает ли Moxa OnCell G3110/G3150 быть названными IP gateways with VPN? Нет ли здесь маркетингового обмана? Мне кажется по отношению к Moxa OnCell G3110/G3150 наблюдается прямая попытка со стороны Moxa обмануть пользователя. Специалисты с форума пишут, что эти IP gateways являются лишь клиентами. Но как так может быть? Это противоречит заявленному функционалу в названии. С точки зрения соединений VPN существует лишь 2-е структуры: Clent-to-Gateway, Gateway-to-Gateway, что подробно описывается MSDN Microsoft согласно там же указанных стандартов. Если в устройствах нет функции VPN-шлюза, то устройства Moxa OnCell G3110/G3150 должны на самом деле называться "Industrial quad-band GSM/GPRS/EDGE IP clients with VPN", и это было бы правильно. А сейчас получается, исходя из указаний специалистов (администраторов) форума, что производитель нам пользователям врёт и у нас появляются основание заявить на них в общество защиты прав потребителя. Товарищи по несчастью, предлагаю свертать Moxa OnCell G3110/G3150 им взад, за не выполнение функций!