[Serusers] Bug with allow_trusted ?

[Francesco Bottà]

Hi all,

maybe it's a bug in module permissions. I'm trying to use the allow_trusted function to trust my SIP/DSS-1 gateways.
Below my conf regarding module permission:

modparam("permissions", "db_url", "mysql://ser:heslo@localhost/ser")
modparam("permissions", "db_mode", 1)
modparam("permissions", "trusted_table", "trusted")

[skip]

        if (search("(User-Agent): Cisco-SIPGateway/IOS-12.x") && (allow_trusted())) {
            setflag(2);
            append_hf("P-hint:Trusted_GW\r\n");
            route(2);
            break;
        };

but SER crashed and below the backtrace of the coredump:



#0  0x0026fc32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x002ae989 in raise () from /lib/tls/libc.so.6
#2  0x002b0342 in abort () from /lib/tls/libc.so.6
#3  0x08083039 in qm_debug_frag (qm=0xbd4fb000, f=0xbd6b2e98) at mem/q_malloc.c:156
#4  0x08083425 in qm_malloc (qm=0xbd4fb000, size=20, file=0xbf0dcf "hash.c", func=0xbf0e1c "hash_table_insert", line=98)
    at mem/q_malloc.c:379
#5  0x00beb8b3 in _shm_malloc (size=20, file=0xbf0dcf "hash.c", function=0xbf0e1c "hash_table_insert", line=98) at shm_mem.h:135
#6  0x00beb04d in hash_table_insert (hash_table=0xbd6b2b80, src_ip=0xa1b6c58 "X.X.X.X", proto=0xa1b6c66 "any", 
    pattern=0xa1b6c6a "sip:[0-9]*@X.X.X.X") at hash.c:98
#7  0x00befb4a in reload_trusted_table () at trusted.c:400
#8  0x00beefd4 in init_trusted () at trusted.c:129
#9  0x00bedd33 in mod_init () at permissions.c:459
#10 0x08075260 in init_mod (m=0x8140ce4) at sr_module.c:474
#11 0x080751d8 in init_mod (m=0x8140dd4) at sr_module.c:471
#12 0x080751d8 in init_mod (m=0x8140ec4) at sr_module.c:471
#13 0x080751d8 in init_mod (m=0x8140fb4) at sr_module.c:471
#14 0x080751d8 in init_mod (m=0x81410a4) at sr_module.c:471
#15 0x080751d8 in init_mod (m=0x8141194) at sr_module.c:471
#16 0x080751d8 in init_mod (m=0x8141284) at sr_module.c:471
#17 0x080752f1 in init_modules () at sr_module.c:497
#18 0x0805d197 in main (argc=2, argv=0xbff219d4) at main.c:1553


and here other trace in debug mode:

 0(0) Number of rows in trusted table: 2
 0(0) qm_malloc(0xbd559000, 20) called from hash.c: hash_table_insert(98)
 0(0) qm_malloc(0xbd559000, 20) returns address 0xbd710de4 frag. 0xbd710dcc (size=20) on 1 -th hit
 0(0) qm_malloc(0xbd559000, 13) called from hash.c: hash_table_insert(105)
 0(0) qm_malloc(0xbd559000, 16) returns address 0xbd710e28 frag. 0xbd710e10 (size=16) on 1 -th hit
 0(0) qm_malloc(0xbd559000, 24) called from hash.c: hash_table_insert(129)
 0(0) qm_malloc(0xbd559000, 24) returns address 0xbd710e68 frag. 0xbd710e50 (size=24) on 1 -th hit
 0(0) Tuple <Y.Y.Y.Y, any, sip:[0-9]*@Y.Y.Y.Y> inserted into trusted hash table
 0(0) qm_malloc(0xbd559000, 20) called from hash.c: hash_table_insert(98)
 0(0) BUG: qm_*: prev. fragm. tail overwritten(c0c0c000, abcdefed)[0xbd710e98:0xbd710eb0]!
 0(0) qm_status (0xbd559000):
 0(0)  heap size= 33340380
 0(0)  used= 1586532, used+overhead=1801928, free=31538452
 0(0)  max used (+overhead)= 1801928
 0(0) dumping all alloc'ed. fragments:

If so, what I'm wrong with the conf?

Any suggestions??

Many thanx

Verbal