Грижа се за мама и за малкото братче, нищо, че малкото братче взима 3000 евро заплата, като програмист, а пък аз взимам вече 650 евро, като пенсионер по психическа болест. Колкото хора, толкова и съдби, ама не бива да се тормозим, а просто да гледаме на нещата по-светло и по-ведро, и нека със Живот и Любов в нас да живеем Животите си. 🙂✌️☀️🌙

Готово, взех пенсията и всичи задачи за днес са свършени. Има проблем с ОББ мобилното приложение, и не мога да вляза и сега нямам опция за оторизации на транзакциите, ама добре че ePay помни оторизацията и транзакциите са без оторизация, и сега парите са в хъба, и в понеделник ми казаха от офиса на ОББ да намина пак, за да видят резултата на комуникацията с отдела си. Абе програмистите са счупили нещо, но може би не за всички клиенти от някаква си технологична специфика, и ще се види в Понеделник дали ще се оправи достъпа до мобилното приложение, ама си оставих някой лев в кеш за всеки случай, иначе няма грижи.

Реставрирах този BMR(Basal Metabolic Rate) калкулатор писан на Python - http://bmr.melanoria.com. Беше на Python 2, а аз го направих на Python 3, и е готов сайта. Имаше перипети, но се справих тази нощ, за да го реставрирам. Този сайт е калкулатор с който да си измериш телесните калории, които имаш, и които трябва да изразходиш, за да ти е нормален организма. калкулатор на телесната маса. Просто го пазя, като спомен от един приятел, който е Python програмист.

Ето го доклада към програмистите на Android и към XDA обществения технологичен форум, който доклад Copilot AI ми направи, за да отворя Issue:

Доклад за несъвършенство в ARP кеша при Android устройства.

Заглавие:
ARP кешът в Android не се обновява адекватно при роуминг между Wi-Fi точки с еднакъв SSID

Категория:
Connectivity > Wi-Fi
Описание:
При многобройни тестове с Android устройства (в частност Galaxy A14 5G), установих следното поведение:
Android асоциира ARP кеша по MAC адрес на Wi-Fi точката за достъп (L2), а не по IP адрес на Gateway (L3). Това води до забавяне или липса на комуникация между Android телефона и други устройства в LAN, когато се премине от една точка за достъп (AP) към друга с еднакъв SSID.
Например:
- Телефонът е свързан към AP с SSID „HomeWiFi“
- Компютърът е свързан към Gateway рутера със същия SSID
- При преминаване от Gateway към AP, Android не обновява ARP таблицата своевременно
- Това води до забавяне от няколко минути преди да се възстанови комуникацията
Това поведение е интуитивно от гледна точка на L2 асоциация, но неефективно в реална мрежова среда. Вътрешната LAN комуникация се базира на L2 switching, без вътрешен routing, което допълнително изостря проблема.
Предложение за подобрение:
- ARP кешът да се управлява по IP Gateway, а не по MAC на AP
- При всяка Wi-Fi асоциация да се изпраща Gratuitous ARP към LAN
- Да се обединят ARP записи между AP-та с еднакъв SSID
Това би подобрило значително комуникацията в домашни и корпоративни мрежи с множество точки за достъп.

Има някои софтуерни и системни грешки на приложенията и операционната система в релация със системните програмни среди и модули на операционната система, които не могат да се оправят на ръка, а се оправят само с ресет или преинсталация на операционната система или с възстановяване на бекъп на операционната система, както и с локализиране и ревизия на хардуерен проблем. Така е, какво да правиш в Живота. Стои си повредения файл на модула или на програмната среда и няма оправия, защото грешката на крайното приложение е грешка в програмния бинарен код на цялостния системен модул, и ако не си програмистта на този модул или среда няма да разбереш нищо.

Светия Дух ми вика купи си го софтуера, защото е яко(готино), и тъкмо ще почерпя програмистите с много кафета. 🙂✌

Вижте Човеците какви са. Един е Художник, а друг е Строител, а друг е Инженер, а друг е Певец, а друг е Писател, а друг е Програмист, а друг е Компютърен Специалист, и т.н. Докато Зверчетата са всичките Разрушителчета на Света. Така е набързо погледнато. Аз да си кажа, за да се знае.

Задълбочен анализ, от който оставам без извод, защото явно има специфика във възприемането на трафика от защитния софтуер. По принцип, когато пусна зловреден трафик директно към компютъра, го засича и го блокирва и всичко е наред, но когато пусна зловреден трафик и през двата NAT рутера го пропуска и не го блокирва. Има специфични данни, когато е директно и когато е индиректно, които данни филтрира, когато е директно и нефилтрира, когато е индиректно. Но при мониторинг от моя страна съм забелязал, че засича и блокирва зловредния трафик през NAT рутера от други IP адреси, и само веднъж за кратко засече и блокира моя тестови зловреден трафик през NAT рутерите. Сигурно Есет вижда разлика в данните, когато е директно и когато не е директно в моя случай на зловреден трафик, но при другите IP адреси от външния свят ги засича, но сигурно зависи какви данни са зловредния трафик. Сложно и омотано са го направили, но пробвах и през мобилния интернет, и пак го пропуска, значи не е нещо от вътрешната мрежа, ами си е до специфичност и сложност на защитния софтуер, като дали е умишлено или е до неоптимизираност или до пропуск в разработването. Няма значение, защото сега няма пробив във вътрешната ми мрежа, колкото и да правя тестове, докато при старата версия нямаше такава специфика и объркване, защото всичко блокирваше, без значение директен или недиректен е трафика. Уведомих програмистите по имейл за този мой анализ. Тази вечер с това се занимавах и не съм спал, ама нищо. Ще спя после. Хайде оставям ви, а пък аз ще пия едно кафе и ще пуша цигари, и после, като мине време ще опитам да поспя малко.