Autor Tópico: Problemas em grid com consulta que utilizam inet_ntoa  (Lida 201 vezes)

Alexandre Pereira Bühler

  • Expert
  • *****
  • Mensagens: 1658
  • Nunca estabeleça um teto para os seus rendimentos.
    • Simão & Bühler Ltda
    • Email
Problemas em grid com consulta que utilizam inet_ntoa
« Online: Março 31, 2016, 02:30:59 pm »
Boa tarde,
Estou fazendo algumas grids para analisar o flow do ntopng que é guardado em um banco mysql.

O banco tem a seguinte estrutura:

CREATE TABLE IF NOT EXISTS `flowsv4_0` (
  `idx` int(11) NOT NULL AUTO_INCREMENT,
  `VLAN_ID` smallint(5) unsigned DEFAULT NULL,
  `L7_PROTO` smallint(5) unsigned DEFAULT NULL,
  `IP_SRC_ADDR` int(10) unsigned DEFAULT NULL,
  `L4_SRC_PORT` smallint(5) unsigned DEFAULT NULL,
  `IP_DST_ADDR` int(10) unsigned DEFAULT NULL,
  `L4_DST_PORT` smallint(5) unsigned DEFAULT NULL,
  `PROTOCOL` tinyint(3) unsigned DEFAULT NULL,
  `BYTES` int(10) unsigned DEFAULT NULL,
  `PACKETS` int(10) unsigned DEFAULT NULL,
  `FIRST_SWITCHED` int(10) unsigned DEFAULT NULL,
  `LAST_SWITCHED` int(10) unsigned DEFAULT NULL,
  `INFO` varchar(255) DEFAULT NULL,
  `JSON` blob,
  `PROFILE` varchar(255) DEFAULT NULL,
  KEY `idx` (`idx`,`IP_SRC_ADDR`,`IP_DST_ADDR`,`FIRST_SWITCHED`,`LAST_SWITCHED`,`INFO`),
  KEY `ix_flowsv4_0_profile` (`PROFILE`)
) ENGINE=InnoDB AUTO_INCREMENT=345624 DEFAULT CHARSET=latin1

Um exemplo de linha guardada no banco:

INSERT INTO `flowsv4_0` (`idx`, `VLAN_ID`, `L7_PROTO`, `IP_SRC_ADDR`, `L4_SRC_PORT`, `IP_DST_ADDR`, `L4_DST_PORT`, `PROTOCOL`, `BYTES`, `PACKETS`, `FIRST_SWITCHED`, `LAST_SWITCHED`, `INFO`, `JSON`, `PROFILE`) VALUES
   (311, 0, 0, 3220755254, 51157, 3232235525, 80, 6, 192, 3, 1459194528, 1459194528, '', _binary 0xDA000000789C5D8D3B0E02310C05AF12A546569EB1F3A14340418758444BC505105488BBE3B76C451A8FC613F99D72CF9B9431206A5D1410B7BC4AB98576C05B30F4D7A8A07629E20C8090BD0459408D5963A20730572614CA95B20161CD7856AC603E30CC75FE867FE3CD87871C82C2B7281E2A526C51A7ED34DDAE87F3FEB8BBC4E6F978DDD3E70BCEDB29CA, '')

Como podem ver temos os campos IP_SRC_ADDR e IP_DST_ADDR que são guardado como uma string ASCII
Para tornar isto legível aos humanos tenho que usar a função inet_ntoa que converte um (IPv4) endereço de rede de Internet em uma string ASCII no padrão da Internet formato decimal com ponto.

Os campos FIRST_SWITCHED e LAST_SWITCHED são timestamp unix. Também tenho que usar a função FROM_UNIXTIME para tornar legível ao humanos.

O campo json está comprimido então tenho que usar uncompress.

Como exemplo de select tenho este aqui:

SELECT
idx,
VLAN_ID,
L7_PROTO,
inet_ntoa(IP_SRC_ADDR),
L4_SRC_PORT,
inet_ntoa(IP_DST_ADDR),
L4_DST_PORT,
PROTOCOL,
BYTES as TRAFEGO,
PACKETS,
FROM_UNIXTIME(FIRST_SWITCHED),
FROM_UNIXTIME(LAST_SWITCHED),
INFO,
uncompress(JSON),
PROFILE
FROM
flowsv4_0
WHERE inet_ntoa(IP_SRC_ADDR)='xxx.xxx.xx.xx'
ORDER BY TRAFEGO DESC

Na grid os campos IP_DST_ADDR e IP_SRC_ADDR são apresentados no padrão xxx.xxx.xxx.xxx graças a função inet_ntoa da consulta.

Mas no quicksearch se faço uma busca pelo ip no formato xxx.xxx.xxx.xxx ele não acha nada. Somente se faço a consulta com o ip no formato string ascii  ele retorna dados. Não era para ele obedecer a consulta sql e procurar no formato xxx.xxx.xxx.xxx?
Este comportamento é um bug?
« Última modificação: Março 31, 2016, 02:38:58 pm por Alexandre Pereira Bühler »
--
Alexandre Pereira Bühler
https://www.simaoebuhler.com.br
Hospedagem compartilhada Scriptcase desenvolvimento e produção. Temos servidores dedicados Scriptcase.
Eu RTFM todo dia e você?