RE: Clickatell http driver patch
I just checked the Kannel http api sources. And the ssl parameters are not used at the moment. It shouldn't be too hard to implement. But I will leave it for another occasion. Let's first see if this patch gets accepted (or not). Rene Kluwen Chimit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alexander Malysh Sent: dinsdag 14 maart 2006 21:14 To: devel@kannel.org Subject: Re: Clickatell http driver patch Hi again, Rene Kluwen schrieb: Hi Alex, As you suggested, I agree that we better move this thread to the ML. I posted the patch to the users ML. I will attach it to this post again for your convenience. I will fix your points 1, 2 4. Probably before the end of this week. About the authentication: Clickatell does not send a username or password along. But I will see if it is possible to make a check on api_id. Besides that, also connect-allow-ip can be used. From what I have heard from the Clickatell techs, their callback HTTP farm connects from behind one single IP address. not really good interface ;) (hint: ip spoofing) Their server should connect via https with username pass... Thanks, Alex Cheers, Rene Kluwen Chimit --- alex - 03-14-06 19:31 GMT --- Hi Rene, I agree with you that we should support as much http interfaces as possible. As to you patch... It's to hard to comment on this patch in mantis. Please post it to ML and I will review it. At least now some comments: 1) please fix comments (they mention Brunet but your patch should support Clickatell ;)) 2) please kill commented blocks which are there due to copypaste from brunet /* e.g. XSER */ 3) I don't see what should prevent me to send your MO message instead of Clickatell server (not auth. for MO and DLR) 4) minor: please fix coding style (indents) Thanks, Alex
RE: Clickatell http driver patch
Alex, I fixed your points 1, 2 4 with the latest patch attached. About point 3: https server support will be nice in the http smsc driver. This is true for ALL http drivers and is not just Clickatell related. So I consider this a seperate issue. Rene Kluwen Chimit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alexander Malysh Sent: dinsdag 14 maart 2006 21:14 To: devel@kannel.org Subject: Re: Clickatell http driver patch Hi again, Rene Kluwen schrieb: Hi Alex, As you suggested, I agree that we better move this thread to the ML. I posted the patch to the users ML. I will attach it to this post again for your convenience. I will fix your points 1, 2 4. Probably before the end of this week. About the authentication: Clickatell does not send a username or password along. But I will see if it is possible to make a check on api_id. Besides that, also connect-allow-ip can be used. From what I have heard from the Clickatell techs, their callback HTTP farm connects from behind one single IP address. not really good interface ;) (hint: ip spoofing) Their server should connect via https with username pass... Thanks, Alex Cheers, Rene Kluwen Chimit --- alex - 03-14-06 19:31 GMT --- Hi Rene, I agree with you that we should support as much http interfaces as possible. As to you patch... It's to hard to comment on this patch in mantis. Please post it to ML and I will review it. At least now some comments: 1) please fix comments (they mention Brunet but your patch should support Clickatell ;)) 2) please kill commented blocks which are there due to copypaste from brunet /* e.g. XSER */ 3) I don't see what should prevent me to send your MO message instead of Clickatell server (not auth. for MO and DLR) 4) minor: please fix coding style (indents) Thanks, Alex clickatell MO Revisited.patch Description: Binary data
Clickatell http driver patch
Hi Alex, As you suggested, I agree that we better move this thread to the ML. I posted the patch to the users ML. I will attach it to this post again for your convenience. I will fix your points 1, 2 4. Probably before the end of this week. About the authentication: Clickatell does not send a username or password along. But I will see if it is possible to make a check on api_id. Besides that, also connect-allow-ip can be used. From what I have heard from the Clickatell techs, their callback HTTP farm connects from behind one single IP address. Cheers, Rene Kluwen Chimit --- alex - 03-14-06 19:31 GMT --- Hi Rene, I agree with you that we should support as much http interfaces as possible. As to you patch... It's to hard to comment on this patch in mantis. Please post it to ML and I will review it. At least now some comments: 1) please fix comments (they mention Brunet but your patch should support Clickatell ;)) 2) please kill commented blocks which are there due to copypaste from brunet /* e.g. XSER */ 3) I don't see what should prevent me to send your MO message instead of Clickatell server (not auth. for MO and DLR) 4) minor: please fix coding style (indents) Thanks, Alex clickatell_MO.patch Description: Binary data
Re: Clickatell http driver patch
Hi again, Rene Kluwen schrieb: Hi Alex, As you suggested, I agree that we better move this thread to the ML. I posted the patch to the users ML. I will attach it to this post again for your convenience. I will fix your points 1, 2 4. Probably before the end of this week. About the authentication: Clickatell does not send a username or password along. But I will see if it is possible to make a check on api_id. Besides that, also connect-allow-ip can be used. From what I have heard from the Clickatell techs, their callback HTTP farm connects from behind one single IP address. not really good interface ;) (hint: ip spoofing) Their server should connect via https with username pass... Thanks, Alex Cheers, Rene Kluwen Chimit --- alex - 03-14-06 19:31 GMT --- Hi Rene, I agree with you that we should support as much http interfaces as possible. As to you patch... It's to hard to comment on this patch in mantis. Please post it to ML and I will review it. At least now some comments: 1) please fix comments (they mention Brunet but your patch should support Clickatell ;)) 2) please kill commented blocks which are there due to copypaste from brunet /* e.g. XSER */ 3) I don't see what should prevent me to send your MO message instead of Clickatell server (not auth. for MO and DLR) 4) minor: please fix coding style (indents) Thanks, Alex
Re: AT driver patch
Hi Stipe+List, On 1.3.2005, at 03:24, Stipe Tolj wrote: Aarno Syvänen wrote: Hi List, Anybody committing this patch to cvs? I tested it with keyspan 19hs adapter and siemens tc35 modem (which combination initialised very slowly), and it seems to work ok. now, obviously you commited it for revision 1.21, 2005/02/22 16:19:21 ;) which brings us up again to a rule: write a post to the list saying commited to cvs if you do. So that developers scanning the list for open issues know that this has been commited and don't have to viewcvs to check. Committed to CVS for every instance for asking a vote ? Yep, there is something in this, a mail lumping all commits together is a bit misguiding. Even while I have to veto again the error() message strings. They are a bit to harsh for a little gsm modem to write in a log file ;) Yep, I fix them. A joke repeated many times over is very tedious. Aarno
Re: AT driver patch
Aarno Syvänen wrote:
Hi Stipe+List,
On 1.3.2005, at 03:24, Stipe Tolj wrote:
Aarno Syvänen wrote:
Hi List,
Anybody committing this patch to cvs? I tested it with
keyspan 19hs adapter and siemens tc35 modem
(which combination initialised very slowly), and it
seems to work ok.
now, obviously you commited it for revision 1.21, 2005/02/22 16:19:21 ;)
which brings us up again to a rule: write a post to the list saying
commited to cvs if you do. So that developers scanning the list for
open issues know that this has been commited and don't have to
viewcvs to check.
Committed to CVS for every instance for asking a vote ? Yep, there is
something in this, a mail lumping all commits together is
a bit misguiding.
now, propose an other more functional way in tracking which vote/patch has
been commited.
Ok, there is kannel-reports mailing list, which I _DO_ read, but IMO it makes
life easier in the mailing list when an issue has been resolved via a commit-set
to be finally noticed with a commited to cvs mail.
We could have a vote on this practive too, if you care? ;)
Even while I have to veto again the error() message strings. They are
a bit to harsh for a little gsm modem to write in a log file ;)
Yep, I fix them. A joke repeated many times over is very tedious.
+1 :0
Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
Re: Fwd: AT driver patch
Aarno Syvänen wrote:
Hi List,
Anybody committing this patch to cvs? I tested it with
keyspan 19hs adapter and siemens tc35 modem
(which combination initialised very slowly), and it
seems to work ok.
now, obviously you commited it for revision 1.21, 2005/02/22 16:19:21 ;)
which brings us up again to a rule: write a post to the list saying commited to
cvs if you do. So that developers scanning the list for open issues know that
this has been commited and don't have to viewcvs to check.
Even while I have to veto again the error() message strings. They are a bit to
harsh for a little gsm modem to write in a log file ;)
Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
Fwd: AT driver patch
Hi List,
Anybody committing this patch to cvs? I tested it with
keyspan 19hs adapter and siemens tc35 modem
(which combination initialised very slowly), and it
seems to work ok.
Aarno
Begin forwarded message:
From: Andreas Fink [EMAIL PROTECTED]>
Date: 21. helmikuuta 2005 14:20:15 GMT+01:00
To: Aarno Syvänen [EMAIL PROTECTED]>
Subject: Fwd: AT driver patch
Begin forwarded message:
From: Andreas Fink [EMAIL PROTECTED]>
Date: 3. Dezember 2004 08:45:51 GMT+01:00
To: devel@kannel.3glab.org
Cc: Subject: AT driver patch
Hi folks.
A user reported to me having problems while initializing the modem after a while.
The log shows it gets no OK after ATF. I however realized that it might simply not wait long enough. ATF resets the modem and this might take a while on some old slow phones. Our default timeout of 3 seconds might simply be too slow for those.
I wrote the attached patch to work around this issue and also to retry the first few commands if it failed. This should make initialization more robust. Before I commit it to CVS I however want to have it tested by a couple of modem users with different types of modems to be sure it doesn't screw up something else.
Andreas Fink
Fink Consulting GmbH
---
Tel: +41-61-332 Fax: +41-61-331 Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail: [EMAIL PROTECTED]
Homepage: http://www.finkconsulting.com
---
--- gw/smsc/smsc_at.c 17 Sep 2004 22:20:50 - 1.17
+++ gw/smsc/smsc_at.c 3 Dec 2004 07:38:53 -
@@ -417,20 +417,28 @@
gwthread_sleep(0.10);
/* reset the modem */
-if (at2_send_modem_command(privdata, ATZ, 0, 0) == -1)
-return -1;
+if (at2_send_modem_command(privdata, ATZ, 0, 0) == -1) {
+error(0, AT2[%s]: modem doesnt like me :(. I'll ignore it for now,
octstr_get_cstr(privdata-name));
+ }
/* check if the modem responded */
if (at2_send_modem_command(privdata, AT, 0, 0) == -1) {
-error(0, AT2[%s]: no answer from modem,
octstr_get_cstr(privdata-name));
-return -1;
+error(0, AT2[%s]: Wrong or no answer from modem. Trying again,
octstr_get_cstr(privdata-name));
+ if (at2_send_modem_command(privdata, AT, 0, 0) == -1) {
+ error(0, AT2[%s]: No luck. get something more reliable,
octstr_get_cstr(privdata-name));
+ return -1;
+ }
}
at2_flush_buffer(privdata);
-if (at2_send_modem_command(privdata, ATF, 0, 0) == -1)
-return -1;
-
+ /* ATF might need a bit a longer timeout as usual */
+if (at2_send_modem_command(privdata, ATF, 7, 0) == -1) {
+ error(0, AT2[%s]: Modem didnt like my ATF. Lets give it a
second try, octstr_get_cstr(privdata-name));
+ if (at2_send_modem_command(privdata, ATF, 7, 0) == -1) {
+ return -1;
+ }
+ }
if (at2_send_modem_command(privdata, ATE0, 0, 0) == -1)
return -1;
@@ -565,9 +573,21 @@
}
+/* at_wait_modem_command waits for the response of a previous
+ sent AT command. The return values are
+ -1: got ERROR
+ 0: got OK
+ 1: got
+ 2: got SIM PIN
+ the function also handles interceptions like RING
+ or incoming SMS and handles them accordingly and transparently
+ timeout is 3 seconds by default
+*/
+
int at2_wait_modem_command(PrivAT2data *privdata, time_t timeout, int gt_flag,
int *output)
{
+
Octstr *line = NULL;
Octstr *line2 = NULL;
Octstr *pdu = NULL;
Andreas Fink
Global Networks Switzerland AG
--
Tel: +41-61-330 Fax: +41-61-334 Mobile: +41-79-2457333
Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland
Web: http://www.global-networks.ch/ [EMAIL PROTECTED]
--
PGP Fingerprint: B982 00B7 FFB5 0B33 BFF8 0F77 1E23 F3CA B4A3 D0B8
AW: AT driver patch
In the same vain: Using a SIM from Mexico, a recent Kannel snapshot failed to send a SMS using a strange GSM mobile phone (CompactFlash format using a CF-to-PCCard adapter). Investigating the problem revealed that Kannel did not wait long enough for the prompt to appear after the AT+CMGS command. Currently the timeout is set to 5 seconds. Increasing it to 15 seconds solved the problem. Regards Jörg -Ursprüngliche Nachricht- Von: Andreas Fink [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 3. Dezember 2004 08:46 An: [EMAIL PROTECTED] Betreff: AT driver patch Hi folks. A user reported to me having problems while initializing the modem after a while. The log shows it gets no OK after ATF. I however realized that it might simply not wait long enough. ATF resets the modem and this might take a while on some old slow phones. Our default timeout of 3 seconds might simply be too slow for those. I wrote the attached patch to work around this issue and also to retry the first few commands if it failed. This should make initialization more robust. Before I commit it to CVS I however want to have it tested by a couple of modem users with different types of modems to be sure it doesn't screw up something else. Andreas Fink Fink Consulting GmbH --- Tel: +41-61-332 Fax: +41-61-331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com ---
AT driver patch
Hi folks.
A user reported to me having problems while initializing the modem
after a while.
The log shows it gets no OK after ATF. I however realized that it
might simply not wait long enough. ATF resets the modem and this might
take a while on some old slow phones. Our default timeout of 3 seconds
might simply be too slow for those.
I wrote the attached patch to work around this issue and also to retry
the first few commands if it failed. This should make initialization
more robust. Before I commit it to CVS I however want to have it tested
by a couple of modem users with different types of modems to be sure it
doesn't screw up something else.
Andreas Fink
Fink Consulting GmbH
---
Tel: +41-61-332 Fax: +41-61-331 Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail: [EMAIL PROTECTED]
Homepage: http://www.finkconsulting.com
---
--- gw/smsc/smsc_at.c 17 Sep 2004 22:20:50 - 1.17
+++ gw/smsc/smsc_at.c 3 Dec 2004 07:38:53 -
@@ -417,20 +417,28 @@
gwthread_sleep(0.10);
/* reset the modem */
-if (at2_send_modem_command(privdata, ATZ, 0, 0) == -1)
-return -1;
+if (at2_send_modem_command(privdata, ATZ, 0, 0) == -1) {
+error(0, AT2[%s]: modem doesnt like me :(. I'll ignore it for now,
octstr_get_cstr(privdata-name));
+ }
/* check if the modem responded */
if (at2_send_modem_command(privdata, AT, 0, 0) == -1) {
-error(0, AT2[%s]: no answer from modem,
octstr_get_cstr(privdata-name));
-return -1;
+error(0, AT2[%s]: Wrong or no answer from modem. Trying again,
octstr_get_cstr(privdata-name));
+ if (at2_send_modem_command(privdata, AT, 0, 0) == -1) {
+ error(0, AT2[%s]: No luck. get something more reliable,
octstr_get_cstr(privdata-name));
+ return -1;
+ }
}
at2_flush_buffer(privdata);
-if (at2_send_modem_command(privdata, ATF, 0, 0) == -1)
-return -1;
-
+ /* ATF might need a bit a longer timeout as usual */
+if (at2_send_modem_command(privdata, ATF, 7, 0) == -1) {
+ error(0, AT2[%s]: Modem didnt like my ATF. Lets give it a
second try, octstr_get_cstr(privdata-name));
+ if (at2_send_modem_command(privdata, ATF, 7, 0) == -1) {
+ return -1;
+ }
+ }
if (at2_send_modem_command(privdata, ATE0, 0, 0) == -1)
return -1;
@@ -565,9 +573,21 @@
}
+/* at_wait_modem_command waits for the response of a previous
+ sent AT command. The return values are
+ -1: got ERROR
+ 0: got OK
+ 1: got
+ 2: got SIM PIN
+ the function also handles interceptions like RING
+ or incoming SMS and handles them accordingly and transparently
+ timeout is 3 seconds by default
+*/
+
int at2_wait_modem_command(PrivAT2data *privdata, time_t timeout, int gt_flag,
int *output)
{
+
Octstr *line = NULL;
Octstr *line2 = NULL;
Octstr *pdu = NULL;
