Ir para conteúdo
  • Cadastre-se

fredericopissarra

Membros
  • Total de itens

    48
  • Registro em

  • Última visita

Reputação

44 Excellent

Últimos Visitantes

O bloco dos últimos visitantes está desativado e não está sendo visualizado por outros usuários.

  1. fredericopissarra

    Livros de programação em C

    Um complemento interessante: 21st Century C https://is.gd/D4FVXs Secure Programming in C https://is.gd/9Tdhfz []s Fred
  2. fredericopissarra

    Aviso sobre aritmética inteira (C & ASM)

    Aviso sobre a aritmética inteira. #BitIsMyth https://wp.me/pudbF-1Bk
  3. https://bitismyth.wordpress.com/2018/09/13/minhas-tentativas-de-otimizar-o-checksum16/
  4. fredericopissarra

    Um provável problema com o TCPDUMP

    Algumas placas de rede permitem que certas operações corriqueiras em hardware. É o caso do cálculo do checksum dos pacotes IP. O termo técnico para isso chama-se offloading. A ideia é a de que o que está "fora da carga" é o tempo de processamento, que é deslocado do driver/kernel para o hardware. Isso é particularmente importante nesses tempos de redes Gigabit e de fibra-ótica.... O problema ao qual me refiro aqui é no relatório do utilitário TCPDUMP (e seu irmão gráfico Wireshark) onde, com determinadas "placas de rede" aparece o aviso de que o checksum não é válido. Isso provavelmente acontece porque o TCPDUMP tenta recalcular o checksum que foi já calculado por hardware. Essa probabilidade aumenta quando realizamos o experimento de capturar o mesmo pacote enviado, por um lado, e recebido por outro, em máquinas diferentes... Esse experimento foi conduzido com conhecidos meus, especialistas em redes, que demonstrou que o pacote recebido tinha, de fato, checksum válido, mas o TCPDUMP reporta a invalidade apenas no pacote enviado. De fato, a manpage do TCPDUMP nos avisa disso via opção --dont-verify-checksum. Para essa opção temos o seguinte texto: Para determinar se sua "placa" usa o recurso de offloading, podemos usar o utilitário ethtool. Eis os dados de minha interface de rede: $ ethtool -k enp3s0 Features for enp3s0: rx-checksumming: on tx-checksumming: off tx-checksum-ipv4: off tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: off tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] scatter-gather: off tx-scatter-gather: off tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: off tx-tcp-segmentation: off tx-tcp-ecn-segmentation: off [fixed] tx-tcp-mangleid-segmentation: off tx-tcp6-segmentation: off udp-fragmentation-offload: off generic-segmentation-offload: off [requested on] generic-receive-offload: on large-receive-offload: off [fixed] rx-vlan-offload: on tx-vlan-offload: on ntuple-filters: off [fixed] receive-hashing: off [fixed] highdma: on [fixed] rx-vlan-filter: off [fixed] vlan-challenged: off [fixed] tx-lockless: off [fixed] netns-local: off [fixed] tx-gso-robust: off [fixed] tx-fcoe-segmentation: off [fixed] tx-gre-segmentation: off [fixed] tx-gre-csum-segmentation: off [fixed] tx-ipxip4-segmentation: off [fixed] tx-ipxip6-segmentation: off [fixed] tx-udp_tnl-segmentation: off [fixed] tx-udp_tnl-csum-segmentation: off [fixed] tx-gso-partial: off [fixed] tx-sctp-segmentation: off [fixed] tx-esp-segmentation: off [fixed] fcoe-mtu: off [fixed] tx-nocache-copy: off loopback: off [fixed] rx-fcs: off rx-all: off tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: off [fixed] l2-fwd-offload: off [fixed] hw-tc-offload: off [fixed] esp-hw-offload: off [fixed] esp-tx-csum-hw-offload: off [fixed] rx-udp_tunnel-port-offload: off [fixed] Repare nas opções rx-checksumming e tx-checksumming. No meu caso, meu NIC (Network Interface Controller) não realiza o checksum para pacotes enviados por hardware (tx-checksumming está em off), Minha interface é meio fraquinha (100BaseT) e talvez, por isso, não permita uma grande quantidade de recursos offloading (exceto pelo cálculo do checksum dos pacotes entrantes e outros detalhes, como rx-vlan-offload e tx-vlan-offload.... Note também que certos recursos não podem ser modificados (são "fixados" pelo NIC). Mas tenho acesso a redes mais rápidas e com NICs com offloading habilitado e o "erro" do checksum de fato acontece como citei... No caso de redes não Gigabit e/ou de fibra-ótica, pode-se desabilitar completamente o offloading do checksum via: $ ethtool -K enp3s0 rx off tx off A opção é "maiúscula" para distinguir a escrita da leitura das opções. Consulte a manpage de ethtool para ver as opções.... Aliás... quando você instala o pacote ethtool, e seu host configura a interface de rede via /etc/network/interfaces, você pode colocar essas opções na própria configuração da interface. Por exemplo: ... iface eth0 inet static address 192.168.1.5 netmask 255.255.255.0 gateway 192.168.1.254 offload-tx off # Extensão do ethtool offload-rx off # Extensão do ethtool ...
  5. fredericopissarra

    T50 5.8.2

    Novamente a rotina cksum() está errada... Corrigida na versão 5.8.2, disponível em: https://sourceforge.net/projects/t50/ https://gitlab.com/fredericopissarra/t50
  6. fredericopissarra

    T50 5.8.1 disponível...

    Sorry... por algum motivo os links foram "corrompidos"... corrigi o problema! Thanks
  7. fredericopissarra

    T50 5.8.1 disponível...

    Alguns poucos bugfixes e a nova feature de mostrar estatísticas no final do processo (experimental), disponível no T50 versão 5.8.1: https://gitlab.com/fredericopissarra/t50 https://sourceforge.net/projects/t50/
  8. fredericopissarra

    Dúvida requisição HTTP

    Você pode verificar isso com o TCPDUMP: $ sudo tcpdump -i eth0 -nv port 53 ... Digite uma url no broser e veja o que dá... termine com Ctrl+C Pegue o IP da url: $ dig url ... Execute o TCPDUMP de novo, vá no browser e digite o IP...
  9. fredericopissarra

    Problemas com requisicoes http em C

    Por que está criando um segundo file descriptor para um segundo socket? Recomendo baixar e ler: https://beej.us/guide/bgnet/
  10. fredericopissarra

    keygenme em C - aula 17 CERO

    Quatro detalhes... linha 20 (return NULL) é o que está causando o aviso (main espera retornar int, não char *); Segundo... getline() aloca o buffer automaticamente se o ponteiro for NULL (como é o caso) e o tamanho for 0. Note que você passa o ponteiro para o ponteiro e um ponteiro para o tamanho porque eles serão atualizados pela função - Ou seja, esse malloc() ai é desnecessário e, no contexto, ERRADO; Terceiro: É interessante livrar-se do buffer alocado com free() antes de sair do processo (embora o encerramento vá fazer isso por você); Quarto... O loop estava correto (talvez você estivesse atualizando buffer e ai estivesse o erro. Eu o substituiria por: for (char *p = buffer; *p; p++) *p = toupper(*p);
  11. fredericopissarra

    keygenme em C - aula 17 CERO

    scanf() recebe, no caso do conversor %s, o ponteiro do buffer que receberá os caracteres... Ele não alocará o buffer pra você. Se você não sabe o tamanho do buffer ou não quer "gastar" espaço à toa, recomendo o uso de getline(): // Devolve ponteiro contendo a string lida ou NULL se houve algum erro. // OBS: O buffer precisará ser liberado com free(), na rotina chamadora para não causar // memory leakage. char *getstring(void) { char *p = NULL, *q; size_t size = 0; if ( getline( &p, &size, stdin ) == -1 ) return NULL; // Livra-se do \n no final... if ( q = strchr( p, '\n' ) ) *q = '\0'; return p; }
  12. fredericopissarra

    sniffer

    Obtenha a documentação da python-libpcap (ou, simplesmente da libpcap)... Ela é bem interessante,mas mexer com RAW sockets sempre é dependende de platafforma... Tive esse problema ao tentar portar o T50 para o Windows, o FreeBSD e o MacOS...
  13. fredericopissarra

    Chamada de testes para o pev v0.81

    Outra coisa interessante é usar a função strdupa() ao invés de strdup()... A primeira usa alloca() e livra-se do buffer, alocado na pilha, asim que a função sair do escopo...
  14. fredericopissarra

    sniffer

    Dê uma olhada em 'man 7 packet' para a combinação AF_PACKET, SOCK_RAW e ETH_P_ALL para a syscall socket().
  15. fredericopissarra

    Carregando

    Hehehehe... eu uso o ponteiro do mouse!
×