On 26.03.2009, at 07:50, jyoti wrote:
Hi,
If we use sms for push over ss7 E1 link.i.e directly connected to MSC,
instead of SMSC(SMPP),Does we will get an advantage?
if yes can we devlop kannel to support the above?
Waiting for Any suggestion.
Thanks & Regards
Jyoti Ranjan Panda
This is wh
On Fri, 2009-03-27 at 11:51, Andreas Fink wrote:
> On 26.03.2009, at 07:50, jyoti wrote:
>> If we use sms for push over ss7 E1 link.i.e directly connected to MSC,
>> instead of SMSC(SMPP),Does we will get an advantage?
>> if yes can we devlop kannel to support the above?
[...]
> This is what we hav
The issue is located on the mtbatch program that exit before receiving all
ack/nack from bearerbox.
(btw, Thanks to alex pointing me this)
The result is an TCP broken pipe System error 104: Connection reset by peer
This patch fixes this.
Vincent.
--
Telemaque - 06560 SOPHIA-ANTIPOLIS - (FR)
Hi,
A small patch that left as it is should lead to memory corruption. I have not
tested the broken code but it seems quite obvious to me. Please vote & decide.
BR,
Nikos
http.diff
Description: Binary data
Another sweet one. This one would lead to infinite loops, but I guess it is not
used. Nevertheless pitty to have it like that. Please vote and decide. It is a
PPG one.
BR,
Nikos
wap-appl.diff
Description: Binary data
Hi nikos,
I could not understand this patch !?
If `from+len' is after the end of `ostr', `len' is reduced appropriately.
So what's wrong here ?
Vincent.
Nikos Balkanas a écrit :
Hi,
A small patch that left as it is should lead to memory corruption. I
have not tested the broken code but it
Hi,
The mistake here is that this is done with memcpy, which will copy all bits
without checking. It is not writing, therefore no memory corruption, as I
stated, but the copied data in Octstr is invalid and has the wrong length.
Not a biggie if you are using it as a C string, but quite messy i
Nikos Balkanas schrieb:
>
> The mistake here is that this is done with memcpy, which will copy all
> bits without checking. It is not writing, therefore no memory
> corruption, as I stated, but the copied data in Octstr is invalid and
> has the wrong length. Not a biggie if you are using it as a C
Hi Stipe,
This is not a segfault, my mistake as I already indicated. It is just copied
from an invalid area. Since the allocated memory is valid, no problem so
far, unless the contents are accessed as an Octstr (through ostr->len)
instead of C-string. In that case you will get garbadge at the