Re: [PATCH]
Dariusz Markowicz wrote: > > Hi all, > > here's a small patch for smsc_cimd2.c > It's remove memory leak warning on exit. > smsc->sender_prefix is allocated in cimd2_open() thanks Dariusz for the patch. Can anyone of the developers who use CIMD2 confirm the patch with a positive vote for commitment? 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] SMPP octstr to long handling
Harrie Hazewinkel wrote:
>
> Hm, I am not so in favour of doing length definitions this hardcoded
> way. But it seems, that many thing get all the time done via
> MACROs and depending on the use the marco results in different code.
>
> This is more coding style, I guess.
I think Lars has made a real great job in defining thing in this .def
macro style way. I admit it's a bit hard to understand what the
code/macros do(es), but when you got this, it's great to see how easy
PDU creation can be done.
> > RCS file: /home/cvs/gateway/gw/smsc/smpp_pdu.c,v
> > retrieving revision 1.1
> > diff -r1.1 smpp_pdu.c
> > 136,138c136,147
> > < gw_assert(octstr_len(p->name) < max_octets); \
> > < if (p->name != NULL) octstr_append(os, p->name); \
> > < octstr_append_char(os, '\0');
> > ---
> >> if (p->name != NULL) { \
> >> if (octstr_len(p->name) >= max_octets) { \
> >> warning(0, "SMPP: PDU element <%s> to long " \
> >> "(length is %d, should be %d)", \
> >> # name, octstr_len(p->name), max_octets); \
> >> temp = octstr_copy(p->name, 0, max_octets-1); \
> >> } else \
> >> temp = octstr_duplicate(p->name); \
> >> octstr_append(os, temp); \
> >> octstr_destroy(temp); \
> >> } \
> >> octstr_append_char(os, '\0');
>
> This also means that you ignore the address part which goes beyond the
> maximum length. Somehow, this feels not right, or do I miss something??
Hmmm, yes, but this is a semantical question I guess. If the address
exceeds the specified maximum length, you only have to choices I guess
a) ignore the PDU itself, which is not feasable in our inter-box
communication environment, because bearerbox is unable to tell smsbox
about such an problem of the given &from and &to variables.
b) cut the Octstrs to the max. specified length and leave the problem
to the user itself not to send to large data for the field.
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
[PATCH]
Hi all, here's a small patch for smsc_cimd2.c It's remove memory leak warning on exit. smsc->sender_prefix is allocated in cimd2_open() Dariusz Markowicz RCS file: /home/cvs/gateway/gw/smsc/smsc_cimd2.c,v retrieving revision 1.1 diff -u -r1.1 smsc_cimd2.c --- gw/smsc/smsc_cimd2.c8 Aug 2002 17:44:38 - 1.1 +++ gw/smsc/smsc_cimd2.c11 Aug 2002 21:09:31 - @@ -1797,6 +1797,7 @@ octstr_destroy(smsc->cimd2_username); octstr_destroy(smsc->cimd2_password); octstr_destroy(smsc->cimd2_inbuffer); +octstr_destroy(smsc->sender_prefix); discarded = list_len(smsc->cimd2_received); list_destroy(smsc->cimd2_received, msg_destroy_item);
Re: [PATCH] SMPP octstr to long handling
--On Sunday, August 11, 2002 6:31 PM +0200 Stipe Tolj
<[EMAIL PROTECTED]> wrote:
> BTW, we should not #define constants of SMPP that are explicitely
> 'defined' by the .def file anyway. So the 21 length for source and
> destination number is already a #define in this semantical way and
> hence we should *not* use #defined things in .def again.
Hm, I am not so in favour of doing length definitions this hardcoded
way. But it seems, that many thing get all the time done via
MACROs and depending on the use the marco results in different code.
This is more coding style, I guess.
> RCS file: /home/cvs/gateway/gw/smsc/smpp_pdu.c,v
> retrieving revision 1.1
> diff -r1.1 smpp_pdu.c
> 136,138c136,147
> < gw_assert(octstr_len(p->name) < max_octets); \
> < if (p->name != NULL) octstr_append(os, p->name); \
> < octstr_append_char(os, '\0');
> ---
>> if (p->name != NULL) { \
>> if (octstr_len(p->name) >= max_octets) { \
>> warning(0, "SMPP: PDU element <%s> to long " \
>> "(length is %d, should be %d)", \
>> # name, octstr_len(p->name), max_octets); \
>> temp = octstr_copy(p->name, 0, max_octets-1); \
>> } else \
>> temp = octstr_duplicate(p->name); \
>> octstr_append(os, temp); \
>> octstr_destroy(temp); \
>> } \
>> octstr_append_char(os, '\0');
This also means that you ignore the address part which goes beyond the
maximum length. Somehow, this feels not right, or do I miss something??
Harrie
Internet Management Consulting
mailto: [EMAIL PROTECTED] http://www.lisanza.net/
Author of MOD-SNMP, enabling SNMP management the Apache HTTP server
Re: [PATCH] Octstr function call sometime barf when called withNULL data
--On Sunday, August 11, 2002 6:38 PM +0200 Stipe Tolj <[EMAIL PROTECTED]> wrote: >> While some Octstr functions handle NULLs gracefully, others (especially >> the formating ones) do not behave so gentlemen-like. this patch will >> cause NULLs received instead of Octstr* in some cases not to panic the >> box but instead be handled in a predictable manner. > > again -1 for this, sorry Oded. > > The returns are very dangerious for functions that deal with > XML output and hence you dump a null'ed Octstr as "" cstr which > oviously will break XML structures and semantics. I see here the association with XML and I missed that. --On Sunday, August 11, 2002 8:04 PM +0300 Oded Arbel <[EMAIL PROTECTED]> wrote: > >> -Original Message- >> From: Stipe Tolj [mailto:[EMAIL PROTECTED]] > >> > Ok - you are correct here too :-). how about using (NULL) >> or [NULL] instead ? >> >> Hmm, what is exactly the problem with it now (or revision backed) is? >> I don't got the point I guess. > > this part : > seems_valid_read(ostr,file,line,func); > > where if the parameter is NULL for some reason, bearerbox panics. > I am with Oded here. If a panic can be overcome by the functionality it should be possible. Oded patch did this. Stipe, if you don't want this solution another is to handle an error all the way up to where you can recover, but panicing is to much. And for (NULL) or [NULL] I don't care. Indeed the is to close to XML. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ --- Author of MOD-SNMP, enabling SNMP management to the Apache server.
RE: [PATCH] Octstr function call sometime barf when called with NULL data
> -Original Message- > From: Stipe Tolj [mailto:[EMAIL PROTECTED]] > > Ok - you are correct here too :-). how about using (NULL) > or [NULL] instead ? > > Hmm, what is exactly the problem with it now (or revision backed) is? > I don't got the point I guess. this part : seems_valid_read(ostr,file,line,func); where if the parameter is NULL for some reason, bearerbox panics. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. We are all entitled to our own hypocracies. -- from "Bull"
Re: [PATCH] Octstr function call sometime barf when calledwithNULL data
--On Sunday, August 11, 2002 6:40 PM +0200 Stipe Tolj <[EMAIL PROTECTED]> wrote: >> This will be in my next commit today. >> I also noticed some other things like "^M' at the end of >> lines in the ChangeLog and so on. I am going thru all this. > > this has been commited already. I have to veto against this and would > like to request a revision step-back. What is the real problem with it?? I think it is quite a nice solution (used also in other packages I have seen). Harrie Internet Management Consulting mailto: [EMAIL PROTECTED] http://www.lisanza.net/ Author of MOD-SNMP, enabling SNMP management the Apache HTTP server
Re: [PATCH] SMPP octstr to long handling
> Yes - your solution is better. I'd vote +1 on Stipe's and removing my patch. btw - >what happened to unified diff format ? Ok, thanks. Harrie are you going to turn the revision wheel back or should I? 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] Octstr function call sometime barf when called with NULL data
> Ok - you are correct here too :-). how about using (NULL) or [NULL] instead ? Hmm, what is exactly the problem with it now (or revision backed) is? I don't got the point I guess. 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] SMPP octstr to long handling
> Yes - your solution is better. I'd vote +1 on Stipe's and removing my patch. btw - >what happened to unified diff format ? ehhmm, ok, you got me. I just snipped this out of WinCVS window. One drink goes to Oded on our next meeting from me :)) 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] Octstr function call sometime barf when called with NULL data
> -Original Message- > From: Stipe Tolj [mailto:[EMAIL PROTECTED]] > Sent: Sunday, August 11, 2002 6:38 PM > To: Oded Arbel > Cc: Kannel-devel (E-mail) > Subject: Re: [PATCH] Octstr function call sometime barf when > called with NULL data > > > > While some Octstr functions handle NULLs gracefully, others > (especially the formating ones) do not behave so > gentlemen-like. this patch will cause NULLs received instead > of Octstr* in some cases not to panic the box but instead be > handled in a predictable manner. > > again -1 for this, sorry Oded. > > The returns are very dangerious for functions that deal with > XML output and hence you dump a null'ed Octstr as "" cstr which > oviously will break XML structures and semantics. Ok - you are correct here too :-). how about using (NULL) or [NULL] instead ? -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. "$HOME is where your dotfiles are" -- Gym Quirk
RE: [PATCH] SMPP octstr to long handling
> -Original Message- > From: Stipe Tolj [mailto:[EMAIL PROTECTED]] > I'd suggest not to copy at the place Oded does, but in > smpp_pdu.c:smpp_pdu_pack() by taking out the assertion check and > throwing an error to the log and copy the Octstrs to the desired > length, please see patch attached. > > Votes for this solution in favour of Odeds? Yes - your solution is better. I'd vote +1 on Stipe's and removing my patch. btw - what happened to unified diff format ? -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. You cannot propel yourself forward by patting yourself on the back.
Re: [PATCH] Octstr function call sometime barf when called withNULL data
> This will be in my next commit today. > I also noticed some other things like "^M' at the end of > lines in the ChangeLog and so on. I am going thru all this. this has been commited already. I have to veto against this and would like to request a revision step-back. 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] Octstr function call sometime barf when called with NULL data
> While some Octstr functions handle NULLs gracefully, others (especially the >formating ones) do not behave so gentlemen-like. this patch will cause NULLs received >instead of Octstr* in some cases not to panic the box but instead be handled in a >predictable manner. again -1 for this, sorry Oded. The returns are very dangerious for functions that deal with XML output and hence you dump a null'ed Octstr as "" cstr which oviously will break XML structures and semantics. 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] SMPP panic when sender or receiver address longerthen20characters.
> Cool. I am commiting this. vetoing (-1) against this commit and requesting a cvs back to previous revision for the commited files. See my recent mail for reason. 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
[PATCH] SMPP octstr to long handling
Hi all,
Oded is right here I guess. bearerbox should not panic if someone
injects data (via sendsms interface) that is out of SMPP specification
scope, which is 20 octets for the source and destination number.
I'd suggest not to copy at the place Oded does, but in
smpp_pdu.c:smpp_pdu_pack() by taking out the assertion check and
throwing an error to the log and copy the Octstrs to the desired
length, please see patch attached.
Votes for this solution in favour of Odeds?
benefits:
- don't panic in case the PDU type is not known anyway.
- log a warning if a given PDU field is too long and cut it to the
specified (by spec) length.
BTW, we should not #define constants of SMPP that are explicitely
'defined' by the .def file anyway. So the 21 length for source and
destination number is already a #define in this semantical way and
hence we should *not* use #defined things in .def again.
Oded, can you try this patch instead of your own that has been
commited and vote for one of both. I'm definetly +1 for this and -1
for Odeds (sorry :), but it's a conceptual clash in my point of view.
Stipe
RCS file: /home/cvs/gateway/gw/smsc/smpp_pdu.c,v
retrieving revision 1.1
diff -r1.1 smpp_pdu.c
104c104
< panic(0, "Unknown SMPP_PDU type, internal error while
destroying.");
---
> error(0, "Unknown SMPP_PDU type, internal error while destroying.");
129c129
< panic(0, "Unknown SMPP_PDU type, internal error while
packing.");
---
> error(0, "Unknown SMPP_PDU type, internal error while packing.");
136,138c136,147
< gw_assert(octstr_len(p->name) < max_octets); \
< if (p->name != NULL) octstr_append(os, p->name); \
< octstr_append_char(os, '\0');
---
> if (p->name != NULL) { \
> if (octstr_len(p->name) >= max_octets) { \
> warning(0, "SMPP: PDU element <%s> to long " \
> "(length is %d, should be %d)", \
> #name, octstr_len(p->name), max_octets); \
> temp = octstr_copy(p->name, 0, max_octets-1); \
> } else \
> temp = octstr_duplicate(p->name); \
> octstr_append(os, temp); \
> octstr_destroy(temp); \
> } \
> octstr_append_char(os, '\0');
145c154
< panic(0, "Unknown SMPP_PDU type, internal error while
packing.");
---
> error(0, "Unknown SMPP_PDU type, internal error while packing.");
192c201
< panic(0, "Unknown SMPP_PDU type, internal error while
unpacking.");
---
> error(0, "Unknown SMPP_PDU type, internal error while unpacking.");
[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] SMPP panic when sender or receiver address longerthen20characters.
Harrie, Oded, > Cool. I am commiting this. can you please check my solution for this problem which I'm posting in a couple of minutes. I'd like to take my solution in favour of Oded's patch that has been just commited to cvs. See the mail for benefits. 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
CVS and cygwin
HI to all those working and committing from CYGWIN to CVS, I just fixed some file with the '^M' problem. This is caused in most cases by people who use cygwin and CVS. Those need to use a native CVS and not the standard cygwin cvs. The cygwin cvs lets the CVS server think it is a UNIX system, where it is a windows system. more info of native cvs can be found here: http://www.cvshome.org/dev/codewindow.html Hope this helps, Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ --- Author of MOD-SNMP, enabling SNMP management to the Apache server.
RE: [PATCH] SMPP panic when sender or receiver address longerthen20characters.
--On Sunday, August 11, 2002 4:14 PM +0300 Oded Arbel <[EMAIL PROTECTED]> wrote: > >> -Original Message- >> From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] >> >> I admit these .def files are difficult, but I believe we need to make >> a define and use that define +1 in the .def file to allcate the space >> and use the define itself in the other places. > > K - how about like this ? Cool. I am commiting this. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ --- Author of MOD-SNMP, enabling SNMP management to the Apache server.
RE: [RFC] delivery reports for concatenated messages.
> -Original Message- > From: Andreas Fink [mailto:[EMAIL PROTECTED]] > Sent: Sunday, August 11, 2002 3:41 PM > To: Oded Arbel > Cc: [EMAIL PROTECTED] > Subject: Re: [RFC] delivery reports for concatenated messages. > > > >My suggestion is to do something like this - since the message ids > >on all parts are identical, > > > Full stop. they are NOT identical. smsbox does split the message. For > the SMSC and bearerbox those are multiple unrelated messages. To do > this we would have to load bearerbox with more work and split the > message there. Yes, the message ids (msg->sms.id) is identical for each of the concatenated message parts. I'm looking at sms_split() right now, and it does not change the internal reference IDs on the message - it simply duplicate the message using the msg_duplicate() call and then changes some fields - none of which is the message ID itself. Thinking about it : doesn't this causes some mayhem with the store file ? -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. "I don't even butter my bread; I consider that cooking." -- Katherine Cebrian
Re: [RFC] delivery reports for concatenated messages.
>Hi list. > >Wanted to ask your opinion about how we should handle DLRs on a >message that get split to multiple concatenated messages. >Currently - the dlr_url is only saved for the first message, so the >originator will only receive a single DLR on the first part of the >message. while this is an obvious temporary work around, I don't >think its a correct solution. I somewhat agree but what should be the delivery report if it is partially received? >My suggestion is to do something like this - since the message ids >on all parts are identical, Full stop. they are NOT identical. smsbox does split the message. For the SMSC and bearerbox those are multiple unrelated messages. To do this we would have to load bearerbox with more work and split the message there. -- 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
[RFC] delivery reports for concatenated messages.
Hi list. Wanted to ask your opinion about how we should handle DLRs on a message that get split to multiple concatenated messages. Currently - the dlr_url is only saved for the first message, so the originator will only receive a single DLR on the first part of the message. while this is an obvious temporary work around, I don't think its a correct solution. My suggestion is to do something like this - since the message ids on all parts are identical, we can track and collate them anywhere in the boxes. since it's DLR related we'll let the DLR module handle that: - rewrite the DLR entry routines to accept the entire message structure and a module created ID - a key actually - that identifies the network's notion of the current message part : the message reference returned from the SMSC on submit, instead of the current implementation where numerous fields are required. this will allow the DLR routines to access and archive more information from the message structure, such as the message's internal reference id. - the DLR routines will collate messages that have the same internal reference id, of course tracking each parts 'external reference id'. - add another delivery report type that says something like "all parts of a concatenated message have been successfully delivered". - when a part of a concatenated message get a non-permanent delivery report notification from a module (using dlr_find), or a success delivery report, the correct delivery report is created - as it is done now. - when all parts of a concatenated message receives the "success" notification, the DLR message generated will contain the normal DLR_SUCCESS flag set and also the new DLR_MULTI_MESSAGE_COMPLETED flag set (temporary name - just a suggestion). - when a single part of a concatenated message receives a permanent failure notification (DLR_FAILED or DLR_SMSC_FAILED), dlr_find will generate the required notification, and also discard the entire collection of message parts from DLR storage, effectively invalidating any future success reports that might arrive for other parts. in addition, it would be nice if the dlr routines could garbage collect old DLR records that can be safely assumed "lost" and either just remove them from the DLR database optionally also delivering them somehow with the DLR_SMSC_FAILED flag set. I'd say that 2 days is a good time limit. Comments, please ? -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Instructions for life: 8. Spend some time alone every day.
RE: [PATCH] SMPP panic when sender or receiver address longerthen20 characters.
> -Original Message- > From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] > > I admit these .def files are difficult, but I believe we need to make > a define and use that define +1 in the .def file to allcate the space > and use the define itself in the other places. K - how about like this ? -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. I can picture in my mind a world without war, a world without hate. And I can picture us attacking that world, because they'd never expect it. -- Deep Thoughts by Jack Handy smsc_smpp.patch Description: smsc_smpp.patch
RE: [PATCH] SMPP panic when sender or receiver address longerthen20 characters.
--On Sunday, August 11, 2002 2:32 PM +0300 Oded Arbel <[EMAIL PROTECTED]> wrote: > >> -Original Message- >> From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] >> >> Hi Oded, >> >> Good catch. >> >> Forgive if I sound stupid, but regarding the length of an address. >> If it is really bigger then 20 can one just discard the part of the >> address that is longer?? > > I don't know - I don't think that there are addresses longer then 20 > chars, and if there are - these can not be used with SMPP which only > supports addresses as big as 20 chars. I'm not sure of the correct > implementation here as I have yet to see any usage examples, but we can > hold a hypothetical discussion in the list about how an address longer > then 20 chars will look like and how it should be handled if the SMSC > does not support such addresses. Not that I want to have a hypothecial discussion, but just dropping parts of an address looks weird to me. Maybe we also have to check were the address is received if it is the correct length. But anyway, making sure it is the correct length like in your patch is a good thing. It also protects against changes within Kannel of the address. > >> That sounds weird to me, or is the address only used internal in the >> smpp part as some indication?? > > The receiver address is used as the target MSISDN for the SM and the > sender address is used to inform the receiving party of who sent the SM > and where to reply too. at least the later can be alpha numeric. > >> On top of your patch, would it not be better to have the length of an >> address >> in some #define and use that?? Then changing the length is >> done in one place >> only. > > it is - in the smpp_pdu.def : > > PDU(submit_sm, > 0x0004, > HEADER > NULTERMINATED(service_type, 6) > INTEGER(source_addr_ton, 1) > INTEGER(source_addr_npi, 1) > NULTERMINATED(source_addr, 21) > INTEGER(dest_addr_ton, 1) > INTEGER(dest_addr_npi, 1) > NULTERMINATED(destination_addr, 21) > > notice the dest_addr and source_addr which are defined as 21 chars null > terminated buffers. > > -- > Oded Arbel > m-Wise mobile solutions > [EMAIL PROTECTED] > > +972-9-9581711 (116) > +972-67-340014 > > ::.. > "...[T]he lesson [comic books] taught children- or this child, at any > rate- was perhaps the unintentionally radical truth that exceptionality > was the greatest and most heroic of values; that those who were unlike > the crowd were to be treasured the most lovingly; and that this > exceptionality was a treasure so great that it had to be concealed, in > ordinary life, beneath what the comic books called a 'secret identity'." > -- Salman Rushdie > > Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ --- Author of MOD-SNMP, enabling SNMP management to the Apache server.
Re: [PATCH] Octstr function call sometime barf when called withNULL data
HI Oded, This will be in my next commit today. I also noticed some other things like "^M' at the end of lines in the ChangeLog and so on. I am going thru all this. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ --- Author of MOD-SNMP, enabling SNMP management to the Apache server.
RE: [PATCH] SMPP panic when sender or receiver address longerthen20 characters.
--On Sunday, August 11, 2002 2:46 PM +0300 Oded Arbel <[EMAIL PROTECTED]> wrote: > >> -Original Message- >> From: Oded Arbel >> > in some #define and use that?? Then changing the length is >> > done in one place >> > only. >> >> it is - in the smpp_pdu.def : > > hm. my bad - this is not what you meant. doing as you suggested is more > correct, but currently that number is only used in two lines of code (one > right after the other) and I can't see how we can extract if from the > pdu.def, so using it in a define has the single advantage of moving the > defining point from halfway down the file to the top of the file (or to > the header). I admit these .def files are difficult, but I believe we need to make a define and use that define +1 in the .def file to allcate the space and use the define itself in the other places. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ --- Author of MOD-SNMP, enabling SNMP management to the Apache server.
RE: [PATCH] SMPP panic when sender or receiver address longer then20 characters.
> -Original Message- > From: Oded Arbel > > in some #define and use that?? Then changing the length is > > done in one place > > only. > > it is - in the smpp_pdu.def : hm. my bad - this is not what you meant. doing as you suggested is more correct, but currently that number is only used in two lines of code (one right after the other) and I can't see how we can extract if from the pdu.def, so using it in a define has the single advantage of moving the defining point from halfway down the file to the top of the file (or to the header). -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. If you got the words it does not mean you got the knowledge.
RE: [PATCH] SMPP panic when sender or receiver address longer then20 characters.
> -Original Message- > From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] > > Hi Oded, > > Good catch. > > Forgive if I sound stupid, but regarding the length of an address. > If it is really bigger then 20 can one just discard the part of the > address that is longer?? I don't know - I don't think that there are addresses longer then 20 chars, and if there are - these can not be used with SMPP which only supports addresses as big as 20 chars. I'm not sure of the correct implementation here as I have yet to see any usage examples, but we can hold a hypothetical discussion in the list about how an address longer then 20 chars will look like and how it should be handled if the SMSC does not support such addresses. > That sounds weird to me, or is the address only used internal in the > smpp part as some indication?? The receiver address is used as the target MSISDN for the SM and the sender address is used to inform the receiving party of who sent the SM and where to reply too. at least the later can be alpha numeric. > On top of your patch, would it not be better to have the length of an > address > in some #define and use that?? Then changing the length is > done in one place > only. it is - in the smpp_pdu.def : PDU(submit_sm, 0x0004, HEADER NULTERMINATED(service_type, 6) INTEGER(source_addr_ton, 1) INTEGER(source_addr_npi, 1) NULTERMINATED(source_addr, 21) INTEGER(dest_addr_ton, 1) INTEGER(dest_addr_npi, 1) NULTERMINATED(destination_addr, 21) notice the dest_addr and source_addr which are defined as 21 chars null terminated buffers. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. "...[T]he lesson [comic books] taught children- or this child, at any rate- was perhaps the unintentionally radical truth that exceptionality was the greatest and most heroic of values; that those who were unlike the crowd were to be treasured the most lovingly; and that this exceptionality was a treasure so great that it had to be concealed, in ordinary life, beneath what the comic books called a 'secret identity'." -- Salman Rushdie
[PATCH] AT2 DLR: new revision
Hi list. Here's a new revision of the AT2 DLR support patch : - changed to patch cleanly against current CVS - changed TP-ST handling to be more correct (still not 100%) and better documented (in the code comments). sorry about the previous email - sent to early.. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. It is difficult to legislate morality in the absence of moral legislators. <> smsc_at2.patch Description: smsc_at2.patch
[PATCH] AT2 DLR : new revision.
Hi list. Here's a new revision of the AT2 DLR support patch : - changed to patch cleanly against current CVS - changed TP-ST handling to be more correct (still not 100%) and better documented (in the code comments).
Re: [PATCH] SMPP panic when sender or receiver address longer then20 characters.
Hi Oded, Good catch. Forgive if I sound stupid, but regarding the length of an address. If it is really bigger then 20 can one just discard the part of the address that is longer?? That sounds weird to me, or is the address only used internal in the smpp part as some indication?? On top of your patch, would it not be better to have the length of an address in some #define and use that?? Then changing the length is done in one place only. --On Sunday, August 11, 2002 1:00 PM +0300 Oded Arbel <[EMAIL PROTECTED]> wrote: > Hi list > > We encountered a bug that causes SMPP to panic when creating the PDU if > the receiver or sender address is longer then 20 characters. the panic > occures in smpp_pdu.c in smpp_pdu_pack which asserts on the length of the > source Octstr before packing it into the PDU. I don't want to change the > assert, just make sure that it will not be invoked just because the user > enetered bad data, so attached is this patch. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ --- Author of MOD-SNMP, enabling SNMP management to the Apache server.
Re: [PATCH] smsc modules directory
--On Sunday, August 11, 2002 12:20 PM +0300 Oded Arbel <[EMAIL PROTECTED]> wrote: > Hi Harrie and everyone > > I saw that smsc.c was moved to the smsc module directory (which I don't > think is write - as this is just the API implementation, not a module in > itself), but the smsc.h file was left in the gw directory. you have to > decide were to put these two files, but they should be together Maybe you are correct. I was in doubt to move the smsc.c file and smsc.h. I did move the smsc.c, since it was used under the smscconn API. Then smsc_wrapper is also moved and I consider that one as an API and a module. It is an API for the old smsc module, but it is a module since it is used from within the smscconn API. I believe this is also due to some legacy and if wanted the wrapper could be complete vapourized if the old smsc module would be ported to the smscconn API. One can argue many ways, but that is also due to the many ways various layes and APIs are made. The include file I left up there, actually incorrect. This counts even so for the smsc_p.h include file. I move them under the smsc directory. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ --- Author of MOD-SNMP, enabling SNMP management to the Apache server.
[PATCH] Octstr function call sometime barf when called with NULL data
Hi list. While some Octstr functions handle NULLs gracefully, others (especially the formating ones) do not behave so gentlemen-like. this patch will cause NULLs received instead of Octstr* in some cases not to panic the box but instead be handled in a predictable manner. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Don't hate yourself in the morning, sleep until noon. <> octstr.patch Description: octstr.patch
[PATCH] SMPP panic when sender or receiver address longer then 20 characters.
Hi list We encountered a bug that causes SMPP to panic when creating the PDU if the receiver or sender address is longer then 20 characters. the panic occures in smpp_pdu.c in smpp_pdu_pack which asserts on the length of the source Octstr before packing it into the PDU. I don't want to change the assert, just make sure that it will not be invoked just because the user enetered bad data, so attached is this patch. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. "I realized that the purpose of writing is to inflate weak ideas." -- Calvin and Hobbes <> smsc_smpp.patch Description: smsc_smpp.patch
Re: [PATCH] smsc modules directory
Hi Harrie and everyone I saw that smsc.c was moved to the smsc module directory (which I don't think is write - as this is just the API implementation, not a module in itself), but the smsc.h file was left in the gw directory. you have to decide were to put these two files, but they should be together (oh, I'm a hopeless romantic ;-) -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Today is the tomorrow you worried about yesterday.
