Re: [REQ] UAProf suppport
Hi Paul, Paul Keogh schrieb: our REFPOOL tests are doing well. Handset manufacturers claim the lack of UAProf support within Kannel. Is there any more details about these claims - ie. what exactly are they claiming is missing ? now basically they complain that Kannel does not check the UAProf profile of a device and hence does not recognize that certain mime-types can or can't be accepted by the device. Can someone please check if UAProf is a mandatory feature for WAP 1.2.1 (jun)? Is there anyone interested to pick this issue up and work on it? The Profile, Profile-Diff and Profile-Warning HTTP headers are all defined, as is the uaprof content type in WSP 1.2.1. Is the question what the gateway should do with this information, other than pass it on to the HTTP server ? yes, I guess UAProf is not only about passing the information. It is also about dealing with it in terms of allowing to modify mime-types to fit the needs of the device. Or am I wrong here? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Kannel SMPP interface !
Aarno Syvänen wrote: You mean making cvs modules located in different machines ? no, I'd like to have the current gateway cvs module as the base component and add-ons (ie. smppbox, emibox, mmsbox) to be extendable to the gateway source. Basically something similiar as the Apache guys did with their APR (apache portable runtime). Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Kannel SMPP interface !
Alex Judd wrote: No, I think Stipe's on about the discussions to build a more module based build with bearerbox forming the core - ie. - smsbox - wapbox bearerbox - smppbox - etc. if we split the modules out a little cleaner like this, then you can checkout just the base and the module you want. It shouldn't be a big job, just need to freeze a cvs branch while someone starts it would be my thoughts. It would be a good incentive to get Wapme to let loose the smppbox they've got chained there :) yep, it's waiting to be freed! ;)) same with mmsbox (our MMSC implementation). Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Problem about wavecom configuration
Hi all, I can not send sms by using wavecom with kannel. Now I use cygwin + window2000 and run bearerbox from kannel with this configuration : group = core admin-port = 13000 smsbox-port = 13001 admin-password = bar status-password = foo admin-deny-ip = *.*.*.* admin-allow-ip = 127.0.0.1 log-file = /tmp/kannel.log log-level = 0 box-deny-ip = *.*.*.* box-allow-ip = 127.0.0.1 unified-prefix = 00358,0 access-log = access.log store-file = kannel.store #ssl-certkey-file = mycertandprivkeyfile.pem # SMSBOX SETUP group = smsbox bearerbox-host = localhost sendsms-port = 13013 global-sender = 13013 sendsms-chars = 0123456789 +- log-file = /tmp/smsbox.log log-level = 0 access-log = access.log # SEND-SMS USERS group = sendsms-user username = jap password = smskiller #user-deny-ip = user-allow-ip = 127.0.0.1 max-messages = 2 concatenation = true # this sender is for Kannel relay testing (http_smsc) group = sendsms-user username = kannel password = rL4y user-deny-ip = *.*.*.* user-allow-ip = 127.0.0.1 # SERVICES group = sms-service keyword = www text = You asked nothing and I did it! catch-all = true # this service is for Kannel relay testing, when this Kannel # works as relay gateway group = sms-service keyword = relay get-url = http://localhost:13013/sms?user=kannelpass=rL4yfrom=%pto=%Ptext=%r; max-messages = 2 concatenation = true # there should be default always group = sms-service keyword = default get-url=http://localhost:13013/sms?user=jappass=smskillerfrom=%pto=%Ptext=%r; max-messages = 2 concatenation = true text = No service specified group = smsc smsc = at2 modemtype = wavecom device = /dev/ttyS1 speed = 9600 ## modems.conf ## group = modems id = wavecom name = Wavecom detect-string = WAVECOM The bearerbox stop with the message look like this ... 2003-06-19 18:31:40 [6] DEBUG: AT2[/dev/ttyS1]: device opened 2003-06-19 18:31:40 [6] INFO: AT2[/dev/ttyS1]: init device 2003-06-19 18:31:40 [6] INFO: AT2[/dev/ttyS1]: speed set to 9600 2003-06-19 18:31:40 [6] DEBUG: AT2[/dev/ttyS1]: -- AT^M I think it occure some problem about my configuration, Does anybody can help me ? kannel log look like this 2003-06-19 18:31:40 [0] INFO: Added logfile `/tmp/kannel.log' with level `0'. 2003-06-19 18:31:40 [0] INFO: Started access logfile `access.log'. 2003-06-19 18:31:40 [0] DEBUG: Started thread 1 (gw/bb_store.c:store_cleanup) 2003-06-19 18:31:40 [0] DEBUG: HTTP: Opening server at port 13000. 2003-06-19 18:31:40 [0] DEBUG: Started thread 2 (gwlib/fdset.c:poller) 2003-06-19 18:31:40 [0] DEBUG: Started thread 3 (gwlib/http.c:server_thread) 2003-06-19 18:31:40 [0] DEBUG: Started thread 4 (gw/bb_http.c:httpadmin_run) 2003-06-19 18:31:40 [0] DEBUG: starting smsbox connection module 2003-06-19 18:31:40 [0] DEBUG: Started thread 5 (gw/bb_boxc.c:smsboxc_run) 2003-06-19 18:31:40 [0] INFO: AT2[/dev/ttyS1]: configuration shows modemtype wavecom 2003-06-19 18:31:40 [0] DEBUG: AT2[/dev/ttyS1]: Reading modem definitions from gsmmodem.conf 2003-06-19 18:31:40 [0] DEBUG: AT2[/dev/ttyS1]: Found 1 modems in config 2003-06-19 18:31:40 [0] INFO: AT2[/dev/ttyS1]: read modem definition for Wavecom 2003-06-19 18:31:40 [0] DEBUG: Started thread 6 (gw/smsc/smsc_at2.c:at2_device_thread) 2003-06-19 18:31:40 [0] DEBUG: Started thread 7 (gw/bb_smscconn.c:sms_router) 2003-06-19 18:31:40 [0] INFO: 2003-06-19 18:31:40 [0] INFO: Kannel bearerbox II version 1.2.1 starting 2003-06-19 18:31:40 [6] INFO: AT2[/dev/ttyS1]: opening device 2003-06-19 18:31:40 [6] DEBUG: AT2[/dev/ttyS1]: device opened 2003-06-19 18:31:40 [7] DEBUG: sms_router: time to sleep 2003-06-19 18:31:40 [0] INFO: Loading store file kannel.store 2003-06-19 18:31:40 [0] INFO: Store-file size 0, starting to unpack 2003-06-19 18:31:40 [0] INFO: Retrieved 0 messages, non-acknowledged messages: 0 2003-06-19 18:31:40 [0] INFO: MAIN: Start-up done, entering mainloop 2003-06-19 18:31:40 [0] DEBUG: AT2[/dev/ttyS1]: start called 2003-06-19 18:31:40 [7] DEBUG: sms_router: list_len = 0 2003-06-19 18:31:40 [6] DEBUG: AT2[/dev/ttyS1]: device opened 2003-06-19 18:31:40 [6] INFO: AT2[/dev/ttyS1]: init device 2003-06-19 18:31:40 [6] INFO: AT2[/dev/ttyS1]: speed set to 9600 2003-06-19 18:31:40 [6] DEBUG: AT2[/dev/ttyS1]: -- AT^M Thanks so much Jap _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
[RFC] changing defaults of SMPP TON and NPI for MT?
Hi list, I'd like to have a quick voting for chaning the current defaults settings for the SMPP module for the TON and NPI values. Currently we have: /* setup default values */ pdu-u.submit_sm.source_addr_ton = GSM_ADDR_TON_NATIONAL; /* national */ pdu-u.submit_sm.source_addr_npi = GSM_ADDR_NPI_E164; /* ISDN number plan */ pdu-u.submit_sm.dest_addr_ton = GSM_ADDR_TON_NATIONAL; /* national */ pdu-u.submit_sm.dest_addr_npi = GSM_ADDR_NPI_E164; /* ISDN number plan */ I'd like to change to: pdu-u.submit_sm.source_addr_ton = GSM_ADDR_TON_INTERNATIONAL; pdu-u.submit_sm.dest_addr_ton = GSM_ADDR_TON_INTERNATIONAL; please votes and comments. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Fw: Incorrect Validity Time
Hi Patrick, my GSM provider has requested to to put the Validity flag to 8 hours. we did it but aftter about 10 hours the SMSC started to have these errors PROVIDER ERROR MESSAGE 06/06 18:52:32 AMP:uac_amppdu001 trace AMP PDU Trace, SMPP: Incorrect Validity Time: 030607030006076+ 06/06 18:52:32 AMP:uac_amppdu001 trace AMP PDU Trace, SMPP: Incorrect Validity Time: 030607030006076+ 06/06 18:52:32 AMP:uac_amppdu001 trace AMP PDU Trace, SMPP: Incorrect Validity Time: 030607030006076+ 06/06 18:52:32 AMP:uac_amppdu001 trace AMP PDU Trace, SMPP: Incorrect Validity Time: 030607030006076+ 06/06 18:52:32 AMP:uac_amppdu001 trace AMP PDU Trace, SMPP: Incorrect Validity Time: 030607030006076+ 06/06 18:52:32 AMP:uac_amppdu001 trace AMP PDU Trace, SMPP: Incorrect Validity Time: 030607030006076+ in the sms box log file we get a error response_sm 0X012 which i belive is a reserved message.. what could it be? why do the times on bith servers need to be in sync? the error you quote can't be inside smsbox log. You may meen bearerbox's log? Can you provide us a log extract of it?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Strange smsbox/bearerbox problem : SMS messages not being sent
Rory Campbell-Lange schrieb: Thanks very much for your message, Stipe. Upon enquirey it appears that the target SMPP host only allows 6 messages a second to pass through on our service. I was trying to send 150 messages in less than a second! yeah, Kannel performs very well ;)) I've slowed down the sending system. However, is there a way of throttling the number of messages sent in a second or automatically retrying requeued messages when sending clients try to send too many messages in a few moments? not directly in the SMPP module. There is an implementation inside the EMI/UCP module. This is definetly a issue for the SMSCConn abstraction layer. Bruno and Angel, are you guys agree'ing? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: FW: Updated Charset.c with greek Alphabet 7-bit encoding
Andreas Fink wrote: will probably mean it works in greece but breaks compatibility in other countries. I vote -1 for this patch as is. Proper implementation of greek has to be made different. ISO-8859-1 is also not appropriate so there's more to this. ok, these are serious concerns from Andreas. Is there a chance that we can use iconv for the mapping?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [RFC] changing defaults of SMPP TON and NPI for MT?
Alexander Malysh schrieb: Hi Stipe, -1 from me. How do you want recognize national numbers? International numbers can be simple detected. They have '+' in front and then we set ton to international and remove the plus. hmm, so you *require* users to send to=%2b49xxx at sendsms HTTP interface. If someone sends to=49xxx then it will be send with national TON. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Strange smsbox/bearerbox problem : SMS messages not being sent
Alexander Malysh wrote: hmm, sleep is very bad (imho). In this sleep time you can maybe handle 100 delivery receipts instead just sleeping. It would be great to add abstracted bandwidth calculation code to kannel and then send only if bandwidth allow this. so sleeping makes only sense if the MT sending thread can be send to sleep and the MO thread yields for the CPU and the connection. If the modules use *one* thread for MT and MO, then sleeping is sort of a problem, that's right. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
[FYI] recent CIMD2 patch commited, please check
Hi list, I have commited now: 2003-06-19 Stipe Tolj [EMAIL PROTECTED] * gw/smsc/smsc_cimd2.c: fixed a bug inside CIMD2 module. Thanks to Per Skaglund [EMAIL PROTECTED] for the patch. [Msg-ID: [EMAIL PROTECTED]] if you run CIMD2 connections, please update your local CVS tree and try this. If there are problems please shout. Angel, any chance you can give this a quick try? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Strange smsbox/bearerbox problem : SMS messages not being sent
Alexander Malysh [EMAIL PROTECTED] wrote: Hi Bruno, Am Donnerstag, 19. Juni 2003 16:03 schrieb Bruno Rodrigues: Stipe Tolj [EMAIL PROTECTED] wrote: Bruno Rodrigues wrote: You need to sleep right after sending the message for it to work. We can have configuration code in smsccon abstraction and only that usleep inside smsc_* modules. why not having the whole throttling mechanism inside the abstracted layer? This would also help in AT2 module, because most GSM modems don't like be hit by 100 msg/sec. ;) If I'm not mistaken, EMI has a list feed by SMSConn or something and smsc_emi reads it and feeds it into smsc, so you can't sleep before filling that list, you have to sleep right after sending the message (in emi case, sleep AFTER receives ack) to take in consideration received messages and other particularities. As I told, sleep is one line, just copy/paste it into every module in the right place and move microsecond calculation and config file processing to smscconn. hmm, sleep is very bad (imho). In this sleep time you can maybe handle 100 delivery receipts instead just sleeping. It would be great to add abstracted bandwidth calculation code to kannel and then send only if bandwidth allow this. EMI uses one thread for sending and another for receiving. This latter sends itself ACKs by managing locking with send thread. In this case, its ok to sleep in sending thread because it won't affect receiving one. I even once needed something to limit incoming messages because I was receiving more messages than the other java service could handle, and store.lock was growing madly with mt-reply messages. If we have some kind of throthling in input, we can let them stay in smsc queue instead of kannel queue. Maybe a automatic throtling in smsc if queue-out larger than something. I don'tknow...
Re: Bug in log.c
a) change gwthread code to use the freed slot ID number instead of incrementing. So we will never have a thread id above 1024 (which is the hard thread limit). b) thing how we can map the thread to the exlusive log file to be honest I'd like to pick a), because b) should be pretty fast because the logging functions are called a lot on high-load systems, so this has to be very fast and array lookups are pretty fast. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Strange smsbox/bearerbox problem : SMS messages not being sent
Rory Campbell-Lange wrote: The only error codes I'm getting are: 2003-06-06 20:42:53 [8] ERROR: SMPP[orangelong]: SMSC returned error code 0x0045 in response to submit_sm. according to SMPP specs this is considered to be a *general* error for a submit_sm PDU. (seee SMPP v3.4, p. 113). Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Bug in log.c
imho there is no point logging each _thread_ into separate file... maybe instead logging thread _types_ into separate files? then , mapping can be made on thread name instead of id... Stipe Tolj wrote: ok, so we have 2 alternative here: a) change gwthread code to use the freed slot ID number instead of incrementing. So we will never have a thread id above 1024 (which is the hard thread limit). b) thing how we can map the thread to the exlusive log file any ideas?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Kannel SMPP interface !
Hi At 01:53 PM 6/8/03 +0200, Stipe Tolj wrote: yes there is. We at Wapme have those beasts arround here still in cages ;) yeah.. ditto... So could some people *please* think of how to handle configure/make of external cvs modules with the gateway cvs module as base core. Here is a very rough idea.. How about keeping it simple. for the SMSC/bearerbox end - a config file that specifies a smsc_type, and the entry function names and a .so that we can use dlopen to load. eg for smpp it could look like this group=smsc_module smsc_type=smpp so_file=smsc_smpp.so smsc_create=smsc_smpp_create Then for the smsbox end. These are essentially standalone apps that connect to Kannel via bearerbox and send messages. So I think we should split the gw directory again, much like we split of gw/smsc kannel/gwlib kannel/gw kannel/smsc kannel/boxes/smsbox : split out the smsbox kannel/boxes/wapbox : split out the smsbox ... Then the add on boxes can fit into there own kannel/boxes/foobar directory, or even in a totally separate tree. One could even supply binaries (though hopefully not) of boxes, or build Kannel support into commercial apps using libs other than gwlib. The configure/make can work just like smsbox, wapbox etc do now. When and as new front end modules get added we can add --with-smpp --with-emi --with-apachemod. Nisan Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Bug in log.c
a hard limit to reach in normal life - but can still become an issue if someone is trying to crash the machine... for example, opening 2000 concurrent connections to the machine from the outside will pass the 1024 barrier without any problem... Stipe Tolj wrote: a) change gwthread code to use the freed slot ID number instead of incrementing. So we will never have a thread id above 1024 (which is the hard thread limit). b) thing how we can map the thread to the exlusive log file to be honest I'd like to pick a), because b) should be pretty fast because the logging functions are called a lot on high-load systems, so this has to be very fast and array lookups are pretty fast. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
RE: Bug in log.c
Hi All,
Found a solution that I think should be ok.
In the gwthread-module the table is size 1024.
While the thread number may increase byond it the
id is a modulo of 1024 and so the modulo can be
used in the log.c to prevent the prior mentioned
problem.
suggested fix would be to use following:
if ((e = thread_to[(gwthread_self()%1024)])) {
Have tested this and appears to work.
Sorry for not spotting this earlier.
Kindest Regards,
Michael.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Stipe Tolj
Sent: 19 June 2003 17:04
To: Nisan Bloch
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Bug in log.c
Nisan Bloch schrieb:
Hi
We run into this all the time with out SMPP server. Threads
are spawned for
new ESME connections and terminated on disconnect. Some of our users
connect and disconnect very regularily and the thread-id
often goes over
1024. This however means quite a few changes to the way the
log stuff
currently works. We may have to use a list instead of an array.
hmmm, list are *slow* compared to a fixed array.
You have to keep in mind that the logging functions are caller
*really* a lot of times anywhere in the code, so the mapping has to be
as fast as possible.
Is there any concern in changing gwthread-pthread.c code in cycling
between 1-1024 for the thread_ids instead of incrementing?!
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf
Tel: +49-211-74845-0
Fax: +49-211-74845-299
E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are
Re: Bug in log.c
Hi,
Am Donnerstag, 19. Juni 2003 18:36 schrieb Stipe Tolj:
Michael Mulcahy schrieb:
Hi All,
Found a solution that I think should be ok.
In the gwthread-module the table is size 1024.
While the thread number may increase byond it the
id is a modulo of 1024 and so the modulo can be
used in the log.c to prevent the prior mentioned
problem.
suggested fix would be to use following:
if ((e = thread_to[(gwthread_self()%1024)])) {
Have tested this and appears to work.
how about having this inside gwthread-pthread.c as function:
/* Return the threadtable sloot this thread is using. */
long gwthread_table_slot(void)
{
return (gwthread_self() % THREADTABLE_SIZE);
}
and use this call instead of gwthread_self() for the logging
functions?!
how about just reusing of freed thread number for next tread ?
static void delete_threadinfo(void)
{
struct threadinfo *threadinfo;
threadinfo = getthreadinfo();
list_destroy(threadinfo-joiners, NULL);
close(threadinfo-wakefd_recv);
close(threadinfo-wakefd_send);
THREAD(threadinfo-number) = NULL;
active_threads--;
next_threadnumber = threadinfo-number; /* reuse tread numer */
gw_assert(threadinfo != mainthread);
gw_free(threadinfo);
}
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf
Tel: +49-211-74845-0
Fax: +49-211-74845-299
E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are
--
Best regards / Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstrasse 2
50672 Köln
Fon: +49 (0221) 277 49 240
Fax: +49 (0221) 277 49 109
email: a.malysh at centrium.de
web: http://www.centrium.de
msn: olek2002 at hotmail.com
___
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Re: Bug in log.c
oops, that was wrong :(
here is the possible solution:
static void delete_threadinfo(void)
{
struct threadinfo *threadinfo;
threadinfo = getthreadinfo();
list_destroy(threadinfo-joiners, NULL);
close(threadinfo-wakefd_recv);
close(threadinfo-wakefd_send);
THREAD(threadinfo-number) = NULL;
active_threads--;
if (threadinfo-number next_threadnumber)
next_threadnumber = threadinfo-number;
gw_assert(threadinfo != mainthread);
gw_free(threadinfo);
}
next_threadnumber is always the min. free slot number.
worst case while creating new thread:
next_threadnumber is used then max MAX_THREATABLE_SIZE-next_threadnumber
loop.
Am Donnerstag, 19. Juni 2003 18:52 schrieb Alexander Malysh:
Hi,
Am Donnerstag, 19. Juni 2003 18:36 schrieb Stipe Tolj:
Michael Mulcahy schrieb:
Hi All,
Found a solution that I think should be ok.
In the gwthread-module the table is size 1024.
While the thread number may increase byond it the
id is a modulo of 1024 and so the modulo can be
used in the log.c to prevent the prior mentioned
problem.
suggested fix would be to use following:
if ((e = thread_to[(gwthread_self()%1024)])) {
Have tested this and appears to work.
how about having this inside gwthread-pthread.c as function:
/* Return the threadtable sloot this thread is using. */
long gwthread_table_slot(void)
{
return (gwthread_self() % THREADTABLE_SIZE);
}
and use this call instead of gwthread_self() for the logging
functions?!
how about just reusing of freed thread number for next tread ?
static void delete_threadinfo(void)
{
struct threadinfo *threadinfo;
threadinfo = getthreadinfo();
list_destroy(threadinfo-joiners, NULL);
close(threadinfo-wakefd_recv);
close(threadinfo-wakefd_send);
THREAD(threadinfo-number) = NULL;
active_threads--;
next_threadnumber = threadinfo-number; /* reuse tread numer */
gw_assert(threadinfo != mainthread);
gw_free(threadinfo);
}
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf
Tel: +49-211-74845-0
Fax: +49-211-74845-299
E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are
--
Best regards / Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstrasse 2
50672 Köln
Fon: +49 (0221) 277 49 240
Fax: +49 (0221) 277 49 109
email: a.malysh at centrium.de
web: http://www.centrium.de
msn: olek2002 at hotmail.com
___
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Re: Need some input for a development job
Do the stuck messages show up as queued. If so I have the same problem after trying to send too many messages a second to the target SMSC. On 19/06/03, Jarrod Hermer ([EMAIL PROTECTED]) wrote: First off I want to say what a fantastic product Kannel is and that it has been working for us very well over the past few months. Except for one niggling issue, which I think is also a problem for some other people using SMPP to deliver messages - messages getting stuck in the store file and not being delivered until Kannel gets restarted. -- Rory Campbell-Lange [EMAIL PROTECTED] www.campbell-lange.net
Re: Bug in log.c
ok, I just commited this: 2003-06-19 Stipe Tolj [EMAIL PROTECTED] * gwlib/gwthread.h, gwlib/gwthread-pthread.c: added function gwthread_table_slot() to provide the slot integer of threadtable the thread is using. * gwlib/log.c: fixed Michael's reported bug for the logging functions. please update your trees and check. It implements the module access to the thread[] mapping table inside the logging module to ensure we don't access over the array limit. Because gwthread_self() is unique and assigned to a free slot when the thread is registered, also (gwthread_self() % THREADTABLE_SIZE) is unique and provides us with the correct slot the thread belongs to. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [PATCH] rewrite/cleanup of dlr handling (new)
Hi what happened to this? Nisan At 12:17 AM 5/27/03 +0200, Alexander Malysh wrote: Hi all, sorry first mail has wrong diff :( attached big patch does following: 1) adds more abstraction to dlr handling 2) makes it easier to add new dlr storage types to kannel without touching a dlr-core code 3) makes dlr-core ready for coming (hopefully soon) modules API 4) makes handling/creating of dlr messages uniformly over all storage types Please look in it. Comments are very welcome... -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: a.malysh at centrium.de web: http://www.centrium.de msn: olek2002 at hotmail.com ___ Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html
Re: [PATCH] rewrite/cleanup of dlr handling (new)
Nisan Bloch wrote: Hi what happened to this? I'm just reading it. Unfortunatly it's huge and even in unified diff almost unreadable to understand what happens. Maybe you Nisan can explain a bit?! Have you tested Alexander's code again SMSCs? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [RFC] changing defaults of SMPP TON and NPI for MT?
On Jeudi, juin 19, 2003, at 04:00 Uhr, Stipe Tolj wrote:
Alexander Malysh schrieb:
Hi Stipe,
-1 from me.
How do you want recognize national numbers? International numbers can be
simple detected. They have '+' in front and then we set ton to international
and remove the plus.
hmm, so you *require* users to send to=%2b49xxx at sendsms HTTP
interface. If someone sends to=49xxx then it will be send with
national TON.
sure. that makes SENSE.
and if you disagree, you can force it with setting ton=international in the config file.
default should be autodetect. + clearly indicates international, anything else is a guess which would be 00... international, 0{1...9} or {1...9} would be national or subscriber or unknown.
my recommendation would be for autodetect (default case)
+ -> international
anything else -> unknown
unless you force it in config file to something specific in which case autodetect would be off.
Andreas Fink
Global Networks Switzerland AG
--
Tel: +41-61-333 Fax: +41-61-334 Mobile: +41-79-2457333
Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland
Web: http://www.global-networks.ch/ [EMAIL PROTECTED]
--
Re: Strange smsbox/bearerbox problem : SMS messages not being sent
Andreas Fink wrote: AT2 module sleeps anyway and waits for ACK from modem before proceeding. So adding sleeps there is not making any sense unless you wana limit it to have only 1 message every minute or such. ok, I wasn't aware of it right now. That's fine with me then. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [PATCH] rewrite/cleanup of dlr handling (new)
Alexander Malysh wrote: sorry first mail has wrong diff :( attached big patch does following: 1) adds more abstraction to dlr handling 2) makes it easier to add new dlr storage types to kannel without touching a dlr-core code 3) makes dlr-core ready for coming (hopefully soon) modules API 4) makes handling/creating of dlr messages uniformly over all storage types Please look in it. Comments are very welcome... ok, looks good to me. +1. will commit this. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [PATCH] rewrite/cleanup of dlr handling (new)
Hi,
i found a small memleak after it ...
Attached you can find corrected version of this patch.
I can say, mysql and internal where tested and works on our production systems
without any problems. libsdb is not tested yet, but should work, because i
have not changed any calls to the library itself. So please people, who use
libsdb, test it!
What happens is pretty simple ;)
1. if dlr_init calls then here storage will be initilialized return pointer to
operations struct. pls consult dlr_p.h for possible operations on the
storage.
2. If dlr_find calls then core dlr do following:
call storage get function
create new dlr message
check if this end status of message (e.g. delivered or undelivered) and then
delete the message by calling of remove storage funct. if end state not
reached then call storage update status entry funct. (its optional, that
means, if storage define this funct. it will be called otherwise not)
3. dlr_status just call storage status funct.
and so on ...
So if any questions about this code should be here, then ask!
Am Donnerstag, 19. Juni 2003 20:02 schrieb Stipe Tolj:
Nisan Bloch wrote:
Hi
what happened to this?
I'm just reading it. Unfortunatly it's huge and even in unified diff
almost unreadable to understand what happens.
Maybe you Nisan can explain a bit?!
Have you tested Alexander's code again SMSCs?
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf
Tel: +49-211-74845-0
Fax: +49-211-74845-299
E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are
--
Best regards / Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstrasse 2
50672 Köln
Fon: +49 (0221) 277 49 240
Fax: +49 (0221) 277 49 109
email: a.malysh at centrium.de
web: http://www.centrium.de
msn: olek2002 at hotmail.com
___
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
? doc/alligata/alligata.tex
? test/test_dbpool
? test/test_md5
? test/test_octstr_dump
? utils/mtbatch
Index: gw/bearerbox.c
===
RCS file: /home/cvs/gateway/gw/bearerbox.c,v
retrieving revision 1.139
diff -a -u -b -r1.139 bearerbox.c
--- gw/bearerbox.c 26 May 2003 18:37:11 - 1.139
+++ gw/bearerbox.c 17 Jun 2003 20:06:20 -
@@ -735,7 +735,7 @@
(float)counter_value(incoming_sms_counter)/t,
(float)counter_value(outgoing_sms_counter)/t,
dlr_messages(),
-octstr_get_cstr(dlr_type));
+dlr_type());
octstr_destroy(version);
ret = octstr_create(buf);
Index: gw/dlr.c
===
RCS file: /home/cvs/gateway/gw/dlr.c,v
retrieving revision 1.33
diff -a -u -b -r1.33 dlr.c
--- gw/dlr.c 27 Feb 2003 09:48:59 - 1.33
+++ gw/dlr.c 17 Jun 2003 20:06:21 -
@@ -5,6 +5,7 @@
*
* Andreas Fink [EMAIL PROTECTED], 18.08.2001
* Stipe Tolj [EMAIL PROTECTED], 22.03.2002
+ * Alexander Malysh [EMAIL PROTECTED] 2003
*
* Changes:
* 2001-12-17: [EMAIL PROTECTED]:
@@ -31,229 +32,147 @@
#include gwlib/gwlib.h
#include sms.h
#include dlr.h
+#include dlr_p.h
+
+/* Our callback functions */
+static struct dlr_storage *handles = NULL;
+
/*
-#define DLR_TRACE 1
-*/
-/*
- * We use memory based DLR
- * the structure of a delivery report waiting list entry
+ * Function to allocate a new struct dlr_entry entry
+ * and intialize it to zero
*/
+struct dlr_entry *dlr_entry_create()
+{
+struct dlr_entry *dlr;
-typedef struct dlr_wle {
- Octstr *smsc;
- Octstr *timestamp;
- Octstr *source;
- Octstr *destination;
- Octstr *service;
- Octstr *url;
- int mask;
- Octstr *boxc_id;
-} dlr_wle;
-
-/*
- * This is the global list where all messages being sent out are being kept track
- * of his list is looked up once a delivery report comes in
- */
-static List *dlr_waiting_list;
-static void dlr_destroy(dlr_wle *dlr);
-static void dlr_init_mem(void);
-#ifdef DLR_MYSQL
-static void dlr_init_mysql(Cfg* cfg);
-#endif
-#ifdef DLR_SDB
-static void dlr_init_sdb(Cfg* cfg);
-#endif
-static void dlr_shutdown_mem(void);
-static void dlr_shutdown_mysql(void);
-static dlr_wle *dlr_new(void);
+dlr = gw_malloc(sizeof(*dlr));
+gw_assert(dlr != NULL);
+
+/* set all values to NULL */
+memset(dlr, 0, sizeof(*dlr));
+
+return dlr;
+}
/*
- * At startup initialize the list, use abstraction to
- * allow to add additional dlr_init_foobar() routines here.
- *
- * Check 'dlr-storage' directive in core group to see how DLRs are
- * processed.
+ * Duplicate dlr entry
*/
-
-static void dlr_init_mem()
+struct dlr_entry *dlr_entry_duplicate(const struct
Re: [PATCH] rewrite/cleanup of dlr handling (new)
Alexander Malysh wrote: i found a small memleak after it ... Attached you can find corrected version of this patch. I can say, mysql and internal where tested and works on our production systems without any problems. libsdb is not tested yet, but should work, because i have not changed any calls to the library itself. So please people, who use libsdb, test it! What happens is pretty simple ;) 1. if dlr_init calls then here storage will be initilialized return pointer to operations struct. pls consult dlr_p.h for possible operations on the storage. 2. If dlr_find calls then core dlr do following: call storage get function create new dlr message check if this end status of message (e.g. delivered or undelivered) and then delete the message by calling of remove storage funct. if end state not reached then call storage update status entry funct. (its optional, that means, if storage define this funct. it will be called otherwise not) 3. dlr_status just call storage status funct. and so on ... +1, commited to cvs. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [PATCH] rewrite/cleanup of dlr handling (new)
Hi Andreas, Am Donnerstag, 19. Juni 2003 21:08 schrieb Andreas Fink: On Jeudi, juin 19, 2003, at 08:33 Uhr, Alexander Malysh wrote: Hi, i found a small memleak after it ... Attached you can find corrected version of this patch. I can say, mysql and internal where tested and works on our production systems without any problems. libsdb is not tested yet, but should work, because i have not changed any calls to the library itself. So please people, who use libsdb, test it! What happens is pretty simple ;) 1. if dlr_init calls then here storage will be initilialized return pointer to operations struct. pls consult dlr_p.h for possible operations on the storage. 2. If dlr_find calls then core dlr do following: call storage get function create new dlr message check if this end status of message (e.g. delivered or undelivered) and then delete the message by calling of remove storage funct. if end state not reached then call storage update status entry funct. (its optional, that means, if storage define this funct. it will be called otherwise not) 3. dlr_status just call storage status funct. I looked at the patch but I don't understand what the cleanup purpose was.. can you explain? sure... 1) make easier to add new dlr storage types to kannel without touching a dlr-core code. With old dlr handling you must to go over all storage types in order to add your's. Now u must simple implement clear defined operations for your storage type without touching any line in dlr core handling. Yet not fully true, due to lack of modules API, now you must add your new storage type (equal to SMSCConn) to dlr_init function. 2) not equal creating of dlrs for different storage types. In old dlr code we have for example in internal storage reversed source and destination addr in dlr msg but not in mysql. 3) that had grown with the time and looks bad ;) this is the same as for SMSCConn... why it was rewriten? a: in order to get things clearer and easier to handle... Andreas Fink Global Networks Switzerland AG -- Tel: +41-61-333 Fax: +41-61-334 Mobile: +41-79-2457333 Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: a.malysh at centrium.de web: http://www.centrium.de msn: olek2002 at hotmail.com ___ Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html
RE: Bug in log.c
so what if I have a thread 10 which is a EMI/UCP process and
suddendly a new process gets added with 1034? we have a new conflict...
No, that what I thought as well, but the gwthread-pthread.c takes
care of that problem.
see gwthread-pthread.c
/* Find a free table entry and claim it. */
first_try = next_threadnumber;
do {
ti-number = next_threadnumber++;
/* Check if we looped all the way around the thread table. */
if (ti-number == first_try + THREADTABLE_SIZE) {
panic(0, Cannot have more than %d active threads,
THREADTABLE_SIZE);
}
} while (THREAD(ti-number) != NULL);
THREAD(ti-number) = ti;
active_threads++;
where THREAD(t) is:
#define THREAD(t) (threadtable[(t) % THREADTABLE_SIZE])
The thread number is incremented and the mod 1024 position in
array is checked to see if an entry exists. If an entry exists then
the thread number is incremented again.
Just to clarify this in my own mind I wrote a program
essentially the following:
/* create 100 threads that sleep indefinitely */
for (i; i 100; i++)
gwthread_create(sleepy_thread, val);
/* create 100 threads that sleep for small bit */
for (i = 0; i 2000; i++)
{
gwthread_create(sleepy_thread, val2);
gwthread_sleep(0.1);
}
the output shows how the thread number works:
2003-06-19 18:17:18 [0] DEBUG: Started thread 1021
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:18 [0] DEBUG: Started thread 1022
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1023
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1125
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1126
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1127
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1128
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1129
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1130
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1131
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Andreas Fink
Sent: 19 June 2003 17:55
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Bug in log.c
On Jeudi, juin 19, 2003, at 06:26 Uhr, Michael Mulcahy wrote:
Hi All,
Found a solution that I think should be ok.
In the gwthread-module the table is size 1024.
While the thread number may increase byond it the
id is a modulo of 1024 and so the modulo can be
used in the log.c to prevent the prior mentioned
problem.
suggested fix would be to use following:
if ((e = thread_to[(gwthread_self()%1024)])) {
Have tested this and appears to work.
Sorry for not spotting this earlier.
Kindest Regards,
Michael.
so what if I have a thread 10 which is a EMI/UCP process and suddendly a new
process gets added with 1034?
we have a new conflict...
Andreas Fink
Global Networks Switzerland AG
--
Tel: +41-61-333 Fax: +41-61-334 Mobile: +41-79-2457333
Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland
Web: http://www.global-networks.ch/ [EMAIL PROTECTED]
--
[RFC] cookie support per detault in wapbox?!
Hi list, I'd like to throw the --enable-cookie directive from configure and make cookie support for wapbox now a permanent default feature. Any objections for doing this? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Bug in log.c
Andreas Fink schrieb: so what if I have a thread 10 which is a EMI/UCP process and suddendly a new process gets added with 1034? we have a new conflict... ahhh, Andreas *is* right here. We don't take into account that the threadtable handling does a linear scan in the threadtable to find a free slot. So the gwthread_self() id can't be used to determine a unique thread id with the module operator, right?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Bug in log.c
Michael Mulcahy schrieb:
so what if I have a thread 10 which is a EMI/UCP process and
suddendly a new process gets added with 1034? we have a new conflict...
No, that what I thought as well, but the gwthread-pthread.c takes
care of that problem.
see gwthread-pthread.c
/* Find a free table entry and claim it. */
first_try = next_threadnumber;
do {
ti-number = next_threadnumber++;
/* Check if we looped all the way around the thread table. */
if (ti-number == first_try + THREADTABLE_SIZE) {
panic(0, Cannot have more than %d active threads,
THREADTABLE_SIZE);
}
} while (THREAD(ti-number) != NULL);
THREAD(ti-number) = ti;
active_threads++;
where THREAD(t) is:
#define THREAD(t) (threadtable[(t) % THREADTABLE_SIZE])
The thread number is incremented and the mod 1024 position in
array is checked to see if an entry exists. If an entry exists then
the thread number is incremented again.
ok, once again I'll chance my opinion ;))
Andreas, do you agree that a (gwthread_self() % THREADTABLE_SIZE)
gives us a runtime unque ID of the thread?
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf
Tel: +49-211-74845-0
Fax: +49-211-74845-299
E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are
GNU autoconf experts arround?!
Hi list, I'm fidling arround with a modified configure/make process to allow adding new add-on boxes (ie. smppbox) to the build. I come up with --with-box[=NAME] inside configure.in and this works, even while this is really an un-nice hack ;) Unfortunatly I can't give more then one --with-box statement to configure. Can anyone give me a good hint or example code on how to implement --with-foobar=1 --with-foobar=2 ... inside M4 macro code for confifure.in??? Any help is appritiated, since release date for smppbox and mmsbox depends on it ;) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
[FYI] RADIOUS accounting proxy commited
Hi list, I just commited this to cvs: 2003-06-20 Stipe Tolj [EMAIL PROTECTED] * Makefile.in: added compilation of RADIUS related files inside radius/. * doc/userguide/userguide.xml: new MSISDN provisioning section describing the use of the RADIUS accounting proxy thread. * gwlib/cfg.def: removed properietary groups that are *not* used inside Kannel's tree and added 'radius-acct' group configuration directives. * gw/wap-appl.c, gw/wapbox.c: added RADIUS accounting proxy related calls. * radius/*: added RADIUS accounting proxy implemenation. * test/test_radius_*.c: added some testing applications for the RADIUS routines. which means we have now a real MSISDN provisioning boarded inside Kannel using a RADIUS accounting proxy thread inside wapbox. See user's guide for guidance. It works here at Wapme for some time inside our MMSC implementation, because we pick the 'From' MMS header using the MSISDN provsioning value provided by the WAP gateway (wapbox) directly. The only thing that needs work on is the MD5 shared secret re-computation to ensure NAS and we are having the same shared secret. Usually I'm aware on how this is done, but it seems I can get this right with our Ascend MAX2000 we have here arround. BTW, we used GNU-radius as the RADIUS server back-end for authentication and account packet forwarding. Any help in getting the damn shared secret re-computation done right is highly welcome. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
