ulogd2, sqlite3 and negative TCP Seq numbers

Slavko <[email protected]>
Newsgroups gmane.comp.security.firewalls.netfilter.general
Message-ID <[email protected]>
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
ulogd.sql (application/sql, 1.4 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.