из-за умершего стартового жесткого диска в домашнем роутере пришлось переставлять freebsd 8.2 c нуля на свежий диск ((((

поскольку freebsd, как правило, используется в довольно узкой специализации интернет-серверов, то имеет грустно-забавную особенность: почти весь прикладно-полезный софт необходимо устанавливать из портов, для чего исходные коды должны быть скачаны из интернета, т.е. freebsd после начальной установки для последующей настройки должна быть подключена к доступному интернету, через реальные адреса или через http/ftp-прокси или через NAT

все эти условия отсутствуют при получении интернета от провайдера квидекс: т.е. абонент получает ethernet кабель в квартиру и ip-адрес из диапазона приватных сетей - конкретно, у меня 10.107.94.19, при этом ни прокси ни nat не доступны, а собственно "доступный" интернет приходит через vpn/pptp/l2tp - путем получения либо реального ip-адреса либо приватного c NAT

похожая методика весьма широко распространена

но засада тут заключается в том, что для включения интернета через провайдерский vpn/pptp/l2tp нужно скачать из интернета исходники либо pptp-client либо mpd либо еще чего-нить в том же духе, т.е. получается замкнутый круг: чтобы был живой интернет нужно скачать некий софт, а чтобы скачать некий софт нужен живой интернет

почему в исходную инсталляцию freebsd (даже в DVD-версии) не включены популярные vpn-клиенты типа pppd,pptp-client,mpd - нифига не понятно
могли бы в /usr/ports/distfiles хоть десяток-другой файлов запихнуть ...

для выхода из такой ситуации без помощи другого компа (удобнее под windows) не обойтись

я делаю тупо:

1. входящий кабель от провайдера втыкаю в хаб/свич
2. туда же втыкаю оба компа: целевой с freebsd и вспомогательный с windows
3. на windows-машине настраиваю сетевую карту согласно параметрам от провайдера: ip=10.107.94.19, mask=255.255.255.0, gw=10.107.94.1, dns=93.182.32.2=93.182.33.2
4. там же настраиваю vpn согласно параметрам от провайдера (vpnserver=192.168.0.17=192.168.0.200) и подключаюсь к живому интернету
5. на freebsd настраиваю (обычно тупо через sysinstall) сетевую карту, подключенный к хабу, в ту же самую сеть, только ip-адрес выбираю из свободных в настоящий момент в этой подсети, например, 10.107.94.211
6. поднимаем на freebsd FTP-сервер с доступом на запись, благо хоть он включен в начальную инсталляцию
7. проверяем возможность ftp-перекачки файлов из windows на freebsd

если файлы передаются, то - ура - можно приступать к основному:

8. на freebsd настраиваю статические маршруты на служебные серверы провайдера, я не пользуюсь тут defaultroute, чтобы не было проблем с его последующем переназначении при установке vpn-соединения -- у квидекса все vpn-серверы находятся в подсети 192.168.0/24; dns-сервера 93.182.32.2 и 93.182.33.2:
/etc/rc.conf

static_routes="kvx1 kvx2 kvx3"
route_kvx1="192.168.0/24 10.107.94.1"
route_kvx2="93.182.32.2 10.107.94.1"
route_kvx3="93.182.33.3 10.107.94.1"

9. запускаю сборку mpd из /usr/ports/net/mpd4 и смотрю какие файлы не находятся и куда их нужно подсунуть, скачиваю на windows машине с указанного http/ftp-адреса нужное файло и через ftp передаю их на freebsd и подкладываю в нужное место где-то в районе /usr/ports/distfiles, процесс повторяется пока все необходимые компоненты не будут всборе и сборка не завершится успешно, устанавливаем и настраиваем согласно параметрам от провайдера до успешного соединения и пингования например того же самого freebsd.org

10. собственно все, отсутствие vpn-клиента побороли, windows машина больше не нужна, и далее все собирать и устанавливать можно штатно на свежеустановленном соединении через собственный vpn-клиент (в моем случае mpd4)

11. далее нужно установить из портов /usr/ports/devel/cvsup-without-gui, настроить и обновить дерево портов
12. возможно, понадобится обновить ранее установленный vpn-клиент на более свежую версию из обновленных портов

Получил по почте La Crosse Technology BC-9009 AlphaPower Battery Charger
Купил на eBay, обошелся чуть меньше 2000 руб на пороге дома
Шел ровно 3 недели из Сакраменто, Калифорния, США
Сделан разумеется в Китае, о чем свидетельствует вполне честная надпись.

Предполагаемые направления использование:

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

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

при работе отмечены следующие неудобства

• отсутствие включаемой подсветки экрана
  
• неудобно вынимать 2ой и/или 3ий элементы, если продолжается обработка 1го и 4го

Показалось, что слабоват блок питания: если установить на всех четырех банках ток заряда 1000 ma, то яркость индикатора начинает меняться, т.е. блок питания дает заметную просадку по напряжению. Надеюсь, это никак не влияет на точность выполняемых замеров, хотя очень даже может.

Провел тренировку(refresh) для 4 шедших в комплекте "родных" аккумуляторов LaCrosse:

которые AAA 1000mah -- ну тысячей там и не пахло (764, 770, 789, 820). Тем не менее хочется отметить довольно высокую стабильность, расхождение по емкости оказались в пределах 10%. Получился вполне себе подобранный комплект

которые AA 2600mah -- 1930, 1980, 2000 и 2020 mah -- про 2600 наврали, но комплект все равно получился довольно ровный, разбег в пределах 5%


Фотки с eBay
[400x400]
[400x400]
[400x400]
[400x400]
[400x400]

А это уже на моем столе:
[690x460]

Приделал медиаплеер Xtreamer (aka v-duck a211) к висящему на стене телевизору, чтобы не было необходимости тыкать пультами в разные места - пульт от плеера имеет раздражающе узкую направленность ((((
теперь механически привычно тыкая в сторону надписи Samsung пультом от плеера попадаю куда надо

[690x460]
[690x460]

путем изготовления кронштейна из двух первых попавшихся скобок (наверное, мебельных)
верхнюю скобку через просверленное в ней отверстие прикрепил к установленному на родное место кронштейну от подставки
нижнюю скобку прикрепил к верхней через просверленные в обоих отверстия
[690x460]
[460x690]

Добрый человек shaluniaka разместил Тестовые картинки и видео для проверки телевизора на битые пиксели

..решил закинуть на файлообменник тестовые картинки для проверки на битые пиксели и настройки изображения!
Картинки взяты из тестовой профессиональной подборки и я ещё добавил коротенький видео-файл в MKV контейнере для проверки возможности его воспроизведения в полном HD разрешении 1080p , но с уменьшенным битрейтом до 9000 и 6-ти канальным звуком в AC3!
Может кому пригодится , что бы самому не делать!

ссылка на Depositfiles (http://depositfiles.com/files/7q90t46dr)
ссылка на Rapidshare (http://rapidshare.com/files/315589854/TEST.rar)

Построение точки доступа на основе моего маршрутизатора на FreeBSD

1. попал мне в руки wifi свисток D-Link DWA-140, а точнее два таких свистка

2. и решил я сделать у себя в хате wifi, практического смысла особо нет, зато есть предмет для $@ли

3. запихал я его в USB и посмотрел /var/log/messages

bsd kernel: ugen4.2: at usbus4
bsd root: Unknown USB device: vendor 0x07d1 product 0x3c09 bus uhub4

оказалось FreeBSD-8.0-R не поддерживает такое устройство

4. очередное изучение сайта FreeBSD показало, что поддержку устройств на чипах Ralink RT2700U/RT2800U/RT3000U соорудили в FreeBSD 8.1-RELEASE под именем run

5. изучение их SVN-репозитария показало, что последние на текущий момент исправления в драйвере /sys/dev/usb/wlan/if_run.c были сделаны 2011-01-20, поэтому было решено обновиться до 8.2-RELEASE, что собственно и было вполне успешно сделано, скачав это все svn'ом и выполнив постройку мира

6. понятно, что при построении нового ядра было вставлено device run; для изучения подробностей man run и man wlan будут вполне полезны

7. в /boot/loader.conf было добавлено

runfw_load="YES"

8. после перезагрузки и втыкания свистка /var/log/messages показал, что новое ядро успешно распознало его как run0:

bsd kernel: ugen4.2: at usbus4
bsd kernel: run0: <1.0> on usbus4
bsd kernel: run0: MAC/BBP RT2860 (rev 0x0103), RF RT2820 (MIMO 2T2R), address 00:21:91:99:14:58
bsd kernel: run0: firmware RT2870 loaded

9. создал /etc/hostapd.conf по многим примерам из интернета:

interface=wlan0
dump_file=/tmp/hostapd.dump
ctrl_interface=/var/run/hostapd
ctrl_interface_group=wheel
driver=bsd
debug=4
ssid=my_wifi
wpa=3
wpa_passphrase=PassWord
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP CCMP

10. для раздачи адресов в wifi с помощью DHCP в /usr/local/etc/dhcpd.conf вписал мою сетку:

subnet 192.168.11.0 netmask 255.255.255.0 {
........range 192.168.11.2 192.168.11.255;
........option broadcast-address 192.168.11.255;
........option domain-name-servers 192.168.11.1;
........option routers 192.168.11.1;
}

11. для доступности дисков через wifi на прочих устройствах приписал к /usr/local/etc/smb.conf:

interfaces 192.168.1.1/24 192.168.11.1/24

12. добавления в /etc/rc.conf по советам из инета:

wlans_run0="wlan0"
create_args_wlan0="wlanmode hostap ssid my_wifi mode 11g channel 7"
ifconfig_wlan0="inet 192.168.11.1 netmask 255.255.255.0 up"

hostapd_enable="YES"
dhcpd_enable="YES"
dhcpd_ifaces="wlan0"

обращаю внимание на up в конце ifconfig_wlan0=.... - без него не устанавливались адреса на интерфейс wlan0

13. в результате всего этого после перезагрузки ifconfig рассказывает следующее:

run0: flags=8843 metric 0 mtu 2290
........ether 00:21:91:99:14:58
........media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
........status: running
wlan0: flags=8843 metric 0 mtu 1500
........ether 00:21:91:99:14:58
........inet 192.168.11.1 netmask 0xffffff00 broadcast 192.168.11.255
........media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
........status: running
........ssid my_wifi channel 7 (2442 MHz 11g) bssid 00:21:91:99:14:58
........country US authmode WPA1+WPA2/802.11i privacy MIXED deftxkey 2
........TKIP 2:128-bit TKIP 3:128-bit txpower 0 scanvalid 60 protmode CTS wme
........dtimperiod 1 -dfs

14. при установке же D-Link DWA-140 в WindowsXP конкретно у меня возникли некие странности: стандартный виндовый менеджер беспроводных сетей ничего не показывал и как-то подглюкивал; возможно это из-за SP2 на всех домашних компах, т.к. на работе с SP3 все нормально

15. установка на винду ftp://ftp.dlink.com/Wireless/dwa140/Drivers/dwa140_drivers_130.zip исправила ситуацию и со свежеустановленным d-link'овским беспроводным менеджером все стало просто замечательно

попробовал настроить IPTV у своего провайдера Kvidex согласно инструкции для бесплатного тестирования, разумеется подключив напрямую комп с winxp к шнурку от провайдера

не пошло ((

на вопрос в службу поддержки спросили "подключаетесь напрямую или через роутер",
на что ответил: разумеется напрямую, файрволл отключил, и задал вопрос "а ваш маршрутизатор в моей подсети поддерживает IGMP?"

на что был получен смешной ответ "сервис находится в стадии тестирования", хотя из текста на страничке
tv.kvidex.ru этого не следует, а следует, что сервис находится во вполне даже коммерческой эксплуатации, даже вполне конкретные тарифы имеются, а протестировать услугу можно на специально организованном для этого бесплатном тестовом пакете, что я собственно и попытался сделать

страница Адреса предоставления услуги "Цифровое телевидение IP-TV" "находится в стадии заполнения"

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

зато могу точно обозначить условия, при которых я бы купил услугу:
- HD, 720p вполне бы устроили, но разумеется реальные, а не SD upscale, в формате же SD вполне имею 30+ каналов из обычной "публичной" антенны за около 100 рублей/мес
- качественное HD, а не пережатки, когда видны артефакты, как на дерьмовых jpg, т.е. видеопоток должен быть не менее 4500 кбит/сек для mpeg4 1280x720p, это поток на котором почти не заметно артефактов, разве что на быстрых сценах

попробовал Xtreamer он же v[duck] A211
довольно долго

недостатки:
- дохлая сетевая подсистема

как написал один толковый деятель на оригинальном форуме, встроенный в медиапроцессор RTD1283 сетевой контроллер обеспечивает скорость капельку больше 6 мбайт/сек
это физически
и это касается похоже всех медиапроцессоров realtek, хотя даже самая дешевая дискретная rtl8139 без проблем обеспечивает 10 мбайт/сек даже на торренте

в Xtreamer'e на уровне прикладных протоколов типа SMB все еще хуже ...

подключение по NFS-UDP в принципе выходит на указанные выше 6 мбайт/сек, однако возникают потери пакетов, видимые и слышимые при воспроизведении, что в принципе не приемлемо

подключение по NFS-TCP xtreamer отказался осуществлять, даже при регистрации nfs-ресурса через web-интерфейс с явным указанием опции tcp - tcpdump показывает, что данные все равно идут по udp со всеми последствиями (см.выше)

явное указание на nfs-сервере в хранилище обслуживать только tcp соединения приводит к полной невозможмости воспроизведения xtreamer'ом видео - он просто зависает ...

по SMB xtreamer в состоянии прокачать порядка 3.5-4 мбайт/сек, но зато без потерь, что дает максимальный поток 25-30 мбит/сек

что правда совсем не значит, что можно без каких-либо проблем воспроизводить фильмы с указанным общим битрейтом, тк обычно указывается средний битрейт для фильма, на быстрых сценах битрейт может превосходить средний раза в 2, а то и более

т.е. от xtreamer'a следует ожидать качественное вопспроизведение по сети фильмов в видеопотоком не более 10-13 мбит/сек (не забываем про аудио)

далее:
при подключении xtreamer'a к сети через hub/switch 1G (пробовал D-Link DGS 1005D и Netgear GS608) скорость падает до ~1 мбайта/сек: на старом ноуте с 100М сетевой картой такое лечится явной установкой режима "full-duplex 100mbit", на xtreamer'е провернуть такое не удалось


так что, если есть желание смотреть высокобитрейтное видео по сети, то xtreamer мало подходит, и имеет смысл посмотреть в сторону какого-нибудь устройства не на realtek, например, dune на старших чипах Sigma Designs

взял на днях попробовать v[duck] В 311, подробности на v-duck.ru и подключил его к своей сети

первое впечатление:

• ему катастрофически не хватает процессора для выполнения немультимедийных операций, в первую очередь на сетевые операции, скорость сети выше 31 Мбита не видел - по его же собственным показаниям
  
• изрядно сырое программное обеспечение -- так случилось, что сеть была занята перекачиванием большого объема данных с сервера-роутера на мой десктоп по 1Г каналу, при этом v-duck стал показывать скорость сети 500к-1М при проходе по списку файлов на сетевом ресурсе, при этом регулярно перегружался
  
• понятно что с цифровым интерфейсом hdmi проблем особых не возникло
  
• поскольку я когда обратил внимание на эту модель допускал возможность использовать его как некий мобильный вариант благодаря мелким размерам и наличию композитного видеовыхода, позволяющего подключать даже старые элт-телевизоры, что и решил проверить, подключение и настройка не вызвали проблем, однако не понравилось как делаются:
  -- pulldown - преобразование частот кадров, например 24p -> 50i (PAL), мой старенький двд с поддержкой mpeg4/divx/... справляется куда лучше: результат работы ви-дака очень напоминает просмотр фильма 24p на мониторе 60Hz,
  -- downscaling - преобразование HD разрешения в PAL/NTSC, причем чем больше исходное разрешение, тем результат на обычном телеке мне показалось неприятнее
  
• показались неудобными масштабные коеффициенты зума: 2, 3, 4, 8 -- я привык 1.2, 1.3, 1.5, 2, 2.5, 3, 3.5, 4, 1/2, 1/3, 1/4, как то больше вариантов, а вариант x8 показался вообще чрезмерным
  

полагаю, что при работе с внутреннего жесткого диска через hdmi проблем особых быть не должно

похожая ситуация с аналоговым сигналом была(есть) с телевизорами, когда эфирный сигнал смотреть просто невозможно

зачем, спрашивается, делать аналоговую часть, если она работает дерьмово

в общем, устройство меня не впечатлило

Походу, вся эта возня с переносом памятников, "воздвигнутых" в лужсковскую эпоху москвы, затеяна исключительно для отвлечения внимания

Новый московский мэр уж точно не меньший клоун по сравнению со старым

"Царствование" будет то еще ....

Могу только сказать, что в регионах беспредел тамошних "царьков-феодалов" еще ужаснее.
Однако это не так заметно в рамках всей страны, поскольку (порядок пунктов не принципиален, т.к. мне без разницы, что от чего зависит):

• москва это москва, и ее "царек" имеет вполне ощутимый вес общероссийского свойства
  
• объем денег просто несопоставим

В принципе я доволен моим домашним интернет-провайдером Квидекс.
Заявленные(оплачиваемые) технические параметры исполняются в полном объеме и цена за мой тариф Лайт: безлимит 8М-down/4M-up за 500 руб/мес вполне терпимая.

Есть забавный технический нюанс:

Все 3 диапазона приватных сетей (10/8, 172.16/12 и 192.168/16) заняты самим провайдером, включая, разумеется, самую популярную 192.168.0.0/24, причем под ключевые сервера, например VPN.

Что даже для специалиста добавляет немного головной боли при организации домашней локальной сети.

Автоматическое "разделение" внешнего VPN-подключения например под Windows XP во внутреннюю локальную сеть приведет к первоначальной выдаче в качестве диапазона адресов внутренней сети именно 192.168.0.0/24, что сразу сделает невозможным достучаться до VPN-сервера, находящегося в том же адресном сегменте, но на стороне провайдера. Понадобятся дополнительные настройки.

Что абсолютно вынесет "моск" неспециалисту при необходимости подключить второй компьютер к инету.

Подозреваю,
что сделано это намеренно, чтобы брать с явных неспециалистов дополнительные деньги либо за дополнительный провод и контракт соответственно либо за очень "хитроумную" настройку сетевого хозяйства специалистом Квидекса.

Мой домашний провайдер Квидекс предоставляет своим клиентам (в том числе и мне) неявную и бесплатную услугу т.н. пиринга (peering), позволяющего получить доступ к сетям других провайдеров Москвы и окрестностей через "локальную" сеть. Точнее было бы сказать: без ограничения скорости согласно тарифному плану.

Что в принципе удобно, например, мой торрент клиент в большинстве случаев скачивает(и отдает) файлы на скорости 9-10 мбайт/сек, т.е. шнурок в 100Мбит, заходящий в мою квартиру, используется по-полной. Это хорошо.

Жаль в Корбину нет "прямых" маршрутов ((((

Однако, чтобы все это работало, необходимо выполнить некий набор телодвижений, описанный здесь (ссылка доступна только из внутренней сети Квидекса, т.к. ее IP=192.168.0.31)

Суть телодвижений сводится к тому, что необходимо на компьютере, подключенному к Квидексу, прописать дополнительные статические маршруты на эти самые сети других провайдеров. Квидекс предоставляет своим клиентам некий набор автоматических средств, предназначенных для операционных систем Microsoft (ссылка доступна только из внутренней сети Квидекса).

Также присутствует регулярно обновляемый полный список пиринговых сетей (ссылка доступна только из внутренней сети Квидекса).
Это текстовый файл, 1 строка = 1 описание сети в формате АДРЕС/МАСКА, например

# Tue Sep 28 10:55:03 2010
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
93.182.0.0/18
62.62.85.0/20
....

что легко обрабатывается скриптами на моей FreeBSD, и преобразуется в набор соответствующих команд "route add/del ....", причем у меня скрипт запускается регулярно каждые 3 часа, дабы поддерживать таблицу маршрутизации в актуальном состоянии, удаляя маршруты для исключенных сетей и добавляя для свежепоявившихся.

Есть маленькая особенность в этом файле: он не оптимален.
Например, на момент написания список содержит 358 (!) сетей, часть из которых является:

• подсетями в более крупных, например
  

  89.222.192.0/24
  89.222.192.0/21

  т.е. сеть 89.222.192.0/24 можно спокойно удалить
  
  
• соседними, например
  

  89.222.176.0/24
  89.222.177.0/24

  которые можно объединить в одну более крупную 89.222.176.0/23 и просто удалить эти две мелкие исходные

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

В результате чего список дополнительных маршрутов уменьшился до 243. Неплохо.

сменил ftp-сервер
поставил Pure-FTPd, т.к. он поддерживает RFC-2640 - Internationalization of the File Transfer Protocol для человеческой поддержки русского языка, хотя штатный ftpd от FreeBSD тоже поддерживает UTF-8, но мне показалось криво

Pure-FTPd имеет явные настройки:
а) в какой кодировке хранятся имена в файловой системе
б) в какой кодировке общаться с ftp-клиентом, не поддерживающим RFC-2640

это важно, т.к. файловая система у меня использует UTF-8, а в Рунете подавляющая часть ftp-клиентов (под Windows, разумеется) без поддержки RFC-2640 по умолчанию могут сразу правильно отобразить русские имена файлов, если они поступают в кодировке 1251, что я и указал в настройках Pure-FTPd

по хорошему, ftp-клиент должен поступать примерно также при работе с ftp-сервером без RFC-2640 - cчитать, что имена файлов поступают в некой дефолтной или явно указанной кодировке

но все оказалось гораздо хуже: самые распространенные ftp-клиенты не поддерживают RFC-2640:

• Midnight Commander
  
• Far Manager
  
• Mozilla Firefox при обработке URL вида ftp://ftp.server.com, причем задание на реализацию стоит с февраля 2000 года, вот вам и хваленый фф
  
• Microsoft Internet Explorer при обработке URL вида ftp://ftp.server.com
  
• Squid при получении от браузера запросов на URL вида ftp://ftp.server.com

жопа, однако
особенно если учесть что RFC-2640 далеко не самый сложный

поставил Samba без каких-либо наворотов

задача крайне тупая:
отдавать в windows-сеть то, что накачает deluge

поэтому просто share режим

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

socket options = TCP_NODELAY SO_RCVBUF=524288 SO_SNDBUF=524288

на моем пока 100Mbit из-за D-Link DES-1005D ethernet стабильно держит ~10 мбайт/сек, что важно для воспроизведения контента непосредственно по сети

потом как-нибудь надо будет прикупить DGS-1005D/GE, и выполнить тюнинг повторно уже на 1G

поставил deluge 1.3.0.rc_1

сборка из исходников проблем не вызвала

cd /usr/ports/net-p2p/deluge
make install clean

по функциям и удобству капельку уступает uTorrent, но вполне даже можно пользоваться

из неприятного для меня:

1) программа заточена в первую очередь для юзеровского интерактивного применения в графическом интерфейсе, из-за чего

2) начальная настройка вызвала некоторые трудности без графической среды, т.к. стартовые настройки выполняет некий графический мастер, без которого мне пришлось повозиться, короче запустить его с наскоку не получилось, но руками все раскидал по нужным местам, в итоге и сам deluged и deluge-web (демон веб-интерфейса) завелись успешно

2.1) советую ДО первого запуска deluged добавить пользователя для него (deluge, delugeuser, ...) с возможностью входа, войти в систему под этим именем, и под этим именем запустить первый раз deluged, этот зверь сам создаст каталоги/файлы где надо,

3) очень странно, но при работе deluge-web потребляет значительно больше процессора, чем собственно deluged, видимо из-за свой питоности (написана на python)

4) клиентская часть web-интерфейса (выполняемая в браузере) также весьма тормознутая, то-ли сама по себе, то-ли из-за deluge-web, суммарное субъективное впечатление о веб-интерфейсе : "гораздо тормознутее чем веб-интерфейс uTorrentа"

5) скачивание файлов происходит может быть совсем чуть-чуть медленнее uTorrent'а, подозреваю из-за отсутствия в deluge протокола uTP, и как следствие, значительный служебный трафик, но все равно это не в разы, а какие-то проценты, меня вполне устраивает

6) deluge-console оказался глюковат на первый момент

/etc/host.conf

hosts
dns

для выяснения имен/адресов компютеров (т.н. ресолвинга) вначале просматривать /etc/hosts, затем, в случае неудачи -- делать обращение к dns-серверу


/etc/hosts

#local
127.0.0.1 localhost

# static ethernet
192.0.2.1 bsd.mynet bsd
192.0.2.2 win.mynet win
192.0.2.3 note.mynet note
192.0.2.4 dune.mynet dune

# dhcp ethernet
192.0.2.65 dhcp65.mynet dhcp65
192.0.2.66 dhcp66.mynet dhcp66

# dhcp wifi
192.0.2.129 wifi129.mynet wifi129
192.0.2.130 wifi130.mynet wifi130

поскольку не планирую заводить свою локальную dns-зону, делаем тупо статику, уж если нужно сильно будет, то dhcpXX и wifiXX в необходимом количестве допишу руками


/etc/resolv.conf

nameserver 93.182.32.2
nameserver 93.182.33.2

это пока не поднял свой dns-прокси (обычный bind с включенным форвардом и кэшем)

Используемые обозначения:
шестиугольники (синий) - статическая часть от провайдера
квадраты (красный) - динамическая часть от провайдера
овалы (черный) - домашная сетка

/etc/rc.conf

ifconfig_rl0="inet 10.108.99.37 netmask 255.255.255.0" # внешний интерфейс (на схеме ## 9, 13)
ifconfig_re0="inet 192.0.2.1 netmask 255.255.255.128" # моя локалка (на схеме ##12, 14)

# прямые маршруты к служебным машинам провайдера, необходимы для запуска
kvidex_router="10.108.99.1" # отдельный шлюз на провайдера (на схеме #7)
static_routes="dns1 dns2 pptp l2tp rtrs"
route_dns1="-host 93.182.32.2/32 ${kvidex_router}" # 1-ый dns-сервер (на схеме #5)
route_dns2="-host 93.182.33.2/32 ${kvidex_router}" # 2-ой dns-сервер (на схеме #5)
route_pptp="-host 192.168.0.17/32 ${kvidex_router}" # pptp-сервер (на схеме #4)
route_l2tp="-host 192.168.0.200/32 ${kvidex_router}" # l2tp-сервер (на схеме #4)
route_rtrs="-host 192.168.0.31/32 ${kvidex_router}" # сервер с актуальным перечнем пиринговых сетей (на схеме не указан)

этого минимально достаточно для запуска vpn-соединения в большой интернет, причем шлюз (на схеме #6), defaultrouter в терминах /etc/rc.conf, вставит mpd самостоятельно при установлении соединения (при соответствующих настройках)

но совершенно недостаточно для доступа к ресурсам локальной и особенно пиринговых сетей из моей локальной сети: нужно организовывать 2 nata: 1-ый в сеть провайдера/пиринга (на cхеме ##3,2) через ethernet-интерфейс 10.108.99.37 (на схеме #9); 2-ой -- в большой интернет (на схеме #1) через vpn-соедиение (на схеме #8)

[691x501]

реальную, но которую я решил использовать для домашнего использования
не скажу, что я очень в восторге от этой ситуации
но чтение RFC 3330 радости добавило не сильно
получается, что в моей ситуации вполне "легально" можно использовать только сеть 192.0.2.0/24

пока еще не нафигачил настроек, туда и переплывем, хуже точно не будет

еще раз про UserGate Proxy & Firewall

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

используемая временная конфигурация сети (в постоянной win и bsd должны поменяться местами):
[690x690]

комментарии:

зеленое - ethernet провайдера
красное - vpn(l2tp), интерфейс в "реальный" интернет
синее - моя домашняя сетка

т.е. машина с windows xp + usergate работают как роутер
на usergate включены dns форвардинг
и прописано единственное правило nat из локалки через vpn для icmp,tcp,udp

на bsd соответственно настройки

/etc/rc.conf

...
ifconfig_re0="inet 1.1.1.1 netmask 255.255.255.0"
defaultrouter="1.1.1.2"
...

/etc/resolv.conf

...
nameserver 1.1.1.2

положительные моменты:
- заработало разрешение внешних имен (nslookup, host, ....)
- ping реально пингует
- ftp выполняет соединение к внешним серверам, авторизует, даже передает содержимое маленьких каталогов (буквально несколько файлов), причем поведение одинаковое для различных ftp-клентов: оригинальный ftp; встроенный ftp-клиент в mc; fetch
- cvsup тоже выполняет соединение с сервером, показывает инфу, но умирает в недрах жесткого тайм-аута

bsd# cvsup -g -L2 ports-supfile
Parsing supfile "ports-supfile"
Connecting to cvsup7.ru.FreeBSD.org
Connected to cvsup7.ru.FreeBSD.org
Server software version: SNAP_16_1h
Negotiating file attribute support
Exchanging collection information
Establishing multiplexed-mode data connection
Running

замеченные сходу недостатки:
1) ни по одному из протоколов не передаются большие объемы данных -- на глазок, не более нескольких десятков байт
2) traceroute не трейсит внешние хосты
3) почему-то на самой винде с установленным usergate браузер firefox перестал делать https на mail.google.com, хотя обычный http на другие сервера вполне нормально
4) почему-то с виндовой машины не смог погулять по инету через http-прокси от usergate

вывод:
хочешь проверить качество "прокси" - поставь в локальной сети какой-нибудь юникс и посмотри, насколько качественно и через какие конфигурации он сможет ходить в инет (как клиентская машина)

инфо 1:
FreeBSD-6.х-i386, установленная на старом жестком диске успешно запустилась после некоторой возни с тем, что в предыдущем месте этот диск распознавался как ad0, и fstab имел соответствующие записи, а на плате GIGABYTE GA-D510UD (мастер на IDE) он распознался как ad8

засада 1:
- после ~3 лет просто-напросто забыл рутовый пароль, поэтому все равно менять систему
- да и наверно имеет смысл на 64-бит архитектуре запускать 64-бит софт

засада 2:
- мой веселый провайдер Квидекс занял под свои нужды все три приватные сети согласно RFC1918, но поскольку мне необходим доступ к ресурсам сети провайдера, то надо думать, что использовать взамен
- легкие изыскания показали, что сеть 1.1.1.0/24 пока вполне применима для домашнего использования: на момент 2010-06-30 принадлежит какому-то австралийскому дядьке для "тестовых работ"
- организовал сетку так: 1.1.1.1=bsd (будущий рутер с freebsd), 1.1.1.2=win(детская винда), 1.1.1.3=note(мой ноут), с соответствующей записью в /etc/hosts, соответственно /etc/host.conf и nsswitch.conf имеют порядок hosts(files), dns

засада 3:
- FreeBSD-8.0R-amd64 на диске почему-то не имела пакетов для pptp и/или l2tp, никаких и совсем
- выход=качать
- а как качать, если провайдер дает выход в большой инет только через pptp/l2tp
- причем зеркала FreeBSD в его локалке нет, в отличии от Корбины с доступным из ее локалки официальным зеркалом ftp://ftp4.ru.FreeBSD.org

засада 4:
- выяснилось, что организовать мало-мальски приличный рутер c NAT и DNS-форвардом из винды несколько проблематично
- убив кучу времени на опробование всяких программных "прокси" для XP, самым "правильным" для моей задачи нашел UserGate Proxy & Firewall, который нормально организовал кэширующий DNS и полный (ICMP, UDP, TCP) NAT из моей локальной сети в большой инет через VPN-соединение Квидекса
- "ping google.com" на FreeBSD сразу дал верный результат: ресолв имени и собственно пинг

засада 5:
- UserGate Proxy & Firewall оказался изрядно кривым: по ftp отказался передавать большие объемы данных, даже список файлов из каталога, если файлов там больше чем 1-2 штуки, не говоря уже о собственно файлах
- причину я так и не понял, хотя UserGate давал вполне достаточный 30-дневный триал


засаду 5 обошел руками: когда fetch при сборке пакета затыкался на скачивании очередного требуемого куска, просто скачивал нужный файл через винду и через поднятый фтп подсовывал его в нужное место в /usr/ports/distfiles

в результате mpd все-таки собрать удалось, а за одно и mc для удобства