pfSense

/usr/local/etc/raddb/users

"bob" Cleartext-Password := "password" 

    WISPr-Bandwidth-Max-Up := 100000,
    WISPr-Bandwidth-Max-Down := 100000,
    pfSense-Max-Total-Octets := 104857600,

    Exec-Program-Wait = "/bin/sh /usr/local/etc/raddb/scripts/datacounter_auth.sh bob daily" 

And from the captive portal sqlite db:

sqlite> PRAGMA table_info(captiveportal);
0|allow_time|INTEGER|0||0
1|pipeno|INTEGER|0||0
2|ip|TEXT|0||0
3|mac|TEXT|0||0
4|username|TEXT|0||0
5|sessionid|TEXT|0||0
6|bpassword|TEXT|0||0
7|session_timeout|INTEGER|0||0
8|idle_timeout|INTEGER|0||0
9|session_terminate_time|INTEGER|0||0
10|interim_interval|INTEGER|0||0
11|traffic_quota|INTEGER|0||0
12|bw_up|INTEGER|0||0
13|bw_down|INTEGER|0||0
14|authmethod|TEXT|0||0
15|context|TEXT|0||0
sqlite> select * FROM captiveportal;
1672755621|2000|172.21.60.135|88:d8:2e:42:f0:9f|bob|9f38eaac218e0cea||||||104857600|0|0|radius|first
sqlite>

I'm not obviously seeing the error here. 100MB = 104857600 Bytes

It would appear the sessions being logged out prematurely would be caused by a bug after reading the value back from the db, as it appears that the correct value is inserted into the db.

Maybe we should pass this one to Reid as he handled https://redmine.pfsense.org/issues/13418

This smells to me like your user authenticated and then you modified the user's traffic quota. The quota in the database is only set when the user logs in and is not updated asynchronously. Can you confirm if this is what happened?

I've tested with a 10GB quota:

[2.7.0-DEVELOPMENT][root@pfSense.home.arpa]/var/db: sqlite3 captiveportaltest.db
SQLite version 3.39.3 2022-09-05 11:02:23
Enter ".help" for usage hints.
sqlite> select * from captiveportal;
1672963506|2000|192.168.60.101|58:9c:fc:09:8f:ea|test|ea20051786b85fae|dGVzdA==|||||10737418240|0|0|radius|first

php > var_dump(captiveportal_read_db());
array(1) {
  [0]=>
  array(32) {
...
    [11]=>
    int(10737418240)
    ["traffic_quota"]=>
    int(10737418240)
...
  }
}

The value in the sqlite db and the value unmarshalled by the php sqlite3 library are the same.

Ok, I misunderstood the actual problem here, which is that the database record is having the wrong value inserted. It's due to 32-bit integer limitations in the PECL radius library, I believe:

>>> hex(10485760000);
'0x271000000'
>>> 0x71000000
1895825408

According to the RFCs, integers types are all 32 bits, period. To support larger limits we'll need to have an alternative attribute type for lower granularity (pfSense-Max-Used-MB e.g.), use a string attribute type, or add an additional max octets high word for 64 bit values and do the appropriate work for splitting and recombining 64 bit values. Regardless, I don't think we want to alter the existing vendor unique type we've defined as pfSense-Max-Used-Octets, as that is a highly disruptive change and breaks backward compatibility.