Nel nostro caso avevamo un US Robotics 5451 in giro, ma la connessione wireless era discretamente instabile e l'ultimo firmware ufficiale è del 2006.
Tra la schiera di firmware opensource:
- DD-WRT : un firmware monolitico;
- OpenWrt : un firmware aggiornabile a pacchetti, tipo distro linux;
- Tomato.
Purtroppo l'unico che supporta il nostro modello è DD-WRT, come potete vedere nella lista dei device supportati.
Questa è la guida all'installazione, che è abbastanza completa.
Riassumerò qui brevemente i passi eseguiti, per avere una lista di passi minimali, tuttavia consiglio vivamente di darsi una breve lettura al materiale illustrato nella pagina. Inoltre la guida sulla wiki di DD-WRT fa sempre riferimento all'ambiente Windows, mentre qui mostrerò i comandi linux.
ISTRUZIONI
- NB: si presume che si parta dal firmware ufficiale di UsRobotics.
- Effettuare un Reset 30-30-30 dell'access point.
- Scaricare il firmware DD-WRT (dd-wrt.v24_micro_generic.bin).
Qui trovate una lista aggiornata di firmware per i prodotti dotati di chipset BroadCom - Scaricare l'ultimo firmware UFFICIALE UsRobotics disponibile per il nostro modello.
Nel nostro caso USR5451-v3.93.35.0.6.usr - Preparare il file/firmware in modo che sia adatto ad essere caricato tramite la GUI. Infatti il bin che si scarica dal sito DD-WRT non ha all'inizio alcuni byte che gli consentono di essere riconosciuto come firmware ufficiale.
# Questo comando estrae i primi 28bytes dal firmware ufficiale
head --bytes 28 USR5451-v3.93.35.0.6.usr > USR5451-v3.93.35.0.6_hdr.usr
# Questo comando aggiunge l'header appena estratto al firmware DD-WRT, per
# creare un file che venga riconosciuto dalla GUI UsRobotics come se fosse
# un firmware ufficiale.
cat USR5451-v3.93.35.0.6_hdr.usr dd-wrt.v24_micro_generic.bin \
> dd-wrt.v24_micro_generic.usr - Connettere il proprio PC all'access point via ethernet. Per farlo:
- Impostare la propria connessione di rete in modalità Shared
È necessario perché l'access point non ha un ip e deve essere il nostro pc ad assegnarglielo - Individuare l'IP dell'access point.
Ecco un metodo: - con il comando ifconfig individuate il vostro ip e la classe di rete (ES: 10.2.0.2/24)
- tramite il comando arp-scan scansionate tale sottorete alla ricerca dell'ip assegnato all'access point.
ES: sudo arp-scan 10.2.0.1-10.2.0.254 - Connettersi alla gui dell'access point (http://ip_dell_access_point)
- Nella scheda Device, selezionare il file (dd-wrt.v24_micro_generic.usr) creato al punto (5) ed infine premere "UPGRADE"
- Aspettare almeno 5 minuti prima di premere il pulsante "CONTINUE"
- impostare la propria scheda di rete in modo che sia compatibile con la classe 192.168.1.0/24
ES: 192.168.1.10 - Collegarsi alla WebGUI di DD-WRT: http://192.168.1.1
- Se il collegamento ha successo, effettuare un altro reset 30/30/30.
PROBLEMI
Nel nostro caso il flash sembrava essere andato bene: il dispositivo si era riavviato, i led lampeggiavano ed aveva un suo IP.
Purtroppo però non appariva nessuna rete WiFi, non rispondeva al ping, ma soprattutto non appariva nessuna WebGUI.
La nostra soluzione è stata effettuare vari reset semplici (30 secondi di pressione del pulsante reset), alcuni spegnimenti/accensioni ed alcune brevi pressioni del pulsante reset (4-5 pressioni nel giro di 4-5 secondi).
Dopo il tempo necessario ai led per stabilizzarsi, laWebGUI è finalmente comparsa, insieme alla rete wifi (che di default ha SSID dd-wrt, non protetta).
It seems a good idea to flash the latest factory firmware before attempting DD-WRT.
Put a static IP on the LAN settings page of the factory firmware. Leaving the LAN IP at DHCP seems like recipe for disaster if DD-WRT does not "take". This is probably more of an issue for the USR5455, 5451, 5441 & 5432 "single port" models, as the 5-port USR5465 & 5461 routers default to a static IP.
In several steps in the above procedure, the 192.168.2.1 in the ping and tftp commands is the default for the USR5465/5461 models. Other default IPs such as 192.168.2.64 may exist for other models.
If DD-WRT is not functioning and you can't ping your router/access point at its factory default, try DD-WRT's default IP 192.168.1.1 or the last static IP you set on the device (setting static IP on your pc appropriately, of course). After a power cycle of the router or "long reset", if it is getting at least partway through boot, you may pick up a few TTL=100 pings. That means you have some boot-wait time to tftp your "working" firmware.
The behaviour of LEDs in response to the "long reset" in step A.5 and C.3 might differ from model to model. The point is to hold the reset button long enough that the overall pattern of LEDs has stopped changing for several seconds. On the USR5465, that means the four LAN LEDs will go on, then off, then a single LAN LED will be flickering, which is the one you're pinging. If I remember correctly, the USR5461 goes through two such iterations with all four LAN LEDS lit, finishing on the second pass with all four still lit.
According to what I've seen from going through the USRobotics GPL sourcecode for these devices, the factory firmware is quite tolerant of corrupt NVRAM variables, so revert to factory firmware has good chance for success.
You shouldn't have to revert to factory firmware anyway on the USR5461, 5451, 5441, or 5432. DD-WRT 12548 through 12874, Eko or BS, micro and micro variants should run fine on these models.
The reset button on the USR54xx models might not work as far as truly clearing NVRAM. My reading of the factory sourcecode suggests that a 30/30/30 or other such "long reset" may simply set a flag in NVRAM to tell the CPU to rebuild NVRAM upon continuing the boot of the factory firmware. DD-WRT might not read the reset button at all. After a successful flash with DD-WRT, the very next thing is to telnet in to erase nvram to be sure.
[NDA: Per esempio ora un cretino si mette a giocare con le impostazioni del dnsmasq prima di fare tutto questo e non sa che il tasto di reset non gli sarà di nessun aiuto!]
After clearing NVRAM, DD-WRT defaults to access point/gateway mode. On the USR5432, this makes it a WLAN to WAN gateway with no wired LAN, i.e. the port labeled "LAN" is actually a WAN port. This makes some sense, as the port occupies the same position as the WAN port on the USR5461, which has the same motherboard. After I flashed DD-WRT and cleared NVRAM, I could not access the USR5432 through wired ethernet, only wireless, till I checked the "Assign WAN Port to Switch" box on the main setup page, and it didn't matter if the WAN connection type was "disabled" by setting DD-WRT to client bridge mode. The situation is likely the same on the USR5451 and 5441 (same hardware as USR5432), and the USR5455 as well, but I haven't tested those particular models. (I did run across a guy on this forum who semi-bricked his USR5455, probably a side-effect of this.)
*BRICK ALERT* On a "single port" USR5451/5441/5432, if you leave all forms of wired administrative access disabled by 1) leaving "Assign WAN Port to Switch" unchecked on the main setup page AND 2) leaving "Remote Access" by http or telnet disabled on the administrative page, and then you do something to the WLAN settings that prevents a wireless connection, you might create for yourself a semi-brick. Maybe time for a serial cable or JTAG. I'm not going to try this to prove it, but I strongly suspect that's the outcome based on the behaviour of the various settings and the non-standard reset button.
I tipici sintomi del chiudersi fuori sopra descritto:
Dato che come evidenziato sopra il tasto di reset non fa sostanzialmente nessuna reimpostazione dei default, l'unica è accedere alla console/jtag con apposita circuiteria. Già, ma come?
Costruendosi il circuito per la il circuito per la connessione seriale tra varie alternative. Noi sceglieremo la stessa costruita da un utente nel forum.
Purtroppo però non appariva nessuna rete WiFi, non rispondeva al ping, ma soprattutto non appariva nessuna WebGUI.
La nostra soluzione è stata effettuare vari reset semplici (30 secondi di pressione del pulsante reset), alcuni spegnimenti/accensioni ed alcune brevi pressioni del pulsante reset (4-5 pressioni nel giro di 4-5 secondi).
Dopo il tempo necessario ai led per stabilizzarsi, laWebGUI è finalmente comparsa, insieme alla rete wifi (che di default ha SSID dd-wrt, non protetta).
NOTE IMPORTANTI
Further thoughts:It seems a good idea to flash the latest factory firmware before attempting DD-WRT.
Put a static IP on the LAN settings page of the factory firmware. Leaving the LAN IP at DHCP seems like recipe for disaster if DD-WRT does not "take". This is probably more of an issue for the USR5455, 5451, 5441 & 5432 "single port" models, as the 5-port USR5465 & 5461 routers default to a static IP.
In several steps in the above procedure, the 192.168.2.1 in the ping and tftp commands is the default for the USR5465/5461 models. Other default IPs such as 192.168.2.64 may exist for other models.
If DD-WRT is not functioning and you can't ping your router/access point at its factory default, try DD-WRT's default IP 192.168.1.1 or the last static IP you set on the device (setting static IP on your pc appropriately, of course). After a power cycle of the router or "long reset", if it is getting at least partway through boot, you may pick up a few TTL=100 pings. That means you have some boot-wait time to tftp your "working" firmware.
The behaviour of LEDs in response to the "long reset" in step A.5 and C.3 might differ from model to model. The point is to hold the reset button long enough that the overall pattern of LEDs has stopped changing for several seconds. On the USR5465, that means the four LAN LEDs will go on, then off, then a single LAN LED will be flickering, which is the one you're pinging. If I remember correctly, the USR5461 goes through two such iterations with all four LAN LEDS lit, finishing on the second pass with all four still lit.
According to what I've seen from going through the USRobotics GPL sourcecode for these devices, the factory firmware is quite tolerant of corrupt NVRAM variables, so revert to factory firmware has good chance for success.
You shouldn't have to revert to factory firmware anyway on the USR5461, 5451, 5441, or 5432. DD-WRT 12548 through 12874, Eko or BS, micro and micro variants should run fine on these models.
The reset button on the USR54xx models might not work as far as truly clearing NVRAM. My reading of the factory sourcecode suggests that a 30/30/30 or other such "long reset" may simply set a flag in NVRAM to tell the CPU to rebuild NVRAM upon continuing the boot of the factory firmware. DD-WRT might not read the reset button at all. After a successful flash with DD-WRT, the very next thing is to telnet in to erase nvram to be sure.
[NDA: Per esempio ora un cretino si mette a giocare con le impostazioni del dnsmasq prima di fare tutto questo e non sa che il tasto di reset non gli sarà di nessun aiuto!]
After clearing NVRAM, DD-WRT defaults to access point/gateway mode. On the USR5432, this makes it a WLAN to WAN gateway with no wired LAN, i.e. the port labeled "LAN" is actually a WAN port. This makes some sense, as the port occupies the same position as the WAN port on the USR5461, which has the same motherboard. After I flashed DD-WRT and cleared NVRAM, I could not access the USR5432 through wired ethernet, only wireless, till I checked the "Assign WAN Port to Switch" box on the main setup page, and it didn't matter if the WAN connection type was "disabled" by setting DD-WRT to client bridge mode. The situation is likely the same on the USR5451 and 5441 (same hardware as USR5432), and the USR5455 as well, but I haven't tested those particular models. (I did run across a guy on this forum who semi-bricked his USR5455, probably a side-effect of this.)
*BRICK ALERT* On a "single port" USR5451/5441/5432, if you leave all forms of wired administrative access disabled by 1) leaving "Assign WAN Port to Switch" unchecked on the main setup page AND 2) leaving "Remote Access" by http or telnet disabled on the administrative page, and then you do something to the WLAN settings that prevents a wireless connection, you might create for yourself a semi-brick. Maybe time for a serial cable or JTAG. I'm not going to try this to prove it, but I strongly suspect that's the outcome based on the behaviour of the various settings and the non-standard reset button.
I tipici sintomi del chiudersi fuori sopra descritto:
- la wifi viene correttamente inizializzata e il router risponde al ping su quella interfaccia
- la gui non risponde sul gateway acquisito da wifi
- la eth acquisisce l'ip 192.168.1.1 ma non c'è verso di pingarlo nè in fase di boot nè dopo.
DEBRICKING (the hard way)
Bene, hai briccato il tuo router o ti sei "chiuso fuori" (vedi parti in rosso delle NOTE IMPORTANTI). E adesso?Dato che come evidenziato sopra il tasto di reset non fa sostanzialmente nessuna reimpostazione dei default, l'unica è accedere alla console/jtag con apposita circuiteria. Già, ma come?
Costruendosi il circuito per la il circuito per la connessione seriale tra varie alternative. Noi sceglieremo la stessa costruita da un utente nel forum.
Circuiteria console seriale
Nel forum hanno usato il più semplice circuito contenuto nel pdf con le possibili alternative (vedi ultimo punto qui sopra).
EDIT: I figured out the pinout and here is the correction. Any other pinout information is incorrect.
From Left -> Right, starting with pin in white square: Tx - Rx - 3.3v - Gnd
From Left -> Right, starting with pin in white square: Tx - Rx - 3.3v - Gnd
| usr5451.jpg | ||
| Description: | ||
| Filesize: | 78.23 KB | |
| Viewed: | 3759 Time(s) | |
 | ||
| jatg-serial-circuit.jpg | ||
| Description: | ||
| Filesize: | 19.64 KB | |
| Viewed: | 3759 Time(s) | |
 | ||
Nessun commento:
Posta un commento