Ir para conteúdo
  • Cadastre-se

fredericopissarra

Membros
  • Total de itens

    52
  • Registro em

  • Última visita

Reputação

47 Excellent

Últimos Visitantes

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

  1. fredericopissarra

    Converter IPv4 inteiro em xxx.xxx.xxx.xxx

    Claro, outra maneira de fazer é usando getaddrinfo(). Vantagem: suporta IPv6 tb. Desvantagens: Há tentariva de resolver nome; vários registros podem ser retornados (inclusive IPv4 mapeado em IPv6)....
  2. fredericopissarra

    Converter IPv4 inteiro em xxx.xxx.xxx.xxx

    Ao usar conversores "%d" não estão verificando se o valor é negativo ou superior a 255... Que tal: #include <stdio.h> #include <stdlib.h> #include <stdint.h> #include <inttypes.h> #include <errno.h> #include <string.h> #include <ctype.h> static int str2ip4 ( char *, uint32_t * ); int main ( int argc, char *argv[] ) { uint32_t ip; if ( ! *++argv ) { fprintf ( stderr, "Usage: %s ipv4string\n", * ( argv - 1 ) ); return EXIT_FAILURE; } if ( ! str2ip4 ( *argv, &ip ) ) { fputs ( "ERROR: Invalid IPv4 string.\n", stderr ); return EXIT_FAILURE; } // ESSA extensão (o 1$ e o 2$ nos conversores) é do GCC!!! printf ( "%1$s -> %2$" PRIu32 " (%2$#" PRIx32 ")\n", *argv, ip ); return EXIT_SUCCESS; } int str2ip4 ( char *s, uint32_t *ip ) { char *p, *q, *r, *t; int count; unsigned long n; p = strdup ( s ); // para garantir que estamos trabalhando com uma cópia // que possa ser escrita. *ip = 0; q = p; t = strchr ( q, '.' ); if ( t ) *t++ = '\0'; count = 1; while ( q ) { if ( ! isdigit ( *q ) ) { free ( p ); return 0; } r = NULL; n = strtoul ( q, &r, 10 ); if ( errno == ERANGE || n > 255 || *r ) { free ( p ); return 0; // falha! } *ip <<= 8; *ip |= ( uint8_t ) n; q = t; if ( t ) { count++; t = strchr ( q, '.' ); if ( t ) *t++ = '\0'; } } free ( p ); return count == 4; }
  3. fredericopissarra

    Comando find e suas miscelâneas

    Cobre o básico do uso de find muito bem. Eu acrescentaria um detalhe: É possível criar expressões mais complexas com o uso de \( e \) e as opções -and (que é implícita) ou -or. Por exemplo: $ find ~/videos/ -type f \( -name '*.webm' -or -name '*.avi' \) \ -exec convert2mp4.sh '{}' \; Aqui todos os arquivos encontrador a partir do diretório ~/videos/, nomeados *.webm ou *.avi, serão passados para o script convert2mp4.sh. Notar que, assim como o ';' final é "escapado", os parênteses também tém que sê-lo.
  4. fredericopissarra

    Endereço de memória

    "Quem" é o endereço vermelho? Lula?! Well... C7 45 F0 e C7 45 F4 são instruções do tipo MOV m32,imm32 C7 45 F0 61 00 00 00 mov dword [ebp-16],61h C7 45 F4 62 00 00 00 mov dword [ebp-12],62h Consulte os manuais de desenvolvimento de software para a arquitetura IA-32 da Intel, lá você encontra a lógica da montagem de instruções...
  5. 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
  6. fredericopissarra

    Aviso sobre aritmética inteira (C & ASM)

    Aviso sobre a aritmética inteira. #BitIsMyth https://wp.me/pudbF-1Bk
  7. https://bitismyth.wordpress.com/2018/09/13/minhas-tentativas-de-otimizar-o-checksum16/
  8. 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 ...
  9. 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
  10. fredericopissarra

    T50 5.8.1 disponível...

    Sorry... por algum motivo os links foram "corrompidos"... corrigi o problema! Thanks
  11. 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/
  12. 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...
  13. 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/
  14. 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);
  15. 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; }
×