8 Dec
2015
8 Dec
'15
10:22 a.m.
Hi all,
I had configured my pdb module to accept 5 number prefixes by modifying:
In pdbt.c:
bufsize = slen + 1 + 1 + 4 + 1 + 1; // line buffer (telephone number + colon + white
space + carrier ID + newline + \0)
...
ret = snprintf(p, 7, "%d\n", node->carrier);
if (ret < 1 || ret > 6) {
And in common.h:
#define MAX_PDB_CARRIERID 99999
And i hadn't had any problem until now. I had rows in my .csv like:
0645052050;10122
And it worked. The problem I have now is with prefixes bigger than 40000. I get
segmentation fault when doiong a query with pdbt, however the pdbt build works good
without any error.
At first i thought of a buffer problem but eventhough testing with a .csv of 2 rows with
50000 prefixes will not work. Another curious effect is that for a prefix like 84238 the
server changes the answer to 18754. I dont know why...
Could anyone help me please?
Thanks.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/433
8 Dec
8 Dec
11:13 a.m.
Hi Igor,
Looking at the kamailio pdb module code I can see that it should work well for prefixes
smaller than the MAX_SHORT_INT= 32767 = 2^15-1 because:
```
typedef int16_t carrier_t;
...
struct dt_node_t {
struct dt_node_t *child[10];
carrier_t carrier;
};
```
Also I think you should try:
```
bufsize = slen + 1 + 1 + *5* + 1 + 1; // instead of your "+ 4"
```
Also the utils/pdbt/pdb_server.c is using the same int16_t for carrierid.
This can be an idea of enhancing the kamailio pdb module to be able to set the number of
prefix digits via modparam (and use uint32_t for carrierid).
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/433#issuecomment-162839566
11:20 a.m.
Hi,
Yes sorry, I had:
bufsize = slen + 1 + 1 + 5 + 1 + 1; // instead of your "+ 4"
Good point, I think you are right about the int16 limitation, I will try and let you know
hank you very much.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/433#issuecomment-162840774
11:49 a.m.
Where did you find :
typedef int16_t carrier_t;
...
struct dt_node_t {
struct dt_node_t *child[10];
carrier_t carrier;
};
In dt.h I only see:
struct dt_node_t {
struct dt_node_t *child[10];
carrier_t carrier;
};
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/433#issuecomment-162846910
12:11 p.m.
I have now made the following changes:
pdbt.c:
bufsize = slen + 1 + 1 + 5 + 1 + 1; // line buffer (telephone number + colon + white
space + carrier ID + newline + \0)
ret = snprintf(p, 7, "%d\n", node->carrier);
if (ret < 1 || ret > 6) {
common.h:
#define MAX_PDB_CARRIERID 99999
#define MAX_CARRIERID 99999
…
typedef int32_t carrier_t;
I still get no answer for prefixes bigger than 32767. I have a server with only this two
lines :
0778667682;32768
0781541867;32767
The results of 2 querys are:
processing command line parameters...
got an answer in 0.180000 ms
0778667682: not_found: comment=''
processing command line parameters...
got an answer in 0.155000 ms
0781541867:32767:unknown carrier
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/433#issuecomment-162852315
12:37 p.m.
The changes are not trivial.
You have to change to uint_32 in all the places where int_16 is used (or short int) for
the carrierid, in order to avoid conversion. This implies changes to both pdb client
(kamailio pdb module) and pdb server(see utils/pdbt folder).
Also have a look on the comunication protocol between pdb server<->client (see
utils/pdbt/docs/network_protocol.txt)
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/433#issuecomment-162857599
2:51 p.m.
I have made some progress, I can reach now 65535.
I have no pdb client module running now, it's just the server and I am testing with
pdbt:
pdbt -r XX.XX.XX.XX:10001 query 0778667682
Now I have changed the int16_t to uint32_t and the short int to uint32_t also but I get
the same result eventhough is unsigned:
pdbt.c:
bufsize = slen + 1 + 1 + 5 + 1 + 1; // line buffer (telephone number + colon + white
space + carrier ID + newline + \0)
ret = snprintf(p, 7, "%d\n", node->carrier);
if (ret < 1 || ret > 6) {
…
uint32_t carrierid;
…
carrierid=ntohs(*((uint32_t *)&(buf[reqlen]))); /* convert to host byte order */
common.h:
#define MAX_PDB_CARRIERID 99999
#define MAX_CARRIERID 99999
…
typedef uint32_t carrier_t;
My server has only this two lines :
0778667682;65535
0781541867;65536
The results of 2 querys are:
processing command line parameters...
got an answer in 0.180000 ms
0778667682: 65535: comment=''
processing command line parameters...
got an answer in 0.155000 ms
0781541867:not_found:unknown carrier
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/433#issuecomment-162885166
11:52 p.m.
You should try have a look in pdbt.c, query_udp():
```
short int carrierid;
...
short int * idptr;
```
You should try have a look in pdb_server.c, udp_server():
```
case PDB_VERSION_1:
...
short int *_id
```
Try to change all the _short int_ related to the carrier id to uint32_t (or *unsigned
int*).
For both of them, you should try to replace ntohs/htons with ntohl/htonl (see [1]).
[1] http://linux.die.net/man/3/ntohs
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/433#issuecomment-163046622
9 Dec
9 Dec
10:46 a.m.
Thank you very much!!!
That solved my issue :)
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/433#issuecomment-163165067
10:46 a.m.
Closed #433.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/433#event-486664650
10:50 a.m.
I'm glad I could help.
If you consider extending the kamailio pdb module to make the length of the prefix
configurable(e.g. via modparam) just make a pull request for it.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/433#issuecomment-163165920
3084
days inactive
3085
days old
10 comments
2 participants
participants (2)
-
igorPot -
Stefan Mititelu