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

Разгадка кроется в малозаметном патче к libiconv-full под названием 100-strip-charsets.patch. Пролистав его можно с удивлением обнаружить, что пакет, вроде бы имеющий в названии слово “full”, ничего общего с этим словом не имеет: доблестные разработчики OpenWrt в “полной” версии libiconv просто выпилили 97% всех кодировок, включая все упоминания кириллических, и оставив лишь несколько западноевропейских.

Наиболее простое решение – просто удалить патч 100-strip-charsets.patch из пакета libiconv-full. Но так размер данной библиотеки увеличится в несколько раз! По этой причине мы сделали исправленную версию исходного патча, в которой оставлены кириллические кодировки, но вырезано большинство прочих.

Скачать исходный код модифицированного libiconv-full можно из нашего архива.

Как оказалось, эта проблема имеет простое решение.

Логирование в davfs2, размещенном на роутере под управлением OpenWrt, организовано не самым удобным образом. Лог всегда пишется в системный кольцевой буфер, прочитать который можно при помощи команды logread, и объем оного весьма незначителен. А отладочные сообщения davfs2 в зависимости от выбранного уровня отладки либо слишком подробны и многочисленны, либо слишком кратки и по ним ничего невозможно понять.

Так или иначе, при работе стандартного пакета davfs2 с выставленным в davfs2.conf параметре debug most в системном логе можно наблюдать следующие строки при попытке загрузки файла в удаленное хранилище:

Mon Dec 22 19:15:36 2014 mark.debug syslog: Running pre_send hooks
Mon Dec 22 19:15:36 2014 mark.debug syslog: Sending request headers:
Mon Dec 22 19:15:36 2014 mark.debug syslog: PUT /testfile HTTP/1.1
User-Agent: davfs2/1.5.2 neon/0.30.0
Connection: TE
TE: trailers
Host: webdav.yandex.ru
Transfer-Encoding: chunked
Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Mon Dec 22 19:15:36 2014 mark.debug syslog: Sending request-line and headers:
Mon Dec 22 19:15:36 2014 mark.debug syslog: Sending request body:
Mon Dec 22 19:15:36 2014 mark.debug syslog: Request body provider failed with 
Mon Dec 22 19:15:36 2014 mark.debug syslog: -
Mon Dec 22 19:15:36 2014 mark.debug syslog: 1
Mon Dec 22 19:15:36 2014 mark.debug syslog: 
Mon Dec 22 19:15:36 2014 mark.debug syslog: sess: Closing connection.
Mon Dec 22 19:15:36 2014 mark.debug syslog: sess: Connection closed.
Mon Dec 22 19:15:36 2014 mark.debug syslog: Request ends, status 
Mon Dec 22 19:15:36 2014 mark.debug syslog: 0
Mon Dec 22 19:15:36 2014 mark.debug syslog:  class 
Mon Dec 22 19:15:36 2014 mark.debug syslog: 0
Mon Dec 22 19:15:36 2014 mark.debug syslog: xx, error line:
Mon Dec 22 19:15:36 2014 mark.debug syslog: Failed reading request body file: Bad address
Mon Dec 22 19:15:36 2014 mark.debug syslog: 
Mon Dec 22 19:15:36 2014 mark.debug syslog: Running destroy hooks.
Mon Dec 22 19:15:36 2014 mark.debug syslog: Request ends.
Mon Dec 22 19:15:36 2014 mark.debug syslog: tidy: neon error
Mon Dec 22 19:15:36 2014 mark.debug syslog:       Failed reading request body file: Bad address

Как видим, выводится не самая информативная ошибка Bad address, происходящая из используемой в davfs2 для коммуникации библиотеки neon – текста Failed reading request body file в исходных кодах davfs2 найти не получится.

После некоторой изыскательной деятельности удалось обнаружить, что причина кроется в том простом факте, что библиотека neon и пакет davfs2 по умолчанию компилируются с разными параметрами. Так, в Makefile пакета neon указаны следующие флаги:

TARGET_CPPFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE

А в Makefile пакета davfs2 такая строка отсутствует. И именно это отличие приводит к фатальной нестыковке, когда дело доходит до загрузки файлов в удаленное хранилище. Простым добавлением означенных флагов в Makefile проблема полностью решается и davfs2 начинает всегда корректно загружать файлы в WebDav.

PS: Кстати, интересно отметить, что данная проблема не была зафиксирована в устаревшей версии davfs2, размещенной в нашем архиве – в нашем случае Makefile содержал все необходимые флаги для корректной сборки. Вопрос, отчего требуемые флаги потерялись в Makefile из официального репозитория OpenWrt, оставим на совести его мейнтейнеров. Да, кстати, версия davfs2 в нашем хранилище теперь обновлена до актуальной 1.5.2. А также приложен дополнительный патч, корректирующий вывод отладочного текста в системный лог.

Может возникнуть закономерный вопрос: зачем изобретать велосипед и почему бы не использовать обычный rsync для копирования данных напрямую в davfs2? Ответ простой: это… не работает как надо. Во всяком случае, с Яндекс.Диском, и если запускать процедуру на роутере под управлением OpenWrt.

То ли из-за особой неторопливости Яндекс.Диска, то ли из-за особенностей davfs2, но при попытке копирования большого количества файлов (а иногда такое случается и с единичными файлами!), большая их часть оказывалась в каталоге lost+found, служащем для локальных копий файлов, загрузка которых в WebDav провалилась. И всё это несмотря на достаточный объем выделенного кэша, стандартные настройки davfs2 для повторной загрузки файлов в случае ее неудачи, и довольно широкого канала связи.

Итак, для самописного и более надежного бэкапера в WebDav нам понадобятся:

1. davfs2 – стандартный пакет из репозитория OpenWrt;
2. cadaver – модифицированная версия утилиты для прямого копирования файлов в WebDav из нашего архива;
3. php-cli – стандартный интерпретатор PHP, при помощи которого мы сгенерируем набор команд для cadaver’а.

Добавленные в cadaver патчи позволяют при помощи нового ключа -F пропускать проверку подлинности сертификатов (а под OpenWrt у нас все используемые в WebDav SSL-сертификаты считаются подозрительными и требуют ручного подтверждения), а также указывать с помощью ключа -n нестандартный путь к хранилищу паролей для автоматической авторизации на WebDav-сервере. Внесенные изменения позволяют создать для cadaver файл с набором команд, которые будут выполняться автоматически без участия человека.

Теперь обратим внимание на скрипт phpsync.php.

У этого скрипта две задачи:
Во-первых, он отвечает за “обратную синхронизацию” – в скрипте производится проверка, все ли находящиеся в WebDav-хранилище файлы продолжают находиться на локальном диске. В случае обнаружения в удаленном хранилище файлов, которые были локально удалены, скрипт удалит их и из WebDav – обычным вызовом unlink() на смонтированном разделе davfs2.
Во-вторых, скрипт генерирует набор команд для cadaver‘а для загрузки локально измененных или отсутствующих в WebDav файлов в удаленное хранилище.
В скрипте есть ряд параметров, которые нужно настроить. Так, параметром $outfile определяется путь к файлу, в который будет записан сгенерированный набор команд, в параметре $remotebase необходимо указать точку монтирования davfs2. Также в нем указывается адрес WebDav сервера, к которому должен подключаться cadaver – по умолчанию это https://webdav.yandex.ru. Затем следует указать каталоги, которые требуется синхронизировать, например:

phpsync("/srv/content","/backup/content");
phpsync("/srv/otherdir","/backup/otherdir");

Так будут сгенерирован набор команд для отражения локальных каталогов /srv/content и /srv/otherdir в удаленные WebDav-каталоги /backup/content и /backup/otherdir соответственно. Обратите внимание – удаленные пути указываются относительно корня WebDav-диска, без привязки к локальной точке монтирования davfs2!

После этого следует создать парольный файл для cadaver. Это обычный текстовый документ, содержающий строку следующего вида:

machine webdav.yandex.ru login вашлогин password вашпароль

Наконец, создаем ash-скрипт, который мы будем вызывать через кронтаб:

#!/bin/ash
/usr/bin/php-cgi -f /srv/phpsync.php

if [ -e "/var/.phpsync.list" -a $(wc -l "/var/.phpsync.list" | awk '{print $1;}') -gt 2 ]
then
        /usr/bin/cadaver -F -r "/var/.phpsync.list" -n "/srv/auth.rc"
fi

Подставляем ваши значения:

• /srv/phpsync.php — путь к PHP-скрипту;
• /srv/auth.rc — путь к парольному файлу;
• /var/.phpsync.list — путь к файлу с набором команд для cadaver.

Не забываем сделать скрипт исполняемым, выполнив команду chmod +x на данном файле. Теперь мы можем проверить работоспособность копирования, запустив этот скрипт. В терминал при этом будет выведен результат работы PHP-генератора, а также будет показан процесс выполнения задания cadaver’ом.

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

Давным-давно, в далекой-далекой галактике… оказалось, что много лет назад некий товарищ по имени ioannis в рамках решения означенной проблемы создал небольшое расширение SQLite, по сути представляющее собой урезанную версию ICU, из которой был выброшен код, который в 95% случаев никогда не потребуется. Таким образом удалось сократить размер расширения с мегабайт до символических 70-90 кбайт (в зависимости от архитектуры и компилятора). Копия исходного сообщения осталась доступна на mail-archive.com, и хотя оригинальная ссылка на исходный код расширения sqlite3_unicode.c неработоспособна, его все еще можно найти в интернете, а также мы добавили его в наш архив.

Возможности расширения

#define SQLITE3_UNICODE_FOLD – поддержка нелатинских символов функцией FOLD() – +10КБ
#define SQLITE3_UNICODE_LOWER – поддержка нелатинских символов функцией LOWER() – +10КБ
#define SQLITE3_UNICODE_UPPER – поддержка нелатинских символов функцией UPPER() – +10КБ
#define SQLITE3_UNICODE_TITLE – поддержка нелатинских символов функцией TITLE() – +10КБ
#define SQLITE3_UNICODE_UNACC – преобразование accented-символов в обычные, для русского языка не очень актуально – +30КБ
#define SQLITE3_UNICODE_COLLATE – заменяет COLLATION типа NOCASE на новый, в котором при сравнении не учитывается регистр в т.ч. и для нелатинских символов.
#define SQLITE3_UNICODE_UNACC_AUTOMATIC – попытаться применять UNACC в функции LIKE и операциях сравнения с COLLATE NOCASE.

Что характерно, функциональность, которая не требуется, может быть отключена путем убирания соответствующих #define для экономии места и увеличения производительности (вряд ли, впрочем, существенного).

Теперь разберемся, как собрать это расширение и задействовать его в cli-версии SQLite и в модуле для PHP.

Сборка под Linux

Для начала, скачиваем и распаковываем исходный код SQLite – нам потребуются заголовочные файлы из него. Можно использовать любую версию: я брал amalgamation без autoconf – она меньше. В тот же каталог копируем sqlite3_unicode.c.

Далее, корректности ради, открываем sqlite3_unicode.c текстовым редактором и вписываем вверху директиву:

/* we want shared library. only. */
#define SQLITE_ENABLE_UNICODE 1

Этим мы указываем, что собираемся компилировать shared-библиотеку. С другой стороны – соответствующий #if в коде расширения написан таким своеобразным образом, что этого можно и не делать.

Затем следует непосредственно процесс компиляции. Предполагается, что пакеты из набора build-essentials уже установлены в системе – во всяком случае, здесь потребуется gcc:

gcc -shared -o sqlite3_unicode.so sqlite3_unicode.c

Закрывая глаза на ряд warning’ов, получаем готовую библиотеку.

При работе с cli-версией потребуется разместить полученный sqlite3_unicode.so в каталоге с остальными системными библиотеками, либо же выполнить export следующего вида:

export LD_LIBRARY_PATH="/path/to/library/dir:$LD_LIBRARY_PATH"

Затем открываем cli и пишем команду .load sqlite3_unicode. Если ошибок не возникло – значит, расширение успешно загрузилось.

Для загрузки расширения в PHP потребуется в php.ini выставить корректный путь к месту расположения библиотеки в перараметре sqlite3.extension_dir. Затем в скрипте используем команду вида $db->loadExtension(‘sqlite3_unicode.so’);

Вот и всё – теперь сравнения с COLLATE NOCASE будут регистронезависимыми не только для латиницы, но и для русских букв.

Сборка под OpenWrt

Теперь попробуем побороть Buildroot от OpenWrt и кросс-компилировать это расширение в toolchain’е для запуска на роутере. В конечном счете, именно ради этого весь процесс и затевался – на ПК-то нет проблемы установить ICU, в отличие от встраиваемых систем. Надо признать, что борьба с Buildroot’ом для меня оказалась намного сложнее, чем все поиски решения проблемы с регистрозависимостью в целом и попытки разобраться, как его собирать в обычных условиях, в частности.

В конечном счете, после бессчетных неудачных попыток, я остановился на варианте формирования отдельного пакета, содержащего только это расширение с выставленным параметром DEPENDS на libsqlite3 и включенным в его состав С-файле с исходным кодом. Скачать готовый пакет можно в нашем архиве.

Его можно распаковать в каталог “package” корневой директории Buildroot’а, а затем нужно в make menuconfig выбрать пакет libsqlite3_unicode и запустить его сборку при помощи команды make package/libsqlite3_unicode/compile.

После установки полученного ipk на роутер подключение данного расширения производится аналогичным ранее описанному способом. Обратите внимание, что имя расширения для OpenWrt – libsqlite3_unicode.so, его размещение по умолчанию – /usr/lib.

Альтернативой davfs2 для прямого получения или загрузки файлов в облачное хранилище является утилита cadaver. Однако, она предполагает интерактивное взаимодействие с пользователем, и использование ее в автоматизированных скриптах не представляется возможным. Обойти эту проблему можно при помощи утилиты empty, аналога expect для создания и взаимодействия с псевдотерминалами.

Для реализации полностью автоматической загрузки и скачивания файлов с облачного хранилища был создан скрипт webdav.sh.

Перед использованием необходимо настроить несколько параметров, определенных в начале скрипта:

• ififo=/tmp/empty.in.fifo
  – путь к fifo ввода, на роутерах желательно размещать в /tmp
• ofifo=/tmp/empty.out.fifo
  – путь к fifo вывода, на роутерах желательно размещать в /tmp
• cmd=”cadaver https://webdav.yandex.ru”
  – путь к утилите cadaver и адрес WebDav-сервиса
• username=YourUserName
  – логин от WebDav-сервиса
• password=YourPassword
  – пароль от WebDav-сервиса

Доступные команды:

• webdav.sh put <локальный файл> [удаленный путь] – загрузка файла в облако
  – Локальный файл – обязательный параметр, должен быть указан один, файл должен быть доступен для чтения;
  – Удаленный путь – опционально, если его не указать, то файл будет загружен в корневой каталог WebDav.
• webdav.sh get <удаленный файл> [локальный путь] – выгрузка файла из облака
  – Удаленный файл – обязательный параметр, должен быть указан один, файл должен существовать;
  – Локальный путь – опционально, если его не указать, то файл будет загружены в текущий каталог.
• webdav.sh mput <локальные файлы> [удаленный путь] – множественная загрузка
  – Локальные файлы – маска вида “/path/to/*.files”, указание кавычек обязательно;
  – Удаленный путь – опционально, если его не указать, то файлы будут загружены в корневой каталог WebDav.
• webdav.sh mget <удаленные файлы> [локальный путь] – множественная выгрузка
  – Удаленные файлы – маска вида “/remote/path/*”;
  – Локальный путь – опционально, если его не указать, то файлы будут загружены в текущий каталог.

Например, для загрузки файла “/etc/config/firewall” в удаленный каталог “/openwrt” необходимо набрать команду webdav.sh put /etc/config/firewall /openwrt/firewall. Отметим, что удаленный каталог “openwrt” перед выполнением этой команды должен существовать.

PS: Стоит обратить внимание, что утилита empty имеет такую особенность, что если указанные в конфигурации fifo-файлы уже существуют на момент ее запуска, то она просто не запустится, тихо ругнувшись в syslog. А в случае каких-либо сбоев в ходе работы с empty эти fifo-файлы могут автоматически не удалиться.

Для исправления ситуации существуют немногочисленные программы, позволяющие создавать своего рода псевдотерминалы, отслеживающие появление на консоли того или иного текста и позволяющие задать текст, автоматически отправляемый в ответ на данный текст. Типовым примером является утилита expect, требующая для работы интерпретатора tcl, или значительно более легкая и значительно менее известная утилита empty, заметно более подходящая для OpenWrt-роутеров.

В случае попытки запуска утилиты empty на роутере, работающем на процессоре архитектуры PowerPC (в частности, mpc85xx), обнаруживается, что любые действия приводят к ее моментальному сбою с сообщением о segfault’е (SIGSEGV) в системном логе:

Tue Apr 22 00:07:26 2014 kern.info kernel: [885768.318640] empty[9029]: unhandled signal 11 at 00004000 nip 4806f2a4 lr 10002180 code 30001

В ходе изучения исходников empty.c была выявлена особенность gcc-компилятора, что при вызове функции semctl() без четвертого параметра, который, в общем-то, должен бы являться необязательным, под архитектуру PowerPC генерируется некорректный код. Описание и workaround для данной проблемы представлен, к примеру, здесь (к слову, обратите внимание на дату заметки – 2003 год). Так, быстро исправить ситуацию позволяет добавление заглушки в виде указателя, к примеру, на неиспользуемую целочисленную переменную, в качестве четвертого параметра на каждом вызове функции semctl().

На базе этой информации был составлен патч mpc85xx-fix.patch:

--- a/empty.c	2014-04-22 00:04:32.317542049 +0400
+++ b/empty.c	2014-04-22 00:06:02.580442807 +0400
@@ -177,6 +177,7 @@
 	int	fl_state = 2;		/* 0 - in	>>>
 					   1 - out	<<<
 					   2 - unknown */
+	int	dummy;
 	
 /* semaphores */
 #ifdef _POSIX_SEMAPHORES
@@ -495,7 +496,7 @@
 	
 	if (semop(sem, &free_sem, 1) == -1)
 		(void)perrxslog(255, "Can't release semaphore: %d from lock %m", sem);
-	if (semctl(sem, 0, IPC_RMID) == -1)
+	if (semctl(sem, 0, IPC_RMID, &dummy) == -1)
 		(void)syslog(LOG_NOTICE, "Warning: Can't remove semaphore: %d  %m", sem);
 
 #if !defined(__SVR4) && !defined(__hpux__) && !defined(__AIX)
@@ -779,7 +780,10 @@
 	va_end(va);
 	
 	if (sem != -1)
-		semctl(sem, 0, IPC_RMID);
+	{
+		int dummy;
+		semctl(sem, 0, IPC_RMID, &dummy);
+	}
 
 	(void)closelog();
 	(void)exit(ex_code);

Для использования его нужно разместить в папку ./package/feeds/packages/empty/patches относительно корня каталога buildroot'а OpenWrt и затем пересобрать утилиту командой make package/feeds/packages/empty/{clean,compile}.

Что характерно, проблема проявляется только при сборке под mpc85xx (powerpc), тогда как, к примеру, утилита, собранная для ar71xx (mips32r) работает корректно.

PS: Название утилиты empty обыгрывает сокращение pty, означающее "псевдотерминал", и слово "empty", означающее "пустоту". И все было бы хорошо, не будь "empty" до такой степени распространенным словом при описании той или иной компьютерной проблемы. В результате найти в интернете хоть какие-то обсуждения утилиты empty и с добавлением дополнительных ключевых слов вроде "terminal", "console" или "utility" терпят сокрушительное фиаско. По этой причине данную утилиту больше шансов найти по не совсем логичному названию empty-expect, что подчеркивает ее связь со значительно более известной утилитой автоматизации интерактивных консольных программ - expect.

[erinome@shuttle trunk]$ make menuconfig V=s
scripts/config/mconf: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by scripts/config/mconf)
make: *** [menuconfig] Error 1

Вызов make dirclean в данном случае не помогает. Дело в том, что скомпилированный в другой системе бинарник mconf автоматически не пересобирается. Для решения этой проблемы просто соберем его заново вручную:

[erinome@shuttle trunk]$ cd scripts/config
[erinome@shuttle trunk]$ make clean && make
[erinome@shuttle trunk]$ cd ../../

После этого make menuconfig снова станет работоспособен.

Итак, рассмотрим еще один вариант, не требующий никакого дополнительного софта, помимо роутера с OpenWrt. Одним из очевидных способов обхода блокировки с минимальным использованием сторонних средств является следующая система:

1. Перестаем использовать провайдерские DNS и переходим на свободные (напр., от Google: 8.8.8.8, 8.8.4.4);
2. Устанавливаем на роутере прокси-сервер (напр., tinyproxy);
3. Заворачиваем при помощи iptables все запросы к заблокированным ресурсам на прокси, выделяя такие запросы по целевому IP-адресу;
4. Задаем в конфиге прокси любой заграничный апстрим-прокси, на котором отсутствует блокировка.

Плюсы:
+ На прокси заворачиваются только обращения к заблокированным ресурсам, все остальные работают как раньше;
+ Не нужно вообще ничего настраивать на всех подключаемых к роутеру устройствах;
+ Мы лично всё контролируем. :)

Минусы:
– Неудобство по ручному составлению списка блокированных ресурсов;
– Неудобство поиска живых и достаточно быстрых апстрим-прокси;
– Необходимость установки лишнего софта на роутер и потенциально его частая перенастройка.

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

Идея в том, что раз мы поднимаем у себя на роутере transparent-прокси и прозрачно заворачиваем на него часть трафика, чтобы затем переправить его на другой прокси в интернете, то можно задаться вопросом: а, собственно, зачем нам создавать каскад из прокси, если можно сразу найти внешние прокси-сервера, поддерживающие transparent-режим? Все, что потребуется – это отыскать таковой и сразу завернуть нужный трафик туда, без локального прокси-сервера.

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

#!/bin/ash
###
# Erinome proxyPass v.1
###

proxy="1.1.1.1:23456"
bhosts="188.190.124.85/32 185.10.208.40/32"

enableProxy()
{
	cleanRules
	for bhost in $bhosts
	do
		cmd="iptables -A prerouting_lan_rule -t nat -p tcp -d ${bhost} --dport 80 -m comment --comment "ErinomePP" -j DNAT --to-destination ${proxy}"
		echo $cmd; $cmd
	done
}

disableProxy()
{
	cleanRules
}

cleanRules()
{
	iptables -S prerouting_lan_rule -t nat | grep "comment ErinomePP" | while read iptfind
	do
		cmd="iptables -t nat -D `echo $iptfind | cut -d' ' -f2-`"
		echo $cmd; $cmd
	done
}


case "$1" in
	ena*)
		enableProxy
		;;
	dis*)
		disableProxy
		;;
	*)
		echo 'not recognized'
		;;
esac

В переменной “bhosts” должны быть перечислены заблокированные хосты, в переменной “proxy” – указан адрес и порт анонимного прокси-сервера с поддержкой transparent-режима. При внесении каких-либо изменений в список заблокированных хостов или при необходимости сменить адрес прокси, всё, что требуется сделать – это обновить данные в скрипте и набрать в консоли “./proxyPass.sh enable”. Старые правила iptables будут вычищены автоматически и заменены новыми.

PS: При использовании типа подключения DHCP необходимо указать опцию “option peerdns ‘0’” в /etc/config/network, чтобы провайдерские DNS-серверы, получаемые с DHCP, полностью игнорировались.

PPS: Также может возникнуть вопрос о том, как завернуть в прозрачный прокси тот трафик, который не проходит через роутер транзитом, а генерируется софтом непосредственно на роутере. Правила рассмотренные для PREROUTING для этих целей не подходят, а нужно добавить правила для OUTPUT:

iptables -t nat -A OUTPUT -d <dest IP>/32 -p tcp -m tcp --dport 80 -m comment --comment ErinomePP -j DNAT --to-destination <proxy IP>:<proxy port>

В терминологии OpenWrt, вероятно, вместо “-А OUTPUT” следует указать более корректный блок правил, определяющий именно OUTPUT зоны WAN…

May 16 15:01:20 OpenWrt daemon.info dnsmasq-dhcp[2451]: DHCPINFORM(br-lan) 172.16.10.30 90:e6:ba:dc:2e:c3
May 16 15:01:20 OpenWrt daemon.info dnsmasq-dhcp[2451]: DHCPACK(br-lan) 172.16.10.30 90:e6:ba:dc:2e:c3 avalanche

Происходит это из-за того, что у встроенного в ОС Windows 7 (и некоторых других творений Microsoft) DHCP-клиента есть маниакальное желание получить настройки прокси-серверов с DHCP, и он продолжает эти попытки и в том случае, когда DHCP никак не реагирует на подобные запросы. В стандартной конфигурации dnsmasq не рассылает никакой информации о прокси-серверах, и Windows-системы продолжают запрашивать эти данные снова, и снова, и снова… и снова.

Заставить их заткнуться можно простым добавлением опции в /etc/dnsmasq.conf:

dhcp-option=252,"\n"

Эта опция недвусмысленно дает понять Windows-системам, что здесь НЕТ никаких прокси-серверов, и что пора уже перестать о них спрашивать.

В их числе:

• whois – C-версия известной утилиты обновлена до 5.0.25;
• samba36 – SMB клиент и сервер обновлен до 3.6.15;
• php5 – PHP-интерпретатор обновлен до 5.4.15.

Для их сборки требуется OpenWrt Buildroot. Имея настроенный Buildroot необходимо просто перенести скачанные файлы в каталог ./packages/<имя пакета>, активировать пакет в make menuconfig, после чего запустить его сборку командой make package/<имя пакета>/compile. Обратите также внимание, что для уже присутствующих в Buildroot’е пакетов рекомендуется их заменять, а не просто копировать в ./packages.