Re: anyone using EMI2 with DLR?

2001-10-08 Thread Stipe Tolj

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?

2001-10-08 Thread Gildas PERROT

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?)

2001-10-08 Thread Stipe Tolj

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?

2001-10-06 Thread Bruno David Rodrigues

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?

2001-10-03 Thread Stipe Tolj

 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?

2001-10-02 Thread Andreas Fink

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