Hi,
i use SQLite for storing long for some years, yesteday i decided to
extend its schema to log more fields, beside others to log tcp.seq and
i noticed negative sequence numbers in DB, eg.:
dt ip_saddr_str tcp_seq
------------------- ------------- -----------
2025-03-08 08:14:56 47.83.121.132 -1689958912
As i log the same packet to file too, it is logged as:
Mar 8 08:14:56 ... SRC=47.83.121.132 ... SEQ=2605008384 ...
I log them by two stacks:
stack=log1:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,print1:PRINTPKT,emu1:LOGEMU
stack=log1:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,mac2str1:HWHDR,sqlite3_pkt:SQLITE3
Not all are logged as negative, i collet (and pair) all yet logged:
LOGEMU SQLITE3
3489577139 -> -805390157
2446884710 -> -1848082586
2407497113 -> -1887470183
2328509367 -> -1966457929
3828861668 -> -466105628
2350061741 -> -1944905555
2605008384 -> -1689958912
2552571305 -> -1742395991
2617767003 -> -1677200293
(i don't see any pattern in it, but i am not experienced with
signed/unsigned numbers).
While investigating these tcp.seq, i noticed the same happens with
tcp.ackseq (only much less packets logged, as most are initial SYN
only).
Initially i think, that i did some mistake in schema (yes it is really
hard in SQLite :-)), but to be sure (full table schema attached):
sqlite3 ulogd.db .schema | grep tcp_seq
tcp_seq INT,
I checked, that SQLite itself is not reason, i tried to cast 2605008384
value to INT in sqlite3 shell tool and insert it into table without any
problems (in memory DB):
sqlite> SELECT CAST(2605008384 as INT);
2605008384
sqlite> CREATE TABLE test (val INT);
sqlite> INSERT INTO test VALUES (2605008384);
sqlite> SELECT * FROM test;
2605008384
It is SQLite 3.40.1 and ulogd2 2.0.8 (for now patched with ARP
attempts) on debian stable.
It is not new DB file, i migrated it from old schema (and copied old
values into new schema, previously i log 21 fields, now it is 51
fields), can it be reason? To be honest, it was my first attempt to
migrate existing SQLite table into new schema, but i don't see anything
wrong in it.
Please, what is/can be wrong?
regards
--
Slavko
https://www.slavino.sk
Attachment:
ulogd.sql
Description: application/sql
