Пофиксили баги что значит

Багфикс человека: как фиксить баги, которые мешают работать

Почему у людей не получается взять — и выполнить задачу? Откуда берутся заминки, неправильные оценки и прокрастинация? Почему люди не понимают друг друга, хотя вроде бы не дураки и общаются на одном языке?

Как оказалось, причина у всего этого одна — когнитивные искажения. Вот про них и поговорим.

Когнитивные искажения — баги в психике человека, которые мешают объективно воспринимать реальность. Их много и они водятся в каждом — на странице Википедии в списке когнитивных искажений под 130 пунктов, и 129 вы, скорее всего, обнаружите у себя. К ним относится сила первого впечатления, желание оправдываться и даже причина, почему мы не можем дать адекватную оценку по задаче.

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

Так как когнитивные искажения мешают работать, понимать друг друга и, по итогу, выполнять задачи, от них нужно избавляться. Это касается менеджеров, разработчиков, дизайнеров, аналитиков, копирайтеров — всех. В идеальном мире каждый сам отлавливает и фиксит свои искажения, но в реальности, как мы знаем, без тестировщиков (взгляда со стороны) такое редко случается. Так что будьте готовы: если вы не фиксите свой баг — однажды окружающие придут на помощь и заставят вас это сделать. А я расскажу, как именно 🙂 Не буду рассматривать все 130 искажений — пройдусь только по тем, которые были пойманы в нашей студии и которые часто встречаются у работников ИТ-сферы.

Генерализация частных случаев

Генерализация частных случаев — когнитивное искажение, из-за которого человек расширяет поставленную задачу. При этом он даже не осознает, что её можно выполнить проще и быстрее. Чаще всего встречается у программистов и редко фиксится самостоятельно. Чтобы вправить это когнитивное искажение, нужна помощь менеджера. Как минимум один раз ему придётся включить режим варан-менеджмента.

Так же пристально, как варан за своим будущим обедом, менеджер должен следить за работой разработчика или дизайнера. В отличие от зверей из дикой природы, они не помирают от этого, но — о чудо! — дело делается, а варан остается голодным 🙂 Кстати, программистам это только поначалу неприятно (ну и неприятна сама идея, что с ними так поступят). Дальше, как ни странно — человек втягивается и выравнивается.

Этот метод гарантированно ставит мозги на место и снижает прокрастинацию — и в итоге оказывается, что вместо недели задачу можно без особого напряга решить за один день. Или час. Или 20 минут. Ну вы поняли.

Это невозможно!

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

У такой реакции несколько причин:

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

Если вы словили это когнитивное искажение у коллеги — задайте ему тот же вопрос, какой задали бы себе: «Скажи, пожалуйста, что тебе потребуется, чтобы сделать эту задачу?». И повторяйте его, пока коллега не поймёт, что ему не верят, да и действительно задача не так уж и невыполнима.

Ну и в будущем, если ситуация повторится, на «Это невозможно!» у вас будет кейс, как человек задачу с таким же диагнозом решил за N минут. Напомните ему этот случай пару раз — и дальше он уже научится сам фиксить этот баг.

Проклятие знания

Проклятие знания — ситуация, когда человек более информированный не может рассмотреть проблему с точки зрения человека, который знает меньше. Отсюда, кстати, столько непонятых гениев. Среди менеджеров даже больше, чем среди программистов или дизайнеров. В основном этот багуля встречается у неопытных менеджеров — которым кажется, что сделать ВОТ ТАК было очевидным решением, которое даже проговаривать не обязательно (чего, естественно, и не было сделано и не сформулировано в задаче). А то, что программист/дизайнер/аналитик этого не понял — его косяк. Конечно, такое нужно фиксить.

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

Личное оскорбление

Следующее когнитивное искажение — когда критика результата воспринимается как личное оскорбление тем, чью работу критикуют.

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

Эффект генерации

Отдаю должное: не все когнитивные искажения — причина проблем и непонимания. Бывают и полезные. Например, «эффект генерации». Благодаря этому искажению человек лучше запоминает информацию, когда воспроизводит её сам, а не воспринимает извне. Поэтому если вы сомневаетесь, что правильно поняли задачу, или боитесь забыть — просто повторите её вслух.

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

Поэтому не бойтесь и не стесняйтесь повторять постановки — это реальный рабочий приём, проверенный пилотами.

Слепое пятно

Это как раз то, о чем я упоминал в начале статьи — мозг не хочет замечать свои несовершенства. Поэтому существует слепое пятно в отношении когнитивных искажений. Даже если человек знает о них, то вряд ли согласится, что они влияют на его поведение. А последствия спишет на обстоятельства и на глупость окружающих. И, соответственно, не сделает ничего, чтобы пофиксить свои когнитивные искажения.

Поэтому если вы замечаете, что задачи делаются с сучками и задоринками, и хотите это изменить — попробуйте оценить объективно, может, причина тому — когнитивные искажения? Если вам кажется, что конечно нет — лучше на всякий случай спросите коллег. Слепое пятно не действует в отношении чужих багов 🙂

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

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

Источник

Пофиксить

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

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

Значение термина

Для этого иностранного слова, широко распространенного среди молодежи существует два основных значения:

Происхождение

Слово имеет свои корни в английском языке: глагол «to fix» дословно обозначает «исправлять», «налаживать», «приводить в порядок», «чинить», «ремонтировать», «регулировать», «останавливать», «устанавливать».

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

Так же существуют другие разговорные обороты: «to fix a problem» — «решить проблему», «to fix a game» — «договор о выигрыше в игре за взятку».

В русском языке это термин «пофиксить» имеет несколько синонимов:

Употребление слова

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

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

Примеры употребления в разговорной речи

Дополнительно следует привести несколько примеров употребления данного термина:

Источник

Что значит «пофиксить» и «фиксить» в интернет-сленге?

В разговорах геймеров, программистов и других продвинутых юзеров мышки и клавиатуры часто проскакивают непонятные слова: фича, лаги, баги, фиксить… При этом человеку, далёкому от сферы, трудно сориентироваться в теме. Tакая терминология озадачивает, в то же время подогревая интерес и желание так же лихо форсить айтишным арго, как это делают профессионалы. Так давайте разберёмся!

Происхождение и значение

Основная часть интернет-сленга – результат русификации английских слов, и «фиксить» не стало исключением.

В переводе с английского, «tofix» означает «чинить». Среди русскоязычной аудитории прижился вариант «фиксить» или «пофиксить».

Английский язык, а также всевозможные русифицированные производные от английских слов или фраз, наполняют интернет-сленг. Что же касается общих чатов в MMORPG играх, то там сленг превалирует, и нубу (в том же сленговом выражении – «зелёному» новичку или неудачнику), не понятно ни единого слова. И в тех же играх это слово, кстати, имеет двоякое толкование.

Как «фиксят баги» в MMORPG

Помимо общепринятого, «пофиксить» может иметь негативный характер. Зачастую это значит, что определенную категорию лишат значительной части умений. Для примера, возьмем World of Warcraft с его многомиллионной армией подписчиков и почитателей по всему миру. Бывает, очередные обновления приносят не только улучшения и решения по самой игре, но и отдельные решения по игровым классам.

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

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

Игровые баги и лаги

Как фиксить системные баги?

Интернету на днях исполнилось 30 лет. Представить современный мир без него невозможно. Все, от мала до велика, начинают день с просмотра новостной ленты, свежих фотографий у друзей в Instagram или обновления статуса в «Одноклассниках». Всё привычно, никто не задумывается о том, что нужно залогиниться, войти в программу, каждое действие обыденно и производится автоматически. Всё идет хорошо, пока вместо привычной стартовой страницы экран не начинает показывать системные сообщения об ошибках.

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

Значительная часть сбоев происходит на уровне реестра ОС, для корректировки которого идеально подходит небольшая утилита Hijackthi.

Hijackthi – инструмент, помогающий фиксить баги

Это знакомая и привычная утилита для всех, кому понятие «админка» не режет слух. Фиксить сбои в среде Windows с её помощью удобно, и при понимании дела, абсолютно безопасно. Однако, если написание поста в Facebook – предел знаний IT-технологий, фиксить сбои самому лучше не браться, а обратиться к специалистам.

Источник

Пропустить нельзя пофиксить: баги в играх и почему их не избежать

Баги это дефекты и сбои, влияющие на пользовательский опыт, без которых редко обходится любой программный продукт. Чего уж греха таить, даже в играх VOKI Games встречаются эти мелкие вредители, несмотря на многоэтапное тестирование профессионалами.

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

Что такое баги в игре: цели тестирования продукта

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

Выявление «жучков», а именно так переводится английское слово bugs, – основная цель тестирования продукта. Оно проводится не только перед релизом игры, а и при мажорных (с серьезными изменениями) и даже минорных (с незначительными исправлениями и дополнениями) обновлениях, чтобы команда разработчиков могла найти баги, проанализировать их и устранить (т.е. пофиксить).

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

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

Тестирование игр: особенности работы тестировщиков

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

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

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

Как искать баги в мобильных играх

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

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

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

Одну и ту же игру могут тестировать месяцами и даже годами, если речь идет об огромном проекте. Чаще на тесты отводят 1–2 месяца, этого вполне достаточно для устранения основных уязвимостей и выпуска игры.

Уровни и категории багов

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

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

Кроме уровня серьезности, баги делятся на категории по типу ошибки:

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

Пользователи = тестировщики: как недоработки попадают в массы

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

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

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

Самые скандальные баги геймдева

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

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

Монстры отображались с искажениями, сервера постоянно выходили из строя, а багоюзеры становились игровыми богами. В течение нескольких лет игру привели в порядок, но все же Bethesda потеряла многих участников из-за ужасного качества релиз-версии.

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

Баги, плавно переходящие в фичи

Итог подведем своеобразно – баги могут стать фичами. Серьезно, это хоть и не происходит повсеместно, все равно имеет место в геймдеве. Стоит вспомнить хотя бы баг с поведением полицейских в Grand Theft Auto, которые не объезжали игрока, а старались проехать сквозь него. Копы-психопаты понравились разработчикам и юзерам, прочно войдя в последующие игры серии.

Легендарная «распрыжка» тоже изначально была багом, который появился в Quake. Ее оставили и в других играх (к примеру, Counter-Strike), поскольку запустить режим быстрого движения могли далеко не все игроки, а сам по себе он не был убер-плюшкой. То же касается и рокетджампа, который был замечен случайно, когда игрок выстрелил ракетой себе под ноги. Так родилась обновленная механика, до сих пор юзаемая прогеймерами.

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

Источник

Что нам стоит пофиксить баг, которого «нет»

Итак, у нас есть задача: пофиксить баг, производитель от которого открещивается, клиенты не замечают, а жить хочется. Есть камера, поток от неё на UDP просто адово ломается, поток на TCP работает, но постоянно рвутся коннекты (и при каждом обрыве пропадает 3-5 сек видео). Виновны в проблеме все (и камера и софт), но обе стороны утверждают что у них всё зашибись, то есть ситуация обычная: ты баг видишь? нет. А он есть.

Так как софт обновляется гораздо чаще, чем камера, имеет смысл править то место, которое потом не придётся трогать. Значит, будем фиксить со стороны камеры.

Исследование плацдарма

Перво-наперво берём свежайшую прошивку (в моём случае — firmware_TS38ABFG031-ONVIF-P2P-V2.5.0.6_20140126120110.bin), и выясняем что же она такое:

Итак, формат его неизвестен, стартовая метка «FIRMWARE» навевает мысли о том, что это что-то своё, наличие внутри uImage ядра и cramfs файлухи подсказывает, что по факту это что-то простое. Наличие строки TS38OEMABFG_LINUX подскзывает что это что-то даже напоминает какой-то вариант архива.

Так как нам сейчас надо просто найти где искать — просто вытаскиваем оттуда файловую систему, и ищем виновный модуль:

Хохохо! «sendRTPOverTCP failed, sock: %d, chn: %d» говорит нам о том, что код оттранслирован с отладочными принтами, а значит, объём работы снижен на порядки!

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

Локализация и фикс проблемы

Грузим модуль в дизассемблер, ищем по «OverTCP» строку отладочную, от неё ищем код вызывающий распечатку => мы нашли функцию sendRTPOverTCP.
Проглядывая её бегло видим два вызова функции send() — одна с 4 байтами, одна с буфером переданным на вход. Значит, нам досталась версия не самая старая, а когда уже объединили буфер, но еще не сделали функции sendDataOverTCP (подробности о различиях реализации — в прошлом посте.

Теперь возникает вопрос, как можно поправить баг в бинарном виде, когда практически нет запаса по месту (пустого пространства внутри файла нет).
Идём в функцию выше, которая вызывает sendDataOverTCP — sendPacket. Её код от версии к версии не менялся, он по сути один — foreach(streams) < sendDataOverTCP(packet, stream) >.

По счастью, код был щедро напичкан отладочными fprintf’ами, и это нас спасает! Вот как этот цикл выглядит в бинарном виде:

Это фактически спасение! Просто вырезка отладочного куска даёт нам место в размере 12 инструкций (у ARM все инструкции ровно по 4 байта, и это очень хорошо).

Итак, у нас есть место в 12 инструкций, чтобы что-то сделать для улучшения ситуации. Но что? Полноценно впихнуть сюда код sendDataOverTCP из последней версии будет сильно затруднительно…
Хотя стоп. А зачем? Я, вроде, подробно описал, что даже использование корректной формы sendDataOverTCP всё равно плохо… А если не видно разницы — почему бы просто не обернуть вызов в makeSocketBlocking()..makeSocketNonBlocking()?

Действительно, если место в системном буфере есть — send() выполнится моментально. Если места нет — то и их реализация sendDataOverTCP всё равно залипнет (почему залипнет а не вывалится сразу с нулём — смотри предыдущий пост).

Отлично! Путем быстрой отмотки назад от функции fcntl находим makeSocketBlocking и makeSocketNonBlocking, после чего рисуем какой должен получиться код:

Для того чтобы запатчить, либо открываем документацию на арм и транслируем в уме, либо пишем код в отдельном файле и транслируем его (не забываем ORG’ами выставлять точные адреса, чтобы все переходы (BL/BGE/ИТД) пересчитаны были корректно), а я всего лишь находил подходящие инстуркции в коде и на их основе вычислял нужные опкоды (первый раз редактирую ARM, уж извините).

В результате получаем rtsp_streamer с наложенным на него патчем, защищающим TCP поток от порчи.

Пайка взрывом, сборка трезвым

Итак, у нас есть новый rtsp_streamer, и есть firmware. bin в который его надо встроить. Ну тут, вроде, всё просто: надо распаковать cramfs, заменить файл, запаковать обратно, заменить его внутри bin’а:

Откроем его в hex редакторе, и начнём кумекать:
(0) «FIRMWARE» — 100% заголовок, 8 байт.
(8) 64 81 DB 15 — 4 байта, назначение непонятно. по запаху — контрольная сумма
(12) 0x00E847C4=15222724 — ага, 4 байта, размер прошивки. проверяем _new.bin — нет, размер не изменился, значит, он не при чем.
(16) 0x00000003 — 4 байта хз что. версия заголовка может?
(20) 0x00000614=1556 — так, а это смещение до ядра внутри
(24) 0x001BF1B0=1831344 — а это размер ядра (1831344+1556=1832900)
(28) 4C 21 81 5D — хм. опять что-то на контрольную сумму похожее.
(32) «TS38OEMABFG_LINUX» и куча нулей потом — 100h байт, явно место под название раздела
(288) 0x001BF7C4=1832900 — ага, смещение до следующей секции
(292) 0x00CC5000=13389824 — ага, размер секции
(296) «TS38OEMABFG_V2.5.0.6» и куча нулей — опачки. 100h байт, явно под название раздела.
Но контрольной суммы перед ней нет O_O
(552-1556) — нечто неизвестной наружности.

Итак, примерно суть ясна. Размер нашей cramfs не изменился, значит, это не размеры, а значит, контрольные суммы.
Извлекаем ядро, и считаем его контрольную сумму длиной 4 байта:

Ну-ка ну-ка… по смещению 28 как раз 0x5D81214C. Повезло — это стандартная CRC32. Повезло потому, что по стандартная тулза умеет только его считать. Иначе пришлось бы запускать питон и считать уже «сложнее» 🙂

Итак, контрольные суммы у нас — crc32. А какая контрольная сумма у оригинальной cramfs. 37499eef. Так-так-так. По смещению 552 как раз и записано 0x37499eef. Значит, для файловой системы почему-то контрольная сумма ПОСЛЕ имени раздела записана. Ну ОК, чего нам, мы не гордые. Обновляем табличку:
(28) 0x5D81214C — crc32 раздела ядра
(552) 0x37499eef — crc32 раздела FS
(556-1556) — нечто неизвестной наружности

Пересчитываем crc32 newcramfs, hex редактором вписываем по смещению 552 его в бинарь, заливаем в камеру.
И… ничего O_O. Значит, чутьё не подвело — по смещению 8 действительно crc32, но от чего?
Тут действуем просто — начинаем брутфорсить.

Отлично, быстро справились. Значит, обновляем табличку:
(8) 0x15DB8164 — CRC32 заголовка (первых 1556 байт), сперва занулив это поле

Итак, тут же в питоне быстро пересчитываем crc32 от заголовка firmware_new.bin и вписываем в hex редакторе его в начало.
Заливаем в камеру… Она уходит в ребут. И не отвечает… не отвечает… еще кирпич… О! Пинги пошли! Фууух.

Берём cam-resync.py, и опять тыкаем палочкой нашу камеру. И… и поток не ломается! Вот прямо вот так, с первой попытки! Уииии 🙂

На хлеб мажется, и есть уже можно, но что-то не то

Ранее упомянутый Андрей Сёмочкин тем временем собрал свою прошивку с исправленным мною rtsp_streamer’ом и залил её на одну из проблемных камер, с которых шло много разрывов. В результате тестирование показало, что поток не ломается, однако начались артефакты видео, такие же, как при потере пакетов на UDP. Так как я ничего не встраивал такого, стало любопытно, что же это было — пришлось еще раз заглянуть в код. Для начала, заглядываем в strings, у нас же куча отладочных строк. «checkBufferTimeout for %d seconds. », «buffered data more than %d ms, drop all the buffered data. ».

Ага! Оказывается, производители сделали защиту от переполнения! И если по какой-то причине пока синхронный send() завис на больше чем надо (по дефолту — 1 сек), он излишки дропает. Это защищает от OOM и от отставания видео, если оно не влезает в тонкий канал. Но код раньше явно не работал из-за использования неблокирующих сокетов и send()’а.

После оборачивания в Blocking. NonBlocking — код начал работать 🙂
Однако есть небольшая проблемка: 1 сек это мало. Если канал начинает сбоить, однако достаточно толстый, то вероятность дропа становится всё сильнее. После любого такого дропа видео восстанавливается только после кейфрейма. Обычно кейфрейм достаточно редко (раз в 5-10 сек)… И получается неприятная ситуация — если был сбой, то 5-10 сек надо ждать до следующего кейфрейма чтоб видео починилось. Если сократить частоту кейфрейма — это автоматически увеличивает объём передаваемых данных, так как кейфреймы довольно толстые, а значит увеличивает частоту помирания канала. Замкнутый круг.

В общем, я дополнительно увеличил таймаут буферизации до 10сек — этого должно быть недостаточно чтобы словить OOM, но достаточно чтобы спокойно переживать ретрансмиты и лаги на не суперстабильных каналах.

Кстати, «хитрый» алгоритм лечения

Я в прошлой статье пообещал рассказать, как же легко починить ситуацию. Решение просто как валенок — так как мы отправляем RTP пакеты, у нас в каждом есть timestamp. Достаточно в sendRTPorRTCPPacketOverTCP проверять ДО отправки срок жизни пакета, и если он меньше настроенного (я всё-таки считаю что 1 сек это мало на TCP, надо именно 6-10 сек) то отправлять, иначе просто молча не отправлять его.

Автоматизируем сборку-разборку

Осталось дело за малым: автоматизировать сборку-разборку прошивки.

В остальном распаковка не имеет никаких интересных моментов.

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

Результат трудов

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

Источник