Erros no app Bradesco

Você está tentando usar o aplicativo Bradesco de home banking e, ao tentar acessar sua conta, recebe uma mensagem de erro. Pode ser um código numérico (4859…) que o componente webview está desatualizado ou, nas últimas versões, uma tela dizendo que você está com problemas de acesso à internet.



Há dicas diversas, desde se atualizar manualmente o webview até a mais simples, que é desligar o WiFi e forçar a utilização de dados móveis.

Eu tinha muito esse problema e sempre acabava utilizando os dados móveis, que não é a melhor solução, já que vocêpode precisar fazer uma consulta numa área sem sinal de sua operadora mas com internet disponível.

Como com os dados móveis funcionavam eu sabia que era alguma restrição na rede local que eu utilizava, então comecei a fazer uma captura de pacotes enquanto tentava o acesso e verificava os dados quando ocorria o erro.

Em alguns minutos, achei a resposta: o app do Bradesco utiliza o googletagmanager.com e o adservice.google.com de maneira ativa. Se não tiver resposta desses domínios, o app dá erro.

Liberei esses domínios de anúncios no meu firewall e agora o app funciona corretamente.

Acredito que os desenvolvedores devriam ter previsto um tratamento de erros melhor, afinal o google não é o Bradesco e problemas em sites externos ao banco não deveriam causar problemas aos usuários. No meu caso foram regras estritas no firewall, mas o mesmo problema irá ocorrer se qualquer um desses sites apresentar problemas.

Fazendo o adb reconhecer seu dispositivo android

androideia

This post has been translated to english.

o adb (android debug bridge) é uma ferramenta desenvolvimento para android.

Geralmente para ativar basta conectar seu dispositivo android, ativar a depuração USB (USB debugging) e verificar com o comando “adb devices”, que deve retornar uma lista com o número serial dos dispositivos que estejam conectados.

Essa é a teoria. A prática é que só são reconhecidos de maneira automática dispositivos de fabricantes como HTC, Motorola, Samsung… se seu dispositivo é de algum fabricante obscuro ou um legítimo xing-ling, o resultado é parecido com esse:

adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached

Para que seu dispositivo seja reconhecido é necessário colocar o identificador de seu dispositivo no arquivo adb_usb.ini.

Como identificar o fabricante:

Conecte seu dispositivo na porta USB do seu micro (ative a depuração USB).

Ver o post original 612 mais palavras

Alcatel NM 5620 e XDMCP no Linux

Por questões de trabalho eu utilizava um estação Sun Ultra 5, já obsoleta, mas era uma das poucas opções para acesso a uma plataforma de gerência Alcatel NM 5620 (também obsoleta, veja só!).

A Sun tomava espaço na mesa, tinha uma fonte com um cooler de barulho particularmente irritante. Detestava ter que usá-la.

Olhando os scripts que iniciavam o programa de gerenciamento eu vi que utilizava protocolo XDMCP para a parte gráfica (o servidor em si estava em outra localidade). Pensei de imediato: vou configurar isso no Linux e posso usar uma estação mais moderna ou uma máquina virtual, para liberar espaço.

O primeiro sinal que não ia ser tão simples era a janela de login, o texto estava com fontes maiores. Mas se fosse só estético, sem problemas.

Depois a tela de abertura, onde o texto estava cortado. Mas era só estética…

E o tiro de misericórdia: a tela de busca de nós de gerência perdia o botão Make List, que iniciava a busca e a coluna de Admin Status não aparecia. A janela tinha tamanho fixo, não permitia o reposicionamento.

Sem isso era inútil prosseguir. Quando tinha um tempo livre experimentava usar diferentes gerenciadores Gnome, LXDE, LightDM, distribuições (Ubuntu, Arch, Mint). Sem sucesso.

Depois de meses vi que tinha máquinas virtuais do Sun Solaris 10, bem mais modernos que a versão que eu usava (tão antiga que até esqueci). Baixei as VMs de 32bits e 64 bits para poder usar nas versões de Windows disponíveis que aparecessem.

Comecei com a VM de 32 bits, configurei, criei os scripts e os testes foram perfeitos, já poderia aposentar a estação. Não do jeito que eu queria, mas estava valendo.

Como já tinha acertado a versão de 32 bits rapidamente coloquei os scripts na de 64 bits. Resultado? As mesmas telas com distorções de fontes que havia encontrado no Linux…

Não fazia sentido. As duas versões possuem exatamente o mesmo conjuntos de fontes.

Usei o comando xset -q, retorna alguns parâmetros, como as fontes em uso:

Além de informar as fontes que o servidor X11 está utilizando ele mostra a ordem em que elas são buscadas!

Mudei a ordem das fontes com o comando xset +fp, fiz uma nova conexão com a VM de 64 bits e a gerência apresentava todas as janelas corretamente, com todos os botões e campos.

Eu não esperava que as fontes pudessem ter uma ordem correta, mas acabei encontrado uma discussão na Internet onde alguém explicava que o SunX (servidor X11 do Solaris) ao encontrar uma referência à uma fonte varre todos os diretórios de fontes até encontrar a fonte de nome exato, apenas quando a fonte é inexistente substitui por uma compatível. O Xorg (servidor X11 do Linux e das versões mais moderanas do Solaris também) utiliza a primeira fonte compatível que encontrar, caso a fonte compatível esteja disponível antes da fonte desejada será utilizada. Isso explicava todos os problemas de apresentação, apesar das fontes adequadas estarem disponíveis.

Resolvido na VM de 64 bits, foi sor seguir o mesmo raciocínio nas máquinas Linux (e Free BSD que alguém usava).

Assim após acertar a ordem das fontes a janela de login apresentava as fontes menores que estávamos acostumados:

A tela de abertura não cortava o texto:

E, o mais importante, a janela de gerência tinha o botão Make List e todos os campos presentes, incluindo o Admin Status:

Para não ter que acertar manualmente a ordem das fontes, no Linux basta criar o seguinte arquivo com a ordem desejada das fontes /usr/share/X11/xorg.conf.d/10-fonts.conf com o seguinte conteúdo:

# Fontes extras para acesso a estacao X11 remota

Section "Files"

FontPath	"/usr/share/fonts/X11/misc:unscaled"
FontPath	"/usr/share/fonts/X11/75dpi:unscaled"
FontPath	"/usr/share/fonts/X11/100dpi:unscaled"
FontPath	"/usr/share/fonts/X11/TrueType"
FontPath	"/usr/share/fonts/X11/Type1"
FontPath	"/usr/share/fonts/X11/Type1/sun/"
FontPath	"/usr/share/fonts/X11/F3bitmaps:scaled"
FontPath	"/usr/share/fonts/X11/misc:scaled"
FontPath	"/usr/share/fonts/X11/75dpi:scaled"
FontPath	"/usr/share/fonts/X11/100dpi:scaled"

EndSection

Problemas com VPN IPsec com cliente strongSwan – MODp_2048 e Windows

A utilização de acesso remoto por VPNs é cada vez mais comum (e agora em tempos de COVID19, praticamente inevitável).

Há algum tempo atrás instalei um firewall que utilizava pfsense (ótimo firewall para quem precisa de uma proteção mais sofisticada para sua rede) e comecei a utilizar seus recursos e foi quando configurei uma VPN com IPsec, pela facilidade de configuração e já existir um cliente nativo desde o Windows 7.

Como utilizo um celular android procurei um cliente IPsec e utilizei o strongSwan, que também a passei a utilizar no Linux. Tudo funcionava bem até o strongSwan chegar na versão 4.4, quando passou a forçar a utilização de chaves de 2048 bits (DH group 14).

Não conseguia mais acesso via android ou Linux. Com Windows estava tudo funcionando.

Observando os logs do pfsense encontrava esse alerta nas tentativas falhas com cliente strongSwan:

[IKE] DH group MODP_2048 inacceptable, requesting MODP_1024

Pesquisei e vi que era por conta da mudança. A primeira coisa foi adequar o pfsense e forçar a utilização do grupo DH-14 (anteriormente estava utilizando DH-2, 1024 bits), nas opções de Fase 1 do algoritmo de encriptação. No menu do pfsense o caminho é VPN / IPsecMobile / Clients / Edit Phase 1.

Pronto, os clientes strongSwan voltaram a funcionar perfeitamente. Os clientes Windows é que deixaram de funcionar. 😦

Mas no próprio site do strongSwan havia a descrição do problema: o cliente IPsec Windows é capaz de trabalhar com o grupo DH-14, porém vem com essa funcionalidade desabilitada.

Para habilitar basta a criar uma chave DWord no registry com o valor 1:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\NegotiateDH2048_AES256

Após essa alteração voltei a ter conectividade em todos os clientes.

No caso do Windows 7 há um procedimento especial para importar certificados privados que sejam utilizados em conexões IPsec:

- Clicar 2 vezes no seu certificado Meu_certificado.crt
- Clicar no botão Instalar Certificado
- Avançar
- Colocar todos os certificados no repositório a seguir
- Clicar em Procurar
- Marcar “Mostar Repositórios Físicos”
- Selecionar “Autoridades de Certificação Raiz Confiável” e dentro desta chave “Computador Local”
- Selecionar OK
- Avançar
- Concluir
- OK

Windows Server 2003 – Erro 0x80072EFF no Windows Update

Ocasionalmente preciso subir um servidor Windows 2003, por conta de sistemas legados.

Após as configurações iniciais o Windows Update apresenta o erro 0x80072eff e não é possível baixar nenhuma atualização.

2003update1

Esse erro é por conta da versão do Internet Explorer inicial ser inferior a 8.x.

A solução é simples: instale o Service Pack 2, que permite instalar o IE 8.x e após esse procedimento o Windows Update se normaliza.

 

Link2SD, Apps2SD com problemas no android Marshmallow 6.0. Solução: ext3 format.

Sempre utilizei o Link2SD em aparelhos android com root, inclusive no LG H442 que possuo. Um dos motivos que me impediram de fazer o upgrade do android Lollipop para o Marshmallow nesse aparelho foi não haver uma estratégia de root disponível no MM, o que iria impedir de continuar usando o Link2SD.

Após o pessoal do XDA Developers conseguir um bootloader destravado e a criação de um recovery com TWRP o root passou a ser possível e o interesse no upgrade retornou.

Após o upgrade a primeira coisa que percebi foi uma mensagem de erro do Link2SD informando que não conseguia escrever os scripts na segunda partição (formatada com ext4).

Encontrei um guia do techmagus que resolveu o problema parcialmente: utilizar o Apps2SD (app similar em funcionalidade ao Link2SD, porém mais recente e com atualizações mais frequentes). Já era possível mover os apps para a segunda partição, porém a mensagem “Cartão SanDisk corrompido” permanecia e outro agravante: a opção de utilizar o cartão SDHC para armazenar as fotos e vídeos da câmera ficava indisponível. 😦

No guia do techmagus há um pequeno FAQ que informa que por conta do algoritmo de detecção de partição ext4 do Marshmallow ele pode dar essa mensagem de erro, porém a partição é funcional e não tem erros.

Sim, funcional mas não atendia minha expectativa.

Procurando mais informações vi a nova funcionalidade do MM, adopted storage, que utiliza uma partição ext4 encriptada como uma extensão da memória interna, mais ou menos como o Link2SD e APPs2SD funcionam.

Então pensei que antes do MM a partição ext4 ficava “invisível” para o android e agora, quando o android passou a utilizar uma partição ext4 para seu uso, a partição passa a ser vista pelo sistema. Como ela não está encriptada, o sistema dispara uma mensagem de erro.

Ocultar a partição seria uma solução, algo que não sei se é possível. A outra opção seria buscar um formato “invisível” para o android. No LG H44x os particionamentos disponíveis são ext2, ext3 e ext4. Vamos então tentar formatar a segunda partição com ext3 e… problema resolvido.

O ext3 permitiu que o Apps2SD criasse seus scripts, a mensagem de “Cartão SanDisk corrompido” desapareceu e a opção de utilizar o cartão SD como armazenamento para fotos e vídeos da câmera voltou a ficar disponível.

O Link2SD aparenta ter problemas coma criação de scripts no android Marshmallow, vários usuários estão recomendando utilizar o Apps2SD apenas para criar os scripts e depois utilizar o Link2SD. Não fiz esse teste, mas deve funcionar.

Esse post está disponível em inglês no xda-developers.

Alterando a resolução de uma Sun Ultra 5

Utilizo ocasionalmente uma estação Sun Ultra 5 no trabalho. Tinha um monitor LCD sobrando e resolvi aposentar o monitor CRT que ainda estava em uso.

Se fosse um computador moderno, plug and play, bastava trocar um monitor pelo outro, mas não era o caso.

Antes de fazer a troca verifiquei qual a resolução do LCD, do contrário não teria imagem posteriormente caso o CRT estivesse com uma resolução incompatível. A resolução do LCD era 1280 x 1024 x 60Hz.

Em uma janela de terminal basta digitar o comando:

m64config -depth 8 -res 1280x1024x60 now

-depth é o parâmetro de profundidade de cores.

now ativa a nova resolução.

Basta desligar, trocar os monitores e ligar novamente.

Instalando o android 6.0 Marshmallow no LG Volt H442f (LG Spirit 4G)

ATENÇÃO: esse método de upgrade para o LG Volt H442f é não-oficial e requer maiores conhecimentos. Se feito inadequadamente pode inutilizar o aparelho!

Ainda não há root para o android 6.0 no LG Volt H442f. Se você precisa de root no aparelho não faça esse upgrade!

Créditos: todo o método foi feito e descrito pelo K Stênio que o enviou como um comentário em outro post. Gentilmente autorizou a publicação que achei bastante completa e importante, apenas formatei o texto para o blog.


 

Descobri ontem dando uma passeada pelo XDA-Developers. Foi lançada uma imagem KDZ Polonesa para o LG-H440N, que em resumo é o mesmo que o nosso LH-H442F. Segui as instruções nos tópicos e consegui instalar no meu aparelho. Está funcionando perfeitamente bem!

Se alguém tiver interesse, fiz um pacote com a maioria dos arquivos necessários aqui: https://www.dropbox.com/s/181rlx7tzbquk5y (só não inclui as imagens KDZ porque são muito grandes).

Para instalar o Android 6.0 Marshmallow em seu LG-H442F (“LG Volt 4G”), basta seguir esses passos:

1º – Extraia os arquivos. Entre na primeira pasta e installe os drivers da LG (recomendo remover os antigos, caso tenha instalado). Talvez seja necessário reiniciar o computador;

2º – Na segunda pasta, abra o arquivo “DOWNLOAD LINK” e baixe a imagem H440n10. Salve ela nessa mesma pasta. Após, coloque o celular em modo de download e rode o programa “LGFlashTool2014” com permissão de administrador para fazer o flash dessa imagem;

3º – Passe a introdução do celular e deixe ele ligado conectado ao computador. Entre na terceira pasta e instale os arquivos do LGUP em ordem (primeiro o LGUP_8994_DLL_Ver_0_0_3_23 e depois o 2nd – LGUP_Install_Ver_1_14_3);

4º – Abra a quarta pasta e execute o comando “h440n.bat” com permissão de administrador;

5º – Finalmente na quinta pasta, faça o download da imagem H440n20a . Após, abra o LGUP e insira o caminho completo de onde está essa nova imagem KDZ, incuindo a extensão (o LGUP não vai conseguir enxergar o arquivo pois está configurado apenas para a extensão .tot e não para .kdz, mas funciona mesmo assim);

6º – Clique no botão start e espere. O celular irá reiniciar algumas vezes e então você terá o Android 6.0 Marshmallow!

Pokémon GO: Failed to detect location.

Pokémon GO foi oficialmente lançado no Brasil fazendo o mesmo sucesso que o jogo obteve no mundo.

Pude observar um problema, a mensagem de Failed to detect location. Curiosamente o problema é restrito o jogo, qualquer outra aplicação (Google Maps, iGO, GPS Tester) que faça uso do GPS funciona normalmente e em poucos segundos obtém a posição do sensor GPS do aparelho.

É possível observar nos ícones indicadores que o GPS está ativo e a localização também.

O problema ocorre quando o aparelho está com a opção “Permitir localizações fictícias” (“Allow mock locations”) habilitada no menu de configuração “Opções de desenvolvedor” (“Developer options”).

Desmarque essa opção e o jogo poderá utilizar o GPS sem maiores problemas.

Sem a mensagem de erro de localização após a alteração:

2016-08-06 13.29.37

Movendo VMs entre hosts VMware ESXi sem VMotion ou armazenamento compartilhado

Trabalho com diversos servidores VMware ESXi para otimizar a utilização de recursos de hardware. Ocasionalmente é necessário mover ou copiar alguma máquina virtual entre servidores.

Sem o ambiente vSphere e a ferramenta vMotion as opções são escassas: copiar as VMs para um drive externo, o que implica acesso físico aos servidores (nem sempre possível ou conveniente) ou copiar a VM através do cliente gratuito VMware vSphere para o armazenamento da máquina onde ele está instalado e, em seguida, fazer a cópia para o servidor de destino. Nesse caso é necessário que a máquina tenha espaço livre em disco suficiente para receber a cópia.

A opção que permite essa operação sem as cópias intermediárias é a ferramenta ovftool, disponível para download gratuito no próprio site da VMware (necessário criar uma conta gratuita para fazer o download). Há versões para Linux e Windows, 32 e 64 bits.

É uma ferramenta de linha de comando, assim o exemplo utilizado tem os mesmos comandos qualquer que seja a versão utilizada.

Para instalar no linux execute o seguinte comando após baixar:

$ sudo ./VMware-ovftool-4.1.0-2459827-lin.i386.bundle

No exemplo o servidor de origem tem hostname camaleao, o de destino zebra. A VM a ser copiada é Papagaio. Os servidores tem root como usuário administrativo e os datastores estão como o nome default datastore1.

Para verificar se a VM está disponível usamos o comando ovftool vi e informamos a senha do usuário root:

$ ovftool vi://root@camaleao
Enter login information for source vi://camaleao/
Username: root
Password: ***********
Error: Found wrong kind of object (ResourcePool). Possible completions are:
Papagaio
Hydra_2k3
Gaviao
Hydra_VM
Morgan_2k3

Faça o mesmo no servidor de destino para  se certificar que não existe uma VM com mesmo nome:

$ ovftool vi://root@zebra.acessonet.com.br
Enter login information for source vi://zebra/
Username: root
Password: ***********
Error: Found wrong kind of object (ResourcePool). Possible completions are:
javali
Hamster
Dragao

Após a verficação inicial o comando ovftool -ds é utilizado para fazer a transferência (observe que é necessário se autenticar em cada um dos servidores):

$ ovftool -ds=datastore1 vi://camaleao/Papagaio_DNS vi://zebra
Enter login information for source vi://camaleao/
Username: root
Password: ***********
Opening VI source: vi://root@camaleao:443/Papagaio_DNS
Enter login information for target vi://zebra/
Username: root
Password: ***********
Opening VI target: vi://root@zebra:443/
Deploying to VI: vi://root@zebra:443/
Transfer Completed
Completed successfully

O tempo de transferência pode ir de minutos a horas, dependendo da velocidade da rede, servidores e do espaço em disco ocupado pela máquina virtual.

Após a cópia basta fazer ajustes necessários de endereço IP, VMWare tools, etc.

Atenção! Se a VM tiver em sua configuração uma imagem ISO como drive de CD ou DVD o processo é interrompido com a mensagem “The task was canceled by a user” como pode ser visto abaixo:

$ ovftool -ds=datastore1 vi://camaleao/Papagaio_DNS vi://zebra
Enter login information for source vi://camaleao/
Username: root
Password: ***********
Opening VI source: vi://root@camaleao:443/Papagaio_DNS
Enter login information for target vi://zebra/
Username: root
Password: ***********
Opening VI target: vi://root@zebra:443/
Error:
– The task was canceled by a user.
Completed with errors

Basta alterar a configuração da VM e remover a imagem e deixar a opção CD/DVD como a do servidor.

Matt's Entropy

... seeding /dev/random, one blog post at a time.

Maravilhoso Mundo Novo

De volta ao Paraíso

androideia

Idéias e Android, necessariamente não nessa ordem.

Another Airgun Blog

Idéias e Android, necessariamente não nessa ordem.

Armas de Pressão - Modificações e afins

Metade da graça em atirar está em fazer ajustes na arma.