В качестве пособия по работе с FTP использовал всем известный документ:
http://www.microchip.ua/simcom/SimCom/Appl.../SIM300_FTP.doc
Запускаю сервер, Логинюсь на FTP-сервере, создаю свои папки бегаю по ним и все такое...потом все созданые папки видно на консольке на ПК... проблема только состоит в том что немогу сосздать файл (вернее файл создается) и немогу записать в него данные в следствии того что два сервера не могут установить Data Connection... Вот сообщение выдаваемые сервером:
at+cipsend
> port 10,10,128,81,7,228
SEND OK
500 I won't open a connection to 10.10.128.81 (only to 81.23.24.44)
Мой ипишник 10.10.128.81 (выдается командой at+cifsr)... В тоже самое время просматривая FTP-сесию на консоли ипшник GPRS модема представляется как 81.23.24.44 (поиски в инете показывают что за этими адресами числятся "Киевстаровкие" сервера)?? При каждой новой FTP-сесии как первый так и второй ипишники меняются (динамические).
При попытке установить Data Connection на ипишник который выдает сервер тоже со времене приходит сообщение о ошибке:
at+cipsend
> port 81,23,24,44,7,228
SEND OK
200 PORT command successful
....
425 Could not open data connection to port 2020: Connection timed out
оно и ясно так как ипишник то не мой а какогото киевстаровкого сервера...
В эксперементах использую GPRS-интернет от DJUICE (он же "Киевстар") и платный FTP-сервер (на нем у нас сайт стоит). Как мне кажется проблема скорее всего именно GPRS сервисе оператора???
Подскажите кто как боролся с Data Connection???
Полная версия этой страницы: Не удается запустить Data Connection на FTP(GPRS SIM300) ?
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Сотовая связь и ее приложения
Цитата(mapic @ Sep 17 2008, 19:00) 
Подскажите кто как боролся с Data Connection???
Да никак ты его не поборешь. Ты за NAT провайдера. Только купить у провайдера услугу "реальный ip-адрес", чтобы он выдавал тебе адрес не из диапазона 10.*, а из 81.*.
В реальном мире используют PASSIVE MODE FTP, чтобы соединения всегда создавал ты (подразумевается, что FTP-сервер сидит на нормальном доступном адресе). Но с SIM300 это работать не будет - его внутренний стек держит только одно соединение.
Цитата(stream @ Sep 18 2008, 10:39)
Да никак ты его не поборешь. Ты за NAT провайдера. Только купить у провайдера услугу "реальный ip-адрес", чтобы он выдавал тебе адрес не из диапазона 10.*, а из 81.*.
В реальном мире используют PASSIVE MODE FTP, чтобы соединения всегда создавал ты (подразумевается, что FTP-сервер сидит на нормальном доступном адресе). Но с SIM300 это работать не будет - его внутренний стек держит только одно соединение.
В реальном мире используют PASSIVE MODE FTP, чтобы соединения всегда создавал ты (подразумевается, что FTP-сервер сидит на нормальном доступном адресе). Но с SIM300 это работать не будет - его внутренний стек держит только одно соединение.
...и что больше никак??? а выглядело все так просто!!! Может попробовать с другими операторами например МТС?
...а какие еще варианты имеются?? Нужно переодически записывать в файл на удаленом сервере небольшой обем данных. Пробовал через почтовый сервер на емейл так с Киевстара нормально кактит...
Цитата(mapic @ Sep 18 2008, 15:14)
...и что больше никак??? а выглядело все так просто!!! Может попробовать с другими операторами например МТС?
...попробовал с оператором "Джинс" от МТС (Украина) - все заработало как в описании... просто отлично! Должно быть дело было в операторе и в выделяемыми им ипишниками...
В результате недолгих экспериментов выявил новую "бяку"... После любой команды связаной с Data Connection (создание файла, запись даных в файл, чтение файла и дериктории) соединение Control Connection закрывается (CLOSED) а Data Connection остается...после попытки передать что то по Data Connection и оно закрывается... После чего приходится каждый раз конектится и логинится на ФТП сервере?
Как избежать обрыва соединения???
P.S.Может кто видел ресурс по FTP где кратко и в доступной форме описаны команды???
Еще было замечено что модем неможет создать Data Connection в том случае когда на консольке запущен "файл менеджер" (на том же логине)... выдает ошибку:
425 Could not open data connection to port 2020: Cannot assign requested addres
В тоже время Control Connection отлично работает!
Как только файл менеджер на ПК был выключен сразу же без всяких перезагрузок стало работать и Data Connection на GPRS модеме???
425 Could not open data connection to port 2020: Cannot assign requested addres
В тоже время Control Connection отлично работает!
Как только файл менеджер на ПК был выключен сразу же без всяких перезагрузок стало работать и Data Connection на GPRS модеме???
Цитата(mapic @ Sep 18 2008, 19:33)
...попробовал с оператором "Джинс" от МТС (Украина) - все заработало как в описании... просто отлично! Должно быть дело было в операторе и в выделяемыми им ипишниками...
Ну да, выделяемые адреса разные. Вот только на российском МТС тоже одно время была типа халява. Всем давали случайные, но настоящие адреса. А потом все равно всех под NAT загнали. И украинцы тоже могут в любой момент все переделать.
Цитата
В результате недолгих экспериментов выявил новую "бяку"... После любой команды связаной с Data Connection (создание файла, запись даных в файл, чтение файла и дериктории) соединение Control Connection закрывается (CLOSED) а Data Connection остается...после попытки передать что то по Data Connection и оно закрывается... После чего приходится каждый раз конектится и логинится на ФТП сервере?
Как избежать обрыва соединения???
Как избежать обрыва соединения???
Перешивать, если можно. Это баги номер 22 и 23, исправленные в 18-й версии (для обычного SIM300).
Цитата(stream @ Sep 19 2008, 10:46)
Ну да, выделяемые адреса разные. Вот только на российском МТС тоже одно время была типа халява. Всем давали случайные, но настоящие адреса. А потом все равно всех под NAT загнали. И украинцы тоже могут в любой момент все переделать.
Перешивать, если можно. Это баги номер 22 и 23, исправленные в 18-й версии (для обычного SIM300).
Перешивать, если можно. Это баги номер 22 и 23, исправленные в 18-й версии (для обычного SIM300).
Да может Вы и правы... Украинский МТС (Джинс) выделяет ипшники типа 88.214.89.200 что и позволяет работать с Data Connection...
Я пошол дальше и опробовал разные украинские операторы на предмет возможности работы в режиме Data Connection... вот результат: Диджус, АсеВасе от Киевстара, Билайн не работают (ипишники начинаются с 10....); Джинс (а соответствено и МТС надо полагать) - работают ипишники начинаются с 88...
А каким еще способом возможно записать даные в файл на FTP или HTTP сервер???
Цитата(mapic @ Sep 22 2008, 17:40)
Да может Вы и правы... Украинский МТС (Джинс) выделяет ипшники типа 88.214.89.200 что и позволяет работать с Data Connection...
Ну так почитайте какие-нибудь основы по TCP/IP, где расписаны диапазоны адресов для локальных сетей - сразу все будет понятно, с кем будет работать, а с кем - нет.
Цитата
А каким еще способом возможно записать даные в файл на FTP или HTTP сервер???
Во-первых, можно использовать http post (требуется поддержка на сервере, типа скрипта, который этот post будет разгребать). Во-вторых, если сервер собственный, проще написать свою крохотную программу, которая будет принимать данные по вашему личному протоколу и складывать, куда надо.
Цитата(mapic @ Sep 18 2008, 16:14)
...а какие еще варианты имеются?? Нужно переодически записывать в файл на удаленом сервере небольшой обем данных.
Я для пожожей цели использовал HTTP POST, а на сервере обыкновенный апач и cgi скрипт.
Данные не кодировал никак: бегло пролистав RFC, прямого запрета делать content-transfer-encoding: binary вроде как не нашел, апач поддерживает.
(Если это криминал, пусть знатоки поправят).
Запрос выглядит примерно так (конец строки = CR+LF):
Код
POST /cgi-bin/server_script.cgi HTTP/1.1
Host: www.myserver.net
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-Length: 123
{пустая строка!}
{ровно 123 байта данных}
Host: www.myserver.net
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-Length: 123
{пустая строка!}
{ровно 123 байта данных}
Если данные сбрасываются редко, то Connection: close и соединение закрывается после одного запроса. Если часто, то лучше работать в режиме Keep-Alive, отслеживать состояние соединения и переконнекчиваться при потере tcp connect.
Цитата(Овец @ Sep 23 2008, 10:37)
Я для пожожей цели использовал HTTP POST, а на сервере обыкновенный апач и cgi скрипт.
Данные не кодировал никак: бегло пролистав RFC, прямого запрета делать content-transfer-encoding: binary вроде как не нашел, апач поддерживает.
(Если это криминал, пусть знатоки поправят).
Запрос выглядит примерно так (конец строки = CR+LF):
Если данные сбрасываются редко, то Connection: close и соединение закрывается после одного запроса. Если часто, то лучше работать в режиме Keep-Alive, отслеживать состояние соединения и переконнекчиваться при потере tcp connect.
Данные не кодировал никак: бегло пролистав RFC, прямого запрета делать content-transfer-encoding: binary вроде как не нашел, апач поддерживает.
(Если это криминал, пусть знатоки поправят).
Запрос выглядит примерно так (конец строки = CR+LF):
Код
POST /cgi-bin/server_script.cgi HTTP/1.1
Host: www.myserver.net
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-Length: 123
{пустая строка!}
{ровно 123 байта данных}
Host: www.myserver.net
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-Length: 123
{пустая строка!}
{ровно 123 байта данных}
Если данные сбрасываются редко, то Connection: close и соединение закрывается после одного запроса. Если часто, то лучше работать в режиме Keep-Alive, отслеживать состояние соединения и переконнекчиваться при потере tcp connect.
...неясно куда имено сбрасываются данные?? - в файл? ... а если мне еще нужно данные и с сервера читать (например из файла??).
...и еще одно а если всетаки сервер не свой? - и имеется только логин и параль доступа?
У Лайфа ИП прямые (пока?). А качать с сервера по ХТТП и того проще:
GET /file.bin HTTP/1.0
...
...
...
где /file.bin путь и имя файла.
GET /file.bin HTTP/1.0
...
...
...
где /file.bin путь и имя файла.
Цитата(bloodden @ Oct 20 2008, 17:22)
У Лайфа ИП прямые (пока?). А качать с сервера по ХТТП и того проще:
GET /file.bin HTTP/1.0
...
...
...
где /file.bin путь и имя файла.
GET /file.bin HTTP/1.0
...
...
...
где /file.bin путь и имя файла.
...у Украинского "Джинса" ип тоже прямые (и "МТС" наверное тоже)...
на самом деле достаточно часто nat встречается подержка ftp - в этом случае проблем с ftp не будет.
ps: увы, часто - это "вообще", а у сотовых операторов норма - серые адреса и nat без поддержки ftp. на это и нужно ориентироваться.
ps: увы, часто - это "вообще", а у сотовых операторов норма - серые адреса и nat без поддержки ftp. на это и нужно ориентироваться.
Цитата(bloodden @ Oct 20 2008, 17:22)
У Лайфа ИП прямые (пока?). А качать с сервера по ХТТП и того проще:
GET /file.bin HTTP/1.0
...
...
...
где /file.bin путь и имя файла.
GET /file.bin HTTP/1.0
...
...
...
где /file.bin путь и имя файла.
...вчера испытывал... нефига неработает...
Цитата(mapic @ Oct 22 2008, 11:34)
...вчера испытывал... нефига неработает...
Что именно не работает? Браузеры, когда качают файлы/страницы (что есть одно и то же) так и делают. И WWW до сих пор работает на этом.
PS: Это, естественно, путь к файлу от корня ХТТП сервера.
Цитата(bloodden @ Oct 22 2008, 23:42)
Что именно не работает? Браузеры, когда качают файлы/страницы (что есть одно и то же) так и делают. И WWW до сих пор работает на этом.
PS: Это, естественно, путь к файлу от корня ХТТП сервера.
PS: Это, естественно, путь к файлу от корня ХТТП сервера.
...я в том смысле что сервер пишет что незнает такой команды???
...а может это у меня просто сервер фтп??? - а где тогда найти хттп сервер и как на него законектится?
Порт 21 - фтп, а ХТТП - 80 (или 8080) обычно.
Цитата(bloodden @ Oct 25 2008, 13:11)
Порт 21 - фтп, а ХТТП - 80 (или 8080) обычно.
ОК... попробуем... я думаю что причина имено в порте...
...а как на счет инет-серверов??? - они хттп 1 поддерживают как стандартный протокол?
Цитата(mapic @ Oct 27 2008, 09:53)
ОК... попробуем... я думаю что причина имено в порте...
...а как на счет инет-серверов??? - они хттп 1 поддерживают как стандартный протокол?
...а как на счет инет-серверов??? - они хттп 1 поддерживают как стандартный протокол?
1.0 и 1.1
Всем привет.
Расскажу свои мытарства. Пробовал по FTP на beeline Россия, не получилось, как после выяснилось из-за NAT. По http GET получился сразу, а POST ни в какую. Причем с компа с помошью проги inetcrack, запросы работают.
GET /test.dat HTTP/1.0
Host: xxxxx
Referer: xxxxx
Cookie: income=1
POST /priem.php HTTP/1.0
Host: xxxxx
Content-Type: multipart/form-data; boundary=gggggggg
--gggggggg
Content-Disposition: form-data; name="filename"; filename="qqq.jpg"
Content-Transfer-Encoding: binary
tytytytytytytyty
--gggggggg--
Создается впечатление, что запрос искажается при передаче модемом. Прошу всех высказать свои предположения по этой проблеме.
Расскажу свои мытарства. Пробовал по FTP на beeline Россия, не получилось, как после выяснилось из-за NAT. По http GET получился сразу, а POST ни в какую. Причем с компа с помошью проги inetcrack, запросы работают.
GET /test.dat HTTP/1.0
Host: xxxxx
Referer: xxxxx
Cookie: income=1
POST /priem.php HTTP/1.0
Host: xxxxx
Content-Type: multipart/form-data; boundary=gggggggg
--gggggggg
Content-Disposition: form-data; name="filename"; filename="qqq.jpg"
Content-Transfer-Encoding: binary
tytytytytytytyty
--gggggggg--
Создается впечатление, что запрос искажается при передаче модемом. Прошу всех высказать свои предположения по этой проблеме.
Нужно было Content-Length: добавить и указать длину сообщения. Смутило, что из inetcrack все работало и без длины. Спасибо разработчикам этой программы. Позаботились о комфорте.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.