Página 2 de 3 PrimeiroPrimeiro 123 ÚltimoÚltimo
+ Responder ao Tópico



  1. #21

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Citação Postado originalmente por rubem Ver Post
    Não funciona TFTP nelas?

    Curioso, nas WOG212 funciona.

    Cada vez mais suspeito que a Intelbras recebe tudo pronto da Ligowave/Deliberant e não modifica conforme os problemas/necessidades locais porque não consegue.
    consegui usar algum outro firmware nela?, pq o original e uma bosta nao tem nada de opçao

  2. #22

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Citação Postado originalmente por lcesargc Ver Post
    consegui usar algum outro firmware nela?, pq o original e uma bosta nao tem nada de opçao
    Eu nunca tentei, mas tem gente que diz que trocou, e inclusive depois veio perguntar como voltar pro firmware original :-)
    Parece que usar um software pra enviar por TFTP, reseta ela e o software envia pro 192.168.1.2 ou *.6, bem simples. Só a volta pro firmware original que não rola.

    Só não lembro que firmware era isso, e... houveram versões diferentes da Wog212, eu usei muito a primeira geração, depois internamente mudou algumas coisas e não abri nenhum pra ver.
    Eu guardei um firmware que recebi, ele tem assinatura da TP-Link nele, seria pra primeira geração de WOG212, não sei se serve em outras versões nem como ele é, salvei mas nunca usei:
    http://s000.tinyupload.com/index.php...26640643635025

    Abre um post, ou procura no forum, deve ter alguma coisa sobre isso, não lembro quem/onde/quando me falou sobre essa troca de firmware. E o TFTP nas Wog212 sei que responde (Pelo menos).

    (Eu na verdade nunca tive problema nem com as Wom5000, não fico trocando firmware só pra "me sentir atualizado" e nunca recebi unidade com problema, o que não consigo resolver com configuração eu deixo pra usar el ptp ou cliente de tráfego baixo)

  3. #23

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Queria saber qual o motivo da Intelbrás não disponibilizar o procedimento de reinstalação do firmware.

  4. #24

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Desculpa a pergunta mas como entra no modo TFTP na Wog 212?

  5. #25

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Era por programa tipo:
    http://www.shadowsoftware.net/shadow...rld/downloads/tftp2.exe

    (O IP com ele ligado com reset apertado acho que era 192.168.1.6 (Ou 192.168.1.2), só aceita TFTP se liga assim, com reset apertado)

    ACHO que era isso.

  6. #26

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Citação Postado originalmente por rubem Ver Post
    Era por programa tipo:
    http://www.shadowsoftware.net/shadow...rld/downloads/tftp2.exe

    (O IP com ele ligado com reset apertado acho que era 192.168.1.6 (Ou 192.168.1.2), só aceita TFTP se liga assim, com reset apertado)

    ACHO que era isso.

    Vlw mestre ...

  7. #27

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Já estou com meu conversor USB e uma WOM5000 em mãos (firmware corrompido), agora como entrar no modo de serviço?? ou não precisa? alguém tem alguma novidade sobre o assunto?

  8. #28

    Padrão

    Clique na imagem para uma versão maior

Nome:	         COM4 - PuTTY - WON5000.jpg
Visualizações:	364
Tamanho: 	144,9 KB
ID:      	62415

    Boa noite

    Alguém teve sucesso para upar o firmware original ou outro no WON5000?

    Segue imagem ta tela de boot de sistema (ligado via serial).

  9. #29

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Essa tela cheia de lixo geralmente é culpa do character set errado.

    O default do Putty talvez seja ISO-8859-1, e geralmente se usa UTF-8 nos firmwares:
    Clique na imagem para uma versão maior

Nome:	         putty.png
Visualizações:	249
Tamanho: 	46,6 KB
ID:      	62416

    Mas... vai que por isso ser brasileiro é o contrário, exige ISO-8859-1 ou Win-1252.

    Enfim, testar outros characters set, geralmente lixo na tela é isso, tradução errada do texto.

  10. #30

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Foi o que me veio a mente... Tentei vários charset e nada...

    Usando o padrão UTF-8 testei com MK, UBNT, roteadores de algumas marcas e todos funcionaram... Único que aparece esse lixo É O LIXO DO WON5000.




    Citação Postado originalmente por rubem Ver Post
    Essa tela cheia de lixo geralmente é culpa do character set errado.

    O default do Putty talvez seja ISO-8859-1, e geralmente se usa UTF-8 nos firmwares:
    Clique na imagem para uma versão maior

Nome:	         putty.png
Visualizações:	249
Tamanho: 	46,6 KB
ID:      	62416

    Mas... vai que por isso ser brasileiro é o contrário, exige ISO-8859-1 ou Win-1252.

    Enfim, testar outros characters set, geralmente lixo na tela é isso, tradução errada do texto.

  11. #31

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Sinceramente creio que a intenção da empresa é fazer os clientes pagarem assistência. Se não fosse esse o motivo o Suporte da Intelbras passaria o procedimento realizado nas assistências. Mk, Ubnt e até outras marcas menos vagabundas (aparentemente) que a intelbras liberam TFTP e seus procedimentos de recuperação. Pq a intelbras não faz a mesma coisa?

    Antes poderiam até falar 'O barato que saia caro'... Agora optar por WON5000 é "O menos caro que realmente não compensa".

    Levando em consideração que outro produto da intelbras que uso é switch e tem outras marcas com o mesmo preço e muito bons vou abandonar toda e qualquer solução intelbras por achar uma empresa muito desrespeitosa com seus clientes.

  12. #32

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Não precisa alterar a codificação, apenas a velocidade: 64000
    Fiz o upload da versão 4, mas deu "bad Magic number"
    Vou fazer novos testes.
    O firmware possui um pequeno cabeçalho que acredito ser o magic number. Se você remover esse cabeçalho e cortar o arquivo no final do enchimento que tem vários FF FF FF FF(em hex), terá um arquivo de 1MB exato.
    Essa primeira parte acredito que seja o kernel e a segunda seja root_fs.
    O bootloader é uboot, mas é capado...
    Enviei por tftp também só o kernel, mas também não bootou...
    Vou tentar pegar uma boa e fazer uns dumps pelo dd. Espero que a Intelbras ajude e libere o firmware para recovery.
    Caso contrário, descobriremos um jeito.
    Boa sorte

  13. #33

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    O jeito que "tem que dar" que todo mundo já sabe, é tirar a Rom e colocar num gravador externo.

    Não tenho nenhuma pra mexer, mas qual é aquele CI de Rom, de 16 pinos, que fica pra cima do chipset? Só achei foto de longe, parece escrito MXIO.

    E de baixo do cabo do conector SMA, não está escrito RX, TX, GND e 3,3V? Se estiver, é por lá que se conecta via serial/TTL pra enviar/copiar o firmware, com um adaptador tipo
    http://produto.mercadolivre.com.br/M...pl2303-ttl-_JM

    Os pontos a verificar, só achei foto ruim no google:
    Clique na imagem para uma versão maior

Nome:	         wom5000.jpg
Visualizações:	449
Tamanho: 	157,8 KB
ID:      	62635


    Eu não acho isso o fim do mundo, pra recuperar roteador doméstico de mesa, de R$ 90, sempre precisamos fazer isso, conectar via serial, ttl ou jtag, pra enviar firmware.
    (Alias, os primeiros DD-WRT nos Linksys não tinha como enviar via web, só via cabo jtag, mas mesmo assim ele cresceu, apareceu o Tomato, Open-WRT e etc, também nessa levada de conectar via cabo jtag. A troca de firmware somente via ethernet acho que tem uns 5 ou 6 anos que virou regra, antes até modem ADSL de R$ 50 precisava disso pra uma mísera troca de VPI/VCI (Aqueles que vem travado pra uma operadora))

  14. #34

    Padrão

    Citação Postado originalmente por rubem Ver Post
    O jeito que "tem que dar" que todo mundo já sabe, é tirar a Rom e colocar num gravador externo.

    Não tenho nenhuma pra mexer, mas qual é aquele CI de Rom, de 16 pinos, que fica pra cima do chipset? Só achei foto de longe, parece escrito MXIO.

    E de baixo do cabo do conector SMA, não está escrito RX, TX, GND e 3,3V? Se estiver, é por lá que se conecta via serial/TTL pra enviar/copiar o firmware, com um adaptador tipo
    http://produto.mercadolivre.com.br/M...pl2303-ttl-_JM

    Os pontos a verificar, só achei foto ruim no google:
    Clique na imagem para uma versão maior

Nome:	         wom5000.jpg
Visualizações:	449
Tamanho: 	157,8 KB
ID:      	62635


    Eu não acho isso o fim do mundo, pra recuperar roteador doméstico de mesa, de R$ 90, sempre precisamos fazer isso, conectar via serial, ttl ou jtag, pra enviar firmware.
    (Alias, os primeiros DD-WRT nos Linksys não tinha como enviar via web, só via cabo jtag, mas mesmo assim ele cresceu, apareceu o Tomato, Open-WRT e etc, também nessa levada de conectar via cabo jtag. A troca de firmware somente via ethernet acho que tem uns 5 ou 6 anos que virou regra, antes até modem ADSL de R$ 50 precisava disso pra uma mísera troca de VPI/VCI (Aqueles que vem travado pra uma operadora))
    Realmente o uso do programador daria certo, mas clonaria os MACs(o que não deve ser tão impossível de alterar).
    A seta de cima são os conectores RS232. Estou usando um PL-2303HX para me comunicar com eles.
    Esse é o meu log após a atualização mal sucedida para o firmware 6 beta 2:

    Código :
    ============================================
    Ralink UBoot Version: 3.6.0.0
    --------------------------------------------
    ASIC 3883_MP (MAC to 100SW Mode)
    DRAM_CONF_FROM: EEPROM
    DRAM_SIZE: 128 Mbits SDR
    DRAM_TOTAL_WIDTH: 16 bits
    TOTAL_MEMORY_SIZE: 16 MBytes
    Flash component: SPI Flash
    Date:Dec 14 2011  Time:02:23:19
    ============================================
    icache: sets:512, ways:4, linesz:32 ,total:65536
    dcache: sets:256, ways:4, linesz:32 ,total:32768
     
     ##### The CPU freq = 500 MHZ ####
     estimate memory size =32 Mbytes
     
    Please choose the operation:
       1: Load system code to SDRAM via TFTP.
       2: Load system code then write to Flash via TFTP.
       3: Boot system code via Flash (default).
       4: Entr boot command line interface.
       7: Load Boot Loader code then write to Flash via Serial.
       9: Load Boot Loader code then write to Flash via TFTP.                     0
     
    3: System Boot system code via Flash.
    ## Booting image at bc050000 ...
    raspi_read: from:50000 len:40
    .   Image Name:   Linux Kernel Image
       Created:      2015-10-02  13:28:25 UTC
       Image Type:   MIPS Linux Kernel Image (lzma compressed)
       Data Size:    3571648 Bytes =  3.4 MB
       Load Address: 80000000
       Entry Point:  80233000
    raspi_read: from:50040 len:367fc0
    .......................................................   Verifying Checksum ... Bad Data CRC

    A seta do meio eu acredito a ser a pinagem JTAG, isso explica a falta de resistores como nas Ubiquiti.
    E sim, a última seta é a memória SPI.
    A minha é uma 25Q03213(32Mb, ou seja, 4MB).
    Farei mais testes hoje a tarde.



    ------


    edit: Tentando bootar OpenWRT 15.10
    Código :
    [    0.000000] SoC Type: Ralink RT3883 ver:1 eco:5
    [    0.000000] bootconsole [early0] enabled
    [    0.000000] CPU0 revision is: 0001974c (MIPS 74Kc)
    [    0.000000] Linux version 3.18.20 (buildbot@builder1) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r46450) ) #1 Fri Sep 4 19:35:23 CEST 2015
    [    0.000000] SoC Type: Ralink RT3883 ver:1 eco:5
    [    0.000000] bootconsole [early0] enabled
    [    0.000000] CPU0 revision is: 0001974c (MIPS 74Kc)
    [    0.000000] Linux version 3.18.20 (buildbot@builder1) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r46450) ) #1 Fri Sep 4 19:35:23 CEST 2015
    [    0.000000] SoC Type: Ralink RT3883 ver:1 eco:5
    [    0.000000] bootconsole [early0] enabled
    [    0.000000] CPU0 revision is: 0001974c (MIPS 74Kc)
    [    0.000000] Linux version 3.18.20 (buildbot@builder1) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r46450) ) #1 Fri Sep 4 19:35:23 CEST 2015

    Isso se repete indefinidamente quando se escolhe a opção 1 no bootloader.
    O arquivo utilizado foi openwrt-15.05-ramips-rt3883-uImage.bin

  15. #35

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Curioso, isso tá igual os Asus, mesmo com um RT3050 diz que o chipset é um RT3883!

    Agora sobre o "Bad data CRC", erro no checksum pelo visto, isso pra mim é culpa de velocidade errada na porta serial. No caso de MK, as vezes dá isso quando usa algo menor que 128Kbps (Enquanto em RB mais velha tem que usar é 9,6K, vai entender). Lembro de ver essa mensagem algumas vezes.

  16. #36

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Citação Postado originalmente por rubem Ver Post
    Curioso, isso tá igual os Asus, mesmo com um RT3050 diz que o chipset é um RT3883!
    Na verdade esse arquivo foi baixado por mim no site do OpenWrt. Eu posso ter escolhido o arquivo errado, por isso não bootou.

    Citação Postado originalmente por rubem Ver Post
    Agora sobre o "Bad data CRC", erro no checksum pelo visto, isso pra mim é culpa de velocidade errada na porta serial. No caso de MK, as vezes dá isso quando usa algo menor que 128Kbps (Enquanto em RB mais velha tem que usar é 9,6K, vai entender). Lembro de ver essa mensagem algumas vezes.
    Não é o caso. A transferência de arquivo é feita pela porta LAN, protocolo TFTP.

    Segue o mapa com a divisão das partições

    Código :
    # cat mtd
    dev:    size   erasesize  name
    mtd0: 00030000 00010000 "Bootloader"
    mtd1: 00010000 00010000 "Config"
    mtd2: 00010000 00010000 "Factory"
    mtd3: 00100000 00010000 "Kernel"
    mtd4: 00270000 00010000 "RootFS"
    mtd5: 00040000 00010000 "UserConf"
    mtd6: 00370000 00010000 "Kernel_RootFS"

    Como se pode ver, a região que começa na mtd0 e vai até a mtd2 é a parte que não devemos tocar.
    Na minha opinião, acho que basta alguns comandos no uboot para formatar o mtd5, que é a partição que armazena a configuração do usuário.
    Consegui fazer o dump de uma boa, mas estou apanhando para transferir para o PC.
    O servidor SSH não funciona muito bem, não consegui conectar nem com o WinSCP nem com FileZilla.
    O firmware é beeeem capado. Estou apanhando aqui para transfeir os dumps.
    mtd6 parece ser uma partição virtual, compreendendo o kernel e o root_fs.
    Suspeito que UserConf seja no final.
    Então a organização ficaria assim.

    192KB Bootloader
    64KB Config(acredito que seja as configurações do bootloader)
    64KB Factory(área de calibrações, endereços MAC e etc)
    1024KB Kernel (onde o uboot inicia o sistema)
    2496KB RootFS(onde ficam os arquivos da flash, exceto o kernel)
    256KB UserConf(onde fica as configurações do usuário)

    O total é de 4096KB, exatamente o tamanho da flash.
    Quero fazer um arquivo de 3776KB(Kernel, RootFS e UserConf) e enviar por TFTP.


    EDIT:
    Deu certo!!!
    Fiz o arquivo juntando mtd6+mtd5 e enviei por TFTP!
    Agora vou tentar atualizar novamente para o 6 beta 2!
    Código :
    #############
             #########################################
    done
    Bytes transferred = 3866624 (3b0000 hex)
    NetBootFileXferSize= 003b0000
    raspi_erase_write: offs:50000, count:3b0000
    raspi_erase: offs:50000 len:3b0000
    ...........................................................
    raspi_write: to:50000 len:3b0000
    ...........................................................
    raspi_read: from:50000 len:10000
    .raspi_read: from:60000 len:10000
    .raspi_read: from:70000 len:10000
    .raspi_read: from:80000 len:10000
    .raspi_read: from:90000 len:10000
    .raspi_read: from:a0000 len:10000
    .raspi_read: from:b0000 len:10000
    .raspi_read: from:c0000 len:10000
    .raspi_read: from:d0000 len:10000
    .raspi_read: from:e0000 len:10000
    .raspi_read: from:f0000 len:10000
    .raspi_read: from:100000 len:10000
    .raspi_read: from:110000 len:10000
    .raspi_read: from:120000 len:10000
    .raspi_read: from:130000 len:10000
    .raspi_read: from:140000 len:10000
    .raspi_read: from:150000 len:10000
    .raspi_read: from:160000 len:10000
    .raspi_read: from:170000 len:10000
    .raspi_read: from:180000 len:10000
    .raspi_read: from:190000 len:10000
    .raspi_read: from:1a0000 len:10000
    .raspi_read: from:1b0000 len:10000
    .raspi_read: from:1c0000 len:10000
    .raspi_read: from:1d0000 len:10000
    .raspi_read: from:1e0000 len:10000
    .raspi_read: from:1f0000 len:10000
    .raspi_read: from:200000 len:10000
    .raspi_read: from:210000 len:10000
    .raspi_read: from:220000 len:10000
    .raspi_read: from:230000 len:10000
    .raspi_read: from:240000 len:10000
    .raspi_read: from:250000 len:10000
    .raspi_read: from:260000 len:10000
    .raspi_read: from:270000 len:10000
    .raspi_read: from:280000 len:10000
    .raspi_read: from:290000 len:10000
    .raspi_read: from:2a0000 len:10000
    .raspi_read: from:2b0000 len:10000
    .raspi_read: from:2c0000 len:10000
    .raspi_read: from:2d0000 len:10000
    .raspi_read: from:2e0000 len:10000
    .raspi_read: from:2f0000 len:10000
    .raspi_read: from:300000 len:10000
    .raspi_read: from:310000 len:10000
    .raspi_read: from:320000 len:10000
    .raspi_read: from:330000 len:10000
    .raspi_read: from:340000 len:10000
    .raspi_read: from:350000 len:10000
    .raspi_read: from:360000 len:10000
    .raspi_read: from:370000 len:10000
    .raspi_read: from:380000 len:10000
    .raspi_read: from:390000 len:10000
    .raspi_read: from:3a0000 len:10000
    .raspi_read: from:3b0000 len:10000
    .raspi_read: from:3c0000 len:10000
    .raspi_read: from:3d0000 len:10000
    .raspi_read: from:3e0000 len:10000
    .raspi_read: from:3f0000 len:10000
    .Done!
    ## Booting image at bc050000 ...
    raspi_read: from:50000 len:40
    .   Image Name:   Linux Kernel Image
       Created:      2014-06-17  15:13:21 UTC
       Image Type:   MIPS Linux Kernel Image (lzma compressed)
       Data Size:    3547072 Bytes =  3.4 MB
       Load Address: 80000000
       Entry Point:  80232000
    raspi_read: from:50040 len:361fc0
    .......................................................   Verifying Checksum ...                                                                                                   OK
       Uncompressing Kernel Image ... OK
    No initrd
    ## Transferring control to Linux (at address 80232000) ...
    ## Giving linux memsize in MB, 32
     
    Starting kernel ...
     
     
    LINUX started...
     
     THIS IS ASIC
    Linux version 2.6.21-firmware (root@guilew) (gcc version 3.4.2) #2 Tue Jun 17 12                                                                                                  :09:11 BRT 2014
     
     The CPU feqenuce set to 500 MHz
    CPU revision is: 0001974c
    Determined physical RAM map:
     memory: 02000000 @ 00000000 (usable)
    Built 1 zonelists.  Total pages: 8128
    Kernel command line: console=ttyS1,57600n8 root=/dev/mtdblock4
    Primary instruction cache 64kB, physically tagged, 4-way, linesize 32 bytes.
    Primary data cache 32kB, 4-way, linesize 32 bytes.
    Synthesized TLB refill handler (20 instructions).
    Synthesized TLB load handler fastpath (32 instructions).
    Synthesized TLB store handler fastpath (32 instructions).
    Synthesized TLB modify handler fastpath (31 instructions).
    cause = 40808000, status = 11000000
    PID hash table entries: 128 (order: 7, 512 bytes)
    calculating r4koff... 001e8480(2000000)
    CPU frequency 500.00 MHz
    Using 250.000 MHz high precision timer.
    Console: colour dummy device 80x25
    Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
    Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
    Memory: 29996k/32768k available (1947k kernel code, 2772k reserved, 297k data, 1                                                                                                  20k init, 0k highmem)
    Mount-cache hash table entries: 512
    NET: Registered protocol family 16
    NET: Registered protocol family 2
    Time: MIPS clocksource has been installed.
    IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
    TCP established hash table entries: 1024 (order: 1, 8192 bytes)
    TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
    TCP: Hash tables configured (established 1024 bind 1024)
    TCP reno registered
    deice id : 20 ba 16 10 0 (ba161000)
    Warning: un-recognized chip ID, please update SPI driver!
    AT25DF321(1f 47000000) (4096 Kbytes)
    mtd .name = raspi, .size = 0x00400000 (4M) .erasesize = 0x00010000 (64K) .numera                                                                                                  seregions = 0
    Creating 7 MTD partitions on "raspi":
    0x00000000-0x00030000 : "Bootloader"
    0x00030000-0x00040000 : "Config"
    0x00040000-0x00050000 : "Factory"
    0x00050000-0x00150000 : "Kernel"
    0x00150000-0x003c0000 : "RootFS"
    0x003c0000-0x00400000 : "UserConf"
    0x00050000-0x003c0000 : "Kernel_RootFS"
    Load Ralink DFS Timer Module
    squashfs: version 3.2-r2 (2007/01/15) Phillip Lougher
    squashfs: LZMA suppport for slax.org by jro
    io scheduler noop registered (default)
    Ralink gpio driver initialized
    Ralink APSoC Hardware Watchdog Timer
    Serial: 8250/16550 driver $Revision: 1.7 $ 2 ports, IRQ sharing disabled
    serial8250: ttyS0 at I/O 0xb0000500 (irq = 37) is a 16550A
    serial8250: ttyS1 at I/O 0xb0000c00 (irq = 12) is a 16550A
    rdm_major = 254
    MAC_ADRH -- : 0x00000000
    MAC_ADRL -- : 0x00000000
    Ralink APSoC Ethernet Driver Initilization. v2.0  256 rx/tx descriptors allocate                                                                                                  d, mtu = 1500!
    NAPI enable, weight = 0, Tx Ring = 256, Rx Ring = 256
    MAC_ADRH -- : 0x0000000c
    MAC_ADRL -- : 0x43436020
    PROC INIT OK!
    --->regValue:1010245
    --->regValue:25010245
    PPP generic driver version 2.4.2
    PPP Deflate Compression module registered
    PPP BSD Compression module registered
    PPP MPPE Compression module registered
    NET: Registered protocol family 24
    tun: Universal TUN/TAP device driver, 1.6
    tun: (C) 1999-2004 Max Krasnyansky <[email protected]>
    block2mtd: version $Revision: 1.1.1.1 $
    u32 classifier
    Netfilter messages via NETLINK v0.30.
    nf_conntrack version 0.5.0 (256 buckets, 2048 max)
    ip_tables: (C) 2000-2006 Netfilter Core Team, Type=Linux
    ipt_time loading
    TCP cubic registered
    NET: Registered protocol family 1
    NET: Registered protocol family 17
    Ebtables v2.0 registered
    802.1Q VLAN Support v1.8 Ben Greear <[email protected]>
    All bugs added by David S. Miller <[email protected]>
    VFS: Mounted root (squashfs filesystem) readonly.
    Freeing unused kernel memory: 120k freed
    init started: BusyBox v1.18.1 (2011-11-28 16:34:27 BRST)
    starting pid 13, tty '': '/bin/firmware init &'
    Algorithmics/MIPS FPU Emulator v1.5
     
    Please press Enter to activate this console. sh: can't create /proc/rt3883/gmac:                                                                                                   nonexistent directory
    Started WatchDog Timer.
    Started WatchDog Timer.
    MAC_ADRH -- : 0x0000001a
    MAC_ADRL -- : 0x3fe28e8f
    rt2860v2_sta: module license 'unspecified' taints kernel.
     
     
    === pAd = c0058000, size = 1076528 ===
     
    <-- RTMPAllocTxRxRingMemory, Status=0
    <-- RTMPAllocAdapterBlock, Status=0
    RX DESC a1810000  size = 2048
    Key1Str is Invalid key length(0) or Type(0)
    Key2Str is Invalid key length(0) or Type(0)
    Key3Str is Invalid key length(0) or Type(0)
    Key4Str is Invalid key length(0) or Type(0)
    1. Phy Mode = 8
    2. Phy Mode = 8
    Read EEPROM, EthCloneMac is 00:1a:3f:XX:XX:XX!
    3. Phy Mode = 8
    MCS Set = ff 00 00 00 01
    <==== rt28xx_init, Status=0
    0x1300 = 00064300
    device eth2 entered promiscuous mode
     
    phy_tx_ring = 0x01f25000, tx_ring = 0xa1f25000
     
    phy_rx_ring0 = 0x01f26000, rx_ring0 = 0xa1f26000
    CDMA_CSG_CFG = 81000007
    GDMA1_FWD_CFG = C0710000
    br0: port 1(eth2) entering learning state
    udhcpc (v1.18.1) started
    Sending discover...
    Using intrapositioned negation (`--option ! this`) is deprecated in favor of ext                                                                                                  rapositioned (`! --option this`).
    Sending discover...
    Sending discover...
    br0: topology change detected, propagating
    br0: port 1(eth2) entering forwarding state
    Sending discover...


    EDIT:
    Atualizado o meu dump foi baseado em uma WOM5000 na versão 3.3. Então eu atualizei para a 4.1 e depois para a 6 beta 2, just in case...
    Queria mandar um abraço para o/a Rosinei!

    Código :
    # cat /proc/version
    Linux version 2.6.21-firmware (root@inet-rosinei) (gcc version 3.4.2) #211 Fri Oct 2 10:26:59 BRT 2015

  17. #37

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Essa parte "factory" na verdade é a config. carregada pelo bootloader quando reseta o aparelho. O MAC e cia ficam no bootloader mesmo.
    (Inclusive dependendo da imagem, pode dar mensagem de falta de mac adress no bootloader, já vi)

    Em algum lugar deve ficar uma parte que é usada quando atualiza o sistema, tem sysupgrade no nome, ela ignora uns checksum's e permite a troca do rootFS no próximo boot. Essa parte poderia ser removida em tese, não lembro onde fica, mas o comando pra usar é algo tipo
    sysupgrade -? endereco-do-novo-rootsfs.img

    Se enviar apenas o uboot.img, ele também tem o TFTP server, em tese dá pra, por ele, enviar o resto (RootFS, inclusive).
    Por um tempo eu usei um 340 da TPLink, brickado, que só conseguia enviar o bootloader, só pra monitorar ping numa torre, ia bem já que IP e mac ficavam no bootloader mesmo.


    Num TPLink antigo, acho que 541 ou 543, lembro que precisei fazer algo do tipo justo por falta de espaço (ACho que era 1 ou 2MB de Rom), mas tinha receita de bolo nalgum canto, enviar bootloader e depois um a um outros 3 ou 4 *.img. Mas... eu usava mais o DD-WRT, eu sei que o Open-WRT tem realmente algumas imagens bla-bla-bla-sysupgrade.bin, não sei bem o que muda, nunca entendi muita coisa com aquela variação, um firmware tem vmlinux.bin, rootfs.bin, root.squash.bin, sysupgrade.bin, factory.bin, outro tem um uimage.bin, e outro vem tudo junto (Ou no máximo em 2 etapas, bootloader primeiro, e suqashfs completo depois), parei no Kamikaze e BackFire porque mesmo neles tinha muita variação, imagina hoje.

    (Achei que ia aprender algo colocando o Kamikaze em hardware x86 (Até num Pentium 4 ele roda, não precisa ser 486 da vida), mas nesse hardware tudo funciona, a vida complica é em roteador de mesa)

    Sobre pegar imagem errada, acho que não, na verdade poucas vezes ví o firmware informar o processador CORRETO, o normal é mostrar um similar da família, não quer dizer muita coisa, só indica qual chipset o desenvolvedor usou quando fez aquela imagem do Open-WRT, no caso dos Asus N6 ou N10 lembrei de ver isso, mostrava um RT38xx quando tinha um RT3050 (Que é muito mais velho que o 3662).

  18. #38

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Acho que você está errado. Se fosse realmente a configuração de fábrica, teria que ser do mesmo tamanho da área de userconf.
    https://wiki.openwrt.org/doc/techref/flash.layout
    Partitions

    Since the partitions are nested we look at this whole thing in layers:

    Layer0: We have the Flashchip, e.g. 8MiB in size, which is soldered to the PCB and connected to the SoC over e.g. the SPI (Serial Peripheral Interface Bus).
    Layer1: We partition the flash space into:
    one or more partition for the bootloader. A U-Boot partition usually consists of 64 KiB u-boot block and a following 64 KiB data block section which contains things like MAC, WPS-PIN, type description…. If no MAC is configured, Wifi will not work correctly.
    a partiton for the OpenWrt firmware
    one or more partition for SoC specific firmware, e.g. "art" for Qualcomm Atheros
    Layer2: we subdivide the "firmware" into:
    "kernel" at the start. In the generation process of the firmware (see obtain.firmware.generate) the Kernel binary file is first packed with LZMA, then packed with gzip. The kernel image is written onto the raw flash, it's not part of any filesystem!
    "rootfs" follow, it contains the file system
    Layer3: we subdivide "rootfs" further into:
    fixed ROM data using SquashFS
    "rootfs_data" using JFFS2. This the the free space on the device that can be used.
    Sobre os vários tipos de arquivos, uns são para boot via rede, outros para instalar na flash, outros para atualizar de uma flash stock e por aí vai.
    E sim, ele mostra a família, mas não bootou.
    Portanto, pode ser que eu tenha escolhido a ROM do OpenWrt da família errada...
    Agora que tenho como fazer o dump completo da flash, fico mais calmo ao testar o OpenWrt.
    Sobre sysupgrade.bin, isso vai depender do fabricante da CPU. Atheros, por exemplo, tem uma partição de calibração de RF chamada art.
    Anyway, um rádio eu já recuperei.
    Amanhã testo no outro.
    Quem sabe não rola um tutorial

  19. #39

    Padrão Re: Recuperação de WON5000 através da interface Serial da Placa

    Alguem sabe a velocidade de comunicação da serial da serie APC?

  20. #40

    Padrão

    Citação Postado originalmente por misterbogus Ver Post
    algum os acompanhantes de luxo, pode testar também não. rsrsrs

    o meu conversor vai chegar ainda. e estarei postando testes e resultados.
    estou esperando a finalização desse texte...