Re: anyone using EMI2 with DLR?
Bi Bruno, do you get the panic even if you don't specify the dlr_* in http push ? yes, even for normal cgi-bin/sendsms this happens. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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: anyone using EMI2 with DLR?
Did you check if the problem still occurs when you comment fakesmsc group entries ? I noticed that bearerbox crashes with cgi-bin/status on Redhat 6.2 with the last CVS version abd only when you add fakesmsc group. PS : I am using emi2 SMSC only -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Stipe Tolj Envoyé : lundi 8 octobre 2001 11:43 À : Bruno David Rodrigues Cc : [EMAIL PROTECTED] Objet : Re: anyone using EMI2 with DLR? Bi Bruno, do you get the panic even if you don't specify the dlr_* in http push ? yes, even for normal cgi-bin/sendsms this happens. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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
BUG in emi2 (was Re: anyone using EMI2 with DLR?)
Hi all, Did you check if the problem still occurs when you comment fakesmsc group entries ? I noticed that bearerbox crashes with cgi-bin/status on Redhat 6.2 with the last CVS version abd only when you add fakesmsc group. There is no fakesmsc group in the config file. There is definitly nothing unusual within the config file. We use a simple emi2 smsc group. Both boxes (smsbox and bearerbox) crash after they write these log etries: bearerbox.log: [...] 2001-10-08 10:51:58 [4] DEBUG: HTTP: Destroying HTTPClient area 0x10035958. 2001-10-08 10:51:58 [4] DEBUG: HTTP: Destroying HTTPClient for `213.70.39.36'. 2001-10-08 10:52:40 [9] DEBUG: boxc_receiver: sms received 2001-10-08 10:52:40 [7] DEBUG: emi2 sending packet: 00/00094/O/51/00491735333216/10F730BC5D76B9CB74/3//746573745039/72 2001-10-08 10:52:40 [7] DEBUG: Got packet from the main socket 2001-10-08 10:52:40 [7] DEBUG: emi2 parsing packet: 00/00020/R/51/A///94 2001-10-08 10:52:40 [7] PANIC: gwlib/octstr.c:2032: seems_valid_real: Assertion `ostr != NULL' failed. (Called from gwlib/octstr.c:839:octstr_search_char.) smsbox.log: [...] 2001-10-08 10:52:40 [3] INFO: smsbox: Got HTTP request /cgi-bin/sendsms from 213.70.39.36 2001-10-08 10:52:40 [3] INFO: sendsms used by foo 2001-10-08 10:52:40 [3] INFO: sendsms sender:foo:wapme.net (213.70.39.36) to:491735333216 msg:test 2001-10-08 10:52:40 [3] DEBUG: Status: 202 Answer: Sent. 2001-10-08 10:52:40 [3] DEBUG: HTTP: Resetting HTTPClient for `213.70.39.36'. 2001-10-08 10:52:40 [0] INFO: Connection closed by the bearerbox 2001-10-08 10:52:40 [0] INFO: Received (and handled?) 0 requests in 45 seconds (0.00 per second) 2001-10-08 10:52:40 [0] INFO: Kannel smsbox terminating. 2001-10-08 10:52:40 [6] DEBUG: Thread 6 (gw/heartbeat.c:heartbeat_thread) terminates. 2001-10-08 10:52:40 [0] DEBUG: Waiting for 2 (gwlib/http.c:server_thread) to terminate 2001-10-08 10:52:40 [3] DEBUG: HTTP: No clients with requests, quitting. 2001-10-08 10:52:40 [3] DEBUG: Thread 3 (gw/smsbox.c:sendsms_thread) terminates. 2001-10-08 10:52:40 [2] DEBUG: Thread 2 (gwlib/http.c:server_thread) terminates. 2001-10-08 10:52:40 [1] WARNING: Destroying fdset with 1 active entries. 2001-10-08 10:52:40 [1] DEBUG: Thread 1 (gwlib/fdset.c:poller) terminates. 2001-10-08 10:52:40 [0] DEBUG: Waiting for 4 (gw/smsbox.c:obey_request_thread) to terminate 2001-10-08 10:52:40 [4] DEBUG: Thread 4 (gw/smsbox.c:obey_request_thread) terminates. 2001-10-08 10:52:40 [5] DEBUG: Thread 5 (gw/smsbox.c:url_result_thread) terminates. 2001-10-08 10:52:40 [0] DEBUG: Immutable octet strings: 176. 2001-10-08 10:52:40 [0] DEBUG: Current allocations: 12 areas, 732 bytes 2001-10-08 10:52:40 [0] DEBUG: Highest number of allocations: 1257 areas 2001-10-08 10:52:40 [0] DEBUG: Highest memory usage: 60404 bytes 2001-10-08 10:52:40 [0] DEBUG: Area 0x10032110, size 12, max_size 12 2001-10-08 10:52:40 [0] DEBUG: Allocated by mutex_create_real at gwlib/thread.c:26 2001-10-08 10:52:40 [0] DEBUG: Claimed by conn_wrap_fd at gwlib/conn.c:399 2001-10-08 10:52:40 [0] DEBUG: Contents of area (first 16 bytes): 2001-10-08 10:52:40 [0] DEBUG: f0 81 3f 00 ff ff ff ff 01 00 00 00 2001-10-08 10:52:40 [0] DEBUG: Area 0x10014670, size 113, max_size 113 2001-10-08 10:52:40 [0] DEBUG: Allocated by octstr_grow at gwlib/octstr.c:107 2001-10-08 10:52:40 [0] DEBUG: Contents of area (first 16 bytes): 2001-10-08 10:52:40 [0] DEBUG: 00 54 54 50 2f 31 2e 31 20 32 30 32 20 46 6f 6f 2001-10-08 10:52:40 [0] DEBUG: Area 0x100321b0, size 16, max_size 16 2001-10-08 10:52:40 [0] DEBUG: Allocated by octstr_create_from_data_real at gwlib/octstr.c:170 2001-10-08 10:52:40 [0] DEBUG: Claimed by octstr_format_valist at gwlib/octstr.c:1969 2001-10-08 10:52:40 [0] DEBUG: Contents of area (first 16 bytes): 2001-10-08 10:52:40 [0] DEBUG: d0 22 03 10 0c 00 00 00 0d 00 00 00 00 00 00 00 2001-10-08 10:52:40 [0] DEBUG: Area 0x1002e0f8, size 16, max_size 16 2001-10-08 10:52:40 [0] DEBUG: Allocated by octstr_create_from_data_real at gwlib/octstr.c:170 2001-10-08 10:52:40 [0] DEBUG: Claimed by init_smsbox at gw/smsbox.c:1872 2001-10-08 10:52:40 [0] DEBUG: Contents of area (first 16 bytes): 2001-10-08 10:52:40 [0] DEBUG: 30 e1 02 10 0d 00 00 00 0e 00 00 00 00 00 00 00 2001-10-08 10:52:40 [0] DEBUG: Area 0x10032558, size 32, max_size 32 2001-10-08 10:52:40 [0] DEBUG: Allocated by client_create at gwlib/http.c:1370 2001-10-08 10:52:40 [0] DEBUG: Contents of area (first 16 bytes): 2001-10-08 10:52:40 [0] DEBUG: d5 32 00 00 78 20 03 10 b0 21 03 10 00 00 00 00 2001-10-08 10:52:40 [0] DEBUG: Area 0x1002e130, size 14, max_size 14 2001-10-08 10:52:40 [0] DEBUG: Allocated by octstr_create_from_data_real at gwlib/octstr.c:178 2001-10-08 10:52:40 [0] DEBUG: Contents of area (first 16 bytes): 2001-10-08 10:52:40 [0] DEBUG: 30 31 32 33 34 35 36 37 38 39 20 2b 2d 00 2001-10-08 10:52:40 [0] DEBUG: Area 0x10032078, size 68, max_size 68 2001-10-08 10:52:40 [0] DEBUG: Allocated by conn_wrap_fd
Re: anyone using EMI2 with DLR?
do you get the panic even if you don't specify the dlr_* in http push ? 5.3.1 Submit Short Message operation (positive result) The following list shows the parameters in the positive result data field: Parameter Type Presence Description ACK Char A M Positive acknowledgement MVP String of char O Modified validity period SM String of char. O System message MVP is optional. DLR code should be aware of that and documentation should mention that too in dlr documentation. -- Bruno David Rodrigues - Original Message - From: Stipe Tolj [EMAIL PROTECTED] To: Andreas Fink [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, October 04, 2001 9:03 AM Subject: Re: anyone using EMI2 with DLR? I've never seen a crash in smsbox because of this. SMSbox is unchanged as far as DLR's are concerned. If you got an assert, in your case, thats normal because your EMI reply is not what bearerbox would expect. Of course this should be fixed and is relatively easy to fix. But it also means that in your case DLR's will not work because no timestamp imformation is given back from the SMSC. Could you provide the fix for emi2 here? We would like to have again a working CVS tree for development. BTW, please instruct me on how I can help you in figuring out if the timestamp's are supported using our SMSC and I'll provide for information on this.
Re: anyone using EMI2 with DLR?
Ok, if you got this problem then you most probably dont connect to a CMG SMSC but something emulating it or a CMG with an old release. The thing it does in this line is reading the timestamp information out which the SMSC gives back on a request. Apparently yours is empty or such. In my case this is something like timestampinformation:phonenumber and the code separates it to keep track of it. Of course if you get nothing back, its clear that delivery reports cant work for you. and what about the failed assertions that crash smsbox and then bearerbox after one SMS has been processed over emi2? This is definitly some kind of buggy. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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: anyone using EMI2 with DLR?
Hi, as I reported previously we had huge problems with latest CVS snapshot for emi2. There were assertion errors after using /cgi-bin/sendsms and both smsbox and bearerbox died. I located the problem to be in: gw/smsc_emi2.c:696:i = octstr_search_char(ts,':',0); so it seems when ts == NULL we get into truble here?! BTW, DLR reports don't work either for me. calling http://host:13013/cgi-bin/sendsms?...dlrmask=3dlrid=xyz does not activate the specified sms-service within conf file. Is anyone using this or has similar problems? It may depend on the above assertion problem? Stipe Ok, if you got this problem then you most probably dont connect to a CMG SMSC but something emulating it or a CMG with an old release. The thing it does in this line is reading the timestamp information out which the SMSC gives back on a request. Apparently yours is empty or such. In my case this is something like timestampinformation:phonenumber and the code separates it to keep track of it. Of course if you get nothing back, its clear that delivery reports cant work for you. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink