Ко мне часто обращаются с запросами траблшутинга беспроводных контроллеров Cisco, часть из которых проистекает от незнания того, как те устроены и работают. Контроллер беспроводных точек доступа – это не привычный роутер или коммутатор с IOS, это специализированный компьютер (либо виртуалка) с Линуксом внутри. Сегодня мы познакомимся с аппаратными платформами разных контроллеров, узнаем о механизме их лицензирования, разберем на части одну прошивку, и получим рутовый доступ к устройству.
Зачем
Вкратце, контроллеры нужны для централизованного управления большими беспроводными сетями, построенными на базе сравнительно не настраиваемых индивидуально точек доступа. Об этой архитектуре я подробно писал на Хабре (один, два, три, четыре). Точки доступа, расставленные по помещениям предприятия (не обязательно в одном офисе) через локальную или глобальную сеть регистрируются на контроллере, получают с него настройки, управляются им, и предоставляют беспроводной доступ Wi-Fi абонентам. Практически все модели точек доступа Cisco выпускаются как в автономном варианте (независимое управление через CLI или GUI), так и в унифицированном (лимитированный CLI и управление с контроллера по протоколу CAPWAP). Контроллер представляет собой программно-аппаратную платформу взаимодействия с точками доступа, и проводной сетью.
В рамках подготовки к CCIE Wireless (два года назад) для экспериментов мне понадобилось сразу несколько контроллеров, которых под рукой не было. До этого успешно запустив в виртуальной машине ACS, Location Appliance, MSE я попробовал аналогично виртуализовать и сам контроллер. Задача (за полтора года решенная) оказалось сложной, и опыта накопилось предостаточно. Им-то я и хочу поделиться с сообществом. Для начала, давайте посмотрим, что из себя представляет аппаратная начинка контроллера.
Железо
По сути, любой контроллер – это специализированный одноплатный компьютер с процессором некоторой широко известной архитектуры, оперативной памятью, флеш-диском (CompactFlash карта в WISM, WLCM, 440x или напаянная на плату микросхема в остальных моделях), сетевыми картами. Любой сомневающийся может открыть крышку устройства и убедиться в этом самостоятельно.
Cisco 8510 и Cisco Flex 7510 основаны на обычных 1U серверах IBM c дополнительной сетевой картой на базе процессора Cavium Octeon, на который контроллер возлагает пакетные операции реального времени (вроде дешифровки DTLS CAPWAP трафика). Данные контроллеры имеют специфическую нишу — агрегацию трафика очень большого числа удаленных (в режиме FlexConnect) точек доступа, и в силу этого распространения не имеют.
Cisco 5760 и Cisco Catalyst 3850 представляют собой близкие к обычным маршрутизаторам и коммутаторам Cisco устройства. Код контроллера исполняется под управлением IOS XE, такого же, как например, в линейке ASR. Все, о чем пойдет речь ниже, к данным пока еще экзотическим устройствам мало относится.
Уходящие с поддержки модели 4402, 4404 несут на себе процессор MIPS 64, сопроцессор NPE и новыми версиями ПО (> 7.2) не поддерживаются. К ним можно отнести встроенный в коммутатор 3750G-24WS контроллер 4402, а также модуль WiSM в Catalyst 6500 (который из себя представляет два независимых 4404, получающих от шасси только консоль, электропитание, и GigE порты).
Устройства WLCM (для ISR) и SRE (ISR G2) представляют собой модули, устанавливаемые в маршрутизатор серий 28хх/38хх, 29хх/39хх и работающие от них вполне автономно. Различаются процессором (Celeron/i386 и Core/x64) и соответственно производительностью (числом поддерживаемых точек доступа).
Нам наиболее интересны более распространенные автономные контроллеры 2504, 5508, и новый модуль WiSM2 для коммутатора 6500. Последний (сюрприз) — это снова два независимых 5508. В действительности все эти три модели – одно и то же, отличаются только количеством сетевых интерфейсов и производительностью CPU (архитектура 64-бит MIPS).
Замыкает линейку виртуальный контроллер, который продается в виде образа ВМ под VMware ESXi (ovf-файл). Логично, что его архитектура соответствует стандартному оборудованию виртуальной машины: процессор x64, диск LSI SCSI, сеть Intel E1000.
Два года назад виртуального контроллера не было. Я попробовал виртуализовать наиболее близкий по архитектуре WLCM (NME-AIR-WLC), что однако потребовало разбора и исследования прошивок (примерно по методике ниже), написания драйвера эмуляции NVRAM для MontaVista 4.0, изучения Ida Pro, модификаций сетевых потрохов QEMU, разбирательств с сетью в ESXi и заняло примерно год времени в вялотекущем режиме. И такой контролер заработал! Правда, современные версии ПО контроллера (>7.2) WLCM более не поддерживают, а у нас есть vWLC, поэтому мои результаты имеют только академическую ценность.
Помимо очевидных различий в производительности (количестве одновременно поддерживающихся точек доступа и беспроводных абонентов) все контроллеры отличаются и функционалом. Главным образом различия сводятся к поддержке wired guest, guest access, mobility-anchor, мультикасту, IPV6 и т.п. редко требуемым фичам. Реально весомое различие — поддержка local mode (традиционного режима) реализована на 2504/5508/WISM2, в то время как Flex7500/vWLC довольствуются только FlexConnect.
Софт
Программное обеспечение контроллера представляет собой файл размером порядка 100 мегабайт, который вы можете скачать на сайте производителя, если у вас есть сервисный контракт либо нагуглить по известному оттуда же имени файла. Для типичного AIR-CTYYYY-K9-X-X-XX.aes расширение .aes не должно вводить вас в заблуждение: оно не имеет никакого отношения к протоколу шифрования. В имени файла прошивки (firmware) может встретиться слово LDPE (Licensed Data Payload Encryption). Это означает, что данная прошивка активирует возможность шифрования пользовательского трафика (CAPWAP туннель управления все равно шифруется через DTLS/AES) отдельной лицензией. Это Cisco специально придумала для пользователей из России, чтобы K9-устройства не попадали под законодательные ограничения ввода средств шифрования.
Внутри файла прошивки проприетарного формата вы увидите немного бинарного мусора, куски шелл-скриптов, большие блоки, похожие на tar- или gz-архивы. Это совсем не напоминает плотноупакованный, монолитный двоичный образ IOS (Internetwork Operating System, не путать с яблочным iOS) какого-нибудь традиционного Cisco-устройства. Поэтому не стоит пытаться проводить какие-либо обновления путем непосредственного удаления-заливки .aes-файла на флеш, вы только окирпичите устройство.
Возьмем последнюю на сегодня версию 7.5.102.0 для контроллера 5508, AIR-CT5500-K9-7-5-102-0.aes. Любопытный факт: помните, я говорил, что 2504, 5508 и WiSM2 – это одно и то же? Если присмотреться, для всех них файл ПО этой версии прошивки имеет одну длину (133146180 байт) и контрольную сумму (62ba852937eefaadaaba25e3b6cc18fc). Софт сам определяет, на какой платформе он работает. Ну а вы, если имеете софт под одну из трех платформ, автоматически имеете его под остальные – просто переименуйте файл.
Получение рутового доступа
Как вы знаете, подключаясь по SSH либо консолью к контроллеру, вы попадаете в интерфейс командной строки, который слегка напоминает IOS. Слегка — потому что вся линейка контроллеров основана на историческом коде, полученном Cisco в результате приобретения компании Airespace в 2005 году. Раз мы знаем, что контроллер построен на базе ОС Linux, возникает вопрос – можно ли получить shеll-доступ к самой системе, желательно рутовый. Попробуем это сделать на примере установленного по инструкции виртуального контроллера. После установки версии 7.4.100 я дополнительно обновил его до версии 7.5.102.
Просто так в его шелл попасть нельзя (это вам не Prime NCS)
Наш «виртуальный контроллер» CTVM выполняется как виртуальная машина под управлением VMware ESXi. Выключим контроллер (кнопкой Power Off) и подключим его виртуальный диск (.vmdk) к какой-нибудь другой нашей виртуальной машине на том же хосте. Я для подобных целей использую Debian/GNU Linux как наиболее близкий к оригинальной ОС вариант. Что мы видим:
root@debian64:~# fdisk /dev/sdb
…
Disk /dev/sdb: 8589 MB, 8589934592 bytes
…
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 33 265072 83 Linux
/dev/sdb2 34 99 530145 83 Linux
/dev/sdb3 100 491 3148740 83 Linux
/dev/sdb4 492 1044 4441972+ 83 Linux
Четыре партиции. Попробуем примонтировать их все:
mkdir sdb && mkdir sdb/1 && mkdir sdb/2 && mkdir sdb/3 && mkdir sdb/4
mount /dev/sdb1 sdb/1/ ; mount /dev/sdb2 sdb/2/ ; mount /dev/sdb3 sdb/3/ ; mount /dev/sdb4 sdb/4/
Раздел 1 содержит бутлоадер (grub) и рекавери ядро rescue.img, раздел 2 не монтируется совсем (и не используется данной версией контроллера), раздел 3 содержит лог-файлы, а раздел 4 содержит самое интересное. Приведу урезанный вывод ls –la с комментариями.
./sdb/4:
drwxr-xr-x 7 root root 4096 Сен 24 12:31 application
drwxr-xr-x 4 root root 4096 Сен 24 12:22 images
-rw-r--r-- 1 root root 524288 Сен 24 11:58 vmstore.bin
vmstore.bin представляет собой монтируемый образ системного хранилища сертификатов и лицензий, о чем поговорим ниже.
./sdb/4/application:
---------- 1 root root 611 Сен 24 12:00 bsnSslWebadminCert.crt
---------- 1 root root 607 Сен 24 12:00 bsnSslWebadminCert.prv
---------- 1 root root 597 Сен 24 12:08 bsnSslWebauthCert.crt
---------- 1 root root 609 Сен 24 12:08 bsnSslWebauthCert.prv
drwxr-xr-x 2 root root 4096 Сен 24 12:31 cfg
-rw-r--r-- 1 root root 131072 Сен 24 11:59 csl.bin
---------- 1 root root 32768 Сен 24 12:00 flash_settings.bin
drwxr-xr-x 2 root root 4096 Сен 24 12:08 ha
---------- 1 root root 4080 Сен 24 12:33 log.bin
drwxr-xr-x 2 root root 4096 Сен 24 11:58 lvl7
---------- 1 root root 1 Сен 24 12:31 mcast_ucast_feature
drwxr-xr-x 2 root root 4096 Сен 24 12:06 nim
-rw-r--r-- 1 root root 125 Сен 24 12:25 promptError.txt
-rw-r--r-- 1 root root 1 Сен 24 12:31 snmpBoots.txt
-rw------- 1 root root 668 Сен 24 11:59 ssh_host_dsa_key
-rw-r--r-- 1 root root 606 Сен 24 11:59 ssh_host_dsa_key.pub
-rw------- 1 root root 531 Сен 24 11:59 ssh_host_key
-rw-r--r-- 1 root root 335 Сен 24 11:59 ssh_host_key.pub
-rw------- 1 root root 883 Сен 24 11:59 ssh_host_rsa_key
-rw-r--r-- 1 root root 226 Сен 24 11:59 ssh_host_rsa_key.pub
drwxr-xr-x 3 root root 4096 Сен 24 12:33 xml
Содержит файлы конфигурации контроллера, ключи SSH, SSL-сертификаты Webadmin и Webauth.
./sdb/4/application/xml:
---------- 1 root root 1583 Сен 24 12:33 aaaapiCfgData.xml
---------- 1 root root 1068 Сен 24 12:33 aaaapiFileDbCfgData.xml
…
Вы, вероятно, знаете, что исчерпывающую конфигурацию коммутатора и маршрутизатора Cisco можно получить через sh run, чтобы заархивировать её, либо залить на другое устройство. Первоначально в беспроводных контроллерах тоже так было. Однако сейчас вывода команды sh config недостаточно, чтобы полностью понять то, что настроено на устройстве. Для этого придется применять многочисленные show.... Дело в том, что реальная конфигурация устройства теперь находится в наборе XML-файлов, расположенных в /application/xml, а каждый запуск команды sh config вызывает специальный код преобразования этого XML в текстовый CFG. Работа над таким преобразователем запаздывает по отношению к развитию устройства (а, может, и вообще заброшена), поэтому на sh config ориентироваться нельзя. Вместе с тем, полная настройка устройства через команды типа config … (т.е. без web gui) возможна. Более того для ряда задач графического эквивалента текстовой команде просто нет. Естественно, в недрах устройства есть обратные инструменты преобразования команд в XML.
./sdb/4/images:
drwxr-xr-x 2 root root 4096 Сен 24 11:58 ap.bak
drwxr-xr-x 2 root root 4096 Сен 24 12:24 ap.pri
-rw-r--r-- 1 root root 39773258 Сен 24 11:58 linux.bak.img
-rw-r--r-- 1 root root 40973323 Июл 31 13:53 linux.pri.img
-rw-r--r-- 1 root root 0 Сен 24 12:21 upgrade.log
-rw-r--r-- 1 root root 10 Июл 31 13:53 vinitrd-primary
-rw-r--r-- 1 root root 10 Сен 24 11:58 vinitrd-secondary
Здесь мы видим primary и backup ядра операционной системы контроллера, а также два каталога с primary и backup версиями прошивок точек доступа (о них далее).
./sdb/4/images/ap.pri:
-rwxr-xr-x 1 root root 11018240 Сен 24 12:22 ap1g1
-rwxr-xr-x 1 root root 40 Сен 24 12:22 ap1g1.md5
-rwxr-xr-x 1 root root 10342400 Сен 24 12:23 ap1g2
-rwxr-xr-x 1 root root 40 Сен 24 12:23 ap1g2.md5
-rwxr-xr-x 1 root root 10383360 Сен 24 12:23 ap3g1
-rwxr-xr-x 1 root root 40 Сен 24 12:23 ap3g1.md5
-rwxr-xr-x 1 root root 11530240 Сен 24 12:23 ap3g2
-rwxr-xr-x 1 root root 40 Сен 24 12:23 ap3g2.md5
-rwxr-xr-x 1 root root 7608320 Сен 24 12:23 ap801
-rwxr-xr-x 1 root root 40 Сен 24 12:23 ap801.md5
-rwxr-xr-x 1 root root 9041920 Сен 24 12:24 ap802
-rwxr-xr-x 1 root root 40 Сен 24 12:24 ap802.md5
-rwxr-xr-x 1 root root 5201920 Сен 24 12:24 c1130
-rwxr-xr-x 1 root root 40 Сен 24 12:24 c1130.md5
-rwxr-xr-x 1 root root 10229760 Сен 24 12:24 c1140
-rwxr-xr-x 1 root root 40 Сен 24 12:24 c1140.md5
-rwxr-xr-x 1 root root 7342080 Сен 24 12:24 c1250
-rwxr-xr-x 1 root root 40 Сен 24 12:24 c1250.md5
-rwxr-xr-x 1 root root 8468480 Сен 24 12:24 c1520
-rwxr-xr-x 1 root root 40 Сен 24 12:24 c1520.md5
-rwxr-xr-x 1 root root 3840000 Сен 24 12:24 c602i
-rwxr-xr-x 1 root root 40 Сен 24 12:24 c602i.md5
Что же представляет собой ядро ОС контроллера? Судя по размеру, оно содержит в себе initramfs, корневую файловую систему со всеми утилитами, монтируемую в память сразу после старта ядра. Кстати, в предыдущих версиях контроллера initrd поставлялся в виде отдельного файла образа ext2fs, что значительно упрощало задачу его модификации.
# file linux.pri.img
linux.pri.img: Linux kernel x86 boot executable bzImage, version 2.6.21_mvlcge500-octeon-mips64_,
RO-rootFS, root_dev 0x801, swap_dev 0x27, Normal VGA
Для получения рутового доступа необходимо разобрать ядро на части, поменять что-то в корневой ФС, и собрать всё обратно. Для этого посмотрим, как устроено ядро. На удивление, внятного описания структуры собранного ядра вкупе с инструментами его разбора в Интернете почти нет (отдаленно помогает binwalk). Ясно, что ядро запаковано, и наверняка запаковщик – gzip. Сигнатура gzip-файлов проста – все архивы начинаются с 0x1F 0x8B 0x08. Поищем место начала архива, вырежем, распакуем, посмотрим что внутри, повторим и т.д. В результате вырисовывается следующая структура:
Константы K1, K2 и K3 подбираются экспериментально и зависят от версии firmware. 2.gz находятся в самом конце ядра, а магическая комбинация gzip там встречается много раз – например известно, что в ядре находится запакованный .config, использованный при его сборке. Для распаковки составился следующий скрипт:
#!/bin/sh
K1=38088
K2=6619136
K3=45117311
dd if=linux.pri.img of=0 skip=0 count=1 bs=$K1
dd if=linux.pri.img of=1.gz skip=0 bs=$K1
zcat 1.gz > 1
dd if=1 of=2-h skip=0 count=1 bs=$K2
dd if=1 of=2-f skip=$K3 bs=1
dd ibs=1 if=1 of=2.gz skip=$K2 count=$(expr $K3 - $K2)
zcat 2.gz > 2
mkdir initramfs
cd initramfs
cpio --no-absolute-filenames -idv < ../2
cd ..
На выходе имеем каталог initramfs, содержащий корневую файловую систему контроллера. Для получения root access достаточно поправить следующие файлы:
- Отредактировать ./etc/inittab так, чтобы при старте запускалась консоль, а не код беспроводной системы:
a. Меняем местами комментарии, разблокируя консоль:
con:2345:respawn:/sbin/getty console
#con:2345:respawn:/bin/gettyOrMwar
b. Раскомментируем со 2 по 6 виртуальные терминалы:
2:23:respawn:/sbin/getty 38400 vc/2 - Пользователю root в /etc/passwd прописываем нормальный шелл, /bin/bash
- Можно также сделать неисполняемым ./etc/init.d/S95mwar, чтобы контроллер без спроса не запускался
Теперь соберем всё обратно. Помним, что архивы в ядре имеют максимальную степень сжатия. При наших манипуляциях наверняка размеры результирующих кусков будут меньше оригинальных, посему для сохранения бинарной структуры добавим блоки с нулями.
#!/bin/sh
cd initramfs
find . | cpio --create --format='newc' | gzip -n -9 > ../2-new.gz
cd ..
SPACER1=$(expr `stat -c%s 2.gz` - `stat -c%s 2-new.gz`)
dd if=/dev/zero of=$SPACER1 bs=1 count=$SPACER1
cat 2-h 2-new.gz $SPACER1 2-f | gzip -n -9 > 1-new.gz
SPACER2=$(expr `stat -c%s 1.gz` - `stat -c%s 1-new.gz`)
dd if=/dev/zero of=$SPACER2 bs=1 count=$SPACER2
cat 0 1-new.gz $SPACER2 > bz
rm $SPACER1 $SPACER2
Теперь надо убедиться, что модифицированное ядро имеет тот же размер, что оригинальное, и положить его на место:
# ls -la linux.pri.img bz
-rw-r--r-- 1 root root 40973323 Сен 27 10:00 bz
-rw-r--r-- 1 root root 40973323 Сен 25 23:05 linux.pri.img
# mount /dev/sdb4 sdb/4/
# cp bz sdb/4/images/linux.pri.img
# umount /dev/sdb4
Можно выключать тестовую виртуальную машину с Linux, и включать контроллер (ESXi один виртуальный диск, .vmdk файл, двум VM одновременно использовать не даст). Загружаем контроллер:
Cisco Bootloader (Version 7.4.100.0)
.o88b. d888888b .d8888. .o88b. .d88b.
d8P Y8 `88' 88' YP d8P Y8 .8P Y8.
8P 88 `8bo. 8P 88 88
8b 88 `Y8b. 8b 88 88
Y8b d8 .88. db 8D Y8b d8 `8b d8'
`Y88P' Y888888P `8888Y' `Y88P' `Y88P'
Booting Primary Image...
Press <ESC> now for additional boot options...
Booting 'Primary image'
Detecting hardware . . . . 3
INIT: version 2.86 booting
…
Итог: у нас есть полный, рутовый доступ к работающему виртуальному беспроводному контроллеру Cisco vWLC.
Устройство работающего контроллера
Очевидно, что контроллер построен на базе специализированной версии Linux производства MontaVista. При старте происходит монтирование указанных выше файловых систем, стандартная инициализация, загрузка модулей ядра, проверка наличия чипа Octeon и загрузка его прошивки. Сетевые карты контроллера в этот момент IP-адресов не имеют. В конце запускается сам код беспроводного контроллера скриптом-обвязкой /bin/bsnmwar. Mwar – Main Wireless Application Routine. Код контроллера содержится в монолитном, статически слинкованном файле /sbin/switchdrvr (ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, stripped), который занимает добрую половину объёма всей прошивки контроллера, и реализует полностью логику его работы. Именно при его запуске на консоли появляются знакомые строки инициализации компонентов контроллера (Starting …. ok), инициализируются сетевые интерфейсы, запускается отдельным процессом демон управления лицензиями, появляется веб-интерфейс и начинают обслуживаться точки доступа и беспроводные клиенты. Шелл-доступ к консоли пропадает, и пользователь попадает на стандартное приглашение консольного логина в контроллер (но мы помним про запущенные getty на остальных виртуальных терминалах, возникшие вследствие нашей модернизации inittab).
В процессе запуска switchdrvr происходит монтирование файла /mnt/wlc/vmstore.bin с лицензиями и сертификатами в память (losetup) и перемонтирование раздела с прошивками точек доступа. В результате точки монтирования выглядят так:
root@(none):/mnt/wlc# df -k
Filesystem 1k-blocks Used Available Use% Mounted on
tmpfs 1029084 8 1029076 0% /tmp
tmpfs 10240 8 10232 0% /dev
tmpfs 1029084 0 1029084 0% /dev/shm
none 1029084 8 1029076 0% /var/run
none 1029084 8 1029076 0% /tmp
/dev/sda4 4372140 394588 3755456 10% /mnt/wlc
/dev/sda3 3099292 82176 2859680 3% /var/log
/dev/loop5 494 176 293 38% /mnt/vmstore
/dev/loop3 110 37 67 36% /root/.csl
/dev/ram3 122 5 117 4% /root/.csl_tmp
tmpfs 40960 9856 31104 24% /mnt/ap_bundle
Точки доступа
Режим их работы определяется прошивкой, которую можно поменять с AP (теперь зовётся SAP, standalone access point) на LAP (lightweight access point) и наоборот. Прошивка в обоих случаях – это IOS, скомпилированный под аппаратную платформу самой точки (все точки — PowerPC различной древности). Файл прошивки для автономной точки будет иметь имя вроде c1130-k9w7-tar.124-3g.JA.tar, а «легковесной» — c1130-k9w8-mx.124-23c.JA3.tar Различие – в W7 и W8. Также существуют «восстановительные (рекавери)» версии вида c1130-rcvk9w8-mx. Здесь прошивка не содержит кода работы с радио, ее цель — запуститься, найти контроллер, и загрузить с него «рабочую» версию софта. Кстати, по последним буквам имени файла легковесной прошивки можно определить версию контроллера, которой она соответствует. Например, 152-2.JB это 7.4.100, а 124-23c.JA3 это 7.0.220.
Все контроллеры несут в себе копии прошивок поддерживаемых ими точек доступа. При подключении точки доступа к контроллеру проверяется соответствие версий, и если те отличаются, происходит автоматическая установка ПО с контроллера. При этом возможен даунгрейд версии. Контроллер будет работать только с соответствующей ему версией ПО точки. Поэтому, если у вас в сети работают два контроллера с ПО разных версий, а точки доступа могут выбрать либо один, либо второй, при «перескоке» с одного контроллера на другой точки будут менять своё ПО. Это долго, и чревато поломкой флеш-памяти точки от постоянной её перезаписи.
Несмотря на то, что что протокол CAPWAP обмена между контроллером и точкой доступа стандартизирован, нет никаких шансов, что контроллер Cisco будет в обозримом будущем работать с точками доступа сторонних производителей. В конкретной реализации очень много недокументированностей, да и не нужно (не выгодно) это никому.
Лицензирование
Для нетерпеливых: средства «поломать» механизм лицензирования контроллеров на сегодня нет.
Старые платформы контроллеров лицензировались по количеству точек доступа аппаратно. Информация по количеству максимально обслуживаемых точек содержится в NVRAM рядом с серийным номером, и не обновляется (нельзя докупить поддержку дополнительных точек).
Все новые платформы используют современный подход, основанный на выписывании лицензии на основе UDI (имя продукта/платформы + Serial Number устройства) на Cisco.com/go/licensing с указанием PAK-ключа, т.е. подтверждения приобретения вами права на устройство и ПО. Таким образом, лицензии можно докупать по мере роста числа установленных у вас точек доступа, в пределах аппаратных возможностей платформы. Можно также один раз активировать демо-лицензию на 90 дней.
Виртуальный контроллер генерирует свой серийный номер в первый раз при запуске, руководствуясь MAC-адресом устройства (предоставляемым VMware) и, вероятно, некоторыми другими параметрами вроде идентификаторов CPU.
Данный метод лицензирования платформ и компонентов применяют все устройства на IOS 15.0, IOS XR, IOS XE, NX-OS и т.д.
Сама лицензия имеет такой вид:
<?xml version="1.0" encoding="UTF-8"?><CISCO_WT_ARTIFACTS version="1.0"><CISCO_WT_LICENSE version="1.0"><FEATURE_NAME>base</FEATURE_NAME><FEATURE_VERSION>1.0</FEATURE_VERSION><UDI><PID>AIR-CT5508-K9</PID><SN>FCJ00000000</SN></UDI><SOURCE>Cisco HQ</SОURCE><CREATE_DATE>2010-10-20T18:29:16</CREATE_DATE>
<LICENSE_LINE_HASH hashAlgo="SHA1">Eb86wsdgdsheIdRgxu8SYjnV2kug=</LICENSE_LINE_HASH>
<TYPE>EXTENSION</TYPE><EXPIRATION><DAYS>60</DAYS></EXPIRATION><EULA>YES</EULA>
<LICENSE_LINE><![CDATA[11 base 1.0 LONG TRIAL DISABLED 1440 DISABLED STANDALONE ADD INFINITE_KEYS INFINITE_KEYS NEVER NEVER NiL SLM_CODE CL_ND_LCK NiL *1B2UN9YKWSE6TLX400 NiL NiL NiL 5_MINS <UDI><PID>AIR-CT5508-K9</PID><SN>FCJ00000000</SN></UDI> IoNEjaiZMvr:SUgPfi7IL7DfUgmILSlzRAumZl96TmLQxk8wOUr9YwwsYn0pd5vsVYhn9K2G:rYugiUzNI2SeH3jL0Fvj9boyHdSgN9heQmw3F1APru5,qKFhvCKGi16CO3A$<WLC>AQEBIf8B///vAvN3WYGs8UKGLXXeaNhRdwitkjqL7s+cOPCdiN04GY47UbtfByUZYOemWEq6ljxHebPkGlARtYd1UQO7GJ3KnufZ9oZ6JdFniDf5HrQ8DrXdpCz5RgZE+y8fbN200xiXA5cB3fwcJqoPIFZm2HmD1qFfsyTAzuio66t6Xk5y8xo1lbVhvoh/FZfy5iRY3oE=</WLC>]]></LICENSE_LINE>
<USER_MODIFIABLE_COMMENT fieldRestrictions="Max 99 ASCII characters in length."></USER_MODIFIABLE_COMMENT></CISCO_WT_LICENSE></CISCO_WT_ARTIFACTS>
Она привязана к серийному номеру устройства, и содержит некоторый аналог цифровой подписи, которая несет в себе хэш указанных в начале лицензии строк. При попытке загрузки лицензии в контроллер (switchdrvr) последний проверяет ее через взаимодействие с работающим отдельным процессом менеджер лицензий (licensed). Есть и утилита командной строки, license_cli. «Ручные» вмешательства в файл лицензии приводят к ошибке обработки. Протокол обмена клиента и сервера не известен (идет через unix domain сокет). Поскольку licensed является 32-битным приложением, он легко разбирается интерактивными дизассемблерами/отладчиками вроде Ida Pro/HexRays на псевдоисходные тексты на С, анализ которых явно говорит о применении библиотек шифрования и подписей Sentinel производства SafeNet. Для дальнейшего разбирательства моих знаний не хватает, да оно мне и не нужно. Насколько известно, генератора лицензии пока еще нет, но самоцензура.
Надо отметить, что написанные на Java серверные системы Cisco (CUCM, ACS, WCS, Prime, MSE, NAC и многие другие) используют схожий формат файла лицензий, с цифровой подписью. Однако там, где есть Java, есть и декомпиляторы. Достаточно просто обнаружить, какие параметры платформы и свойства (features) (в виде строк) ищутся в лицензии, и что для проверки подписи используется flexlm.jar, со всеми вытекающими последствиями. Впрочем, я призываю вас жить честно.
Послесловие
Надеюсь, приведенный материал избавит пользователей в общем-то хороших беспроводных систем на базе контроллеров Cisco WLC от ряда тяжелых вопросов эксплуатации, траблшутинга, обновления ПО. С другой стороны, изложенный здесь вполне тривиальный метод реверс-инженеринга прошивок может помочь пытливому исследователю в работе над аналогичными Linux-based устройствами.
Данный пост не ставит целью сравнение преимуществ и недостатков беспроводных систем разных производителей и не за кого не агитирует. Я никак на аффилирован с компанией Cisco Systems.
Все изложенное выше я узнал в результате длительного изучения файлов, который каждый может скачать в Интернете, документации, и на основе личного опыта. Я призываю использовать данный пост только в целях траблшутинга и самообразования. Для целей обучения вполне достаточно демоверсии виртуального контроллера. Лицензия на 5 точек доступа к (бесплатному) виртуальному контроллеру стоит $750 (без скидки). Сами б/у точки старых, но ещё поддерживаемых моделей дешевы – я на eBay взял три штуки 1131a/g за 2500 руб. с доставкой.
Автор: antonvn
