Search in topic

Вопрос знатокам . Открытие портов.

Долго не писал отчёта о проделанной работе, так как возникающие вопросы пытался сам гуглить.
И пришёл к выводу, что,походу, ввёл всех в заблуждение. Контрольный вопрос, звучавший ранее «а слушает ли кто данный порт?»
По порядку,что сделано :
Выполнил на нужном компьютере(пусть будет комп1) команду netstst -abn и в списке не обнаружил необходимый порт.
Далее взял другой компьютер (пусть будет комп2) отключил его от домашней сети и подключил к модему gsm (в телефон вставил сим карту (с помощью которой буду организовывать связь sim800 с комп1) и организовал точку доступа по WiFi)
На обоих компьютерах скачал и установил рекомендованные программы Putty и Wireshark.
На комп2 запустил их и в Putty стал пытается организовать подключение к комп1 порту 3846( перварительно узнав ip адрес модема комп2)
На комп1 запустил Wireshark и в общем потоке информации «нашёл» ip комп2 и то, что он пытается зайти в порт 3846. Поставил фильтр на обоих компах, и фактически на них информация идентична.
Комп1

Комп2

Из чего я сделал выводы :
Сим карта работает
Роутер видит запрос подключения на порту 3846 отправляет это подключение на локальный комп1 порт 3846
Комп1 видит эти подключения
Дальше догадки : так как подключаться ему не с кем, связь обрывается.
Решил организовать прислушивание при помощи программы netcat , но пока безуспешно (как писал ранее уровень знаний ‘интуитивный’))

Наверно надо было сразу рассказать, что я задумал (а вдруг всё уже придумано за нас)
Есть в интернете проект по передаче mavlink через gprs на программу mission planer ( ykoctpa.ru/…/prozrachnyj-modem-telemetrii-cherez-g… ). Автор данного проекта осуществил данную идею и описал её. А попытался повторить. Собрал девайс, залил код . Ну и собственно тупик. Автор долго и упорно пытался мне помочь , но переодически модули выходили из строя , и наше общение прерывалось до покупки следующего модуля. Причину выхода модулей из строя я ,возможно, нашёл (высокие логические уровни) и исправил, добавил делителей. Но увы, автор очень занятой человек, и ,на данный момент, он не в силах мне помочь .
И я решил, что по-тихонечко, тихим сапом, я сам смогу организовать такое соединение. И сейчас вижу следующую проблему:
В mission planer есть подключение по upd и tcp . По tcp программа сама по всей видимости пытается организовать подключение(а не с кем, так как ip у модема совсем серый). А вот upd подключение- там задаёшь только номер порта , и программа долгое время его прослушивает. Ват я и решил, что на модеме надо организовать соединение с комп1 на порт3846,как раз который слушает программа … и для этого я решил сначала проверить , открыт ли порт.
И замудрил всем мозг.))

Дальше догадки : так как подключаться ему не с кем, связь обрывается.

Все правильно поняли. Именно так.

Есть в интернете проект по передаче mavlink через gprs на программу mission planer

Из того что прочитал бегло по вашей ссылке
—
Для использования нужен сервер где-нибудь в интернете
…
она будет принимать все на порту 8888 и передавать на порт 7777, и наоборот, все принятое на порту 7777 передавать на порт 8888. При старте модем подключается к порту 8888 (порт и адрес можно выбрать в конфигураторе), остается настроить МиссионПланнер/Tower на подключение к порту 7777 сервера - и вы имеете надежную связь с вашим дроном надо всем городом.
—
+

По tcp программа сама по всей видимости пытается организовать подключение

Как я это понял == И МиссионПланнер И источник данных (то что за модемом) оба работают как клиенты и не один из них не работает как сервер слушающий порт.

Поскольку ни тот ни другой сами порты (хоть UDP хоть TCP) не слушают то и напрямую между собой их не соединить. И дело тут не в типе канала (TCP или UDP), а в принципе подключения. Что по тому что по другому протоколу клиент с клиентом не соединятся нужен сервер посредник.

Некоторая промежуточная программа сервер - задача которого слушать два порта и перебрасывать данные из одного в другой. От одного клиента к другому. Эдакий кросс кабель или промежуточный хаб при соединении сетевых плат двух компьютеров.

По той ссылке что вы дали в качестве такого сервера посредника предлагается использовать комбинация утилит stdbuf, nc + заранее созданый Unix сокет. Перенаправляя ввод вывод с портов (используя Netcat для приема соединения) в поток и обратно. Аналогов для windows не подскажу.

А вот upd подключение- там задаёшь только номер порта , и программа долгое время его прослушивает.

Нет не так. Там тоже МиссионПланнер выступает как клиент. По крайней мере nc -ulk 7777 на это намекает -l принимать соединения -k после закрытия возвращаться в режим приема соединения -u по протоколу udp. + Остается настроить МиссионПланнер/Tower на подключение к порту 7777 сервера ==> МиссионПланнер клиент и сам ничего на порту 7777 не слушает. Он к этому порту обращается присылая свои данные и ожидая ответа от сервера на свой динамический порт переданный в составе пакета данных.

В UDP протоколе тоже есть клиент и сервер. Они не договариваются о канале и не следят за успешностью доставки но схема работы та же. Кто то клиент кто то сервер. И без особых ухищрений клиент может соединиться только с сервером (имеющим хорошо известный порт) но не с другим клиентом (получающий номер порта случайным образом).

Общая схема работы UDP очень похожа на TCP
Сервер резервирует и прослушивает всем хорошо известный UDP порт (назначенный в конфигурации) а получив пакет данных может пользуясь адресными данными клиента записанными в полученном пакете ответить клиенту. В свою очередь клиент (а точнее операционная система создавая UDP сокет) случайно резервирует номер UDP порта и записывая его в качестве обратного адреса шлет UDP серверу данные на заранее известный серверный адрес и порт. Различие только в том что канал не создается, готовность читать не проверяется и успешность доставки не контролируется - если кто то слушает данные на указанному адресе отлично. Данные ему отдадут на обработку. Нет никого - данные выбросить и забыть.

Собственно основное различие программы UDP сервера и UDP клиента - сервер имеет фиксированный номер порта и обычно сперва слушает/принимает данные и потом ориентируясь на адрес откуда поступили данные иногда по этому адресу отвечает.

А UDP клиент наоборот фиксированного хорошо известного порта не имеет (имеет временный назначенный случайно) и сперва шлет данные по хорошо известному серверному адресу порту а потом иногда если предусмотрено протоколом обмена получает от сервера ответ на свой указанный в посылке к серверу случайный UDP порт.

По всем приметам МиссионПланнер всегда клиент что в TCP что в UDP и ему всегда нужен сервер посредник между ним и mavlink через gprs.

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

• следовать основной затее автора и снова арендовать сервер с внешним ip. Запросить у автора код и детально его анализировать и искать в нём неточность и свои ошибки, которые препятствуют реализации идеи.
• следовать основной затее автора , найти программу или набор команд для реализации сервера на своём компьютере(win8) . Тем самым, при помощи внутреннего сервера, соединить двух клиентов . Но также необходимо запросить код, и его анализировать, так как там есть определённый тупик .
• вернутся к истокам данной идеи
  diydrones.com/…/adding-external-configuration-gprs… Если я правильно понимаю, то там как раз идёт подключение напрямую, без серверов. И следуя логике, сам модем выступает сервером . Но проект на английском языке, а гугол переводчик прямо огонь)). Собственно я из за этого и отказался от этого решения в пользу решения нашего соотечественника .
  В общем, буду думать …
  А ещё маленький вопрос- «туннелирование» вроде так называется- это случаем не создание, так сказать, мини сервера для двух клиентов? Рою в интернете решение ))))

А ещё маленький вопрос- «туннелирование» вроде так называется- это случаем не создание

Увы нет. Сервера при туннелировании используются но они служат как своеобразный удлинитель а не как соединитель клиентов.
Образно - туннель через сервер (обычно через SSH) это шнурок мама-папа, а вам нужен шнурок мама-мама.

следовать основной затее автора и снова арендовать сервер с внешним ip

Не обязательно внешний и арендовать сервер.
Внешний ip адрес уже есть у вашего роутера (пусть он и динамически назначаемый об этом кстати ниже будет пара слов как компенсировать), а проброс портов на компьютер внутри сети вы освоили
Так что :

1. если есть “лишнее старенькое железо” можно в локальной сети поднять на нем какую нибудь из вариаций Ubuntu, Mint … и на ней запустить предложенную автором комбинацию
2. если старенького железа нет но зато на основном памяти и процессора “с запасом” можно на Windows поставить гипервизор скажем VirtualBox и в его рамках понять виртуалку Unix в режиме совместного владения сетевой картой - дальше аналогично.

В принципе это не сложнее и не дольше чем настроить проброс порта. (Разбирать код и программировать сервер без навыка будет гораздо дольше)

запросить код,

Тоже можно. Код то на чем и чего. Если код ардуинки и инициализации модема то см. ниже.

вернутся к истокам данной идеи

Не похоже чтобы в оригинале сервер был на модеме .

while(!sendATCommand(“AT+CLPORT=\“UDP\”,8888”,“OK”,100)); // Prep UDP Port 8888
while(!sendATCommand(“AT+CIPSTART=\“UDP\”,\“drone.dyndns.com\”,8888”,“OK”,1000)); // AT+CIPSTART=“protocol”,“ip address or domain”,“port #”.

Из описания команд модема

• AT+CLPORT command sets the local port number for the TCP or UDP connection. The port number can be a number between 0-65535
• AT+CIPSTART comamnds starts a TCP or UDP connection.

Соединение всегда начинает клиент. Так что по ходу и в оригинале модем как клиент устанавливает соединение по UDP на порту 8888 с сервером drone.dyndns.com
(сам для приема ответов от этого сервера также использует порт 8888 но такое совпадение не обязательно)

Что стоит на сервере drone.dyndns.com и слушает порт 8888 и как потом данные добегают “куда надо” вопрос отдельный.

Сервер drone.dyndns.com судя по имени в сети находится нерегулярно и при подключении получает хотя и реальный но динамически назначаемый адрес (ну вот прямо как ваш роутер). И чтобы постоянно не перепрограммировать для модема значение IP адреса в командах выше, этот сервер арендует имя (зону) drone в сервисе dyndns.com и при каждом старте после получения IP адреса от провайдера забегает в сервис (это динамический DNS сервер) для регистрации связки полученного IP с именем drone.dyndns.com. За счет этого в коде инициализации модема “гвоздями прибит” адрес drone.dyndns.com и никто не парится что от старта к старту IP адрес сервера куда обращается модем меняется.

Но модем в оригинале увы клиент. А сервер что то другое и вряд ли это МиссионПланнер на машине с именем drone.dyndns.com.

Хотя судя вот по этом вопросу
A question to configure the GCS part : i see your dronecell modem will send telemetry data to IP “drone.dyndns.biz:8888” which should correspond to a UDP server listening on the GCS side. My question is how do you configfure mission planner to start a listening server on this drone.dyndns.biz:8888

и комментарию
The domain resolves to your computer using a dynamic dns service, so when your in Mission Planner you just need to select UDP from the drop down menu then click connect. Then you enter
the port number and click okay. If your firewall isn’t blocking UDP the connection will be established.

За фразу
— вряд ли это МиссионПланнер на машине с именем drone.dyndns.com.
я бы уже и не поручился. Может действитель МиссионПланнер может работать как сервер принимая UDP соединения.
Это было бы странно чтобы по TCP он работал как клиент а по UDP как сервер - но чем черт не шутит технически это возможно. Надо читать руководство к настройке МиссионПланнер-а.

Любопытство не порок - оно гораздо хуже. 😃
По гуглив и посмотрев документацию

Судя по картинке тут
ardupilot.org/planner/docs/common-mp-tools.html

в “секретных настройках” MissionPlanner относящихся к Mavlink есть выпадающее окно определяющее тип соединения и протокол .
На картинке на него показывает стрелочка 2 и оно в состоянии UDP client.
Если волею судеб и программистов MissionPlanner-а там есть и можно выбрать UDP server - бинго MissionPlanner может сам работать как сервер конфигурируйте его на это и проброс порта заработает. А если нет и в выпадающем окне одни клиенты (TCP и UDP)- ну на нет и суда нет.

Первое : исходя из Вашего ответа, мне не только надо учиться пробрасывать порты, но и уметь гуглить 😃

Второе: это называется «бинго» 😎 или всё же рано радуюсь?
Третье : собираюсь в будущем организовать ddns, ибо данную опцию даже роутер предлагает с каким-то своим аффилированным сервисом. Но сейчас, ввиду ограниченности по свободному времени, весь упор на реализацию самой идеи.

это называется «бинго»

Это бинго.

Настраивайте MissionPlanner-а как UDP-host а свой роутер на проброс UDP портов. (до этого вы настраивали проброс TCP портов. При настройке проброса UDP скорее всего отличие галка в типе порта остальное тоже)

UDP потому что во всех примерах и кодах настройки модема и ардуинки которые я увидел использовался именно он - вам проще будет найти примеры.

Для UDP тройки [SYN] [SYN, ACK] [ACK] как признака успешного создания канала в дампе не будет (нет в UDP каналов). Будут просто пакеты с данными по выбранным портам. НА это и ориентироваться.Так что алгоритм контроля и инструментарий что все работает практически тот же netstat для контроля что MissionPlanner порт слушает , Wireshark для перехвата и контроля наличия трафика, но а вот пробник/генератор UDP трафика нужен другой. Или поставить NetCat для windows или использовать сам Mavlink. Putty с udp не работает

Технически можно использовать и TCP-host и проверить соединение как раньше но тогда вам надо будет перенастроить инициализацию модема на TCP. На первый взгляд
while(!sendATCommand(“AT+CIPSTART=\“TCP\”,\“drone.dyndns.com\”,8888”,“OK”,1000)); // AT+CIPSTART=“protocol”,“ip address or domain”,“port #”.
должно быть достаточно

Но минус TCP в рамках этого проекта еще в том что если в момент старта модема (после AT+CIPSTART) или в процессе работы MissionPlanner отвалится и “порвет канал” то на стороне модема все тоже отвалится и он должен будет уйти на ре инициализацию и восстановление канала. Я внимательно не смотрел код и не уверен следит ли ардуинка Mavlink-а за целостностью TCP канала и уходит ли она на реинициализацию при его разрыве. Если нет то для TCP покопаться надо будет не только в инициализации но и в основном цикле.

А для UDP отправляющему наплевать готов ли кто либо и принимает какие либо данные или нет. Он отослал а там хоть огнем гори. Когда оба запустились и готовы обмен происходит сам собой. Если кто то отвалился ну значит отвалился. Пока его нет все отосланное в его адрес потеряется. Когда вернется и начнет принимать обмен восстановится.

Удачи в настройке.

Олег, спасибо огромное ! Вы реально очень сильно помогли. Будете в Питере- с меня коньяк!