[GTER] Proramador de EEPROM SFP/SFP+

Nielsen nk at nexttel.com.br
Wed Mar 22 10:33:33 -03 2017 

Pergunta de leigo, qual a vantagem em se programar um gbic ?
Se forem comprar de fora, não peçam dhl ou frete expresso (mais caro) vai 
pagar um horror de taxa.


----- Original Message ----- 
From: <gter-request at eng.registro.br>
To: <gter at eng.registro.br>
Sent: Wednesday, March 22, 2017 10:24 AM
Subject: gter Digest, Vol 168, Issue 137


> Send gter mailing list submissions to
> gter at eng.registro.br
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://eng.registro.br/mailman/listinfo/gter
> or, via email, send a message with subject or body 'help' to
> gter-request at eng.registro.br
>
> You can reach the person managing the list at
> gter-owner at eng.registro.br
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gter digest..."
>
>
> Today's Topics:
>
>   1. Re: Bloqueio de portas (Andrio Prestes Jasper)
>   2. Re: Entrega de IPv4 Fixo /32 (Alan Mendes)
>   3. Re:  RES: Peti??o para Internet sem Limite de Trafego.
>      (Leandro Carlos Rodrigues)
>   4. Re: Bloqueio de portas (Nenhum_de_Nos)
>   5. Re: Programador de EEPROM SFP/SFP+ (Paulo Coimbra)
>   6. Re: Entrega de IPv4 Fixo /32 (Andre Almeida)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 21 Mar 2017 22:31:30 -0400
> From: Andrio Prestes Jasper <mascaraapj at gmail.com>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
> <gter at eng.registro.br>
> Subject: Re: [GTER] Bloqueio de portas
> Message-ID:
> <CAPp3_vPN_gv29Zz1V8WJyUEk-uMku=RuZ1fa+1QdHPLCWTEvPw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Art. 5 e 6 manda abra?o.
>
> Em 21 de mar de 2017 21:53, "Fernando Frediani" <fhfrediani at gmail.com>
> escreveu:
>
>> 2017-03-21 19:51 GMT-03:00 Andrio Prestes Jasper <mascaraapj at gmail.com>:
>> > Em 21 de mar?o de 2017 19:16, Eduardo Bragatto <eduardo at bragatto.com>
>> > escreveu:
>> >
>> > Basicamente a regra ? assim:
>> > Conex?es established,related = liberado
>> > Tudo que vier de origem do cliente com destino internet = liberado
>> > Tudo que vier de origem da internet com destino ao cliente, porta dst
>> > 0-1024 = bloqueado.
>>
>> Basicamente a regra ? assim:
>> Lei 12.965/14 - Art. 9o O respons?vel pela transmiss?o, comuta??o ou
>> roteamento tem o dever de tratar de forma ison?mica quaisquer pacotes
>> de dados, sem distin??o por conte?do, origem e destino, servi?o,
>> terminal ou aplica??o.
>> ? 3o Na provis?o de conex?o ? internet, onerosa ou gratuita, bem como
>> na transmiss?o, comuta??o ou roteamento, ? vedado bloquear, monitorar,
>> filtrar ou analisar o conte?do dos pacotes de dados, respeitado o
>> disposto neste artigo.
>>
>> >
>> > Isso garante que o cliente possa acessar e utilizar qualquer site ou
>> > servi?o dispon?vel na internet.
>>
>> Isso garante que o cliente n?o consiga utilizar a internet da maneira
>> que ele deseja e que n?o necessariamente seja acessar um site ou ler
>> um email mas por exemplo ter conex?es entrantes por motivos que n?o
>> cabem ao provedor saber ou mesmo analisar.
>>
>> Fernando
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 22 Mar 2017 08:17:52 -0300
> From: Alan Mendes <alan at zuknet.com>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
> <gter at eng.registro.br>
> Subject: Re: [GTER] Entrega de IPv4 Fixo /32
> Message-ID:
> <CAJQ5M_s-FrELynUGCvtpz=-sgFf0WpLDx+OaTRvzy1H7PzpZPw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Aqui defino o framed-ip no radius e vai tranquilo.
>
>
>
>
>
>
>
> *ZUKNET NETWORKS LTDA. MEAlan Mendes Morais*
> *Email:* alan at zuknet.com
> *Tel:* 15 3376-9893
>
>
> www.zuknet.com
> http://as262333.peeringdb.com
> http://bgp.he.net/AS262333
>
>
> Em 21 de mar?o de 2017 10:02, Andre Almeida <andre at bnet.com.br> escreveu:
>
>> Amigos, bom dia!
>>
>> Temos alguns clientes que possuem um servi?o um pouco diferenciado, e que
>> n?o querem usar PPPoE nos seus dispositivos.
>>
>> Mas n?o queremos desperdi?ar IPv4 nesse momento delicado fazendo entrega 
>> de
>> /30 desnecessariamente.
>>
>> Pensei em alguma forma de entregar o /32 publico ao cliente.
>>
>> Como aqui utilizamos PPPoE para entregar o servi?o, pensei em fazer algo
>> diferente:
>>
>> 1 ) Incluir no pacote um roteador Mikrotik (como CPE) para fazer o PPPoE
>> (esse tunel receberia um IP Privado)
>> 2 ) Criar um atributo de Framed-route no Radius para ao logar, criar
>> dinamicamente no concentrador a rota do IP Publico com gateway o IP 
>> Privado
>> do PPPoE
>> 3 ) No OSPF do Concentrador, distribuir rotas est?ticas, para encaminhar
>> essas rotas entregues pelo Radius ?s bordas.
>>
>> A partir dai, j? dava pra come?ar a pensar em entregar o IP Privado
>> diretamente para o cliente.
>>
>> Pensei em separar um IP para ser gateway de todos esses clientes.
>> Como assim? Seria o IP de gateway do cliente, ficaria vis?vel apenas para 
>> o
>> cliente. Esse IP, mesmo p?blico, poderia at? mesmo ser o IP network ou
>> broadcast de qualquer outro segmento, pois n?o seria utilizado para
>> destinos. Seria s? para ficar mais "bonito" do que entregar um IP Publico
>> com Gateway privado.
>>
>> E entregar um DHCP (ou dar a possibilidade de adicionar estaticamente) um
>> IP Publico /32 ao cliente.
>> Dessa forma, o cliente s? usaria 1 IP e n?o 4 IPs (que acontece quando
>> usamos um /30).
>>
>> O que voc?s acham? Tem alguma outra forma de fazer isso usando PPPoE 
>> quando
>> no final das contas o PPPoE nao vai direto no equipamento do cliente?
>>
>> Algu?m tem alguma sugest?o? V?rias cabe?as sempre pensam melhor que uma.
>>
>> Obrigado
>>
>> Andre Almeida
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 22 Mar 2017 08:53:16 -0300
> From: Leandro Carlos Rodrigues <leandro at allchemistry.com.br>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
> <gter at eng.registro.br>
> Subject: Re: [GTER]  RES: Peti??o para Internet sem Limite de Trafego.
> Message-ID: <c3e048d5-8ee2-dd5b-6098-1bf07e77d9d1 at allchemistry.com.br>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Em 21/03/2017 18:33, Kurt Kraut escreveu:
>> Aloha,
>>
>>
>> Diante deste assunto recomendo o v?deo "Oligop?lio dos provedores de
>> internet brasileiros" (https://youtu.be/sKFEN2fhSHw) que explica duas
>> coisas importantes:
>>
>> 1) Diferentemente do que a maioria das pessoas pensam, o oligop?lio na
>> internet brasileira  (n?o confundir com telecomunica??es) ? criada pela
>> for?a de mercado, n?o pela a??o do governo ou ANATEL.
>
> Kurt. H? uma contradi??o neste argumento. N?o existe meios de impor
> oligop?lio com aus?ncia estatal.
>
> Lembremos que telecomunica??es s?o uma concess?o do governo. Logo s? ?
> permitido empreender neste ramo por autoriza??o de pol?ticos.
>
> Claro que ? poss?vel obter o oligop?lio naturalmente por?m, impor
> coercitivamente, s? ? poss?vel por interven??o estatal:
>
> 
> http://www.ilisp.org/noticias/empreededores-sao-presos-por-fornecer-internet-sem-autorizacao-da-anatel/
>
> Neste caso, aonde voc? escreve "for?a de mercado", eu interpreto como
> "for?a do corporativismo estatal".
>
> E no artigo, o que a Anatel chama de "concorr?ncia desleal", eu
> interpreto como "n?o se meta no nosso territ?rio sen?o morre".
>
> A gente precisa come?ar a chamar as coisas pelos seus verdadeiros nomes
> para ser poss?vel refletir melhor sobre os problemas do mundo real.
>
>>
>> 2) ? poss?vel resolver o problema desse oligop?lio com pequenos e m?dios
>> ISPs. N?o precisamos nos esfor?ar para manter empresas gigantes (e
>> ineficientes) como a OI.
>
> Exatamente. S? precisa algu?m avisar a Anatel que precisam parar de
> perseguir os pequenos empreendedores.
>
>>
>>
>>
>> Abra?os,
>>
>>
>> Kurt Kraut
>>
>>
>> Em 21 de mar?o de 2017 16:05, R?ney Eduardo 
>> <roneyeduardosantos at gmail.com>
>> escreveu:
>>
>>> Em 21 de mar?o de 2017 15:16, Pedro A M Vazquez
>>> <pedro.a.m.vazquez at gmail.com> escreveu:
>>>> O mercado brasileiro ? reservado para empresas de grande porte. A ON 4G
>>>> encerra opera??es em 20/04 e vai embora do pa?s, aparentemente nem 
>>>> tentou
>>>> vender a ?rea de cobertura dela para a TIM ou assemelhados. Na minha 
>>>> ?rea
>>>> volto a ter a Vivo e a Net como ?nicas alternativas.
>>>>
>>>> Att
>>>>
>>>> Pedro
>>>>
>>> Pedro,
>>>
>>> Tem alguma not?cia que corrobore essa sua informa??o? Procurei e n?o 
>>> achei.
>>>
>>> --
>>> R?ney Eduardo
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 22 Mar 2017 08:07:38 -0300
> From: "Nenhum_de_Nos" <matheus at eternamente.info>
> To: gter at eng.registro.br
> Subject: Re: [GTER] Bloqueio de portas
> Message-ID:
> <522c81786bb23cd2a84a72c61d029379.squirrel at cabo.dyn.arroway.org>
> Content-Type: text/plain;charset=iso-8859-1
>
>
> On Tue, March 21, 2017 13:24, Elias Andrade via gter wrote:
>> Compartilho do pensamento do Thiago e do Raul.
>> Filtrar as portas entrantes 0-1024 e se o cliente tiver necessidade,
>> aloca ele num range de IP p??blico (ou aloca 1 IP p??blico) que seja
>> liberado, pois, teoricamente, esse cliente tem conhecimento do que t??
>> fazendo.
>
> Ningu?m nasce sabendo dos perigos de morar em casa fora de condom?nio
> fechado, mas eles aprendem, certo?
>
> Reitero o problema da velocidade dos carros. E para o rapaz que falou que
> isso n?o afeta o fabricante, afeta sim. V?o dizer que o problema ? carro X
> ou Y que corre demais, que ? inseguro, etc. Brasileiro ? ?timo em colocar
> a culpa nos demais.
>
> Se essa op??o de colocar o IP p?blico e liberar as portas fosse simples,
> tipo um reles chamado na operadora. Mas como j? falaram aqui, ? criar
> dificuldade para vender facilidade. Acho estranho isso como produto, algo
> que ? direito. De ter a conex?o por completo, n?o s? o que o dono do
> provedor "entende" como sendo o certo.
>
>> Um teste simples pra quem defende porta entrante em bloco de cliente
>> residencial: suba um Mikrotik (ou Ubiquiti, telefone IP, roteador wifi
>> de baixo custo) na rede e acompanhe os logs desses equipamentos. O
>> Mikrotik ?? o primeiro que mia se estiver habilitado o DNS recursivo
>> (Allow Remote Request), o telefone IP vai tocar o dia inteiro com falsas
>> requisi????es SIP e travar a interface web e o Ubiquiti, se n??o for
>> infectado por v??rus, vai cair por "DoS".
>
> Antes da inven??o do telefone, ningu?m se preocupava com as liga??es de
> falsos sequestros. Hoje temos isso, que podemos ver como ataques ao
> portador do n?mero. V?o agora bloquear as liga??es entrantes? Ou criar um
> proxy? A defini??o de conex?o ? internet ? acessar e ser acessado. N?o
> adianta o quanto tentem disvirtuar isso.
>
>> Quando sobe-se um IP p??blico na sua rede (sem filtragem), j?? vem uma
>> penca de requisi????es em cima dele tentando explorar http, https, ssh,
>> dns etc. Liberar as portas entrantes pra todos os clientes residenciais
>> traria mais problema do que solu????o, pois poucos clientes t??m
>> conhecimento pra tratar isso em seus equipamentos (overhead urraria na
>> sua rede, o suporte de primeiro nivel de um callcenter ent??o ficaria
>> enlouquecido).
>
> Reitero, se querem fazer isso, fa?am, DEEM A DEVIDA PUBLICIDADE, e a op??o
> de quem quiser desligar isso. Tenho duas conex?es internet em casa, das
> mais lentas, e quando foram instalar ambas acharam estranho que eu queria
> o modem sem wifi. eu escolhi isso, pois queria tudo da conex?o no meu
> roteador, e nada mascarado no modem-faz-tudo-mal-feito s? pra ter um wifi
> (que tem baixo alcance, sem op??o de quase nada e com rede sem fio
> intocada do provedor).
>
> Fa?a e n?o cobre pela mudan?a, pra resolver SEU problema do 1? n?vel e
> respeitar o direito do contratante :)
>
> matheus
>
>> [ ]'s
>> Elias Andrade
>
> -- 
> "We will call you Cygnus,
> the God of balance you shall be."
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 22 Mar 2017 09:20:39 -0300
> From: Paulo Coimbra <coimbra.root at gmail.com>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
> <gter at eng.registro.br>
> Subject: Re: [GTER] Programador de EEPROM SFP/SFP+
> Message-ID:
> <CAHUiQ_XnDfb7W2w9pxD+mnxz_EfYj1oo0ObnkAK0LHdiHKGexA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Ol?,
> Usei a biblioteca WiringPi, a leitura/gravacao se d? byte a byte
> (unsigned char). A leitura est? ok. A gravacao nos bytes que preciso,
> est?o ok (a funcao int wiringPiI2CWriteReg8 (int fd, int reg, int
> data)  retorna 0==OK), por?m quando tento gravar o checksum a funcao
> retorna -1 (Erro).
> Talvez seja pelo fato de o SFP estar com a EEPROM em modo protegido?
>
> Em 22 de mar?o de 2017 04:21, Luiz Otavio O Souza <lists.br at gmail.com> 
> escreveu:
>> 2017-03-21 18:03 GMT-03:00 Paulo Coimbra:
>>> Cara, chegar at? chega, vi que ? pela DHL que entregam. S? que a parada
>>> custa 800 Trumps la fora. E se (110% de chance de ser) taxado, mais 80% 
>>> em
>>> cima, al?m de demorar (preciso com urgencia). No brasil nao achei nada
>>> interessante. Fiz um prot?tipo aqui com RPi , um pedaco velho de switch
>>> (usar o cage sfp), umas linhas de codigo, uns jumpers e alguns caf?s, 
>>> pra
>>> ver se consigo alguma coisa, ja que a comunicacao ? I2C. Ja consegui ler 
>>> e
>>> gravar uma parte, mas tem uma area q ta dando erro.
>>
>> Que comando voc? usou ? Qual o offset e tamanho do bloco ? Que erro d? ?
>>
>> Voc? sabe o modelo da eeprom que voc? esta tentando acessar ?
>>
>> As eeproms s?o acessadas em blocos, toda grava??o deve ser feita com
>> um bloco completo.  O tamanho do bloco, pagina e consequentemente dos
>> offsets mudam de acordo com os modelos e tamanhos de eeprom.
>>
>> Fora isso, existem determinados modelos que tem prote??o contra
>> grava??o tempor?ria (ativado e desativado por software) e definitivo
>> (uma vez ativado os blocos selecionados n?o podem ser reescritos).
>>
>> HTH,
>> -l
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>
>
>
> -- 
> br,
>
> Paulo Coimbra
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 22 Mar 2017 10:08:08 -0300
> From: Andre Almeida <andre at bnet.com.br>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
> <gter at eng.registro.br>
> Subject: Re: [GTER] Entrega de IPv4 Fixo /32
> Message-ID:
> <CAKAeHyFg-tP2MncwtJKTehU7gKWDMMmuarzZA05qwVP7x7tRTg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> O framed-ip no radius n?o ? o problema. Esse atributo usamos aqui para os
> demais clientes. Normal, entregamos /32 pelo tunel PPPoE.
>
> O problema ? que o IP do framed-ip vai para o tunel PPPoE, coisa que n?o
> vai direto pro cliente (no email incial eu destaquei que o cliente nao
> gostaria de fechar o tunel).
>
> O DHCP Relay que o @Bruno Cabral sugere ? interessante, pois vai isolar os
> clientes por CPE.
>
> Mas o problema ? quando esse IP ? fixo.
>
> Mas acho que estou chegando em uma solu??o.
>
>
> OBS. Algu?m aqui j? conseguiu redistribuir rotas est?ticas no OSPF do
> Mikrotik tranquilamente? Funciona quando tira a rota e habilita ela
> novamente ?
>
> Eu notei aqui que quando o t?nel cai a rota some e engra?ado (e que parece
> um bug) ? que quando o tunel volta, a rota n?o ? mais distribu?da.
> Precisa for?ar a instancia do OSPF a fechar novamente para ela passar.
> Tipo, desabilitando a interface dentro do OSPF e habilitando novamente
> Deveria ser algo dinamico. Tirou o tunel, perdeu a rota est?tica do
> framed-route, o OSPF p?ra de anunciar. Voltou o tunel, volta a rota
> est?tica do framed-route e o OSPF volta a anunciar. Mas pelo que vi s?
> funciona uma vez, depois que perder a rota ela nao volta mais a ser
> redistribu?da via OSPF, ficando somente ela est?tica no concentrador.
>
>
> Att,
>
> Andre H. de Almeida
>
>
> Em 22 de mar?o de 2017 08:17, Alan Mendes <alan at zuknet.com> escreveu:
>
>> Aqui defino o framed-ip no radius e vai tranquilo.
>>
>>
>>
>>
>>
>>
>>
>> *ZUKNET NETWORKS LTDA. MEAlan Mendes Morais*
>> *Email:* alan at zuknet.com
>> *Tel:* 15 3376-9893
>>
>>
>> www.zuknet.com
>> http://as262333.peeringdb.com
>> http://bgp.he.net/AS262333
>>
>>
>> Em 21 de mar?o de 2017 10:02, Andre Almeida <andre at bnet.com.br> escreveu:
>>
>> > Amigos, bom dia!
>> >
>> > Temos alguns clientes que possuem um servi?o um pouco diferenciado, e 
>> > que
>> > n?o querem usar PPPoE nos seus dispositivos.
>> >
>> > Mas n?o queremos desperdi?ar IPv4 nesse momento delicado fazendo 
>> > entrega
>> de
>> > /30 desnecessariamente.
>> >
>> > Pensei em alguma forma de entregar o /32 publico ao cliente.
>> >
>> > Como aqui utilizamos PPPoE para entregar o servi?o, pensei em fazer 
>> > algo
>> > diferente:
>> >
>> > 1 ) Incluir no pacote um roteador Mikrotik (como CPE) para fazer o 
>> > PPPoE
>> > (esse tunel receberia um IP Privado)
>> > 2 ) Criar um atributo de Framed-route no Radius para ao logar, criar
>> > dinamicamente no concentrador a rota do IP Publico com gateway o IP
>> Privado
>> > do PPPoE
>> > 3 ) No OSPF do Concentrador, distribuir rotas est?ticas, para 
>> > encaminhar
>> > essas rotas entregues pelo Radius ?s bordas.
>> >
>> > A partir dai, j? dava pra come?ar a pensar em entregar o IP Privado
>> > diretamente para o cliente.
>> >
>> > Pensei em separar um IP para ser gateway de todos esses clientes.
>> > Como assim? Seria o IP de gateway do cliente, ficaria vis?vel apenas
>> para o
>> > cliente. Esse IP, mesmo p?blico, poderia at? mesmo ser o IP network ou
>> > broadcast de qualquer outro segmento, pois n?o seria utilizado para
>> > destinos. Seria s? para ficar mais "bonito" do que entregar um IP 
>> > Publico
>> > com Gateway privado.
>> >
>> > E entregar um DHCP (ou dar a possibilidade de adicionar estaticamente) 
>> > um
>> > IP Publico /32 ao cliente.
>> > Dessa forma, o cliente s? usaria 1 IP e n?o 4 IPs (que acontece quando
>> > usamos um /30).
>> >
>> > O que voc?s acham? Tem alguma outra forma de fazer isso usando PPPoE
>> quando
>> > no final das contas o PPPoE nao vai direto no equipamento do cliente?
>> >
>> > Algu?m tem alguma sugest?o? V?rias cabe?as sempre pensam melhor que 
>> > uma.
>> >
>> > Obrigado
>> >
>> > Andre Almeida
>> > --
>> > gter list    https://eng.registro.br/mailman/listinfo/gter
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> gter digest list    https://eng.registro.br/mailman/listinfo/gter
>
> ------------------------------
>
> End of gter Digest, Vol 168, Issue 137
> **************************************

More information about the gter mailing list