[FrancYescO]

su modem starlink non si può impostare niente e anche su switch non si imposta niente

ma non c'e nulla di impostare li... io intendevo al posto di usare la porta SFP del timhub per quello che vuoi fare usa la WAN

[Darkeyes7@86]

Ciao, sto lavorando su un DGA4132 con firmware 19.4 Damson e GUI Ansuel 9.7.7-b55fe2d8.
Ho cambiato correttamente la LAN a 192.168.3.1/24, DHCP 192.168.3.100–239 e SFP a 192.168.2.2. SSH/root e GUI funzionano.

Il problema rimasto è questo: la GUI si carica, ma periodicamente alcune chiamate AJAX con auto_update=true vanno in 404 Not Found, in particolare:
connected_device.lua, port_status.lua, cpuload.lua, mmpbx_status.lua e a volte internet.lua.

Nei log nginx/sessionmgr compaiono:
Session limit reached
Service not available

Ho già verificato:

i file AJAX esistono;
tutti fanno LOADFILE OK;
non contengono ngx.exit(404);
nginx e i processi Lua risultano attivi;
restart di nginx ripristina temporaneamente il funzionamento;
web.default.maxsessions='60'
web.default.maxsessions_per_ip='50'
il percorso della richiesta passa da SessionMgr:checkrequest(), getSessionForRequest(), verifySession(), newSession().

La mia impressione è che le richieste AJAX non stiano riutilizzando correttamente il sessionID, vengano create troppe sessioni e si arrivi al limite.

Qualcuno ha già visto questo comportamento su Ansuel/Damson 19.4?
È un problema noto del sessionmgr, della GUI 9.7.7, del cookie sessionID o dell’auto_update?
Prima di modificare limiti/sessionmgr vorrei capire qual è la correzione corretta

[FrancYescO]

19.4 ma esattamente quale? È probabile sia qualche problema proprio intrinseco del firmware, e forse non dipendente dalla GUI alzare le sessioni sarà probabilmente solo un palliativo e ti porterà a saturare la ram/bloccare tutto il modem

Il problema dovrebbe essere sui mapping lua di transformers che rispondono a quelle request e a volte restano in loading infinito senza rispondere, forse è tra i fix che ho portato/sto per portare sulle versioni 9.8.x della gui cercando di portare le migliorie di firmare technicolor più recenti per quanto ormai agthp/agtef siano fermi

[Darkeyes7@86]

Grazie 👍
La versione esatta è:

19.4.1051-3401197-20241118125242-cf49b74e8c88c918fead0a0f9ad052f3283f4ee7
DGA4132 / VBNT-S, release Damson 19.4.

Nel frattempo abbiamo continuato a controllare. I file AJAX che vanno in errore (cpuload.lua, connected_device.lua, port_status.lua, mmpbx_status.lua) esistono e compilano correttamente, quindi non sembrano file mancanti/corrotti.

Abbiamo anche verificato che il sessionmgr.lua attivo è diverso da quello originale presente in /rom, e nei log il Session limit reached compare realmente. Però sono d’accordo con te che alzare il limite delle sessioni non risolve la causa e rischia solo di peggiorare la situazione.

A questo punto la tua indicazione sui mapping Lua/transformer mi interessa parecchio, soprattutto perché dici che alcuni fix sono finiti nelle GUI 9.8.x usando componenti Technicolor più recenti.

Nel frattempo mi è stato anche fatto notare che, per il nostro progetto, una volta ottenuto root stabile non siamo obbligati a mantenere firmware TIM + GUI Ansuel: potremmo eventualmente passare più avanti a OpenWrt/LuCI.

Prima però vorrei capire da te una cosa: con questa precisa build 19.4, secondo te ha senso provare prima una 9.8.x che contiene quei fix transformer, oppure il problema è abbastanza intrinseco al firmware da non valere la pena perderci altro tempo?

Se consigli la 9.8.x, quale versione useresti sul DGA4132 con questa 19.4?

[FrancYescO]

Openwrt non c’è ne un target per il soc e il bootloader fa la verifica della firma, almeno fino ad oggi è sempre stato un vicolo ceco. Luci già ce come app installa bile sulla gui.

Puoi provare l’ultima della 9.8 se il bug lo hai facilmente replicabile…

[Exelcius]

Ciao a tutti.
Vi scrivo perché ieri ho voluto provare ad installare la versione 9.8.48 della GUI su firmware 2.3.5. Ero curioso di provare AdHomeGuard ma non ci sono arrivato...

All'avvio tutto ok. Ho "voluto" cambiare delle impostazione sulla rete wireless. All'atto di salvare i dati si è aperta la solita schermata modale al centro dello schermo che non si è più chiusa. Ho per cui aggiornato la pagina: sono rientrato nella schermata di configurazione ed ho notato che era sparita dalla scheda wireless la voce relativa alla rete a 5 Ghz.
Ho per cui deciso di resettarlo ma anziché farlo dal tasto posto sul retro ho selezionato l'ultimo pulsante nel tab della GUI in cui c'era scritto che avrebbe cancellato la configurazione mantenendo la GUI mod.

Da quel momento, il modem fa 3 cicli con luce fioca su infoled ed internet, poi luce arancione su infoled.
Poi, si accende luce arancione di infoled, inizia a lampeggiare ethernet (vedo che avvia la connessione di rete perché blinka il cavo di rete collegato).
Poi luce viola, smette di blinkare la scheda di rete e poi luce fissa blu.

Ho provato a fare la procedura di failboot avviando il modem con il tasto di reset premuto: infoled lampeggia assieme ad ethernet ma dal tab Log viewer di tftp (versione 4.74 portable eseguita su Windows11), compare solo questo

Codice: [Seleziona]

Rcvd BootP Msg for IP 0.0.0.0, Mac A4:91:B1:30:66:72 [23/10 18:18:35.359]
DHCP: proposed address 192.168.1.1 [23/10 18:18:35.360]
non vedo alcun altro segnale che mi faccia presupporre che sia partito il trasferimento del firmware verso il router.

Ho provato anche a proseguire la procedura per farlo avviare dal secondo bank ma dalla guida dice di:

2.   Accendiamo il router e dopo circa 8-10 secondi premiamo velocemente off-on e continuiamo a farlo ogni 4 secondi finché non va in failboot (vedremo il router accendere e spegnere i 3 led di stato)

Ora prima di peggiorare ulteriormente la situazione, volevo chiedervi ragguagli anche su quest'ultima fase: io non vedo MAI accendere e spegnere i 3 led di stato anche dopo minuti che faccio la procedura... sbaglio la tempistica o la modalità? Una delle vote che ho fatto tale procedura, ha iniziato a lampeggiare infoled ed ho visto che lato tftp (che avevo lasciato aperto) veniva assegnato un indirizzo IP al router. Ho per cui dedotto di aver avviato la procedura per il caricamento del firmware via tftp senza tener premuto il tasto di reset.

Pensate si possa ancora recuperare? Qualcuno ha idea di cosa posso aver fatto?

[FrancYescO]

che firmware stai mandando via tftp? prova a mandare lo stesso 2.3.5, e prova la versione 32bit di tftpd.. anche se comunque la modalita di blocco mi fa pensare al chip wifi andato... era un modem che stavi usando?

[Exelcius]

Grazie del feedback.

Ho provato ad inviare i firmware versioni 1.0.3 e 2.2.1.
Ora ho provato anche ad inviare il 2.3.5 ma stesso risultato: mi risponde con il medesimo messaggio (assegna l'ip al modem) e non fa null'altro.
Penso che fallisca perché poco dopo, si disattiva l'ethernet e poi si riavvia.

Non riesco nemmeno ad eseguire il fail boot (magari sto sbagliando tempistiche/metodologia): può essere che la prassi che si usava con il firmware 1.1.1 sia ora differente?
Quella procedura l'avevo usata nel 2018/2019 quando avevo fatto il root. Da allora mai un problema...

E' un modem che stavo usando.
Ne ho altri 4 identici che usavo in bridge e li uso come AP: negli altri vedo di non fare le stesse "cavolate". Speravo infatti che si potesse avviare il Mesh...
Non riesco a capire cosa possa essere successo.

Ti viene in mente qualche altro tentativo che possa provare?

[FrancYescO]

il punto è che su alcuni modem potrebbe essere abilitato il flag antidowngrade, ne vidi qualche esemplare tra i firmware 2.2 e 2.3 quindi se è quello non ti accetterebbe via tftp nessun firmware sotto il 2.3.5... pero' non credo sia quello andando a memoria il trasferimento del firmware comunque avveniva tutto.

anche lo stato dei led "che cambiano" non fa pensare a un device irrecuperabile, pero difficile direi cosa stia facendo pero' se non ti funziona tftp32 la causa è da ricercare sul pc e il suo firewall.. quando provi a mandargl iil firmware come unica interfaccia connessa hai quella verso il modem? (niente wifi ne altro..)

hai gia provato a premere il tasto reset quando vedi la luce blu o poco prima che arrivi in quello stato?

[FrancYescO]

Mi son trovato anche io a flashare un 788vn... e forse c'e qualcosa di rotto nelle nuove versioni di tftp32, riceve le richieste di DHCP ma poi non parte il download dell'rbi, dopo vari smarmellamenti e prove a vuoto (disattivare firewall, mettere un nome molto semplice al file tipo F.rbi, disattivare tutte le altre interfacce di rete, attivare/disattivare il bind del server dhcp e tftp sull'ip 192.168.1.x..) con sia tftp32 che tftp64 4.76

mi ha funzionato al primo tentativo con tftp32 4.70 quindi ti suggerirei di usare quella
https://github.com/PJO2/tftpd64/releases/download/v4.70/Tftpd32_Portable_v4.70.zip

[Exelcius]

Yes.
Ti confermo che, installata la versione 4.70 di tftp, al primo tentativo sono riuscito a re-installare il firmware 2.3.5. Ho ovviamente perso il root.
Ora sto facendo tutta la procedura per ri-acquisire il root e riportarlo alla situazione iniziale.

Avevo provato ad usare anche la versione 4.64 di tftp (usata nel lontano 2018/2019 per fare il primo root) ma anche quella versione non inviava il firmware al modem.
Ci sarà qualcosa che non digerisce bene del protocollo...
Ad ogni modo, un sentito ed infinito GRAZIE  .