четверг, 13 июля 2017 г.

Обновление Xiaomi Mi4c до LineageOS 14.1

Решил поделиться впечатлениями от обновления своего Xiaomi Mi4c с CyanogenMod 13.1 до LineageOS 14.1. Основная причина обновления - попытка решить проблему с внезапным отключением телефона при заряде батареи 20-30%.

Для обновления использовал вариант прошивки LineageOS от Team Superluminal, firmware от miui 8.2.3.0 и заодно обновил TWRP до 3.1.1. Уже прошло две недели с момента обновления и можно подвести итог:
  • Решилась главная проблема с отключением телефона при заряде батареи ниже 30%. Как и положено на 15% я получаю всплывающее уведомление, которое повторяется на 5% и потом телефон разряжается до нуля и выключается.
  • Работает активация/деактивация второй симки. В CyanogenMod 13.1 не было возможности деактивировать вторую симку и она постоянно оставалась активной. В качестве второй симки у меня установлена туристическая симка от GoodLine и не хочется "случайно" звонить через нее.
Теперь касательно плюшек новой версии Android
  • Я получил последнюю стабильную версию Android 7.1.2 (security patch level: June 5, 2017).
  • Теперь при звонке телефон автоматически включает режим "Do not disturb" и новые смски или уведомления от aNag более не жужжат в ухо во время разговора.
P.S. Заметил что если включить русский язык в настройках интерфейса, то Mi Fit не показывает контакт при входящем звонке или SMS. В этом случае в Mi Fit просто нет нужного пункта. Все приходит в норму, если выбрать английский язык.

Второй момент - если смотреть ролики на Youtube и выбран английский язык в настройках интерфейса, то почти нет рекламы. Ее становится сильно больше, если сменить язык интерфейса на русский.

вторник, 11 июля 2017 г.

Прошляпил обновление signing key для моего репозитария

В пятницу пришло письмо от человека, который указал на истекший срок действия ключа, которым подписывается мой репозитарий.

В APT ошибка выглядит так:

Сущ:10 http://www.tataranovich.com/debian jessie Release
Ошк:13 http://www.tataranovich.com/debian jessie Release.gpg
  Следующие подписи неверные: EXPKEYSIG 836CC41976FB442E Tataranovich.com APT Repository 
Чтение списков пакетов… Готово
W: Произошла ошибка при проверке подписи. Репозиторий не обновлён и будут использованы предыдущие индексные файлы. Ошибка GPG: http://www.tataranovich.com/debian jessie Release: Следующие подписи неверные: EXPKEYSIG 836CC41976FB442E Tataranovich.com APT Repository 
W: Не удалось получить http://www.tataranovich.com/debian/dists/jessie/Release.gpg  Следующие подписи неверные: EXPKEYSIG 836CC41976FB442E Tataranovich.com APT Repository 

Я уже обновил ключ, но для исправления требуется несколько ручных действий:

sudo apt-key adv --keyserver pool.sks-keyservers.net --recv-keys 0x836CC41976FB442E
sudo apt-get update

Кроме этого можно установить пакет tataranovich-keyring отсюда. В этом случае больше шансов, что ситуация не повторится.

В процессе обновления пакета заметил, что теперь ключ нужно класть в /etc/apt/trusted.gpg.d, а не добавлять через apt-key в postinst.

среда, 28 июня 2017 г.

Перестал подключаться PPTP через NAT

Имеется домашний сервер, который маршрутизатор домашней сети и еще много чего, работающий на Debian Jessie. После обновления ядра со штатного 3.16.43-2+deb8u1 до 4.9.30-2~bpo8+1 из backports перестало работать подключение к корпоративной сети через PPTP. Если перезагрузить сервер на старое ядро, то PPTP работает.

Нужные модули загружены:

$ grep pptp /etc/modules
nf_nat_pptp
nf_conntrack_pptp

$ lsmod | awk '/pptp/ {print $1}'
nf_nat_pptp
nf_nat_proto_gre
nf_conntrack_pptp
nf_conntrack_proto_gre
nf_nat
nf_conntrack

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

Добавить дополнительное правило в netfilter:

$ sudo iptables -t raw -A PREROUTING -p tcp -m tcp --dport 1723 -j CT --helper pptp

или включить conntrack helper:

$ sudo sysctl -w net.netfilter.nf_conntrack_helper=1

Больше информации по теме можно почерпнуть тут.

пятница, 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.

четверг, 2 февраля 2017 г.

Настройка suspend to hibernate в Debian Jessie

Ранее я уже писал про экономию заряда батареи ноутбука при использовании suspend to ram (S3). Такой режим называется suspend to hibernate и заключается в автоматическом переходе из S3 (suspend to ram) в S4 (suspend to disk) если пользователь не продолжит работу в течении заданного периода времени.

Прошлое решение базировалось на pm-utils, но с переходом jessie на systemd это перестало работать (#745848). До недавнего времени я пользовался jessie + sysv init и эта проблема меня не касалась, но последнее время все чаще сталкиваюсь с systemd и решил дать ему шанс на домашней системе. Наибольшей проблемой после перехода на systemd стал отвалившийся suspend-to-hibernate.

В wiki archlinux есть вариант для systemd. Пришлось немного доработать их вариант, чтобы он начал работать в debian jessie.

[Unit]
Description=Delayed hibernation trigger
Documentation=https://wiki.archlinux.org/index.php/Power_management
Before=suspend.target
Conflicts=hibernate.target hybrid-suspend.target
StopWhenUnneeded=true

[Service]
Type=oneshot
RemainAfterExit=yes
Environment="WAKEALARM=/sys/class/rtc/rtc0/wakealarm"
Environment="SLEEPLENGTH=+2hours"
ExecStart=-/bin/sh -c 'echo -n "alarm set for "; date +%%s -d$SLEEPLENGTH | tee $WAKEALARM'
ExecStop=-/bin/sh -c '\
  alarm=$(cat $WAKEALARM); \
  now=$(date +%%s); \
  if [ -z "$alarm" ] || [ "$now" -ge "$alarm" ]; then \
     echo "hibernate triggered"; \
     systemctl hibernate; \
  else \
     echo "normal wakeup"; \
  fi; \
  echo 0 > $WAKEALARM; \
'

[Install]
WantedBy=sleep.target

Этот сервис нужно сохранить в файле /etc/systemd/system/suspend-to-hibernate.service и добавить в suspend.target зависимость на suspend-to-hibernate.service. В противном случае suspend.target не будет дожидаться выполнения suspend-to-hibernate.service.

sudo cp /lib/systemd/system/suspend.target /etc/systemd/system/suspend.target
echo Requires=suspend-to-hibernate.service | sudo tee -a /etc/systemd/system/suspend.target
sudo systemctl enable suspend-to-hibernate.service
sudo systemctl daemon-reload

В будущем планирую интегрировать поддержку systemd в мой laptop-utils и собрать для него пакет.