пятница, 16 июня 2017 г.

Xiaomi Mi4c внезапно отключается при заряде батареи 20-30%

Не могу вспомнить когда это случилось первый раз, но похоже мой Xiaomi Mi4c взял привычку отключаться при остаточном заряде 20-30%. В произвольный момент, когда батарея показывает ниже 40% телефон вдруг решает что заряд около нуля и штатно выключается.


На графике батареи видно что с примерно 25% батарея мгновенно "разрядилась" до нуля, а после повторного включения телефона отработала еще несколько часов. Причем повторилась старая проблема с продолжающимся разрядом батареи при подключенном зарядном. Калибровка батареи не помогла - я пробовал полностью разрядить батарею, потом зарядить до 100%, калибровать, разрядить до нуля и снова зарядить до 100%.

В интернете встречаются упоминания, что такое поведение не редкость даже у новых телефонов: произвольное отключение телефона происходит при заряде батареи 20-60%. Похоже это связано с проблемами в прошивке (сейчас у меня установлен CyanogenMod 13.1 от Team Superluminal), т.к. у меня эту проблема появилась относительно недавно и скорее всего связана с последним обновлением прошивки в начале этого года.

Зайдя на форум team superluminal узнал, что теперь они предлагают LineageOS 14.1 для Mi4c - нужно будет попробовать эту прошивку при случае.

четверг, 1 июня 2017 г.

Разрядился телефон будучи подключенный к зарядному устройству

Не первый раз замечаю что мой Xiaomi Mi4c, подключенный перед сном к зарядному устройству (остаточный заряд 20-30%), к утру разряжается почти до нуля или совсем отключается.

Сегодня утром аккумулятор показывал 2% заряд и я сделал скриншот


Перед подключением зарядного было больше 20% заряда, но после отключения экрана телефон не уснул. Зарядное устройство и кабель - родные.

Похоже из-за какой-то проблемы в прошике телефон клинит и он начинает расходовать больше, чем дает зарядное. Либо в добавок из-за нагрева ограничивается заряд и поэтому его не хватает, чтобы скомпенсировать повышенный расход энергии.

вторник, 30 мая 2017 г.

Спустя год заметил что отвалился IPv6 на сервере

В процессе прикручивания сертификата Let's Encrypt к своему сайту обнаружил что он более недоступен по IPv6 извне. Причем судя по статистике траффика в панели управления сервером это произошло еще в июне 2016. Сервер имеет IPv4/IPv6 стек и последний был настроен по принципу "пусть будет". А сейчас при валидации домена Let's Encrypt не может соединиться на IPv6 адрес сайта и проверка не проходит.

Доступность сервера по IPv4 проверяется в nagios из дома, а вот проверку доступности IPv6 пришлось добавить в виде костыля (нет у меня другого сервера с IPv6):

command['check_ipv6']=/usr/lib/nagios/plugins/check_http -6 -H google.com

Похоже что-то изменилось в маршрутизации у хостера, т.к. ipv6 адрес шлюза пингуется, а вот дальше него - тишина.

$ ip -6 a
1: lo: <loopback> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <broadcast> mtu 1500 qlen 1000
    inet6 2a01:4f8:d13:2742::2/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::21c:14ff:fe01:1dba/64 scope link 
       valid_lft forever preferred_lft forever

$ ip -6 r
2a01:4f8:d13:2742::/64 dev eth0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via 2a01:4f8:d13:2742::1 dev eth0  metric 1024

$ ip -6 neigh
fe80::3285:a9ff:fea4:1ff7 dev eth0 lladdr 30:85:a9:a4:1f:f7 router STALE
2a01:4f8:d13:2742::1 dev eth0 lladdr 30:85:a9:a4:1f:f7 router STALE

$ ping6 -c 5 2a01:4f8:d13:2742::1
PING 2a01:4f8:d13:2742::1(2a01:4f8:d13:2742::1) 56 data bytes
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=1 ttl=64 time=0.281 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=2 ttl=64 time=0.284 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=3 ttl=64 time=0.250 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=4 ttl=64 time=0.223 ms
64 bytes from 2a01:4f8:d13:2742::1: icmp_seq=5 ttl=64 time=0.148 ms

--- 2a01:4f8:d13:2742::1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.148/0.237/0.284/0.050 ms

$ ping6 -c5 ipv6.google.com
PING ipv6.google.com(waw02s06-in-x0e.1e100.net) 56 data bytes

--- ipv6.google.com ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4033ms

Посмотрю что завтра ответит тех. поддержка Hetzner.

UPDATE 31/05/2017

Ответ из техподдержки:
Thanks for trying a reboot first. We've now rechecked the routing of your IPv6-net and we were able to find an issue, which we fixed directly and your server is now back online using the mentioned IPv6.
IPv6 снова работает и мне удалось установить сертификат Let's Encrypt для моего сайта.

Обновление BIOS на Dell Latitude E6430

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

После публикации информации об уязвимости в Intel AMT CVE-2017-5689 (INTEL-SA-00075) отправился на сайт Dell проверить апдейты. На тот момент обновление прошивки для моего Latitude E6430 еще не было выпущено, но в планах значилось начало июня.

На днях проверил обновления еще раз - уже доступна прошивка A21 с исправлением уязвимости. Последний раз обновлял BIOS в ноутбуке сразу после покупки и потому там установлена старая версия A16.

Для обновления скачиваю все доступные прошивки от A16 до A21, которые предназначены для Latitude E6430 (A16, A17, A18, A20, A21) и создаю загрузочный образ FreeDOS, содержащий в себе скачанные прошивки (загрузочный образ можно скачать тут).

Убедидесь что ваша флешка видна в системе как /dev/sdb. В противном случае рискуете затереть системный диск!
 
Несколько команд для скачивания образа и заливки на флешку:

$ wget http://www.tataranovich.com/public/dell/{e6430_bios_update.img.gz,MD5SUMS}
$ md5sum -c MD5SUMS
$ gunzip e6430_bios_update.img.gz
$ sudo dd if=e6430_bios_update.img of=/dev/sdb

Не продолжайте обновление, если не совпадает контрольная сумма для образа диска!

Далее можно продолжать обновление по аналогии.

Посколько в installation guide для прошивки нет ничего про запрет сквозного обновления, то для ноутбука жены (у нее тоже Latitude E6430) выбрал вариант обновления с версии A16 до A21. Весь процесс обновления занял минут 5 и завершился без ошибок.

А вот с моим ноутбуком такой финт не прошел. На этапе обновления "Sending Intel(R) Management Engine Firmware Update" произошла ошибка "ME FW Update Failed: Internal error: FWU_Buffer". После этого обновление продолжилось и завершилось без ошибок.

Я пробовал гуглить ошибку, но нашел только что ее исправили в обновлении A17. Накатываю прошивку версии A17 - обновилось без проблем. Потом настает очередь A18, A20 и снова A21. В этот раз обновление "Management Engine Firmware" прошло без ошибок.

До обновления версия Intel Management Engine Firmware была 8.1.40.1416, а после установки прошивки A21 стала 8.1.71.3608.

Кстати еще нашел утилиту mei-amt-check для проверки версии AMT:

$ git clone https://github.com/mjg59/mei-amt-check.git
$ cd mei-amt-check
$ make
$ sudo ./mei-amt-check
Intel AMT is present
AMT is unprovisioned

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

понедельник, 22 мая 2017 г.

Произвольная скорость порта с Prolific PL2303 в Linux

Тут описаны мои попытки разобраться в настройку нестандартной скорости порта 74880 бит/с используя usb-to-serial конвертор prolific pl2303. Похоже в linux модуль ядра pl2303 реализует только стандартные скорости для передачи данных: 9600, 14400, 28800 и т.д. Но скорость 74880 не входит в этот список и драйвер хотя и принимает настройку через anybaud, но ничего при этом не изменяется.

Я нашел в сети два патча для pl2303, которые решают проблему задания произвольной скорости порта в linux. Первый патч меняет формулу расчета делителя частоты, а второй патч использует эту формулу для любой скорости, не входящей в список поддерживаемых драйвером. Соответственно для стандартных скоростей ничего поменяться не должно.

Чтобы не возиться с установкой модуля в linux я подготовил репозитарий с версией для dkms

sudo apt-get update
sudo apt-get install linux-headers-$(uname -r) dkms
wget -O pl2303-dkms.tar.gz https://github.com/tataranovich/pl2303/archive/master.tar.gz
tar -xzf pl2303-dkms.tar.gz
cd pl2303-master
sudo make install

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

cd pl2303-master
./anybaud /dev/ttyUSB0 74880
Changed successfully.

воскресенье, 21 мая 2017 г.

Скорость порта 74880 бит/с в Prolific PL2303

Собираю датчик качества воздуха (температура, относительная влажность и содержание углекислоты) на базе esp8266, который будет интегрирован с системой мониторинга. Сейчас у меня esp8266 есть только в виде модуля ESP-01 (выводы модуля vcc, gnd, ch_en, reset, gpio0, gpio2, rx, tx), но уже заказал модуль в варианте ESP-12S.
ESP8266 ESP-01

ESP8266 ESP-12S
На ESP-01 выведены только два gpio, но и те доступны с ограничениями. Оба этих вывода участвуют в выборе режима запуска модуля

Bootloader Modes
Modegpio0gpio2gpio15
UART Download Mode (Programming)010
Flash Startup (Normal)110
SD-Card Boot001

Соответственно gpio0/gpio2 желательно не использовать на модуле ESP-01, но поскольку особого выбора не было, то для подключения датчика температуры и влажности DHT22 (AM2302) я использовал gpio2. Чтобы подключить датчик углекислоты mh-z19 мне нужно использовать uart (выводы rx/tx) и после этого для программирования модуля его придется извлекать. Перед подключением датчика проверяю что выдается в uart помимо отладочных сообщений прошивки.

Подключаю конвертер на базе Prolific PL2303, который я использую для связи с компьютеров и настраиваю порт /dev/ttyUSB0 на скорость 115200 бод:

$ stty -F /dev/ttyUSB0 115200 raw
$ cat /dev/ttyUSB0

После этого жму reset и вижу "мусор" перед первой строчкой, которую выдает прошивка.

ESP8266 UART 115200 bps

Скорее всего это лог встроенного загрузчика, но который передается на другой скорости (не 115200). Попробовал несколько вариантов 9600, 38400, 57600, но разборчивого текста так и не получилось.

После гугления я выяснил что лог загрузчика передается на нестандартной скорости 74880 бод и потому я вижу "мусор" в терминале. Пробую переключить порт на 74880:

$ stty -F /dev/ttyUSB0 74880
stty: invalid argument ‘74880’
Try 'stty --help' for more information.

Облом, не дает задать произвольную скорость, но при этом в linux уже давно есть возможность задавать произвольную скорость для последовательных портов. Нашел простую утилитку anybaud.c, которая позволяет выставить произвольную скорость. Компилирую ее и пробую выставить настройку:

$ wget -O anybaud.c https://gist.githubusercontent.com/peterhurley/fbace59b55d87306a5b8/raw/5017e43f9fde34e9ac37ab2c3fd35b5ca3c3e73f/anybaud.c
$ gcc -static -o anybaud anybaud.c
$ ./anybaud /dev/ttyUSB0 74880
/dev/ttyUSB0 speed changed to 74880 baud

Хотя команда и прошла без ошибок, но лучше не стало

ESP8266 UART 74880 bps
Сообщения прошивки превратились в мусор, но сообщения загрузчика текстом не стали.

Загрузил Windows 7 в VirtualBox, пробросил pl2303 в виртуальную машину и попробовал подключиться к порту через Putty

ESP8266 UART 74880 bps в Putty

Сначала подумал, что это проблемы из-за эмуляции USB в VirtualBox, но переключение скорости порта в Putty на 115200 опровергает эту теорию

ESP8266 UART 115200 bps в Putty
Гугление приносит результат - для поддержки скорости 74880 бод нужно добавить настройку в реестр:

REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Ser2pl]
"ExtBaudrate"="74880,2147485264"

После импорта в реестр перезагрузил виртуальную машину и снова попробовал подключиться к порту к Putty. На этот раз все сработало и появились сообшения загрузчика

ESP8266 UART 74880 bps в Putty после патча реестра
Забегая вперед скажу, что я уже нашел способ как пропатчить pl2303 в linux, но напишу об этом в следующий раз.

Обновлено 22/05/2017: описал способ пропатчить модуль ядра pl2303 в linux для поддержки произвольной скорости передачи данных.

среда, 17 мая 2017 г.

Изменения в моем репозитории: Ubuntu Zesty

Добавил поддержку Ubuntu Zesty 17.04 в свой репозиторий и удалил Ubuntu Precise по причине окончания поддержки последнего.

Пакеты для midnight commander (stable и nightly) уже добавлены для Ubuntu Zesty.

Сейчас список поддерживаемых дистрибутивов и архитектур выглядит так:

Debian: wheezy (i386, amd64, armel, armhf), jessie (i386, amd64, armel, armhf, arm64), stretch (i386, amd64), sid (i386, amd64)
Ubuntu: trusty (i386, amd64, armhf, arm64), xenial (i386, amd64), yakkety (i386, amd64), zesty (i386, amd64)

С покупкой raspberry pi 3 планирую добавить полноценный хост для сборки пакетов под архитектуры armel, armhf и arm64. Сейчас пакеты под эти архитектуры собираются в qemu и скорость сборки достаточно медленная.

Начал тестировать jenkins-debian-glue и думать над реорганизацией структуры репозитория. В теперешнем виде пакеты для debian и ubuntu находятся в одной иерархии и к примеру добавление raspbian дает конфликт по именам относительно debian.