Штатная прошивка у SonyEricsson X8 застыла на версии 2.1, что не очень приятно.

При установки прошивки от CyanogenMod версия обновляется до 2.3.7 и добавляются следующие возможности (из коробки):

1. Установка приложений в карту памяти;
2. Возможность расшарить интернет с мобилы через WiFi;
3. Приложение работают заметно быстрее, хотя Angry Birds все еще тормозит;
4. Более вменяемый лаунчер;
5. Лента SMS в виде чата;
6. Root-доступ.

Из минусов:

1. При перепрошивке теряются все настройки телефона (купленные через маркет приложения повторно покупать не придется);
2. Возможно, что на альтернативной прошивке будут какие-либо проблемы;
3. Возможна потеря гарантии.

Отмазка

То, что описанный в данном тексте алгоритм сработал у меня, не значит, что он сработает у всех.

Теоретически, хоть и маловероятно, можно превратить аппарат в кирпич. Все что вы делаете – вы делаете на свой страх и риск.

Нам понадобится:

1. Телефон SonyEricsson X8 и карта памяти.
   Без телефона нечего прошивать, а карта памяти нужна для копирования туда прошивки.
   Карта должна быть отформатированна файловой системой FAT32 (обычно оно уже так и есть) и на ней должно быть около 100Мб свободного пространства для прошивки.
2. SonyEricsson Update Service
   http://www.sonyericsson.com/cws/support/mobilephones/downloads/subject/updateservice/xperiax1?cc=gb&lc=en
   Эта утилита позволяет вернуть заводскую прошивку.
3. FlashTool
   http://androxyde.github.com/Flashtool/
   Утилита для перепрошивки. Сильно упрощает процедуру установки прошивки, избавляя от рутования и ручной устнановки загрузчика.
4. Модифицированное ядро (E15_nAa)
   http://code.google.com/p/minicm/downloads/list
   Ядро и загрузчик для перепрошивки при помощи Flashtool. Из него нам нужен только загрузчик.
5. Прошивка
   http://download.cyanogenmod.com/?type=stable&device=shakira
   Собственно прошивка.
6. Софт от Google
   http://wiki.cyanogenmod.com/wiki/Latest_Version/Google_Apps
   Это различный необходимый для жизни софт от Google. В него, например, входит:
   • Маркет;
   • Синхронизация контактов с GMail;
   • Голосовой поиск от Google.

Общая последовательность действий:

Важно: все настройки телефона будут потеряны.

1. Для начала надо привести телефон в рабочее состояние (сброситься до заводской прошивки).
   Тут все просто:
   • Запускаем SonyEricsson Update Service;
   • Выбираем там телефон;
   • Выключаем телефон выниманием батареи;
   • Возвращаем батарею на место. Телефон не включаем;
   • Зажимаем на телефоне кнопку назад;
   • Вставляем USB-шнур, кнопку назад при этом не отпускаем;
   • Запускаем перепрошивку и ждем.
2. Записываем данные на карту памяти.
   В корень карты памяти надо сбросить прошивку и архив с софтом от Google. В моем случае это файлы:
   • update-cm-7.1.0-X8-signed.zip
   • gapps-gb-20110828-signed.zip
3. Копируем в директорию C:\Flashtool\firmwares\ ядро и прошивку. У прошивки при этом надо сменить расширение на ftf.
   В моем случае получились файлы:
   • E15_nAa-08_2.6.29.6-nAa-08.ftf
   • update-cm-7.1.0-X8-signed.zip
4. Устанавливаем загрузчик:
   • Выключаем телефон при помощи кнопки выключения.
   • Запускаем FlashTool и жмем на молнию.
   • Выбираем режим FlashMode.
   • Выбираем прошивку с именем E15 и устанавливаем галочку «Exclude Kernel» (должен остаться в списке только файл loader.sin)
   • Жмем «ОК».
   • Зажимаем кнопку «назад» на выключенном телефоне и подключаем его по USB.
   • Ждем пока появится сообщение «Now unplug the device and power it on».
   • Отключаем телефон от USB.
   • Включаем телефон. Он должен корректно загрузиться.
     Если во время загрузки нажимать кнопку «назад», то должно появиться меню восстановления.
5. Устанавливаем ядро:
   • Выключаем телефон при помощи кнопки выключения.
   • Запускаем FlashTool и жмем на молнию.
   • Выбираем режим FlashMode.
   • Выбираем прошивку без имени и устанавливаем галочки «Exclude System», «Exclude Baseband» (должен остаться в списке только файл kernel.sin)
   • Жмем «ОК».
   • Зажимаем кнопку «назад» на выключенном телефоне и подключаем его по USB.
   • Ждем пока появится сообщение «Now unplug the device and power it on».
   • Отключаем телефон от USB.
   • Включаем телефон. Он не должен загрузиться. Вместо логотипа SonyEricsson должна появиться буква X.
6. Устанавливаем прошивку:
   • Выключаем телефон выниманием батареи;
   • Включаем телефон и истерично нажимаем кнопку «назад», пока не попадем в режим восстановления.
   • Чистим кэш и настройки (без этого прошивка может не загрузиться):
     • wipe data/factory reset
     • wipe cache partition
   • Устанавливаем прошивку:
     • install zip from sdcard > choose zip from sdcard > update-cm-7.1.0-X8-signed.zip
   • Устанавливаем софт от Google:
     • install zip from sdcard > choose zip from sdcard > gapps-gb-20110828-signed.zip
   • Перезагружаем телефон:
     • reboot system now

     Телефон должен корректно загрузиться.

7. Радуемся.

Решение проблем

Проблема с нестабильной работой сети (3G+WiFi)

Обнаружилась проблема с отваливающейся передачей данных. Пока не решена, но рецепт, возможно, есть здесь: http://forum.xda-developers.com/showpost.php?p=19187110&postcount=2407

Выполнить это можно командой:

echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

Аналогичная конструкций для выключения компьютера:

echo 1 > /proc/sys/kernel/sysrq
echo o > /proc/sysrq-trigger

Первое, что пришло в голову – сконвертировать существующий раздел из ext3 в btrfs. Для конвертации выполнил штатную утилиту:

btrfs-convert /dev/mapper/LVM-DISK1

По прошествии некоторого времени конвертация была успешно завершена, но результат меня сильно озадачил: при выполнении команды df разница «размер – (использовано + доступно)» была более 100Гб при размере раздела 400Гб. То есть, было «потеряно» более 25% дискового пространства. Я нашел две причины такого поведения…

Причина 1. Резервная копия для восстановления ext3

Причина оказалась достаточно проста: утилита btrfs-convert при изменении файловой системы, сохраняет метаданные ext3 для возможности отката. То есть, после конвертации в файловой системе уже будет один снимок – данные на момент конвертации.

В этом легко убедиться, если выполнить команду вида:

btrfs subvolume list /mnt/disk1/

Для удаления снимка можно воспользоваться командой:

btrfs subvolume delete /mnt/disk1/ext2_saved

После этого кол-во свободного места неторопливо поползло вверх.

Причина 2. Не оптимальная структура файловой системы

После выполнения команды:

btrfs fi df /mnt/disk1/

Я обратил внимание на безумный размер метаданных – их меньше чем данных всего раза в четыре.

После перестроения дерева командой:

btrfs fi balance /mnt/disk1/

Кол-во метаданных уменьшилось до 1Гб, а кол-во «потерянного» места – до 4Гб.

Если его установить а потом обновить до актуальной версии, то после перезагрузки он перестанет запускать демоны. В том числе, перестанет работать SSH.

После изучения страницы http://wiki.openvz.org/Gentoo_template_creation удалось сформулировать принцип приведения контейнера в рабочее состояние.

Восстановление запуска SSH

Для начала, надо восстановить запуск демона ssh. В противном случае, сделать что-либо с виртуальной машиной затруднительно.

Если у вас есть возможность выполнить какой-либо скрипт внутри контейнера (например, через vzctl enter), то данный шаг можно пропустить.

Для этого нужно каким-либо образом закоментировать в файле /sbin/rc строку (у меня это была строка 249), добавив в начало символ решетки (#):

# try mount -n ${mntcmd:--t sysfs sysfs /sys -o noexec,nosuid,nodev}

После этого нужно перезапустить контейнер.

Исправление шероховатостей контейнера

Исправить внутренние проблемы контейнера (убрать запуск лишних скриптов и т.п.) можно скриптом:

# Make /etc/mtab a symlink to /proc/mounts
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

# Replace /etc/fstab
echo "proc /proc proc defaults 0 0" > /etc/fstab

# Edit /etc/inittab and put a hash mark (#) at the beginning of the lines containing:
# c?:1235:respawn:/sbin/agetty 38400 tty? linux
F=/etc/inittab
sed -e 's/^c[0-9].*tty[0-9]/#\0/g' $F > $F~
chmod --reference=$F $F~ && mv -f $F~ $F

# Disable unneeded init scripts
rm /etc/runlevels/boot/checkroot
rm /etc/runlevels/boot/consolefont

# Edit /sbin/rc and put a hash mark (#) at the beginning of line 224:
# try mount -n ${mntcmd:--t sysfs sysfs /sys -o noexec,nosuid,nodev}
F=/sbin/rc
sed -e 's/^[^#]*try mount.*sysfs/#\0/g' $F > $F~
chmod --reference=$F $F~ && mv -f $F~ $F

# To ensure that this change isn't automatically overwritten on update, add the
# following to /etc/make.conf:
# CONFIG_PROTECT="/sbin/rc"
echo 'CONFIG_PROTECT="/sbin/rc"' >> /etc/make.conf

# Set up udev
mknod /lib/udev/devices/ttyp0 c 3 0
mknod /lib/udev/devices/ptyp0 c 2 0
mknod /lib/udev/devices/ptmx c 5 2

F=/etc/conf.d/rc
sed -e 's/.*RC_DEVICES=".*"/RC_DEVICES="udev"/g' $F | \
sed -e 's/.*RC_DEVICE_TARBALL=".*"/RC_DEVICE_TARBALL="no"/g' > $F~
chmod --reference=$F $F~ && mv -f $F~ $F

Надеюсь, эти изыскания помогут и не только мне

Для обеспечения прозрачной маршрутизации я пробросил IP-over-IP тунель, но у этого решения остался один существенный недостаток – DNS оставался в каждой подсети свой.

От идеи поднять общий DNS-сервер я сразу отказался, так как каждая сеть должна работать независимо от работоспособности другой сети.

Принцип решения данной проблемы:

1. На DD-WRT установлен DNS-сервер Dnsmasq. Он не только работает, как кэширующий DNS-сервер, но и возвращает A и PTR для записей, которые перечислены в файле /etc/hosts на точке доступа;
2. Файл /etc/hosts на точке доступа не статичен – он может измениться внутренним DHCP-сервером и при перезагрузке точки доступа;
3. Для того, чтобы Dnsmasq перечитал файл, ему нужно отправить HUP сигнал: killall -1 dnsmasq

В результате я написал на python небольшой скрипт: dns-ddwrt.

Этот скрипт:

1. скачивает с моих точек доступа по SSH исходные файлы hosts;
2. объединяет их;
3. добавляет к этому списку перечень виртуальных OpenVZ машин;
4. записывает полученный результат обратно на точки доступа и перезапускает на них dnsmasq.

Скрипт поставил в cron и радуюсь

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

Пошаговая инструкция для сборки контейнера есть на: http://wiki.openvz.org/Gentoo_template_creation.

После прочтения этого руководства я написал скрипт, который позволяет собрать шаблон из архивов stage-3 и portage: openvz.zip

Скрипт должен запускаться под рутом. Сборка может производиться из любой Linux-системы (не обязательно из Gentoo).

Все проблемы 32-х битной версии WTK связаны с тем, что для её сборки была использована 32-х битная версия Java. И, если установить 32-х битную верию Java, то все зарботает.

Таким образом у меня получился следующий алгоритм установки:

1. Устанавлием 32-х битную версию Java:
   • Идем на сайт Sun Oracle и скачиваем не RPM-файл с JDK для Linux (не Linux 64): http://java.sun.com/javase/downloads/widget/jdk6.jsp
   • Получаем из .bin-файла .deb-файл, выполнив следующие команды:

     sudo apt-get install java-package
     DEB_BUILD_GNU_TYPE=i486-linux-gnu DEB_BUILD_ARCH=i386 fakeroot make-jpkg jdk-6u21-linux-i586.bin

   • К сожалению, в полученном файле лежит битый postinst скрипт. Его надо удалить:

     sudo dpkg-deb -x sun-j2sdk1.6_1.6.0+update21_amd64.deb temp/
     sudo dpkg-deb -e sun-j2sdk1.6_1.6.0+update21_amd64.deb temp/DEBIAN
     sudo rm temp/DEBIAN/postinst
     dpkg-deb -b temp/ sun-j2sdk1.6_1.6.0+update21_amd64.deb
     sudo rm -fR temp

   • И после этого можно собственно установить 32-х битный JDK:

     sudo dpkg -i sun-j2sdk1.6_1.6.0+update21_amd64.deb

2. Собственно установка Sun Java Wireless Toolkit:
   • Идем на сайт Oracle и скачиваем версию для Linux: http://java.sun.com/products/sjwtoolkit/download.html
   • Запускаем всежескаченный файл: sun_java_wireless_toolkit-2.5.2_01-linuxi486.bin.sh. Когда он спросит путь к JDK, указываем: /usr/lib/j2sdk1.6-sun/bin/

Вот, собственно, и все.

Установить собственный сервер оказалось очень просто:

1. Скачать на WEB-сервер скрипт: http://people.mozilla.org/~telliott/weave_minimal.tgz
   Данный скрипт написан на PHP и использует для хранения контактов SQLite.
2. Прописать скрипт в настройках апача:

   Alias /weave /<путь до скрипта>/index.php

3. Создать пользователя, воспользовавшись скриптом:

   php create_user
   

4. Дать права для доступа к файлу базы данных пользователю, от имени которого запущен WEB-сервер.
5. Проверить скрипт.
   Для пользователя dummy адрес должен выглядеть как-то так:

   https://localhost/weave/1.0/dummy/info/collection

Собственно все.

Ссыдки по теме:

1. http://tobyelliott.wordpress.com/2009/09/11/weave-minimal-server/
2. https://wiki.mozilla.org/Labs/Weave/API

Все делал по инструкции – прошивка по tftp заливается, но толку с этого ноль: после перезагрузки точки доступа она кажет по адресу 192.168.0.1 страницу для перепрошивки.

Оказывается, что перепрошить её можно еще проще:

1. заливаем через штатную WEB-морду официальной прошивки прошивку: DIR320-wimax-1.2.6 (2.7Mb);
2. заливаем через штатную WEB-морду свежеустановленной  прошивки любую другую – в моем случае DD-WRT.

К сожалению, я запамятовал, где подсмотрел этот рецепт

1. Сеть A: функцию маршрутизатора выполняет компьютер на Linux Ubuntu 8.10, интернет через PPPoE;
2. Сеть B: маршрутизатор D-Link DIR-300 rev. B1, интернет приходит по Ethernet-у.

В обоих сетях от провайдера получен белый IP. Кол-во компьютеров в каждой сетки более одного.

Сети должны быть связаны, но при этом максимально автономны (у каждой свой DNS и DHCP-сервер).

Алгоритм решения у меня был следующий:

1. Установить на D-Link DIR-300 rev. B1 прошивку DD-WRT v24-sp2;
2. Настроить туннель IP-over-IP между DD-WRT и Linux;
3. Настроить маршрутизацию между подсетями через тунель.

Важный момент: трафик в туннеле передается в открытом виде. Каким образом его можно зашифровать я не разбирался.

Теперь по каждому пункту подробнее…

Установка DD-WRT на D-Link DIR-300 rev. B1

Существует как минимум две разновидности DIR-300: rev A и rev B. Судя по всему, они между собой внутри имеют мало общего.

На DIR-300 rev B прошивка DD-WRT устанавливается через штатный WEB-интерфейс без каких-либо проблем.

Надо отметить, что доступная под DIR-300 прошивка не имеет встроенной поддержки OpenVPN. Так же на маршрутизатор не получится поставить дополнительные пакеты – нет карты памяти и USB-порта.

Воспользоваться Firmware Modification Kit для установки OpenVPN внутрь прошивки, у меня так же не получилось (утилитка отказалась распаковывать прошивку, сославшись на неизвестный формат образа). Таким образом от использования OpenVPN пришлось отказаться.

Настройка туннеля между DD-WRT и Linux

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

1. OpenVPN – самый идеологически правильный вариант, но от него пришлось отказаться из-за нежелания самому собирать прошивку из исходников. Обладает следующими особенностями:
   1. Качественное шифрование трафика;
   2. В качестве транспорта используется TCP или UDP. Оба протокола корректно обрабатываются NAT-ами;
   3. Клиент-серверная архитектура. Клиент может быть с серым IP-адресом.
2. EoIP (Ethernet Over IP, протокол etherip – 97) – загадочный зверь, поддерживаемый DD-WRT из коробки.
   Теоретически позволяет настроить мост между двумя DD-WRT с минимальными усилиями, но я не нашел по нему никакой документации касательно Linux. Модуль для поддержки этого протокола etherip.ko в моем ядре так же отсутсвовал.
3. IPIP (IP Over IP, ipencap – 4) – протокол для инкапсуляции IP-пакетов в IP-пакеты.
   Собственно его я и использовал. Для работы использует модуль ядра ipip.ko. Этот протокол был как в Linux, так и в DD-WRT.
4. GRE (Generic Routing Encapsulation, gre – 47) – протокол для инкапсуляции всего и всея в IP-пакеты.
   В теории, туннель в GRE должен настраиваться точно так же, как и в IP-over-IP, но я не пробовал.

Во всех случаях, кроме OpenVPN, туннель существует отдельно от шифрования.

Адреса сети

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

Сеть A (Linux Ubuntu):

1. Внутренняя сеть: 192.168.1.0/24
2. Адрес сервера внутри туннеля: 192.168.0.1
3. Внешний адрес сервера: 89.123.1.234

Сеть B (DD-WRT):

1. Внутренняя сеть: 192.168.2.0/24
2. Адрес сервера внутри туннеля: 192.168.0.2
3. Внешний адрес сервера: 89.123.2.234

Предполагается, что обе сети по отдельности функционируют и имеют доступ в интернет с белым IP.

Настройка туннеля в Linux Ubuntu

Для настройки сети необходимо добавить в файл /etc/network/interfaces следующие строки:

auto tun1
iface tun1 inet static
    # Адрес машины внутри туннелся. Соединения точка-точка, по этому маска из одних единиц
    address 192.168.0.1
    netmask 255.255.255.255
    # Адрес внутренний адрес машины, с которой установлен тунель
    pointopoint 192.168.0.2
    # Размер MTU
    mtu 1480
    # Перед поднятием интерфейса нужно создать тунель, что мы тут и делаем
    pre-up iptunnel add tun1 mode ipip local 89.123.1.234 remote 89.123.2.234 ttl 255
    up ifconfig tun1 multicast
    # Весь трафик в соседнюю сеть надо завернуть в тунель
    up route add -net 192.168.2.0/24 gw 192.168.0.2 dev tun1
    # Удаляем туннель после удаления интерфейса
    post-down iptunnel del tun1

В примере используется имя интерфейса tun1, но, в принципе, его можно назвать как угодно.

Размер MTU может быть различным. Для его вычисления надо взять минимальный MTU от интерфейсов, смотрящих в интернет (это можно сделать командой ifconfig), и вычесть из него заголовок пакета ipip, которые равен 20 байтам.

Основная борьба под Linux начитается с фаерволом. У меня она свелась к добавлению следующих правил в файл /var/lib/ufw/user.rules (но это сильно зависит от конкретного случая):

-A ufw-user-input   -p ipencap -i ppp0 -j ACCEPT
-A ufw-user-input   -i tun1 -j ACCEPT
-A ufw-user-forward -i tun1 -j ACCEPT

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

sudo ifup tun1
sudo /etc/init.d/ufw restart

Для диагностики могу посоветовать следующий порядок действий:

1. Проверить наличие туннеля:

   ~$ ip tunnel show
   tunl0: ip/ip  remote any  local any  ttl inherit  nopmtudisc
   tun1: ip/ip  remote 83.123.1.234  local 83.123.2.234  ttl 255

2. Проверить, поднялся ли интерфейс:

   ~$ ifconfig tun1
   tun1      Link encap:IPIP Tunnel  HWaddr
    inet addr:192.168.0.1  P-t-P:192.168.0.2  Mask:255.255.255.255
    UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1480  Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:81 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:0 (0.0 B)  TX bytes:6478 (6.4 KB)

   Здесь надо отметить, что кол-во RX-пакетов должно расти при пинговании той стороны даже в том случае, если маршрутизатор на той стороне выключен.
   То есть если идет попытка пинговать адрес 192.168.0.2 или 192.168.2.100, то RX должен увеличиваться. В противном случае надо искать проблему в фаерволе.

3. Проверить, проходят ли пакеты через нужные правила iptables.
   Для этого можно воспользоваться ключем -v. Он показывает сколько пакетов и байт прошло через указанное правило.
4. Проверить, уходят ли пакеты во внешний интерфейс:

   sudo ~$ tcpdump -i ppp0 -n proto ipencap

Настройка туннеля в DD-WRT

Алгоритм настройки тот же, что и в Linux, только без /etc/network/interfaces.

Сначала надо обкатать эти команды через SSH, и только потом заносить в Administration > Commands.

Для поднятия интерфейса нужно выполнить следующие команды (их позже надо будет внести в Administration > Commands > Startup):

/sbin/insmod ipip
/usr/sbin/ip tunnel add tun1 mode ipip remote 89.123.1.234 local 89.123.2.234 ttl 255
ifconfig tun1 192.168.0.2 pointopoint 192.168.0.1 mtu 1480 up
route add -net 192.168.1.0/24 gw 192.168.0.1

Для пропускания пакетов через фаервол нужно выполнить команды (их позже надо будет внести в Administration > Commands > Firewall):

iptables -I INPUT 2 -p ipencap -s 89.123.1.234 -j ACCEPT
iptables -I INPUT 3 -i tun1 -j ACCEPT
iptables -I FORWARD 1 -o tun1 -j ACCEPT
iptables -I FORWARD 2 -i tun1 -j ACCEPT

Если все прошло успешно, то подсети 192.168.1.0/24 и 192.168.2/24 должны прозрачно общаться друг с другом.

Для диагностики справедливы те же принципы, что и для Linux.

После того, как ping-и ходят в обе стороны имеет смысл проверить размер MTU (при неправильном MTU может не работать передача больших IP-пакетов):
Для проверки вычисления размера MTU проще всего выполнить ping с крупным размером пакета, например:

ping -s 1500 -M do -c 10 192.168.2.1