[Marvel]

Per la 19 in teoria si potrebbe continuare ad usare uclient-fetch, basta aggiornare  libustream-openssl da te compilato con libopenssl1.1.

Perfetto mi piace, ma mi avevi detto questo:

Quello che comanda la baracca è  libustream-openssl che richiede libubox20191228 e qui credo che si rompa il tutto.
Provo a eseguire un altra catenaria previo reset completo.

Quindi avevo capito che c'è il problema di libubox20191228.
Mi confermi che invece si può? Hai fatto altri test?
Io non ho homeware 19 quindi mi baso sui tuoi feedback.

[larsen64it]

Si deve forzare con

Codice: [Seleziona]

opkg install  libustream-openssXXX --nodeps per impedire l'aggiornamento di libubox20191228
 

Io non ho homeware 19 quindi mi baso sui tuoi feedback.

Siamo messi bene
Io non i poteri della Super Mucca! 🐮

[Marvel]

Si deve forzare con

Codice: [Seleziona]

opkg install  libustream-openssXXX --nodeps per impedire l'aggiornamento di libubox20191228
 

Perfetto, se non si rompe nulla ce lo teniamo così.

Siamo messi bene
Io non i poteri della Super Mucca! 🐮

In compenso però hai tanta pazienza e dato che ti sei messo a fare prove ho colto subito la palla al balzo!

Comunque ora che mi è chiaro come preparare il repo per homeware 19, appeno ho tempo inizio a sistemare tutto e credo che con i nuovi pacchetti non si dovrà nemmeno forzare l'installazione.

[greyhand]

opkg list-installed | grep ssl

Codice: [Seleziona]

root@modemtim:~# opkg list-installed | grep ssl
libmosquitto-ssl - 1.5-3
libopenssl - 1.0.2t-1
mosquitto-ssl - 1.5-3
openssl-util - 1.0.2t-1
root@modemmes:~#

Si, credo anche io che il problema in questo caso siano i DNS, controllerei di più un:

Codice: [Seleziona]

nslookup raw.githubusercontent.com
Comunque nel fine settimana dovrei riuscire a compilare anche le librerie openssl aggiornate per homeware 19.

Ho eseguito anche questo comando sempre da SSH per vedere quale DNS viene usato per la risoluzione  e qui la sorpresa ( e credo anche sia il problema ) cioè:

Codice: [Seleziona]

root@modemtim:~# nslookup raw.githubusercontent.com
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

nslookup: can't resolve 'raw.githubusercontent.com': Name or service not known

Lo stesso comando inviato sia dal secondo router in cascata e da CMD di windows risolve l'IP quindi funziona. Ergo il problema sembra confinato localmente nel Modem TIM. Il fatto che dia  127.0.0.1 mi fa pensare a un qualcosa come un filtro IP solo che io non ho mai impostato nulla in tal senso. Sul router  esiste un filehost i similare che potrebbe appunto portare  a questo problema? Grazie!

[Marvel]

Il problema sono palesemente i DNS, probabilmente in dhcp hai 127.0.0.1 come list server e in network hai dei list dns validi per l'interfaccia wan, oppure la tua macchina windows ed il router in cascata (se in lan-to-wan) hanno dei resolver dns locali configurati. Situazione strana se non hai messo tu mano a queste configurazioni.

[greyhand]

La situazione DNS sul Modem è la seguente :



Quindi anche senza DNS personalizzato non funziona.  Questa dovrebbe essere la configurazione di default del modem o perlomeno io non l'ho toccata, Presume quindi che in caso di mancata presenza dei DNS nelle altre interfacce vengano utilizzati quelli sull'interfaccia wan che è quella che si relaziona alle rete esterna.  Ma evidentemente non è cosi. Compilando i DNS in tutte le interfacce ( per prova) utilizzando DNS personalizzati riesco a scaricare i pacchetti . Quindi il problema credo sia stato trovato e forse risolto. L'unico problema che mi rimane è che per la GUI Telstra  era stata tentata una istallazione che per i motivi di cui sopra non si installava realmente anche se dal menù delle estensioni risultata istallata comunque.  Ora anche se risulta installata non è possibile rimuoverla con il tasto "rimuovi". Per il resto stiamo tornando a bolla.

[larsen64it]

uci set modgui.app.telstra_webui="0"
uci commit

[greyhand]

@larsen64it  grazie ha funzionato.

Faccio anche un aggiornamento sul problema dei DNS. Ieri pensavo che il problema fosse dovuto alla mancata impostazione dei DNS sulle altre interfacce diverse dalla WAN. Tanto vero che impostando manualmente gli stessi DNS ufficiali cioè 85.38.28.2 e 85.38.28.3 su ogni singola interfaccia il problema sembrava risolto in quanto le estensioni come le GUI alternative venivano scaricate e istallate correttamente. Stamattina rientro nel menù del modem e verifico che tutto fosse ancora funzionante ma non era così. Il problema si era ripresentato anche con l'impostazione manuale dei DNS di cui sopra nonostante da SSH con un lookup rispondono correttamente. Tolgo tutti i DNS impostati manualmente lasciando bianchi i campi lasciando solo quelli relativi all'interfaccia WAN che non è possibile eliminare o cancellare.  Nonostante questo fosse la configurazione che mi dava problema dall'inizio oggi funziona cioè con solo compilati i DNS nell0interfaccia WAN riesco comunque a scaricare i pacchetti.  Il problema è legato ai DNS anche se funzionanti (vedi SSH). Non so il problema è risolvibile qui ma lo faccio presente in modo che sia valutato.

[Diabolik]

Nel frattempo... dopo le peripezie per aggiornare alla 2.3.2 da un pò di giorni sul mio DGA4132 è ricomparso:

Un riavvio è in attesa! Motivazione: TIM ACS asked for firmware update. Go to Modgui Settings to allow this.

Ora è possibile capire se questa cosa è relativa al passaggio ad un 2.3.3 (leggo che qualcuno ha ottenuto il beta...) oppure se è relativo al downgrade al 2.2.1 che altri invece hanno segnalato di aver ricevuto ?

[Teorico]

Buon pomeriggio,
dopo un po' di tempo trascorso con modem ben stabile (firmware 2.2.0 e GUI 9.6.65 e OBP), essendo nata l'esigenza di segmentare la LAN e sfruttare tecnologia VLAN secondo OpenWRT poichè ho un secondo router da affiancare come Access Point, vorrei intervenire sul TIM HUB nell'interfaccia WiFi e nello switch di rete con Luci, ma ho scoperto che ci sono parecchie limitazioni.
Andando a ritroso nel thread ho scoperto che Network/Wireless è buggata (impossibile aggiungere servizi nella gui installata, come verificato direttamente), mentre su Network/Switch devo partire da zero poichè non ho nulla d'impostato. Ma qui mi tocca studiare un po', perchè devo fare almeno 3 VLAN.
Venendo al dunque: se si fa l'upgrade all'ultima versione firmware 2.3.2, che si accompagnerebbe alla GUI DEV 9.6.90, si risolvono i problemi di Openwrt sottostanti? Mi pareva di aver letto che si stava facendo l'upgrade della versione Chaos Calmer cui si appoggia la gui di Ansuel. A che punto siamo? Rilascio in future versioni stable o dev?
In effetti se vedo quello che ho sull'altro router (un Netgear con OpenWRT 21.02 rilasciata qualche settimana fa) tutto fila liscio senza problemi.
Un grazie anticipato per ogni feedback.
Bye

[LuKePicci]

Non puoi usare LuCI per configurare questi aspetti sul technicolor perchè i driver usati dall'OpenWrt liscio che hai sul Netgear e quelli usati qui sol technicolor sono diversi e LuCi non sa come gestire le loro config. Puoi facilmente ottenere quello che vuoi fare editando a mano le config studiando il loro formato attuale. Tieni presente che i Vecchi OpenWrt non usavano configurazioni compatibili con DSA, questi technicolor sono basati su quelle vecchie versioni ma usano configurazioni compatibili con DSA, mentre la nuova OpenWrt 21 cambia molto il paradigma di configurazione per rendere tutto nativamente compatibile con DSA. In parole povere, fa come se su questo technicolor non ci fosse OpenWrt, non prendere come riferimento la documentazione di OpenWrt per quel che riguarda la configurazione delle VLAN sullo switch.

Quello che vuoi fare non ha niente a che vedere con la MOD oggetto di questo thread. Anche le nuove versioni di Homeware (basate sui nuovi OpenWrt) usano driver diversi quindi resteranno sempre non compatibili con LuCi

[Teorico]

Infatti sospettavo una situazione del genere. Trattandosi sempre di OpenWRT, sia pur di una versione datata, pensavo che upgrade recenti di gui e librerie sottostanti potessero cambiare qualcosa.
Chiedo scusa per l'off-topic, che non mi sembra così clamoroso. Ero pur sempre partito chiedendo se firmware 2.3.2 e gui 9.6.90 potevano risolvere il mio problema.
Ma sinceramente, vale la pena fare l'ugrade appena citato o tanto vale rimanere fermi?
Thank you again @LuKePicci

[LuKePicci]

Non risolveresti alcun problema rispetto a quello che dici di voler fare. Non aggiornare la mod finchè non esce una nuova stabile, Solo successivamente ti converrà aggiornare il firmware.

[greyhand]

Quindi come la maggior parte dei modem\router non è possibile istallare firmware alternativi come wrt puro?. Che poi il problema solitamente è nella parte modem di quasi tutti i dispositivi. Non che wrt sia esente da problemi però sono gestibili ed è molto più leggero soprattutto con dispositivi con hardware limitato. 

[LuKePicci]

Ci sono due cose che impediscono l'installazione di firmware alternativi (ovvero non compilati da technicolor per la stessa board) su questi dispositivi.

La prima è che su questi SoC è attivo il secure boot, ovvero il bootloader è bloccato come sugli smartphone. Il SoC si rifiuta di caricare un bootloader non firmato da technicolor. Il bootloader si rifiuta di caricare un firmware non firmato da technicolor.

Anche ammettendo che technicolor consenta lo sblocco del bootloader, le piattaforme hardware utilizzate da technicolor non sono ben supportate dall'open source. Su dispositivi simili a questi dove il bootloader era sbloccato, un firmware open tipo openwrt ammazza le potenzialità del dispositivo quasi a renderlo inutilizzabile. per il suo design originale.(pur aprendo possibilità diverse).