Esses dias, alguém me perguntou se a defesa da neutralidade da rede também tem sido discutida em outros países.

SIM! A votação similar no Parlamento Europeu está acontecendo amanhã. “Coincidência”, né?

Está rolando uma campanha forte para que as pessoas contactem seus representantes. (Alô amigos aí que têm dupla cidadania europeia!)

Esse debate do Marco Civil da Internet está acontecendo dentro de uma discussão em escala global. Não é uma mera picuinha em Brasília.

E o que nos interessam as leis da Europa? Em primeiro lugar, elas definem precedentes. Em tempos de Organização Mundial de Comércio, há muito não dependemos somente das nossas leis locais. O que se torna prática de negócio comum no mundo acaba chegando aqui via pressão na balança comercial. Em segundo lugar, o motivo dessas coisas estarem acontecendo agora em diferentes lugares não é coincidência, é pressão de lobbies das multinacionais de comunicação (ou seja, o lobby de lá é o mesmo lobby daqui). Em terceiro lugar, pela própria natureza da internet o que acontece na internet da Europa e na internet dos EUA nos afeta aqui.

A nossa política interna é sempre um pedacinho da geopolítica, muito mais do que aparenta. Pintar a nossa realidade puramente em termos internos (ou pior, partidários) é uma ilusão. Acompanhar política internacional não é uma “curiosidade”.

http://www.savetheinternet.eu/

Das várias coisas discutidas dentro do Marco Civil da Internet, a principal questão em jogo é a “neutralidade da rede”. Isto é, é a ideia de que a internet é um condutor neutro de dados. O que isso significa em termos práticos? Significa que os provedores de internet devem prover acesso integral, e não filtrar conteúdos e cobrar a mais por eles.

Nos EUA já existe uma briga grande entre provedores de TV a cabo (que proveem internet através dos seus “combos”) e sites como Netflix. O Netflix usa a internet para prover um serviço de TV de melhor qualidade do que a própria TV a cabo. As operadoras não gostam de “carregar os dados para o concorrente”. Ao invés de prover um serviço melhor, elas querem silenciar a concorrência.

Aqui no Brasil já se começam a ver ameaças à neutralidade da rede. Começa com o “Facebook e Twitter grátis no seu celular pré-pago”. O que de início parece um ‘brinde’ na verdade é uma forma de começar a incutir a ideia de que “uns sites custam mais do que outros”.

Serviços de VoIP como Skype também já são detectados por operadoras de celular e cobrados em separado ou bloqueados. Como no caso do Netflix, é porque eles oferecem um serviço melhor do que a própria operadora.

A proliferação desse tipo de negócio põe em risco a estrutura aberta da internet como a conhecemos. Como diz o Gilberto Gil no texto da petição do Avaaz, não podemos deixar a internet virar uma “uma espécie de TV a cabo, em que se poderia cobrar a mais para podermos assistir a vídeos, ouvir música ou acessar informações”.

Além do mais, se o conjunto de sites e serviços provido aos usuários for restrito tem consequências. Na prática, isso pode até acabar virando monopólio ou censura, pois novos sites não terão oportunidade de surgir.

Cliquem na petição, leiam a descrição e façam parte.

Observação: como o texto abaixo claramente já explicava, um título mais tecnicamente correto seria: “o site do Banco do Brasil compartilha cada link que você acessa nele com o Facebook” (ou seja, cada clique que solicita uma nova página), não absolutamente cada clique do mouse.

Updates: recebi o contato do Banco do Brasil e o problema já foi resolvido, ver no final.

Porra, Banco do Brasil! Quando eu vi aquela “aba” com o logo do Facebook dentro do site seguro do banco, logo pensei que seria uma coisa muito idiota carregar material do site do Facebook de dentro da conexão segura com o banco. Fiquei com raiva do Banco sequer oferecer essa opção pras pessoas.

Aí fui verificar as conexões que o site já faz quando carrega… e lá estava (ver imagem). O site uma requisição ao domínio facebook.com de dentro do site do BB a cada página que eu acesso.

(Sim, e o facebook.com responde com “no-cache” pra garantir que o arquivo não seja armazenado temporariamente, pra se certificar que eles são notificados a cada link que eu clico no site.)

Que lindo. Mesmo se eu NÃO clicar na abinha Facebook, o Facebook é informado que eu (porque eles já sabem o meu IP afinal então cruzar com os hits via BB é trivial) acabei de pedir pra ver meu extrato. (O BB aparentemente não é tão burro a ponto de enviar os dados da página pro Facebook, mas é burro a ponto de enviar a URL (Referer ali na imagem), através da quel dá pra descobrir quais as operações realizadas — cada fundo de investimento tem uma URL diferente, por exemplo.)

Primeiro eu achava esse site novo do BB só feio. Aí eu tentei usar e vi que tem pior usabilidade. Agora eu descobri que é menos seguro. Sabe-se lá o que mais de tosco ele faz.

Clientes de internet banking do BB: a alternativa mais simples é clicar em “Versão Anterior” no topo da página (eu verifiquei e ela não faz hits para facebook.com). É um paliativo enquanto o BB não tira a versão antiga do ar, pelo menos! Ainda assim o Facebook fica sabendo a cada vez que você loga, porque precisa entrar no site novo uma vez pra clicar no “Versão Anterior”.

Uma opção melhor é instalar o Adblock Plus, apertar Ctrl+Shift+V na página do Banco do Brasil, achar o item do facebook.com na lista, clicar com o botão direito e marcar “Block this Item”.

Sério, pra onde eu tenho que gritar pra que o Banco do Brasil conserte isso?

Update: 07/mar/2014 16:08: Depois de trocar algumas mensagens via Twitter, um representante do Banco do Brasil me ligou. Foi bastante solícito. Disse que o departamento de TI deles estava conferindo a situação desde ontem e que hoje deve entrar no ar uma versão nova com a integração com o Facebook “temporariamente desligada”. Disse também que mais adiante eles vão ver como fazer isso da forma certa. Ao meu ver não deveria ter integração nenhuma, mas no mínimo que não haja integração pra quem não peça explicitamente por ela. Pelo visto o problema vai ser consertado mesmo. Valeu a todos que compartilharam!

Update 2: 07/mar/2014 18:00: E acabo de conferir no site e o problema já foi resolvido! Valeu!

E eis que consegui conectar o notebook à internet usando o celular Nokia (N85) e um cabo USB. (Ok, tive que catar instruções lendo no browserzinho do celular, mas rolou!)

Condensando aqui as instruções para facilitar minha vida da próxima vez:

1) Configurar o celular para conectar em modo “PC Suite” (normalmente eu deixo em “Mass storage”). No celular: Tools → Settings → Connection→ USB → USB Connection Mode: “PC Suite”

2) Plugar o celular na USB. Devem aparecer linhas mais ou menos assim no log do kernel (/var/log/kernel, dmesg)

usb 2-1.2: new high speed USB device using ehci_hcd and address 5
usb 2-1.2: New USB device found, idVendor=0421, idProduct=0094
usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.2: Product: N85
usb 2-1.2: Manufacturer: Nokia
usb 2-1.2: SerialNumber: 356808020426058
usb 2-1.2: configuration #1 chosen from 1 choice
cdc_acm 2-1.2:1.1: ttyACM0: USB ACM device
usbcore: registered new interface driver cdc_acm
cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
NET: Registered protocol family 35
cdc_phonet: probe of 2-1.2:1.12 failed with error -22
usbcore: registered new interface driver cdc_phonet
usbcore: registered new interface driver cdc_ether
usb 2-1.2: bad CDC descriptors
usbcore: registered new interface driver rndis_host
usb 2-1.2: bad CDC descriptors
usbcore: registered new interface driver rndis_wlan

O principal ali é o “ttyACM0”, que indica que criou o device. Conferir que existe agora um arquivo /dev/ttyACM0

3) Arquivo /etc/ppp/peers/tether:

ttyACM0 460800 crtscts
connect '/usr/sbin/chat -v -f /etc/ppp/chat-tether'
noauth

O nome “tether” é arbitrário, pode ser qualquer um (será usado abaixo), mas o pppd parece realmente querer os arquivos no diretório /etc/ppp/peers.

4) Arquivo /etc/ppp/chat-tether:

TIMEOUT 5
ECHO ON
ABORT BUSY
ABORT ERROR
ABORT 'NO CARRIER'
ABORT VOICE
ABORT 'NO DIALTONE'
ABORT 'NO DIAL TONE'
ABORT 'NO ANSWER'
ABORT DELAYED
TIMEOUT 12
'' ATZ
OK AT+CGDCONT=1,"IP","tim.br"
OK ATD*99#
CONNECT ''

Note a APN da operadora TIM ali. Para outras operadoras, mudar ali de acordo (gprs.oi.com.br, claro.com.br, zap.vivo.com.br).

O nome do arquivo deve ser o mesmo referenciado dentro do arquivo /etc/ppp/peers/tether acima.

5) Rodar: sudo pppd call tether

Se tudo for bem, aparecerá algo assim no /var/log/messages:

Jul 16 21:24:32 (none) pppd[4746]: pppd 2.4.4 started by root, uid 0
Jul 16 21:24:33 (none) chat[4747]: timeout set to 5 seconds
Jul 16 21:24:33 (none) chat[4747]: abort on (BUSY)
Jul 16 21:24:34 (none) chat[4747]: abort on (ERROR)
Jul 16 21:24:34 (none) chat[4747]: abort on (NO CARRIER)
Jul 16 21:24:34 (none) chat[4747]: abort on (VOICE)
Jul 16 21:24:34 (none) chat[4747]: abort on (NO DIALTONE)
Jul 16 21:24:34 (none) chat[4747]: abort on (NO DIAL TONE)
Jul 16 21:24:34 (none) chat[4747]: abort on (NO ANSWER)
Jul 16 21:24:34 (none) chat[4747]: abort on (DELAYED)
Jul 16 21:24:34 (none) chat[4747]: timeout set to 12 seconds
Jul 16 21:24:34 (none) chat[4747]: send (ATZ^M)
Jul 16 21:24:34 (none) chat[4747]: expect (OK)
Jul 16 21:24:34 (none) chat[4747]: ATZ^M^M
Jul 16 21:24:34 (none) chat[4747]: OK
Jul 16 21:24:34 (none) chat[4747]:  -- got it
Jul 16 21:24:34 (none) chat[4747]: send (AT+CGDCONT=1,"IP","tom.br"^M)
Jul 16 21:24:34 (none) chat[4747]: expect (OK)
Jul 16 21:24:34 (none) chat[4747]: ^M
Jul 16 21:24:34 (none) chat[4747]: AT+CGDCONT=1,"IP","tom.br"^M^M
Jul 16 21:24:34 (none) chat[4747]: OK
Jul 16 21:24:34 (none) chat[4747]:  -- got it
Jul 16 21:24:34 (none) chat[4747]: send (ATD*99#^M)
Jul 16 21:24:34 (none) chat[4747]: expect (CONNECT)
Jul 16 21:24:34 (none) chat[4747]: ^M
Jul 16 21:24:34 (none) chat[4747]: ATD*99#^M^M
Jul 16 21:24:34 (none) chat[4747]: CONNECT
Jul 16 21:24:34 (none) chat[4747]:  -- got it
Jul 16 21:24:34 (none) chat[4747]: send (^M)
Jul 16 21:24:34 (none) pppd[4746]: Serial connection established.
Jul 16 21:24:34 (none) pppd[4746]: Using interface ppp0
Jul 16 21:24:34 (none) pppd[4746]: Connect: ppp0 <--> /dev/ttyACM0
Jul 16 21:24:37 (none) pppd[4746]: local  IP address 189.67.100.239
Jul 16 21:24:37 (none) pppd[4746]: remote IP address 10.6.6.6

E deve aparecer um ppp0 no ifconfig:

ppp0      Link encap:Point-to-Point Protocol
          inet addr:189.67.100.239  P-t-P:10.6.6.6  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:8938 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7998 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:7405264 (7.0 Mb)  TX bytes:1018670 (994.7 Kb)

6) Estabelecer o default gateway: sudo route add default gw 10.6.6.6

Conferir com o comando route:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.6.6.6        *               255.255.255.255 UH    0      0        0 ppp0
default         10.6.6.6        0.0.0.0         UG    0      0        0 ppp0

7) Configurar o DNS (por exemplo, com o DNS público do Google). Arquivo /etc/resolv.conf:

nameserver 8.8.8.8

Feito isso, o acesso à internet deve estar funcionando normalmente no computador!

Como não ficar no escuro em caso de segmentation fault:

1) Compile o programa com símbolos de depuração

Use a flag “-g” do gcc para compilar o programa com símbolos de depuração. Certifique-se que todos os objetos estão compilados com “-g”. Você pode precisar dar “make clean”.

2) Seu ambiente deve estar com “core dump” habilitado

Ao ocorrer um “segmentation fault”, o Linux pode gerar um arquivo que é imagem da memória do programa na hora que ele “deu pau”, o chamado “core dump” (curiosidade: o “core dump” tem esse nome por causa da memória de ferrite dos anos 1950-1970, que era chamada de “magnetic-core memory“, ou simplesmente “core”). Com o arquivo de “core dump”, podemos fazer a análise post-mortem do processo e descobrir por que ele explodiu.

Digite “ulimit -c” no seu shell. Se ele retornar “0”, o sistema não irá gerar os arquivos “core”. Digite “ulimit -c unlimited” para remover a restrição de tamanho aos arquivos core. Esta é uma configuração por processo, que é herdada pelos processos filhos (portanto, só vale no terminal onde foi digitada). Para torná-la “permanente”, você pode configurar isso no seu .bash_profile, .zshrc ou equivalente.

3) Rodando o gdb

Com o binário e o core dump na mão, rode o gdb:

gdb ./meu_programa_bugado core

(Dependendo da distro, o arquivo core pode ter o número do processo no seu nome, como “core.1234”)

4) Comandos básicos do gdb

Com esses comandos básicos, podemos analisar os dados de um core dump:

• bt - (ou backtrace), mostra a pilha de execução, indicando o arquivo e linha onde seu programa caiu. bt full mostra também as variáveis locais de cada função na pilha.
• up e down - sobem e descem níveis na pilha. Útil para usar o comando:
• print expressão - o comando print é bastante poderoso: ele pode exibir variáveis e usar boa parte da sintaxe de C. Use-o para inspecionar seus dados:
• print x
• print ((char*)x)[4]
• print &x
• print x->y
• …
• quit - porque eu sempre erro e escrevo exit!

Há muito mais que se pode aprender sobre o gdb — é um debugger completo capaz de depurar o programa enquanto roda (gdb -p pid), lidar com threads, etc… mas esse conjunto pequeno de comandos apresentado aqui já é uma mão na roda para decifrar os “segmentation faults”!