Некоторое время назад мне предложили немного поработать с одноплатным ПК Orange Pi 2G-IOT (встроенный 2G и цена выглядят очень привлекательно). Прочитав пост об апельсиновом рае, я подумал, что без затруднений повторю этот путь, тем более, что с Linux я на «ты» (вернее, так я думал недели три назад) и уже имел опыт общения с Raspberry Pi 2 B+. На практике этот путь оказался намного длиннее. Создавалось ощущение, что наши китайские друзья намеренно создавали сложности (причём иногда с особым цинизмом). Если вы захотели сэкономить и купить эту плату, то сначала прочитайте этот пост и подумайте ещё раз.
По возможности, я постараюсь сдерживать эмоции или как минимум переводить их в юмор.
Итак, вот мне в руки попадает плата и SD карточка десятого класса. Поехали.
Всё ниже написанное относится к модели Orange Pi 2G-IOT, но в чате Телеграма (ищите «Orange Pi и не только») говорят, что модели 2G, 3G и 4G примерно одинаково себя ведут (одинаково плохо). Написанное НЕ относится к, например, Orange Pi PC и Orange Pi One, которые по отзывам ведут себя стабильно.
Мина №1 (учебная): скачивание образа ОС
Казалось бы, что может быть проще? Идём на сайт производителя и качаем. Однако все ссылки ведут на mega.nz, который собирает его прямо в браузере. Мой дешёвый ноутбук с 4 Гб ОЗУ не потянул такую задачу и вкладка упала. Можно было бы воспользоваться фирменной программой для скачивания с Меги, но он у меня не вызвал доверия (тем более, что в Интернетах некоторые пишут, что программа распознаётся антивирусами как вредоносное ПО). Варианты решения: скачать с неофициального сайта (например, здесь), развернуть виртуалку и поставить в ней клиент для скачивания с Меги, попросить кого-то с более современным ПК скачать образ.
Мина №2: выход в Интернет через модем
Дословно следуя настройке wvdial и pppd в Интернете, я внезапно обнаружил, что ping запросы проходят исправно, а вот обычные TCP пакеты ни в какую:
orangepi@OrangePi:~$ curl --interface ppp0 195.201.201.32
curl: (7) Failed to connect to 195.201.201.32 port 80: Connection timed out
orangepi@OrangePi:~$ curl --interface ppp0 195.201.201.32
curl: (7) Failed to connect to 195.201.201.32 port 80: Connection timed out
orangepi@OrangePi:~$ curl --interface ppp0 195.201.201.32
curl: (7) Failed to connect to 195.201.201.32 port 80: Connection timed out
orangepi@OrangePi:~$ curl --interface wlan0 195.201.201.32
46.0.208.54
orangepi@OrangePi:~$ ping 195.201.201.32 -I ppp0
PING 195.201.201.32 (195.201.201.32) from 10.33.64.21 ppp0: 56(84) bytes of data.
64 bytes from 195.201.201.32: icmp_seq=1 ttl=52 time=664 ms
64 bytes from 195.201.201.32: icmp_seq=2 ttl=52 time=240 ms
64 bytes from 195.201.201.32: icmp_seq=3 ttl=52 time=234 ms
64 bytes from 195.201.201.32: icmp_seq=4 ttl=52 time=246 ms
64 bytes from 195.201.201.32: icmp_seq=5 ttl=52 time=241 ms
64 bytes from 195.201.201.32: icmp_seq=6 ttl=52 time=237 ms
^C
--- 195.201.201.32 ping statistics ---
7 packets transmitted, 6 received, 14% packet loss, time 6032ms
rtt min/avg/max/mdev = 234.634/310.971/664.998/158.370 ms
orangepi@OrangePi:~$Решение подсказал edtun: https://www.linux.org.ru/forum/admin/12135523, хотя допускаю, что можно было как-то проще.
Сразу насторожило, что IMEI модема забит нулями. Благо, красно-белый оператор связи не обращает на это внимание. (Кстати, у встроенного WiFi аналогично нет МАС-адреса: при каждом передёргивании питания он генерируется случайным образом.)
Мина №3: USB порт
Втыкаем WiFi свисток в USB разъём и… Ничего не происходит. lsusb отобразил пустой USB порт. Небольшое копание показало, что в плате реально всего один USB. И по умолчанию он подключен к microUSB порту. Для переключения его на обычный USB HOST необходимо переключить на плате джамперы, которые находятся рядом с перемычкой для выбора загрузки. Их описание есть на 4pda:
Решение: переключить джамперы в положение: 1234 вниз, 5678 вверх.
Только потом я нашёл небольшое упоминание об этом нюансе в мануале к Orange Pi.
Мина №4: Драйверы
Теперь устройство определяется в системе, lsusb отображает производителя и код продукта, но беспроводной сетевой интерфейс в системе не определяется. Потому что разработчики не завезли на апельсинку драйвера для WiFi адаптеров. Причём вообще никаких. Есть драйвер только для встроенного WiFi, не больше и не меньше. А что мы делаем, когда у нас нет драйвера под наше железо? Правильно, идём собирать их из исходного кода!
Мина №5: Подготовка к сборке
В переписке bad__day предложил сборку непосредственно на Orange Pi. Может быть, это возможно, но мне не удалось.
Для Orange Pi разработчики сделали специальную Orange Pi Build System, с помощью которой в теории для сборки ядра или модулей к нему достаточно просто следовать указаниям на экране. Подробная инструкция изложена в мануале начиная с 61-й страницы. Казалось бы, просто следуй, и всё будет хорошо, но нет.
Во-первых, чтобы вручную не править все зависимости на своём компьютере (я регулярно обновляю ПО, это здорово, но не в этот раз), я развернул виртуалку с Ubuntu 16.04 и все действия проводил там. Во-вторых, в скриптах где-то вкралась ошибка, и Build System не ставила тулчейн для кроссплатформенной компиляции. Решается это таким костылём:
- Вручную apt-get'ом ставим тулчейн для кросскомпиляции под ARM.
- Делаем симлинки:
Обратите внимание: компилятор берётся версии 4.9, на версиях выше ничего не соберётся.mkdir $HOME/OrangePiRDA/toolchain/bin ln -s $(which arm-linux-gnueabi-ld) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-ld ln -s $(which arm-linux-gnueabi-gcc-4.9) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-gcc ln -s $(which arm-linux-gnueabi-g++-4.9) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-g++ ln -s $(which arm-linux-gnueabi-ar) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-ar ln -s $(which arm-linux-gnueabi-nm) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-nm ln -s $(which arm-linux-gnueabi-objcopy) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-objcopy ln -s $(which arm-linux-gnueabi-size) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-size - Открываем OrangePiRDA/scripts/Prepare_toolchain.sh и на всякий случай комментируем строки, упоминающие тулчейн.
На самом деле все эти скрипты просто вызывают apt-get install -y… и make. Скрипт не предлагает пользователю как-либо изменять конфигурацию (или я не нашёл?).
Но ведь нам ничего не мешает самим вызвать
make menuconfigи отметить нужные драйверы. Делаем это и снова собираем (теперь можно только модули) и…
Мина №6 (с прикрученным ИК датчиком движения и запасным детонатором): Сборка драйвера
… И тут скрипт приветливо стал задавать вопросы, как ему конфигурировать ядро. Он вызвал старомодный конфигуратор ядра, но почему?! Что не так?
Оказалось, что в Makefile прописано проверять ВРЕМЯ(!!!) изменения конфига!
В комментарии дословно написано «кто-то копался». (На скриншоте уже изменённый Makefile, я прописал menuconfig.) Пробовал вызывать make oldconfig, не заметил, чтобы это что-то где-то изменило. Ладно, теперь ведь при сборке вызовется menuconfig, это не страшно. Снова вызываю сборку, сборка замечает, что «кто-то копался в конфиге», вызывает menuconfig, я выхожу и жду завершения. А теперь представьте моё удивление, когда я не нашёл выбранный мною драйвер.
Что ж, лезем разбираться. Оказывается, make создаёт файл modules.order, где описаны все модули, которые будут скомпилированы. И даже после всех изменений конфига и его сохранения этот файл заполняется одинаковым набором. Я не придумал ничего лучшего, чем вручную дописать в него строки (мой свисток собран на чипсете RTL8192CU):
kernel/driver/net/wireless/rtlwifi.ko
kernel/driver/net/wireless/rtlwifi/rtl8192cu.koВсе упоминания этого файла в Makefile заменил на modules.order.fake. Запускаю сборку. На этот раз сборка пошла, но оборвалась, так как аналогичного файла нет в папке с исходным кодом rtlwifi. Я переименовал в этой папке и подпапках файлы modules.order.fake на modules.order, и это стало моим последним приключением при сборке драйвера. После этого система ещё два раза выводила мне menuconfig, как будто спрашивая меня «ты точно этого хочешь?», но всё же собрала дополнительно три заветных .ko файла, которые завелись как положено.
Мина №7: Совместная работа внешнего WiFi и модема
Немного поигравшись с airodump'ом и убедившись, что как минимум ловить пакеты в режиме монитора устройство умеет, я решил проверить модем ещё раз. Выполняю
sudo wvdialИ светодиод на внешнем WiFi адаптере гаснет, а SSH отваливается. В логах потом прочитал, что адаптер был отключен. Первая мысль — проблема с питанием. До этого момента я использовал свой зарядник на 1,5 Ампера, а производитель рекомендует аж целых 3 (куда столько? Она и одного Ампера даже не ест). Под рукой был зарядник на 2 Ампера, который годами исправно питал Raspberry Pi.
На данный момент я не нашёл какого-либо стабильного решения данной проблемы. Вот некоторые попытки решения:
- С вероятностью 80% можно отключить внешний WiFi с помощью:
chmod 777 /sys/bus/usb/drivers/usb/unbind echo 1-1 > /sys/bus/usb/drivers/usb/unbind
а затем запустить wvdial, который с 1-3 попытки установит соединение и можно выйти в Интернет. В 20% разного рода зависания и глюки. - Однажды случайно оказалась такая ситуация, что был убит wvdial, но pppd остался работать (как так может быть?), после которого поднялся внешний WiFi (см. выше, только вместо unbind пишем bind) и связь через модем была. Воспроизвести ситуацию не удалось.
- Оказалось, что можно без пересборки ядра отключать питание на USB с помощью такой утилиты командой
./hub-ctrl -h 0 -P 1 -p 0
и включить питание
На 2G-IOT поведение непредсказуемое: отключение питания может быть либо на одну секунду, либо до перезагрузки. При некоторых фазах Луны попытка вернуть питание приводит к зависанию платы../hub-ctrl -h 0 -P 1 -p 1 - Переключить джамперы на OTG (1234 вверх, 5678 вниз), питание подать на ноги GPIO 2 и 6 (прозванивал, они напрямую соединены с питанием microUSB)
Распиновка
подключить WiFi адаптер через USB-OTG переходник от смартфона. Система не видит USB устройства вообще. Возможно, надо настойчивее поиграться с джамперами.
Не проверялось, но может сработать (в планах опробовать все эти варианты):
- Другой WiFi адаптер.
- Очень стабильный источник питания с максимальным током 3 Ампера.
- Дополнительное питание к ногам USB.
- Бензин и спички.
В общем, задача выглядит как натягивание треугольного одеяла на четырёхугольный апельсин.
На этом пока всё.
UPD: Сегодня мне привезли источник питания с выходом 5В 3А. С ним удалось одновременно запустить и модем, и USB WiFi адаптер. Модем сыплет ошибками, перестаёт отвечать, но в среднем с третьей попытки подключается. После этого можно использовать USB WiFi.
Подводя итог.
Одноплатник Orange Pi 2G-IOT очень сырой и почти не поддерживается производителем. Даже на простых вещах, где казалось бы ничего не предвещает беды, что-то может пойти не так. Если необходимо использовать устройство с выходом в Интернет через мобильную сеть и вы не уверены, что сможете совладать с Orange Pi, то лучше доплатить и взять что-то более надёжное и отлаженное. Сбережёте время и нервы.
Комментарии (17)
gudvinr
22.02.2019 22:49+1встроенный 2G и цена выглядят очень привлекательно
Потому что в случае с Orange вы платите своим временем. С поддержкой драйверов и по для своих железок у них не просто плохо — у них никак.
xxxFeLiXxxx
22.02.2019 22:55Я когда-то тоже повелся на поводу маркетинга. Разработчики Chip обещали золотые горы, производительность и всякое такое задешево. Действительно, сперва я был очень доволен — процессор летал по сравнению с первым и вторым распбери. Однако с поддержкой и обновлениями было просто никак, пока в конце-концов они просто не объявили о банкротстве. ИМХО в таких случая софт важнее чистой производительности/фич, если хочется включить и чтобы оно работало, а не пересобирать ядро, попутно включая патчи, потому что обычная юсб сетевая карта просто не работает.
Serge78rus
23.02.2019 12:08Рекомендации производителя использовать источник питания с током 3А вполне справедливы, так как GSM модуль при работе передатчика в диапазоне 900МГц (мощность до 2Вт) в пике вполне может потреблять ток до 2А. В диапазоне 1800Мгц — немного полегче (мощность до 0.5Вт, но КПД, обычно, похуже).
id_potassium_chloride Автор
23.02.2019 17:24Вероятно, действительно проблема с питанием. Сегодня мне привезли источник питания 5В 3А и с ним хоть и с ошибками, но с 3-й попытки wvdial вышел в Интернет. Лагов никаких не было. Сейчас пытаюсь это всё автоматизировать и наблюдаю, что сразу после загрузки wvdial даже с 10-й попытки не может подключиться. А сейчас плата тупо перестала загружаться.
UPD: снова стала загружаться, хотя я ничего не изменял.Serge78rus
23.02.2019 19:09+1Судя по схеме, питание GSM модуля осуществляется непосредственно от цепи VBAT. Емкость блокировки по питанию в этой цепи всего 22мкФ, что, на мой взгляд несколько маловато. Я бы попробовал повторить все Ваши попытки с подключенным аккумулятором в качестве буфера по питанию.
id_potassium_chloride Автор
24.02.2019 02:18Здорово. Жаль, плюсануть не могу. У меня тоже была мысль вкрутить куда-то конденсатор или аккумулятор, только не мог придумать куда. Если модем реально оттуда берёт питание, то должно помочь. В принципе от него многого не требуется: всего лишь секунд на 30 «прикурить» модем и всё. Завтра у меня будет паяльник, надо попробовать, отпишусь о результатах. Вот почему нет нормальных одноплатников с модемом?
Serge78rus
24.02.2019 11:25Контактные площадки под не установленный 3-х контактный разъем для подключения аккумулятора хорошо видны на фото платы снизу: прямо под разъемом под 3.5мм джек. Правда, обозначение контактов "+" и "-" (минус в середине) противоречит изображенному на схеме разъему J302, где "+" и "-" — это крайние контакты, так что придется разбираться. Кстати, с блокировочной емкостью, похоже я ввел Вас в заблуждение и приношу извинения — на фрагменте схемы, рядом с упомянутым выше разъемом, нарисован конденсатор C4 емкостью аж 0.07F (если, конечно, это конденсатор — УГО на схеме как у батарейки).
id_potassium_chloride Автор
24.02.2019 13:16Я уже пробовал вчера пальцами держать на этих площадках аккумулятор. Судя по тому, что от платы не пошёл дымок и характерный запах, на плате "+" и "-" написаны правильно. Особого эффекта в работоспособности девайса я не заметил, но заметил изменение частоты звучания источника питания (источник питания нормальный, это я просто ухо прислонил), вероятно, пошла зарядка аккумулятора (хотя он и так до 4 В заряжен)
Serge78rus
24.02.2019 13:37Значит моя гипотеза про проблемы с питанием была не верна. Просто, за более чем 10 лет опыта работы с GSM модулями, сбои по причине плохого питания были одной из наиболее частых проблем.
id_potassium_chloride Автор
24.02.2019 16:40Думаю, дело в разработчиках платы. Сейчас я пытаюсь отследить закономерность и не нахожу её. Возможно, это какое-то когнитивное искажение, но кажется, как будто если вставить sd-карточку в ноут, прочитать syslog и вставить обратно, то вероятность успеха выше. Тупо примерно в 1/3 случаев подключение идёт как положено и всё работает (иногда даже дольше часа), а в 2/3 по кругу модем ошибками сыплет и/или просто не отвечает, wvdial отрубается, скрипт его запускает заново и так по кругу. Мне ещё одну плату привезли (из другого магазина даже, партия другая), с ней абсолютно тоже самое. Честно говоря я сейчас хочу уже тупо пробовать передёргивать питание и составлять статистику подключений, занося их в таблицу
Serge78rus
24.02.2019 17:52Можно ли из логов понять, на какие именно AT команды модем отвечает ошибкой? Доступен ли перечень команд модема и их описание? Есть ли вообще возможность в терминалке подавать AT команды и видеть ответы? Если ответ на последние два вопроса положительный, то может стоит попытаться вручную пройти все этапы подключения:
1. Убедиться, что модем зарегистрирован в сети оператора (пока только GSM, а не GPRS). Посмотреть уровень сигнала.
2. Если надо, настроить параметры GPRS подключения.
3. Попытаться получить GPRS контекст.id_potassium_chloride Автор
24.02.2019 19:24Да, можно. Чаще всего в самом начале CME ERROR:50. Реже 148.
Где искать подробную документацию по АТ командам я не знаю. Каких-то специфичных для этого модема я тоже не знаю. Здесь про модем много написано, оттуда всё работает.
Модем рабочий, видит нескольких операторов связи, есть сигнал и мне даже удалось успешно отправить АТ-командами СМСку на свой телефон.
Лог неудачного подключения скорее всего будет готов минут через 15 :)))
Вот лог удачного подключенияJan 1 00:03:24 OrangePI rc.local[414]: --> WvDial: Internet dialer version 1.61
Jan 1 00:03:24 OrangePI kernel: [ 204.582580] md_tty_install result 0
Jan 1 00:03:24 OrangePI rc.local[414]: --> Cannot get information for serial port.
Jan 1 00:03:24 OrangePI rc.local[414]: --> Initializing modem.
Jan 1 00:03:24 OrangePI rc.local[414]: --> Sending: ATE1
Jan 1 00:03:24 OrangePI rc.local[414]: ATE1
Jan 1 00:03:24 OrangePI rc.local[414]: OK
Jan 1 00:03:24 OrangePI rc.local[414]: --> Sending: AT+COPS=0
Jan 1 00:03:24 OrangePI rc.local[414]: AT+COPS=0
Jan 1 00:03:29 OrangePI rc.local[414]: --> Sending: ATQ0
Jan 1 00:03:29 OrangePI rc.local[414]: ATQ0
Jan 1 00:03:29 OrangePI rc.local[414]: +CME ERROR:50
Jan 1 00:03:29 OrangePI rc.local[414]: --> Re-Sending: AT+COPS=0
Jan 1 00:03:29 OrangePI rc.local[414]: AT+COPS=0
Jan 1 00:03:34 OrangePI rc.local[414]: +CTZV:19/2/24,13:8:3,12
Jan 1 00:03:35 OrangePI rc.local[414]: +CIEV: service, 1
Jan 1 00:03:35 OrangePI rc.local[414]: +CIEV: roam, 0
Jan 1 00:03:35 OrangePI rc.local[414]: +CREG: 1
Jan 1 00:03:35 OrangePI rc.local[414]: OK
Jan 1 00:03:35 OrangePI rc.local[414]: --> Sending: AT+CFUN=1
Jan 1 00:03:35 OrangePI rc.local[414]: AT+CFUN=1
Jan 1 00:03:35 OrangePI rc.local[414]: OK
Jan 1 00:03:35 OrangePI rc.local[414]: --> Sending: AT+CGATT=1
Jan 1 00:03:35 OrangePI rc.local[414]: AT+CGATT=1
Jan 1 00:03:40 OrangePI rc.local[414]: --> Sending: ATQ0
Jan 1 00:03:41 OrangePI rc.local[414]: ATQ0
Jan 1 00:03:41 OrangePI rc.local[414]: +CGATT:1
Jan 1 00:03:41 OrangePI rc.local[414]: OK
Jan 1 00:03:41 OrangePI rc.local[414]: --> Re-Sending: AT+CGATT=1
Jan 1 00:03:41 OrangePI rc.local[414]: AT+CGATT=1
Jan 1 00:03:41 OrangePI rc.local[414]: +CGATT:1
Jan 1 00:03:41 OrangePI rc.local[414]: OK
Jan 1 00:03:41 OrangePI rc.local[414]: --> Sending: AT+CGDCONT=1,"IP","internet.mts.ru","",0,0
Jan 1 00:03:41 OrangePI rc.local[414]: AT+CGDCONT=1,"IP","internet.mts.ru","",0,0
Jan 1 00:03:41 OrangePI rc.local[414]: OK
Jan 1 00:03:41 OrangePI rc.local[414]: --> Sending: AT+CGACT=1,1
Jan 1 00:03:41 OrangePI rc.local[414]: AT+CGACT=1,1
Jan 1 00:03:41 OrangePI kernel: [ 222.196166] md_tty_install result 0
Jan 1 00:03:41 OrangePI rc.local[414]: +CME ERROR:148
Jan 1 00:03:41 OrangePI rc.local[414]: --> Bad init string.
Jan 1 00:03:41 OrangePI rc.local[414]: --> Cannot get information for serial port.
Jan 1 00:03:41 OrangePI rc.local[414]: --> Initializing modem.
Jan 1 00:03:41 OrangePI rc.local[414]: --> Sending: ATE1
Jan 1 00:03:42 OrangePI rc.local[414]: ATE1
Jan 1 00:03:42 OrangePI rc.local[414]: OK
Jan 1 00:03:42 OrangePI rc.local[414]: --> Sending: AT+COPS=0
Jan 1 00:03:42 OrangePI rc.local[414]: AT+COPS=0
Jan 1 00:03:47 OrangePI rc.local[414]: --> Sending: ATQ0
Jan 1 00:03:47 OrangePI rc.local[414]: ATQ0
Jan 1 00:03:47 OrangePI rc.local[414]: +CME ERROR:50
Jan 1 00:03:47 OrangePI rc.local[414]: --> Re-Sending: AT+COPS=0
Jan 1 00:03:47 OrangePI rc.local[414]: AT+COPS=0
Jan 1 00:03:52 OrangePI rc.local[414]: --> Modem not responding.
Jan 1 00:03:52 OrangePI rc.local[414]: Oops. Restart wvdial
Jan 1 00:03:55 OrangePI rc.local[414]: --> WvDial: Internet dialer version 1.61
Jan 1 00:03:55 OrangePI rsyslogd-2007: action 'action 17' suspended, next retry is Sat Jan 1 00:04:25 2000 [try http://www.rsyslog.com/e/2007 ]
Jan 1 00:03:55 OrangePI kernel: [ 236.200561] md_tty_install result 0
Jan 1 00:03:55 OrangePI rc.local[414]: --> Cannot get information for serial port.
Jan 1 00:03:55 OrangePI rc.local[414]: --> Initializing modem.
Jan 1 00:03:55 OrangePI rc.local[414]: --> Sending: ATE1
Jan 1 00:03:56 OrangePI rc.local[414]: +CME ERROR:50
Jan 1 00:03:56 OrangePI rc.local[414]: --> Bad init string.
Jan 1 00:03:56 OrangePI rc.local[414]: --> Cannot get information for serial port.
Jan 1 00:03:56 OrangePI rc.local[414]: --> Initializing modem.
Jan 1 00:03:56 OrangePI rc.local[414]: --> Sending: ATE1
Jan 1 00:03:56 OrangePI rc.local[414]: ATE1
Jan 1 00:03:56 OrangePI rc.local[414]: OK
Jan 1 00:03:56 OrangePI rc.local[414]: --> Sending: AT+COPS=0
Jan 1 00:03:56 OrangePI rc.local[414]: AT+COPS=0
Jan 1 00:03:57 OrangePI rc.local[414]: OK
Jan 1 00:03:57 OrangePI rc.local[414]: --> Sending: AT+CFUN=1
Jan 1 00:03:57 OrangePI rc.local[414]: AT+CFUN=1
Jan 1 00:03:57 OrangePI rc.local[414]: OK
Jan 1 00:03:57 OrangePI rc.local[414]: --> Sending: AT+CGATT=1
Jan 1 00:03:57 OrangePI rc.local[414]: AT+CGATT=1
Jan 1 00:03:57 OrangePI rc.local[414]: +CGATT:1
Jan 1 00:03:57 OrangePI rc.local[414]: OK
Jan 1 00:03:57 OrangePI rc.local[414]: --> Sending: AT+CGDCONT=1,"IP","internet.mts.ru","",0,0
Jan 1 00:03:57 OrangePI rc.local[414]: AT+CGDCONT=1,"IP","internet.mts.ru","",0,0
Jan 1 00:03:57 OrangePI rc.local[414]: OK
Jan 1 00:03:57 OrangePI rc.local[414]: --> Sending: AT+CGACT=1,1
Jan 1 00:03:57 OrangePI rc.local[414]: AT+CGACT=1,1
Jan 1 00:03:58 OrangePI rc.local[414]: OK
Jan 1 00:03:58 OrangePI rc.local[414]: --> Modem initialized.
Jan 1 00:03:58 OrangePI rc.local[414]: --> Sending: ATDT*99***1#
Jan 1 00:03:58 OrangePI rc.local[414]: --> Waiting for carrier.
Jan 1 00:03:58 OrangePI rc.local[414]: ATDT*99***1#
Jan 1 00:03:58 OrangePI rc.local[414]: CONNECT
Jan 1 00:03:58 OrangePI rc.local[414]: --> Carrier detected. Starting PPP immediately.
Jan 1 00:03:58 OrangePI rc.local[414]: --> Starting pppd at Sat Jan 1 03:03:58 2000
Jan 1 00:03:58 OrangePI rc.local[414]: --> Pid of pppd: 475
Jan 1 00:03:58 OrangePI kernel: [ 239.296325] PPP generic driver version 2.4.2
Jan 1 00:03:58 OrangePI pppd[475]: pppd 2.4.6 started by root, uid 0
Jan 1 00:03:58 OrangePI pppd[475]: Using interface ppp0
Jan 1 00:03:58 OrangePI pppd[475]: Connect: ppp0 <--> /dev/modem0
Jan 1 00:03:58 OrangePI rc.local[414]: --> Using interface ppp0
Jan 1 00:03:58 OrangePI rc.local[414]: --> pppd: ????8??[01] ~?[01][01]
Jan 1 00:03:58 OrangePI rc.local[414]: --> pppd: ????8??[01] ~?[01][01]
Jan 1 00:03:58 OrangePI NetworkManager[413]: (ppp0): new Generic device (driver: 'unknown' ifindex: 5)
Jan 1 00:03:58 OrangePI NetworkManager[413]: (ppp0): exported as /org/freedesktop/NetworkManager/Devices/4
Jan 1 00:03:58 OrangePI NetworkManager[413]: devices added (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
Jan 1 00:03:58 OrangePI NetworkManager[413]: device added (path: /sys/devices/virtual/net/ppp0, iface: ppp0): no ifupdown configuration found.
Jan 1 00:03:58 OrangePI pppd[475]: kernel does not support PPP filtering
Jan 1 00:03:58 OrangePI rc.local[414]: --> pppd: ????8??[01] ~?[01][01]
Jan 1 00:03:59 OrangePI pppd[475]: local IP address 10.30.121.77
Jan 1 00:03:59 OrangePI pppd[475]: remote IP address 192.200.1.21
Jan 1 00:03:59 OrangePI pppd[475]: primary DNS address 213.87.1.1
Jan 1 00:03:59 OrangePI NetworkManager[413]: (ppp0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
Jan 1 00:03:59 OrangePI NetworkManager[413]: (ppp0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) starting connection 'ppp0'
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) Stage 1 of 5 (Device Prepare) scheduled...
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) Stage 1 of 5 (Device Prepare) started...
Jan 1 00:03:59 OrangePI NetworkManager[413]: (ppp0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) Stage 2 of 5 (Device Configure) scheduled...
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) Stage 1 of 5 (Device Prepare) complete.
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) Stage 2 of 5 (Device Configure) starting...
Jan 1 00:03:59 OrangePI NetworkManager[413]: (ppp0): device state change: prepare -> config (reason 'none') [40 50 0]
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) Stage 2 of 5 (Device Configure) successful.
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) Stage 3 of 5 (IP Configure Start) scheduled.
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) Stage 2 of 5 (Device Configure) complete.
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) Stage 3 of 5 (IP Configure Start) started...
Jan 1 00:03:59 OrangePI NetworkManager[413]: (ppp0): device state change: config -> ip-config (reason 'none') [50 70 0]
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) Stage 3 of 5 (IP Configure Start) complete.
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) Stage 5 of 5 (IPv4 Commit) started...
Jan 1 00:03:59 OrangePI NetworkManager[413]: Could not send ARP for local address 10.30.121.77: Failed to execute child process "/usr/bin/arping" (No such file $
Jan 1 00:03:59 OrangePI NetworkManager[413]: (ppp0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) Stage 5 of 5 (IPv4 Commit) complete.
Jan 1 00:03:59 OrangePI NetworkManager[413]: (ppp0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
Jan 1 00:03:59 OrangePI NetworkManager[413]: (ppp0): device state change: secondaries -> activated (reason 'none') [90 100 0]
Jan 1 00:03:59 OrangePI NetworkManager[413]: NetworkManager state is now CONNECTED_LOCAL
Jan 1 00:03:59 OrangePI rc.local[414]: --> local IP address 10.30.121.77
Jan 1 00:03:59 OrangePI rc.local[414]: --> pppd: ????8??[01] ~?[01][01]
Jan 1 00:03:59 OrangePI rc.local[414]: --> remote IP address 192.200.1.21
Jan 1 00:03:59 OrangePI rc.local[414]: --> pppd: ????8??[01] ~?[01][01]
Jan 1 00:03:59 OrangePI rc.local[414]: --> primary DNS address 213.87.1.1
Jan 1 00:03:59 OrangePI rc.local[414]: --> pppd: ????8??[01] ~?[01][01]
Jan 1 00:03:59 OrangePI NetworkManager[413]: Activation (ppp0) successful, device activated.
Serge78rus
24.02.2019 20:21Ну, это лог тоже не совсем удачного подключения (точнее, удачного, но не с первого раза): сначала идет все нормально, но при попытке в первый раз активировать GPRS контекст:
Jan 1 00:03:41 OrangePI rc.local[414]: AT+CGACT=1,1
сразу, без какой-либо задержки, выскакивает ошибка (обычно эта операция длинная, типичная задержка — несколько секунд, но может доходить и до десятков) Дальше программа без какой-либо задержки пытается провести повторную инициализацию, при этом модем может еще находиться хрен знает в каком состоянии после предыдущей ошибки, в итоге добивается отсутствия реакции модема вообще:
Jan 1 00:03:52 OrangePI rc.local[414]: --> Modem not responding.
После этого программа перезапускается, и только со второго раза все проходит успешно.
Исходя из всего этого сложно даже сказать кто виноват — модем или программа.
ПС: кстати, используемые AT команды — стандартные, каких-либо расширений, специфических для данного модема я не увидел.
Armavir
24.02.2019 02:24не в орандж пи дело. Такое со всеми одноплатниками. Мы закупили несколько разных производителей начиная от nano pi и заканчивая asus. Везде проблемы с поддержкой, с драйверами, ничего не работает из коробки
einhander
25.02.2019 09:03Наверное, прежде чем покупать одноплатник стоило почитать про его поддержку софтом. Например, прежде чем купить orange pi zero, я выяснил, что в нем хоть и есть wifi но стабильно работающих драйверов для него нет, потому на wifi я не рассчитывал и использовал ethernet. В качестве источника звука для старого музыкального центра orange pi zero работает отлично. У него ещё есть ик-приемник, но я поленился его настраивать на орегинальый пульт от музыкального центра.
kovserg
Вот Sinclar при всей его простоте был компьютером. А это не одноплатные компьютеры — это наборы для
BDSMгребли.