[PATCH] orig DLR bitmask passing back via DLR msg

[Stipe Tolj]

Hi list,

at the moment we don't pass back the original set bitmask when a DLR 
msg-sms is send back to an smsbox connection, we just set the actual 
DLR even bit in msg-sms.dlr_mask.


I would like to add the original DLR bitmask that was set when MT was 
processed in the msg-sms.meta_data part, group 'dlr', name 'dlr_mask', 
to allow smsbox applications to retrieve this information without the 
need to locally store temporary data.


Please review and vote for committing.

--
Best Regards,
Stipe

---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany

Kannel Foundation tolj.org system architecture
http://www.kannel.org/http://www.tolj.org/

mailto:stolj_{at}_kannel.org  mailto:st_{at}_tolj.org
---
Index: gw/dlr.c
===
--- gw/dlr.c(revision 5138)
+++ gw/dlr.c(working copy)
@@ -91,6 +91,7 @@
 #include sms.h
 #include dlr.h
 #include dlr_p.h
+#include meta_data.h
 
 /* Our callback functions */
 static struct dlr_storage *handles = NULL;
@@ -386,6 +387,7 @@
 Msg*msg = NULL;
 struct dlr_entry *dlr = NULL;
 Octstr *dst_min = NULL;
+Octstr *dlr_mask;
 
 if(octstr_len(smsc) == 0) {
warning(0, DLR[%s]: Can't find a dlr without smsc-id, dlr_type());
@@ -438,6 +440,17 @@
  * route this msg back to originating smsbox
  */
 O_SET(msg-sms.boxc_id, dlr-boxc_id);
+/*
+ * We will provide the DLR request bitmask in the DLR going back
+ * to the smsbox connection for processing. This allows smsbox
+ * connection type applications to avoid temporary storing and
+ * resolving data to pull up this information.
+ */
+dlr_mask = octstr_format(%ld, dlr-mask);
+msg-sms.meta_data = octstr_create();
+meta_data_set_value(msg-sms.meta_data, METADATA_DLR_GROUP,
+octstr_imm(METADATA_DLR_GROUP_BITMASK), dlr_mask, 
1);
+octstr_destroy(dlr_mask);
 
 time(msg-sms.time);
 debug(dlr.dlr, 0, DLR[%s]: created DLR message for URL %s,
Index: gw/meta_data.h
===
--- gw/meta_data.h  (revision 5138)
+++ gw/meta_data.h  (working copy)
@@ -69,6 +69,7 @@
 #define METADATA_DLR_GROUP_DONETIME   donetime
 #define METADATA_DLR_GROUP_SUBMITTIME submittime
 #define METADATA_DLR_GROUP_ERRORCODE  errorcode
+#define METADATA_DLR_GROUP_BITMASKdlr_mask
 
 #define METADATA_SMPP_GROUP   smpp
 

Re: Fwd: Need Help Regarding Encrypting Passwords

[Milan P. Stanic]

On Wed, 2015-07-08 at 10:31, Stipe Tolj wrote:
 Am 15.05.2015 07:55, schrieb Pandey Nitin:
 Can you please help me regarding the encryption of the passwords that we
 use in kannel configuration files.
 
 For example - I want to use the encrypted passwords in KANNEL.CONF file
 for -
 1. SMSC connection
 2. ADMIN passwords.
 I'd like to assist here. Can you please describe the scenario for the
 required encrypted counterparts of of passwords in the config?
 
 For the admin password it's pretty clear, and can be facilitated via sha1
 hash values, since the user needs to provide the password interactively when
 performing and HTTP admin URI command.
 
 But how about SMSC connection passwords? Bearerbox needs to send them to the
 SMSC in plain-text. So, the daemon needs to be able to recover them from any
 crypt-ed version.
 
 An idea would be to use AES to encrypt them with the admin keyword. Then at
 daemon start time the calling user would need to supply the admin password
 on the command line to let bearerbox unlock the crypt-ed string in the
 config to gain the plain-text for communication with the SMSC.

Is it wise to give any password on the command line, especially for long
running processes, because it could be seen with the simple 'ps' command
except when the system is security hardened.

 In addition you would need to shadow the password strings in the log
 files.
 
 Is there no chance to use file permissions for this, if it's only a matter
 of grouping the maintenance staff to see/no-see of passwords in the config?

-- 
Kind regards