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, если вы его построете в случае возможно способного на это вашего "клиента". А вот в случае не маршрутизатора, допустим модема, пробос точно потребовался бы.