Loopabck para RJ-45

[andre_luis]

Pessoal,

Seguindo a sequencia de rotinas de testes para a placa que estou trabalhando, me veio a idéia de testar os componentes ETH pela inserção de um Loopback para RJ-45.

Mas aí, veio a pergunta : Se a placa pingar os componentes de rede, com ou sem o loopback, não vai responder ao PING de qualquer maneira ?

Se eu quizesse testar por exemplo um cabeamento extenso pelo meu Laptop, apenas colocando um loopback 50 depois, como eu faria isso ?

+++

[andre_luis]

Resolvido !!!

Se estiver conectado no loopback, responde ao PING, caso contrário, não.

+++

[polesapart]

Bicho, eu não sei o que exatamente vc está tentando e em que sistema, mas pode ocorrer que o driver de rede autocomute entre o estado up/down mediante a presença de um estado de "link" ou não. Da forma como a ethernet é constituida eletricamente, a presença deste estado implica na possibilidade de transferir dados (ao menos em um sentido, dependendo da configuração duplex), porém com ping em internet protocol/icmp (assumo que seja isto que voce tenha usado), você não pode determinar a qualidade deste link (se há perdas de dados pela relação sinal/ruído não estar adequada, ou no caso de duplex, se um dos lados não está bom).

A razão disto é que (ao menos em todas as pilhas tcp/ip que testei) um pacote destinado a uma interface local não chega ao nível físico de rede, ele é resolvido pelo nível lógico da pilha IP, que verifica que o pacote é destinado a uma interface local e redireciona os dados antes mesmo de consultar ARP ou enviar qualquer dado para o driver da placa de rede em si. O fato dela parar de responder quando o cabo é removido é porque isto interrompe o estado lógico UP da interface.

Então você pode determinar que há link, mas com ping tradicional vc não vai ter os dados de ping/pong efetivamente trafegando pelo link físico, eles estarão a nível lógico; Se o que vc precisa saber é se o cabo está dando link, ótimo, se vc precisa saber se a interface física está transmitindo e recebendo dados corretamente, especialmente se o link for duplex, o teste estará incompleto

Por que isto é feito assim? Por que em condições normais de link ethernet (leia-se sem um cabo de loopback full-duplex) a placa de rede não recebe de volta os pacotes que envia: em half-duplex o circuito receptor é desativado por quê não é muito útil vc ter de volta o pacote que está enviando, isto não serve para acnowledge de sucesso de transmissão pois não garante que o resto do circuito (seja cabo, sejam hubs ou switches) tenha entregue o pacote ao destino. E em um link full-duplex, o circuito de receiver apenas escuta os pacotes dos outros membros do barramento, e não o uplink da interface para frente.

Como o driver de rede e as pilhas de protocolos superiores não sabem que vc tem a intenção de fazer um teste de loopback, isto não é implementado desta forma

[andre_luis]

Olha,

A explicação é muito bem vinda, mas a finalidade dos testes não é de performance, mas funcional. O foco está na própria placa, mas não no cabeamento externo.

Ou seja, após a etapa de montagem, essa placa passará por uma Giga, que deverá enviar um comando de auto-teste para a placa. A placa, ao disparar um PING, terá como diagnosticar se os circuitos relacionados á Ethernet estão funcionando.

O raciocínio está correto, ou estou esquecendo algum detalhe ?

+++

[polesapart]

Bom,

Sem um loopback de verdade, você não vai ter certeza que a comunicação está operando 100% corretamente do transceiver pra frente. Se isto é relevante ou não pro nível de teste que você quer alcançar, é algo que só você pode decidir. A probabilidade de você ter algo como um curto num dos pares (se a tua interface é full-duplex) na própria placa é pequena, mas sem considerar o que levantei, não dá pra dizer que este caso foi testado empiricamente na giga de testes, pois não haverá pacotes entrando ou saindo pelo dispositivo de rede...

Eu montaria uma placa dessas, pré-testada, como parte da giga de testes, e a programaria apenas para enviar ou responder ping. Na giga de teste você a ligaria a placa em teste e verificaria se tudo está ok, na giga poderia acender um led se estivesse tendo retorno, e se tua placa for para os testes na giga já com o firmware final, vc também poderia aproveitar pra ver se ele tá pegando ip por dhcp ou seja lá que outros testes queira fazer.

Mas isto sou eu imaginando um cenário onde preferiria um falso negativo (ex. ter problema no cabo de rede da giga de testes e perder tempo com isso) a um falso negativo (colar uma etiqueta de testado no equipamento cujo transceiver tá indo virgem pro cliente final).

Certamente há casos e casos.

Abraços!

[andre_luis]

Olá pole,

Então...a placa possui 2 grandes chips em sequencia, LQFP64 e QFP48 entre o RJ45 e o uC; acredito que um para a camada física da rede, e outro para a camada lógica ( não me aprofundei, já que o firmware funciona ) e pendurado neles há ainda alguns poucos componentes passivos.

A interface com o uC é feita por SPI, e a idéia nesse teste como um todo, era saber se um comando básico de Eco (Ping) ao menos funcionaria. No chip mais próximo do uC há um registrador no qual se pode obter o status para esse comando.

A dúvida então é saber se esse Loop local testaria todas as possibilidades de problemas. Na minha opinião, suponho que seja suficiente, pois o loopback emularia outra placa, mas o que não tenho certeza é se alguma outra funcionalidade não estaria sendo testada, apenas conectando os pinos 1-6 e 2-3.

Será que isso atende ao que estou precisando ?

+++

[polesapart]

Hmm neste caso parece (teria que conferir no datasheet) que teu dispositivo ethernet tem um modo de testes próprio, e o "ping/pong" seria mesmo uma sequencia de loopback envolvendo a camada física. Se for o caso, acho que te atende tranquilo, pois na prática são só esses 2 pares que são usados, e te simplifica grandemente os testes. Tem o datasheet do bicho aí?

[andre_luis]

Aqui...

ftp://ftp.efo.ru/pub/wiznet/W3150Aplus_ ... _v2.00.pdf
( Página 19 )

Esse cara é o que fica mais próximo do uC, e interfaceia com o outro CI que implementa a interface com o conector. A única comunicação disponível com o uC é com esse aí.

+++

[polesapart]

O datasheet parece até a documentação que eu escrevo, ou seja, não diz detalha nada hahaha.

Me parece, e posso estar enganado, que este flag habilita o "pong", ou seja, se o dispositivo responde ao ping vindo da rede ou não. Se for isso, não ajuda muito, pois precisa de alguém de fora mandando o ping. Vou dar uma olhada com mais calma depois.