Спутниковый Интернет для продвинутых

[ANGEL OF FIRE]

Внимание!!!

[IMG]http://img171.**************/img171/6761/lucifer2ta2.gif[/IMG]


Любые нарушения правил этого раздела будут считаться умышленными, вне зависимости от того, прочли ли Вы их, согласны ли Вы с ними или нет. Нарушители этих правил будут наказаны в соответствии с правилами форума.

Если после нарушения Вы решите создать новый аккуант на форуме и снова нарушите правила, оба аккуанта будут заблокированы, поэтому не следует усложнять своё положение.

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

[IMG]http://img187.**************/img187/8364/el1dq12zfin6.gif[/IMG]

Статус

Инструкция по форуму

Правила раздела Спутниковый приём

[wasil]

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

Спутниковый интернет на SkyStar1 и SkyStar2 под Linux
1. Подготовка
Подготовка к работе всегда занимает времени больше, чем сама работа

Народная мудрость
Самый простой й взгляд путь — это работать с ветвью ядра версии 2.6.xx. На данный момент на сайте kernel.org доступная версия 2.6.13.1. Насколько я понял, начиная с версии 2.6.11, благодаря стараниям NuclearCat встроенные в ядро драйвера DVB-карт SkyStar 1 и SkyStar 2 прекрасно работают.

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

Сейчас мы устанавливаем карточку SkyStar 1 под Linux, с ядром версии не ниже 2.6.11.
Карта эта — весьма капризная особа и к ней, как минимум понадобится дополнительный охладитель.
В файл конфигурации надо доабавить следующие опции ([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]

После сборки должен получится следующий набор модулей[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_core — dvb_shutdown_timeout=0. Дело в том, что карты SkyStar 1 и SkyStar 2 для защиты от перегрева при отсутствии нагрузки выключаются и теряют связь. Число 0 означает не выключаться никогда.
Если всё прошло успешно, то 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
В отличие от ядра 2.6.xx.x в нём драйверов для карт SkyStar 1 и SkyStar 2 нет. Драйвера придётся загрузить с опять-таки с сайта LinuxTV. На данный момент это — linuxtv-dvb-1.1.1.tar.bz2[327K]. Правда, во многих местах в сети, в частности в статьте, размещённой на сайте General Satellite «Программное обеспечение под Linux 2.4», утверждается, что эти драйвера для работы с интернет не годятся — всё нормально загружается, но спутник не «лочится».

Во всяком случае, в большинстве сетевых заметок, настоятельно рекомендуется взять альтернативные драйвера от Дениса Федорищенко (NuclearCat) — ss1linux-rc5.tar.gz[1.8M].

В сети есть немало статей, посвящённых установке и настройке DVB-драйверов в под ядром Linux v2.4.xx.x, в частности, например, статьи Сергея Мазенкова «Как запустить интернет через DVB-S под Linux 2.4», Сергея Ткачова «Digital Video Broadcasting или как заставить работать TechniSat SkyStar-1 под Linux» или «Установка спутникового Internet под Linux»

Все эти руководства, кроме последнего, предлагают устанавливать dvbds-2, dvbd3. Желательно созданный Andrix'ом. Даже в знаменитом Sat-HOWTO предлагается использовать этот путь.

Однако, данная концепция на сей день несколько устарела, так что остановим наше внимание на «штатных» драйверах: 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». Это вполне понятно — кто лучше автора расскажет о том, как оно всё работает. И даже не важно, что оно сделано для ядра 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 skystar2. dmesg должен показать следующее (MAC-адрес должен соответсвовать MAC-адресу с метки на Вашей карте):

drivers/media/dvb/b2c2/skystar2.c: FlexCopIIB(rev.195) chip found
drivers/media/dvb/b2c2/skystar2.c: the chip has 38 hardware filters
driver_initialize MAC address = 00: d0: d7:0c: d3: 1dcf: 34:
DVB: registering new adapter (SkyStar2).
DVB: registering frontend 0 (ST STV0299 DVB-S)...

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

1.4. SkyStar 2, Linux v2.4.xxПроцесс установки под ядром 2.4.xx.x почти идентичен установке под 2.6.xx.x, за исключением того, что нам придётся взять драйвера 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. Сетевой интерфейс—

Итак, если у Вас не установлена 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 4155

Формат файла, содержащего в себе описания каналов 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:

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 на этот файл. Если всё верно настроено и антена хорошо сориентирована, то на экране получится что-то вроде

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:D0:5C:0A:9B:28

route add 10.95.2.1 dev dvb0_0

Теперь ipconfig должен показать что-то в этом роде:

dvb0_0 Link encap:Ethernet HWaddr 00:D0:5C:0A: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 > 88.2909: . 1195548608:1195549945(1337)
ack 1701755686 win 57491
21: 42: 01.020584 IP 217.10.39.84.80 > 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

Второй вариант проверки работоспособности интерфейса и того проще:

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)»

[wasil]

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

Учет всего трафика, проходящего через маршрутизатор работающий под ОС Linux;

Возможность быстрого изменения конфигурации без внесения изменений в код;

Данные о трафике должны храниться в базе данных, в нашем случае мы в качестве сервера баз данных будем использовать MySQL.
В рассматриваемом примере будем считать, что все IP адреса в нашей сети реальные. Начнем с создания конфигурационного файла, назовем его billing.conf. Пусть он имеет следующий вид:

# Формируем список IP адресов машин или сетей, для которых мы будем считать
# трафик
# Рабочее место
WS1="192.168.0.1"
# Ceть нашего клиента
NET="192.168.1.0/24"
# Объединим объединим все сети и адреса в один список.
ALLNETS="$WS1 $NET"

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

Программы формирования правил учета для firewall, с использованием iptables;

Программы снятия статистики;

Программы отображения статистики;
Рассмотрим программу формирования правил учета для firewall, названную в нашем случае rc.firewall, которую нужно будет добавить в один из файлов, который будет выполняться при загрузке системы.

Для начала немного теории, в ядрах Linux серии 2.4.X используется firewall NetFilter, интерфейсом к которому является программа iptables. В NetFilter cущестуют несколько цепочек: INPUT - все входящие пакеты, адресованные маршрутизатору, OUTPUT - все исходящии из маршрутизатора пакеты, FORWARD - все пересланные маршрутизатором пакеты во внешнюю сеть.

#!/bin/bash
# Подключаем конфигурационный файл
. /etc/lbiling.conf
IPTABLES="/sbin/iptables" # Задаем путь к программе iptables
###################################
# Учет трафика
###################################
# Функция для создания правила учета
addrule(){
$IPTABLES -N ACCT_IN_ # Создаем правило для учета входяшего трафика
$IPTABLES -N ACCT_OUT_ # Создаем правило для учета изходяшего трафика
$IPTABLES -F ACCT_IN_ # Обнулим полученные цепочки
$IPTABLES -F ACCT_OUT_
$IPTABLES -A INPUT -j ACCT_IN_ # Включим учет по цепочкам
$IPTABLES -A FORWARD -j ACCT_IN_
$IPTABLES -A FORWARD -j ACCT_OUT_
$IPTABLES -A OUTPUT -j ACCT_OUT_
$IPTABLES -A ACCT_IN_ -s # Считать входящим трафик у которого источник
# адрес
$IPTABLES -A ACCT_OUT_ -d # Считать исходящим трафик у которого получатель
# адрес
}
# Создаем правила для учета трафика
for NET in $ALLNETS; do
# Для всех сетей в списке $ALLNET создать правила учета трафика
addrule $NET $NET
done

После выполнения нашей программы rc.firewall, набрав в консоли:

# iptables -L

Вы должны будете увидеть нечто подобное:

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCT_IN_192.168.0.1 all -- anywhere anywhere
ACCT_IN_192.168.1.0/24 all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCT_IN_192.168.0.1 all -- anywhere anywhere
ACCT_OUT_192.168.0.1 all -- anywhere anywhere
ACCT_IN_192.168.1.0/24 all -- anywhere anywhere
ACCT_OUT_192.168.1.0/24 all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCT_OUT_192.168.0.1 all -- anywhere anywhere
ACCT_OUT_192.168.1.0/24 all -- anywhere anywhere

Chain ACCT_IN_192.168.0.1 (2 references)
target prot opt source destination
all -- 192.168.0.1 anywhere

Chain ACCT_IN_192.168.1.0/24 (2 references)
target prot opt source destination
all -- 192.168.1.0/24 anywhere

Chain ACCT_OUT_192.168.0.1 (2 references)
target prot opt source destination
all -- anywhere 192.168.0.1

Chain ACCT_OUT_192.168.1.0/24 (2 references)
target prot opt source destination
all -- anywhere 192.168.1.0/24

Создадим базу данных в MySQL с названием trafficbd, для этого необходимо будет выполнить следующий SQL запрос (вопрос "как это сделать" не входит в рамки нашей статьи, обратитесь к документации MySQL):

CREATE DATABASE IF NOT EXISTS trafficbd;
use trafficbd;

#
# Структура таблицы `traffic`
#

CREATE TABLE traffic (
id int(11) NOT NULL auto_increment,
date datetime NOT NULL default '0000-00-00 00:00:00',
ip varchar(20) NOT NULL default '',
inb int(11) NOT NULL default '0',
outb int(11) NOT NULL default '0',
KEY id (id)
) TYPE=MyISAM;

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

#!/usr/bin/perl
# Функция занимающаяся сбором и внесением данных в БД.
sub account{
$name=$_[0]; # Имя правила
$IP_IN=0; # Инициализация счетчиков
$IP_OUT=0;
# Командная строка MySQL для внесения данных в таблицу.
$mysqlcommand="/usr/bin/mysql -hlocalhost trafficbd -e";
# Снимем данные со счетчика входящего трафика и обнулим
$ipstuff=`/sbin/iptables -L -Z ACCT_IN_$name -v -x`;
# Выделим из вывода предыдущей команды значение счетчика
@IPTBMASS=split(/ /,$ipstuff);
chomp $IPTBMASS[2];
$string=$IPTBMASS[2];
$string=~ s/s{1,}/ /g;
@INFOMASS=split(/ /,$string);
$IP_IN=$INFOMASS[2];
# Снимем данные со счетчика исходящего трафика и обнулим
$ipstuff=`/sbin/iptables -L -Z ACCT_OUT_$name -v -x`;
# Выделим из вывода предыдущей команды значение счетчика
@IPTBMASS=split(/ /,$ipstuff);
$string=$IPTBMASS[2];
$string=~ s/s{1,}/ /g;
@INFOMASS2=split(/ /,$string);
$IP_OUT=$INFOMASS2[2];
# Получим текущее время
($min, $hours, $day, $mounth,$year) = (localtime)[1,2,3,4,5];
$time=$hours.":".$min.":00";
$mounth=$mounth+1;
$year=$year+1900;
$date=$year."-".$mounth."-".$day;
# Формируем SQL запрос
$sql="insert into traffic values('','".$date." ".$time."','".$name."','".$IP_IN."','".$IP_OUT."') ;";
# Выполняем его
`$mysqlcommand "$sql"`;
} # На этом функция account заканчивается
# Основная программа

$config=`./lconfreader.sh`; # Прочитаем конфигурационный файл.

# Ниже приводится текст скрипта lconfreader.sh:
# #!/bin/bash
# . ./lbiling.conf # Включить конфигурационный файл
# echo $ALLNETS # Вывести в stdout список всех сетей, покоторым ведется учет.
#

chomp $config;

@NETMASS=split(/ /,$config);

foreach $nets(@NETMASS)
{
# Для каждого элемента списка, выполнить функцию account
account $nets;
}

Вот собственно и вся биллинговая система

[wasil]

Разоблачение негативных мифов о спутниковом интернете

Многие пользователи интернет задумывались, о переходе от обычного
коммутируемого доступа, к более прогрессивным технологиям. Перед
ними стоял выбор - местные недорогие небольшие провайдеры,
крупные но бьющие по кошельку корпорации и компании, или спутниковый
интернет? Провайдеров также мучает аналогичный вопрос, подключиться
ли к местному "телекому", или найти независимый провайдер? Остро
стоит проблема скорости и надежности наземных коммуникаций,
недорогое оборудование не дает желаемой скорости, а дорогое мало
того, что не по карману, так как минимум нужно покупать комплект
для провайдера, и не исключено, что провайдер не захочет его
подключать, ну и конечно провайдеру невыгодно подключать
высокоскоростные линии, когда у него собственные каналы не могут
обеспечить должных скоростей. Как альтернатива возникает независимый
и недорогой доступ в сеть через спутник. Однако его "нестандартность"
отпугивает,как формулировками, так и неудачным опытом пользователей
попавших в период бума спутниковых провайдеров "однодневок".
Итак, начинаем разоблачать мифы о недостатках спутникового интернета.

Миф первый - ненадежность.
Если трактовать под понятием ненадежность, частоту отсутствия связи
по вине магистральной техники провайдера,
то можно сравнить спутниковый провайдер с наземным. Если спутниковый
провайдер чаще всего подключен к информационным магистральным европейским
каналам, и чаще всего к нескольким независимым (например PlanetSky -
KPN, Genuity, Concert), то местные "наземные" провайдеры, чаще всего
подключены по цепочке "местный телеком" - "региональный телеком" - "
бекбон к которому подключен телеком". Соответственно можно сделать выводы
о надежности связи. Бесспорно, что при отсутствии связи по земле,
асинхронный доступ работать не будет, но такая ситуация складывается
не так часто, более распространена ситуация "перегрузки" входящих
международных каналов "телекома" в часы пик, в большинстве
из-за дороговизны который вынужден перепродавать их полосу несколько раз.
Спутниковый интернет позволяет не замечать эту проблему, и иметь
собственный входящий международный канал.
Надежность собственно спутникового канала, намного выше наземных
коммуникаций. Для примера сравните качество спутникового телевизионного
канала, и наземного. Обеспечивается это двойным уровнем коррекции ошибок
(транспортный Viterbi, и инкапсулированный в MPEG2 Transport Stream
посредством добавления избыточного блока основанного на алгоритме
Reed Solomon). У PlanetSky через Viterbi добавляется 2 дополнительный пакета
на 3 полезных пакета, и если даже это не помогло, исправляется посредством
коррекции через Reed Solomon. Вероятность ошибки бита - 10^-11
на входе декодера MPEG-2. Для примера вероятность ошибки
в радиорелейных линиях 10^-8. Ненадежность кабеля как транспорта
в наших странах обычно сложно обсуждать, так как в большинстве случаев
дублирование и избыточность сопрягается с непозволительными расходами.
RadioEthernet не менее сильно подвержен влиянию погодных условий по
сравнению со спутниковым каналом связи , и не имеет надежного
механизма коррекции ошибок.

Миф второй - дороговизна
В настоящиее время спутниковые каналы успешно конкурируют с наземными
национальными провайдерами, и одна из причин успеха - более низкие цены.
Почему? Причины три
1)Нестабильность спроса и рынка требует быстрой окупаемости
вложенных средств, как следствие повышая стоимость услуг.
2)Эффект масштаба - удельное количество пользователей на население
значительно ниже, чем в странах с развитой информационной структурой.
3)Различие протяженности и маршрутов траффика, а именно
большая протяженность магистралей, и как факт - значительно более
высокие расходы на поддержку и создание новых коммуникаций.

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

Миф третий - низкая скорость из-за задержек
Многие менеджеры, технические работники и администраторы компаний беспокоятся,
что приобрев недорогой спутниковый канал, они снижают качество
доступа, и тщательно скрывают факт использования и не афишируют тип канала.
Однако зря. Почему?
Задержки имеют существенное значение только в интерактивных приложениях
требующих изменения данных синхронно с удаленными в течении не более 300
миллисекунд. Обычно это исключительно игры. Большинство других приложений
некритично к задержкам, хочу акцентировать внимание - это относится и к
VoIP(IP-телефонии) - задержка по магистральным трансатлантическим каналам в
США может составлять до 300ms, однако это не создает больших проблем.
2)Скорость передачи данных зависит от времени передачи пакета между серверами,
но существуют параметры в настройках операционных систем призванные устранить
снижение скорости из-за большого времени передачи. А именно это размер "окна"
TCP пакета. Принцип работы TCP/IP таков, что данные передаются "окнами" -
которые являются блоками данных определенной величины, и каждый из этих
блоков требует подтверждения. При увеличении задержки стандартный блок данных
слишком мал, и соответственно увеличение времени передачи пакетов сильно
снижает скорость обмена данными. Однако практически во всех современных
операционных системах есть возможность увеличить стандартный размер "окна"
до нужного, тем самым увеличив максимальную скорость передачи данных.
Многие спутниковые провайдеры в рекомендациях к настройке имеют приложенные
"патчи" или программы для коррекции размеров "окна" TCP, с их помощью
большинство пользователей без проблем достигают скоростей 1 Мбит/с, и
это не предел. Также существуют альтернативные протоколы и технологии,
разработанные специально для работы через спутник, к примеру
совместный проект "Satax", созданный зарубежной компанией для отечественного
крупнейшего реселлера спутникового интернета

Миф четвертый - Несовместимость и бесполезность спутникового оборудования.
Данное утверждение весьма существенно в наше время, как пример может послужить
постоянное обновление модемных технологий, и в итоге многие провайдеры
не могут применить "старые модемы", и вынуждены продавать их.
Спутниковое оборудование базируется на утвержденных и общепринятых
стандартах, широко применяемых также в спутниковом телевидении. Капиталы
вложенные в эту область бизнеса предполагают длительное функционирование.
Кроме того, рынок DVB интернета сейчас начинает активно развиваться, и для
подключения к другому провайдеру достаточно "повернуть тарелку". При полном
отказе от спутникового интернета, многие DVB карты можно применить для приема
спутникового телевидения.

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


Все статьи взяты с сайта http://www.d-v.ru/

[wasil]

MAC-адрес DVB-карты.

За подробным описанием того, что такое MAC-адрес, как он используется сетевыми устройствами и протоколами, отсылаю читателя к солидным изданиям, например CITFORUM.RU и PROTOCOLS.RU

MAC-адрес - уникальный серийный номер присваиваемый каждому сетевому устройству для идентификации его в сети. Каждый производитель присваивает адреса из принадлежащего ему диапазона адресов. Идентификатор производителя (OUI - Organizationally Unique Identifier ) занимает первые 3 байта MAC-адреса устройства Ethernet. Выделяет OUI международная организация Institute of Electrical and Electronics Engineers - IEEE.
MAC-адрес имеет длину 6 байт (48 бит), обычно записывается в шестнадцатиричном виде, например 00: 34: 56: 78: 90: AB и содержит знаки 0 - 9, A - F. Регистр символов роли не играет. Разделителтьные знаки (":" "-" и пр.) могут и отсутствовать, но их наличие делает число более читаемым. Для сетевых устройств первый байт всегда равен 00 (другие значения используются для broadcast и multicast -адресации)

Таблица MAC-адресов производителей спутникового оборудования

00-D0-5C Technotrend Systemtechnik GMBH SkyStar1
00-D0-D7 B2C2, INC. SkyStar2
00-30-6A PENTAMEDIA CO., LTD. Pent@
00-90-BC TELEMANN CO., LTD. SkyMedia
00-D0-72 BROADLOGIC
00-08-CA TwinHan Technology Co.,Ltd
00-30-05 Fujitsu Siemens Computers
00-D0-C1 HARMONIC DATA SYSTEMS, LTD.

Первые три байта MAC-адрес вашей DVB-карты обязательно должны соответствовать OUI ее производителя.

Как узнать MAC-адрес?
На упаковке ряда DVB-карт есть наклейка с MAC-адресом.

Наклейка на коробке Pent@Value

2. На самой карте может быть наклейка с MAC-адресом.

Наклейка на обратной стороне SkyStar1 rev 1.5

3. Программым способом

Windows. Способ 1
Запустите через Пуск->Выполнить программу Winipcfg (для Windows NT Wntipcfg.exe из Windows NT4 Resource Kit), выберите из списка интерфейсов DVB карту. В графе Адрес контроллера будет находится MAC адрес.

Вывод команды Winipcfg
Windows. Способ 2
Запустите через Пуск->Выполнить команду ipconfig /all. В появившемся списке найдите DVB карту. В графе Физический адрес будет находится MAC адрес. Если список быстро промелькнет, то используйте команду ipconfig /all | more или ipconfig /all /Batch [filename], где [filename] - имя файла в который будет записан вывод команды ipconfig


Вывод команды ipconfig /all
Windows. Способ 3
В программах настройки многих DVB-карт, тоже можно узнать MAC-адрес. Установите только сначала режим использования аппаратного MAC-адреса


SkyStar2, софт 4.14



SkyStar1

Linux
Команда ifconfig будет показывать MAC устройства определенный в настройкакх фильтра. Чтобы увидеть аппаратный MAC-адрес карты необходимо убрать из dvbdd.conf ВСЕ фильтры и перезапустить драйвера.

Если DVB-карта прежде была настроена на любую СКД, где используется режим вычисления MAC-адреса из IP-адреса (НТВ-интернет), то команда ifconfig будет показывать виртуальный MAC-адрес вида 00-02-xx-xx-xx-xx, где xx-xx-xx-xx - IP-адрес вашего внешнего интерфейса в hex-виде.

[wasil]

Электронный "сторож"

Каждый второй покупатель, впервые приобретающий спутниковую систему, задает вопрос: "А можно установить антенну в комнате?". Ответ повергает его в уныние - сопрут ведь! Алюминий нынче в цене. Или просто из баловства, из любопытства - снимут, испортят, в лучшем случае собьют настройку.
Что поделаешь - воруют в нашей стране. Воруют все подряд, нужное и ненужное. Железные двери, кодовые замки, противоугонные системы всевозможнейших конструкций и другие символы тотального недоверия прочно вошли в наш быт. В нашем городе на 300 угнанных автомобилей приходится только одна ограбленная "тарелка", но, увы, прецеденты есть. Если антенна смонтирована на стене или на балконе, добраться до нее ворам не так то просто. А вот если по каким-то причинам она установлена на крыше, ее безопасность становится головной болью для владельца.
Предлагаемое устройство является попыткой авторов каким-то образом решить эту проблему. "Сторож" представляет собой прибор, который включается в разрыв высокочастотного кабеля, идущего от спутниковой антенны к ресиверу. Электронный датчик контролирует ток, потребляемый конвертором. При обрыве цепи питания конвертора (отключение конвертора или обрыв кабеля) "сторож" выдает звуковой сигнал. Конечно, такое устройство не обеспечит полной сохранности антенны и конвертора, но, возможно, несколько успокоит их хозяина. По крайней мере, антенну не уведут "из-под носа".
Приведенный ниже вариант "сторожа" не имеет собственного источника питания и предназначен для работы с ресиверами, у которых в режиме "Standby" питание с конвертера не снимается. Этому условию отвечают почти все одновходовые ресиверы, предлагаемые на российском рынке, в том числе ресиверы "НТВ-Плюс". Сложнее с двухвходовыми аппаратами - как правило, питание подается либо на один вход, либо на другой, и в "Standby" питание остается только на том входе, который использовался последним. Если используется только один вход ресивера - беспокоиться не о чем. Разумеется, для работы "сторожа" необходимо, чтобы ресивер был постоянно включен в сеть.
Принцип работы прибора. Датчиком тока служит диод VD1. Ток, потребляемый конвертером, создает на нем падение напряжения, достаточное для надежного отпирания транзистора VT1. При пропадании тока конвертера транзистор VT1 запирается, запирает транзистор VT2, и на выходе элемента DD1.1 появляется уровень логического "0". Срабатывание датчика фиксируется триггером на элементах DD1.2 и DD1.3. Триггер включает генератор прерывистого тона на микросхеме DD2. Нагрузкой генератора служит пьезоэлектрический звонок HA1. Даже если цепь питания конвертера восстановится, сторож будет выдавать сигнал тревоги до тех пор, пока триггер не будет сброшен кнопкой S1. Питание всей схемы осуществляется от тюнера, ток, потребляемый в дежурном режиме, невелик и не влияет на работу конвертера. Катушки L1 и L2 представляют собой 4 - 5 витков эмалированного провода диаметром 0,5 - 0,7 мм без каркаса. Настройка прибора не требуется.
Вместо звукового генератора к выходу триггера можно подключить слаботочное реле, контакты которого будут включать мощную сирену, разрывать шлейф действующей охранной сигнализации и т. п. Авторы также надеются привлечь внимание производителей подобного оборудования - на основе нашего "сторожа" можно разработать прибор для серийного производства. Спрос на него наверняка будет - воруют в нашей стране...

DD1, DD2 - K561ЛА7
VD1 - КД 522 Б
VT1 - КТ 361 Б
VT2 - КТ 315 А
НА1 - ЗП-1
Рис. 1. Принципиальная схема "сторожа"

Статьи взяты с сайта http://www.d-v.ru

[wasil]

Передача Данных через DVB
Рост использования персоналом мультимедийных услуг Интернет и, в частности, использование world wide web, привел к всевозрастающей потребности в широкополосном доступе. Акценты сместились с простейшего Интернет доступа к ожиданию, что высокоскоростной доступ будет предоставлен где бы то ни было. Это бросило новый вызов индустрии сетевых решений и вскоре привело к созданию таких комбинированных ассиметричных систем доступа к Интернет с широкополосным спутниковым приемным каналом, как уже ставшая классикой система DirecPC американской Hughes Network Systems.
Вместе с ростом использования Интернет во всем мире наблюдалась и революция в передаче телевидения, с все более утверждающимся стандартом Digital Video Broadcast (DVB). Помимо высокого качества передачи и разнообразия сервисов, одной из основных задач, реализованных в DVB явилась DTH (Direct To Home) доставка большого количества цифровых каналов непосредственно на терминал получателя. Таким образом уже известный к этому моменту асимметричный доступ к Интернет получил возможность интеграции во множество спутниковых DVB систем, а пользователи получили возможность высокоскоростного (до 45 Мбит/сек) приема Интернет данных с использованием доступного комплекта, состоящего из небольшой спутниковой антенны и конвертора - (LNB -Low Noise Block), соединенных высокочастотным кабелем на ПЧ с приемным адаптером в виде PCI карты или Set Top Box (STB).
В большинстве потребительских систем обратный канал строится с использованием существующей наземной инфраструктуры и запросы пользователей отправляются стандартным модемом по обычному коммутируемому соединению с локальным ISP, обеспечивая таким образом экономичный двунаправленный доступ с требуемой полосой. В ряде случаев, например HNS IP Advantage (DirecPC Enterprise Edition), в качестве обратного канала используется дешевый низкоскоростной обратный канал, имеющийся в уже работающих корпоративных спутниковых сетях. Все эти системы обеспечивают низкую стоимость и широкую полосу доступа к Интернет для любой точки в пределах зоны покрытия спутника, используемого DVB системой.

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

Множество людей имеют опыт работы с реализациями таких соединений, которые на сегодняшний день устарели. Документы исследований, опубликованные в начале 90-х, связывали все проблемы с TCP, хотя большинство из них уже давно разрешены.

Во многих известных экспериментах использовались неправильно настроенные TCP-стеки. До недавнего времени не многие TCP-стеки допускали установки, необходимые для использования в спутниковых соединениях.

К сожалению, большинство исследователей все еще не в состоянии понять способ, по которому фактически функционирует TCP. Это свидетельствует об их плохой осведомленности. IETF недавно были вынуждены издать два документа, разъясняющих эти вопросы.

Результат всего этого это то, что у большинства остались чувства опасения, неопределенности и сомнения относительно того, функционирует ли TCP в спутниковых соединениях. Эти сомнения фактически не обоснованы, поскольку множество пользователей спутникового сервиса могут свидетельствовать об обратном. Первоначальная цель научно-исследовательской работы, в ходе которой был создан TCP, состояла в том, чтобы связать пилотную спутниковую сеть (SATNET) с наземным Интернет-сегментом (ARPANET). Хотя нет никаких практических ограничений производительности TCP (максимальная теоретическая производительность - 1.5 Gbps - быстрее, чем любое спутниковое соединение), существует ряд важных проблем, которые непосредственно не затрагивают эффективность, но о которых пользователи должны иметь правильные представления. Это основные отличия спутниковой связи от наземных каналов, оказывающие воздействие на производительность TCP:

Ошибки в спутниковом соединении

Временные задержки спутникового соединения

Ширина полосы частот и асимметрия соединений

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

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

Передача данных в Прямом канале.
Как правило в DТН системах данные занимают только часть полосы MCPC DVB канала и передаются в отдельном транспортном потоке MPEG-2 вместе другими с потоками видео и радио каналов. В SCPC системах данные являются единственным транспортным потоком, однако, содержащим всю служебную информацию DVB пакета. Помимо DVB DTH систем используются и другие варианты упаковки данных, как например в DirecPC. Передача данных может быть одно или двунаправленной (используя в качестве обратного канал управления) и может быть unicast (точка-точка), multicast (точка-многоточка) или broadcast (все адаптеры получают выделенный PID). Основным элементом данной конфигурации, отличающей ее от чисто телевизионной DVB системы, является IP/DVB шлюз (gateway, encapsulator), осуществляющий упаковку данных в формат транспортного потока DVB. Несколько лет назад DVB адаптеры для приема данных выпускались как правило фирмами, разрабатывавшими и сами IP/DVB шлюзы. Однако в настоящий момент стандартизация способов передачи данных в DVB системах позволяет выпускать адаптеры на готовых чипсетах все большему числу производителей. В стремлении стандартизировать эти устройства, DVB спецификации предполагают что данные могут передаваться одним из пяти способов:

Data Piping - дискретные порции данных доставляются по назначению используя транспортные пакеты. Синхронизация между пакетами данных и другими PES пакетами отсутствует.

Data Streaming - данные принимают форму непрерывного потока который может бытьАсинхронным, т.е. без временных меток, как пакеты данных в Интернет.

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

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

Multi-Protocol Encapsulation (MPE) - наиболее часто используемая сегодня технология, основанная на DSM-CC и предназначенная для эмуляции локальной сети при обмене пакетами данных.

Data Carousels - схема сборки в буфере наборов данных, которые многократно прокручиваются в периодических передачах. Наборы данных могут иметь любой формат или тип. Одним из примеров является передача данных Electronic Programme Guides (EPGs). Данные передаются используя DSM-CC секции фиксированного размера.

Object Carousels - Карусели "прокручивающие" Карусели Данных, первоначально предназначенная для услуг вещания (broadcast) services. Наборы данных определены спецификацией DVB Network Independent Protocol и могут использоваться к примеру для загрузки данных в DVB декодеры.

Для передачи Интернет данных рекомендуемой процедурой является использование MPE схемы. Обратная совместимость с нестандартными схемами передачи данных использующими piping/streaming механизмы достигается присвоением зарегистрированного Service Information (SI) кода каждому формату данных. Каждый SI код, который распознается приемником/декодером обрабатывается, обеспечивая поддержку нестандартного кодирования соответствующими аппаратными средствами.

[wasil]

Факторы, влияющие на скорость приема данных.

В данный момент большинство пользователей спутникового интернета испытывает проблемы, связанные со скоростью получения данных. В связи с этим назрела необходимость дать краткие разъяснения, от каких параметров зависит скорость, а так же некоторые замечания по поводу работы TCP/IP в спутниковых системах.
Система передачи данных через спутник способна обеспечить однонаправленную передачу данных пользователю, обратная связь часто обеспечивается по наземным линиям связи, т.е. по обычному Dial-Up. Такой тип подключения приводит к тому, что мы имеем соединение с различной пропускной способностью к пользователю и от него. Большой процент пользователей (обычно около 85% от общего числа абонентов ISP) в основном получает информацию, нежели передает, поэтому такая асимметричность канала оправдана. Но высокая степень зависимости каналов (в большей степени это относится к обратному каналу) друг от друга становится критическим моментом для работы с подобной системой.
Пропускная способность TCP/IP соединения ограничена двумя пунктами:

· временем возвращения - RTT round trip time

· размером TCP окна.

Производительность DVB-систем построена на возможности IP->DVB шлюза устанавливать максимальные размеры TCP окон, а именно делать их равным 65535 байт. Использование конечным пользователем TCP стеков, отвечающих всем современным стандартам, позволяет IP->DVB шлюзам выполнять RFC-1323, имеющей возможность запрашивать увеличение размера окна для повышения пропускной способности канала.

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

Какие же негативные моменты порождает данный процесс?

Данный процесс особенно негативно отражается на работе с web-узлами, т.к. IP протокол имеет ряд «медленных» мест, а именно IP протокол начинает эффективно работать только тогда, когда от запрашиваемого узла получен основной «скелет» страницы, основной HTML код и начинается подгрузка остальных объектов (картинок, апплетов и т.п.).

Любое соединение начинается с запросом клиентом TCP-соединения с Интернет, после чего клиент запрашивает требуемый HTML-документ, обычно это корневая страница сервера. Сервер подтверждает запрос и начинает передачу данных. Сначала он отсылает только один пакет и получает подтверждение о его приеме (ACK), но обычно страница имеет размер больший, нежели чем размер пакета, и сервер передает столько пакетов, сколько требуется для полной передачи запрашиваемой страницы и, соответственно, получает столько подтверждений, сколько необходимо. Если Вся страница передана, то сервер посылает пакет с информацией о конце передачи (FIN).

После получения основного «скелета» страницы, клиент, а точнее его броузер, анализирует поступивший код, на предмет наличия в нем ссылок на графические или еще какие либо объекты. После этого он открывает необходимое количество соединений и начинает получение этих объектов.

Как видно из следующего примера, чем больше объектов имеет запрашиваемая страница, тем выше будет скорость передачи.

Количество объектов
Скорость передачи, Кбит/сек
Время передачи

2
34
3 sec

4
83
3 sec

8
140
3 sec

16
295
3 sec

32
560
3 sec

Как видно из этих данных, наибольшая скорость была достигнута на страничке, имеющей 32 встроенных объекта, но на практике такая ситуация случается довольно редко и средняя скорость при серфинге обычно не превышает 30 – 100 Кбит\сек.

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

В случае получения большого объема данных с использованием DVB системы приходится заниматься подстройкой TCP стека самостоятельно, соответствуя рекомендациям ISP.

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

Выходом из данной ситуации является увеличение размера TCP окна, а именно приводу его к размеру 32768 байт или более. Но также необходимо учесть, что при скорости соединения ниже, чем 19.200 время на передачу пакетов начинает значительно возрастать, вследствие чего может потребоваться менять значения на другие, подобранные экспериментальным путем.

Наиболее оптимальные значения MTU и MaxRcvWindow является:

MTU: 1020 и выше.

MaxRcvWindow: 32768

[wasil]

Настройка "полярки" - это технология

Ветераны спутникового телевидения вспоминают, как ожидали звездную ночь, готовили подвеску антенны для установки телескопа и настраивали полярную ось подвески на Полярную звезду с помощью телескопа. Вспоминают, как ожидали солнечного полдня, чтобы по часам и отвесу точно определить направление "север-юг". Эти времена прошли. На продолжительность всепогодной настройки полярной подвески можно объявлять соревнование мастеров, и многие уложатся в полчаса, хотя обычно профессионалы не спешат.
Настройка полярной подвески стала сегодня ясной технологией. Идея полярной подвески заключается в том, чтобы вращать параболическое зеркало вокруг оси, параллельной оси вращения Земли. В таком случае, если настроить зеркало на вершинный спутник, можно ожидать, что луч антенны отследит геостационарную орбиту спутников-ретрансляторов при вращении вокруг полярной оси.

Рис. 1 поясняет стереометрию этой идеи. Поскольку оси вращения Земли и полярная ось в подвеске антенны разнесены в пространстве на расстояние, соизмеримое и с радиусом Земли, и с радиусом геостационарной орбиты, то возникает принципиальная ошибка метода, ее угловая мера обозначена на рис. 1 углом X. Это угол между направлением на крайний спутник и главным лепестком диаграммы направленности антенны, настроенной по вершинному спутнику, при повороте ее на крайний спутник при d = dmax на данной местности. К счастью, угол ошибки X — малый угол.


рисунок 1

Если зеркало установлено на подвеске так, что главный лепесток диаграммы направленности перпендикулярен полярной оси подвески, то в процессе вращения зеркала относительно полярной оси главный лепесток ("луч") антенны будет параллельным плоскости экватора и никогда не пересечет орбиту спутников-ретрансляторов. Для настройки антенны на геостационарную орбиту луч надо опустить на угол y, называемый углом склонения. Угол склонения y рассчитывается по следующей формуле (2).

sin Ф y = arctg --------------- (2) 6.618 - cos Ф Сразу укажем предельные значения y согласно приведенной формуле (2): на экваторе (Ф = 0) имеем y = 0; далее функция y = y(Ф) монотонно возрастает при увеличении Ф и на предельной широте cos Ф = 0,1511 имеем ymax = 8,7°; на широте Полтавы угол склонения y = 7,3°, Киева y = 7,4°, Москвы y = 7,8°, С.-Петербурга y = 8,1°. Оговоримся, что в реальных условиях угол склонения y содержит в себе не только упомянутую добавку к углу широты, но также всю погрешность "верх-низ" в расположении конвертора относительно точки истинного фокуса зеркала. Настройщики знают, что недогнутые и перегнутые консоли тоже "сидят" в этом угле и вызывают его отклонение от расчетного значения.

Опишем конструкцию типичной полярной подвески (см. рис. 2). Подвеска устанавливается на цилиндрическую опору в виде вертикальной трубы, присоединительная часть подвески выполнена при этом в виде прямоугольного или цилиндрического стакана, снабженного болтами. Иногда болты позволяют выровнять стакан, если труба не достаточно вертикальна. К стакану крепится большой флаг, содержащий полярную ось, относительно которой организуется вращение зеркала. Поскольку полярная ось должна быть наклонена к горизонтальной плоскости под углом широты Ф, то на большом флаге имеются соответствующие регулировочные пазы и болты для фиксации установленного угла. Между полярной осью и зеркалом вводится еще один механизм, на рис. 2 он назван "малый флаг", который осуществляет отклонение зеркала вверх и вниз на угол склонения y. Наконец, между большим флагом и зеркалом устанавливается актуатор, для чего на большом флаге есть место для закрепления хомута корпуса актюатора, а на зеркале имеется кронштейн для закрепления выдвижного штока актюатора.

Теперь у нас достаточно данных для описания технологии настройки полярной подвески. Во-первых, настраиваем вертикаль опорной трубы. Строго говоря, это не всегда обязательно: иногда отклонение опоры от вертикальности компенсируется настройкой стакана, отклонение от вертикальности в направлении "север-юг" полностью компенсируется при настройке угла широты, а отклонение от вертикальности в направлении "запад-восток" частично компенсируется отклонением большого флага в том же направлении "запад-восток". Тем не менее, добротная вертикаль опорного устройства развязывает настройщику руки, а наклон опоры, наоборот, загоняет настройщика в угол. Все дело в том, что в процессе настройки приходится вращать большой флаг в направлении "запад-восток" с тем, чтобы большой флаг занял в итоге точно южное или почти точное южное направление. Если опора наклонная, то при этом вращении будет меняться еще и угол широты, а нагромождать кучу проблем с регулировкой сразу двух ответственных углов — тяжелая форма самоистязания. Обычно точность вертикали ±(0,3-0,5)° достаточна. Вертикаль контролируется в двух плоскостях отвесом или по углам близкорасположенных зданий.

Рисунок 2.

Во-вторых, устанавливаем угол широты. Чтобы не было влияния погрешности установки вертикали, лучше этот угол контролировать и настраивать после установки подвески на вертикальную опору. Но конструкция подвески не всегда это позволяет. В таком случае угол широты может быть настроен до монтажа подвески и антенны в целом на вертикальную опору, но тогда за вертикальностью опоры следует особо последить. Настройка угла широты выполняется универсальным угломером с градусной шкалой, а если требуется лучшая точность, а она требуется, то следует изготовить прямоугольный треугольник с углом широты Ф при одной из вершин и размером катетов примерно = 200 мм. При другой вершине окажется дополнительный угол (90° — Ф), тоже полезный при настройке. В процессе измерения угла широты контролируется горизонтальность или вертикальность одного из катетов уровнем или отвесом, или же по углу расположенного рядом здания.

В-третьих, настраивается угол склонения. Процедура настройки следующая. Включается электроника и настраивается на прием вершинного спутника, угол склонения устанавливается на ожидаемое расчетное положение, например, в Полтаве — 7,2°, а большой флаг предварительно ориентируется на юг, например с точностью ±(5-10)°. Угол склонения устанавливается по лимбу изготовителя или через пересчет в угол длин элементов конструкции, если лимб не предусмотрен. Ориентация на юг осуществляется по компасу, по Полярной звезде, по стенам церквей, по солнцу в полдень, по большим флагам расположенных рядом антенн с полярной подвеской или по опыту установки антенн в данном районе города (в данной местности). Далее актюатором (но возможно и вручную) зеркало проворачивается на ±(10-20)° влево-вправо с целью захватить сигнал вершинного спутника. Захват происходит эффективно, если выбран спутник, транслирующий в С-диапазоне, т.к. при больших длинах волн луч (главный лепесток) у антенны шире. В центральных районах России и на Украине таким спутником является "Горизонт-40Е", настройка на программу "РТР", транслируемую на низкой частоте f = 3,675 ГГц с большим уровнем сигнала, очень удобна для захвата. Далее следует оценить визуально угол между большим и малым флагами, измеряемый в плоскости, перпендикулярной полярной оси. Этот угол назовем "угол поворота" и обозначим T. Этот угол близок к относительной долготе спутника d, однако больше его. Величина угла поворота T связана с величиной угла относительной долготы спутника d следующими соотношениями (3):


Для вершинных спутников cosd ~= 1, откуда следует, что и cosT ~= 1; при дифференцировании левой и правой части равенства получаем при cosd ~= 1 ~= cosT и sind ~= d, sinT ~= T для вершинных спутников (4):

d ~= (1 - m)*T = (1-0,1511*cos Ф)*T (4) Поскольку m << 1, то этой точностью можно считать, что для вершинных спутников d ~= T. В Полтаве, например, m ~= 0,1; для спутника "Горизонт-40Е" имеем d = -5,4° и T ~= -6,0°, для спутника "Галс-36Е" имеем d = -1,4° и T ~= -1,6°. Для окраинных спутников T > d.

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

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

После захвата вершинного спутника для выполнения точной настройки угла склонения y следует перейти на высокочастотные программы "НТВ-Плюс" со спутника "Галс-36Е", при приеме которых луч антенны существенно более острый, или расстроить настройку радиоканала при приеме программы "РТР" со спутника "Горизонт- 40Е", с тем чтобы сделать более критичной расстройку по углу T. Изменяя далее угол склонения y, добейтесь наиболее широкой зоны устойчивости изображения при варьировании угла T. Удобнее всего это делать в разности числа отсчетов сенсора актюатора, индицируемых тюнером-позиционером. Со временем даже выработаются стереотипы на число этих отсчетов для антенн разных диаметров. После этого возможно слегка расстроить антенну, подняв луч (уменьшив угол склонения) на величину половинного угла ошибки. Настройка угла склонения завершена.

В-четвертых, настраиваем угол "север-юг" большого флага. Расширяем варьирование угла поворота T и включаем в меню настройки сначала спутники"Eutelsat 13Е" (программы "Eurosport", "Euronews" и "BBC world") и "Intelsat 63E" (программы "IRIB"), а затем еще далее на запад к спутникам "Intelsat 1W" (программы "TV NORGE", "TV5") и "Экспресс-14W" (программа "НТВ") и на восток к спутнику "Экспресс-80E" (программы "АСТ 2х2", "ТВ-6", "ТВ-3"). Варьируя большой флаг в направлениях "восток-запад", добиваемся наилучшего качества приема. При этом перемещение большого флага, например, на восток, означает подъем луча антенны для восточных спутников и опускание — для западных. Всякий раз после очередного поворота большого флага следует актюатором находить зону наилучшего приема и сравнение качества изображения проводить только при этом условии.

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

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

Материалы взяты с сайта http://www.russat.info

[wasil]

Зачем нужен специальный рассчитанный облучатель для каждого типа антенны?
Облучатель формирует нужную диаграмму направленности конвертора. Поясним принцип работы облучателя на рисунках:

На рис.1 изображена прямофокусная антенна с облучателем имеющим угол раскрыва 120 град. Облучатель спроектирован правильно и электромагнитное пятно не выходит за геометрические границы антенны.

На рис.2 изображена та же антенна, но с облучателем, имеющим угол раскрыва 90 град. Из рисунка видно, что больше половины площади антенны не используется. Для этой антенны облучатель выбран не верно. Усиление антенны снизится.

На рис.3 изображена офсетная антенна с правильно выбранным облучателем.

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

[wasil]

Анализ состояния и роли Клиентских Служб в ДС


Несколько лет назад среди сетестроителей бытовало мнение что достаточно создать технически идеальную сеть и предоставлять высококачественную в техническом смысле услугу за разумные деньги – и пользователь будет доволен и счастлив и низа что не променяет такого Оператора на конкурента.
Участники рынка Широкополосного доступа рассматривали и бились за два основных конкурентных преимущества – за цену и за техническое качество услуги, пытаясь предложить первое как можно ниже и второе как можно выше. Многим удалось и то и другое – однако доволен ли пользователь? Что бы разобраться в сложившейся ситуации позволим себе сделать некоторые утверждения и обосновать их по ходу статьи.

Утверждение первое.
Современные показатели ARPU в районе 15-20 у.е. с домашнего клиента в секторе домашнего широкополосного доступа не позволяют операторам оказывать качественные услуги населению.

Да, именно так. «Киты» телекома (Стрим, Центел, Корбина), рвясь на рынок Широкополосного доступа загнали себя (да и операторов ДС тоже) в ценовой угол, опустив цены до уровня при котором прекрасно можно предложить пользователю технически качественную услугу, но вот обслужить клиента за эти деньги уже не получается как ни крути.
Речь в данном случае идет не о качестве самого соединения с Интернетом – ширине канала, надежности сети и т.д. – речь сейчас о Customer Service, т.е. обслуживании клиента как такового. Широкополосный доступ в сеть Интернет это достаточно сложная многоаспектная услуга требующая от пользователя некоторого багажа знаний как об Интернете как таковом, так и о компьютере, сетях, протоколах и т.д.

Во времена модемной эры, решение обзавестись доступом в Интернет приходило к человеку после достаточно долгого периода использования домашнего или рабочего компьютера и далеко не каждый, у кого был дома компьютер, мечтал о модеме. Причин тому несколько – во первых Интернет тех времен был мало функционален для простого человека и воспринимался как экзотическая приблуда к компьютеру. Так или иначе, но к покупке модема и последующей покупке диалапного доступа пользователь подходил достаточно подготовленным PC-пользователем. Другим немаловажным моментом является и то, что подключать модем и настраивать соединение пользователю приходилось самому, что дополнительно положительно сказывалось на уровне подготовки. Плюс к этому, у пользователя модема однозначно складывалось понятие «клиентское оборудование» работающее ровно настолько насколько пользователь сам его настроил.
Напротив, сейчас, когда цена подключения выделенной линии упала чуть ли не до 1500 рублей, (или до 0 кое-где) которые и то идут на счет, человек купивший только что компьютер максимум через пару дней заказывает «выделенку» домой.
Заметьте что после того как пришли монтажники – все подключили и настроили – наш новоиспеченный пользователь садится за PC во-первых мало что понимая «как это работает» и во-вторых будучи полностью уверенным что Интернет на его PC есть только потому что в него сзади воткнули кабель – ну вы понимаете – как антенну в телевизор, это совершенно естественно – ведь весь процесс создания и настройки соединения на PC для человека остался за кадром.

Вывод: Средний новоподключенный пользователь широкополосного доступа требует наличия постоянной предельно тактичной и грамотной телефонной технической поддержки по базовым вопросам касающимся основ предоставления услуги и основ работы ОС Windows касающихся работы сетевых приложений.

Можно долго рассуждать о том обязана ли Техническая Поддержка по телефону объяснять пользователю, как зарегистрировать почтовый ящик на Яндексе или как найти в Интернете сайты посвященные вязанию крючком, но существуют и менее забавные вопросы, касающиеся использования непосредственно ресурсов сети Интернет. Казалось бы – пользователю можно ответить следующим образом – наша компания по договору о возмездном оказании услуг доступа в сеть Интернет обеспечивает Вам связность с узлами сети, а работа, правила и способы использования отдельных ресурсов принадлежащих третьим сторонам не имеют прямого отношения к предмету такого договора и консультаций, касающихся работы отдельных ресурсов мы не производим – всего доброго.
Однако при всей правильности и юридической чистоте такого заявления, операторы стараются в основном не посылать клиента даже в такой мягкой форме, ибо понимают – клиент такого не простит, и если не отключится то уж, по крайней мере, соседям и знакомым расскажет что мол «только деньги дерут – чисто совковая контора».

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

Суммируя опыт общения с пользователями широкополосного доступа выяснилась интересная тенденция – клиенты начинают считать оператора связи обязанным решать все их проблемы связанные с компьютером – всем знакома логическая связка при которой пользователь обращается к оператору с жалобой типа «Не работает Интернет» после чего присланный оператором специалист обнаруживает полуразложившийся Windows с букетом вирусов на любой вкус и обоснованно сообщает пользователю – «Windows умер и Интернет не работает из-за кучи вирусов – проще переустановить ОС чем вылечить.» Переустановка ОС стоит от 500 до 1500 рублей, однако пользователь платить не хочет – мол «до Вашего Интернета у меня все было отлично, а вирусов я из Вашей сети нацеплял – требую переустановить Windows бесплатно!». Конечно, велико количество и вполне вменяемых обращений – вроде установки антивируса или принтера/сканнера. Ответ технической поддержки на подобные обращения в стиле: «Мы не оказываем таких услуг» вполне законен, но пользователем расценивается опять же как «совковый сервис»

Вывод: Оператор широкополосного доступа должен быть готов на возмездной основе оказывать услуги «компьютерной помощи» не связанной напрямую с услугами доступа в Интернет.

Огромный поток обращений в службу технической поддержки вызывают так же вопросы, связанные с нюансами тарификации услуг, условиями смены тарифных планов, оплатой услуг и т.д. Несовершенство и сырость биллинговых систем, как в пионерских сетях, так и у крупных операторов, отсутствие полностью автоматизированных «личных кабинетов пользователей» в биллинговых системах порождает большое количество аккаунтинговых манипуляций требующих обращения «голосом» в клиентскую службу и последующих «ручных» действий аккаунтингового персонала. Стоит ли говорить о том, что разработка и внедрение полностью продуманных биллингово-мониторинговых инструментов для ДС/Широкополосного доступа задача настолько же трудоемкая насколько и дорогая.

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

Наличие бесплатной «локалки» в ДС является вторым по значимости стимулом привлекающим новых пользователей после собственно дешевизны подключения и доступности тарифов. Чего ожидает от локальной сети только что подключенный новичок? Трудно сказать... Однако это точно не перспектива пользования сканнером для выявления ftp-серверов и не выспрашивание логинов и паролей к ним на IRC-канале сети. Типичные вопросы и крики в форуме любой ДС или даже в форумах породистых операторов типа Центел или Корбина:
– как войти в локальную сеть?
– не могу ничего скачать из локальной сети – ни один сервер не открывается.
– фильм скачивается 10 часов – что за тормоза?
– Недавно подключился – сетка полное *****, фильмов мало, серверов нормальных нет!
Основная форма локальных ресурсов ДС это ftp-сервера пользователей – надо заметить форма крайне непригодная для создания «продукта», который можно было бы не то что продавать, а хотя бы предлагать в качестве бонуса. В результате мы имеем горстку продвинутых пользователей (обычно не самых платежеспособных) которые все знают, все умеют и всем пользуются (редко оплачивая основные услуги) и кучу недовольных (регулярно платящие и платежеспособные пользователи) которые тыкаются по файловым помойкам в сети, чувствуют себя обманутыми и все больше разочаровываются в том что называется ДС. Приведу реальный флейм из форума ДС, очень красочно живописующий такую ситуацию:

«В общем локалка-*****!!! Я ни с одного ресурса скачать ничего не могу!!! Я ***** не программист чтобы еще додумывать как и чего качать, я должен включить компьютер и наслаждаться - именно за это я деньги и плачу!!»


Вывод: Оператор Широкополосного доступа должен либо создать интегрированную систему организации мультимедийного контента, либо возложить на службу Технической Поддержки обязанность подробно консультировать пользователей по вопросам пользования бесплатной локальной сетью.

Что же получается?
Пользователь не успев подключиться через пару часов уже накручивает номер Технической Поддержки своего Оператора с полным ртом вопросов из серии «А что...? А как...? А где?». Складывается парадоксальная ситуация – вновь подключенный пользователь получает домой технически качественную услугу (надежное соединение, обещанная ширина канала)... и не знает, что с этим делать или имеет больше вопросов по услуге, чем реальных навыков.

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

Все вышеприведенные выводы говорят о том что наряду с «техникой» услуг связи, Оператор так же нуждается в мощном хорошо организованном консалтинговом подразделении выполняющем задачи технической поддержки и аккаунтинга пользователей.

Заметьте, все вышенаписанное относится к консультативным услугам, которые пользователь должен получить бесплатно (за исключением компьютерной помощи) в нагрузку и в обеспечение платной услуги о которой, как таковой мы не сказали в данной статье ни слова – не о каналах, не о цене трафика, не о технических аспектах построения и работы сетей - только препарировали Клиентскую Службу – так называемый хелп-деск, Customer Service, call-центр – назовите как угодно.
Поставьте перед собой вопрос – «А сколько бы стоили такие услуги отдельно?» Ну скажем, есть некий провайдер Х и он по условиям договора предлагает свою услугу «as is» оговаривая в договоре что услуги технической и иной поддержки оказывает другая компания Y услуги которой пользователь оплачивает отдельно, исходя из например количества обращений или времени проведенного на линии у сотрудника call-центра.

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

Что же получается? Неужели до ¼ части от валового дохода (или от ARPU) оператор должен потратить на Customer Service?
Судя по всему должен. Боюсь что специалисты «Китов» не учли размеры затрат на качественный Customer Service когда планировали вторжение на рынок Широкополосного доступа. Объяснить это можно только тем, что этот вид бизнеса в новинку традиционным Операторам, знакомым в основном с технической поддержкой модемных пользователей и юридических лиц.

Утверждение второе.
Наличие и качество Клиентского Обслуживания (Customer Service) является важнейшим конкурентным преимуществом наряду с техническим качеством услуг связи и ценой этих услуг.

Цены в Москве на широкополосный доступ полностью стабилизировались вокруг 30-35 у.е. за самый дорогой/быстрый и 10-15 у.е. за самый дешевый/медленный Интернет. Колебания в стоимости услуг вряд ли предвидятся – возможны изменения количества услуг внутри относительно фиксированных ценовых рубежей «бюджетный», «комфортный» и «престижный».
В этот момент участники рынка начнут изыскивать дополнительные средства борьбы за клиента. Цена услуг, как конкурентное преимущество, себя исчерпала – ее дальнейшее снижение будет самоубийственно даже для самых крупных игроков рынка. Качество услуг? За исключением совсем маргинальных и некоммерческих сетей, качество ДС достигло определенного уровня и постоянно растет, ну а сети, строящиеся Центелом и Корбиной, по определению, не должны быть хуже.
Остается только повышать качество Клиентских Служб.

Прогноз: Как только рынок «наестся» предельно дешевого Широкополосного доступа, наступит недолгая пауза и очень вероятен некоторый рост цен (ARPU до 30 у.е.) у тех операторов которые сумеют создать отлаженные Клиентских Службы способные переварить огромные потоки обращений стремительно растущей клиентской массы. Такие операторы найдут своего клиента – я уверен это будет не малый кусок рынка. Предельно дешевый анлим с сервисом из цикла «дешево и сердито» так же будет востребован не меньше - благо IT-навыки населения медленно но растут.
В добавление к прогнозу можно сказать, что современный уровень Клиентских Служб у подавляющего большинства Операторов еще очень далек даже от «дешево и сердито».

[wasil]

Зачем нужен космический шлюз

Шлюзы позволяют ускорить TCP-потоки в спутниковых каналах связи
Спутниковая связь — идеальный способ «протянуть» Internet-соединения туда, где нет адекватной наземной инфраструктуры. Армады спутников связи способны обеспечить сетевой доступ чуть ли не из любой точки земного шара, обещая в скором времени расширить «космическую» полосу пропускания.

Однако несмотря на то, что протоколы TCP/IP были разработаны специально в расчете на сетевые инфраструктуры любых типов, особенности протокола TCP применительно к условиям передачи, характерным для спутниковых каналов, может серьезно ограничить пропускную способность последних. Преодолеть эти ограничения призваны новые решения — шлюзы протоколов, или ускорительные прокси-серверы.



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

Задержка: геосинхронные спутниковые орбиты проходят на высоте 14 тыс. км, в результате чего общий цикл прохождения сигнала к спутнику и затем от него на одном участке спутниковой сети составляет примерно 540 мс. Если не проводить специальную настройку параметров TCP, типичный размер окна приема, равный 8 Кбит/с, устанавливает предел пропускной способности одного соединения на уровне всего лишь 120 Кбит/с.
Ошибочные биты: протоколом TCP предполагается, что потери данных вызываются перегрузками в сети, а не другими факторами, и потому TCP оказывается крайне чувствителен к тем уровням потерь, которые характерны для спутниковых и прочих беспроводных каналов.
Асимметрия полосы пропускания: по соображениям экономии в спутниковых сетях широкий прямой канал часто сочетается с узким обратным. Однако, если такая асимметрия окажется слишком значительной, обратный канал может резко замедлить общее быстродействие.
Эти проблемы допускают частичное решение: например, можно соответствующим образом настроить стек TCP на оконечных узлах и воспользоваться такими нетривиальными возможностями TCP, как масштабирование окна передачи и выборочное подтверждение приема. Однако подобный подход, как правило, оказывается непрактичным, поскольку требует конфигурировать на каждом конечном узле стек TCP/IP таким образом, чтобы он поддерживал эти возможности.

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

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

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

Статья взята с сайта http://www.osp.ru

[wasil]

Когда DVB-ресивер не имеет драйверов под данную ОС.

Допустим, ваш локальный сервер работает под уникально редкой ОС, под которую не имеет драйверов ни одна DVB-карта, или имеет, но только одна, которая вас не устраивает по каким-либо причинам. Тогда подключиться к одностороннему спутниковому интернету можно тремя способами:

Поменять ОС локального сервера на такую, для которой есть драйвера DVB-карт.
Использовать внешний DVB-ресивер, например Pent@Office, подключаемый к вашему локальному серверу как сетевое устройство.
Поставить на отдельный PC под удобной ОС карту DVB-ресивера и заставить этот компьютер передавать на локальный сервер все пакеты, получаемые ресивером от спутникового провайдера.
Первый способ отбросим как невозможный в данном случае (иначе, и проблемы не было бы)
Второй способ требует приобретения довольно дорого устройства, чьи преимущества в полной мере могут и не понадобиться.
А вот третий способ как раз и будет рассмотрен в этой статье.

Схема роутинга в локальной сети с сетевым DVB-ресивером
Схема установки соединения в этом случае подобна схеме поключения Pent@Ofice:

Сетевой ресивер и локальный сервер находятся в одной локальной сети.
Локальный сервер имеет свой собственный запросный канал.и раздаёт интернет на остальные машины в сети.
На локальном сервере устанавливается соответствующее VPN или прокси-соединение со спутниковым провайдером.
Сетевой ресивер отправляет пакеты от сатинет-провайдера на локальный сервер и этим исчерпывается его роль в интернет-доступе.

Преимущества такой схемы подключения:

Кросплаторменность
Отсутствие вмешательства в ядро операционной системы локального сервера. Изменения касаются только настроек сетевых подключений.
Большую лёгкость в обслуживании за счёт возможности отключить DVB-ресивер, не перегружая сервер

Настройка
Идея состоит в том, чтобы в этой же схеме заменить сетевой DVB-ресивер системным блоком с установленной на нём DVB-картой.Предлагается взять машину под Windows 98 (как самой простой в использовании) желательно, не обременённую другими задачами, установить на ней DVB-карту (драйвера для Windows есть у них у всех, но возьмём для примера SkyStar 2, как самую дешевую) и внести необходимые изменения в регистр и настройку сети. Это может дать:

Экономию. Например, системный блок необходимый для нормальной работы SkyStar 2 на Караваевых Дачах в Киеве можно собрать за $100-120. Вместе со SkyStar 2 это обойдётся примерно в $200, т.е на уровне SkyStar 1, которая считается единственной пригодной DVB-картой под Unix FreeBSD
Удобство настроек. Настраивать стандартный софт той же SkyStar под Windows гораздо удобнее, чем Telnet'ом настраивать Pent@Office.

Берём системный блок с сетевой, и устанавливаем на него DVB-карту. Установка не будет отличаться ничем от описаных на этом сайте для соответствующих провайдеров и тюнеров.
Включаем роутинг. Для этого нужно установить в "1" параметр HKEY_LOCAL_MACHINESystemCurrentControlSetServicesV xDMSTCPEnableRouting.

Убедиться, что маршрутизация включена, можно при помощи "Пуск"->"Выполнить"->"winipcfg".
Указываем сетевой карте машины с DVB в качестве шлюза по умолчанию локальный сервер:

Это необходимо для того, чтобы наша Win 98 "знала", куда отправлять предназначеннные нам пакеты, которые SkyStar 2 выделит из общего DVB потока по MAC-адресу.
Перегружаемся. Теперь мы полностью подготовили к работе компьютер, который будет вылонять роль сетевого DVB-ресивера.
Настраиваем на локальном серверке необходимое прокси- или VPN соединение со спутниковым провайдером.

(по материам сайта http://www.rokc.ru)

[wasil]

GPRS на Dreambox

Итак, сегодня мы расскажем о том, как можно подключить свой сотовый телефон к спутниковому ресиверу Dreambox. Далеко не секрет, что мы с Вами живем в век господства электроники. Но даже при этом не у всех есть возможность использовать ресурсы всемирной сети Интернет. Любителям спутникового телевидения и счастливым обладателям "коробок мечты" ресиверов dreambox не стоит так сразу отчаиваться, соединение с Интернет теперь возможно через мобильный телефон (хочется отметить, что это можно было сделать и ранее, но в связке dreambox -> компьютер -> телефон). Ниже будут описаны практические советы подключения по данной схеме, те же, у кого есть стабильный выход в интернет по Ethernet, могут пропустить эту статью.

Для тестов нам понадобится один из ресиверов dreambox серии DM500,DM56x0,DM7000. Прежде всего нам потребуется заменить программное обеспечение в ресивере. Бесплатно скачать его можно на нашем download центре DOWNLOAD. После установки нового ПО и всех настроек (поиск каналов, установка настроек сети и.т.д ) можно приступать к установкам GPRS.
Для корректной работы GPRS нам необходимо в Expert Menu-> Communication setup выставить следующие параметры (фото 1).

1 – IP адрес нашего Dreambox в локальной сети (если у вас нет локальной сети, то оставьте это поле без изменения) .
2 - Маска подсети согласно ваше сети (если у вас нет локальной сети, то оставьте это поле без изменения).
3. - В Name Server нужно выставить адрес DNS сервера, который Вам выдает Ваш оператор мобильной связи, в чьей сети вы будите пользоваться услугами GPRS.
4. - GateWay - в этом поле нужно поставить "0", так как при поднятии ppp сессии маршрут по умолчанию для выхода будет замен IP адресом шлюза провайдера. Ну и не забываем сохранить наши настройки, нажав зеленую кнопку “сохранить”.
Далее нам понадобится мобильный телефон с поддержкой GPRS протокола.
Теперь соединяем наш телефон и ресивер посредством кабеля. В телефоне активируем режим поддержки GPRS ( у Вас уже должна быть активирована услуга мобильного интернета и передачи данных, если нет, то узнайте у Вашего оператора мобильной связи, как это сделать.)
Ну а теперь, наверное, самое простое, что можно сделать. Это синий кнопкой вызвать окно plugins и выбрать опцию “GPRS Connect” (фото 2).

Если Вы все сделали правильно, в окне появится лог соединения с провайдером (фото 3) . Связь установлена

[wasil]

Проблема
Удивительные вещи могут случиться, если компьютер, в котором стоит SkyStar, подключен к сети электропитания с заземлением (розетка с тремя контактами). В этом случае, если по тем или иным причинам тарелка также оказывается заземлена (через железную крышу или арматуру в бетоне), то между землей компьютера и землей тарелки начинает течь ток, причем весьма существенный. Этот ток может привести к выходу из строя компьютера, SkyStar, Diseqc-оборудования или актуатора - это как Вам повезет.

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

Именно такая ситуация имела место и у нас - компьютер был занулен, а тарелка и актуатор заземлены. При этом тарелка заземлялась не всегда, а исключительно после дождя (когда вода протекала по опоре до арматурины в бетоне). В этом случае через скайстар, позиционер, и провода управления актуатором начинал течь ток, весьма немаленький (у нас позиционер попросту начинал дымиться!).

В результате длительной эксплуатации в подобном режиме неизбежно выйдет из строя компонент с наименьшим сечением земляного провода - это:

SkyStar, если он не прикручен винтиком к корпусу компьютера - земляная разводка по плате больше 10-20 ампер не выдержит,
Diseqc-позиционер, если SkyStar надежно прикручен, актуатор хорошенько заземлен, а провода-солидные;
Актуатор, в нашем случае выгорал датчик вращения мотора.
Если Вам повезло, и все изделия у Вас рассчитаны на солидный ток, то все будет работать и потихоньку себе греться, дожидаясь, когда же Вы открутите антенный провод и возьметесь одной рукой за него, а второй-за корпус компьютера (копьютер включать необязательно - достаточно вилку воткнуть!)

Даже если ток между землей компьютера и тарелки будет невелик для вывода приборов из строя, его может оказаться вполне достаточно для обеспечения полной неработоспособности DiSEqC оборудования за счет эффекта, известного как Ground Loop. Так что если у Вас не всегда срабатывает DiSEqC (особенно после дождя), то причина может быть именно в этом.

К превеликому сожалению, догадались мы о сути происходящих явлений только после того, как несправедливо возвели поклеп на позиционер уважаемой фирмы Aston (который сгорел, причем так, как будто ему на вход датчика вращения вдруг подали 220 вольт - ремонтник отказывался поверить, что позиционер не трогали), починили вдруг сгоревший датчик вращения в актуаторе, и спасли от смерти уже дымившийся позиционер V-box фирмы Moteck.

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

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

Рекомендации
Что же можно посоветовать, чтобы избежать вышеперечисленных проблем?

Ни при каких обстоятельствах не хватайтесь одной рукой за антенный провод, а другой рукой за корпус компьютера. Всегда вынимайте провод (а не выключайте выключатель!) перед откручиванием антенного провода от SkyStar.
Всегда закручивайте винтик, которым SkyStar прикручивается к корпусу компьютера. Тем самым Вы спасаете карту и (или?) мат. плату компьютера от смерти в случае вышеописанной ситуации.
Внимательно изучите Вашу тарелку на предмет гальванического соединения арматурой здания - в последнем случае включать компьютер сеть с заземлением нельзя! Следует обратиться к квалифицированному электрику для решения возникшей проблемы. Не следует также полагаться на измерения в хорошую погоду - как показал наш опыт, проблемы могут происходить только в дождь.