[LuKePicci]

Per avere un comportamento del genere credo che avesse la gui anche in bank2 con il controllo della bank attivato... bella testa.

Sì è probabile che la prima installazione della custom GUI fosse stata fatta su bank_2, ma il problema è: perchè dopo la migrazione sul primo banco la custom gui lascia il secondo banco in uno stato inservibile? La migrazione automatica sul primo banco non è che avvenga solo durante l'installazione, si riverifica continuamente ogni volta che si prova a riavviare il banco 2 e questo è un problema enorme. Sarebbe meglio non fare alcuna migrazione e lasciare la gui in funzione sul banco su cui viene installata e stop, in modo da lasciare pulito l'altro (meglio se l'altro è il primo per il solito motivo). Finchè non sistemano questa cosa sarà pieno di casi di brick simili a quello di @Bales,

[FrancYescO]

e' impossibile che venga lasciata una bank2 inservibile post migrazione in bank1: se ricordo bene viene fatta una copia 1:1 dell'overlay e mtd quindi dopo una migrazione automatica da bank2 ci si ritrova sia le bank che gli overlay identici (la cosa piu' rischiosa e' proprio la duplicazione dell'overlay) l'unico modo per averla inservibile sarebbe appunto essere partiti con una migrazione in uno stato in cui era gia' rotta

Per quanto siamo d'accordo che ormai ci sono modi migliori di gestire la cosa, personalmente dato l'alto rischio a sbagliare qualcosa che potrebbe fare grossi danni toccandola al momento non voglio mettere mano su quella porzione di codice.

[LuKePicci]

Eh ma è proprio la duplicazione 1:1 dell'overlay che la rende inservibile, perchè (da quanto forse ho capito) avviandola lei parte di nuovo con la migrazione. Cioè, bank_2 è in un "buono" stato, non corrotto, ma ogni volta che la si avvia rootdevice (che per altro sopravvive alla rimozione normale della mod) parte a fare una copia di mtd (che in sostanza va a fare downgrade del firmware in bank_1) e overlay. Ora io non ho capito cosa vada storto in questo processo ma è esattamente come dici tu, andare a cambiare il comportamento di quella funzione ora è estremamente rischioso, ed è assolutamente impensabile pensare di migrare le installazioni esistenti su un pan diverso, però non dovrebbe essere difficile rimuovere e disabilitare del tutto il codice che fa la migrazione dal codice della mod. Se mi dici esattamente dov'è il codice in questione ti mando una PR per sistemare una volta per tutte questa immensa rogna. Intanto una cosa che andrebbe sicuramente fatta è impedire il tweak dei driver qualora sia rilevato un bank planning non safe. Fornire la possibilità di sostituire driver dsl a caso (la maggior parte diventa incompatibile con l'avanzare delle versioni) mentre la mod forza un bank planning non safe è una bastardata bella e buona.

[FrancYescO]

Per i driver xdsl la pezza l'abbiamo già messa: il driver viene caricato con un symlink da /tmp e spostato in modo permanente dove serve solo se il restart di xdsl ha successo

Anche quello che resiste ai reset abbiamo ridotto al minimo (se ricordo bene nell'ordine, check spazio, abilitazione seriale, root)

La funzione è questa, ma per quanto mi sono impegnato in primis a pulire il codice la pura è sempre che ci sia qualcosa altrove che possa causare ad esempio reboot infiniti quando parte in bank2
https://github.com/Ansuel/tch-nginx-gui/blob/master/decompressed/base/etc/init.d/rootdevice#L255

[HAlex™]

Mi scuso in anticipo se è già stato chiesto/risposto ma non sono riuscito a trovare niente al riguardo:
Il mio Fastgate è al firmware 18.3.n.0439_FW_258_DGA4131 e ho seguito tutti i passaggi.
Per sicurezza ho usato l'immagine per l'USB fornita nel post originale ma nel momento in cui accedo a \\192.168.1.254\....nomechiavetta\rootlink Windows mi da errore dicendo che non ho i permessi sufficienti, le altre cartelle si aprono (e sì ho usato il link per attivare la condivisione).

Per caso non si può più fare con l'ultima versione?

[larsen64it]

Sono/siamo rimasti indietro con la versione (17.2.0412_FW_248_DGA4131) se non hanno chiuso tutte porte via tftp o direttamente da fail boot o altro  forse qualche cosa si può ancora fare. Oltre non mi esprimo.

P.S. Ma ti è arrivato così o si è aggiornato.

[LuKePicci]

GRANDE GIUBILO, ora mi lavoro l'upgrade

@HAlex™ non ho ancora nemmeno scaricato quell'aggiornamento ma nei nuovi 18.x non c'è più samba quindi si sicuro quello che c'è descritto nella guida non si può più fare. Però coem sta scritto anche nella parte finale della guida in prima pagina previo downgrade e root indiretto ce la si dovrebbe comunque fare. Inoltre c'è sempre tch-exploit che qui non abbiamo mai provato ma che probabilmente funziona (sarebbe meglio testarlo prima sulle versioni "vecchie").

Da una prima occhiata:
- linux 4.1/glibc
- nqe al posto di samba
- niente driver spu :-(
- driver wifi molto più nuovo
- tch-exploit almeno in teoria, configurato con opportuni ip diversi da quelli di default,  dovrebbe funzionare, bisogna fare il reset ed attendere un bel po' prima che il wansensing fallisca 5 volte il setup della porta sfp prima di usare la porta wan rj45
- l'update dovrebbe andare liscio tramite questa guida: https://hack-technicolor.readthedocs.io/en/stable/Upgrade/ ma non bisogna assolutamente saltare la parte in cui si resetta e riapplica il root

[FrancYescO]

Mirrori RBI? Sia mai che fa resuscitare i morti...

[HAlex™]

Grazie ragazzi per le risposte, credevo che il forum inviasse le notifiche tramite email ma non mi è arrivato nulla.

[FrancYescO]

É zoppo ma vivo.

- Metto il 18.3 con TFTP, non cambiava niente solito bootloop causato dal chip 5ghz (che tralaltro non causa nemmeno il bootfail)
- Prendo il pistolone di aria calda e tento di resuscitarlo sparandogli 500° qua e la, niente di fatto, ne ho approfittato per fare 2 foto con gli shield rimossi, tralaltro si notano bene la palline di stagno che strasbordano dal chip 5ghz (quello con il recinto piu' grande)

- Non poteva avermi fatto perdere solo tempo, tento il tutto per tutto.

- i primi spiragli di luce, sembra partire risponde in layer3 ma non accede in ssh (permission denied, immagino c'e il RootLogin a 0 su dropbear), ne parte l'interfaccia sembra freezato forse non gli piace il contenuto dell'overlay
- tento un bootfail, l'overlay del bank2 era pulito e con il firmware vecchio, parte lo script di rooting sembra fare il suo lavoro ma arriva un bel kernel panic, ne deduco che senza chip 5ghz il firmware 17 esplode (ma questo mi pare lo aveva gia fatto notare Luke)..
- torno al 18 in bank1 dopo che si "freeza" faccio un bel reset da tastino
- si stacca il cavetto seriale che era volante, ma parte finalmente parte tutto e anche gia bello che rootato immagino lo script di rooting che e' sempre li resiliente ha fatto il suo lavoro
- l'interfaccia fastweb sputa random errori generici, il wifi (nessuno dei due) non si attiva


Log console delle varie operazioni: https://termbin.com/ustov

[larsen64it]

Quindi con la 18 e dopo la "messa in piega",  funziona tutto tranne il wifi?   

[FrancYescO]

Esatto, a dirla tutta credo ci fosse qualche modo per farlo andare anche con la 17 disabilitando (velocemente appena boota) qualcosa su watchdog (mi sembra e' lui che causa il panic) ma non ho approfondito, cosi come non ho approfondito la possibilita' di attivare almeno il 2.4GHz sul 18, anche perche' wlan0 lo visualizzo tranquillamente con un ifconfig

[larsen64it]

wlctl -i wl0 up

Mentre questo era era il log prima del reset?

Codice: [Seleziona]

hhecking country codes in /etc/wlan/brcm_country_map_5G (wl1)
Checking0/0/804 --> NOK
Checking Q1/45 --> NOK
############################################################################
### ERROR. WLAN COUNTRY MAP FILES NOT CORRECT
### --> DISABLING WLAN
############################################################################

[FrancYescO]

quel blocco che hai postato e' proprio quello che permette l'avvio.. prima (con il chip sulla board) non ci arrivava lì

il reset da tastino corrisponde a quando nel log vedi "[  285.276276] reboot: Restarting"

Questo e' quello che si vedeva in loop nella seriale di un firmware 17:

Codice: [Seleziona]

[   17.027000] dhdpcie_bus_write_vars: Download, Upload and compare of NVRAM succeeded.
[   22.034000] dhdpcie_readshared: address (0xf7c70838) of pciedev_shared invalid
[   22.040000] Waited 5000023 usec, dongle is not ready
[   22.045000] dhd_bus_init :Shared area read failed
[   22.050000] dhd_bus_start, dhd_bus_init failed -1
[   22.055000] dhdpcie_init: dhd_bud_start() failed
[   22.361000] dhd_detach(): thread:dhd_watchdog_thread:346 terminated OK
[   22.367000] dhd_dpc_thread: Unexpected up_cnt 0
[   22.367000] dhd_detach(): thread:dhd0_dpc:347 terminated OK
[   22.378000] dhd_flow_rings not initialized!
[   22.392000] dhdpcie_pci_probe: PCIe Enumeration failed
[   22.396000] dhdpcie_init: can't find adapter info for this chip
[   22.519000] DHD: dongle ram size is set to 1835008(orig 1835008) at 0x200000
[   22.526000] dhd:0: fw path:/etc/wlan_dhd nv path:(null)
[   22.531000] Creating CPU ring for queue number 7 with 128 packets descriptor=0xbe9f460c
[   22.531000]  Done initializing Ring 7 Base=0xffdf3000 End=0xffdf3800 calculated entries= 128 RDD Base=0x00c25000 descriptor=0xbe9f460c
[   22.552000] RDPA returned tx wakeup reg = <0x80299004>, val = <0x10000000>
[   22.559000] RDPA returned rx wakeup reg = <0x8029a004>, val = <0x26000000>
[   22.566000] dhd_runner_psp_get radio0rxoffl not implemented
[   22.572000] dhd_runner_attach: Rx Offload - Enabled, Ring Size = 1024
[   22.581000] dhd_attach: wl0: pre-allocated buffer mode is disabled (allocskbsz=0)
[   22.588000] dhd_attach(): thread:dhd_watchdog_thread:349 started
[   22.595000] dhd_attach(): thread:dhd0_dpc:34a started
[   22.600000] dhd_deferred_work_init: work queue initialized
[   22.605000] Creating CPU ring for queue number 2 with 1024 packets descriptor=0xbec418f0
[   22.605000]  Creating CPU ring for queue number 3 with 1024 packets descriptor=0xbec4190c
[   22.615000]   wfd_bind: Dev wl%d wfd_idx 1 wl_radio_idx 0 Type fkb configured WFD thread wfd1-thrd minQId/maxQId (10/11), status (0) qmask 0xc
[   22.628000] Instantiating WFD 1 thread
[   22.640000] dhd:0: fw path:/etc/wlan_dhd nv path:(null)
[   22.646000] dhd_bus_download_firmware: firmware path=/etc/wlan_dhd, nvram path=
[   22.653000] update_firmware_path: DHD HDR feature is supported.
[   22.660000] dhdpcie_ramsize_adj: Enter
[   22.663000] dhdpcie_ramsize_adj: Adjust dongle RAMSIZE to 0x240000
[   22.670000] dhdpcie_download_code_file: download firmware /etc/wlan_dhd/4366c0/rtecdc.bin
[   23.013000] wl:srom/otp not programmed, using main memory mapped srom info(wombo board)
[   23.020000] wl: ID=pci/1/1/0/
[   23.023000] wl: ID=pci/1/1/0/
[   23.026000] wl: loading /etc/wlan/bcm43664_map.bin
[   23.037000] wl: reading /etc/wlan/bcmcmn_nvramvars.bin, file size=20
[   23.043000] Replace or append with internal Mac Address
[   23.050000] dhdpcie_bus_write_vars: Download, Upload and compare of NVRAM succeeded.
il comando sembra andare ma non vedo alcun ssid... immagino devo sistemare la config in modo da dividere 2.4 e 5ghz cosi che avii solo quella che esiste..

[lorenzocanalelc]

Ma l'RBI del Firmware? E poi un paio di domande, posso aggiornare con la GUI di Ansuel? Con questo Kernel è possibile usare le stesse repo del DGA4132 con FW 2.1.0?