SparkLan WX-6800-II

Nota introduttiva: istruzioni su come flashare via jtag in rete ce ne sono tante, e pure scritte molto chiaramente -- quindi io mi focalizzerò solo (o quasi) sui particolari cui prestare attenzione per lo SparkLan WX-6800-II.

In uno dei miei due mi sono sbagliato a flashare un firmware e PUFF! Irraggiungibile. Manco adatto come fermaporta. Buttarlo senza togliersi lo sfizio di vedere se è possibile recuperarlo? Non è da me... Smile

Visto che già avevo avuto a che fare con firmware alternativi (in particolare con OpenWrt e dd-wrt), ho cercato in giro se per caso fosse possibile installarne uno.
Fortunatamente (e grazie al traduttore di Google) ho scoperto che Sparklan utilizza praticamente lo stesso HW del Linksys WRT54G (versione tradotta). Purtroppo, a differenza dei modelli "normali" (e più vecchi) del WRT54G, il WX-6800 ha solo 2M di Flash, e questo preclude l'uso di OpenWrt. La scelta ricade quindi su dd-wrt, edizione "vintage micro".
Primo problema: convincere il WX ad accettare il firmware.
Il loader ha boot_wait=Off (che impedisce, di fatto, l'uso diretto del tftp) e tramite la sua interfaccia web non si riesce a convincerlo ad accettare firmware non originali.
Il metodo più rapido ed affidabile è quello di usare il cavo JTAG da parallela (sconsiglio di cortocircuitare a massa il pin 19 della flash durante il boot!), con HairyDairyMaid_WRT54G_Debrick_Utility (la v48 supporta bene l'autodetect della flash da 2M) per cancellare il kernel:

./wrt54g -erase:kernel

(anche se l'operazione è abbastanza rapida, è sufficiente cancellare un paio di blocchi).

Dopo la cancellazione, il boot si interromperà a causa del checksum errato sul firmware. A questo punto è possibile inviare, con tftp, il nuovo firmware.

tftp 192.168.1.250
bin
trace
put nomeDelFirmware.trx

Peccato che non si possa inviare direttamente il .bin/.trx! Il loader non lo accetta (inviandolo, non viene flashato, o per lo meno non si riavvia). Una rapida occhiata al firmware originale, scaricato dal sito, mostra che prima del marker "HDR0" devono esserci altri byte. Per comodità, ho disponibile il .trx (che sarebbe un .bin, a questo punto) pronto per l'invio. I byte extra dell'header del .bin sono anche riportati in CFE:

chk_fw_hdr=Enabled
fw_hdr=00 90 4B 21 BC C7 00 04

Purtroppo è proprio necessario usare JTAG: anche aggiungendo l'header, l'interfaccia web rifiuta l'aggiornamento poiché crede che si voglia effettuare un downgrade! (ma che cavolo glie ne frega a loro se voglio effettuare un downgrade? Bah!)

Attenzione: l'IP di default per il WX è 192.168.1.250, da usare anche per il tftp. Ma una volta flashato dd-wrt diventa 192.168.1.1 ! Quindi attenzione: se smette di rispondere al 250, magari è già passato sull'1 !

Aggiornamento: ho trovato un altro sito che ne parla (anche se si riferisce ad un altro AP, il Dick Smith XH8287 che altro non è che un WX-6800II rimarchiato).
L'autore lì ha usato l'accesso via seriale (impostata a 115200 8N1), e la cosa è in effetti piuttosto furba, dato che i fori nel connettore per la seriale non sono pieni di stagno (e quindi si può saldare il connettore molto più velocemente). Inoltre dice che è sufficiente dare i comandi:

# nvram set chk_fw_hdr=Disabled
# nvram commit

via seriale per abilitare il flashing di qualsiasi versione di firmware tramite l'interfaccia web (molto più veloce che non farlo via JTAG).

Nel caso andasse male, i comandi per flashare da CFE sono:

CFE> nvram set chk_fw_hdr=Disabled
CFE> nvram commit
CFE> flash -noheader 1.2.3.4:/foo.trx flash1.trx

(su '1.2.3.4' deve ovviamente essere attivo un server TFTP).

0
Il tuo voto: Nessuna

Commenti

Opzioni visualizzazione commenti

Seleziona il tuo modo preferito per visualizzare i commenti e premi "Salva impostazioni" per attivare i cambiamenti.

Comunque rimane poco stabile

immagine di NdK

Dopo un po' di test, sono convinto che sia proprio una questione HW: anche con dd-wrt la connessione rimane decisamente instabile, almeno nelle modalità client bridge e repeater bridge (dall'altro lato c'è una Fonera 2100 con FW originale, che sostituirò per altri motivi -- mancanza di impostazioni per il routing -- ma che è decisamente stabile).
Probabilmente è dovuto al fatto che l'HW è solo "praticamente" uguale a quello del WRT54, ma ne differisce in qualche modo subdolo.

Molto spesso perde pacchetti o introduce ritardi inaccettabili, anche se poi, magari, basta tenere attivo un ping in background verso l'AP remoto perché tutto funzioni per un po'. Comunque mi sta tenendo inaccessibili per il 60-70% del tempo i siti sul server di casa, e già questo sarebbe sufficiente per condannarlo al macero. Ma prima lo sottoporrò a qualche piccola tortura... Per esempio voglio vedere se overclockandolo regge (e quanto)...

Comunque oggi rimetterò al suo posto la Fonera che avevo tolto per aggiornarla (e se lo SparkLan avesse funzionato a dovere, avrei potuto utilizzarla diversamente...), e speriamo in bene!

Il tuo voto: Nessuna

Opzioni visualizzazione commenti

Seleziona il tuo modo preferito per visualizzare i commenti e premi "Salva impostazioni" per attivare i cambiamenti.
Realizzato con Drupal, un sistema open source per la gestione dei contenuti