Control sideband что это
Обновлено: 06.07.2024
История от Bloomberg о том, что на материнских платах якобы были установлены некие импланты [Китайцы использовали микрочип, чтобы контролировать американские компьютеры], не прошла незамеченной. После неё многие люди делились идеями по поводу возможности создания подобных имплантов (их предполагаемого размера, возможностей или способа их обнаружения).
Через несколько дней журнал Bloomberg выпустил статью с дополнительными доказательствами. Вот что конкретно подогрело наш интерес:
Существуют способы взаимодействия с сетевой картой прямо с материнской платы. Несколько людей указали на то, что можно поиграться с BMC (Baseboard Management Controller – компонент, разрешающий доступ к серверу помимо основного канала), что позволит импланту контролировать BMC и получать доступ к сетевой карте. Но как это работает на практике? Давайте посмотрим, сможем ли мы это воспроизвести.
Начальная позиция
Посмотрим на наличие возможных интерфейсов между NIC (сетевой платой) и BMC. Один из основных протоколов для работы по выделенному каналу – это интеллектуальный интерфейс управления платформой IPMI.
Википедия говорит, что IPMI — «интеллектуальный интерфейс управления платформой, предназначенный для автономного мониторинга и управления функциями, встроенными непосредственно в аппаратное и микропрограммное обеспечения серверных платформ. Ключевые характеристики IPMI — мониторинг, восстановление функций управления, журналирование и инвентаризация, которые доступны независимо от процессора, BIOS'a и операционной системы. Функции управления платформой могут быть доступны, даже если система находится в выключенном состоянии». Весьма похоже на то, что нам нужно.
На следующей блок-схеме показан возможный путь реализации проекта:
IPMI на самом деле определяет два Sideband-канала для NIC: SMBus и NC-SI. NC-SI – это современная замена SMBus, поддерживающая увеличенную скорость передачи данных и другие новые возможности. Проблема в том, что ей требуется больше сигналов (порядка 10), и в её работу гораздо сложнее вмешаться в случае, когда мы работаем с имплантом. Так что пока остановимся на SMBus.
SMBus
SMBus (System Management Bus) — последовательный протокол обмена данными для устройств питания. Односторонняя простая двухпроводная шина, обеспечивающая несложные коммуникации. Чаще всего используется в компьютерах для связи материнской платы с источником питания и отправки инструкций вида вкл/выкл. Основан на шине I 2 C, обычно использующейся в микроконтроллерах. Интерфейсу нужно всего два сигнала (тактовая частота и данные), и третий сигнал — прерывание. Идеально подходящий для игр с имплантом протокол.
Получение информации
Как вы могли догадаться, мы продолжили читать документацию и отправлять специально подготовленные команды на NIC для проверки того, что всё работает, как ожидалось.
[START] [@SLAVE] [CMD] ( [START] [@SLAVE] [READ_DATA] ) [STOP]
[START] и [STOP] – это условия START и STOP, определяемые протоколом I 2 C.
К примеру, команда на чтение MAC-адреса (описанная в главе 8.8.2.3) будет 0xD4. Отправляем команду в SMBus в режиме I 2 C:
[START] [0x92] [0xD4] [START] [0x92] [read 8 bytes] [STOP]
При переводе в команды Hydrabus это будет:
i2c1> [ 0x92 0xd4 [ 0x92 hd:2 hd:6 ]
I2C START
WRITE: 0x92 ACK 0xD4 ACK <== [NIC address] [command]
I2C START <== Switch state
WRITE: 0x92 ACK <== [NIC address]
07 D4 | .. <== Read [length] [header]
68 05 CA 89 B2 2E | h. <== Read MAC address bytes
NACK
I2C STOP
И, да, мы получаем наш MAC-адрес!
Коммиты — это снимки, а не различия
Git имеет репутацию запутывающего инструмента. Пользователи натыкаются на терминологию и формулировки, которые вводят в заблуждение. Это более всего проявляется в "перезаписывающих" историю командах, таких как git cherry-pick или git rebase. По моему опыту, первопричина путаницы — интерпретация коммитов как различий, которые можно перетасовать. Однако коммиты — это не различия, а снимки! Я считаю, что Git станет понятным, если поднять занавес и посмотреть, как он хранит данные репозитория. Изучив модель хранения данных мы посмотрим, как новый взгляд помогает понять команды, такие как git cherry-pick и git rebase.
Если хочется углубиться по-настоящему, читайте главу о внутренней работе Git (Git internals) книги Pro Git. Я буду работать с репозиторием git/git версии v2.29.2. Просто повторяйте команды за мной, чтобы немного попрактиковаться.
Хеши — идентификаторы объектов
Самое важное, что нужно знать о Git-объектах, — это то, что Git ссылается на каждый из них по идентификатору объекта (OID для краткости), даёт объекту уникальное имя.
Чтобы найти OID, воспользуемся командой git rev-parse. Каждый объект, по сути, — простой текстовый файл, его содержимое можно проверить командой git cat-file -p.
Мы привыкли к тому, что OID даны в виде укороченной шестнадцатеричной строки. Строка рассчитана так, чтобы только один объект в репозитории имел совпадающий с ней OID. Если запросить объект слишком коротким OID, мы увидим список соответствующих подстроке OID.
Блобы — это содержимое файлов
На нижнем уровне объектной модели блобы — содержимое файла. Чтобы обнаружить OID файла текущей ревизии, запустите git rev-parse HEAD:<path>, а затем, чтобы вывести содержимое файла — git cat-file -p <oid>.
Если я отредактирую файл README.md на моём диске, то git status предупредит, что файл недавно изменился, и хэширует его содержимое. Когда содержимое файла не совпадает с текущим OID в HEAD:README.md, git status сообщает о файле как о "модифицированном на диске". Таким образом видно, совпадает ли содержимое файла в текущей рабочей директории с ожидаемым содержимым в HEAD.
Деревья — это списки каталогов
Обратите внимание, что блобы хранят содержание файла, но не его имя. Имена берутся из представления каталогов Git — деревьев. Дерево — это упорядоченный список путей в паре с типами объектов, режимами файлов и OID для объекта по этому пути. Подкаталоги также представлены в виде деревьев, поэтому деревья могут указывать на другие деревья!
Воспользуемся диаграммами, чтобы визуализировать связи объектов между собой. Красные квадраты — наши блобы, а треугольники — деревья.
Деревья дают названия каждому подпункту и также содержат такую информацию, как разрешения на файлы в Unix, тип объекта (blob или tree) и OID каждой записи. Мы вырезаем выходные данные из 15 верхних записей, но можем использовать grep, чтобы обнаружить, что в этом дереве есть запись README.md, которая указывает на предыдущий OID блоба.
При помощи путей деревья могут указывать на блобы и другие деревья. Имейте в виду, что эти отношения идут в паре с именами путей, но мы не всегда показываем эти имена на диаграммах.
Само дерево не знает, где внутри репозитория оно находится, то есть указывать на дерево — роль объектов. Дерево, на которое ссылается <ref>^, особое — это корневое дерево. Такое обозначение основано на специальной ссылке из вашего коммита.
Коммиты — это снапшоты
Коммит — это снимок во времени. Каждый содержит указатель на своё корневое дерево, представляющее состояние рабочего каталога на момент снимка.
В коммите есть список родительских коммитов, соответствующих предыдущим снимкам. Коммит без родителей — это корневой коммит, а коммит с несколькими родителями — это коммит слияния.
Например, коммит в v2.29.2 в Git-репозитории описывает этот релиз, также он авторизован, а его автор — член команды разработки Git.
Круги на диаграммах будут представлять коммиты:
Квадраты — это блобы. Они представляют содержимое файла.
Треугольники — это деревья. Они представляют каталоги.
Круги — это коммиты. Снапшоты во времени.
Ветви — это указатели
В Git мы перемещаемся по истории и вносим изменения, в основном не обращаясь к OID. Это связано с тем, что ветви дают указатели на интересующие нас коммиты. Ветка с именем main — на самом деле ссылка в Git, она называется refs/heads/main. Файлы ссылок буквально содержат шестнадцатеричные строки, которые ссылаются на OID коммита. В процессе работы эти ссылки изменяются, указывая на другие коммиты.
Это означает, что ветки существенно отличаются от Git-объектов. Коммиты, деревья и блобы неизменяемы (иммутабельны), это означает, что вы не можете изменить их содержимое. Изменив его, вы получите другой хэш и, таким образом, новый OID со ссылкой на новый объект!
Ветки именуются по смыслу, например, trunk [ствол] или my-special-object. Ветки используются, чтобы отслеживать работу и делиться её результатами. Специальная ссылка HEAD указывает на текущую ветку. Когда коммит добавляется в HEAD, HEAD автоматически обновляется до нового коммита ветки. Создать новую ветку и обновить HEAD можно при помощи флага git -c:
Обратите внимание: когда создавалась my-branch, также был создан файл (.git/refs/heads/my-branch) с текущим OID коммита, а файл .git/HEAD был обновлён так, чтобы указывать на эту ветку. Теперь, если мы обновим HEAD, создав новые коммиты, ветка my-branch обновится так, что станет указывать на этот новый коммит!
Общая картина
Посмотрим на всю картину. Ветви указывают на коммиты, коммиты — на другие коммиты и их корневые деревья, деревья указывают на блобы и другие деревья, а блобы не указывают ни на что. Вот диаграмма со всеми объектами сразу:
Время на диаграмме отсчитывается слева направо. Стрелки между коммитом и его родителями идут справа налево. У каждого коммита одно корневое дерево. HEAD указывает здесь на ветку main, а main указывает на самый недавний коммит.
Корневое дерево у этого коммита раскинулось полностью под ним, у остальных деревьев есть указывающие на эти объекты стрелки, потому что одни и те же объекты доступны из нескольких корневых деревьев! Эти деревья ссылаются на объекты по их OID (их содержимое), поэтому снимкам не нужно несколько копий одних и тех же данных. Таким образом, объектная модель Git образует дерево хешей.
Рассматривая объектную модель таким образом, мы видим, почему коммиты — это снимки: они непосредственно ссылаются на полное представление рабочего каталога коммита!
Вычисление различий
Чтобы сравнить два коммита, сначала рассмотрите их корневые деревья, которые почти всегда отличаются друг от друга. Затем в поддеревьях выполните поиск в глубину, следуя по парам, когда пути для текущего дерева имеют разные OID.
В примере ниже корневые деревья имеют разные значения для docs, поэтому мы рекурсивно обходим их. Эти деревья имеют разные значения для M.md, таким образом, два блоба сравниваются построчно и отображается их различие. Внутри docs N.md по-прежнему тот же самый, так что пропускаем их и возвращаемся к корневому дереву. После этого корневое дерево видит, что каталоги things имеют одинаковые OID, так же как и записи README.md.
На диаграмме выше мы заметили, что дерево things не посещается никогда, а значит, не посещается ни один из его достижимых объектов. Таким образом, стоимость вычисления различий зависит от количества путей с разным содержимым.
Теперь, когда понятно, что коммиты — это снимки, можно динамически вычислять разницу между любыми двумя коммитами. Почему тогда этот факт не общеизвестен? Почему новые пользователи натыкаются на идею о том, что коммит — это различие?
Одна из моих любимых аналогий — дуализм коммитов как дуализм частиц, при котором иногда коммиты рассматриваются как снимки, а иногда — как различия. Суть дела в другом виде данных, которые не являются Git-объектами — в патчах.
Подождите, а что такое патч?
Патч — это текстовый документ, где описывается, как изменить существующую кодовую базу. Патчи — это способ самых разрозненных команд делиться кодом без коммитов в Git. Видно, как патчи перетасовываются в списке рассылки Git.
Патч содержит описание изменения и причину ценности этого изменения, сопровождаемые выводом diff. Идея такова: некий разработчик может рассматривать рассуждение как оправдание применения патча, отличающегося от копии кода нашего разработчика.
Git может преобразовать коммит в патч командой git format-patch. Затем патч может быть применён к Git-репозиторию командой git apply. В первые дни существования открытого исходного кода такой способ обмена доминировал, но большинство проектов перешли на обмен коммитами непосредственно через пул-реквесты.
Самая большая проблема с тем, чтобы делиться исправлениями, в том, что патч теряет родительскую информацию, а новый коммит имеет родителя, который одинаков с вашим HEAD. Более того, вы получаете другой коммит, даже если работаете с тем же родителем, что и раньше, из-за времени коммита, но при этом коммиттер меняется! Вот основная причина, по которой в объекте коммита Git есть разделение на "автора", и "коммиттера".
Самая большая проблема в работе с патчами заключается в том, что патч трудно применить, когда ваш рабочий каталог не совпадает с предыдущим коммитом отправителя. Потеря истории коммитов затрудняет разрешение конфликтов.
Идея перемещения патчей с места на место перешла в несколько команд Git как "перемещение коммитов". На самом же деле различие коммитов воспроизводится, создавая новые коммиты.
Если коммиты — это не различия, что делает git cherry-pick?
Команда git cherry-pick создаёт новый коммит с идентичным отличием от <oid>, родитель которого — текущий коммит. Git в сущности выполняет такие шаги:
Вычисляет разницу между <oid> коммита и его родителя.
Применяет различие к текущему HEAD.
Создаёт новый коммит, корневое дерево которого соответствует новому рабочему каталогу, а родитель созданного коммита — HEAD.
Перемещает ссылку HEAD в этот новый коммит.
После создания нового коммита вывод git log -1 -p HEAD должен совпадать с выводом git log -1 -p <oid>.
Важно понимать, что мы не "перемещали" коммит так, чтобы он был поверх нашего текущего HEAD, мы создали новый коммит, и его вывод diff совпадает со старым коммитом.
А что делает git rebase?
Команда git rebase — это способ переместить коммиты так, чтобы получить новую историю. В простой форме это на самом деле серия команд git cherry-pick, которая воспроизводит различия поверх другого, отличного коммита.
Самое главное: git rebase <target> обнаружит список коммитов, доступных из HEAD, но недоступных из <target>. С помощью команды git log --online <target>. HEAD вы можете отобразить их самостоятельно.
Затем команда rebase просто переходит в местоположению <target> и выполняет команды git cherry-pick в этом диапазоне коммитов, начиная со старых. В конце мы получили новый набор коммитов с разными OID, но схожих с первоначальным диапазоном.
Для примера рассмотрим последовательность из трёх коммитов в текущей ветке HEAD с момента разветвления target. При запуске git rebase target, чтобы определить список коммитов A, B, и C, вычисляется общая база P. Затем поверх target они выбираются cherry-pick, чтобы создать новые коммиты A', B' и C'.
Коммиты A', B' и C' — это совершенно новые коммиты с общим доступом к большому количеству информации через A, B и C, но они представляют собой отдельные новые объекты. На самом деле старые коммиты существуют в вашем репозитории до тех пор, пока не начнётся сбор мусора.
С помощью команды git range-diff мы даже можем посмотреть на различие двух диапазонов коммитов! Я использую несколько примеров коммитов в репозитории Git, чтобы сделать rebase на тег v2.29.2, а затем слегка изменю описание коммита.
Если пройти вдоль дерева, вы увидите, что история коммитов всё ещё существует у обоих наборов коммитов. Новые коммиты имеют тег v2.29.2 — в истории это третий коммит, тогда как старые имеют тег v2.28.0 — болеее ранний, а в истории он также третий.
Если коммиты – не отличия, тогда как Git отслеживает переименования?
Внимательно посмотрев на объектную модель, вы заметите, что Git никогда не отслеживает изменения между коммитами в сохранённых объектных данных. Можно задаться вопросом: "Откуда Git знает, что произошло переименование?"
Git не отслеживает переименования. В нём нет структуры данных, которая хранила бы запись о том, что между коммитом и его родителем имело место переименование.
Вместо этого Git пытается обнаружить переименования во время динамического вычисления различий. Есть два этапа обнаружения переименований: именно переименования и редактирования.
После первого вычисления различий Git исследует внутренние различия, чтобы обнаружить, какие пути добавлены или удалены. Естественно, что перемещение файла из одного места в другое будет выглядеть как удаление из одного места и добавление в другое. Git попытается сопоставить эти действия, чтобы создать набор предполагаемых переименований.
На первом этапе этого алгоритма сопоставления рассматриваются OID добавленных и удалённых путей и проверяется их точное соответствие. Такие точные совпадения соединяются в пары.
Вторая стадия — дорогая часть вычислений: как обнаружить файлы, которые были переименованы и отредактированы? Посмотреть каждый добавленный файл и сравните этот файл с каждым удалённым, чтобы вычислить показатель схожести в процентах к общему количеству строк. По умолчанию что-либо, что превышает 50 % общих строк, засчитывается как потенциальное редактирование с переименованием. Алгоритм сравнивает эти пары до момента, пока не найдёт максимальное совпадение.
Вы заметили проблему? Этот алгоритм прогоняет A * D различий, где A — количество добавлений и D — количество удалений, то есть у него квадратичная сложность! Чтобы избежать слишком долгих вычислений по переименованию, Git пропустит часть с обнаружением редактирований с переименованием, если A + D больше внутреннего лимита. Ограничение можно изменить настройкой опции diff.renameLimit в конфигурации. Вы также можете полностью отказаться от алгоритма, просто отключив diff.renames.
Я воспользовался знаниями о процессе обнаружения переименований в своих собственных проектах. Например, форкнул VFS for Git, создал проект Scalar и хотел повторно использовать большое количество кода, но при этом существенно изменить структуру файла. Хотелось иметь возможность следить за историей версий в VFS for Git, поэтому рефакторинг состоял из двух этапов:
Эти два шага позволили мне быстро выполнить git log --follow -- <path>, чтобы посмотреть историю переименовывания.
Я сократил вывод: два этих последних коммита на самом деле не имеют пути, соответствующего Scalar/CommandLine/ScalarVerb.cs, вместо этого отслеживая предыдущий путь GVSF/GVFS/CommandLine/GVFSVerb.cs, потому что Git распознал точное переименование содержимого из коммита fb3a2a36 [RENAME] Rename all files.
Не обманывайтесь больше
Теперь вы знаете, что коммиты — это снапшоты, а не различия! Понимание этого поможет вам ориентироваться в работе с Git.
И теперь мы вооружены глубокими знаниями объектной модели Git. Не важно, какая у вас специализация, frontend, backend, или вовсе fullstack — вы можете использовать эти знания, чтобы развить свои навыки работы с командами Git'а или принять решение о рабочих процессах в вашей команде. А к нам можете приходить за более фундаментальными знаниями, чтобы иметь возможность повысить свою ценность как специалиста или вовсе сменить сферу.
Грабли вай фая: как не нужно настраивать беспроводную сеть
Давайте, наконец, побеседуем о сельхозинвентаре в беспроводных сетях. Ведь эту интересную тему так редко обсуждают! А ведь неопытных пользователей на пути настройки Wi-Fi связи подстерегает просто масса коварных «граблей». Осторожно, не наступите!
Чужой экспириенс. Или чуждый?
Что делают неопытные пользователи для повышения уровня своего экспириенса перед настройкой Wi-Fi сети? Конечно же, бродят закоулками интернета, в поисках необходимых крупиц знаний. Увы, наряду со знаниями современный интернет предлагает нам множество мифов, сказок, фантасмагорий и прочих легенд «народного творчества». Сила интернета - в свободе слова. И это же его слабость: выразить свое мнение о природе бозонов Хиггса теперь можно просто отложив на минуточку Букварь…
Поэтому всегда помните, чему учил великий дедушка Эйнштейн: «все относительно и зависит от точки зрения наблюдателя». Руководствуйтесь принципом «доверяй, но проверяй», и не ошибетесь. Ведь какова единственно верная настройка применительно к конфигурации вашего оборудования, можете установить только вы сами, проверив работу той или иной функции на практике. Учитывайте, что даже так называемое «общепринятое» или «общественное» мнение может быть ошибочным. Именно так когда-то было с пресловутым инцидентом с QoS, который якобы «отъедал» 20% пропускной способности компьютерной сети. И который все дружно кинулись отключать, потому что один «великий эксперт» из интернета совершенно неправильно понял разработчиков Microsoft, а у тех как обычно «не было времени объяснять». И куча человеко-часов труда была растрачена разными (и даже очень умными) людьми на абсолютно напрасное ковыряние в сетевых настройках. Признаться, и ваш покорный слуга согрешил с QoS по молодости лет. Прекрасное было время.
Так, быстренько прогоняем ностальгию! Ведь нам вообще в другую сторону: у нас пробежка по беспроводным граблям.
Гребемся в безопасности: уйма настроек, которые… Не нужны.
Помнится в статье, касающейся раздачи Wi-Fi с телевизора, я поддержал компанию LG в ее подходе к безопасности сети. Все возможности пользователя по настройке безопасности были ограничены единственной опцией смены пароля! И на самом gagadget, и на сайтах «спионеривших» данную статью, непременно находились мастера тонкой настройки безопасности, гневно осуждающие такой подход. Им, видите ли, подавай разнообразие настроек! Видимо в глубине души, где-то очень глубоко, эти люди чувствуют себя великими гуру-учителями дзен безопасности. Но нирвана заядлых настройщиков разрывается о суровую действительность реального мира.
Какие настройки безопасности предлагает нам Wi-Fi сеть? Это построение защиты в соответствии со стандартами WEP, WPA и WPA2 при использовании алгоритмов шифрования TKIP и AES.
Стандарты WPA имеют простой режим, он же WPA-Personal, он же Pre-Shared Key (WPA-PSK) и расширенный режим аутентификации, он же WPA-Enterprise.
Пробежимся по ним, лавируя между граблями. Метод защиты WEP (Wired Equivalent Privacy) вы можете использовать, только если хотите предоставить соседским мальчишкам реальный шанс опробовать свои силы во взломе беспроводных сетей. Если они талантливы – управятся за считанные минуты. Если очень ленивы – справятся за день, с перерывом на обед. Думаю, такой вариант безопасности сети на сегодня не устраивает 99,99999% пользователей, кроме тех редких чудаков, которые пишут комментарии, откладывая Букварь.
WPA (Wi-Fi Protected Access) – более сильная штука в плане защиты. Согласно стандарту IEEE 802.11i при использовании защищенного беспроводного доступа WPA применяется временный протокол целостности ключа TKIP (Temporal Key Integrity Protocol). Это звучит так прекрасно! И сеть была бы на замке, если не учитывать «но». Первое «но» прозвучало еще в 2008 году, когда умными людьми был предложен способ взлома ключа TKIP за несколько минут, что позволяло перехватывать данные в сети. А в 2009 году японцы занимались в университете непонятно чем, и нашли способ гарантированного взлома WPA сетей. WPA, давай до свиданья!
Картина с безопасностью Wi-Fi была бы совсем безрадостной, если бы уже почти десять лет обязательным условием для сертификации любых Wi-Fi устройств не являлась поддержка протокола защищенного беспроводного доступа WPA2, использующего алгоритм шифрования AES (Advanced Encryption Standard). Именно благодаря уникальному сочетанию WPA2+AES современная беспроводная сеть может быть надежно защищена. Если пользователь не какал, простите, на ее безопасность.
Таким образом, режим WPA-Personal, защищенный доступ WPA2 и шифрование AES ((WPA-PSK) + WPA2 + AES) – это все что пользователю нужно знать о настройках безопасности беспроводной сети. Иного адекватного варианта просто нет. Именно этот вариант по умолчанию предлагала в своем телевизоре компания LG, за что я ее и похвалил. Все остальные вариации настроек – от лукавого. Чей нездоровый интерес удовлетворяют производители беспроводного оборудования, предлагая давно ненужные и устаревшие опции настройки в современных Wi-Fi устройствах, я не знаю. Ориентация на тех, кто уже одолел букварь, но все еще чувствует себя неуверенно при виде таблицы умножения? Возможно.
Ах да! Ведь есть же еще «популярный» режим работы Wi-Fi сети вообще безо всяких защит! И каждый второй обзиратель беспроводного оборудования не преминет упомянуть: вот это, ребята, и есть искомый идеал – режим самой высокой производительности Wi-Fi! А всякое там шифрование только снижает скорость связи. Ой ли?
Безопасность без тормозов.
Получается, чтобы получить максимальную скорость работы сети, мы должны пожертвовать безопасностью? Но это как-то очень похоже на грабли, даже на первый взгляд. У таких утверждений вроде бы есть и рацио: ведь при передаче на шифрование/дешифровку сигнала требуется дополнительно время. Однако это было бы справедливо в идеальном мире. Наш мир несправедлив. Его мрачные реалии таковы, что скорость передачи данных по беспроводной сети столь низка (возможно, в сети стандарта 802.11ас расклад и отличается, пока у меня нет возможности это проверить, но все сказанное абсолютно справедливо для сетей 802.11 b/g/n), что процессор вполне справляется с шифрованием практически в «фоновом» режиме. Поэтому скорость Wi-Fi сети при адекватно настроенном шифровании ((WPA-PSK) + WPA2 + AES) не падает по сравнению с режимом без шифрования. Спросите об этом у любого производителя сетевого оборудования, он вам это подтвердит. Или можете просто проверить на своем роутере и убедиться в этом лично. Однако при других настройках безопасности скорость сети может падать (подробности немного далее). Поэтому следите, чтобы сетевые настройки на всем оборудовании были корректны и какие-нибудь малозаметные грабельки в одном месте не приводили к снижению скорости передачи данных всей сети. Ну, собственно к скорости давайте и перейдем.
По граблям со скоростью
Есть еще один распространенный среди обзирателей миф – якобы беспроводная сеть «сбрасывает обороты», работая на скорости самого медленного Wi-Fi устройства из подключенных. Ничего подобного! Разработчики Wi-Fi не падали с дуба! А даже если и падали, то невысоко. Поэтому роутер или точка доступа общаются с каждым беспроводным устройством индивидуально и на максимально доступной для него скорости, разумеется, в рамках скоростных возможностей используемой сети. Так, при использовании смешанного режима mixed mode 802.11g/n устройства, поддерживающее скорость сети n, не будут сбрасывать скорость до стандарта g. Скорость беспроводной сети будет снижаться только во время связи с устройствами, поддерживающих g-стандарт. Просто нужно понимать, что чем больше будет в беспроводной сети таких медленных устройств и чем больше будет у них трафик, тем медленнее будет работать беспроводная сеть в целом. Поэтому производители и не рекомендуют использовать всякие там mixed режимы и ограничится выбором стандарта 802.11n для современной сети. Исключение – когда в хозяйстве есть старые, но дорогие сердцу устройства, несовместимые со стандартом 802.11n. Например, ноутбуки. Впрочем, для них вполне можно прикупить какой-нибудь недорогой Wi-Fi адаптер с поддержкой стандарта n и не отказывать себе в скорости беспроводного серфинга.
Самые «горячие головы» в порыве энтузиазма советуют сразу же отключить всякие «режимы экономии» и перевести роутер, точку доступа или сетевую карту в режим максимальной мощности передачи – для повышения скорости.
Однако ни к какому заметному результату, окромя дополнительного нагрева устройства, это не приведет. Попытка выявить увеличение скорости работы сети при повышении мощности передачи роутера или сетевого адаптера в пределах моей скромной квартиры успехом не увенчалась – сеть работала на одинаковой скорости независимо от мощности радиосвязи. Разумеется, если у вас большой частный дом, совет может оказаться дельным – для устойчивой связи в самых дальних комнатах мощность сигнала действительно желательно повысить. Жителям обычных городских квартир максимальная мощность Wi-Fi просто ни к чему, она будет только мешать соседским сетям. К тому же беспроводные устройства находящемся недалеко от роутера или точки доступа при максимальной мощности передачи могут работать даже менее стабильно и быстро, чем при более низкой мощности. Поэтому всегда начинайте с
а там уже смотрите по обстановке.
А вот неправильные настройки безопасности сети вполне способны отрицательно сказаться на скорости! Почему-то даже писатели мануалов к роутерам, не говоря уже об обзирателях, при выборе настройки безопасности рекомендуют выбирать шифрование TKIP + AES. Однако если налажать и использовать режим шифрования TKIP в mixed mode сети, то скорость всей сети автоматически упадет до 802.11 g, поскольку сетями 802.11n такой устаревший тип шифрования просто не поддерживается. Оно вам надо? Сравните:
Пропускная способность беспроводной WPA-PSK сети в режиме шифрование AES, раскрывается весь потенциал 802.11n (около 13,5 Мб/с):
И пропускная способность этой же беспроводной сети при использовании шифрования TKIP (около 2,8 МБ/с):
Сравнили? А теперь забудьте про этот TKIP вообще! Это просто старые ужасные грабли.
Если кому интересно - пропускная способность сети в обеих случаях замерялась при передаче одно и того же файла (iso образа диска) размером 485,5 МБ между единственным передатчиком (роутер) и единственным приемником (Wi-Fi карта ноутбука) в беспроводной сети.
Ускорение с тормозами
Пожалуй, не буду рассказывать про длинную и короткую преамбулу и прочую чепуху, оставшуюся в настройках сетевого оборудования с доисторических времен – это утратило актуальность еще с приходом стандарта Wi-Fi 802.11g, когда длинные преамбулы ушли на вечный покой. Но, тем не менее, некоторые интересные «плюшки» ускорения Wi-Fi сохранились еще с тех пор. Это, например, возможность использования Short GI. Что за…?
Поясняю. Wi-Fi оборудованием используется так называемый Guard Interval. Это пустой промежуток времени между последовательно передаваемыми по беспроводной связи символами (обычно шестнадцатеричными). Интервал имеет важное прикладное значение – он используется для снижения уровня ошибок при беспроводной передаче данных. Стандартный Guard Interval имеет продолжительность 800нс. Предполагается, что за 800нс отправленный радиосигнал гарантированно попадет на приемное устройство с учетом всех возможных задержек, и можно будет отправлять следующий символ.
Ну так вот, «оверклокеры Wi-Fi», предлагают сократить защитный интервал. Short GI означает Guard Interval сокращенный вдвое, до 400нс. В теории по расчетам британских ученых это должно поднять скорость работы беспроводной сети примерно на 10% с небольшим. Отлично же! И вроде как в пределах небольшой сети «подводных каменей» для быстрых волн Wi-Fi не должно быть при Short GI. На это когда-то купился и я. Около года мой роутер проработал с Short GI, пока в один прекрасный момент я не решил померять прирост производительности от этого «улучшайзера». Померял. И чуть не откусил себе локти!
Нет, это даже не грусть, это вообще печаль какая-то! Скорость работы сети с параметром Short GI оказалась раза так в два ниже, чем с нормальным Guard Interval . Почему так произошло? Потому что в условиях перенасыщенного соседними сетями радиоэфира количество ошибок приема/передачи при сокращении Guard Interval существенно возросло! Увы, урезанием интервала снижения ошибок в реальных условиях можно добиться не роста, а наоборот, падения производительности беспроводной сети. Вот так грабли с сюрпризом! Это еще раз подтверждает аксиому: если применяет очередной «ускоритель» сети, всегда проверяйте полученный результат!
Свободу каналам!
Львиная доля писателей советов по ускорению Wi-Fi рекомендуют непременно «вручную» поискать наименее загруженные частотные радиоканалы и принудительно прописать их в настройках роутера для своей сети. Они почему-то совершенно забывают, что современный роутер сам способен выбирать наименее загруженные каналы при инициализации сети и начинать работу на них. Если же прописывать каналы принудительно, то возможна ситуация, как в сказке про двух баранов на мосту. Например, когда один настройщик «прописывал» каналы, соседский роутер не работал, и наоборот. В итоге возникает вариант, когда наиболее близкие соседние сети по итогам «ручных» настроек оказываются на одних и тех же каналах. И поскольку настройки жестко заданы пользователем, сам роутер уже не в состоянии ничего изменить и упорно работает на занятых частотах. В результате соседние сети, использующие широкий (40 МГц) диапазон для беспроводной связи, активно мешают друг другу, а пользователи плюются от низкого качества связи.
Чтобы не наступить на эти неприятные грабли, предоставьте Wi-Fi роутеру возможность самостоятельно проверить эфир и выбрать свободные радиоканалы.
За сим раскланиваюсь, светлого вам беспроводного будущего!
Почитайте еще про настройку беспроводных сетей:
А посмотреть доступные на рынке устройства для раздачи беспроводного интернета можно в нашем каталоге Wi-Fi-роутеров.
Подписывайтесь на наш нескучный канал в Telegram, чтобы ничего не пропустить.
Первый контакт
Приходится проявлять смекалку, не имея доступа к материнской плате с BMC. Изучая технические характеристики серверных материнок, мы обнаружили, что некоторые из них используют чип Intel 82574L. Он, согласно документации, обеспечивает «SMBus advanced pass-through interface» – как раз то, что нужно. А что лучше всего, он бывает в формате карт PCI-E.
Доступ к SMBus
Мы сходили в магазин, и теперь у нас есть карточки Intel EXPI9301CTBLK с чипом 82574L. Что теперь?
В документации можно отследить SMB_DAT и SMB_ALRT_N. К счастью, все они оказались доступными на контактных площадках. Вроде бы всё достаточно легко.
NIC PCB. Слева вверху – EEPROM, справа вверху — коннектор для SMBus [ALRT|CLK|DAT]. Обратите внимание, что R39 и R40 отпаяны, что запрещает доступ к SMBus для коннектора PCIe.
Мы подключили зонд I 2 C и просканировали SMBus, но ничего полезного не считали. Документация говорит, что SMBus включается только при установке определённого битового регистра. Это значение загружается с EEPROM. Пришло время копнуть глубже.
Включаем доступ к SMBus
Нам снова помогает документация. Доступ к SMBus определяется значением регистра, загружаемого с NIC EEPROM. К счастью, EEPROM можно прочесть при помощи flashrom. Сбросив содержимое EEPROM, мы можем проанализировать и изменить значения:
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25X40" (512 kB, SPI) on buspirate_spi.
Reading flash. done.
Судя по NVM map (глава 6.1 документации), видно, что нам надо изменить два значения:
- Init Control Word 2[MNGM] (Datasheet chapter 6.1.1.6)
- Compatibility[ASF SMBus Connected] (Datasheet chapter 6.1.2.1.1)
- Compatibility[SMBus Connected] (Datasheet chapter 6.1.2.1.1)
После этого нам надо ещё разобраться со значением Checksum. В главе 6.1.2.11 указано, что сумма всех слов в диапазоне [0x00-0x40] должна равняться 0xBABA. Немного Python поможет нам подсчитать правильную контрольную сумму:
import struct
data = open('/tmp/flash.mod', 'rb').read()
tot = 0
for i in range(0x3f):
tot = (tot + struct.unpack('<H',data[2*i:(2*i)+2])[0]) & 0xffff
И вот, наконец, все наши изменения для EEPROM:
< 00000000: 6805 ca89 b22e 2004 46f7 8010 ffff ffff h. .F.
> 00000000: 6805 ca89 b22e 3014 46f7 8010 ffff ffff h. 0.F.
< 00000010: 69e4 0881 6b02 1fa0 8680 d310 ffff 5a9c i. k. Z.
> 00000010: 69e4 0881 6b02 1fa0 8680 d310 ffff 5adc i. k. Z.
< 00000070: ffff ffff ffff ffff ffff 3001 ffff 0bef . 0.
> 00000070: ffff ffff ffff ffff ffff 3001 ffff fb9e . 0.
После внесения изменений и прошивки EEPROM мы подсоединили I 2 C зонд и:
i2c1> scan
Device found at address 0x49
i2c1>
Адрес I 2 C кодируется в семи битах, требуемый нам адрес получается, как 0x49 << 1 = 0x92.
Теперь у нас есть рабочая схема для нашего импланта. Мы можем отправлять команды в NIC:
Заключения
Мы описали возможный метод внедрения небольшого и недорогого микроконтроллера в качестве импланта на уровне NIC. Такому импланту нужны, по меньшей мере, четыре контакта (Vcc, GND, CLK, DAT), и он может управлять картой сервера. Среди его возможностей:
- Прослушивание входящего сетевого трафика на сервер.
- Получение команд из сети без ведома сервера.
- Передача данных по сети без ведома сервера.
Однако в реальной жизни доступ у такого импланта был бы только к SMBus. В зависимости от схемы материнской платы это устройство может быть единственным из доступных, и тогда взаимодействие с ОС сервера будет невозможно. В случае, когда требуется полный контроль над ОС, лучше всего будет изменить код BMC, поскольку у него и так уже есть доступ ко всем интересным шинам, и он не оставляет видимых следов на материнке.
Ещё один недостаток такого импланта состоит в том, что он может передавать данные на скорости порядка 100 Кб/с, чего недостаточно для полного изучения трафика. Кроме того, имплант способен перехватывать только трафик, приходящий из сети. В результате данное решение кажется неэффективным по сравнению с теми усилиями, которые требуются для его внедрения в оборудование цели.
Скорость по Wi-Fi ниже скорости по проводу
Как превысить скорость 100 мбит/с по проводу?
Стоит ноутбук Ноутбук Samsung ATIV Book 8 880Z5E . Win 10 LAN контролер Realtek PCIe GBE Family.
Равна ли скорость радиоволн скорости света?
В этом разделе много говорят о скорости света и всем что с ней связано можете тогда объяснить такую.
Скорость скачивания ниже заявленной
Приветствую. У меня был инет на 4 Мбита - как то не заморачивался со скоростью скачивания. А тут.
Реальная скорость ниже заявленой
Здравствуйте, проблема следующая - скорость соединения в разы ниже той, что была заявлена.
сделай скрин из проги inssider insect_87, думал адаптер не поддерживает 11n, но оказалось поддерживает.
Перейти на частоту 5 ГГц не дает, просто нет выбора, только 2.
Скрин приложил.
проверь
1) панель управление - электропитание - настройки текущего плана электропитания - изменить доп параметры электропитания - параметры адаптера беспроводной сети - режим энергосбережения - максимальная производительность
2) Панель управления\Сеть и Интернет\Сетевые подключения
ПКМ по беспроводное сетевое подключение - свойства - настроить - управление электропитанием
разрешить отключать устройство для экономии электроэнергии - должно быть выключено
сделай скрин, чтобы было видно все свойства
3)Панель управления\Сеть и Интернет\Сетевые подключения
ПКМ по беспроводное сетевое подключение - свойства - настроить - дополнительно
Делаем имплант
Теперь, зная, как можно общаться с NIC, посмотрим, как можно использовать этот канал для кражи сетевого трафика и отправки данных по сети. В главе 8 документации описано всё, что нужно для этого.
Отправка пакетов
Описана в главах 8.6 и 8.8.1. Мы можем просто создать фрейм Ethernet при помощи команд. Вот пример скрипта для Hydrabus или Bus Pirate для отправки пакета:
import serial
import struct
from scapy.all import *
После выполнения скрипта можно увидеть пакет, идущий от машины с имплантом, и, что самое интересное, сам сервер вообще не видит этого пакета:
Tcpdump с машины атакующего слева, сервера – справа
Чтение пакетов
Фильтрация
Чтобы узнать, какие фреймы должны пойти в SMBus, NIC использует управляющие фильтры. Они сопоставляют трафик из сети, и либо перенаправляют его на PCIe, либо на SMBus, либо одновременно и туда и туда. С нашей точки зрения это даёт нам большую гибкость:
- Можно отслеживать трафик, поставив фильтр, который будет его проверять и перенаправлять на PCIe и SMBus.
- Можно заставить трафик исчезнуть, направив его только на SMBus.
- Можно создать скрытый канал, который не будет виден серверу с имплантом.
- UDP/TCP port
- VLAN
- IPv4 – IPv6
- MAC address
- …
Доступно семь независимых фильтров MDEF[0:6], и каждый из них можно настроить на перенаправление соответствующего трафика на PCIe поверх SMBus при помощи регистра MANC2H (подробности в главе 8.4.3).
Реализация
Настроить всё правильно оказалось довольно сложно, мы пробовали множество различных комбинаций, чтобы заставить фильтр работать. К счастью, примечание к приложению от Intel дало нам больше деталей по поводу запуска фильтров нужным нам способом.
Используя наш I 2 C-зонд, мы можем настроить всё это четырьмя командами:
// Глобальный запрет фильтров
[ 0x92 0xca 0x01 0x40 ]
// Настроить MDEF[0] на получение фреймов, идущих к UDP/664 и UDP/623
[ 0x92 0xcc 0x06 0x61 0x00 0x00 0x00 0x0c 0x00 ]
// Настроить MANC2H на запрет перенаправления к ОС
[ 0x92 0xcc 0x05 0x0a 0x00 0x00 0x00 0x00 ]
// Включить фильтрацию (SMBus alerting, status reporting / Enable)
[ 0x92 0xca 0x01 0x45 ]
Как описано в главе 8.8.1.3, необходимо установить несколько битов для того, чтобы разрешить получение данных и для отправки фреймов обратно на наш имплант. Мы выбрали SMBus alert, поскольку другие модели позволяют сетевой карте осуществлять асинхронные запросы к SMBus (детали в главе 8.4.5).
Чтение фреймов
Поскольку мы использовали метод SMBus alert, нам нужно было ожидать отключения сигнала SMB_ALRT_N перед отправкой команды Receive TCO Packet. Если бы мы ждали слишком долго, пакет был бы отвергнут NIC.
Чтобы просто проиллюстрировать схему, мы будем отправлять фреймы периодически и отправлять команды на чтение – просто, чтобы подтвердить, что этот принцип работает. Схема выглядит так:
- У сервера с имплантом установлены фильтры, отслеживающие трафик с UDP / 623 (глава 3.6.1.2).
- Имплант симулируется при помощи Hydrabus.
- Другой сервер отправляет пакеты, попадающие под фильтр, при помощи скрипта Scapy:
Получается нечто интересное:
Слева SMBus читает фрейм, данные фрейма показаны внизу. Справа tcpdump, работающий на сервере с имплантом, не показывает входящих фреймов.
Ретрансляция фреймов
Меняя регистр MANC2H, возможно сделать так, чтобы трафик, который отправляется на SMBus и PCIe, корректно отображался на сервере. К примеру, давайте создадим перехватывающий фильтр, реагирующий на трафик UDP/161 (SNMP) и отправляющий его на SMBus и PCIe:
// Глобальный запрет фильтров
[ 0x92 0xca 0x01 0x40 ]
// Создать флекс-фильтр 0 на порту 161 (0xa1)
[ 0x92 0xcc 0x04 0x63 0x00 0x00 0xa1 ]
// Настроить MDEF[0] на получение трафика, совпадающего с флекс-фильтром 0
[ 0x92 0xcc 0x06 0x61 0x00 0x00 0x00 0x10 0x00 ]
// Настроить MANC2H на разрешение перенаправления трафика MDEF[0] на PCIe
[ 0x92 0xcc 0x05 0x0a 0x00 0x00 0x00 0x00 ]
// Включить фильтрацию (SMBus alerting, status reporting / Enable)
[ 0x92 0xca 0x01 0x45 ]
Вверху – перехваченный SNMP-запрос с импланта. Внизу — SNMP-запрос дошёл до сервера.
Читайте также: