bearerbox segfaults on Mac OS X 10.7 Lion
Hi, Since upgrading to OS X 10.7, bearerbox segfaults on startup. Here's a gdb backtrace: 2011-07-31 01:24:03 [45285] [0] DEBUG: Started thread 6 (gw/smsc/smsc_smpp.c:io_thread) 2011-07-31 01:24:03 [45285] [6] DEBUG: Thread 6 (gw/smsc/smsc_smpp.c:io_thread) maps to pid 45285. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0419000cbd70 [Switching to process 45285 thread 0x1a03] 0x00010008f41d in log_thread_to (idx=4294967295) at log.c:717 717 info(0, Logging thread `%ld' to logfile `%s' with level `%d'., (gdb) backtrace #0 0x00010008f41d in log_thread_to (idx=4294967295) at log.c:717 #1 0x0001000681f7 in io_thread (arg=0x101) at smsc_smpp.c:1908 #2 0x000100085c72 in new_thread (arg=0x1018031f0) at gwthread-pthread.c:362 #3 0x7fff92f358bf in _pthread_start () #4 0x7fff92f38b75 in thread_start () Has anyone else encountered this so far on Lion and figured a workaround? Thanks, Nii
Re: HTTP Generic relay and prevent splitting long messages
Take a look at the max-sms-octets setting under config group smsc. Nii On May 30, 2011, at 9:03 PM, Tomasz wrote: I've tried it but the only difference is that kannel doesn't add UDH parameter. Message is still splitted into parts. Tomasz Try concatenation = false in group = sendsms-user. == Rene -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Tomasz Sent: Monday, 30 May, 2011 22:38 To: users@kannel.org Subject: HTTP Generic relay and prevent splitting long messages Hello group, The company I'm working in need access to specific SMSC which doesn't provide SMPP access. I'm forced to use their HTTP API and connect to it using Kannel HTTP-based relay (generic system-type). Everything works fine if message is up to 160 chars. Above Kannel splits messages as normally, adds UDH for each part and sends it independently to SMSC. But the SMSC doesn't support UDH, and it want to get one long message (in one string) - splitting and concatenating is done at their side. If kannel splits message, the recipient receives several messages which are not concatenated on his mobile but they are independent ones. Is it possible to configure Kannel to not splitting messages when using http based relay (generic) but to send them at one part to SMSC? BR, Tomasz
alt-charset on HTTP SMSCs
Hello, Does anyone have experience with converting between different character encoding schemes for HTTP SMSCs? Here's the scenario I'm facing: I receive messages via SMPP interface in encoded as UCS-2. I need to send these messages out formatted as UTF-8 to an HTTP SMSC. For some reason defining the alt-charset as UTF-8 (or anything else, for that matter) doesn't seem to have an effect on what is sent out in the HTTP call. Does the alt-charset directive work with HTTP SMSCs? Any help will be greatly appreciated. Thanks, Nii.
Re: alt-charset on HTTP SMSCs
The mclass switch isn't set. I forgot to mention I'm dealing with an HTTP SMSC of type generic. The send-url interface for this is extremely limited and basically only allows me to pass the following parameters: from, to, msg Is there any work around for applying a specific coding scheme to the message? Thanks, Nii. On Thu, 2009-02-12 at 16:01 +0100, Falko Ziemann wrote: Yeah, I think everyone had this problem once: when the mclass switch is set, the alt-charset is ignored. Regards Falko Am 12.02.2009 um 15:39 schrieb Nii Ako Ampa-Sowa: Hello, Does anyone have experience with converting between different character encoding schemes for HTTP SMSCs? Here's the scenario I'm facing: I receive messages via SMPP interface in encoded as UCS-2. I need to send these messages out formatted as UTF-8 to an HTTP SMSC. For some reason defining the alt-charset as UTF-8 (or anything else, for that matter) doesn't seem to have an effect on what is sent out in the HTTP call. Does the alt-charset directive work with HTTP SMSCs? Any help will be greatly appreciated. Thanks, Nii. -- Rancard Solutions Ltd Web: www.rancardmobility.com mobile: +233 24 987 9795 office: +233 28 952 9573
