 Jefferson,  30 de agosto de 2016, HDMI, PorDentro Este post possui recursos que pode ser complicado ou impossível acessar na versão mobile do blog e/ou com uma touchscreen. Versão desktop e mouse recomendados.
Este post estava em rascunho desde junho. Vai para publicação assim mesmo por causa da minha nova política a respeito.
Mas ainda é um rascunho. Quando estiver “pronto” eu removerei este aviso.
Neste post eu vou começar a explicar como os switches HDMI funcionam e fazer a análise de alguns modelos baratos. No final você vai entender por que alguns funcionam de forma errática, o perigo de usar fonte externa e até como corrigir alguns problemas se você tiver alguma habilidade com eletrônica.
Todos os switches HDMI que conheço são eletrônicos e tem alguma inteligência embutida.
Métodos de seleção
Todos implementam um ou mais dos seguintes métodos de seleção de entrada:
- Manualmente, pressionando um botão repetidas vezes até selecionar a entrada desejada;
- Seleção automática, onde o aparelho recentemente ligado seleciona automaticamente a porta do switch onde está conectado.
- Por controle remoto infravermelho.
Alimentação
Geralmente o switch é alimentado por qualquer uma das entradas HDMI. Não é preciso nem abrir um switch para perceber que o sucesso disso é incerto, pois basta olhar a especificação HDMI, que na seção 4.2.7 esclarece os seguintes pontos sobre o fornecimento de corrente por uma porta HDMI:
- Todo Source HDMI deve ser capaz de fornecer um mínimo de 55mA no pino +5V;
- Um Source HDMI dever oferecer proteção contra sobre-corrente de não mais que 500mA no pino +5V.
Ou seja, para a especificação, 500mA já é um curto-circuito e os fabricantes só precisam garantir meros 55mA. Muitos equipamentos podem fornecer e fornecem mais que isso, mas a especificação só exige 55mA. Para resolver esse problema alguns switches contam com entrada para fonte externa, mas você verá adiante que usar uma pode não ser boa idéia.
Pela análise de um switch típico você poderá entender esse e outros problema:
SWITCH “TD-LINK”

Este switch usa um chip bem popular: o Pericom PI3HDMI301. A primeira coisa interessante que encontramos no datasheet é que o consumo típico é de 200mA quando em operação. Bem acima do mínimo garantido pela especificação HDMI. Mas os problemas não acabam aí.

O chip chaveador opera com 3.3V que precisam ser obtidos a partir dos 5V através do regulador AMS1117 (marcado como U2 na foto). A tensão de entrada de um regulador precisa ser um pouco maior que a tensão de saída, que no caso desse regulador é no mínimo 1V. Isso implica que precisamos de no mínimo 4.3V na entrada e temos 0.7V de margem. Até aí parece razoável, mas como o switch usa diodos para isolar as entradas a tensão na entrada do regulador é a tensão +5V HDMI menos a queda de tensão típica no diodo. Aí a coisa fica crítica.
O designer deste switch usou diodos retificadores comuns, que tem uma queda de tensão típica justamente de 0.7V. Isso explica porque esse modelo tem um jack para alimentação externa.
CONTINUARÁ QUANDO EU PUDER – Assine o feed de comentários ou assine este post para ficar sabendo de atualizações.
Outro switch por dentro:



(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  30 de agosto de 2016, Esse problema deve ter acontecido comigo uma, no máximo duas vezes antes. E quando eu usava o Windows XP (estou agora no 8.1 x64). Faz tanto tempo que eu não o reconheci. Estava ficando cada vez mais difícil ler o cartão da minha câmera. Eu colocava em múltiplos leitores, em múltiplas portas USB (eu tenho mais de 30) e às vezes ele pegava na hora e eu achava que era mau contato. Houve uma vez que eu desisti e deixei o leitor plugado na USB enquanto eu fazia outra coisa aí uma meia hora depois, sozinho, o Explorer abriu com o conteúdo do cartão.
Passei vários dias convivendo com o problema até que perdi a paciência. Ai me lembrei de como eu havia resolvido um problema similar em 2010.
Removi todos os leitores de cartão e apaguei todos os dispositivos que apareciam como ocultos.
Problema resolvido.
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  29 de agosto de 2016, PorDentro Este post possui recursos que pode ser complicado ou impossível acessar na versão mobile do blog e/ou com uma touchscreen. Versão desktop e mouse recomendados.
Este post está em rascunho.

Eu tenho um aparelho desses e o amigo José Carneiro tem dois. Um dos quais deu defeito e agora não exibe nada pela HDMI. Eu peguei para analisar e estou escrevendo este post com as coisas que vou aprendendo no caminho. Posso não conseguir o conserto mas o meu relato pode ser útil para outros.
A única coisa que vou adiantar sobre minha opinião a respeito do aparelho é que achei a qualidade do som decepcionante. Entretanto eu ainda preciso fazer um teste mais rigoroso para ter certeza de que fatores externos não influenciaram negativamente minha percepção.

Lá no centro da placa principal podemos ver escrito MODEL: HT-F5500. O que sugere que a mesma placa é usada para outros aparelhos.

Outras inscrições:
- CODE: AH41-01606A
- AH41-01606
- SIZE: 240×142/1.6T
- DATE:2012.12.19
O aparelho tem uma entrada e uma saída HDMI. Com a entrada HDMI selecionada seu som deveria sair pelas caixas acústicas do aparelho e a imagem (e o som também) pela saída HDMI, mas o aparelho não exibe imagem em nenhuma condição e o som da HDMI IN, segundo relato de JC, também não pode ser ouvido. Isso sugeria o chip HDMI completamente morto.
Coloquei um switch HDMI na saída HDMI para checar se a porta tinha tensão. A porta correspondente do switch acendeu, então havia tensão.
Liguei à minha TV FullHD para me certificar de não ser enganado pelo HT estar em um modo incompatível e apesar de não ver imagem constatei que o HT era adicionado como um dispositivo HDMI CEC no menu, então a saída HDMI não estava morta pois os canais de sinalização estavam funcionando. A não ser que a sinalização seja feita por fora, o chip HDMI não deve estar realmente morto.
Eu tentei um RESET do aparelho que é feito apertando por cinco segundos o botão STOP frontal na condição de NO DISC. O display exibe INIT por algum tempo e depois, quando selecionada a opção BD-DVD, fica exibindo SETUP, que é a condição de fábrica. Mas nada mudou.
Todo a operação HDMI é controlada pelo chip Explore EP92A2S4, sobre o qual praticamente não existe informação (centro da foto) exceto pelo manual de serviço do Samsung HT-9750W, que usa o mesmo chip. Esse manual de serviço dá muitas dicas importantes de diagnóstico, mas carece de informações detalhadas sobre a operação do EP92A2S4.

Nem no site do fabricante esse chip existe. Assim como não pode ser encontrado nem no ebay nem na Aliexpress. E não é porque seja exatamente “novo” já que o aparelho até saiu da garantia e acho que esse modelo nem é mais vendido. Então se o defeito for nele vai ser preciso canibalizar outro aparelho com o mesmo chip. No Mercado Livre tem gente hoje vendendo a placa inteira, supostamente nova, por mais de R$350. Na minha opinião não vale a pena.
Pesquisando por inscrições existentes na placa acabei encontrando o manual de serviço do Home Theater Sharp HTSB60, cuja interface HDMI é controlada pelo chip EP92A2E. Do mesmo fabricante, com o mesmo número de pinos e com uma diferença de sufixo. Depois de uma comparação da função de diversos pinos entre o esquema da Sharp e as fotos que tirei estou razoavelmente convencido que o pinout é o mesmo portanto dá para usar também o manual da Sharp como referência de manutenção desta região do F5505K.
Aqui está o datasheet do EP92A2E. Ele não acrescenta muita informação ao que pode ser visto no manual de serviço da Sharp exceto por este diagrama de blocos que joga bastante luz sobre o funcionamento interno do chip:

O diagrama de blocos dá a entender que, sendo confirmado que não existe áudio em HDMI IN, então o chip deve estar mesmo com defeito, provavelmente no switch interno.
Uma coisa interessante que podemos ver no datasheet e nos manuais de serviço é que o chip tem uma porta HDMI extra, não implementada pelo F5505K. As portas do chip são numeradas 0, 1 e 2 sendo que o F5505K usa apenas as portas 0 e 2. Será que o chip está travado justamente na porta que não tem conexão?
Duas outras informações saltam aos olhos no manual da Sharp:
- O chip tem firmware, que pode ser atualizado pelo fabricante do aparelho;
- Existe um pino chamado MCU_RSTb que quando posto em nível baixo “a controladora HDMI é totalmente resetada”;
É tentador resetar a controladora, mas o termo “reset” tem conotações perigosas e existe um pequeno risco de que isso só piore as coisas e eu teria que regravar o firmware mas não há qualquer informação de como fazer isso.
Os pinos de acesso aos terminais de gravação estão disponíveis na placa, rotulados EX3.3V, HM_70, HM_71, HMCU_OP e HGND. Aliás foi procurando pelo propósito de um desses pinos que cheguei ao manual da Sharp. Entretanto o manual da Samsung chama esse conector de DEBUG. Será que atua como porta serial?
Veja no centro da foto.

A foto acima mostra também o footprint para um conector WR1_R e test points para os sinais WDATA1, WBCLK, WCLK, WINIT, WIOSET e WS4.6V de um lado e WRST, WDATA, WDGND, WLRCK,WDATA2 e WDGN2 do outro. Mais acima os test points para a porta Ethernet (L_DGND, RX-, RX+, TX- e TX+). Aliás no centro da foto está o chip controlador da porta ethernet, um Realtek RTL8201E.
Zoom nos componentes mais próximos aos conectores HDMI:

Os componentes marcados como ESD Protection (proteção contra descarga eletrostática) parecem similares ao CM1213 da ON.
Na região das memórias temos os footprints para um conector CN6 (esquerda) e UCN2 (direita)
CN6 parece conectar com o chip com dissipador preto.

Footprint para CN12 e o curioso footprint para um um botão (SW17). O que será que isso aciona?
CN12 parece conectar com o chip com dissipador preto.

Footprint para conector CN7 e algo que parece ser um indutor (WC2_R).
Módulo bluetooth.
Conector do flat cable dos botões capacitivos do painel. À direita vemos o footprint de uma possível conexão USB extra (WCN1_i)

(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  27 de agosto de 2016, Consertos, PorDentro, Redes 
Além do básico que é checar se o cabo está crimpado corretamente este tipo de aparelho tem um recurso impressionante: ele mede o comprimento do cabo. Mais que isso: ele mede o comprimento de cada par do cabo. Assim é possível saber:
- Se o cabo foi cortado e onde;
- Se algum par foi danificado e onde;
- Se o cabo é longo demais.
Alimentação
O aparelho tem um consumo de 16mA (de acordo com o manual) e é alimentado por quatro pilhas AA, o que eu hoje em dia acho muito inconveniente. Precisar de duas desse tipo é o meu limite. E o fato disso criar oito possíveis pontos de mau contato não ajuda, mas poderia ser pior: eu gosto ainda menos de baterias de 9V. Opera normalmente também com quatro baterias NiMh.
Resultado de meus testes:
- 4.0V – Não liga.
- 4.4V – Liga, mas texto mal é visível na tela
- 4.6V – Texto mais visível
- 4.8V – Texto já parece completamente visível
Qualquer dia desses eu vou acabar colocando um jack USB no aparelho para ter a opção de alimentá-lo usando o mesmo “power bank” que uso para carregar meu celular.
A eletrônica
O aparelho é muito difícil de abrir quando você não sabe como. Eu provoquei pequenos danos externos e internos ao meu PN-8108 tentando forçar a abertura até descobrir que ele é fechado por parafusos ocultos em orifícios selados por cilindros de plástico, que parecem “pezinhos” que por não saírem de jeito nenhum você acredita que sejam parte da carcaça do fundo. O único modo aparente de desbloquear o caminho até os parafusos é perfurar esses cilindros.
A foto abaixo é do interior do Puneng PN-8108. O SC8108, de outro fabricante, opera da mesma forma (eu tenho ambos) e por isso eu suponho que seja quase idêntico por dentro.

O display é alfanumérico de 16 colunas e 4 linhas e a disposição dos pinos me faz crer que seja compatível com o padrão hitachi HD44780. Porém ainda assim seria um tanto difícil conseguir substituto exato para o display porque o formato não é tão comum. O que você encontra às pencas no mercado por causa do Arduino são displays 20×4 e 16×2, mas não 16×4. O display tem backlight que você opera por um botão.
Toda a inteligência está no enorme microcontrolador de 40 pinos Atmel AT89S52 (opera de 4V a 5.5V). Se este der defeito o aparelho provavelmente vai para a sucata, porque aí está o programa e embora seja possível comprar um “virgem” por R$10 no Mercado Livre, não faço idéia de como implementar o algoritmo que mede o comprimento dos cabos, mesmo que eu levantasse todo o diagrama. Os outros componentes relevantes estão no fundo e são todos circuitos integrados lógicos comuns fáceis de adquirir:
- HCF4051 (3x) – multiplexador/demultiplexador analógico de 8 canais – opera com no mínimo 3V;
- HCF4052 – multiplexador/demultiplexador analógico de 4 canais duplo – opera com no mínimo 3V;
- 74HC00 (2x) – quatro portas NAND de duas entradas – opera com no mínimo 2V;
- 74HC373 (2x) – Latch transparente tipo-d tri-state com 8 portas – opera com no mínimo 2V;
- 74HC4040 – contador ripple binário de 12 estágios – opera com no mínimo 2V.
A necessidade do microcontrolador acaba definindo até onde as baterias podem descarregar antes do aparelho deixar de funcionar. Note que o microcontrolador deve operar com até 5.5V mas quatro pilhas AA novas podem dar até 1.6×4 = 6.4V. Para evitar dano, a tensão de alimentação de todos os circuitos integrados é regulada pelo conjunto de diodo e transistor Q1 e D2.
Diagrama parcial
Clique na imagem para ver em tamanho real e legível

Detalhe do circuito de alimentação:

Os dois diodos, marcados D3, ligados a R18 são o mesmo componente. Possivelmente um MMBD4148SE.
Ao apertar o botão Power, Q3 conduz o que faz Q4 conduzir e manter Q3 conduzindo através de R12. O aparelho é desligado pela atuação de Q5, que pelo que entendi ocorre em duas situações:
- Após um intervalo de 30 minutos ligado, o microcontrolador manda um sinal de desligamento via C11;
- Ao apertarmos de novo o botão Power o microcontrolador sente isso no pino 7 (através de R19) e comanda o desligamento também via C11
Ou seja: o desligamento sempre depende do microcontrolador.
A tensão +B é um pouco menor que VBAT por causa da queda em Q4 e a tensão em +C é regulada em torno de 4.1V (a tensão do zener D2 menos a queda de tensão na junção base-emissor de Q1)
O meu PN-8108 não ligava mais e após levantar o esquema levei apenas alguns minutos para descobrir que era Q3 que estava com defeito. Após a substituição por um transistor NPN de uso geral 2N3904 o problema foi resolvido.

Terminadores
Para medição de comprimento não é necessário haver nada na outra extremidade do cabo. Para outros testes o aparelho requer que um terminador especial chamado de “wiremap adapter” seja colocado na outra ponta. Para abrir o terminador basta remover o parafuso que está oculto sob a etiqueta e desencaixar.
Você pode ter até 8 terminadores que o aparelho é capaz de distinguir entre eles e dizer que cabo você está testando. Eu não consegui adquirir os outros sete por um preço razoável mas adiante eu explico o necessário para fabricá-los. Isso só faz falta realmente quando você está sozinho identificando um grande número de cabos.
A eletrônica do terminador é simples:


Diagrama

A placa tem dois componentes que não aparecem no diagrama: D105 e D106 (provavelmente um zener), porque eles são conectados apenas às ilhas de solda no fundo e mais nada. Dependendo das ligações que você faz com essas ilhas de solda você muda o ID do terminador, conforme imagem abaixo:

A lógica é a seguinte:
São sempre três jumpers de solda, mas os dois primeiros (sempre 2,3 ou 1,4) apenas definem a polaridade da série com os dois diodos. Ligando 2 e 3 é uma polaridade e ligando 1 e 4 a polaridade inverte, mas uma ponta é sempre ligada ao pino 1 do conector RJ45. O último jumper define se a outra ponta da série vai ficar ligada aos terminais 3, 4, 5 ou 6 do conector RJ45.
Você não precisa fazer as ligações referentes a ID1. Nenhum jumper dá o mesmo resultado.
A informação necessária pra deduzir isso foi obtida nos comentários deste blog russo, que por sua vez foi dica do leitor João Batista nos comentários deste post.
Nesta outra versão do esquema eu tento deixar o papel dos dois diodos mais fácil de entender:

O BIP
O terminador emite um bip periódico quando o testador é plugado na outra extremidade que é útil quando você está trabalhando em dupla mas pode deixar outras pessoas desconcertadas sem saber de onde o som vem. Geralmente você pluga o terminador primeiro porque ele não tem qualquer indicação visual e se encaminha para a outra ponta do cabo com o testador. Quando você chega lá minutos depois e pluga o testador no cabo, o terminador começa a emitir o bip. O intervalo entre bips não é curto o bastante para ser irritante, mas é longo o bastante para dificultar muito a localização de sua origem. Já ocorreu uma vez de eu mesmo voltar ao recinto e por um minuto ficar imaginando de onde vinha o bip. Eu conheço um celular que faz a mesma coisa quando a bateria está com carga baixa e é de deixar você maluco.
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  22 de agosto de 2016, Como o próprio nome diz, este procedimento é genérico. Um exemplo simplificado que você pode adaptar para o seu aparelho. Até agora só testei com meu NVR (backup e restauração) e seis câmeras IP (apenas backup). Eu vou passar a publicar backups de aparelhos que passarem pelas minhas mãos e espero poder estimular outras pessoas a publicarem os backups dos seus.
Do que você precisa:
- Acesso telnet ao aparelho;
- Que o linux do aparelho tenha busybox (os comandos necessários são parte dele);
- Um servidor NFS ou TFTP (por enquanto só abordarei NFS). Aviso: Se o aparelho tem porta USB que suporta pendrives pode ser muito mais simples usá-la em vez de usar o servidor NFS/TFTP. Veja exemplo na seção “DUMP/backup do firmware” no meu post sobre o mini-NVR.
Infelizmente nem todo aparelho com busybox disponibiliza os comandos de que precisamos. Modems e roteadores, por exemplo, costumam vir com uma versão bem limitada do busybox. Aliás, é comum você sequer conseguir listar diretórios via telnet nesses equipamentos.
O que você precisa saber
Para o propósito deste texto, entenda o comando “mount” do linux como o comando para fazer o que é um “mapeamento de rede” no jargão do Windows. Por exemplo:
mount -t nfs 10.0.0.10:/srv/storage /tmp/nfs
Faz com que o conteúdo de 10.0.0.10:/srv/storage seja mapeado localmente como /tmp/nfs
Para gravação em memória flash do tipo NOR usa-se o comando flashcp. Em flash do tip NAND usa-se o comando nandwrite. Eu suponho que você possa distinguir qual é o caso por qual comando está presente no seu aparelho. Nos poucos que testei somente flashcp estava disponível.
Apesar do firmware que você instala ser apresentado como um único arquivo, no aparelho a memória flash é organizada em partições, como um HDD. No jargão do linux a flash é chamada de “MTD” e as partições são identificadas como “mtd0”, “mtd1”, “mtd2” e assim por diante.
Para obter tudo o que precisamos saber sobre essas partições use o comando:
cat /proc/mtd
A resposta é algo assim:
|
|
# cat /proc/mtd dev: size erasesize name mtd0: 00050000 00010000 "uboot" mtd1: 00180000 00010000 "kernel" mtd2: 00400000 00010000 "rfs" mtd3: 01930000 00010000 "app" mtd4: 000c0000 00010000 "config" mtd5: 00040000 00010000 "logo" |
O campo “name” nos dá a dica do propósito (os nomes variam com os aparelhos) de cada partição o que é muito útil ao fazer restauração e modificações. Você deve fazer backup de todas, mas só deve restaurar o mínimo necessário e com atenção:
- uboot – A primeira partição, não importando o nome, deve ser o bootloader. Geralmente somente leitura. Não mexa nessa a menos que não tenha escolha.
- kernel – É onde fica o linux propriamente dito. Geralmente somente leitura. Geralmente você não precisa mexer com ela.
- rfs – “rootfs” ou sistema de arquivos raiz. Não tenho certeza ainda do que você pode fazer com ela.
- app – No caso do NVR, é onde fica o programa (app) que você vê no monitor, o controle activex que você baixa, etc
- config – a configuração do usuário. Muitas vezes apagar essa partição faz um hard reset do aparelho, mas sempre faça um backup antes.
- logo – no caso do NVR é nessa partição que fica a imagem em formato JPG que aparece na tela quando o aparelho está dando boot.
Vamos supor para os procedimentos a seguir que você tem seis partições no aparelho e tem um servidor NFS no endereço 10.0.0.10 com um export chamado /srv/storage.
Procedimento de backup
mkdir /tmp/nfs
mount -t nfs 10.0.0.10:/srv/storage /tmp/nfs
dd if=/dev/mtd0 of=/tmp/nfs/mtd0.img
dd if=/dev/mtd1 of=/tmp/nfs/mtd1.img
dd if=/dev/mtd2 of=/tmp/nfs/mtd2.img
dd if=/dev/mtd3 of=/tmp/nfs/mtd3.img
dd if=/dev/mtd4 of=/tmp/nfs/mtd4.img
dd if=/dev/mtd5 of=/tmp/nfs/mtd5.img
Pronto, se você não viu nenhuma mensagem de erro uma cópia das seis partições está no seu servidor NFS. Confira o tamanho de cada arquivo com o que aparece na coluna “size” do comando cat /proc/mtd antes de prosseguir. Tem que dar exatamente igual mas perceba que os números em /proc/mtd estão em hexadecimal e o Windows mostra os tamanhos, claro, em decimal.
De posse desse backup você pode fazer comparações grosseiras entre firmwares. Instale várias versões pelo método tradicional, faça backup de todas elas e depois compare os backups com um utilitário de comparação para ter uma idéia do que mudou entre elas. Note que as partições que guardam as configurações de usuário podem ser sempre diferentes.
Procedimento de restauração
Digamos que você só queira restaurar as partições 3 e 4 e que os respectivos arquivos estão no compartilhamento do servidor NFS.
mkdir /tmp/nfs
mount -t nfs 10.0.0.10:/srv/storage /tmp/nfs
#cd /tmp/nfs
ls < – você deve ser capaz de ver uma listagem dos arquivos no servidor
flashcp -v mtd3.img /dev/mtd3
flashcp -v mtd4.img /dev/mtd4
reboot
Pronto. Partições restauradas.
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  22 de agosto de 2016, Nota: Este post está em rascunho. Eu sei que pode estar vago, mas alguns poderão notar que já é muito útil do jeito que está. Se precisar de um maior esclarecimento deixe um comentário porque eu irei preenchendo lacunas aos poucos.
NFS (Network File System – Por um tempo eu jurava que significava Network File Server) é um protocolo de compartilhamento de arquivos massivamente usado no mundo Linux e completamente distinto do usado no mundo Windows (CIFS/SMB). Normalmente não tem qualquer utilidade para nós exceto quando precisamos lidar com aparelhos baseados em Linux (cameras ip, nvr, media player, tv, etc), que é o caso que vou abordar neste post. Para muitos dispositivos desse tipo o único meio de trocar arquivos com o mundo exterior, principalmente arquivos que contém o firmware do aparelho, é você ter acesso a um servidor NFS. A maioria dos usuários Windows está a no máximo uma dúzia de cliques de criar um servidor CIFS, mas conseguir um servidor NFS pode ser bem complicado e frustrante quando você não faz a menor idéia de por onde começar.
Outros posts virão onde explicarei como fazer backup e restauração de firmware de alguns aparelhos e o processo vai depender de você ter acesso a um servidor NFS.
Se você tiver acesso ao Windows Server 2008 ou 2012, um servidor NFS supostamente é parte das opções oferecidas, mas não vou tratar disso aqui.
haneWIN NFS Server
Shareware
Prós
- Roda no Windows. Incluindo XP e Windows 8.1 x64 (testado);
- Pequeno, leve, prático e funciona. Do download ao servidor funcionando são só uns poucos minutos.
Contras
O procedimento é muito simples
- Baixe e instale o programa;
- Crie um diretório c:\public
- Execute NFS Server pelo ícone deixado no desktop (para configurar você precisa executar como Administrador);
- Vá em Exports -> Edit Exports File e retire o parâmetro -readonly da linha que começa com c:\public
- Clique em Restart Server
Agora você pode montar no cliente com uma seqüência de comandos do tipo (digamos que o servidor esteja em 192.168.0.10);
#mkdir /tmp/nfs
#mount -t nfs 192.168.0.10:/c/public /tmp/nfs
Observe a notação acima. Se o drive fosse “d:”, o caminho a usar começaria com “/d/”
Se der “Connection Refused” experimente acrescentar ‘-o nolock’, assim:
#mount -t nfs -o nolock 192.168.0.10:/c/public /tmp/nfs
Tunkey Linux File Server
Prós:
- Imediatamente após terminar o assistente de configuração o servidor já está funcionando;
- Compartilhamentos são simultaneamente exportados como CIFS e NFS. Assim você pode colocar um arquivo no servidor através do Linux e resgatá-lo do mesmo local usando o Windows e vice-versa;
Contras:
- É irritante que ele não deixa você terminar a instalação enquanto não escolher uma senha complicada (que dois meses depois eu já havia esquecido e tive que instalar tudo de novo);
- Oferece uma enorme quantidade de configurações pela GUI que são todas completamente inúteis para nosso caso e só confundem;
- Embora o servidor NFS rode automaticamente não encontrei opção na GUI para configurá-lo. Eu só descobri quais eram os diretórios exportados quando fiz um webshell e li /etc/exports. Depois foi preciso editar o arquivo /etc/exports manualmente para fazer uma mudança necessária;
- É configurado para atualizar automaticamente e não encontrei opção na GUI para desativar isso. Então para tentar impedi-lo na marra eu forneci endereços de gateway e DNS falsos;
O Turnkey Linux File Server é uma distro do Linux que está disponível como máquina virtual. Basta importar o arquivo .ova disponibilizado no site na sua cópia do Virtualbox e seguir o assistente de instalação. Em poucos passos está quase pronto para o uso.
A primeira tela do assistente vai pedir uma senha para o usuário root. Você precisa combinar letras maiúsculas e minúsculas e colocar ao menos um número.

Confirme a senha
Se a senha não estiver ao agrado do programa vai ser rejeitada logo na primeira tentativa

Em seguida o programa vai oferecer os “hub services”, que são inúteis para nossa finalidade. Você pode pular a instalação com a tecla TAB, até selecionar SKIP
Salte as notificações da mesma forma

Minta internet tem apenas 800kbps. Esperar para fazer atualizações é intolerável. Eu salto isso também.

Se você não quiser mudar as configurações de rede, a configuração acabou. Se quiser mudar, selecione Advanced Menu

Selecione Networking

Selecione Static e configure ao seu gosto. Para evitar que o programa se atualize sem minha permissão, eu forneço informações falsas de gateway e DNS. Isso não afeta a operação na sua rede.

A partir desse ponto você pode fazer muita coisa com o mouse. Basta acessar o servidor via browser, no endereço IP que você definiu.
O único real problema que encontrei foi que apesar de não existir username e password para acessar um servidor NFS pois as permissões são definidas por IP, por default o servidor NFS não permite gravação se você estiver acessando como usuário root, mas normalmente esse é justamente o usuário com que fazemos login nos dispositivos (dá permission denied). Mas uma pequena configuração extra no arquivo /etc/exports resolve.
Exemplo de arquivo /etc/exports
|
|
# export to all known non-routable (local) networks /srv 10.0.0.0/8(rw,fsid=0,no_subtree_check) 172.16.0.0/12(rw,fsid=0,no_subtree_check) 192.168.0.0/16(rw,fsid=0,no_subtree_check) /srv/storage 10.0.0.0/8(rw,fsid=1,no_subtree_check) 172.16.0.0/12(rw,fsid=1,no_subtree_check) 192.168.0.0/16(rw,fsid=1,no_subtree_check) /srv/homes 10.0.0.0/8(rw,fsid=2,no_subtree_check) 172.16.0.0/12(rw,fsid=2,no_subtree_check) 192.168.0.0/16(rw,fsid=2,no_subtree_check) |
Após a instalação você precisa acrescentar a opção no_root_squash ao compartilhamento que quer liberar completamente.
Você não pode simplesmente copiar e colar o meu arquivo exports porque o arquivo é criado com endereços que dependem da sua rede.
O modo simples de editar o arquivo exports é fazer login pelo webshell para copia-lo para o compartilhamento, editá-lo usando o seu editor preferido no Windows mesmo e depois transferi-lo de volta:
|
|
Acesse: https://endereço_servidor_nfs:12320/ Entre com usuário e senha cp /etc/exports /srv/storage/exports <- copia para um diretório acessível via Windows Edite o arquivo usando o Explorer (acrescente <em>no_root_squash</em> às opções) e o Bloco de Notas e salve-o. cp /srv/storage/exports /etc/exports <-copia o arquivo editado sobre o arquivo original exportfs -ra <- faz as mudanças entrarem em vigor |
O arquivo editado fica mais ou menos assim (observe o que foi acrescentado em negrito):
|
|
# export to all known non-routable (local) networks /srv 10.0.0.0/8(rw,fsid=0,no_subtree_check) 172.16.0.0/12(rw,fsid=0,no_subtree_check) 192.168.0.0/16(rw,fsid=0,no_subtree_check) /srv/storage 10.0.0.0/8(rw,fsid=1,no_subtree_check,<strong>no_root_squash</strong>) 172.16.0.0/12(rw,fsid=1,no_subtree_check) 192.168.0.0/16(rw,fsid=1,no_subtree_check) /srv/homes 10.0.0.0/8(rw,fsid=2,no_subtree_check) 172.16.0.0/12(rw,fsid=2,no_subtree_check) 192.168.0.0/16(rw,fsid=2,no_subtree_check) |
A partir do servidor telnet de uma câmera, consegui fazer o mount com:
# mkdir /tmp/nfs
# mount -t nfs -o nolock 10.0.0.39:/srv/storage /tmp/nfs
Não funcionaram
FreeNFS e FreeNFSe – Free. A versão FreeNFSe é destinada a instalação a partir do Windows XP e é especificamente destinada ao que desejamos: a conexão de clientes NFS “embutidos” ou “embarcados” e é extremamente simples de usar, mas não consegui fazer funcionar. O compartilhamento é criado mas tentar copiar para ele dá muitos erros e os arquivos são criados com zero bytes.
Windows Services For Unix – Gratuito e da própria Microsoft. Pode ser instalado até no Windows XP, mas foi descontinuado e não é mais oferecido para download. Complica demais porque requer que você faça um mapeamento entre os usuários do Windows e do Unix antes de poder compartilhar pastas. Se você quiser procurar por ele aqui estão informações de autenticidade para a versão 3.5 (a última), da cópia que baixei anos atrás:
CRC-32: 87cfd0f3
MD4: 95aac2b26bfd9971b73efe9e6c62d462
MD5: d632c1bd7bed8af2ddb2a00c81aafcab
SHA-1: cd9cc633d967a2186c6f55ec8e362c1efb370661
Problemas diversos
- “Connection refused” no comando mount – A maioria dos tutoriais diz que isso está relacionado ao seu firewall. Mas descobri que acrescentar ao mount a opção ‘-o nolock’ resolve o problema;
- Comando mount demora demais e depois dá “RPC timed out” – O firewall está atrapalhando
- “Permission denied” no comando mount – Se você é o usuário ‘root’ na máquina onde está dando o comando mount, o servidor NFS está configurado para negar acesso ao usuário root;
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  19 de agosto de 2016, Acho um absurdo que em pleno 2016 ainda exista tanto machismo e segregação nas olimpíadas. Essa separação precisa acabar e precisamos ver a mulherada competindo de igual para igual com os marmanjos não só na esgrima, tiro, ginástica artística e nado sincronizado mas também na maratona, canoagem, vôlei, boxe, atletismo…
Quando saiu a primeira notícia de que os nadadores americanos tinham dito que os bandidos que os assaltaram tinham “mostrado o distintivo” para eles eu imediatamente achei que havia algo errado, só por causa disso. Mas como era o Rio eu deixei para lá minha desconfiança. No final minha primeira impressão estava correta e era invenção mesmo.
Concordo plenamente com o surf e skate se tornarem esportes olímpicos porque se futebol é esporte olímpico acho que até cuspe à distância se enquadra :P
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  18 de agosto de 2016, As diferenças não atrapalham a digitação mas atrapalham significativamente o controle do notebook.
Veja as discussões que tive com o vendedor no Mercado Livre aqui e aqui e tire suas próprias conclusões. Para registro, o teclado abaixo é o legítimo teclado PK130QG2B27 que equipa o gateway Ne56R08b

Eu até pensei em comprar vários teclados direto com a bringIT porque além do frete ser mais barato que o do Mercado Envios (alguém se surpreende?), direto com eles dá para trazer vários teclados no mesmo frete, o que eles não deixam fazer pelo Mercado Envios. E como bônus eu não daria nenhum dinheiro ao Mercado Livre. Mas depois dessa eu estou com um pé atrás. Algum de meus leitores de longa data pode testemunhar a favor da empresa? Esse é um hábito ou um caso isolado?
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  16 de agosto de 2016, CFTV, Redes, software Notas:
- “servidor” é, para a intenção deste post, uma funcionalidade de rede oferecido por um equipamento qualquer. Não estou me referindo a “um computador”, mas a aparelhos modernos conectados à rede como câmeras IP, NVRs, DVRs, modems, roteadores e media players;
- Meu interesse é descobrir senhas padrão telnet e ftp de equipamentos que possuo e minha abordagem será essa;
- O método de força bruta só é eficaz se o servidor não limitar o número de tentativas de login num determinado período de tempo. Medidas simples como bloquear o acesso do seu endereço IP por x minutos após y tentativas erradas de login já reduzem enormemente a capacidade de sucesso. Mas os equipamentos em que estou interessado geralmente não implementam qualquer proteção contra ataque de força bruta (edit: Injusto. Vários dos meus implementam medidas simples. Veja comentários);
- Qualquer comentário com perguntas onde sequer pareça que você está querendo usar isso em servidores que não estão sob sua administração será vetado.
Para quê?
Você pode pular essa parte indo direto para “NCRACK” se quiser.
Neste momento eu tenho cinco câmeras IP conectadas à rede de minha casa que tem servidor telnet embutido. O acesso telnet em equipamentos desse tipo geralmente oferece opções avançadas de diagnóstico e recuperação, como hard reset (apagamento da partição de configuração), mudança de configurações e comportamento e até backup e restauração do firmware. Este último é especialmente interessante porque minhas câmeras são genéricas, chinesas, e apesar de todas oferecerem opção de instalação de novo firmware, nenhum dos fabricantes tem sequer uma página na internet. Se o firmware de uma delas for corrompido, o único jeito de consertar é conseguindo uma igual (minhas câmeras são geralmente diferentes) para fazer uma complicada operação de desmontagem e dessoldagem para fazer uma cópia da memória flash com um gravador. Tendo um backup guardado do firmware original eu estou mais seguro.
O problema é que as câmeras tem essa funcionalidade, mas o fabricante não te diz a senha de acesso. Faz um certo sentido porque se você não souber o que está fazendo pode inutilizar a câmera (basta apagar um arquivo do bootloader) e nenhum fabricante quer essa dor de cabeça. Provavelmente a senha só é dita ao usuário pelo suporte técnico avançado quando há um problema sério ou o analista de suporte faz um acesso remoto à sua rede e com isso pode fazer o diagnóstico sem nem precisar dizer a senha. Mas…
Suporte técnico avançado?
Analista de suporte?
Suporte? Que suporte?
No final a existência desse acesso se torna uma vulnerabilidade, porque você não sabe a senha mas alguém na internet com certeza sabe. Todos esses equipamentos são baseados em Linux e o modo mais comum de obter a senha deles é, tendo acesso ao arquivo de firmware (que pode ser de uma atualização oferecida pelo fabricante), extrair o arquivo criptografado de senhas (geralmente etc/passwd) e rodar um programa de força bruta como o John The Ripper. Como o “ataque a um arquivo” não pode ser limitado como o ataque a um servidor, você testa milhares de possibilidades por segundo dependendo do poder computacional que tem disponível. E as senhas nem são tão complexas assim por isso fazendo uma pesquisa no Google você encontra diversos casos de senhas que foram descobertas “facilmente” dessa maneira.
Eu não estou particularmente preocupado com o acesso de terceiros às minhas câmeras porque eu procuro tomar medidas para que terceiros não tenham acesso fácil à minha rede, mas se eu tiver acesso não custa nada eu mudar essa senha default para dar um pouco mais de trabalho a um possível intruso. E, como eu disse anteriormente, o acesso telnet abre diversas possibilidades para o usuário avançado, incluindo mudar essa senha.
Mas já estou fugindo do assunto.
NCRACK
O Ncrack é um programa simples de linha de comando que permite fazer isso. Eu queria testar cinco câmeras e tinha uma dúzia de possíveis senhas. Parece pouco mas manualmente eu teria que fazer 5×12= 60 tentativas de login. Na décima eu já estaria tão entediado que começaria a errar a digitação (HA! Dependendo da senha eu já estou errando na primeira tentativa). Ncrack facilita muito isso porque eu pude colocar as 12 senhas (agora são 23) em um arquivo :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
|
123456 1234qwer admin adminlvjh123 antslq cat1029 h2014071 helpme hi3511 hi3516 hi3518 hiklinux juantech jvbzd klv123 OxhlwSG8 root S2fGqNFs tlJwpbo6 vizxv vizxv xc3511 xmhdipc |
E dei ao ncrack uma lista dos IPs das minhas câmeras e esse arquivo para ele tentar. A linha de comando que eu coloquei em um arquivo .bat ficou mais ou menos assim:
|
|
ncrack -vv -f -P ipcam.pwd --user root 192.168.10:23, 192.168.11:23, 192.168.12:23, 192.168.13:23, 192.168.14:23 pause |
No exemplo acima, “ipcam.pwd” é o nome que dei ao arquivo com a lista de senhas (uma por linha) e o usuário testado sempre será ‘root” (–user root).
Em 30 segundos (quando a lista tinha apenas 12 senhas) eu tinha as senhas de três das câmeras. As senhas das outras duas não estavam na minha lista.
Mais tarde quando acrescentei três câmeras rodei o teste de novo e consegui a senha de mais duas em menos de um minuto. Depois eu ampliei a lista de senhas para 23 e sem fazer qualquer esforço consegui obter a senha de mais uma câmera.
Se você quiser que o programa teste várias combinações de usuários e senhas pode colocar os nomes de usuários em um arquivo (um por linha) e indicar ao programa que o use, trocando o parâmetro ‘–u’ por ‘-U’ como abaixo:
|
|
ncrack -vv -f -P ipcam.pwd -U ipcam.users 192.168.10:23, 192.168.11:23, 192.168.12:23, 192.168.13:23, 192.168.14:23 pause |
No exemplo acima eu coloquei os usuários em um arquivo de nome ‘ipcam.users’.
Note que este é um exemplo bem simples em que eu usei uma lista especial de senhas com alta probabilidade. Ncrack tem outras opções e você pode usar listas muito maiores.
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  08 de agosto de 2016, CFTV Eu tenho esse problema com três das minhas câmeras ONVIF, de um total de oito em operação. Todas do mesmo modelo rodando duas versões do firmware. As três apagam ao mesmo tempo e voltam sozinhas ao mesmo tempo. O intervalo é variável mas se eu não fizer absolutamente nada a imagem volta sozinha em 15 minutos. A primeira vez que notei o problema foi ao desligar o disjuntor #4 no quadro geral da casa. Depois notei que sempre acontecia também quando desligava o disjuntor do meu quarto (que no quadro geral está no circuito do disjuntor #7). Nenhum desses disjuntores alimentava essas câmeras. Até esse ponto eu estava pensando em um estranhíssimo problema de indução magnética. Não fazia sentido, mas era a única explicação que eu tinha.
Até que eu fui fazer manutenção na rede ethernet nos fundos da casa (as três câmeras problemáticas ficam no quintal da frente) e descobri por acaso que desconectar da rede o roteador do quintal também fazia as câmeras apagarem. E as câmeras não tinha nenhuma dependência desse roteador. Mas o roteador estava no circuito do disjuntor #4. As peças começavam a se encaixar.
Então eu fui ao meu quarto e descobri que não era desligar o disjuntor que apagava as câmeras: bastava desligar o switch do meu quarto, que também nada tinha a ver com as câmeras.
Percebeu o tamanho do abacaxi?
A única coisa que eu encontrava em comum entre o roteador no quintal dos fundos e o switch no meu quarto é que ambos eram ligados ao switch principal da casa passando por um longo eletroduto de dezenas de metros. E isso não oferecia explicação alguma já que as câmeras problemáticas são ligadas a um outro switch seguindo na direção oposta sendo que nesse switch são ligadas quatro câmeras e uma delas, de outro modelo, não apresenta problema algum.
Depois de 24h pensando ocasionalmente sobre essa bizarrice, finalmente a ficha caiu e descobri o que mais havia em comum entre o roteador do quintal e o switch do meu quarto: cada um deles era o ponto de acesso à rede de um NVR secundário (eu tenho três na casa no momento).
A explicação até agora: por um motivo que só o fabricante dessas câmeras sabe explicar, se qualquer NVR visualizando as câmeras for desligado estas apagam esperando que o NVR volte a ficar online. Se o NVR voltar a imagem volta imediatamente. Se não voltar, em 15 minutos elas voltam a responder. Não adianta tentar visualizar as câmeras por outros meios nesse intervalo. Elas aparecem na rede, mas não dão imagem. Isso cria uma preocupante vulnerabilidade porque qualquer segmento da minha rede levando a um NVR que for desligado faz com que a gravação de todas essas câmeras pare. Ainda não encontrei uma solução que não seja reduzir as possibilidades de ataque a esses segmentos e/ou distribuir as câmeras por pontos pouco importantes. Não que eu acredite que alguém vá fazer isso, mas eu sempre trato o que faço em casa como um laboratório.
Eu ainda não sei qual o hardware usado pelas câmeras. Quando eu precisar fazer manutenção em alguma delas eu aproveitarei para desmontar e analisar que possibilidade de troca do firmware eu tenho.
(Prefira clicar em "Responder" se estiver comentando um comentário)
|
|
Ótimo; daí que falo a importância dessas informações aqui no blog.
Que tal fazer um post novo com esse conteúdo de 2010?
Abraço.
Eu pretendo mover todo o conteúdo de G&G para cá um dia. Mas antes eu tenho que aprender a mover os comentários e deixar um redirecionador em cada post para avisar aos mecanismos de busca que tudo foi movido. Da última vez que olhei, isso não era fácil.
Jefferson, nos comentários lá, o Bruno sugeriu o software Device Remover, que parece
ser muito bom e poderoso.
Infelizmente o site oficial está vazio, mas achei o download no MajorGeeks.
Nesse link: http://www.majorgeeks.com/files/details/device_remover_543c.html
Se achar inconveniente, por favor pode remover do comentário.
Caso você tenha usado e posteriormente puder, seria muito bom uma análise/tutorial dele.
Não vejo nenhum problema no seu comentário.
Eu usei o programa apenas uma vez, há seis anos. Tenho preferido fazer manualmente, nas raras vezes em que foi necessário.