Aquest blog ha estat uns dies amb el certificat caducat.

La caducitat ha coincidit amb uns dies de molta feina, i m’ha faltat empenta per instal·lar el nou a temps.

Hi ha algun sistema per actualitzar-lo automàticament, ho hauré de mirar.

Malgrat que tinc el ZOC configurat per fer servir colors del text diferents en el servidor de casa i el d’aquest web, aquest matí he fet això en el del web (segons el registre):

USER=root ; COMMAND=/sbin/halt -p

O sigui que l’he aturat pensant-me que aturava el de casa.

D’ençà del canvi a ARM64 de tant en tant (entre un i tres cops al dia) les connexions ethernet es desactiven i s’activen al cap de 2 o 3 segons. No hi ha cap altre error al log.

No puc assegurar que s’hagi començat a produir just amb el canvi, o que hi tingui relació directa. En el procés no vaig introduir fins al fons el connector cilíndric del corrent, i me’n vaig adonar al cap d’uns dies. Pot ser que hagi quedat malmès.

Primer decideixo canviar la font d’alimentació. N’encarrego una a principis de setmana, i encara no m’ha arribat. Poc se’n parla, dels entrebancs que generen algunes empreses de transport i, sobretot, la mala gestió que fan de les incidències: ni contesten telèfon ni correus.

Mentre espero trobo 2 entrades estranyes al «bridge» de la xarxa local. Les trec. No descarto que fossin la font del problema. També eren al backup de la configuració ARM que vaig fer-me al seu dia, i per algun motiu en ARM64 provoquen aquestes desconnexions. No sé si són imaginacions meves, un cop corregit això diria que la navegació és més àgil.

Al cap d’un parell de dies el problema persisteix, tot i que (potser) amb menys freqüència. Pensant que hi pot haver alguna altra part de configuració estranya que no es veu he optat per esborrar tota la configració i refer-la des de zero.

Tot just mentre escrivia això:

Així que esperaré uns dies a veuri si trobo algun patró de comportament. Després miraré de fer algun retoc de configuració a veure si trobo el desllorigador.

És simptomàtic que ether1, que no està connectat al xip de “switch”, no es desconnecta.

21/09: dissabte vaig desactivar les cues i reactivar la regla de fasttrack del firewall i no hi ha hagut desconnexions les darreres 48 hores.

Aquest matí he desactivat la regla del fasttrack i he tingut desconnexions.

Més tard m’ha arribat la font d’alimentació de recanvi, ja funciona amb les cues activades i sense fasttrack, i el problema ha reaparegut dues vegades en 5 hores. Per tant no és cosa de la font d’alimentació (ja ho sospitava després de les darreres proves). Torno a activar el fasttrack.

Al registre de canvis de la propera versió del RouteOS no veig res relacionat amb aquest problema, si bé hi ha entrades genèriques del tipus «millores d’estabilitat». Si quan surti la propera versió el problema persisteix obriré un cas a suport. Fins aleshores deixo el fasttrack actiu.

24/09: Fa 36 hores que no tinc desconnexions, amb les cues activades i el fasttrack desactivat. Sense explicació.

25/09: A quarts de cinc del matí hi ha hagut una altra desconnexió.

27/09: Desconnecto el mateix cable que comentava al final d’aquesta entrada. L’única referència que he trobat a internet de problemes similars explica que li passava per un cable defectuós. Però això no era el problema.

1/10: 2 dies i mig estable sense cues i amb fasttrack. Ha sortit la versió 7.24.5 i l’he instaŀlada, i he activat les cues i el fasttrack. A la llista de canvis hi ha una millora d’estabilitat (sense més detalls), a veure si és la que calia. També havia retocat una mica (a la baixa) els amples de banda pels dispositius de les cues.

3/10: El canvi de versió no m’ho va millorar. Però un canvi a les regles del firewall sembla que sí. Amb aquestes regles

 9     ;;; Evitar fasttrack per ip amb cues
       chain=forward action=accept connection-state=established,related dst-address-list=AmpleBandaLimitat log=no log-prefix=""
 
10     ;;; Evitar fasttrack per ip amb cues
       chain=forward action=accept connection-state=established,related src-address-list=AmpleBandaLimitat log=no log-prefix=""
 
11     ;;; defconf: fasttrack
       chain=forward action=fasttrack-connection connection-state=established,related
 
12     ;;; defconf: accept established,related, untracked
       chain=forward action=accept connection-state=established,related,untracked

Les regles 9 i 10 són noves, les comento més endavant.

Perquè les cues (limitacions d’ample de banda) funcionin desactivava la regla 11 (fasttrack). Això fa que tot el tràfic passi pel processador del router en comptes del circuit de switch, més ràpid.

En alguna configuració de cues he llegit en comptes de desactivar del tot el fasttrack era preferible posar un parell de regles accept abans del fasttrack. Són les 9 i 10 noves. De fet això mateix (accept general) és el que fa la regla 12 si no hi ha les 9, 10 i 11.

I així porto 48 hores, amb estabilitat total.

L’única diferència que veig entre la 9/10 i la 12 és el untracked.

6/10: I com qui no vol la cosa, diumenge a la tarda 5 errors en 1 h. Desactivo les cues i les regles 9 i 10 del firewall. Ho deixaré en observació un parell de setmanes, sense tocar res. Al cap i a la fi és com ho deu tenir el 99,9% de les llars.

M’ha calgut una bona estona per passar el router Mikrotik L009 a ARM64. Més per desconeixement de com funciona netinstall (tot i que ja l’havia fet servir) que perquè fos difícil.

En tot cas, ja està fet. Ara ja tinc DoH amb https/2 (vegeu Servei DNS4EU).

Més endavant em miraré les «apps».