Ами за спорта ще пробвам малкия, през андроид апа нищо не става.

Закачи се с кабел, ползвай winbox, избери това на картинката, след това щракаш на mac адреса.

Явно имат проблем с дефолтните пароли и аналогичните им надписи на етикетите, залепени на дъното на кутийката. Не съвпадат и туй то, с мак без мак - нъц.
Варианти 2:
1. Натискаш ресет бутона, включваш захранване, диода почва да мига - това е reset, после светва постоянно - тогава пускаш ресета.
Рутера е в CAPS режим. Влизаш с winbox-a, с админ, без парола, както syscop каза по-горе, цъкаш на Neighbors, Refresh и трябва да се появи у-вото по-долу.
Цъкни изрично на мак адреса, щото вероятно ip адреса е 0.0.0.0 и Connect.
Пускаш от winbox-a нов терминал и пишеш вътре:
/user add disabled=no name=1 password=1 group=full
/system reset-configuration keep-users=yes
Т.е. добавяш потребител 1 с парола 1 и нулираш настройките, като запазваш потребителите.
След като ресета мине - влизаш доволно с единиците и си сменяш паролата на админа, и триеш потребител 1.
Ще те пита и за скрипта с default конфигурацията дали да го стартира - най-вероятно да.
После ще оправяме бриджа.

Вариант 2 е с още по-продължително задържане на ресет бутона, до угасване на диода. Тогава рутера се опитва да бутне през мрежата, и от там да си вземе
нов firmware. Netinstall им е програмката, която се стартира на компутер. Много лесно стана първия път, рутера се появява в netinstall-a, флаш и готово, за секунди налят нов акъл и празна админска парола. Е, вчера утрепах два часа, дорде открия, че на порта, на който netinstall слуша са се настанили разни други програмчета и ги отсвирих и пак тръгнаха инсталациите на нови устройства. Тъпото е, че netinstall-a не изрева, че не може да отвори порт...

ПС. Голяма издънка им е тая глупост с еврогейските изисквания за пароли, почти колкото с пробойната им през winbox-a преди няколко лета, ама тази май ще е с доста по-голям отзвук сред клиентите им.

да ви се чуди човек...

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

Да ама аз да си призная не го пробвах това ... едното вече пътува наобратно, и малкото е в колата и май няма да дочака аз да го пробвам. Аз предполагам в голямото има по-читави антени, в малкото много ме съмнава каква натена има и дали ще покрива добре, а мен мие трбяваше основно да покрива добре в къщи ... то малкото беше за друга цел взето .. как да е, май няма да имам време да го тествам.
Преди 10-15 години сигурно щях да си изгубя един час два три та ако трябва и ден и да го подкарам, в момента има по-важни приоритети, решаването на всеки възникнал проблем вече далеч не ме влече както едно време, само тия които са смислени ... точно сега си губя времето с едни други измамници дето взеха парите и акзаха ще видим, и не ми е за парите, ама ако няма да свършат работа трябва да хдоя до Чикаго, много исках да си го спестя ...

Някой да е чувал за ZIP/GZIP библиотечка, с по-стрийм "ориентиран" алгоритъм?

Класиката в жанра - uzlib изисква данните, които ще се компресират да са налични в паметта. Аз нямам толкоз акъл... Предполагам по-големите библиотеки са базирани на файлове, но сигурно са и доста по-сложни. Мен ми трябва нещо сравнително простичко ако има такова, че ме мързи да пиша

Виж тук: stb.h
Цъкай: file reading -> Compression.

Това е "single header library" и не зависи от други. Препоръчвам за бързо напредване, без много четене .

Допълнително: тук

Това е интересно, компресията е доста по-добре направена... но е на база стандартния алгоритъм на другарите Лемпел и Зив (LZO). Проблемът както казах е, че стандартната имплементация изисква памет, с каквато аз не разполагам за съжаление.

Ще го опиша тук, щото така по-лесно си събирам мислите... Но пък и някой по-умен от мен може да му хрумне идея.

Значи въпросният алгоритъм е така да се каже най-елементарната компресия, която се поддържа в ZIP и GZIP файловите формати. Аз трябва да генерирам файлове които трябва да могат да се отварят от стандартни програми на компютър, така че няма как да си измисля нов формат или компресия.

Въпросната "компресия" се състои в намиране на повторения. Заради кодирането се търси повторение на поне 3 байта. Това е. От тук нататък има различни импровизации как точно да става търсенето.

Най-баналният вариант би бил - вземаш поредните 3 байта и почваш да ги търсиш от началото на файла до текущата позиция. Ако не ги откриеш значи те са уникални, съответно ги кодираш без компресия в изхода. Ако ги срещнеш, проверяваш дали повторението не е повече от 3 байта и колкото е там го кодираш като повторение...
Очевидния проблем на тоя вариант е, че има много търсене. На всеки 3 байта сканираш всичко от началото. Ако файлът е мегабайти ще падне голям размисъл... Не се прави така, просто го описвам за да се разбере идеята на компресията.

Вторият вариант е да се ползва голяма таблица. Тогава въпросните 3 байта се ползват като индекс в таблицата. Значи вземаш поредните 3 байта, отиваш на съответната позиция в таблицата и виждаш дали има предишно срещане или няма. Няма никакво търсене - просто индексиране. В това се състои идеята на LZO и затова принципно е много бърз алгоритъм.

Сега реално никой не прави чак толкова голяма таблица. Почти всички използват Хеш функция с която от 24-бита (3 байта) генерират от 9-15 бита в зависимост колко памет имаш и колко компресия искаш. При uzlib по подразбиране се ползват 12 бита. Демек таблицата е размер 4к елемента. В линка по-горе тия от stub.h като гледам поддържат до 4 таблици с 4 различни хеш функции. Идеята им предполагам, е че при всеки хеш естествено имаш повече от една стойност, които да дават един и същ резултат. Това значи, че за някои 3-байтови стойности няма да се открие евентуално повторение и ще се загуби компресия. Явно са преценили, че е по-добре да се направят 4 различни таблици вместо да се вдига с 2 бита размера на индекса(хеша). Както и да е, това не е толкова важно за мен в случая.

Проблемът не е свързан с хеширането, а в това какво се пише в таблицата. Всички пишат указатели. Демек всичко, което ще компресираш трябва да ти е в паметта или поне последните 64К от данните. Съответно когато обхождаш вземаш 3 байта, смачкваш ги до някакъв индекс и на съответната позицията се слага указател... По-точно подменяш старата стойност с новата. Ако е имало стар указател, значи тия 3 байта евентуално са се срещали преди. Казвам евентуално, щото заради хеширането може и да не са точно тия 3 байта. Както и да, въпросът е че се работи с указатели, което е бързо и лесно - веднага сравняваш паметта и всичко е точно.

Моят проблем е, че нямам свободни 64К, а файловете ще са мегабайти, евентуално на SD карта. Не мога да работя с указатели, щото нямам памет. Мога вместо указател да пазя позиция във файла. Тогава ми трябва памет само за таблицата. Но така бързото индексиране се заменя с файлови операции. Накрая нещо такова ще сътворя и естествено всичко ще стане адски бавно. Въпросът е дали не може да се измисли нещо по средата.
Демек да вкарам някакво кеширане, така че поне някаква част от разхождането по файла да си спестя. Въпросът е какво да е това кеширане, че да е ефективно. Класическото не съм убеден, че ще е много полезно (аз имам някакво, ама пак изисква файлови операции, т.е. пести се достъп до диска, ама се минава през стека на файловата система и драйвери и т.н.).

Админите,
Може би ще е добре да отделите постовете за "ZIP/GZIP библиотечка" в отделна тема в някой раздел за софтуер.

Миро, изискването ти за съвместимост със стандартни PC ZIP/RAR програми ти налага големи ограничения. Не можеш да променяш нито хеш функциите, нито размера на таблиците по твой вкус.

Ако не трябва да си толкова "съвместим" - все ще може да се измисли нещо за твоите ограничени ресурси като RAM.

Мога, няма проблем. Значи във файла данните се пишат на блокове. Блокът може да е без компресия и да съдържа самите данни. Или с "компресия" която в случая с LZO е едно побитово кодиране на офсет и дължина. В тоя блок няма данни, те са просто повторение на нещо, което го има вече във файла.
Как аз съм открил повторенията никой не го интересува. С хеш без хеш, с таблици или с търсене това си е мой проблем.
Аз мога изобщо да не търся повторения. Просто от всеки 3 байта правя блок без компресия. Блокът се описва с 3 бита хедър. Демек ще имам овърхед от 1 бит на всеки байт средно. Това ще си е съвсем валиден zip или gz файл. Само дето ще е по-голям от оригинала.
Не това е целта ми, клиентът иска компресия щото си мисли, че ще постигна супер-дупер компресия. Аз пък още не съм се научил да ловя маймуни с трици, но клиентът може и да ме научи щото е от оня континент...

Колко памет имаш на разположение?

Физически с имам толкова (stm32)... практически, обаче почти нямам свободна, защото в случая става дума за генериране и пращане на много данни във фонов режим. При това се ползва TLS за комуникацията и т.н.

В тоя смисъл обмислях и друга луда идея, обаче мнооо работа ще ми се отвори. Трябва да си преработя RTOS-a да swap-ва нишки и други неща дето ползват памет временно и да ги връща после обратно. Но много дебело става.
Засега ще направя компресията през файл. Не мога да преценя точно колко, но няма начин да не стане ужасно бавно. Последно в TLS-а, когато се вдига връзка с шифър, който ползва RSA за размяна на ключове по дефи-хелмъна, има едно степенуване на прости числа. Функцията е елементарна - десетина реда код. Обаче отнемаше към 20-25 секунди и някои сървъри им се изчерпваше търпението. Видях, че в последната версия на библиотечката от която взаимствам са я разписали на асемблер. Аз погледнах какво е генерирал компилатора при мен, погледнах и асемблерския код. Нямаше принципна разлика. Да, на асемблера ползваха специалните АРМ инструкции за умножение и събиране едновременно. Викам си това ще ускори най-много два пъти, но колкото-толкова. Като пуснах и замерих ускорението се оказа към 7-8 ПЪТИ.
Та искам да кажа, че много важно оня участък от кода дето е най-вътре в един цикъл какво прави. Само от компилация разликите може да са драстични, а в случая с тая компресия аз ще заменя едно индексиране в масив (нещо от порядъка на 2-3 цпу-клока) с викане на две файлове операции (минимум 1000+ пъти по-бавно). Ще видим де, ама това са ми очакванията.

Една още по-щура идея: Тези файлове предполагам са ти отчет на транзакциите за деня. Т.е. създаваш ги като след всяка транзакция добавяш по нещо в края на файла.
Та ако вместо да компресираш файла точно преди изпращането му го правиш още по време на създаването му - дори да го създаваш във флаша - забавянето няма да ти е никакъв проблем. Т.е. няма да го усетиш.
Вероятно това ще ти спести и RAM памет, защото ще можеш да си изчиташ и преравяш байтовете на файла от флаша колкото пъти ти трябва - без да те притеснява колко бавно ще става това. В случая за никъде не бързаш.
В крайна сметка във флаша ще имаш некомпресиран файл (какъвто имаш и в момента) + компресиран файл, който ще създаваш и компресираш по време на "допълването" на данни в некомпресирания файл.

Ако устройството ти е батерийно - идеята няма да се отрази много добре на живота на батерията, но пълно щастие няма. Всичко е въпрос на компромис който трябва да се направи и ти ще трябва да решиш колко голям може да е.