Спутниковый интернет: установка и настройка SkyStar1 и SkyStar2 под Linux

Эта статья описывает настройку спутникового интернет под Linux на базе карт SkyStar 1 и SkyStar 2
Надо думать, что настройка SkyStar 3 (так называемая «бюджетная карта») и SkyStar 1 CI (с CI-слотом «на борту») будет мало отличаться от двух предыдущих вариантов.

Спутниковый интернет на SkyStar1 и SkyStar2 под Linux

Содержание

Предисловие

Для чего или для кого, взялся писать этот дайджест? Да ни для чего. Чтобы не забыть. Ну и ни для кого, разумеется. Для себя, разве что.
Чтобы при переустановке не разыскивать снова разрозненные описания и компоненты программного обеспечения, не выискивать заметки в сети, пытаясь в очередной раз составить из ста зайцев одну целую лошадь.
Статья сделана откровенно в «детском» стиле — делай раз, делай два. Сам я Linux знаю плохо, потому старался сделать всё нарочито подробно. Буду рад любым комментариям, дополнениям, исправлениям. Всё слать на yevstigneyevda@mail.ru
Предполагается, что Вы уже закрепили и настроили антенну, сигнал принимается более чем прекрасно. Если же нет, то очень настоятельно рекомендую почитать статью «Установка и настройка спутниковой антенны»[13]. Лучше и не напишешь!
Писался этот дайджест (а это именно дайджест, обзор. Т.е., ничего нового в нём нет — всё это сборная солянка с кучей ссылок) нарочито подробно, так чтобы человек также плохо знающий Linux, как и я, смог бы «поднять» сетевое подключение хотя бы за пару часов.

1. Подготовка

Подготовка к работе всегда занимает времени больше, чем сама работа
© Народная мудрость
Самый простой на мой взгляд путь — это работать с ветвью ядра версии 2.6.xx. На данный момент на сайте kernel.org[19] доступная версия 2.6.18.6. Насколько я понял, начиная с версии 2.6.11, благодаря стараниям NuclearCat встроенные в ядро драйвера DVB–карт SkyStar 11 и SkyStar 2 прекрасно работают.

1.1 SkyStar 1. Linux kernel v2.6.1x.x

Итак, если Вы подробнейшим образом ознакомились со статьёй Алексея Силякова «DVB–карта SkyStar–1, релиз 1.5. Technotrend. Работа над ошибками.»[1], очаровались сервисами, предоставляемыми этой картой и стали её счастливейшим обладателем (за какие-нибудь 190$-200$) то лучше ничего и придумать нельзя, как использовать её в среде #nix. Она вполне работоспособна как под FreeBSD, так и в среде Linux
Сейчас мы устанавливаем карточку SkyStar 1 под Linux, с ядром версии не ниже 2.6.11. Сам я экспериментировал с ядром 2.6.18-r2.
Должен Вас предупредить, что карта эта — весьма капризная особа и к ней, как минимум понадобится дополнительный охладитель. Впрочем, это отдельная история и о ней можно подробно почитать в статье Николая Штермеля «Охлаждение SkyStar 1»
В файл конфигурации надо доабавить следующие опции ([m] — в виде модуля, [y] — собрать вместе с ядром):
# # Digital Video Broadcasting Devices # DVB=[y] CONFIG_DVB=[y] CONFIG_DVB_CORE=[m|y] CONFIG_DVB_VES1X93=[m|y] CONFIG_DVB_AV7110=[m|y] CONFIG_DVB_AV7110_OSD=[y] CONFIG_VIDEO_SAA7146=[m|y] CONFIG_VIDEO_SAA7146_VV=[m|y] CONFIG_VIDEO_VIDEOBUF=[m|y] CONFIG_VIDEO_TUNER=[m|y] CONFIG_VIDEO_BUF=[m|y] CONFIG_VIDEO_BTCX=[m|y] CONFIG_VIDEO_IR=[m|y]

 

Хотелось бы напомнить почтеннейшим гражданам Публике, что подробно информацию о конфигурации ядра стоит почитать либо в прилагаемом к ядру же пакету документации, либо на сайте TLDP, либо, того лучше заглянуть в замечательную русскоязычную статью Алексея Федорчука «Ядро Linux: опции конфигурирования»[18]
После сборки должен получится следующий набор модулей[2]:
dvb-ttpci
Основной драйвер полнофункциональных карт, основанных на чипсете AV7110.
videodev
Модуль ядра Video4Linux. Это основной модуль, предоставляющий доступ к аналоговой «картинке» mpeg2-декодера av7110.
v4l2-common
Модуль вспомогательных функций драйверов Video4Linux-2.
v4l1-compat
Модуль вспомогательных функций для обратной совместимости приложений, использующих Video4Linux-1.
dvb-core
Модуль ядра DVB. Обеспечивает поддержку работы с утройствами каталога /dev/dvb/adapter/
saa7146
Ядро драйвера SAA7146. Необходим для работы со всеми устройствами, основанными на чипсете saa7146.
saa7146_vv
Поддержка функций Видео и Виртуальных Двоичных Интерфейсов (VBI — Video Binary Interface). Этот модуль необходим только для работы с полнофункциональными DVB-картами.
video-buf
Вспомогательный модуль saa7146 для захвата видеопотока. Модуль для захвата видеопотока.
dvb-ttpci
Основной драйвер карт основанных на AV7110 и полнофункциональных DVB-S/C/T
Подгружать модули в память и перезагружаться с обновлённым ядром пока рановато. Вряд-ли dvb-ttpci загрузится без необходимых программных средств — firmware. Этот файл будет загружаться непосредственно в исполнительное устройство карты, примерно также, как подгружаются firmware-файлы в софтварные модемы. Так, что необходимо в зависимости от версии карты загрузить с сайта LinuxTV необходимый файл:
  Name Last Modified Size
Parent Directory 09-Jun-2005 19:52
dvb-ttpci-01.fw-261a 14-Nov-2004 00:48 221k
dvb-ttpci-01.fw-261b 14-Nov-2004 00:48 221k
dvb-ttpci-01.fw-261c 14-Nov-2004 00:48 221k
dvb-ttpci-01.fw-261d 26-Dec-2004 01:02 227k
dvb-ttpci-01.fw-261f 06-Jul-2005 00:44 229k
А можно нигде эти файлы не искать и загрузить нужный файл при помощи скрипта, находящегося в документации, прилагающейся к исходному коду ядра — Documents/dvb/get_dvb_firmware
Нужный файл надо переименовать в dvb-ttpci-01.fw и положить в папку /lib/firmware. (Расположение этой директории, как правило определяется переменной FIRMWARE_DIR в файле /etc/hotplug/firmware.agent.)
Если карта установлена в компьютер, то можно попытаться всё это загрузить: modprobe dvb_core dvb_shutdown_timeout=0 dvb_net_debug=1 и dvb-ttpci videodev v4l2-common v4l1-compat saa7146 saa7146_vv video-buf dvb-ttpci.
Обратите внимание на параметр, передаваемый при загрузке модуля dvb_coredvb_shutdown_timeout=0. Дело в том, что карты SkyStar 1 и SkyStar 2 для защиты от перегрева при отсутствии нагрузки выключаются и теряют связь. Как сообщается в /usr/src/linux/Documentation/dvb/faq.txt по умолчанию этот параметр установлен на пять секунд, причём карта выключается через это время вне зависимости от того, нагружена она или нет. Если установить этот параметр в 0, то это будет значить, что карта не будет выключаться никогда [2] Это-то нам и нужно!
В Gentoo можно прописать dvb-core dvb_shutdown_timeout=1 в файле /etc/modules.autoload.d/kernel-2.6.
Также незатейливо можно в параметрах загрузки ядра указать через точку имя модуля и необходимый параметр. К примеру, в загрузчике Grub данную процедуру можно оформить как-то так:
/title Gentoo Linux (x86-2.6.19-gentoo-r2) /root (hd0,0) /kernel kernel-genkernel-x86-2.6.19-gentoo-r2 root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sda1 dosci dvb_core.dvb_shutdown_timeout=0 /initrd initramfs-genkernel-x86-2.6.19-gentoo-r2 / 

 

(желающие поподробнее узнать о настройке в Mandriva могут заглянуть, скажем на страничку Российского Мандрива-Клуба)
Увы: в новых ядрах (начиная эдак, с 2.6.18) ни один из вышеуказанных методов, увы не работает. Посему, всяк почитающий себя линуксоидом непременно цитирует ./usr/src/linux/Documentation/. В частности, в файле /usr/src/linux/Documentation/kernel-parameters.txt указывается на возможность иницализирования параметров ядра, непосредственно в каталоге /proc:
This document may not be entirely up to date and comprehensive. The  "modinfo -p ${modulename}" shows a current list of all parameters of a loadable module. Loadable modules, after being loaded into the running kernel, also reveal their parameters in /sys/module/${modulename}/parameters/. Some of these parameters may be changed at runtime by the  "echo -n ${value} > /sys/module/${modulename}/parameters/${parm}".

 

Таким образом, можно напечатать руками в командной строке, а можно в инициализирующий скрипт dvb-интерфейса, дописать следующую строку:
echo -n 0 > /proc/sys/net/ipv4/conf/dvb0_0/rp_filter

Если всё прошло успешно, то dmesg | less должен показать примерно такую распечатку:
dvb-ttpci: gpioirq unknown type=0 len=0 dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 8000261d dvb-ttpci: firmware @ card 0 supports CI link layer interface dvb-ttpci: Crystal audio DAC @ card 0 detected saa7146_vv: saa7146 (0): registered device video0 [v4l2] DVB: registering frontend 0 (ST ST  V0299 DVB-S)... dvb-ttpci: found av7110-0. 

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

1.2 SkyStar 1, Linux, Ядро 2.4.xx

Для меня, как для человека знакомого с Linux весьма поверхностно, существование двух вполне пополуярных веток ядер было и остаётся загадкой. Быть может, подразумеваеются ветви Stable, Current и Release? Или нечто подобное тому, как до сих пор довольно популярно использование FreeBSD v4.11? Точно не знаю.
Так или иначе, но мне пришлось проэкспериментировать с ядром 2.4.31.
В отличие от ядра 2.6.xx.x в нём драйверов для карт SkyStar 1 и SkyStar 2 нет. Драйвера придётся загрузить с опять-таки с сайта LinuxTV. На данный момент это — linuxtv-dvb-1.1.1.tar.bz2[327K]. Правда, во многих местах в сети, в частности в статьте, размещённой на сайте General Satellite «Программное обеспечение под Linux 2.4»[3], утверждается, что эти драйвера для работы с интернет не годятся — всё нормально загружается, но спутник не «лочится». У меня, правда, всё заработало. Возможно, что информация просто устарела.
Во всяком случае, в большинстве сетевых заметок, настоятельно рекомендуется взять альтернативные драйвера от Дениса Федорищенко (NuclearCat)[5] — ss1linux-rc5.tar.gz[1.8M].
В сети есть немало статей, посвящённых установке и настройке DVB-драйверов в под ядром Linux v2.4.xx.x, в частности, например, статьи Сергея Мазенкова «Как запустить интернет через DVB-S (–S — означает Satспутник, спутниковое подключение. Различают ещё также, DVB–C и DVB-T — эфирное и наземное (Terrastrial) подключение по кабелю) под Linux 2.4»[4], Сергея Ткачова «Digital Video Broadcasting или как заставить работать TechniSat SkyStar-1 под Linux»[6] или «Установка спутникового Internet под Linux»[7]
Все эти руководства, кроме последнего, предлагают устанавливать dvbds-2, dvbd3. Желательно созданный Andrix’ом[8]. Даже в знаменитом Sat-HOWTO[10] предлагается использовать этот путь. Правда, даже пробовать этот вариант не стал: во-первых сразу отпугнула фраза в Readme2, а во-вторых, для полноценной компиляции и установки dvbd необходимо загрузить и установить драйвер siemens_dvb-0.8.2.tar.gz именно данной версии. Это может означать только одно: данная ветвь уже давно умерла и никем больше не поддерживается.
Вообще, как мне кажется, данная концепция на сей день несколько устарела. Так что мы, почтеннейшие граждане Публика, остановим наше внимание на драйверах, ставших «штатными» в ядре Linux: linuxtv-dvb-1.1.1.tar.bz2 от LinuxTV.
Порядок установки вполне соответствует декларированному в прилагаемом README-файле. Нужно только не забыть скачать firmware (в моём случае это файл dvb-ttpci-01.fw-261d) «Раскручиваем» куда-нибудь полученный исходник: tar -jxvf linuxtv-dvb-1.1.1.tar.bz2, заходим в получившуюся директорию linuxtv-1.1.1. Файл firmware помещаем в поддиректорию build-2.4, переименовав его в dvb-ttpci-01.fw.
Не стоит забывать, что надо сделать ссылку /usr/src/linux из того места, где находятся исходные годы Вашего ядра. В моём случае это выглядело так: ln -sf /usr/src/linux-2.4.31 /usr/src/linux.
Теперь можно запустить (прямо из linuxtv-1.1.1/build-2.4 make.
Изменим в файле linuxtv-1.1.1/build-2.4:
# DVB core    insmod ./dvb-core.o

на
# DVB core         insmod ./dvb-core.o dvb_shutdown_timeout=0

Это, опять таки, необходимо, чтобы карта при отсутствии каких-либо действий, самопроизвольно не выключилась. Если загрузка модулей прошла удачно, то следующей командой должна быть ./insmod.sh load (её следует запускать только из linuxtv-1.1.1/build-2.4)
Если lsmod покажет что-то вроде этого:
dvb-core               39616   0  [ttusb_dec dvb-ttusb-budget dvb-ttpci mt312 cx24110 grundig_29504-491 grundig_29504-401 tda1004x ves1820 stv0299 alps_tdmb7 alps_tdlb7 ves1x93] 

К моему удивлению, dmesg | less наличия dvb-ttpci устройства не показал, но карта работала! Впрочем, об этом будем говорить несколько позже. На данный момент dmesg выдал следующее:
Linux video capture interface: v1.00 saa7146: register extension 'dvb'. PCI: Found IRQ 5 for device 00:09.0 saa7146_core: found saa7146 @ mem d09f4000 (revision 1, irq 5) (0x13c2,0x0000). DVB: registering new adapter (Siemens/Technotrend/Hauppauge PCI rev1.3). probe_tuner: try to attach to Siemens/Technotrend/Hauppauge PCI rev1.3 stv0299.c: setup for tuner BSRU6, TDQB-S00x DVB: registering frontend 0:0 (STV0299/TSA5059/SL1935 based)... Siemens/Technotrend/Hauppauge PCI rev1.3 adapter 0 has MAC addr = 00:d0:5c:03:8b:14 DVB: AV7110(0) - firm f0240009, rtsl b0250018, vid 71010068, app 8000261b DVB: AV7110(0) - firmware supports CI link layer interface av7110(0): Crystal audio DAC detected saa7146_fops: saa7146 (0): registered device video0 [v4l2] av7110: found av7110-0. saa7146: register extension 'budget dvb'. saa7146: register extension 'budget_ci dvb'. saa7146: register extension 'budget dvb /w video in'.

Если нас всё устраивает, то можно зайти в linuxtv-1.1.1 и набрать make install и настроить автоматическую загрузку модулей при запуске системы, на забыв про dvb-core dvb_shutdown_timeout=0

1.3. SkyStar 2, Linux kernel v2.6.xx.x

Теперь попробуем установить SkyStar 2. Пожалуй, самое толковое руководство по этому вопросу сделано NuclearCat — «Руководство по установке SkyStar2 под Linux 2.4»[9].Это вполне понятно — кто лучше автора расскажет о том, как оно всё работает. И даже не важно, что оно сделано для ядра 2.4 — для ядер ветки 2.6.xx.x технология будет почти такой же, за исключением того, что с сайта LinuxTV нам ничего загружать не придётся. «Родные» драйвера ядра вполне работоспособны. Таким образом, нам осталось добавить в /usr/src/linux/.config следующие настройки:
# # Digital Video Broadcasting Devices # CONFIG_DVB=y CONFIG_DVB_CORE=m # # Supported FlexCopII (B2C2) Adapters # CONFIG_DVB_B2C2_FLEXCOP=m CONFIG_DVB_B2C2_FLEXCOP_PCI=m CONFIG_DVB_B2C2_FLEXCOP_USB=m # CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set CONFIG_DVB_B2C2_SKYSTAR=m # # DVB-S (satellite) frontends # CONFIG_DVB_STV0299=m CONFIG_DVB_MT312=m 

Ну чтож, теперь наберём в директории cd /usr/src/linux/ && make mrproper && make modules && make modules_install. Модули готовы.
Понадобится нам всего три из них: dvb-core, stv0299, skystar2. Как и в случае со SkyStar 1 при загрузке модуля dvb-core следует загружать с параметрами dvb_shutdown_timeout=0. В противном случае, сигнала Вы просто не увидите!
Итак: modprobe dvb-core dvb_shutdown_timeout=0 dvb_net_debug=1 && modprobe stv0299 && modprobe b2c2_flexcop_pci && modprobe b2c2_flexcop && modprobe stv0299. dmesg должен показать следующее (если вы не переопределили MAC-адрес своей карты при помощи ifconfig, то он должен соответсвовать MAC-адресу написанному на Вашей карте):
b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully flexcop-pci: will use the HW PID filter. flexcop-pci: card revision 2 ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10 DVB: registering new adapter (FlexCop Digital TV device). b2c2-flexcop: MAC address = 00:d0:d7:0c:d0:0d PM: Adding info for No Bus:i2c-1 b2c2-flexcop: found the stv0299 at i2c address: 0x68 DVB: registering frontend 0 (ST STV0299 DVB-S)... b2c2-flexcop: initialization of "Sky2PC/SkyStar 2 DVB-S" at the "PCI" bus controlled by a "FlexCopIIb" complete

Если Вы видите что-то подобное у себя, значит драйвера установлены вполне удачно.

1.4. SkyStar 2, Linux v2.4.xx

Процесс установки под ядром 2.4.xx почти идентичен установке под 2.6.xx, за исключением того, что нам придётся взять драйвера linuxtv-dvb-1.1.1.tar.bz2 с LinuxTV или «родные» драйвера от NuclearCat — linuxtv-dvb-1.1.1a.tar.bz2.
Как и в случае с картой SkyStar 2, нам понадобится «раскрутить» драйвера в какую-нибудь директорию: tar -jxvf linuxtv-dvb-1.1.1.tar.bz2, зайти в полученную папку и набрать make. Не будем, также, забывать, что в /usr/src/linux должен находится исходный код ядра Linux.
Если процесс компилляции прошёл удачно, заходим в linuxtv-1.1.1/build-2.4 и загружаем модули: ./insmod.sh load. dmesg должен показать что-то вроде:
Linux video capture interface: v1.00 saa7146: register extension 'dvb'. saa7146: register extension 'budget dvb'. saa7146: register extension 'budget_ci dvb'. saa7146: register extension 'budget dvb /w video in'. usb.c: registered new driver Technotrend/Hauppauge USB-Nova usb.c: registered new driver ttusb-dec PCI: Found IRQ 5 for device 00:09.0 skystar2.c: FlexCopIIB(rev.195) chip found skystar2.c: the chip has 38 hardware filters DVB: registering new adapter (Technisat SkyStar2 driver). probe_tuner: try to attach to Technisat SkyStar2 driver stv0299.c: setup for tuner Samsung TBMU24112IMB DVB: registering frontend 0:0 (STV0299/TSA5059/SL1935 based)... 

Если всё выглядит так, то считаем установку удачной и можем позволить себе запустить cd linuxtv-1.1.1 && make install и прописываем автозагрузку модулей при запуске системы.

2. Сетевой интерфейс

— А теперь, дорогие товарищи пассажиры, пристегнитесь. Мы попытаемся вместе со всей этой фигнёй взлететь.
© Из анекдота
Остальные действия от версии ядра почти не зависят, так что дальше разбиения на разделы 2.4 и 2.6 не будет. Также будет почти сходна настройка карт SkyStar 1 и SkyStar 2.
 
Итак, если у Вас не установлена devfs, то Вам придётся создать соответсвующие интерфейсы. Лучше всего это сделать при помощи скрипта, предлагаемого NuclearCat в заметке «Руководство по установке SkyStar2 под Linux 2.4.». Почему-то в драйверах linuxtv-1.1.1.tar.bz2 скрипт так и неисправлен, так что копируйте его у NuclearCat и запускайте: ./makedev-dvb.sh. Впрочем, думаю, что лучше использовать devfs.
Теперь настаёт достаточно сложный и ответственный момент: нам предстоит настроить карту на приём информации. Для этого понадобится набор утилит linuxtv-dvb-apps-1.1.0.tar.bz2, всё с того же сайта LinuxTV. Если мы под ядром 2.4.xx.x, то всё в порядке — просто распаковываем поставку, заходим в получившуюся директорию linuxtv-dvb-apps-1.1.0 набираем make, если же ядро 2.6.xx.x, то нужно зайти в директорию linuxtv-dvb-apps-1.1.0/util/ и набрать make. После компилляции, получившиеся файлы:
linuxtv-dvb-apps-1.1.0/utils/av7110_loadkeys/evtest
linuxtv-dvb-apps-1.1.0/utils/av7110_loadkesy/av7110_evtest
linuxtv-dvb-apps-1.1.0/utils/dvbdate/dvbdate
linuxtv-dvb-apps-1.1.0/utils/dvbnet/dvbnet
linuxtv-dvb-apps-1.1.0/utils/dvbtraffic
linuxtv-dvb-apps-1.1.0/utils/scan/dvb-c
linuxtv-dvb-apps-1.1.0/utils/scan/dvb-s
linuxtv-dvb-apps-1.1.0/utils/scan/dvb-t
linuxtv-dvb-apps-1.1.0/utils/szap/czap
linuxtv-dvb-apps-1.1.0/utils/szap/szap
linuxtv-dvb-apps-1.1.0/utils/szap/tzap
перенести, либо в локальный ~/bin, в /usr/local/bin/ или ещё куда-нибудь, в «исполняемую» директорию. В этой «игре» нам понадобится всего три утилиты: szap, dvbnet и dvbtraffic
Теперь нам предстоит «рассказать» карте о том, с каким транспондером и с каким каналом ей предстоит работать. Например, я использую Сервис Raduga, спутник Intelsat-904:
частота 11595 GHz
поляризация Вертикальная
скороть передачи 29270 Msps
PID 4152
Формат файла, содержащего в себе описания каналов S-диапазона таков:
Поле Значение Описание
Название канала/сервиса
Если есть символы, отличные от буквенно-цифровых или пробелы, то название заключить в двойные кавычки.
Частота GHz
Частота передачи канала со спутника в GHz.
поляриазция v/h
Поляриазция: v — вертикальная, h — горизонтальная (соответственно, для круговой h — левая круговая, v — правая круговая)
diseqc 0/1
Если принимающая головка одна, то «0», если больше, то «1»
symbol rate Msps
Скороcть символьной передачи данных (symbol rate — Mega symbols per rate)
V-PID номер
Идентификатор Пакетов Видеопотока (Video Packet Identificator)
A-PID номер
Идентификтора Аудио Пакетов (Audio Packet Identificator)
SID номер
Идентификатор Сервиса (используется только в цифровом вещании) для использованием рессивера определённого сервиса (Service ID)
Соответственно, создаём файл /etc/channels.conf и делаем в нём запись:
Raduga:11595:v:0:29270:0:0:0

Конечно, можно было бы и создать файл, скажем с названием Intelsat-904.60W и нашпиговать его параметрами транспондеров. Ну путь это будет спутник Intelsat-904 W60°. Параметры можно будет взять, к примеру, с сайтов SatCodX или с www.lyngsat.com:
S 11155000 H 2963000  3/4 S 11491000 V 5787000  3/4 S 11520000 V 12000000 3/4 S 11529000 V 2893000  3/4 S 11555000 H 2927000  5/6 S 11595000 H 29270000 5/6 S 11595000 V 29270000 7/8 

«напустить» scan на этот файл. Если всё верно настроено и антенна хорошо сориентирована и Вы не забыли прописать при загрузке dvb_core dvb_shutdown_timeout=0 и всё оборудование исправно, то на экране получится что-то вроде
scanning Intel904.60W using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 11595000 H 29270000 7 initial transponder 11595000 V 29270000 7 initial transponder 11520000 V 12000000 3 >>> tune to: 11595:h:0:29270 WARNING: >>> tuning failed!!! >>> tune to: 11595:h:0:29270 (tuning failed) WARNING: >>> tuning failed!!! >>> tune to: 11595:v:0:29270 WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x0000 WARNING: filter timeout pid 0x0010 >>> tune to: 11520:v:0:12000 0x0000 0x0001: pmt_pid 0x0105 MIR-Teleport -- Moskow (running) 0x0000 0x0002: pmt_pid 0x0106 Teleport MIR -- HTB (running) 0x0000 0x0003: pmt_pid 0x0107 MIR-Teleport -- MIR-TV (running) 0x0000 0x0004: pmt_pid 0x0108 MIR Teleport -- MGOU (running) 0x0000 0x0006: pmt_pid 0x010a MIR-Teleport -- MIR Radio Service (running) 0x0000 0x0007: pmt_pid 0x0101 MIR-Teleport -- MAYAK FM (running) 0x0000 0x0008: pmt_pid 0x0100 MIR-Teleport -- MIR Service (running) 0x0000 0x0009: pmt_pid 0x0102 Mir Teleport -- Radio MIR (running) Network Name 'NDS' dumping lists (8 services) Moskow:11520:v:0:12000:512:650:1 HTB:11520:v:0:12000:515:653:2 MIR-TV:11520:v:0:12000:514:652:3 MGOU:11520:v:0:12000:517:655:4 MIR Radio Service:11520:v:0:12000:0:660:6 MAYAK FM:11520:v:0:12000:0:662:7 MIR Service:11520:v:0:12000:513:651:8 Radio MIR:11520:v:0:12000:0:665:9 Done. 

Только беда в том, что сервисы данных scan не «отловит» (обратите внимание на строчку >>> tune to: 11595:h:0:29270 WARNING: >>> tuning failed!!! Как раз, нужный мне транспондер) так что для настроек на Интернет Провайдера, придётся создавать файл channels.conf вручную.
Попробуем настроить карту на приём данных: /bin/szap -c /etc/channels.conf. Опять же, если всё было сделано верно, то мы увидим на экране следующее:
brat3 util # szap -c /etc/channels.conf -n 1 -x reading channels from file '/etc/channels.conf' zapping to 1 'I904': sat 0, frequency = 11595 MHz V, symbolrate 29270000, vpid = 0x0000, apid = 0x0000 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 03 | signal ba7a | snr 7aeb | ber 000026cd | unc 00000000 | status 1f | signal b8fe | snr cfe1 | ber 000005c6 | unc 00000000 | FE_HAS_LOCK 

Понятно, что если сигнал по той или иной причине пропал, ну например, произошло затенение отражателя, то эту процедуру надо повторить.
Осталось активировать сетевой интерфейс. Будьте внимательны — всё завист от того, какой тип фильтрации сетевых пакетов использует Ваш Интернет Провайдер. Если фильтрация пакетов идёт по MAC-адресу, то исправлять ничего не надо. Если фильтрация идёт по IP-адресу, то необходимо установить MAC-адрес карты в нужное значение. Например, если выданный мне провайдером IP-адрес 10.252.155.40, то его необходимо перевести в шестнадцатеричную форму: 0A:FC:9B:28 и прибавить в начале ещё два нуля: 00:00:0A:FC:9B:28. Иногда, правда, провайдер добавляет специальный префикс. Например, 02:00:0A:FC:9B:28. Впрочем, всю эту информацию вы у него и должны узнать.
Адрес карты устанавливаем произвольный, причём, желательно, чтоб этот адрес не попадал ни в одну из внутренних подсетей. Ну, например, для моей сети вполне подойдёт адрес 10.95.2.1, Поскольку внутренняя подсеть у меня 10.95.1.0/24. Итак:
1. Настраиваем фильтрацию по PID-у, указанному провайдером (Идентификатору Пакетов) и создаём сетевой интерфейс. Например: dvbnet -p 4152.
brat3 root # dvbnet -p 4152 DVB Network Interface Manager Version 1.1.0-TVF (Build Fri Aug 12 14:12:43 2005) Copyright (C) 2003, TV Files S.p.A Device: /dev/dvb/adapter0/net0 Status: device dvb0_0 for pid 4152 created successfully.

2. Присваиваем интерфейсу IP-адрес и MAC-адрес. Здесь будьте внимательны — если вы сделаете что-то неверно, то tcpdump будет показывать наличие траффика, но работать ничего не будет.
ifconfig dvb0_0 10.95.2.1 netmask 255.255.255.255 broadcast 255.255.255.255
ifconfig dvb0_0 hw ether 00:00:0A:FC:9B:28
route add 10.95.2.1 dev dvb0_0
Теперь ifconfig должен показать что-то в этом роде:
dvb0_0    Link encap:Ethernet  HWaddr 00:00:0A:FC:F3:9F           inet addr:10.95.2.1  Bcast:255.255.255.255  Mask:255.255.255.255           UP BROADCAST RUNNING NOARP MULTICAST  MTU:4096  Metric:1           RX packets:0 errors:0 dropped:0 overruns:0 frame:0           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)           Base address:0x1038 

а в таблице маршрутизации должна появится следующая строка:
Kernel IP routing table Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 10.95.2.1       0.0.0.0         255.255.255.255 UH    0      0        0 dvb0_0

Настал трепетный момент проверки работоспособности сетевого интрефейса. Вариантов два. Самый простой:
 # tcpdump -ni dvb0_0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on dvb0_0, link-type EN10MB (Ethernet), capture size 96 bytes 21:42:01.020568 IP 217.10.39.84.80 > <GW_IP>88.2909: . 1195548608:1195549945(1337) 	ack 1701755686 win 57491 21:42:01.020584 IP 217.10.39.84.80 > <GW_IP>88.2909: . 1337:2674(1337) ack 1 win 	57491 21:42:01.020586 IP 217.16.19.219.80 > 10.252.246.254.2394: S 3017247152:3017247152(0) 	ack 4146269160 win 5840 <mss 1460>

Вот когда такое по экрану ползёт, рука сама тянется «напустить» на всё это sniffit, но мы это делать не будем, поскольку неприлично подглядывать за чужим траффиком. Так делают только очень нехорошие дяди. Нам вполне должно быть достаточно того, что всё работает, однако!
Второй вариант проверки работоспособности интерфейса и того проще:
brat3 root # dvbtraffic 0365    10 p/s     1 kb/s    15 kbit 1029    89 p/s    16 kb/s   134 kbit 1030   166 p/s    30 kb/s   250 kbit 1031   774 p/s   142 kb/s  1164 kbit 1036   312 p/s    57 kb/s   469 kbit 1037   616 p/s   113 kb/s   926 kbit 1038  1035 p/s   190 kb/s  1557 kbit 1039   678 p/s   124 kb/s  1020 kbit 1040    91 p/s    16 kb/s   137 kbit 1042   119 p/s    21 kb/s   180 kbit 1050     1 p/s     0 kb/s     2 kbit 1051  2161 p/s   396 kb/s  3250 kbit 1056     5 p/s     0 kb/s     8 kbit 1057   359 p/s    65 kb/s   540 kbit 1058   961 p/s   176 kb/s  1445 kbit 1059     5 p/s     0 kb/s     8 kbit 1101   244 p/s    44 kb/s   367 kbit 1102   222 p/s    40 kb/s   334 kbit 1103     9 p/s     1 kb/s    14 kbit 1104   166 p/s    30 kb/s   249 kbit 1105    49 p/s     8 kb/s    73 kbit 1109  1095 p/s   201 kb/s  1647 kbit 2000  9177 p/s  1684 kb/s 13802 kbit -PID--FREQ-----BANDWIDTH-BANDWIDTH- 0365     9 p/s     1 kb/s    14 kbit 

Теперь неплохо бы собрать это всё в один скрипт. Ну пусть он называется, скажем, dvb.sh. Честно сказать, я воспользовался готовым, который взял из заметки Виталия Прядко «Установка Skystar-2 на Linux (skystar dvb linux driver)»[12]
Того лучше, прописать какой-нибудь init-скрипт. Скажем, для Gentoo можно построить в /etc/init.d/ скрипт dvbinit:
#!/sbin/runscript # Copyright (c) Vitaliy Pryadko # 2005 ( http://www.opennet.ru/base/sys/skystar2_linux.txt.html ) #  DIR=/usr/local/ #пид вашего провайдера  PID=0x103B  DEV_NAME=dvb0_0  #IP карты dvb. смотреть в мануале или в и-нете.  IP_ADDR=10.95.2.1 NETMASK=255.255.255.255 BCAST=255.255.255.255 # здесь пишем MAC dvb карты. В данном случае -- 00:00:+ # IP-адрес, выданный провайдером в шестнадцатеричном виде. MAC_ADDR=00:00:0A:FC:F3:9F depend() {     # need szap dvbnet ifconfig route     after net.eth0 } start () {             cd $DIR/bin               # тюним на нужный спутник, частоту и т.п.      ebegin "Read channels.conf"     $DIR/bin/szap -c /etc/channels.conf -n 1 -x      eend          # создаем сетевой адаптер     ebegin "Set PID ${PID}"     $DIR/bin/dvbnet -p $PID     eend                # присваеваем карте IP      ebegin "ifconfig Dev=${DEV_NAME} IP=${IP_ADDR}, Netmask=${NETMASK}, Broadcast=${BCAST}"     /sbin/ifconfig $DEV_NAME $IP_ADDR netmask ${NETMASK} broadcast ${BCAST}     eend          # присваеваем карте MAC      ebegin "Set MAC-Address - ${MAC_ADDR}"     /sbin/ifconfig $DEV_NAME hw ether ${MAC_ADDR}     eend          # Устанавливаем маршрутизацию на этот интерфейс     ebegin "Set route on DVB card interface"      route add ${IP_ADDR} dev ${DEV_NAME}     eend          ebegin "Disable rp_filter"     echo -n 0 > /proc/sys/net/ipv4/conf/dvb0_0/rp_filter      eend } stop() {     ebegin "Shutdown DVB-Interface"      /sbin/ifconfig ${DEV_NAME} down      $DIR/bin/dvbnet -d 0     eend }

А в Ubuntu тот же init-скрипт может выглядеть примерно так:
#!/bin/bash # Copyright (c) Vitaliy Pryadko # 2005 ( http://www.opennet.ru/base/sys/skystar2_linux.txt.html ) #  DIR=/usr/ # пид вашего провайдера (в данном случае представлен в шестнадцатеричном виде, но кто мешает в десятичном?) PID=0x103B # DVB-интерфейс DEV_NAME=dvb0_0  # IP карты dvb. смотреть в мануале или в и-нете. Назначить можно "от балды", главное прописать правильно роутинг IP_ADDR=10.95.2.1 NETMASK=255.255.255.255 BCAST=255.255.255.255 # здесь пишем MAC dvb карты. В данном случае -- 00:00:+ # IP-адрес, выданный провайдером в шестнадцатеричном виде. MAC_ADDR=00:00:0A:FC:F7:9E case "${1}" in 	start) 		cd $DIR/bin  		# настраиваем на нужный спутник, частоту и т.п.  		echo "Read channels.conf" 		$DIR/bin/szap -c /etc/channels.conf -n 1 -x  		# устанавливаем PID для аппаратной фильтрации пакетов 		echo "Set PID ${PID}" 		$DIR/bin/dvbnet -p $PID 		# Создаём сетевой интерфейс и присваеваем карте IP  		echo "ifconfig Dev=${DEV_NAME} IP=${IP_ADDR}, Netmask=${NETMASK}, Broadcast=${BCAST}" 		/sbin/ifconfig $DEV_NAME $IP_ADDR netmask ${NETMASK} broadcast ${BCAST} 		# Устанавливаем MAC-адрес карты (если фильтрация идёт по IP, представленному в виде 		# шестнадцатеричной формы MAC-адреса или MAC-адрес карты не соответствует необходимому 		echo "Set MAC-Address - ${MAC_ADDR}" 		/sbin/ifconfig $DEV_NAME hw ether ${MAC_ADDR} 		# Устанавливаем маршрутизацию на созданный интерфейс 		echo "Set route on DVB card interface"  		route add ${IP_ADDR} dev ${DEV_NAME} 		# Выключаем rp_filter для того, чтобы пакеты могли приходить с _другого_ интерфейс 		# (spoofing)  		echo "Disable rp_filter" 		echo 0 > /proc/sys/net/ipv4/conf/dvb0_0/rp_filter  		# Отменяем автоматическое отключение карты ( 5 сек ) 		echo "Disable shutdown timeout" 		echo 0 > /sys/module/dvb_core/parameters/dvb_shutdown_timeout 	;; 	stop) 		echo "Shutdown DVB-Interface"  		/sbin/ifconfig ${DEV_NAME} down  		$DIR/bin/dvbnet -d 0 	;; 	reload) 		echo "Shutdown DVB-Interface"  		/sbin/ifconfig ${DEV_NAME} down  		$DIR/bin/dvbnet -d 0 		cd $DIR/bin  		# настраиваем на нужный спутник, частоту и т.п.  		echo "Read channels.conf" 		$DIR/bin/szap -c /etc/channels.conf -n 1 -x  		# устанавливаем PID для аппаратной фильтрации пакетов 		echo "Set PID ${PID}" 		$DIR/bin/dvbnet -p $PID 		# Создаём сетевой интерфейс и присваеваем карте IP  		echo "ifconfig Dev=${DEV_NAME} IP=${IP_ADDR}, Netmask=${NETMASK}, Broadcast=${BCAST}" 		/sbin/ifconfig $DEV_NAME $IP_ADDR netmask ${NETMASK} broadcast ${BCAST} 		# Устанавливаем MAC-адрес карты (если фильтрация идёт по IP, представленному в виде 		# шестнадцатеричной формы MAC-адреса или MAC-адрес карты не соответствует необходимому 		echo "Set MAC-Address - ${MAC_ADDR}" 		/sbin/ifconfig $DEV_NAME hw ether ${MAC_ADDR} 		# Устанавливаем маршрутизацию на созданный интерфейс 		echo "Set route on DVB card interface"  		route add ${IP_ADDR} dev ${DEV_NAME} 		# Выключаем rp_filter для того, чтобы пакеты могли приходить с _другого_ интерфейс 		# (spoofing)  		echo "Disable rp_filter" 		echo 0 > /proc/sys/net/ipv4/conf/dvb0_0/rp_filter  		# Отменяем автоматическое отключение карты ( 5 сек ) 		echo "Disable shutdown timeout" 		echo 0 > /sys/module/dvb_core/parameters/dvb_shutdown_timeout 	;; 	restart) 		echo "This reloading all DVB modules" 	;; esac

Понятно, что в данном случае, скрипт переопределяет фильтрацию пакетов по MAC-адресу карты. Также, совершенно ясно, что приведённые здесь MAC-адреса взяты «от балды», то есть числа эти появились здесь совершенно случайно.
Правда, совершенно не важно, каков на самом деле настоящий MAC-карты — в данном случае, он определяется параметрами скрипта, а не прошивкой микросхемы.
Если Вы, почтеннейшие граждане Публика пользуетесь GentOO, то не забудьте добавить Ваш скрипт в «умолчальный» уровень загрузки:
rc-update add dvbinit default

3. Ассиметричный доступ

Клопы отдельно, тараканы — отдельно
© Народный рецепт
Думаю, что никому не открою страшной тайны, если скажу, что спутниковый доступ к Интернет ассиметричный. То есть, исходящий траффик должен идти по другому каналу, который, как правило, называют почему-то «наземным». Забавно, но в большей части случаев подключение к Интернет через спутник осуществляется через GPRS (EDGE) или CDMA мобильному телефону. Гораздо реже связь осуществляется через спутник же, но такое подключение обходится по себестоимости дороже трафика через GPRS-провайдера (порядок цен ~ .22$ за мегабайт). Правда подключение такое будет двунаправленным, а вовсе ни разу не симметричным — устройство для исходящего трафика отдельно, для входящего — отдельно.

Ниже размещу некую картинку, дабы подчеркнуть размеры пропасти между пользователем, спутником и провайдером (что-то порядка 36.000 км до геостационарной орбиты спутника и столько же обратно):
Принципиальная схема спутникового подключения к Интернет.
Во-первых, мы отправляем запрос к нашему спутниковому провайдеру через подключение к наземному Интернет-провайдеру, например, через GPRS, EDGE, CDMA или другим способом. Получив наш запрос наземный провайдер передаёт его Спутниковому Провадйдеру. Последний, в свою очередь, обрабатывает его и отправляет данные на спутник. Со спутника данные принимаются нашей спутниковой антенной и попадают через Спутниковую Карту на наш компьютер и, может быть, во внутренню интрасеть.
Современные спутниковые провайдеры как правило предоставляют наземное поключение по Виртуальной Частной Сети (VPN). На мой взгляд, самый простой способ осуществить подключение к сети — использовать OpenVPN. Начиная со второй версии, Клиент OpenVPN при подключении самостоятельно настраивает маршрутизацию и что, кстати, немаловажно при подключении через мобильный телефон GPRS, EDGE или CDMA, устойчиво «держит» связь (в отличие, скажем от P-t-P MPPE/MPPC подключения).
Кроме того, OpenVPN-подключение можно установить и через GPRS и EDGE. К примеру, на сей день провайдеры БиЛайн и МТС закрыли возможность подключения по обычному VPN. У Megafon‘a, вроде бы работает, но лучше бы не работало — качество связи просто отвратительное. Что же до разнесчастного SkyLink‘a, то они, через какой-то год совместно работы, обнаружили что я работаю по ассиметричному каналу. Тогда они просто перекрыли доступ в интернет. (А может и вру, может действительно, помехи из Кубинки мешали… но тогда почему с другого номера, с того же аппарата, связь прекрасно «качалась»?)
Во-всяком случае, Плакатов Я ДОВОЛЕН всё больше, а связь всё хуже (чтоб не быть голословным, процитировал запись прямо со скайлинковского форума. Там ещё где-то был весьма препасквильный стишок про этого самого мужика, который доволен, но я его где-то протерял.
Надо так понимать, что никакие звонки в службу техподдержки и прочая ругань не помогли. Увы… хотя, надо честно признать, что CDMA-подключение, скажем через тот же Ubiquam-105, работает намного прияственнее, чем через EDGE при помощи модема Nokia-6021.
Но, увы. Не для меня это пока, не для меня. Впрочем, провайдеров тоже можно понять: раздавать большое количество дата-трафика куда как невыгоднее, чем драть за голосовой…

3.1. OpenVPN.

Если Ваш провайдер предоставляет подключение через OpenVPN, то всё, что Вам нужно — это загрузить последнюю версию программного обеспечения, установить её. Далее, загрузить файлы ключей и конфигурационный файл у провайдера, положить их в какую-нибудь директорию (например /etc/openvpn/config/ и набрать из командной строки: openvpn —config client.config.
Для моего замечательного провайдера Raduga-Internet конфигурационный OpenVPN-файл будет выглядеть простейшем виде, под Windows ™ примерно так:
clientdev tapdev-node Radugaproto udpremote 80.81.208.82 55668resolv-retry infinitenobindpersist-keypersist-tunca ca.crtcert iXXXXXXX.crtkey iXXXXXXX.keyns-cert-type serververb 3comp-lzo comp-noadaptauth-user-pass ovpn.txt

Обратите внимание на строчку auth-user-pass.txt, в котором первая строка, данный вам провайдером логин, во-второй — пароль (некое, правда несколько сомнительное, повышение безопасности туннеля) Однако, в #nix–системах всё может выглядеть несколько иначе:
dev	tapport	55668proto	udpremote	80.81.208.82comp-lzocomp-noadaptifconfig 10.255.XXX.XXX 255.255.255.0route-noexectun-mtu 1400tls-clientca /etc/openvpn/raduga/ca.crtcert /etc/openvpn/raduga/iXXXXXXX.crtkey /etc/openvpn/raduga/iXXXXXXX.keyauth-user-pass /etc/openvpn/raduga/password.txt ns-cert-type serveruser  daemongroup daemonverb 4

Т.е., скажем халявы с автоматической маршрутизацией пакетов не будет: роутинг, и прочие радости придётся настраивать вручную. А чегож Вы, почтеннейшие граждане Публика, хотели? #nix он на то и #nix, чтобы всё, включая закат солнца вечером, вручную.
Да и не забудьте, правильно скомпилировать то самое устройство /dev/tap, к которому мы собрались обратиться. В противном случае на экран после груды отладочной информации будет вывалено примерно такое сообщение:
Thu Nov 23 11:07:52 2006 us=372950 Control Channel MTU parms [ L:1474 D:138 EF:38 EB:0 ET:0 EL:0 ] Thu Nov 23 11:07:52 2006 us=373540 Note: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2) Thu Nov 23 11:07:52 2006 us=373740 Note: Attempting fallback to kernel 2.2 TUN/TAP interface Thu Nov 23 11:07:52 2006 us=375631 Cannot allocate TUN/TAP dev dynamically Thu Nov 23 11:07:52 2006 us=375893 Exiting

Чтобы этого не произошло, не забудьте подключить при компилляции ядра настройку CONFIG_TUN=[m/y] (раздел «Drivers» -> «Network device support» -> «Universal TUN/TAP device driver support TUN») в случае /usr/src/linux/make menuconfig или, скажем, /usr/src/linux/make gconfig, а то и вовсе cd /usr/src/linux/ && genkernel —gconfig all)
Подробнее об устройствах /dev/net/tun и /dev/net/tap/ Вы можете почитать, к примеру в разделе документации, прилагающейся к ядру линукса /usr/src/linux/Documentation/networking/tuntap.txt.
Впрочем, если Вы, почтеннейшие граждане Публика, думаете, что на этом Ваши мучения закончились, Вы глубоко заблуждаетесь: они только начались. Нам предстоит настроить маршрутизацию IP-пакетов, что само по себе, является далеко не тривиальной задачей для ассиметричного доступа.
Да нет, нет, шучу. Нужно просто удалить «default» маршрут на входящие подключения и указать отдельные маршруты на входящие и исходящие пакеты:
route del default
route add -net <dsn спутникового провайдера> netmask 255.255.255.255 dev ppp0
/usr/sbin/openvpn —config /etc/openvpn/config/client.ovpn —daemon —log /var/log/openvpn.log
route add default gw <шлюз, указанный спутниковым провайдером>
Т.е., шлюз указывается только после того, как открыто openvpn подключение, а первичный маршрут {route add -net <dns спутникового провайдера> netmask 255.255.255.255 dev ppp0}, прописывается только для того, чтобы подключиться к спутниковому провайдеру по openvpn-каналу.
Того проще, запихать всё это, скажем в один настроечный файл. Нууу… пусть это будет либо фрагмент /etc/ppp/ip-up-скрипта, либо (что более грамотно реализовано в штатной поставке Ubuntu-Linux) скриптом, находящимся в директории /etc/ppp/ip-up.d/01swparams:
#!/bin/sh## this is a script which is executed after connecting the ppp interface.# look at man pppd for details# the followings parameters are available:# $1 = interface-name# $2 = tty-device# $3 = speed# $4 = local-IP-address# $5 = remote-IP-address# $6 = ipparam CURDATE=`date`# echo "${CURDATE} iface = $1 tty = $2 iface = $3 ip_local = $4 ip_remote = $5 param = $6" >> ${TESTLOG}# The  environment is cleared before executing this script# so the path must be resetPATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/binexport PATH# These variables are for the use of the scripts run by run-parts# PPP_IFACE="$1"# PPP_TTY="$2"# PPP_SPEED="$3"# PPP_LOCAL="$4"# PPP_REMOTE="$5"# PPP_IPPARAM="$6"OVPNCNF="/etc/openvpn/raduga/client.ovpn"OVPNLOG="/var/log/openvpn.log"RESOLVRADUGA="/etc/ppp/resolv/resolv.raduga"OPENVPN="/usr/sbin/openvpn"ROUTE="/sbin/route"LOGGER="/usr/bin/logger"TUN_IFACE="tap0"# http://faq.d-v.ru/index.php?action=artikel&cat=44&id=212&artlang=ruSATGW="10.255.128.1"REMOTE="80.81.208.82"export PPP_IFACE PPP_TTY PPP_SPEED PPP_LOCAL PPP_REMOTE PPP_IPPARAM# as an additional convenience, $PPP_TTYNAME is set to the tty name,# stripped of /dev/ (if present) for easier matching.PPP_TTYNAME=`/usr/bin/basename "$2"`export PPP_TTYNAME case "${PPP_IPPARAM}" in    mts)    ${ROUTE} del default    ${ROUTE} add default gw ${PPP_REMOTE}    iptables -F    iptables -t nat -F    iptables -t mangle -F    iptables -t nat -A POSTROUTING -o ${PPP_IFACE} -j MASQUERADE    echo 1 > /proc/sys/net/ipv4/ip_forward    ;;    bee)    ${ROUTE} del default    ${ROUTE} add default gw ${PPP_REMOTE}    iptables -F    iptables -t nat -F    iptables -t mangle -F    iptables -t nat -A POSTROUTING -o ${PPP_IFACE} -j MASQUERADE    echo 1 > /proc/sys/net/ipv4/ip_forward    ;;        mts+dv)    echo "Delete default ${ROUTE} rule"    ${ROUTE} del default    echo "Add particular ${ROUTE} rule -net ${REMOTE} netmask 255.255.255.255 dev ppp0 (d-v server)"    ${ROUTE} add -net ${REMOTE} netmask 255.255.255.255 dev ppp0    echo "Store old iptables rule"    ${IPTABLES_SAVE} | tee iptables.old.lst    echo "Startup openvpn"	# From http://www.openvpn.net/index.php/documentation/manuals/openvpn-20x-manpage.html :	# Note that cmd can be a shell command with multiple arguments, in which case all     # OpenVPN-generated arguments will be appended to cmd to build a command line which will be passed to the shell	# '#' -- comment all parameters added by openvpn automatically    ${OPENVPN} --config ${OVPNCNF} --daemon --pull --up "${ROUTE} add default gw ${SATGW} # " --log ${OVPNLOG}	echo "load IPTABLES rules for MASQUERADING and enable forwarding "    iptables -F    iptables -t nat -F    iptables -t mangle -F    iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE	echo "Enable ip forwarding"    echo 1 > /proc/sys/net/ipv4/ip_forward    echo "Rewrite resolv.conf"    /bin/cp ${RESOLVRADUGA} /etc/resolv.conf    echo "PPP_PARAM = "${PPP_IPPARAM}", PPP_REMOTE = "${PPP_REMOTE}    ;;        bee+dv)    echo "Delete default ${ROUTE} rule"    ${ROUTE} del default    echo "Add particular ${ROUTE} rule -net ${REMOTE} netmask 255.255.255.255 dev ppp0 (d-v server)"    ${ROUTE} add -net ${REMOTE} netmask 255.255.255.255 dev ppp0    echo "Store old iptables rule"    ${IPTABLES_SAVE} | tee iptables.old.lst    echo "Startup openvpn"	# From http://www.openvpn.net/index.php/documentation/manuals/openvpn-20x-manpage.html :	# Note that cmd can be a shell command with multiple arguments, in which case all     # OpenVPN-generated arguments will be appended to cmd to build a command line which will be passed to the shell	# '#' -- comment all parameters added by openvpn automatically    ${OPENVPN} --config ${OVPNCNF} --daemon --pull --up "${ROUTE} add default gw ${SATGW} # " --log ${OVPNLOG}	echo "load IPTABLES rules for MASQUERADING and enable forwarding "    iptables -F    iptables -t nat -F    iptables -t mangle -F    iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE	echo "Enable ip forwarding"    echo 1 > /proc/sys/net/ipv4/ip_forward    echo "Rewrite resolv.conf"    /bin/cp ${RESOLVRADUGA} /etc/resolv.conf    echo "PPP_PARAM = "${PPP_IPPARAM}", PPP_REMOTE = "${PPP_REMOTE}    ;;esac

Обратите внимание на то, что в строчке ${OPENVPN} —config ${OVPNCNF} —daemon —pull —up "${ROUTE} add default gw ${SATGW} # " —log ${OVPNLOG} в параметре —up после ${ROUTE} add default gw ${SATGW} стоит символ ‘#’. Это связано с тем, что openvpn любит добавлять свои собственные параметры (нафига так делать было?) если в —up вызывается команда с несколькими аргументами командной строки. Теперь, всё, что имеет добавить openvpn будет воспринято, как комментарий.
В данном случае, команда route add default gw <IP> добавляет маршрут по умолчанию для созданного tap интерфейса. Теперь все пакеты будут «ходить» именно через него. Кстати, большая часть ошибок в стиле «всё настроил и не работает…» приходится именно на этот участок. Не забывайте набирать в случае «не работает» почаще команду
$ route -nKernel IP routing tableDestination     Gateway         Genmask         Flags Metric Ref    Use Iface10.0.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 ppp080.81.208.82    0.0.0.0         255.255.255.255 UH    0      0        0 ppp010.95.2.1       0.0.0.0         255.255.255.255 UH    0      0        0 dvb0_010.255.128.0    0.0.0.0         255.255.255.0   U     0      0        0 tap0192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth00.0.0.0         10.255.128.1    0.0.0.0         UG    0      0        0 tap0

И, ура:

Теперь при подключении к «спутнику» можно будет набрать что-то вроде:
pppd call mts+dv
а не последовательность комманд, обозначающую, что все процессы работы с ассиметричным доступом Вы уже успели выучить наизусть и беглость пальцев при печати с избытком покрывает Вашу неприязнь к любого рода изыбточной оптимизации. Никакого прогресса! Всем назад в пещеры и картинки всем править в текстовой консоли!!!
Понятно, что самое название подключения, скажем bee+dv или sky+dv указываеся в настройках модема, используемого для исходящего трафика. Я использую для «наземного» подключения GPRS-модем (в данном случае, GPRS-модема Siemens NS75) Настройки записаны в файл /etc/ppp/peers/mts+dv и название подключения задано при помощи ipparam bee+dv:
# Siemens ES75i GPRS 115200K# 115200,8,N,1, ctsfl=1, rtsctl=2/dev/ttyACM0115200user mtsremotename "internet.mts.ru"debug-detachnovjnoauthpersist# passiveusepeerdnsnoipdefaultdefaultrouteconnect 'chat -v -f /etc/chatscripts/mts -T *99***1#'ipparam mts

Заметьте, что здесь стоит опция -detach. Это связано с тем, что модем Siemens NS75, как и некоторые другие, имеет привычку подключаться аккуратно через раз. С чем это может быть связано, даже предположить боюсь… так, что лучше держать перед глазами консоль, на которой видно состояние подключения.
Подробнее о настройке OpenVPN можно прочитать в OpenVPN ™ 2.x HOWTO[14]. Ну а если Вы и так всё правильно настроили, то при подключении OpenVPN-клиента должно получиться что-то в этом роде:
brat3 config # openvpn --config client.ovpn Sat Sep 17 21:01:00 2005 OpenVPN 2.0 i686-pc-linux [SSL] [LZO] [EPOLL] built on Aug 14 2005 Sat Sep 17 21:01:00 2005 IMPORTANT: OpenVPN's default port number is now 1194, based on an 	official port number assignment by IANA. 	OpenVPN 2.0-beta16 and earlier used 5000 as the default port. Sat Sep 17 21:01:00 2005 WARNING: file 'Client.key' is group or others accessible Sat Sep 17 21:01:00 2005 Control Channel MTU parms [ L:1573 D:138 EF:38 EB:0 ET:0 EL:0 ] Sat Sep 17 21:01:00 2005 Data Channel MTU parms [ L:1573 D:1450 EF:41 EB:4 ET:32 EL:0 ] Sat Sep 17 21:01:00 2005 Local Options hash (VER=V4): '2c50bd2c' Sat Sep 17 21:01:00 2005 Expected Remote Options hash (VER=V4): '0ddbb6e3' Sat Sep 17 21:01:00 2005 UDPv4 link local: [undef] Sat Sep 17 21:01:00 2005 UDPv4 link remote: <SERVER_IP>:55684 Sat Sep 17 21:01:08 2005 TCP/UDP: Incoming packet rejected from 127.0.0.1:53[2], 	expected peer address: <SERVER_IP>:55684 (allow this incoming source address/port 	by removing --remote or adding --float) Sat Sep 17 21:01:08 2005 TCP/UDP: Incoming packet rejected from 127.0.0.1:53[2], 	expected peer address: <SERVER_IP>:55684 (allow this incoming source 	address/port by removing --remote or adding --float) Sat Sep 17 21:01:10 2005 TLS: Initial packet from <SERVER_IP>:55684, sid=7bcc4f6c bae60adb Sat Sep 17 21:01:51 2005 VERIFY OK: depth=1, 	/C=RU/ST=MW/L=MOSCOW/O=RadugaVPN/emailAddress=support@telecom-service.net Sat Sep 17 21:01:51 2005 VERIFY OK: nsCertType=SERVER Sat Sep 17 21:01:51 2005 VERIFY OK: depth=0, 	/C=RU/ST=MW/O=RadugaVPN/CN=RadugaVPN/emailAddress=support@telecom-service.net Sat Sep 17 21:01:55 2005 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Sat Sep 17 21:01:55 2005 Data Channel Encrypt: Using 160 bit message hash 'SHA1' 	for HMAC authentication Sat Sep 17 21:01:55 2005 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Sat Sep 17 21:01:55 2005 Data Channel Decrypt: Using 160 bit message hash 'SHA1' 	for HMAC authentication Sat Sep 17 21:01:55 2005 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 	1024 bit RSA Sat Sep 17 21:01:55 2005 [RadugaVPN] Peer Connection Initiated with <SERVER_IP>:55684 Sat Sep 17 21:01:56 2005 SENT CONTROL [RadugaVPN]: 'PUSH_REQUEST' (status=1) Sat Sep 17 21:01:57 2005 PUSH: Received control message: 	'PUSH_REPLY,redirect-gateway,dhcp-option DNS <SERVER_IP>, 	route-gateway <GW_IP>,ping 10, 	ping-restart 120, 	route 0.0.0.0 0.0.0.0 <GW_IP>, 	dhcp-option DNS 82.118.131.162, 	ifconfig <LOCAL_IP> 255.255.255.0' Sat Sep 17 21:01:57 2005 OPTIONS IMPORT: timers and/or timeouts modified Sat Sep 17 21:01:57 2005 OPTIONS IMPORT: --ifconfig/up options modified Sat Sep 17 21:01:57 2005 OPTIONS IMPORT: route options modified Sat Sep 17 21:01:57 2005 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Sat Sep 17 21:01:57 2005 TUN/TAP device tap0 opened Sat Sep 17 21:01:57 2005 /sbin/ifconfig tap0 <LOCAL_IP> 	netmask 255.255.255.0 mtu 1500 broadcast <BROADCAST_IP> Sat Sep 17 21:01:57 2005 /sbin/route add -net <SERVER_IP> 	netmask 255.255.255.255 gw 212.119.97.85 Sat Sep 17 21:01:57 2005 /sbin/route del -net 0.0.0.0 netmask 0.0.0.0 Sat Sep 17 21:01:57 2005 /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw <GW_IP> Sat Sep 17 21:01:57 2005 /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw <GW_IP> Sat Sep 17 21:01:57 2005 /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw <GW_IP> Sat Sep 17 21:01:57 2005 Initialization Sequence Completed

, где <LOCAL_IP> — IP-адрес, предоставленный Вам провайдером для подключения (если используется фильтрация по IP-адресу), <SERVER_IP> — адрес сервера, к которому осуществляется подключение, <BROADCAST_IP> — IP-адрес широковещательной передачи, <GW_IP> — IP-адрес шлюза.
Таблица маршрутизации после создания VPN-подключения, соответственно, будет выглядеть так:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
<EARTHLINK_GW> 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
<SATLINK_GW> <EARTHLINK_GW> 255.255.255.255 UGH 0 0 0 ppp0
<LOCAL_DVB_IP> 0.0.0.0 255.255.255.255 UH 0 0 0 dvb0_0
<LOCAL_NET> 0.0.0.0 <LOCAL_NETMASK> U 0 0 0 eth0
<DVB_NETWORK> 0.0.0.0 <DVB_NETMASK> U 0 0 0 tap0
127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo
0.0.0.0 <EARTHLINK_GW> 0.0.0.0 UG 0 0 0 tap0
, где <EARTHLINK_GW> — шлюз для наземного подключения (в данном случае — ppp0); <SATLINK_GW> — шлюз спутникового подключения; <LOCAL_DVB_IP> — IP-адрес, присвоенный dvb-интерфейсу спутниковой карты; <LOCAL_NET>, <LOCAL_NETMASK> — соответственно, адрес локальной (интранет) сети (если есть) и маска подсети; <DVB_NETWORK>, <DVB_NETMASK> — адрес сети из которой Вам выдаётся IP-адрес при подключении и маска подсети.
Соответственно, ppp0 — интерфейс «наземного» подключения, tap0 — OpenVPN-подключение, dvb0_0 — интерфейс спутниковой карты, eth0 — сетевое подключение к внутренней (интранет) сети (если она, конечно же есть).
Ну чтож, всё, что осталось сделать — это запустить
brat3 root # ping ya.ru PING ya.ru (213.180.204.8) 56(84) bytes of data. 64 bytes from ya.ru (213.180.204.8): icmp_seq=1 ttl=50 time=623 ms 64 bytes from ya.ru (213.180.204.8): icmp_seq=2 ttl=50 time=598 ms 64 bytes from ya.ru (213.180.204.8): icmp_seq=3 ttl=50 time=519 ms

и убедиться, что всё работает… ну или не работает… тогда начинать всё сначала, проверять и перепроверять, тестировать оборудование… да мало ли?
Думаю, что в первую очередь, надо проверять, верно ли настроена филтрация IP-пакетов в спутниковой карте.
(Для случая Sky-Link были сделаны настройки для телефона Ubiquam-100, Ubiquam-105. Хотя менеджеры Sky-Link‘a и Евросети хором утверждают, что лучше всего пользоваться не менее, чем Ubiquam-U<M>300, Ubiquam-540). Причина — поддержка некоей услуги «SkyTurbo» — сжатие потока данных со стороны сервера. Нужен-ли для этого в действительности такой сверхаппарат, точно не знаю, пока не разобрался, но большая часть Тарифных планов SkyLink ориентирована на работу именно в режиме «SkyTurbo».
Во-всяком случае, чат-скрипт /etc/ppp/chats/skylink
'' AT+CRM=1;&C0	'OK' ATS0=0		'OK' ATS7=60		'OK' ATDT#777	'CONNECT'

и файл с «рулями» (peers) — /etc/ppp/peers/cdma-skylink
# You usually need this if there is no PAP authentication noauth # The chat script (be sure to edit that file, too!) connect "/usr/sbin/chat -v -f /etc/ppp/chats/skylink" # Set up routing to go through this PPP link defaultroute # Set this to /dev/ircomm0 or similar /dev/ttyUSB0 # Speed # 115200 23040 # Control character handling asyncmap	20A0000 escape		FF # Reconnect on disconnect persist # Be extra verbose debug # You may need these passive noipdefault noproxyarp ipcp-accept-local ipcp-accept-remote ipcp-restart 2 ipcp-max-configure 20 ipcp-max-failure 20 # Use remote DNS usepeerdns # With GPRS, authentication is normally done  automatically # via your cellphone number, so leave login name empty # user "mobile@mppc.skylink.msk.ru" user "mobile" ipparam cdma-skylink # Set MTU mtu	1400 # User Hardware flow -control crtscts # Let the phone figure out all the IP addresses noipdefault

и /etc/ppp/peers/skylink+dv:
# You usually need this if there is no PAP authentication noauth # The chat script (be sure to edit that file, too!) connect "/usr/sbin/chat -v -f /etc/ppp/chats/skylink" # Set up routing to go through this PPP link defaultroute # Set this to /dev/ircomm0 or similar /dev/ttyUSB0 # Speed # 115200 230400 # Set MTU mtu	1400 # Reconnect on disconnect persist # Be extra verbose debug # You may need these passive noipdefault noproxyarp # Let the phone figure out all the IP addresses ipcp-accept-local ipcp-accept-remote ipcp-restart 2 ipcp-max-configure 20 ipcp-max-failure 20 # Control character handling asyncmap 20A0000 escape FF # asyncmap 0xa0000 # No ppp compression novj nodeflate nobsdcomp # Use remote DNS usepeerdns # With GPRS, authentication is normally done  automatically # via your cellphone number, so leave login name empty # user "mobile@mppc.skylink.msk.ru" user "mobile" ipparam skylink+dv # Use hardware flow conrtrol crtscts

В некоторой степени отличаются от «штатных» GPRS/EDGE-настроек.». На пример, файл для подключения Nokia-6021 через BlueTooth /etc/ppp/chats/nokia-6021:
# Siemens NS75 Serial GPRS 57K# 57600,8,N,1, ctsfl=1, rtsctl=2REPORT CONNECTABORT BUSYABORT "NO CARRIER"ABORT ERRORABORT ncorrectABORT "NO ANSWER"ABORT "NO DIALTONE"''ATZ	OKAT+CGDCONT=1,"IP","internet.mts.ru"	OKATDT	CONNECT

всенепременно завершается запуском ‘ATDT’ и ожиданием ‘CONNECT’, в то время, как чат-скрипт для Ubiquam-105 завершается несколько странной строчкой ATDT#777 ‘CONNECT’
Вообще говоря, при подключении через SkyLink лучше использовать аппаратик вроде C-motech CHS-628 или C-motech CNU-550 Pro. Скажем, в магазине SkyLink’a представлена модель C-motech CNU-550 Pro — ни тебе проблем с настройкой подключения, ни с маршрутизацией. (настоятельно рекомендую ознакомиться со-всей линейкой CDMA-модемов C-motech.)3

3.2 PPP MPPE/MPPC Подключение

Для меня это подключение, увы, оказалось несколько бесполезным: «наземное» подключение осуществляется через CDMA–аппарат Ubiquam-100, а он имеет свойство в моменты «затишья» выключаться. ppp-клиент, обнаружив, что связи нет, обрывает VPN соединение. Как с этим боротся, пока не разобрался. Впрочем, нет худа без добра: теперь могу подключаться к SkyLink со сжатием данных, что очевидно экономит траффик.
Для GPRS/EDGE–подключения MPPE/MPPD–подключение также оказалось бесполезным — нужные порты просто закрыты провайдером (у меня Билайн)
Кроме того, настройка этого подключения под Linux оказалась несколько более хлопотная, чем установка, настройка и подключение через OpenVPN. Ну да ладно, хватит жаловаться на неблагоприятные погодно-материальные условия! Начнём, пожалуй.
Во-первых, понадобится патч для ядра, ppp-клиента и самый ppp-клиент, версии не ниже, чем 2.4.2. Патчи можно взять на сайте MPPE/MPPC kernel module for Linux (бывший www.polbox.com). Ну а что же до ppp-клиента, то его домашний сайт находится там же где и всегда — PPP Web-page
Не забудьте, что версии патчей должны соответствовать версиям ядра и ppp-клиента.
Начнём с ядра. Предположим, что вы распаковали исходный код яра и сделали линк на /usr/src/linux и зали в эту директорию (патч остался в папке /usr/src/linux-2.XX.XX-mppe-mppc-1.X.patch.gz) Набираем команду: gzip -cd linux-2.XX.XX-mppe-mppc-1.X.pathc.gz && patch -p1.
Далее, набираем make mrproper && make menuconfig (ну или, к чему Вы там привыкли?) И находим в разделе «Network device support» «PPP (point-to-point protocol) support» и «Microsoft PPP compression/encryption (MPPC/MPPE)». Отмечаем их для компиляции.
Кроме того, в разделе «Cryptographic API» надо отметить «SHA Digest algorithm» и «ARC4 cipher algorithm»[15]. Сохраняем конфигурацию ядра и пересобираем его.
Теперь очередь pppd. «Раскручиваем» исходный код в какую-нибудь директорию, и накладываем патч: patch -p0 < ppp-2.4.X-mppe-mppc-1.X.patch.gz (patch (1) {между прочим, автор — знаменитый Larry Wall, автор regex’ов }) и далее делаем всё по инструкции установки: ./configure && make && make install.
Теперь надо настроить конфигурационные файлы ppp. Начнём с файлов авториации: /etc/ppp/chap-secrets. CHAP (Challenge Handshake Authentication Protocol протокол аутентификации с предварительным согласованием вызова) Открываем файл /etc/ppp/chap-secrets и дописываем туда логин/пароль, выданные провайдером для подключения в хорошо знакомом всем формате:
#<login>	<server>	<password>	<IP-Address> mylogin	*	mypassword	*

Далее принимаемся за файл /etc/options.pptp:
# # Lock the port # lock # # Debug option # debug # # We don't need the tunnel server to authenticate itself # noauth # # Turn off transmission protocols we know won't be used # nobsdcomp nodeflate # # # lock # # We want MPPE # mppe required,stateless # # We want a sane mtu/mru # mtu 1000 mru 1000 # # Time this thing out of it goes poof # lcp-echo-failure 10 lcp-echo-interval 10 # Handshake Auth Method +chap : # +mschap-v2

Я пробовал увеличивать значение lcp-echo-failure, но почему-то к толковому результату это не привело. Связь всё равно до обидного быстро обрывалась.
Теперь редактируем файл самого подключения. Обычно эти файлы находятся в директории /etc/ppp/peers. Свой файл назвал Raduga по имени сервиса, к которому подключаюсь.
# # PPTP Tunnel configuration for tunnel 904.d-v.ru # Server IP: 904.d-v.ru # Route: add -host 80.81.208.34/0 gw 10.252.243.159 # # # Tags for CHAP secret selection # name                            mylogin -pap +chap -mschap -mschap-v2 debug noauth novj nobsdcomp noproxyarp nodeflate silent 

Ну вот, пожалуй и всё. Можно набрать pptp- start Raduga. Опять же, если всё правильно настроено, то вы логе Вы можете увидеть следующие сообщения:
Sep 18 00:24:17 brat3 pppd[1313]: Connect: ppp1 <--> /dev/pts/4 … Sep 18 00:24:58 brat3 pppd[1313]: sent [CHAP Response id=0x65 , na me = "MyLogin"] … Sep 18 00:24:58 brat3 pppd[1313]: rcvd [LCP EchoRep id=0x0 magic=0x39495f17] Sep 18 00:24:58 brat3 pppd[1313]: rcvd [CHAP Success id=0x65 "Access granted"] Sep 18 00:24:58 brat3 pppd[1313]: CHAP authentication succeeded: Access granted Sep 18 00:24:58 brat3 pppd[1313]: sent [CCP ConfReq id=0x1 ] … 

Если Вы хотите поподробнее почитать о настройке VPN подключения, то обратитесь к более специальной статье. Например, рекомендую заглянуть в заметку Алекса Зорга «Настройка VPN (использование pptp-client’а)»[16].

Маскарадинг

Iptables

Ну тут всё просто (особенно, если заглянуть в «Masquerading Made Simple HOWTO»:[17]
$> modprobe ipt_MASQUERADE # If this fails, try continuing anyway $> iptables -F; iptables -t nat -F; iptables -t mangle -F $> iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE $> echo 1 > /proc/sys/net/ipv4/ip_forward

или, если Вы используете MPPC/MPPE-подключение:
$> modprobe ipt_MASQUERADE # If this fails, try continuing anyway $> iptables -F; iptables -t nat -F; iptables -t mangle -F $> iptables -t nat -A POSTROUTING -o ppp1 -j MASQUERADE $> echo 1 > /proc/sys/net/ipv4/ip_forward

Что любопытно, теперь спутниковое подключение к Интернет будет доступно со всех компьютеров Вашей Локальной Сети.

Ipchains

Ой, разберитесь сами, не совсем понимаю, как это работает.

И последнее

Не забудьте прописать грамотно /etc/resolv.conf:
nameserver <адрес.dns-сервера.спутникового.провайдера>
Хотя, честно сказать, предпочитаю в /usr/local/bind/bind.conf прописать опцию forwarders

5. Приложения

Конфигурационные файлы

Все настроечные файлы одним архивом:
1. config.tar.bz2 — все конфигурационные файлы в архиве tar.bz2
2. config.tar.gz — все конфигурационные файлы в архиве tar.gz
3. linuxsat.tar.bz2 — сама статья вместе с конфигурационными файлами и картинками в архиве tar.bz2
4. linuxsat.tar.gz — сама статья вместе с конфигурационными файлами и картинками в архиве tar.gz
В папке /etc присутствует разбиение на /etc/gentoo и /etc/ubuntu. Различия между ними, на самом деле невелики: во-первых, в /etc/gentoo/openvpn/config/client.ovpn использована группа nobody, а в /etc/ubuntu/openvpn/config/client.ovpn использована группа daemon; во-вторых, в /etc/gentoo/init.d/dvbinit использутеся шелл /sbin/runscript, традиционный для init-скриптов GentOO, а в /etc/ubuntu/init.d/dvbinit#!/bin/bash, традиционный для init-скриптов UbuntU.
С уважениемъ, ВашЫ

Ссылки

[1] Алексей Силяков «DVB-карта SkyStar-1, релиз 1.5. Technotrend. Работа над ошибками.» На мой взгляд, одна из самых подробных и разносторонних статей об этой, несомненно, по сей день популярной DVB-карте.
[2] Файл Documentation/dvb/faq.txt из пакета документации ядра Linux 2.6.12.2
[3] «Програмное обеспечение под Linux» (обзор)
[4] «Как запустить интернет через DVB-S под Linux 2.4»
[5] Сайт NuclearCat‘a
[8] Сайт Andrix’а (dvbd, dvbroute)
[9] NuclearCat, s.o.v.a., «Руководство по установке SkyStar2 под Linux 2.4»
[10] Роберто Аркомано, Sat-HOWTO
[13] «Установка и настройка спутниковой антенны»
[17] John Tapsell, Thomas Spellman, Matthias Grimm, «Masquerading Made Simple HOWTO»
[18] Алексей Федорчук, KoT, lexb, «Ядро Linux: опции конфигурирования»

Сноски

1 не стоит путать её, с картой SkyStar 1 CI — это несколько разные вещи, хотя утверждается, что эта карта работает вполне нормально работает с теми же драйверами. Что же до SkyStar 1, то она довольно давно снята с производства, хотя до сих пор свободно продаётся в России и странах СНГ, но часто сгорающие на ней микросхемы питания 13/18V достать к ней очень и очень трудно. Если уж Вы решились её купить, то лучше сразу соберите себе внешний блок питания с ручным переключением напряжения. Так спокойнее будет.
Приобрести её можно, например здесь.
2Dont flame me if it does not work for you, destroys your computer or what-not. I take no responsibility. My intention was to modify Carsten’s dvbd so that it does not need patching anymore (at least for me). I also added this docs, help for line flags acceptable by dvbd, and made a few extensions inside the program — consult the top of dvbd.c file if you are wondering.
3 Что характерно, под Mac OS X — этот вариант будет единственно приемлемым, поскольку Ubiquam драйверов для Mac OS X не поставляет(?), хотя, наверное, если как-следует покопаться на Ross Barkman’s Home Page, можно если не найти искомое, то вполне соорудить самому — невелика сложность. Правда, не совсем понятно, что делать с Ubiquam-UM300 — что там с PCMCIA-слотом? Найдутся-ли какие-нибудь штатные драйвера, которым можно будет «заобщать» это устройство с Mac OS X или Linux’ом?
Опять же, при помощи «штатного» Нуль-модемного драйвера, любезно предоставленного на сайте SkyLink’a, Группа Народных Умельцев (GNU .-) по-последним слухам таки вполне соединила U-серию c Mac OS X (ещё об этом полезно почитать здесь) То есть, решение не очевидно, но, существует и вполне реализуемо.
Увы, информации о спутниковых картах, нормально взаимодействующими с этой операционной системой мне найти не удалось. Видимо, компьютера-роутера, с Linux и спутниковой картой на борту, не избежать.
С уважением, вашы ПлотнегЪ и Алексавр

Related posts

Leave a Comment