Jefferson, 11 de setembro de 2021, CFTV Das oito câmeras IP que eu tenho funcionando em casa no momento, duas apresentaram um defeito estranho aparentemente ao mesmo tempo: uma redução no número de quadros por segundo e um retardo enorme, como se a CPU não estivesse conseguindo dar conta do processamento. A câmera do portão e a câmera da cozinha. Na da cozinha o retardo era tão grande que eu podia estar conversando com minha mãe no quarto e vê-la na cozinha ao mesmo tempo. Coisa de 30s ou mais.
O que me levou a pensar em um hack:
- Aparentemente ocorreu ao mesmo tempo;
- As câmeras estavam em pontos diferente da casa e dependiam de segmentos de rede completamente distintos;
- Problemas na rede deveriam afetar as outras câmeras;
- Essas duas eram do mesmo modelo, diferente das outras seis;
- Recentemente eu tinha resolvido relaxar minha política de negar acesso à internet para as câmeras porque estava cansado de lidar com o horário errado nas gravações.
A primeira câmera eu “consertei” aparentemente pelo uso da função “recover” que existe na interface web. Eu ainda tive que fuçar bastante até que o comportamento dela normalizasse.
Mas a segunda câmera ainda me fez apanhar por dias. Eu ia trocá-la por outra mas como isso dava trabalho eu decidi antes testar com outro cabo pelo chão, ligando a câmera a outro switch. O problema foi resolvido na hora.
Era o switch do quintal traseiro com defeito. E apesar de estar com três câmeras conectadas só criava problemas para uma.
Ainda não explica a coincidência do problema na outra câmera, mas já estou confiante de que não foi hack.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 02 de junho de 2021, CFTV, Redes Este texto pode parecer declarar o óbvio, mas é necessário para dar suporte a um texto mais longo em que estou trabalhando.
Com a popularização das câmeras de vigilância IP 4K, o fato de ser conveniente usar a infraestrutura de rede já existente para criar ou expandir seu sistema de vigilância pode criar problemas inesperados se você não ficar atento. Isso já era um problema com câmeras 1080p em empresas, mas com 4K pode virar um problema até em residências.
Segundo esta calculadora, enquanto uma câmera 1080p numa dada qualidade requer 3.5Mbps de banda, uma câmera 4K nas mesmas condições requer 18Mbps. Com apenas quatro câmeras você já precisa de 72Mbps de banda. São 72% de uma rede de 100Mbps comprometidos ininterruptamente, 24×7. E dependendo de como as coisas estiverem conectadas até para navegar na internet você vai estar limitado a 28Mbps, não importando o que você contratou com a operadora. É preciso organizar sua rede de forma que o caminho entre as câmeras e o NVR não compartilhe o mesmo segmento de rede que você precisa para acessar a internet. Usando rede gigabit você não precisa se preocupar com isso.
Observe o diagrama abaixo, que é mais apropriado para representar uma pequena empresa, mas que não está muito longe da situação na minha residência. Suponha que os switches sejam de 100Mbps.
Com o NVR ligado ao switch A, o segmento de rede F fica ocupado com um fluxo contínuo de 72Mbps, sobrando apenas 28Mbps de banda para os computadores C, D e E acessarem a internet, o servidor e o próprio NVR (playback das gravações). Note que esse é um exemplo arbitrário. Com outra combinação de equipamentos você poderia facilmente saturar os 100Mbps da sua rede. A solução mais simples para o problema do exemplo é trazer o NVR para o switch B. Assim todo o tráfego das câmeras fica restrito ao switch B e o segmento de rede F fica com 100Mbps livres. Uma segunda solução é trocar o switch B por um modelo gigabit e uma terceira seria acrescentar um switch só para as câmeras e lançar outro cabo de rede até o switch A.
Como se pode ver, é um problema contornável. Às vezes pode levar mais tempo para você se dar conta de que tem o problema do que o tempo necessário para corrigi-lo.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 09 de dezembro de 2018, CFTV Um amigo me pediu para colocar uma câmera PTZ para funcionar. Eu tenho experiência com comunicação RS485 e fazer isso funcionar deveria ser simples, mas no processo eu esbarrei em vários problemas, sendo um deles a dificuldade para compreender as opções de configuração existentes no DVR e depois como fazer a operação. Depois que você entende, percebe que é muito simples, mas o manual não ajudou em nada e eu tive quer ir por tentativa e erro. Apesar de ser um post curto eu vou deixar documentado aqui porque essa informação vai ser auxiliar para outro post que estou fazendo sobre a câmera.
O DVR que eu usei nos testes tem vários anos e é um modelo vagabundo (DVR-9318V) que comprei diretamente na China, mas muitos outros aparelhos tem uma configuração similar.
Ao entrar no Main Menu, logo aparece a opção PTZ Config:
Meu problema foi entender a distinção entre “PTZ Device” e “RS485 Device”. O que eu descobri através de experimentação é que, ao contrário do que seria intuitivo, se você está usando a porta RS485 embutida no DVR vale apenas o que está em “PTZ Device” e tudo o que está sob “RS485 Device” é ignorado.
As opções para “RS485 Device” são: NONE, AiBi, Dahua, Dahua2, GPS, General, HB5003, HangBang, Hikvision, LongYang, LongYang-D900, MeiFang, MinYang, MinYang3, PearMain, Ranging, SISO, SISO2, Takral, Transparent, Universal-CS8x, Vista, Wonwoo e eMax.
É como se o DVR suportasse conversores USB-RS485 e esse menu permitisse dizer que tipo de conversor você plugou. Entretanto isso não explica por que existem configurações separadas já que Baud rate, Data Bits, Stop Bits e Parity precisam ser idênticos no conversor e no dispositivo a ser controlado. Outra coisa que chama a atenção é que vários desses nomes são claramente de fabricantes de DVRs e câmeras e nenhum me lembra um fabricante de acessórios ou componentes de comunicação. Isso seria um meio de fazer um DVR controlar outro DVR via PTZ? Se alguém souber para que serve realmente essa parte da configuração, por favor deixe um comentário.
Mas voltando ao “PTZ Device”: nesse menu você escolhe o seguinte:
- Channel: O canal do DVR onde está o dispostivo PTZ que você está configurando;
- Protocol: O Protocolo de comunicação usado por esse dispositivo PTZ. Você vai ter que olhar no manaul do mesmo;
- Address: O endereço do dispositivo no bus RS485. Tem que ser o mesmo endereço configurado no dispositivo PTZ
- Baud Rate, Data Bits, STOP Bits e Parity: Tem que conferir com o configurado no dispositivo PTZ
Para usar o controle PTZ do DVR existe um pequeno detalhe que você precisa observar, que é óbvio, mas acaba passando despercebido quando você está enrolado com outras variáveis na configuração: O canal que você quer controlar precisa estar em tela cheia ou, se você estiver no modo de exibição múltipla, você tem que clicar com o botão direito sobre o canal que você quer controlar antes de selecionar “PTZ Control”.
Atente para o número “08” na barra superior. Esse é o canal por onde estão sendo transmitidos os comandos RS485.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 17 de janeiro de 2018, android, CFTV As versões atuais da app Viewcam do desenvolvedor Camdev, que por alguma razão agora se chama “Viewcan” (“n” no lugar de “m”), incluindo a última versão de 5 de janeiro de 2018, não funcionam. Você precisa reverter para a versão 1.4.9 de 2014 para que a app pare de fechar abruptamente segundos após iniciar.
Isso afeta especificamente DVRs fora de linha da TRX série 72. A empresa em seu site age como se essa linha nunca tivesse existido. Aliás, a TRX parece abandonar todos os produtos que deixou de vender.
Outro dia eu colocarei online minha cópia que obtive em um aparelho android que não havia sido atualizado e aproveitarei para colocar online o conteúdo do CD original, com os manuais e o instalador do cliente para Windows/IE.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 18 de novembro de 2017, CFTV, PorDentro Principais características:
- Suporte a câmeras HDCVI, IP (apenas duas) e analógicas;
- Suporte a 1HDD de até 8TB;
- Alimentação 12V;
- Acesso remoto facilitado pelo serviço de “cloud” da Intelbras, mas com suporte a acesso tradicional.
Pontos negativos
- O formato compacto faz com que os conectores estejam muito próximos e seja muito difícil plugar e desplugar câmeras individuais, requerendo o que chamam por aí de “chave extratora de BNC”;
- O DVR demora bastante a inicializar e muitas vezes você fica achando que pifou;
- O LED frontal de rede apaga quando a rede está conectada e acende quando desconectada. Os outros dois LEDs estão acesos em condições normais de uso. Se você entender a lógica me avise porque eu não consigo;
- Enche o saco dizendo que você precisa usar um HDD Western Digital Purple. Eu compreendo que um DVR abusa mais do HDD que uma aplicação normal em desktop e a série púrpura é específica para uso em DVRs mas eu ficaria menos incomodado se a Intelbras recomendasse também outros modelos, de outros fabricantes.
É importante frisar que 16 câmeras HDCVI 720p a 2Mbps cada demandam um fluxo constante de gravação de meros 32Mbps (4MB/s). Um valor baixo até para um HDD USB2.0 (23-30MB/s) e risível para um HDD SATA relativamente moderno (60-100MB/s) então o problema não é desempenho.
As fotos tem qualidade e resolução limitadas porque eu só tinha o meu Samsung A5 disponível na hora.
Os quatro maiores chips, marcados DH9920A (“DH” provavelmente vem de “DAHUA”), são receptores HDCVI. A quantidade sugere que cada um lida com 4 câmeras. Note o footprint para um conector SATA extra, ao lado dele o footprint para um flat cable e dos dois lados conectores de propósito desconhecido de 6 e 18 pinos.
O chip de RAM no centro da foto, identificado como R04D6Y6M supostamente é DDR de 4Gb (512MB) . O firmware está no chip de 8 pinos U19/U18. Abaixo e à direita da RAM temos os conectores de 4 pinos J11 e J12 que podem ser uma porta serial. Mais à direita, J13 possivelmente é para um cooler extra.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 17 de novembro de 2017, CFTV As três são tecnologias digitais concorrentes que aproveitam o mesmo cabo usado nas câmeras analógicas para transportar áudio e vídeo com uma qualidade muito superior. E as câmeras não custam os olhos da cara: você pode comprar uma câmera que suporta as três tecnologias digitais e a analógica (4 em 1) como a Intelbras VHD 1010 G3 por a partir de R$80 no Mercado Livre. E a qualidade da imagem é impressionante. Em várias situações é difícil de distinguir de uma câmera IP.
Todos os DVRs digitais suportam também câmeras analógicas por isso a troca é praticamente plug-and-play e você pode deixar para trocar câmeras apenas onde fizer diferença. Embora alguns modelos como os da Intelbras suportem apenas a tecnologia digital HDCVI, você pode encontrar vários modelos no mercado que suportam mais de uma.
A única “desvantagem” é que ao usar câmeras digitais você precisa de HDDs de maior capacidade. Um HDD de 1TB em DVR HDCVI de 16 canais da Intelbras só suporta uns cinco dias de gravação usando 16 câmeras de 720p VHD1010, que tem uma bitrate padrão de 2Mbps.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 16 de outubro de 2016, CFTV Sabe aquele desenvolvedor que tem trocentas apps para visualização de câmeras de vigilância que você não consegue diferenciar? MEye, VMEye, TMEye, VMeyeSuper, etc, etc, etc?
Várias apps dele pararam de funcionar no Android 5 e como ele parecia as ter abandonado achei que nunca iriam funcionar. Mas este mês finalmente ele começou a compatibilizar algumas. Se você precisava delas, dê uma olhada.
Aproveitando isso eu gostaria de comentar sobre o desgosto que tenho com o sistema de avaliação da Play Store. A Google faz uma modificação no Android que sai inutilizando apps no atacado e o que acontece? Os usuários que atualizaram o SO começam a dar notas negativas às apps porque deixaram de funcionar!
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 05 de setembro de 2016, CFTV, correios, IR-CUT O comércio de Recife é decepcionante por duas razões: ele obviamente não se compara ao de São Paulo em números e os poucos comerciantes que temos aqui parecem não ter descoberto a internet ainda. Eu estou há um tempão precisando comprar domos vazios para câmeras de segurança e não encontro um anúncio sequer de Recife. O mais próximo fica a pelo menos 100km daqui em Caruaru, vou ter que comprar sem ver o produto e vou ter que pagar por isso R$14 de frete.
Ontem eu decidi que preciso comprar algumas lentes de 1.9mm S-Mount. A julgar pelo Google não existem ninguém em todo o Pernambuco vendendo isso. A lente já não é barata: custa no mínimo R$19, o que parece um abuso quando você compra uma câmera inteira (com outra lente, é verdade) por R$35. Mas o que mata é o frete: R$17 para esperar no mínimo uma semana por um produto que pesa cinco gramas? E isso porque estou usando os descontos do Mercado Envios, que evaporam se eu quiser duas lentes: o frete salta para R$28 por 10 gramas no sistema louco(1) desenhado pelo Mercado Livre. E não é porque sequer R$17 seja o custo real porque sabemos que uma carta registrada custa tão baixo quanto R$4. Mas isso já é o monopólio dos Correios em ação.
Com um frete desses não dá. Pelo jeito vou ter que “bater perna” e procurar nos vendedores incompetentes de Recife.
(1) O Mercado Livre decidiu, por razões que só a ganância sabe explicar, não perguntar ao vendedor qual o peso do produto. Você diz o que quer vender e eles arbitram o quanto pesa. Sabendo que o peso mínimo de uma encomenda PAC é de 1kg, o preço sobe em incrementos de também 1kg e o seguro é de 1% do valor do produto, as práticas de cobrança de frete do Mercado Envios não fazem qualquer sentido.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 16 de agosto de 2016, CFTV, Redes, software Notas:
- “servidor” é, para a intenção deste post, uma funcionalidade de rede oferecido por um equipamento qualquer. Não estou me referindo a “um computador”, mas a aparelhos modernos conectados à rede como câmeras IP, NVRs, DVRs, modems, roteadores e media players;
- Meu interesse é descobrir senhas padrão telnet e ftp de equipamentos que possuo e minha abordagem será essa;
- O método de força bruta só é eficaz se o servidor não limitar o número de tentativas de login num determinado período de tempo. Medidas simples como bloquear o acesso do seu endereço IP por x minutos após y tentativas erradas de login já reduzem enormemente a capacidade de sucesso. Mas os equipamentos em que estou interessado geralmente não implementam qualquer proteção contra ataque de força bruta (edit: Injusto. Vários dos meus implementam medidas simples. Veja comentários);
- Qualquer comentário com perguntas onde sequer pareça que você está querendo usar isso em servidores que não estão sob sua administração será vetado.
Para quê?
Você pode pular essa parte indo direto para “NCRACK” se quiser.
Neste momento eu tenho cinco câmeras IP conectadas à rede de minha casa que tem servidor telnet embutido. O acesso telnet em equipamentos desse tipo geralmente oferece opções avançadas de diagnóstico e recuperação, como hard reset (apagamento da partição de configuração), mudança de configurações e comportamento e até backup e restauração do firmware. Este último é especialmente interessante porque minhas câmeras são genéricas, chinesas, e apesar de todas oferecerem opção de instalação de novo firmware, nenhum dos fabricantes tem sequer uma página na internet. Se o firmware de uma delas for corrompido, o único jeito de consertar é conseguindo uma igual (minhas câmeras são geralmente diferentes) para fazer uma complicada operação de desmontagem e dessoldagem para fazer uma cópia da memória flash com um gravador. Tendo um backup guardado do firmware original eu estou mais seguro.
O problema é que as câmeras tem essa funcionalidade, mas o fabricante não te diz a senha de acesso. Faz um certo sentido porque se você não souber o que está fazendo pode inutilizar a câmera (basta apagar um arquivo do bootloader) e nenhum fabricante quer essa dor de cabeça. Provavelmente a senha só é dita ao usuário pelo suporte técnico avançado quando há um problema sério ou o analista de suporte faz um acesso remoto à sua rede e com isso pode fazer o diagnóstico sem nem precisar dizer a senha. Mas…
Suporte técnico avançado?
Analista de suporte?
Suporte? Que suporte?
No final a existência desse acesso se torna uma vulnerabilidade, porque você não sabe a senha mas alguém na internet com certeza sabe. Todos esses equipamentos são baseados em Linux e o modo mais comum de obter a senha deles é, tendo acesso ao arquivo de firmware (que pode ser de uma atualização oferecida pelo fabricante), extrair o arquivo criptografado de senhas (geralmente etc/passwd) e rodar um programa de força bruta como o John The Ripper. Como o “ataque a um arquivo” não pode ser limitado como o ataque a um servidor, você testa milhares de possibilidades por segundo dependendo do poder computacional que tem disponível. E as senhas nem são tão complexas assim por isso fazendo uma pesquisa no Google você encontra diversos casos de senhas que foram descobertas “facilmente” dessa maneira.
Eu não estou particularmente preocupado com o acesso de terceiros às minhas câmeras porque eu procuro tomar medidas para que terceiros não tenham acesso fácil à minha rede, mas se eu tiver acesso não custa nada eu mudar essa senha default para dar um pouco mais de trabalho a um possível intruso. E, como eu disse anteriormente, o acesso telnet abre diversas possibilidades para o usuário avançado, incluindo mudar essa senha.
Mas já estou fugindo do assunto.
NCRACK
O Ncrack é um programa simples de linha de comando que permite fazer isso. Eu queria testar cinco câmeras e tinha uma dúzia de possíveis senhas. Parece pouco mas manualmente eu teria que fazer 5×12= 60 tentativas de login. Na décima eu já estaria tão entediado que começaria a errar a digitação (HA! Dependendo da senha eu já estou errando na primeira tentativa). Ncrack facilita muito isso porque eu pude colocar as 12 senhas (agora são 23) em um arquivo :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
|
123456 1234qwer admin adminlvjh123 antslq cat1029 h2014071 helpme hi3511 hi3516 hi3518 hiklinux juantech jvbzd klv123 OxhlwSG8 root S2fGqNFs tlJwpbo6 vizxv vizxv xc3511 xmhdipc |
E dei ao ncrack uma lista dos IPs das minhas câmeras e esse arquivo para ele tentar. A linha de comando que eu coloquei em um arquivo .bat ficou mais ou menos assim:
|
ncrack -vv -f -P ipcam.pwd --user root 192.168.10:23, 192.168.11:23, 192.168.12:23, 192.168.13:23, 192.168.14:23 pause |
No exemplo acima, “ipcam.pwd” é o nome que dei ao arquivo com a lista de senhas (uma por linha) e o usuário testado sempre será ‘root” (–user root).
Em 30 segundos (quando a lista tinha apenas 12 senhas) eu tinha as senhas de três das câmeras. As senhas das outras duas não estavam na minha lista.
Mais tarde quando acrescentei três câmeras rodei o teste de novo e consegui a senha de mais duas em menos de um minuto. Depois eu ampliei a lista de senhas para 23 e sem fazer qualquer esforço consegui obter a senha de mais uma câmera.
Se você quiser que o programa teste várias combinações de usuários e senhas pode colocar os nomes de usuários em um arquivo (um por linha) e indicar ao programa que o use, trocando o parâmetro ‘–u’ por ‘-U’ como abaixo:
|
ncrack -vv -f -P ipcam.pwd -U ipcam.users 192.168.10:23, 192.168.11:23, 192.168.12:23, 192.168.13:23, 192.168.14:23 pause |
No exemplo acima eu coloquei os usuários em um arquivo de nome ‘ipcam.users’.
Note que este é um exemplo bem simples em que eu usei uma lista especial de senhas com alta probabilidade. Ncrack tem outras opções e você pode usar listas muito maiores.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 08 de agosto de 2016, CFTV Eu tenho esse problema com três das minhas câmeras ONVIF, de um total de oito em operação. Todas do mesmo modelo rodando duas versões do firmware. As três apagam ao mesmo tempo e voltam sozinhas ao mesmo tempo. O intervalo é variável mas se eu não fizer absolutamente nada a imagem volta sozinha em 15 minutos. A primeira vez que notei o problema foi ao desligar o disjuntor #4 no quadro geral da casa. Depois notei que sempre acontecia também quando desligava o disjuntor do meu quarto (que no quadro geral está no circuito do disjuntor #7). Nenhum desses disjuntores alimentava essas câmeras. Até esse ponto eu estava pensando em um estranhíssimo problema de indução magnética. Não fazia sentido, mas era a única explicação que eu tinha.
Até que eu fui fazer manutenção na rede ethernet nos fundos da casa (as três câmeras problemáticas ficam no quintal da frente) e descobri por acaso que desconectar da rede o roteador do quintal também fazia as câmeras apagarem. E as câmeras não tinha nenhuma dependência desse roteador. Mas o roteador estava no circuito do disjuntor #4. As peças começavam a se encaixar.
Então eu fui ao meu quarto e descobri que não era desligar o disjuntor que apagava as câmeras: bastava desligar o switch do meu quarto, que também nada tinha a ver com as câmeras.
Percebeu o tamanho do abacaxi?
A única coisa que eu encontrava em comum entre o roteador no quintal dos fundos e o switch no meu quarto é que ambos eram ligados ao switch principal da casa passando por um longo eletroduto de dezenas de metros. E isso não oferecia explicação alguma já que as câmeras problemáticas são ligadas a um outro switch seguindo na direção oposta sendo que nesse switch são ligadas quatro câmeras e uma delas, de outro modelo, não apresenta problema algum.
Depois de 24h pensando ocasionalmente sobre essa bizarrice, finalmente a ficha caiu e descobri o que mais havia em comum entre o roteador do quintal e o switch do meu quarto: cada um deles era o ponto de acesso à rede de um NVR secundário (eu tenho três na casa no momento).
A explicação até agora: por um motivo que só o fabricante dessas câmeras sabe explicar, se qualquer NVR visualizando as câmeras for desligado estas apagam esperando que o NVR volte a ficar online. Se o NVR voltar a imagem volta imediatamente. Se não voltar, em 15 minutos elas voltam a responder. Não adianta tentar visualizar as câmeras por outros meios nesse intervalo. Elas aparecem na rede, mas não dão imagem. Isso cria uma preocupante vulnerabilidade porque qualquer segmento da minha rede levando a um NVR que for desligado faz com que a gravação de todas essas câmeras pare. Ainda não encontrei uma solução que não seja reduzir as possibilidades de ataque a esses segmentos e/ou distribuir as câmeras por pontos pouco importantes. Não que eu acredite que alguém vá fazer isso, mas eu sempre trato o que faço em casa como um laboratório.
Eu ainda não sei qual o hardware usado pelas câmeras. Quando eu precisar fazer manutenção em alguma delas eu aproveitarei para desmontar e analisar que possibilidade de troca do firmware eu tenho.
(Prefira clicar em "Responder" se estiver comentando um comentário)
|
|
Existe um outro problema relacionado a algo chamado “backplane bandwidth”, que é a quantidade máxima de dados que o processador de um switch pode manipular. Em teoria, um switch de 100Mbps com 8 portas permitiria que oito dispositivos trocassem dados a 100Mbps, em pares, ao mesmo tempo. Mas para isso o switch precisaria ter uma “backplane bandwidth” de 400Mbps (4 pares x 100Mbps)*. Seguindo o mesmo raciocínio, um switch de 16 portas precisaria processar 800Mbps. Na prática, eu duvido que switches baratos do tipo usado em residências e pequenas empresas sejam capazes disso, mas eu preciso testar isso há anos e sempre esqueço. O que quero dizer com isso é que é possível que com switches baratos não seja garantido que você tenha 100Mbps livres no segmento F se outras portas no mesmo switch estiverem sobrecarregadas, mas isso por enquanto é só especulação.
(*) Estou supondo que é assim que se faz a conta. Mas pode ser que seja o dobro.
Eu sempre esqueço que um dispositivo de 100Mbps, seja switch ou placa de rede, em teoria pode se comunicar a 100Mbps em cada direção, simultaneamente (modo full-duplex), totalizando 200Mbps por porta.
Me dei conta agora de que meu exemplo está errado. Supondo que mesmo um switch vagabundo operando em modo full-duplex (não tenho certeza de que todos operem) tenha 100Mbps em cada direção simultaneamente, no meu exemplo o segmento F tem um tráfego contínuo de 72Mbps do switch B para o A, mas na direção A para B ainda existem 100Mbps livres (apenas o upload fica comprometido). Para meu exemplo funcionar considerando uma rede full-duplex completamente funcional, a ligação de câmeras e NVR precisa ser invertida.