Тут, кажется, вам только эксперименты помогут. Я в своей работе в принципе не отдаю опцию 60, так загружается самый простой режим, который (по крайней мере у меня) работает.
Когда я пытался отвечать с PXEClient, то сетевуха по спецификации делает ещё один DHCPproxy-запрос юникастом на другой порт. В общем, меня такое поведение не радовало и поэтому я не использую опцию 60.
С конкретной моделью не работал, но в общем нахватался забавных ситуаций. Не готов ответить по-научному и со всеми пруфами, но направление для отладки, надеюсь, смогу вам подсказать.
В общем случае могу сказать, что если вы уверены, что DHCPOFFER доходит до сетевухи, а сетевуха не хочет отправлять DHCPREQUEST, то это значит, что ваш оффер не удовлетворяет требованиям сетевухи.
Я, в частности, обнаружил, что «обычный» PXE игнорирует офферы, если в них нет next-server и bootfile. В некоторых случаях у сетевухи два режима загрузки — в соответствии со спецификацией интела и какой-то «обычный» режим. Так вот первый режим требует в ответе опции 60 со значением PXEClient, иначе тоже игнорирует офферы.
Послушайте трафик, там есть опция, кажется, 54, Parameter LIst называется, там указан список опций, которые хочет видеть сетевуха. Сравните этот список с тем, что вы предоставляете и, может быть, это и будет решением.
Технические характеристики «железного» радио — это, действительно, вам в статью по ссылке из начала. Сам проект Ka-Radio32 не то чтобы развивается семимильными шагами, но его сложно называть заброшенным. А ещё он достаточно неплохо работает.
А «проект заброшен, с багами» относится к интеграции, которая связывает Home Assistant и Ka-Radio32.
Так уж получилось, что мои познания в JS меньше, чем умение строить велосипеды. В конце концов, эта статья про разбор png, а не про попытки поладить с малознакомой мне платформой на не сильно знакомом мне языке =)
Но ваш комментарий, я, безусловно, приму к сведению. Благодарю!
Я работаю с Mi Smart Band 9, потому что на 4pda какое-то нереальное запустение на тему приложений, только перезаливы с китайских форумов. У самого «семерка», но ей в плавности до «девятки», конечно, далеко. А хочется плавность девятки и софт как на семерке, поэтому потихоньку наскребаю порты легенд.
Насколько я понял, quickapp'ы, которые rpk-приложения, очень ограничены. У них есть набор интерфейсов, но и те как-то через пень-колоду сделаны. Чтение файлов, там, например, не open/read/write/close, а отдельный метод, который по имени файла считывает нужное количество байт с нужного оффсета. Так что побайтовое чтение там вряд ли реализуемо в нормальном понимании этого словосочетания. И такого много, поэтому я хз, как из JS-окружения дёргать что-то внутри ОС и до сего момента были сомнения в том, что это вообще возможно.
Я буду рад, если вы скажете, что я не прав, и эти приложения могут больше, чем кажется на первый взгляд. Что-то вроде тулбокса с семерки было бы очень приятно иметь.
Я видел «магические» циферблаты, которые могут удалять приложения и с них вышел на ваш репозиторий с EasyFace и lua-скриптами в циферблатах, которые имеют доступ к ОС. Но циферблаты, на мой взгляд — это не то.
Можете более подробно раскрыть мысль про либы png? Это нативные библиотеки и их как-то можно вызывать из JS? Или это какие-то недокументированные JS-библиотеки?
Устройства из экосистемы Xiaomi Vela. Там приложения пишутся на упрощенном Vue.js, так что libpng может и можно принести, но слинковать с приложением или запустить как-то иначе не получится.
Xiaomi Redmi Watch 4 на другой платформе -- VelaOS (HyperOS), на той же, что и Mi Smart Band 8 Pro и 9. Там навороченные циферблаты делать нельзя. Приложения -- можно, но что-то на 4pda этим никто не занимается о.О
Нет, поля не выравниваю. Была идея извлекать ячейки с условием, а весь остальной сканворд нарисовать на «конве», но тогда нужно извлекать ещё и стрелочки. В общем, решил максимально не усложнять в первой итерации.
Я могу ответить только достаточно поверхностно: LLM и рисующие нейросети имеют разную специфику и, соответственно, архитектуру.
Ранее в статье про Midjourney я писал, что у них появилась команда /shorten, которая немного показывает как работает токенайзер, который удаляет предлоги и прочий «шум». Ну и генерация изображения -- это итеративный процесс, в котором картинка за пару десятков шагов «вытягивается» из шума. Причем картинки, в общем-то, понятны на любом языке. На страничке анонса SD3 написано, что их новые модели имеют от 800 миллионов параметров до 8 миллиардов. Примем эти «параметры» за некую метрику размера модели.
Языковые модели -- это трансформеры, которые получают текст на вход и «угадывают» какой токен должен быть следующим. И с текстом есть проблемы: языков много.
Для сравнения GPT-J-6B, опенсурсный аналог GPT-3, состоит из 6 миллиардов параметров и (в моих тестах) достаточно часто говорит дичь. Причем только на английском. Википедия заявляет (а она может врать), что настоящая GPT-3 содержит 175 миллиардов параметров, ну и GPT-3 уже умела говорить на многих языках.
Отсюда простой вывод: чем больше параметров в модели -- тем больше нужно мощности, чтобы с ней поладить.
Ну, месяц прошёл. Приём ответов этим комментарием закрывается.
И ответ для желающих, а также явно тегну @whocoulditbe и @DimaFromMai, как людей, которые показали свой интерес, но не дошли до решения.
Задача этого дампа была использовать описанные в статье приёмы, но не сделать решение невозможным.
Шаг 1
Большая часть статьи посвящена тому, что символы кодируются как разница между временными метками в теле ICMP-пакета. Автоматизируем разбор дампа, в моем случае -- через scapy.
Если считать с ограничением в миллисекунды, как указано в статье, то разница -- идеально точная секунда. Так не бывает :) Считаем в микросекундах и получается что-то такое:
Что делать с этим набором данным -- под следующим спойлером.
Шаг 2
Это, конечно, ещё не ответ, но раз нам обещали загадку, значит ответ где-то рядом. В статье можно найти такой абзац:
Если передавать необходимо текст, то можно использовать компактную кодировку. Например, только заглавные буквы алфавита и пробел: 34 символа для русского алфавита. А если алфавит отсортировать с учетом частотности символов, то отклонение множества пакетов будет в рамках погрешности и заметить передачу будет сложнее.
33 буквы алфавита + пробел = 34 символа. В нашем массиве данных минимальное значение 0, максимальное -- 33, отлично подходит. Переходим по ссылке и честно забираем оттуда буквы в порядке убывания частотности символа. При это заглавные буквы будут или строчные -- неважно, на ответ не влияет. Получается что-то такое:
Остается вопрос: где должен быть пробел. Хотя пробел можно расположить куда угодно, это всего 33 строки на проверку, что относительно быстро перебирается. Но интуитивно хочется поместить в начало (код 0) или в конец (код 33).
dec = [voc[i] for i in data]
print("".join(dec))
Ответ
Пробел прячется на нулевой позиции. Ответ:
в этом дампе нет совершенно никакого сообщения тчк совсем тчк точно тчк это всё обман
Эхо-запросы по умолчанию (с их 32 или 56 байтами данных) весьма неприметные. И к пакетам с малым объемом минус "легко обнаружить из-за размера" действительно неприменим. Мало ли кто что пингует.
В тексте неприметность заключается в том, что эхо-запрос может быть создан кем угодно с какой угодно мотивацией. А вот если вы начнете рассылать эхо-ответы без запроса или пакеты про TTL без входящего трафика, то вопросов будет даже больше.
Пардон, пропустил уведомление о комментарии.
Тут, кажется, вам только эксперименты помогут. Я в своей работе в принципе не отдаю опцию 60, так загружается самый простой режим, который (по крайней мере у меня) работает.
Когда я пытался отвечать с PXEClient, то сетевуха по спецификации делает ещё один DHCPproxy-запрос юникастом на другой порт. В общем, меня такое поведение не радовало и поэтому я не использую опцию 60.
С конкретной моделью не работал, но в общем нахватался забавных ситуаций. Не готов ответить по-научному и со всеми пруфами, но направление для отладки, надеюсь, смогу вам подсказать.
В общем случае могу сказать, что если вы уверены, что DHCPOFFER доходит до сетевухи, а сетевуха не хочет отправлять DHCPREQUEST, то это значит, что ваш оффер не удовлетворяет требованиям сетевухи.
Я, в частности, обнаружил, что «обычный» PXE игнорирует офферы, если в них нет next-server и bootfile. В некоторых случаях у сетевухи два режима загрузки — в соответствии со спецификацией интела и какой-то «обычный» режим. Так вот первый режим требует в ответе опции 60 со значением PXEClient, иначе тоже игнорирует офферы.
Послушайте трафик, там есть опция, кажется, 54, Parameter LIst называется, там указан список опций, которые хочет видеть сетевуха. Сравните этот список с тем, что вы предоставляете и, может быть, это и будет решением.
Я видел мем, что при вопросе про платные подписки deepseek отвечает что-то вроде "абсолютно бесплатно", а потом добавляет про подписку плюс =)
Я не смог добиться такого, да и может это фотошоп, но полностью исключать нельзя.
Технические характеристики «железного» радио — это, действительно, вам в статью по ссылке из начала. Сам проект Ka-Radio32 не то чтобы развивается семимильными шагами, но его сложно называть заброшенным. А ещё он достаточно неплохо работает.
А «проект заброшен, с багами» относится к интеграции, которая связывает Home Assistant и Ka-Radio32.
Так уж получилось, что мои познания в JS меньше, чем умение строить велосипеды. В конце концов, эта статья про разбор png, а не про попытки поладить с малознакомой мне платформой на не сильно знакомом мне языке =)
Но ваш комментарий, я, безусловно, приму к сведению. Благодарю!
Вот это поворот.
Я работаю с Mi Smart Band 9, потому что на 4pda какое-то нереальное запустение на тему приложений, только перезаливы с китайских форумов. У самого «семерка», но ей в плавности до «девятки», конечно, далеко. А хочется плавность девятки и софт как на семерке, поэтому потихоньку наскребаю порты легенд.
Насколько я понял, quickapp'ы, которые rpk-приложения, очень ограничены. У них есть набор интерфейсов, но и те как-то через пень-колоду сделаны. Чтение файлов, там, например, не open/read/write/close, а отдельный метод, который по имени файла считывает нужное количество байт с нужного оффсета. Так что побайтовое чтение там вряд ли реализуемо в нормальном понимании этого словосочетания. И такого много, поэтому я хз, как из JS-окружения дёргать что-то внутри ОС и до сего момента были сомнения в том, что это вообще возможно.
Я буду рад, если вы скажете, что я не прав, и эти приложения могут больше, чем кажется на первый взгляд. Что-то вроде тулбокса с семерки было бы очень приятно иметь.
Я видел «магические» циферблаты, которые могут удалять приложения и с них вышел на ваш репозиторий с EasyFace и lua-скриптами в циферблатах, которые имеют доступ к ОС. Но циферблаты, на мой взгляд — это не то.
Можете более подробно раскрыть мысль про либы png? Это нативные библиотеки и их как-то можно вызывать из JS? Или это какие-то недокументированные JS-библиотеки?
Устройства из экосистемы Xiaomi Vela. Там приложения пишутся на упрощенном Vue.js, так что libpng может и можно принести, но слинковать с приложением или запустить как-то иначе не получится.
Xiaomi Redmi Watch 4 на другой платформе -- VelaOS (HyperOS), на той же, что и Mi Smart Band 8 Pro и 9. Там навороченные циферблаты делать нельзя. Приложения -- можно, но что-то на 4pda этим никто не занимается о.О
В самом конце блока «Разработка красивого приложения»:
По крайней мере я так ставлю. Но на 4pda можно найти и более специфичные варианты.
Ссылки поправлены, спасибо!
Жаль, что потраченного трафика уже не вернуть. Но картинку сжали и перезалили!
Нет, поля не выравниваю. Была идея извлекать ячейки с условием, а весь остальной сканворд нарисовать на «конве», но тогда нужно извлекать ещё и стрелочки. В общем, решил максимально не усложнять в первой итерации.
Если бы на Хабре можно было бы давать медальки своим подписчикам, я бы дал вам медаль I степени за преданность :)
civit.ai -> Models -> Filters -> (выбрать) SD3 -> Закрыть фильтры
Прям ссылку на эту поисковый запрос, увы, нельзя сделать.
Я могу ответить только достаточно поверхностно: LLM и рисующие нейросети имеют разную специфику и, соответственно, архитектуру.
Ранее в статье про Midjourney я писал, что у них появилась команда /shorten, которая немного показывает как работает токенайзер, который удаляет предлоги и прочий «шум». Ну и генерация изображения -- это итеративный процесс, в котором картинка за пару десятков шагов «вытягивается» из шума. Причем картинки, в общем-то, понятны на любом языке. На страничке анонса SD3 написано, что их новые модели имеют от 800 миллионов параметров до 8 миллиардов. Примем эти «параметры» за некую метрику размера модели.
Языковые модели -- это трансформеры, которые получают текст на вход и «угадывают» какой токен должен быть следующим. И с текстом есть проблемы: языков много.
Для сравнения GPT-J-6B, опенсурсный аналог GPT-3, состоит из 6 миллиардов параметров и (в моих тестах) достаточно часто говорит дичь. Причем только на английском. Википедия заявляет (а она может врать), что настоящая GPT-3 содержит 175 миллиардов параметров, ну и GPT-3 уже умела говорить на многих языках.
Отсюда простой вывод: чем больше параметров в модели -- тем больше нужно мощности, чтобы с ней поладить.
Ну, месяц прошёл. Приём ответов этим комментарием закрывается.
И ответ для желающих, а также явно тегну @whocoulditbe и @DimaFromMai, как людей, которые показали свой интерес, но не дошли до решения.
Задача этого дампа была использовать описанные в статье приёмы, но не сделать решение невозможным.
Шаг 1
Большая часть статьи посвящена тому, что символы кодируются как разница между временными метками в теле ICMP-пакета. Автоматизируем разбор дампа, в моем случае -- через scapy.
Если считать с ограничением в миллисекунды, как указано в статье, то разница -- идеально точная секунда. Так не бывает :) Считаем в микросекундах и получается что-то такое:
Что делать с этим набором данным -- под следующим спойлером.
Шаг 2
Это, конечно, ещё не ответ, но раз нам обещали загадку, значит ответ где-то рядом. В статье можно найти такой абзац:
33 буквы алфавита + пробел = 34 символа. В нашем массиве данных минимальное значение 0, максимальное -- 33, отлично подходит. Переходим по ссылке и честно забираем оттуда буквы в порядке убывания частотности символа. При это заглавные буквы будут или строчные -- неважно, на ответ не влияет. Получается что-то такое:
Остается вопрос: где должен быть пробел. Хотя пробел можно расположить куда угодно, это всего 33 строки на проверку, что относительно быстро перебирается. Но интуитивно хочется поместить в начало (код 0) или в конец (код 33).
Ответ
Пробел прячется на нулевой позиции. Ответ:
ICMP-пакеты, как и UDP-пакеты, фрагментируются при превышении MTU.
В загадке участвует только дамп. Так что гитлаб по хттп не является частью загадки.
Да. Если размер данных (флаг -s) больше паттерна, то паттерн вмещается несколько раз.
Эхо-запросы по умолчанию (с их 32 или 56 байтами данных) весьма неприметные. И к пакетам с малым объемом минус "легко обнаружить из-за размера" действительно неприменим. Мало ли кто что пингует.
В тексте неприметность заключается в том, что эхо-запрос может быть создан кем угодно с какой угодно мотивацией. А вот если вы начнете рассылать эхо-ответы без запроса или пакеты про TTL без входящего трафика, то вопросов будет даже больше.