Re: SMS over SS7

2009-03-27 Thread Andreas Fink
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

Re: SMS over SS7

2009-03-27 Thread Milan P. Stanic
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 have been

[PATCH] Fix bug #495 - System error 104: Connection reset by peer

2009-03-27 Thread Vincent CHAVANIS
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 -

gwlib/http.c patch

2009-03-27 Thread Nikos Balkanas
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

gw/wap-appl.c

2009-03-27 Thread Nikos Balkanas
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

Re: gwlib/http.c patch

2009-03-27 Thread Vincent CHAVANIS
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

Re: gwlib/http.c patch

2009-03-27 Thread Stipe Tolj
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

Re: gwlib/http.c patch

2009-03-27 Thread Nikos Balkanas
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