Вот тут ближайший к вам диапазон бывшего "Sibirtelecom", который теперь RTC(Rostelecom), и ваша цель скорее всего находится в нём: Spoiler: крепитесь 87.103.240.0/20 90.189.0.0/18 90.189.112.0/20 90.189.128.0/17 90.189.64.0/19 90.189.96.0/20 92.124.0.0/16 92.125.0.0/16 92.126.0.0/16 92.127.128.0/17 193.16.106.0/24 213.228.64.0/19 213.228.96.0/22 213.228.112.0/22 77.72.246.0/23 90.189.131.0/24 92.127.152.0/24 95.191.129.0/24 212.20.15.0/24 212.20.19.0/24 212.164.201.0/24 213.228.96.0/21 217.70.96.0/19 Хоть он не так велик как полный лист ростелекома, но всё же...
Собственно аббревиатуру DOCSIS слышали многие, но далеко не все представляют что это и зачем оно нужно. Самые любопытные могли, даже просветится этим вопросом в википедии, но как показывает практика довольно много вопросов все равно остается. Итак, начинаем срывать покровы давайте разберемся с вопросами: 1. что это? 2. кому это нужно? 3. что для этого нужно? 4. как начать? Слабонервных не желающих вникать в «How it's made?» просьба под хабракат не заглядывать — там ничего интересного нет. здесь Для совсем несведущих это (очень грубо) такой большой и дорогой модем к которому линкуются абонентские модемы. 4. Основным требованием к сети является – обслуживаемость и наличие на усилителях обратного канала. Обслуживаемость – это перманентное вырезание нелегалов и слежение за уровнями сигнала в прямом и обратном каналах. Сезонный шат сигнала может очень существенно подпортить жизнь пользователям и вашей службе поддержки. 5. С кратким перечнем производителей модемов можно ознакомиться здесь. Docsis модем является довольно специфичным устройством предоставляющий довольно широкие возможности – начиная ограничением пропускной способности абонента прямо на его модеме и заканчивая фильтрами (грубо удаленно управляемым фаерволом). С чего начать? В последнее время ко мне с завидной регулярностью стучат админы начальство которых, руководствуясь соображениями, изложенными в «Кому это нужно?» купило CMTS (почему-то чаще всего это что-то типа подержанных BSR1000, BSR2000, CiscoUBR) и сказало «засунь интернет в КТВ сеть». Для людей знакомых уже с Ethernet или ADSL схема работы DOCSIS сети может оказаться не совсем прозрачной а количество телодвижений нужных для того чтобы хотя бы один модем запингался – окончательно упоротым. Довольно сложно что-то сделать не представляя общих принципов того как это должно работать. Первая мысль которая приходит в голову это прикрутить модем напрямую к CMTS и посмотреть что получится. Естественно не получится ничего – модем будет просто светомузыкально мелькать лампочками и все. Больше ничего не случится. При попытке соединиться модем сканирует весь диапазон частот на тему наличия downstream/upstream и если находит пытается получить адрес посредством DHCP для модема, если адрес получен — модем по TFTP пытается получить специальным образом собранный конфиг для себя родимого, после чего если конфиг нормально прожеван пытается получить по DHCP адрес для CPE (customer-provided equipment) коим являться будет скорее всего сетевая плата либо роутер. Работать в норме на тестовом стенде оно должно так: 1. CMTS настроена 2. На сервере подняты вышеуказанные сервисы 3. модем подключен через пачку тапов чтобы обеспечить номинальные уровни сигнала для DS/US. 1. На настройке CMTS заострять внимание мы особо не будем, ибо в зависимости от производителя, физических реалий сети и планируемой топологии сети она будет очень сильно разниться. Радует наличие всеобъемлющей документации, которое шло в комплекте со всеми попадавшими ко мне в руки дивайсами – думаю по ней должно быть все более-менее понятно для людей знакомых с cisco-like интерфейсом и общей теорией настройки сетевых устройств. Минимальные пассы руками которые следует провести над CMTS чтобы она была готова к стендовым испытаниям выглядят как: — прописываем частоту DS — прописываем частоты и модуляции для US — прописываем адрес DHCP сервера который мы будем рилеить — прописываем secret key для конфигов — прописываем пароли — сохраняемся 2. Поднимаем на сервере нужные нам сервисы. # cd /usr/ports/net/isc-dhcp31-server/ && make install (собираем с поддержкой Option82) tftpd скорее всего у нас есть по умолчанию, просто раскоментируем его в /etc/inetd.conf #cd /usr/ports/net-mgmt/docsis && make install Который нужен нам для генерации бинарных конфигов для DOCSIS-совместимых модемов как гласит pkg-descr. Допустим CMTS мы настроили как 10.10.10.9 рилеящую DHCP риквесты на сетевую нашего хоста с айпишкой 10.10.10.10 которая смотрит на CMTS. Тогда наш /usr/local/etc/dhcpd.conf должен выглядеть следующим образом option domain-name "catv"; option domain-name-servers 10.10.10.10; default-lease-time 3600; max-lease-time 43200; authoritative; ddns-update-style none; log-facility local7; one-lease-per-client true; deny duplicates; subnet 10.10.200.0 netmask 255.255.248.0 { default-lease-time 3600; max-lease-time 86400; option domain-name-servers 10.10.10.10; option subnet-mask 255.255.248.0; option routers 10.10.200.1; include "/usr/local/etc/users_dhcp.conf"; } subnet 10.10.100.0 netmask 255.255.248.0 { default-lease-time 3600; option subnet-mask 255.255.248.0; option routers 10.10.100.1; server-name "10.10.10.10"; option tftp-server-name "10.10.10.10"; option bootfile-name "cm_config/other.b"; next-server 10.10.10.10; filename "cm_config/other.b"; option time-servers 10.10.10.10; option time-offset 2; include "/usr/local/etc/modems_dhcp.conf"; } Из чего должно быть понятно что мы резервируем под модемы сеть 10.10.100/21 и под пользовательские CPE сеть 10.10.200/21 Для простоты работы в будущем хосты для сабнетов мы инклудим из /usr/local/etc/modems_dhcp.conf и /usr/local/etc/users_dhcp.conf соответственно. Для начала в /usr/local/etc/modems_dhcp.conf мы вписываем наш тестовый модем в виде host m1002 { hardware ethernet 00:ff:ff:55:ff:f2; fixed-address 10.10.100.3; filename "cm_config/testmodem.b"; } А в и /usr/local/etc/users_dhcp.conf добавляем свой тестовый хост: host m10102002 { hardware ethernet 00:cc:cc:99:aa:ff; fixed-address 10.10.200.2; } Директива filename должна намекать на то что в ней содержится путь (относительно tftp root который обычно в /tftpboot) к забинареному конфигу модема. В простейшем случае конфиг модема (не пригодный к реальному использованию! For testing purposes only! Achtung!) будет выглядеть следующим образом: #cat /tftpboot/cm_source/testing Main { NetworkAccess 1; GlobalPrivacyEnable 0; UsServiceFlow { UsServiceFlowRef 200; QosParamSetType 7; MaxRateSustained 0; SchedulingType 2; } DsServiceFlow { DsServiceFlowRef 100; QosParamSetType 7; TrafficPriority 3; MaxRateSustained 0; } MaxCPE 16; } Теперь нам следует его скомпилить в приемлемый для модема вид при помощи ранее собранной утилиты docsis используя указанный на CMTS secret-key #echo "sosecret" > /somewhere/key #docsis -e /tftpboot/cm_source/testing /somewhere/key /tftpboot/cm_config/testing.b Прописываем рауты для сетей модемов, и пользователей на CMTS в rc.conf: static_routes="cable modem" route_cable="10.10.200.0/21 10.10.10.9" route_modem="10.10.100.0/21 10.10.10.9" 3. собираем из спичек и желудей пигтейлов и тапов конструкцию объединяющую DS и один из US и обеспечивающую прохождение на модем указанных в документации уровней сигнала. Если мы все сделали правильно то на CMTS в bsr#show cable modem Мы увидим что-то типа Cable 0/0/D0/U0/C0 431 online 1458 26.0 10.10.100.3 00ff.ff55.fff2 И соответственно наши тестовый модем и тестовый хост которые как мы помним 10.10.100.3 и 10.10.200.2 должны пингаться. Видите как все просто и наглядно? – а вы боялись. =) В случае сегментирования сети на множество CMTS для обеспечения повышения отказоустойчивости и быстродействия все выглядит аналогичным образом. И сводиться к разнесению разных сетей по раутам. Вышеприведенный конфиг не адекватен для реального применения по ряду причин: Как минимум: — нету фильтров на изоляцию пользователей — нету прописанных snmp для сбора статистики — нету привязки модема к конкретному CPE Еще хорошо было бы сделать: — шейпинг канала прямо на устройстве — учесть особенности различных дивайсов — отрубить веб-лицо модема, пользователю там делать нечего — грамотно построить QoS Изначально я очень хотел написать пошаговый мануал по тому, как сделать не просто чтобы «ходили интернеты» а и по тому, как грамотно их продать конечным пользователям, собственно с примерами конфигов, готовой АСР итд. Но так как писатель из меня честно-говоря никакой — мне банально стыдно показывать свой быдлокод который к тому же довольно узкоспецифичен и в любом случае требует глубокой доводки под конкретного оператора В общих чертах требования к биллингу работающему в DOCSIS сети очень просты: — уметь считать трафик — уметь считать деньги — делать из посчитанных денег трафика гибкие тарифы — гибко ограничивать пользовательскую полосу — уметь на лету компилировать конфиги к модемам на каждого пользователя + править хосты dhcpd. Если с первыми четырьмя пунктами все понятно – и собственно все АСР ими в основном и занимаются, то на последнем следует заострить внимание на последнем. Естественно можно выдать один конфиг на всех, а потом аутентификацию пользователя производить при помощи внутренних механизмов АСР (разношерстные авторизаторы) либо скажем методом PPtP тунелля но это я считаю просто дополнительным костылем и сознательным отказом от очень удобных возможностей предоставляемых технологией. Думаю сейчас много-много людей скажет, что технология мертва, дорога, не актуальна и потыкают меня мордочкой в FTTB, PON, HCNA. Да я в курсе что такие есть и что например в плотнозаселенных многоэтажках намного цена/скорость порта в десятки раз дешевле с FTTB и что HCNA предоставляет по тому же коаксиалу намного более вкусные скорости при сопоставимой стоимости абонентских железок и отсутствии в необходимости покупки относительно дорогой CMTS. Если интересно могу на пальцах объяснить, почему FTTB в частном секторе это дорого, и почему там же HCNA сводится к «почти FTTB» по стоимости порта а так же почему публика пока еще не готова к PON. Опять же для применения любой пока еще живой технологии всегда есть свои мотивы от «давайте использовать существующую сеть» до «иначе будет слишком дорого и долго». Опять же выбор играть в демпинг и гоняться со скоростями домашних сетей не самый хороший вариант при вышеуказанных ТТХ и собственно козырем DOCSIS провайдера должны быть имхо сервисы предоставляемые по одному кабелю и их качество. На данном этапе развития DOCSIS 2.0 может в полнее успешно конкурировать с ADSL а 3.0 наступает на пятки остальным как перспективная платформа для Triple Play. Как всегда в конце статьи я использую свою слабую отмазку звучащую как: «Да я не грамотен, я знаю. Язык не родной, в школе не учили, хотя догадываюсь это слабая отмазка. Если вы воспринимаете пропущенную запятую как личное оскорбление – приношу извинения заранее. Честно – я не хотел» Как правило, действует
Прекрасно. Только не совсем понятно, зачем копипастить статейку, в бороде которой может запутаться мамонт: https://habrahabr.ru/post/102429/ ?
Почему то не парсится пароль из пары на вебку в ZTE ZXDSL 931VII, hardware: 1.0.0, firmware: 2.0.00.RUSS. Выборка(10-ти минутной давности). https://yadi.sk/d/8jBxupqR3Jwxww
Потому что там используется уязвимость, а пароль берётся со страницы user_info_gch.gch, на этих экземплярах он скрыт. Надо будет реализовать, чтобы пароль брался из конфига (здесь он просто сжат) manager_dev_config_t.gch К слову, у первого - superadmin:zteadmin123, admin:6pjhL43p2B
У меня всё парсит: Code: Address: http://176.97.189.101:8080/ Time: 46 ms Device: ASUS RT-N66U, firmware: 2.0 BSSID: BC:EE:7B:93:79:88 ESSID: AsusRT-N66U
а что это admin:admin добавить можно? а этот парсится http://176.97.187.219:8080/ http://176.97.168.69:80 отображается как Web server http://176.97.168.105:80 отображается как Ag [47] Два последних Keenetic Lite III
Потому что это роутер. У меня определяются корректно: ZyXEL Keenetic Lite III (NDMSv2) Похоже, у вас старая версия программы, обновляйте.
