Re: [Users] Comverse MMSC SMIL problem
On Sat, Dec 24, 2011 at 08:57:49AM +0300, abdirezak musse yusuf wrote: please send to me too. sent pgp6xMLLRteWc.pgp Description: PGP signature ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] when i run MMSBOX command it say unable to find Mbuni.conf
On Thu, Dec 22, 2011 at 08:18:18AM +0300, abdirezak musse yusuf wrote: [root@localhost mbuni-1.5.0]# mmsbox2011-11-13 04:22:51 [15691] [0] INFO: Debug_lvl = -1, log_file = none, log_lvl = 02011-11-13 04:22:51 [15691] [0] ERROR: fopen failed: couldn't open `mbuni.conf'2011-11-13 04:22:51 [15691] [0] ERROR: System error 2: No such file or directory2011-11-13 04:22:51 [15691] [0] ERROR: mms_cfg.c:151 mms_cfg_read [mms_cfg] [n/a] failed to read config from `mbuni.conf'2011-11-13 04:22:51 [15691] [0] ERROR: System error 2: No such file or directory2011-11-13 04:22:51 [15691] [0] ERROR: mmsbox_cfg.c:119 mms_load_mmsbox_settings [mmsbox] [n/a] Couldn't read configuration from 'mbuni.conf'.2011-11-13 04:22:51 [15691] [0] PANIC: Configuration file loading failed, file: mbuni.conf2011-11-13 04:22:51 [15691] [0] PANIC: mmsbox(gw_panic+0xc2) [0x80a1b22]2011-11-13 04:22:51 [15691] [0] PANIC: mmsbox(main+0x3fb) [0x80544ab]2011-11-13 04:22:51 [15691] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xdc) [0x506e8c]2011-11-13 04:22:51 [15691] [0] PANIC: mmsbox [0x8053ff1] PLEASE help if you can see any mistake in this operation. also tell me the directory of the mbuni.conf and give me a sample mbuni.conf file. when running mmsbox like that, make sure that you give it a path to it's config file as a command line argument. pgpwFbI52ExwR.pgp Description: PGP signature ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
[Users] Comverse MMSC SMIL problem
Hi, About a month ago I started to have problems with one of operators when sending via MM1 interface... They accept m-send-reqs and properly respond with m-send-confs. The problem is that when message contains SMIL it isn't delivered to the destination address. If I send plain text, or image message (without SMIL) it's being delivered correctly. SMIL messages sent via other operators' MMSCs are handled correctly. I suspect that the problem here is caused by a kind of software upgrade/reconfiguration on the operator's side. I'm unable to verify this with them however. It appears that their Customer Care Department has been hired as a firewall between the customer and the rest of the company. My most successful conversation with them resulted in sending me configuration messages for MMS service ;/ I've spent a lot of time experimenting with various combinations of m-send-req and SMIL contents. It appears that whether the message is being handled properly or not depends on SMIL presence. Maybe someone had similar problems and would like to comment on this? Response headers tell me that their current gateway is Comverse 4.5 Regards, Piotr pgpR3vFKHayQe.pgp Description: PGP signature ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] Huawei config
On 2011-04-18, at 09:32, Stanisław Czech wrote: I have no problems sending and recieving sms, and sending MMS but i can't recieve any MMS. Does anyone have some clues where there can be a problem? smsbox see's nothing when I send mms from a mobile to the mbuni's modem. In kannel.conf I have: group = sms-service keyword-regex = .* catch-all = true max-messages = 0 get-url = http://localhost/run.php concatenation = true group = sms-service keyword = default catch-all = true get-url = http://localhost:13014/?text=%b max-messages = 0 concatenation = true First thing to do is to make kannel to see an incoming mms notification (wap-push) and dispatch it via the proper service to mbuni. If you don't see ANY incoming message in kannel, that could mean one of two: - something is broken in the delivery chain before kannel (you can check this by removing a SIM card from modem, placing it in a phone and checking if you receive incoming MMS messages) - Huawei modems do not support incoming wap push messages (in that case the only solution I can think about is to change your modem) As for dispatch part: you have two concurrent services defined in kannel. There is a chance they will compete for the same message so it will never be routed to mbuni. So remove the first service definition until you will be able to receive an MMS. Then you can make your config more complex again. PGP.sig Description: This is a digitally signed message part ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] Huawei config
On 2011-04-18, at 10:20, Stanisław Czech wrote: First thing to do is to make kannel to see an incoming mms notification (wap-push) and dispatch it via the proper service to mbuni. If you don't see ANY incoming message in kannel, that could mean one of two: - something is broken in the delivery chain before kannel (you can check this by removing a SIM card from modem, placing it in a phone and checking if you receive incoming MMS messages) - Huawei modems do not support incoming wap push messages (in that case the only solution I can think about is to change your modem) As for dispatch part: you have two concurrent services defined in kannel. There is a chance they will compete for the same message so it will never be routed to mbuni. So remove the first service definition until you will be able to receive an MMS. Then you can make your config more complex again. After half an hour I got in smsbox logs: 2011-04-18 07:18:55 [9017] [4] INFO: Starting to service Nowa wiadomosc multimedialna od +48 na http://foto.plus.pl MMS_id: haslo: xxx from Centrum MMS to +48x This means I got sms msg that I have a new mulitmedia msg that I can download form the website. As far as I understand this means that my operator couldn't send MMS directly due to incompatible the hardware/missing configuration. Or that means your account isn't configured for direct delivery of MMS notification. Contact your operator tech support and ask them to check if they can configure your card for direct mms delivery (or test via mobile phone - it should show a difference). I've tried to test different op (Orange) and the result seems to be the same (sms works both ways, no recieving mms) I will try using only one rule to see if it makes any difference but I don't think it will help. I already ordered OPTION iCON 505 MODEM so I will see if there will be any difference in behaviour. Greetings, Stanislaw Czech NOWATEL Sp. z o.o. http://www.nowatel.com ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users PGP.sig Description: This is a digitally signed message part ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] Huawei config
Maybe there is some secret knowledge needed for making Huawei modem work with this. I don't know :-( On 2011-04-18, at 11:20, Stanisław Czech wrote: It seems Huawei is incapable of recieving MMS. Is there a way to check it to be sure? I found on other forums: http://broadbandforum.in/bsnl-3g/63542-mms-setting-bsnl-3g-huawei/ Seems like no one has been successfully able to use MMS functionality using Huawei modem On the other hand, NOWSMS seems to support it: http://www.nowsms.com/sms-and-mms-with-the-huawei-e160-usb-modem PGP.sig Description: This is a digitally signed message part ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] Huawei config
On 2011-04-18, at 11:55, Paul Bagyenda wrote: I don't think there is a secret. Receipt of the notification is *purely* via SMS. Which means that Mbuni hasn't even kicked in yet. Basically MMS reception at the network works like this: The operator MMSC checks (HLR, whatever) if receiving subscriber's device is MMS-capable. If not, subscriber receive SMS (as you have done). This is the important bit. Typically the operator can flag your account so MMS is *always* sent to you as MMS, whether or not your device is known to support MMS. Maybe yes, maybe no. The other truth is that most modem vendors currently focus on Internet access functionality. I.e. Sierra Wireless modems does not support USSD commands. Operator may fall back to SMS notification if device does not respond to a push in a specific period of time. Maybe one need use some vendor specific AT command to activate receiving of push notifications. After all I'm here arguing about something I'm not able to verify. It needs be tested by someone with Huawei modem. PGP.sig Description: This is a digitally signed message part ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] Huawei config
I can only say, that it (505) works for me, but I'm using it on different network, so if it's an operator related issue, it may happen you will have the same problem with Option. P. On 2011-04-18, at 12:11, Stanisław Czech wrote: Nevertheless could someone confirm that Option Icon modems (like 505) have native MMS support? Or I will also need to contact the operator to flag it as mms capable. PGP.sig Description: This is a digitally signed message part ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] Huawei config
looks like one of mm1 threads not being started... That would rather be due to some of ports being blocked by some other app than because of modem-specific problem. Check your MM1 config for port conflicts. Regards, Piotr On Fri, Apr 15, 2011 at 03:39:26PM +0200, Stanisław Czech wrote: Welcome, Would be helpful yes. I still did not get this config too. Thats a pity. I tried and got the same result as you did: 2011-04-15 15:23:11 [29837] [7] DEBUG: Queued to thread 2 for /var/spool/mbuni/mmsbox_outgoing/1/9l/qf3489.1.x837.54, sendt=1302873790, tnow=1302873791 2011-04-15 15:23:11 [29837] [15] ERROR: bearerbox.c:1679 process_send_res [MM7] [n/a] Retry later MMSBox Outgoing Queue MMS Send: From 100/TYPE=PLMN, to 48/TYPE=PLMN, msgsize=98: internal error, mm1 notify not started! I tired Kannel 1.4.3 with recent Mbuni 1.5.0 without any luck. As far as I can see everything 'by hand' works ok (ppp connection, stoping and starting service) but thoes actions are not even executed. Sending sms by pure Kannel works ok. I use: Bus 001 Device 002: ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem Any advice? My configs: ___ mmsbox.conf group = core log-file = /var/log/kannel/mmsbox.log access-log = /var/log/kannel/mmsbox-access.log log-level = 0 group = mbuni storage-directory = /var/spool/mbuni max-send-threads = 5 maximum-send-attempts = 50 default-message-expiry = 36 queue-run-interval = 5 send-attempt-back-off = 300 sendmms-port = 10001 sendsms-url = http://localhost:6113/cgi-bin/sendsms sendsms-username = ginn sendsms-password = ginn # Sample conf for MMSBox using a modem (MM1) group = mmsc id = modem type = custom #custom-settings = smsc-on=lynx -dump 'http://localhost:13000/start-smsc?password=kirasmsc=moj';smsc-off=lynx -dump 'http://localhost:13000/stop-smsc?password=kirasmsc=moj';gprs-on=pon plus; gprs-pid=cat /var/run/ppp0.pid | head - mmsc-library = /usr/local/lib/libmmsbox_mm1.so group = send-mms-user username = ginn password = ginn faked-sender = 100 ___ kannel.conf # Default kannel configuration file group = core admin-port = 13000 admin-password = kira status-password = kira admin-deny-ip = *.*.*.* admin-allow-ip = 127.0.0.1;192.168.*.* smsbox-port = 13001 wapbox-port = 13002 #box-deny-ip = *.*.*.* box-allow-ip = 127.0.0.1 wdp-interface-name = * log-file = /var/log/kannel/kannel.log log-level = 1 access-log = /var/log/kannel/kannel.access group = smsbox bearerbox-host = localhost sendsms-port = 6113 global-sender = 6113 sendsms-chars = 0123456789 access-log = /var/log/kannel/kannel.access log-file = /var/log/kannel/smsbox.log log-level = 0 group = sendsms-user username=ginn password=ginn max-messages = 10 concatenation = true group = smsc smsc-id = moj smsc = at port = 1 modemtype = huawei_e220_00 device = /dev/ttyUSB0 sms-center = +48601000310 my-number = +48663837206 connect-allow-ip = 127.0.0.1;192.168.*.* group = modems id = huawei_e220_00 name = Huawei E220 detect-string = huawei init-string = AT+CNMI=2,1,2,2,0 message-storage = sm speed = 460800 #The sms-service group configures how Kannel gets messages to your web application. group = sms-service keyword = default text = No service specified group = sms-service #keyword = keyword-regex = .* catch-all = yes max-messages = 0 get-url = www.whatever.net group = sms-service keyword = default catch-all = true get-url = http://localhost:13014/?text=%b # kannel sends the binary data from #the message(%b) to mbuni #denied-prefix = income sms accepted max-messages = 0 concatenation = true group = wapbox bearerbox-host = localhost log-file = /var/log/kannel/wapbox.log log-level = 0 syslog-level = 0 timer-freq = 10 map-url = http://mms/* http://localhost:13014; ___ In logs I have: 2011-04-15 15:16:46 [29803] [0] INFO: Added logfile `/var/log/kannel/kannel.log' with level `1'. 2011-04-15 15:16:46 [29803] [0] INFO: Started access logfile `/var/log/kannel/kannel.access'. 2011-04-15 15:16:46 [29803] [0] INFO: HTTP: Opening server at port 13000. 2011-04-15 15:16:46 [29803] [0] INFO: BOXC: 'smsbox-max-pending' not set, using default (100). 2011-04-15 15:16:46 [29803] [0] INFO: Set SMS resend frequency to 60 seconds. 2011-04-15 15:16:46 [29803] [0] INFO: SMS resend retry set to unlimited. 2011-04-15 15:16:46 [29803] [0] INFO: DLR rerouting for smsc id moj disabled. 2011-04-15 15:16:46 [29803] [0] INFO: AT2[moj]: configuration shows modemtype huawei_e220_00 2011-04-15 15:16:46 [29803] [0] INFO: AT2[moj]: read modem definition for Huawei E220 2011-04-15 15:16:46 [29803] [0] INFO: Adding interface * 2011-04-15 15:16:46 [29803] [0] INFO:
Re: [Users] Huawei config
As for mmsc settings, here are mine: custom-settings = smsc-on=lynx -dump 'http://localhost:13000/start-smsc?password=barsmsc=modemsmsc';smsc-off=lynx -dump 'http://localhost:13000/stop-smsc?password=barsmsc=modemsmsc';gprs-on=/usr/local/mbuni/sbin/start-mms-gprs;gprs-pid=cat /var/run/ppp-mms.pid|head -1;port=13014;mmsc-url=http://mms.orange.pl;proxy=192.168.6.104:8080;msisdn=0048505505505; those work well for Orange, and similar ones work with P4. I use CVS versions for kannel mbuni (but mbuni recently advanced to next release, so it's better to start with it). Also note, that kannel is only relevant if you want to receive mms messages or send push notifications to mobile phones. For sending mms messages you don't need running kannel. You only need it's gwlib to compile mbuni. I had no chance to play with Huawei, but I can tell that Option modems work without problems. On Fri, Apr 15, 2011 at 08:25:34PM +0200, Stanisław Czech wrote: I haven't upgrade to current stable yet, so I don't know if my comment will be appropriate for you, however, I think in mmsc section you should uncomment custom settings, and provide setting for port (i.e. port=8976). That's the port on which MM1 module will listen for incoming notifications, and perhaps lack of this setting makes it impossible for notify thread to start. I did. It was commented since I wanted to know if it makes any difference. With and without custom settings parameter the same error occurs. What kind of version setup is known to be the most stable/proven (kannel/mbuni) ? Maybe you could suggest any known to work combination of mm1 modem and kannel/mbuni version that is available on polish market? Greetings, Stanislaw Czech NOWATEL Sp. z o.o. http://www.nowatel.com ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users pgpuDw4lAsSkb.pgp Description: PGP signature ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] Most suitable GSM/GPRS/3G modem
http://www.mail-archive.com/search?l=users%40mbuni.orgq=%22MM1+modems%22 On Sat, Dec 11, 2010 at 08:53:34PM -0800, luke devon wrote: Hi I would like to check with you , what would be most suitable GSM/GPRS/3G modem that we can use with MBUNI VAS Gateway? Since I do not have access to an operator MMSC I need to use a modem to send and receive MMS. Thank you Luke ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users pgpdBw2obohUa.pgp Description: PGP signature ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] utf-8 subject in outgoing messages
On Thu, Nov 25, 2010 at 11:19:32AM +0100, Piotr Isajew wrote: 0x16 0xea: looks like encoding indication for me, doesn't match utf-8 above, I'm not sure, why 0xEA is an indication of UTF-8 charset (i'm not sure why it differs from the value I quoted before) and 0x16 is a number of octets in subject including charset octet and null-terminator. I think the fix would need to modify mms_pack_well_known_field(), create separate case for MMS_HEADER_SUBJECT and push those two octets into os before call to wsp_pack_text() Paul, what do you think about this? pgpy0fK3uKDQd.pgp Description: PGP signature ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] MM1 modems
Option Icon 505: outgoing traffic is fine, incoming: not tested yet On Wed, Sep 01, 2010 at 07:28:04AM +0300, Paul Bagyenda wrote: I am compiling a list of modems that have been successfully used with the Mbuni MM1 mmsbox plugin (i.e. works fully for message exchange). Kindly let me know, those who have used these. I will then put up a list that can be of use to others. Thanks Paul. ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users pgpoHsQ40GHDR.pgp Description: PGP signature ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] Mbuni mm1 problem
Just guessing, but from response dump in logs you sent it looks like MMSC gateway (or something you communicate to) is unable to parse your submit request. If I were you I would check if I connect to correct (MMS) APN, and if both mmsc-url and proxy settings are OK. On Fri, Sep 10, 2010 at 10:00:35AM +, Dr Ox wrote: Hi list, Am trying to use Mbuni MM1 library to send MMS through GPRS using a GSM modem.Connection to operator is done but still getting an error. This is a part of the mmsbox logs: 2010-09-10 17:32:52 [20358] [15] INFO: mmsbox.c:1613 dispatch_sendmms_recv [mmsbox] [n/a] MMSBox.mmssend: u=x, Queued [Accepted: Mbuni-msg.1172.x2.58.0] 2010-09-10 17:32:56 [20358] [8] DEBUG: Queued to thread 3 for /var/www/html/mms/mmsbox_outgoing/qf1172.2.x358.20, sendt=128472, tnow=128476 2010-09-10 17:33:06 [20358] [5] INFO: mmsbox_mm1.c:659 start_gprs [mmsbox-mm1] [n/a] waiting for connection: 0, pid=21677 cpid=0, ifexited=1, exitstatus=5 2010-09-10 17:33:11 [20358] [5] INFO: mmsbox_mm1.c:379 handle_mm1 [mmsbox-mm1] [n/a] start_gprs returned PID: 21677 2010-09-10 17:33:11 [20358] [5] DEBUG: WSP: Mapping `text/plain', WSP 1.2 to 0x0003. 2010-09-10 17:33:13 [20358] [5] INFO: mmsbox_mm1.c:589 write_octstr_data [mmsbox-mm1] [n/a] write_data called with nmemn=401, size=1 2010-09-10 17:33:13 [20358] [5] WARNING: Error parsing application-header. 2010-09-10 17:33:13 [20358] [5] DEBUG: Octet string at 0x9e60348: 2010-09-10 17:33:13 [20358] [5] DEBUG: len: 401 2010-09-10 17:33:13 [20358] [5] DEBUG: size: 1024 2010-09-10 17:33:13 [20358] [5] DEBUG: immutable: 0 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 27 31 ?xml version='1 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 2e 30 27 3f 3e 0a 3c 21 44 4f 43 54 59 50 45 20 .0'?.!DOCTYPE 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 68 74 6d 6c 20 50 55 42 4c 49 43 20 27 2d 2f 2f html PUBLIC '-// 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 57 41 50 46 4f 52 55 4d 2f 2f 44 54 44 20 58 48 WAPFORUM//DTD XH 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 54 4d 4c 20 4d 6f 62 69 6c 65 20 31 2e 30 2f 2f TML Mobile 1.0// 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 45 4e 27 0a 27 68 74 74 70 3a 2f 2f 77 77 77 2e EN'.'http://www. 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 77 61 70 66 6f 72 75 6d 2e 6f 72 67 2f 44 54 44 wapforum.org/DTD 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 2f 78 68 74 6d 6c 2d 6d 6f 62 69 6c 65 31 30 2e /xhtml-mobile10. 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 64 74 64 27 3e 0a 3c 68 74 6d 6c 20 78 6d 6c 6e dtd'.html xmln 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 73 3d 27 68 74 74 70 3a 2f 2f 77 77 77 2e 77 33 s='http://www.w3 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 2e 6f 72 67 2f 31 39 39 39 2f 78 68 74 6d 6c 27 .org/1999/xhtml' 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 3e 0a 3c 68 65 61 64 3e 0a 3c 74 69 74 6c 65 3e .head.title 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 54 68 65 20 72 65 71 75 65 73 74 20 66 61 69 6c The request fail 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 65 64 3c 2f 74 69 74 6c 65 3e 0a 3c 2f 68 65 61 ed/title./hea 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 64 3e 0a 3c 62 6f 64 79 3e 0a 3c 70 3e 3c 62 69 d.body.pbi 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 67 3e 54 68 65 20 72 65 71 75 65 73 74 20 69 73 gThe request is 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 20 6e 6f 74 20 75 6e 64 65 72 73 74 6f 6f 64 2enot understood. 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 3c 2f 62 69 67 3e 3c 2f 70 3e 0a 3c 70 3e 0a 3c /big/p.p. 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 69 3e 54 65 63 68 6e 69 63 61 6c 20 64 65 73 63 iTechnical desc 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 72 69 70 74 69 6f 6e 3a 3c 2f 69 3e 3c 62 72 2f ription:/ibr/ 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 3e 34 30 30 20 42 61 64 20 52 65 71 75 65 73 74 400 Bad Request 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 20 2d 20 43 68 65 63 6b 20 79 6f 75 72 20 73 70- Check your sp 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 65 6c 6c 69 6e 67 20 66 6f 72 20 74 68 65 20 72 elling for the r 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 65 71 75 65 73 74 65 64 20 55 52 4c 2e 3c 2f 70 equested URL./p 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 3e 0a 3c 2f 62 6f 64 79 3e 0a 3c 2f 68 74 6d 6c ./body./html 2010-09-10 17:33:13 [20358] [5] DEBUG: data: 3e 2010-09-10 17:33:13 [20358] [5] DEBUG: Octet string dump ends. 2010-09-10 17:33:13 [20358] [5] ERROR: mmsbox_mm1.c:499 handle_mm1 [mmsbox-mm1] [n/a] Sending failed: (none), (none)! 2010-09-10 17:33:13 [20358] [5] INFO: mmsbox_mm1.c:524 handle_mm1 [mmsbox-mm1] [n/a] GPRS turned off returned: 0 2010-09-10 17:33:13 [20358] [22] INFO: mmsbox_mm1.c:345 send_msg
Re: [Users] Re : Mbuni mm1 problem
Hi,
I don't think I could add anything more than I wrote
previously. Response you get from server mbuni tries to talk to gives
error 400 ('Bad Request! Check spelling of requested URL'). I had
similar problem when I used wrong URL (mmsc-url setting). It could
happen if you use proxy where you shouldn't or give mmsc ip as proxy
where it uses different ip. I cannot say what's specifically wrong in
your case because: first - I don't know the configuration settings of
network you use to send MMS and second - you blanked IP addresses and
URL in your config.
I also wonder why you used port=8080 setting. It's nothing technically
illegal in it but it's a well known port for proxies so IMHO it's not
a good idea to use it for your listener thread.
Kind regards,
Piotr
On Fri, Sep 10, 2010 at 10:45:10AM +, Dr Ox wrote:
Hi Piotr
Thanks for your fast response and let me provide you with more logs.
mmsbox logs
2010-09-10 18:02:20 [21803] [3] DEBUG: HTTP: Creating HTTPClient for
`xxx.xxx.xxx.xxx'.
2010-09-10 18:02:20 [21803] [3] DEBUG: HTTP: Created HTTPClient area
0x8b71f70.
2010-09-10 18:02:20 [21803] [14] DEBUG: WSP: Mapping `text/plain', WSP 1.2 to
0x0003.
2010-09-10 18:02:20 [21803] [14] INFO: mmsbox.c:1366 make_and_queue_msg
[mmsbox] [n/a] MMSBox: Queued message from service [sendmms-user], [transid
[Mbuni-msg.2940.x1.3.84]: b-qf2940.1.x803.41
2010-09-10 18:02:20 [21803] [14] DEBUG: HTTP: Destroying HTTPClient area
0x8b71f70.
2010-09-10 18:02:20 [21803] [14] DEBUG: HTTP: Destroying HTTPClient for
`xxx.xxx.xxx.xxx'.
2010-09-10 18:02:20 [21803] [14] INFO: mmsbox.c:1613 dispatch_sendmms_recv
[mmsbox] [n/a] MMSBox.mmssend: u=know1221, Queued [Accepted:
Mbuni-msg.2940.x1.3.84]
2010-09-10 18:02:24 [21803] [8] DEBUG: Queued to thread 0 for
/var/www/html/mms/mmsbox_outgoing/b/qf2940.1.x803.41, sendt=1284112940,
tnow=1284112944
SMSC `TEST' shut down
arg 0: pppd
arg 1: call
arg 2: test-auth
chat: Sep 10 18:02:31 CONNECT 115200
Serial connection established.
using channel 32
Using interface ppp0
Connect: ppp0 -- /dev/ttyUSB0
sent [LCP ConfReq id=0x1 asyncmap 0x0 magic 0x25ad635a pcomp accomp]
rcvd [LCP ConfRej id=0x1 magic 0x25ad635a]
sent [LCP ConfReq id=0x2 asyncmap 0x0 pcomp accomp]
rcvd [LCP ConfAck id=0x2 asyncmap 0x0 pcomp accomp]
rcvd [LCP ConfReq id=0x1 mru 1500 asyncmap 0x0 pcomp accomp auth
pap]
sent [LCP ConfAck id=0x1 mru 1500 asyncmap 0x0 pcomp accomp auth
pap]
sent [PAP AuthReq id=0x1 user=xxx password=hidden]
cat: /var/run/ppp0-mbuni.pid: No such file or directory
2010-09-10 18:02:34 [21803] [5] INFO: mmsbox_mm1.c:659 start_gprs
[mmsbox-mm1] [n/a] waiting for connection: 0, pid=21829 cpid=0, ifexited=1,
exitstatus=0
rcvd [PAP AuthAck id=0x1 Welcome!]
Remote message: Welcome!
PAP authentication succeeded
sent [CCP ConfReq id=0x1 deflate 15 deflate(old#) 15]
sent [IPCP ConfReq id=0x1 addr 0.0.0.0 ms-dns1 0.0.0.0 ms-dns3 0.0.0.0]
rcvd [IPCP ConfReq id=0x1 addr 192.168.111.111]
sent [IPCP ConfAck id=0x1 addr 192.168.111.111]
rcvd [LCP ProtRej id=0x20 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [IPCP ConfNak id=0x1 addr 10.236.116.182 ms-dns1 xxx.xxx.xxx.xxx
ms-dns3 xxx.xxx.xxx.xxx]
sent [IPCP ConfReq id=0x2 addr 10.236.116.182 ms-dns1 xxx.xxx.xxx.xxx
ms-dns3 xxx.xxx.xxx.xxx]
rcvd [IPCP ConfAck id=0x2 addr 10.236.116.182 ms-dns1 xxx.xxx.xxx.xxx
ms-dns3 xxx.xxx.xxx.xxx]
local IP address 10.236.116.182
remote IP address 192.168.111.111
primary DNS address xxx.xxx.xxx.xxx
secondary DNS address xxx.xxx.xxx.xxx
Script /etc/ppp/ip-up started (pid 21847)
Script /etc/ppp/ip-up finished (pid 21847), status = 0x0
2010-09-10 18:02:39 [21803] [5] INFO: mmsbox_mm1.c:379 handle_mm1
[mmsbox-mm1] [n/a] start_gprs returned PID: 21829
2010-09-10 18:02:39 [21803] [5] DEBUG: WSP: Mapping `text/plain', WSP 1.2 to
0x0003.
2010-09-10 18:02:41 [21803] [5] INFO: mmsbox_mm1.c:589 write_octstr_data
[mmsbox-mm1] [n/a] write_data called with nmemn=401, size=1
2010-09-10 18:02:41 [21803] [5] WARNING: Error parsing application-header.
2010-09-10 18:02:41 [21803] [5] DEBUG: Octet string at 0x8b71f88:
2010-09-10 18:02:41 [21803] [5] DEBUG: len: 401
2010-09-10 18:02:41 [21803] [5] DEBUG: size: 1024
2010-09-10 18:02:41 [21803] [5] DEBUG: immutable: 0
2010-09-10 18:02:41 [21803] [5] DEBUG: data: 3c 3f 78 6d 6c 20 76 65 72 73
69 6f 6e 3d 27 31 ?xml version='1
2010-09-10 18:02:41 [21803] [5] DEBUG: data: 2e 30 27 3f 3e 0a 3c 21 44 4f
43 54 59 50 45 20 .0'?.!DOCTYPE
2010-09-10 18:02:41 [21803] [5] DEBUG: data: 68 74 6d 6c 20 50 55 42 4c 49
43 20 27 2d 2f 2f html PUBLIC '-//
2010-09-10 18:02:41 [21803] [5] DEBUG: data: 57 41 50 46 4f 52 55 4d 2f 2f
44 54 44 20 58 48 WAPFORUM//DTD XH
2010-09-10 18:02:41 [21803] [5] DEBUG: data: 54 4d 4c 20 4d 6f 62 69 6c 65
20 31 2e 30 2f 2f TML Mobile 1.0//
2010-09-10 18:02:41 [21803]
[Users] Re: MM1 Modems
Option iCON 031: works pgpBMYGLhaFDD.pgp Description: PGP signature ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] Mbuni MM1 behavior regarding ppp connection and MMS stored in queue
On Mon, Aug 09, 2010 at 06:52:01PM +1100, Emmanuel CHANSON wrote: I already reported this behavior but I think it is better to open a new thread for this. I notice that in my config, Mbuni connect and disconnect from ppp GPRS connection for each MMS stored in queue. Is it a normal behavior ? Piotr told me that in its config: *With settings similar to yours I get the behaviour when mbuni sends everything that is queued and then disconnects. Maybe if you patch mmsbox_mm1.c to add a 2 second sleep at end of inner loop in handle_mm1 function that will solve your problem.* So should Mbuni connect and disconnect for each MMS ? Or can we set an options to keep the ppp connection open until all MMS stored are sent ? Others options: - patch Mbuni to add a 2 second sleep ? If Piotr you can show me which function to add in order to have the sleep ? Or anybody else :) Try patch I sent to devel list last week: http://www.mail-archive.com/de...@mbuni.org/msg00427.html If you try it please let me know if it solves your problem. - manage pppd and ignore SIGTERM sent by Mbuni ? How to do this ? - ... Note: I am not a C expert :) -- Regards, Emmanuel ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users pgpycS16bIofL.pgp Description: PGP signature ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] Mbuni compilation failed on linux x86_64
do you recompile mbuni with '-fPIC' too? On Fri, Aug 06, 2010 at 07:24:56AM +0200, Emmanuel CHANSON wrote: When compiling kannel using : ./configure --with-mysql --with-cflags=-fPIC And then mbuni I got the same errors: */usr/bin/ld: /usr/lib64/kannel/libgwlib.a(gwmem-native.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC* /usr/lib64/kannel/libgwlib.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [libmmsbox_mm1.la] Erreur 1 make[2]: quittant le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras/mmsbox-mm1 » make[1]: *** [install-recursive] Erreur 1 make[1]: quittant le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras » make: *** [install-recursive] Erreur 1 # Emmanuel 2010/8/5 Vincent CHAVANIS v.chava...@telemaque.fr just read the warnings ;-) recompile the kannel libs with -fPIC regards Vincent. Le 05/08/2010 13:26, Emmanuel CHANSON a écrit : Hello, This time I am installing Mbuni on a x86_64 plateform. I got this error trying to compile Mbuni on Fedora 13 x86_64: ./bootstrap ./configure make install ... make[2]: entrant dans le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras/mmsbox-mm1 » /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -O4 -Wall -D_LARGE_FILES= -I/usr/include/kannel -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_LARGE_FILES= -I/usr/include/libxml2 -I/usr/include/openssl -I/usr/include/mysql -module -rdynamic -L/usr/lib64/kannel -lgw -lwap -lgwlib -lmysqlclient_r -lssl -lpcreposix -lrt -lresolv -lnsl -lm -lpthread -lxml2 -lz -lm -lpcreposix -lpcre -L/usr/lib64 -lcrypto -lssl -rdynamic -L/usr/lib64/mysql -lmysqlclient_r -lz -lpthread -lcrypt -lnsl -lm -lpthread -lssl -lcrypto -o libmmsbox_mm1.la http://libmmsbox_mm1.la -rpath /usr/local/lib mmsbox_mm1.lo -lwap -lgwlib -lpthread -ldl -L/usr/lib64/kannel -lgw -lwap -lgwlib -lmysqlclient_r -lssl -lpcreposix -lrt -lresolv -lnsl -lm -lpthread -lxml2 -lz -lm -lpcreposix -lpcre -L/usr/lib64 -lcrypto -lssl -rdynamic -L/usr/lib64/mysql -lmysqlclient_r -lz -lpthread -lcrypt -lnsl -lm -lpthread -lssl -lcrypto -lcurl libtool: link: gcc -shared .libs/mmsbox_mm1.o -L/usr/lib64/kannel -L/usr/lib64 -L/usr/lib64/mysql -ldl -lgw -lwap -lgwlib -lrt -lresolv -lxml2 -lpcreposix -lpcre -lmysqlclient_r -lz -lcrypt -lnsl -lm -lpthread -lssl -lcrypto -lcurl -m64 -mtune=generic -Wl,-soname -Wl,libmmsbox_mm1.so.0 -o .libs/libmmsbox_mm1.so.0.0.0 /usr/bin/ld: /usr/lib64/kannel/libgwlib.a(gwmem-native.o): *relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC* /usr/lib64/kannel/libgwlib.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [libmmsbox_mm1.la http://libmmsbox_mm1.la] Erreur 1 make[2]: quittant le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras/mmsbox-mm1 » make[1]: *** [install-recursive] Erreur 1 make[1]: quittant le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras » make: *** [install-recursive] Erreur 1 [r...@mediaserver mbuni]# Any idea how to solve this issue? BR -- Emmanuel ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users -- Emmanuel CHANSON Emmanuel Mobile Nouvelle-Calédonie: +687.77.35.02 Mobile France: +33 (0) 6.68.03.89.56 @email : emmanuelchan...@gmail.com ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users pgppOLffSVU3u.pgp Description: PGP signature ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users
Re: [Users] Mbuni compilation failed on linux x86_64
I know I have had this problem on x86_64, I'm also sure, that it's solvable somehow (however I don't remember the actual solution). Maybe try: CFLAGS=-fPIC ./configure for both projects instead of --with-cflags option. On Fri, Aug 06, 2010 at 06:34:20PM +1100, Emmanuel CHANSON wrote: Yes I tried using: For Kannel: # ./configure --with-mysql --with-cflags=-fPIC ... # make rpm For Mbuni # ./configure --with-kannel-dir=/root/rpmbuild/BUILD/kannel-svn/ --with-cflags=-fPIC # make but same error BR, Emmanuel 2010/8/6 Piotr Isajew p...@ex.com.pl do you recompile mbuni with '-fPIC' too? On Fri, Aug 06, 2010 at 07:24:56AM +0200, Emmanuel CHANSON wrote: When compiling kannel using : ./configure --with-mysql --with-cflags=-fPIC And then mbuni I got the same errors: */usr/bin/ld: /usr/lib64/kannel/libgwlib.a(gwmem-native.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC* /usr/lib64/kannel/libgwlib.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [libmmsbox_mm1.la] Erreur 1 make[2]: quittant le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras/mmsbox-mm1 » make[1]: *** [install-recursive] Erreur 1 make[1]: quittant le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras » make: *** [install-recursive] Erreur 1 # Emmanuel 2010/8/5 Vincent CHAVANIS v.chava...@telemaque.fr just read the warnings ;-) recompile the kannel libs with -fPIC regards Vincent. Le 05/08/2010 13:26, Emmanuel CHANSON a écrit : Hello, This time I am installing Mbuni on a x86_64 plateform. I got this error trying to compile Mbuni on Fedora 13 x86_64: ./bootstrap ./configure make install ... make[2]: entrant dans le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras/mmsbox-mm1 » /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -O4 -Wall -D_LARGE_FILES= -I/usr/include/kannel -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_LARGE_FILES= -I/usr/include/libxml2 -I/usr/include/openssl -I/usr/include/mysql -module -rdynamic -L/usr/lib64/kannel -lgw -lwap -lgwlib -lmysqlclient_r -lssl -lpcreposix -lrt -lresolv -lnsl -lm -lpthread -lxml2 -lz -lm -lpcreposix -lpcre -L/usr/lib64 -lcrypto -lssl -rdynamic -L/usr/lib64/mysql -lmysqlclient_r -lz -lpthread -lcrypt -lnsl -lm -lpthread -lssl -lcrypto -o libmmsbox_mm1.la http://libmmsbox_mm1.la -rpath /usr/local/lib mmsbox_mm1.lo -lwap -lgwlib -lpthread -ldl -L/usr/lib64/kannel -lgw -lwap -lgwlib -lmysqlclient_r -lssl -lpcreposix -lrt -lresolv -lnsl -lm -lpthread -lxml2 -lz -lm -lpcreposix -lpcre -L/usr/lib64 -lcrypto -lssl -rdynamic -L/usr/lib64/mysql -lmysqlclient_r -lz -lpthread -lcrypt -lnsl -lm -lpthread -lssl -lcrypto -lcurl libtool: link: gcc -shared .libs/mmsbox_mm1.o -L/usr/lib64/kannel -L/usr/lib64 -L/usr/lib64/mysql -ldl -lgw -lwap -lgwlib -lrt -lresolv -lxml2 -lpcreposix -lpcre -lmysqlclient_r -lz -lcrypt -lnsl -lm -lpthread -lssl -lcrypto -lcurl -m64 -mtune=generic -Wl,-soname -Wl,libmmsbox_mm1.so.0 -o .libs/libmmsbox_mm1.so.0.0.0 /usr/bin/ld: /usr/lib64/kannel/libgwlib.a(gwmem-native.o): *relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC* /usr/lib64/kannel/libgwlib.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [libmmsbox_mm1.la http://libmmsbox_mm1.la] Erreur 1 make[2]: quittant le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras/mmsbox-mm1 » make[1]: *** [install-recursive] Erreur 1 make[1]: quittant le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras » make: *** [install-recursive] Erreur 1 [r...@mediaserver mbuni]# Any idea how to solve this issue? BR -- Emmanuel ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users -- Emmanuel CHANSON Emmanuel Mobile Nouvelle-Calédonie: +687.77.35.02 Mobile France: +33 (0) 6.68.03.89.56 @email : emmanuelchan...@gmail.com ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users ___ Users mailing list Users@mbuni.org http://lists.mbuni.org/mailman/listinfo/users -- Emmanuel CHANSON Emmanuel Mobile Nouvelle-Calédonie: +687.77.35.02 Mobile France: +33 (0) 6.68.03.89.56 @email
Re: [Users] Mbuni compilation failed on linux x86_64
that works for me: For kannel: # CFLAGS=-fPIC ./configure --prefix=/usr/local/mbuni # make make install # echo /usr/local/mbuni/lib /etc/ld.so.conf # ldconfig For mbuni: # CFLAGS=-fPIC ./configure --prefix=/usr/local/mbuni --with-kannel-dir=/usr/local/mbuni # make On Fri, Aug 06, 2010 at 09:35:39PM +1100, Emmanuel CHANSON wrote: Same errors :( 2010/8/6 Vincent CHAVANIS v.chava...@telemaque.fr just configure kannel --with-cflags='-rdynamic -fPIC' Vincent. Le 06/08/2010 10:12, Emmanuel CHANSON a écrit : Same errors: Note I am using Fedora 13 (x86_64) # make clean # make distclean for both kannel and mbuni before compiling I don't run ./bootstrap for each (is it necessary ?) Then for Kannel: # CFLAGS=-fPIC ./configure --with-mysql Ok # make rpm Ok For Mbuni: # CFLAGS=-fPIC ./configure --with-kannel-dir=/root/rpmbuild/BUILD/kannel-svn Ok # make ... /usr/bin/ld: /usr/lib64/kannel/libgwlib.a(gwmem-native.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /usr/lib64/kannel/libgwlib.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[3]: *** [libmmsbox_mm1.la http://libmmsbox_mm1.la] Erreur 1 make[3]: quittant le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras/mmsbox-mm1 » make[2]: *** [all-recursive] Erreur 1 make[2]: quittant le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras » make[1]: *** [all-recursive] Erreur 1 make[1]: quittant le répertoire « /opt/mediaserver/softs/mbuni/mbuni » make: *** [all] Erreur 2 # Strange Emmanuel 2010/8/6 Piotr Isajew p...@ex.com.pl mailto:p...@ex.com.pl I know I have had this problem on x86_64, I'm also sure, that it's solvable somehow (however I don't remember the actual solution). Maybe try: CFLAGS=-fPIC ./configure for both projects instead of --with-cflags option. On Fri, Aug 06, 2010 at 06:34:20PM +1100, Emmanuel CHANSON wrote: Yes I tried using: For Kannel: # ./configure --with-mysql --with-cflags=-fPIC ... # make rpm For Mbuni # ./configure --with-kannel-dir=/root/rpmbuild/BUILD/kannel-svn/ --with-cflags=-fPIC # make but same error BR, Emmanuel 2010/8/6 Piotr Isajew p...@ex.com.pl mailto:p...@ex.com.pl do you recompile mbuni with '-fPIC' too? On Fri, Aug 06, 2010 at 07:24:56AM +0200, Emmanuel CHANSON wrote: When compiling kannel using : ./configure --with-mysql --with-cflags=-fPIC And then mbuni I got the same errors: */usr/bin/ld: /usr/lib64/kannel/libgwlib.a(gwmem-native.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC* /usr/lib64/kannel/libgwlib.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [libmmsbox_mm1.la http://libmmsbox_mm1.la] Erreur 1 make[2]: quittant le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras/mmsbox-mm1 » make[1]: *** [install-recursive] Erreur 1 make[1]: quittant le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras » make: *** [install-recursive] Erreur 1 # Emmanuel 2010/8/5 Vincent CHAVANIS v.chava...@telemaque.fr mailto: v.chava...@telemaque.fr just read the warnings ;-) recompile the kannel libs with -fPIC regards Vincent. Le 05/08/2010 13:26, Emmanuel CHANSON a écrit : Hello, This time I am installing Mbuni on a x86_64 plateform. I got this error trying to compile Mbuni on Fedora 13 x86_64: ./bootstrap ./configure make install ... make[2]: entrant dans le répertoire « /opt/mediaserver/softs/mbuni/mbuni/extras/mmsbox-mm1 » /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -O4 -Wall -D_LARGE_FILES= -I/usr/include/kannel -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_LARGE_FILES= -I/usr/include/libxml2 -I/usr/include/openssl -I/usr/include/mysql -module -rdynamic -L/usr/lib64/kannel -lgw -lwap -lgwlib -lmysqlclient_r -lssl -lpcreposix -lrt -lresolv -lnsl -lm -lpthread -lxml2 -lz -lm -lpcreposix -lpcre -L/usr/lib64 -lcrypto -lssl -rdynamic -L
Re: [Users] Mbuni try to send POST MMS before GPRS connection is established
Hi. From what I see you miss the following options to pppd (unless they are present in config file): nodefaultroute nodetach nodetach is important here since it stops grps-on process from quitting (pppd daemonizes) before it has a chance to set-up the connection. Other way would be to provide a shell script for gprs-on. A very simple example would be something like: #!/bin/sh pppd call your_mmsc while [ ! -r /var/run/ppp0-mbuni.pid ]; do sleep 5 done exit 0 When everything is correctly configured mbuni stops on SIGTERM and SIGINT, so CTRL+C should work here. However you may need to check your privilege set-up: pppd needs to be run with root privileges, so it should be setuid root or run via sudo; mbuni tries to stop pppd by sending SIGTERM with kill() call, and that means that in your configuration mbuni should be run with root privileges too. Hope that helps, Piotr On Thu, Aug 05, 2010 at 08:53:30AM +1100, Emmanuel CHANSON wrote: *Hello Piotr, Still Mbuni does not want to wait after GPRS connection even with ip-up script, do I miss something? Following your advises I have configured: in /etc/ppp/ip-up symlink to ip-up.sh:* *#!/bin/sh IFNAME=$1 LOCAL_IP=$4 REMOTE_IP=$5 IPPARAM=$6 MMS_PROXY=192.168.39.201 ip route add to $MMS_PROXY dev $IFNAME # routing has been set up, so: ln -sf /var/run/ppp-0.pid /var/run/ppp0-mbuni.pid * *Then in mmsbox.conf:* *custom-settings = gprs-on=pppd call mobile-auth;gprs-pid=cat /var/run/ppp0-mbuni.pid|head -1;port=3130;mmsc-url= http://mms.xx.xx/mmsc;proxy=192.168.39.201:3130;msisdn=100* *Intial ip routing:* -- # ifconfig;netstat -rn eth1 Link encap:Ethernet HWaddr 00:16:E6:4E:0C:2B inet adr:192.168.0.2 Bcast:192.168.0.255 Masque:255.255.255.0 adr inet6: fe80::216:e6ff:fe4e:c2b/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1707 errors:0 dropped:0 overruns:0 frame:0 TX packets:1589 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:1445194 (1.3 MiB) TX bytes:542026 (529.3 KiB) Interruption:20 Adresse de base:0x8000 loLink encap:Boucle locale inet adr:127.0.0.1 Masque:255.0.0.0 adr inet6: ::1/128 Scope:Hôte UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:210 errors:0 dropped:0 overruns:0 frame:0 TX packets:210 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:17962 (17.5 KiB) TX bytes:17962 (17.5 KiB) Table de routage IP du noyau Destination Passerelle Genmask Indic MSS Fenêtre irtt Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 0.0.0.0 192.168.0.1 0.0.0.0 UG0 0 0 eth1 # *Then the test:* # lynx -dump http://localhost:10003/?username=testerpassword=foobarmmsc=modemto=%2B/TYPE=PLMNsubject=Test-mediacomtext=TEST-MMS-depuis-MBUNI-2 *but mbuni still complain about:* (no pid file found if I translate) *cat: /var/run/ppp0-mbuni.pid: Aucun fichier ou dossier de ce type 2010-08-05 08:36:11 [2580] [5] INFO: mmsbox_mm1.c:659 start_gprs [mmsbox-mm1] [n/a] waiting for connection: 0, pid=2607 cpid=2607, ifexited=1, exitstatus=0 2010-08-05 08:36:11 [2580] [5] WARNING: mmsbox_mm1.c:375 handle_mm1 [mmsbox-mm1] [n/a] failed to start GPRS connection. waiting...* /var/log/mbuni/*log: 2010-08-05 08:23:53 [2403] [3] DEBUG: HTTP: Creating HTTPClient for `127.0.0.1'. 2010-08-05 08:23:53 [2403] [3] DEBUG: HTTP: Created HTTPClient area 0xb57005b0. 2010-08-05 08:23:53 [2403] [14] DEBUG: WSP: Mapping `text/plain', WSP 1.2 to 0x0003. 2010-08-05 08:23:53 [2403] [14] INFO: mmsbox.c:1366 make_and_queue_msg [mmsbox] [n/a] MMSBox: Queued message from service [sendmms-user], [transid [Mbuni-msg.7033.x1.3.40]: qf7033.1.x403.79 2010-08-05 08:23:53 [2403] [14] DEBUG: HTTP: Destroying HTTPClient area 0xb57005b0. 2010-08-05 08:23:53 [2403] [14] DEBUG: HTTP: Destroying HTTPClient for `127.0.0.1'. 2010-08-05 08:23:53 [2403] [14] INFO: mmsbox.c:1613 dispatch_sendmms_recv [mmsbox] [n/a] MMSBox.mmssend: u=tester, Queued [Accepted: Mbuni-msg.7033.x1.3.40] 2010-08-05 08:23:57 [2403] [7] DEBUG: Queued to thread 0 for /var/spool/mbuni/mmsbox_ outgoing/qf7033.1.x403.79, sendt=1280957033, tnow=1280957037 arg 0: pppd arg 1: call arg 2: mobile-auth cat: /var/run/ppp0.pid: Aucun fichier ou dossier de ce type - Afficher le texte des messages précédents - 2010-08-05 08:24:02 [2403] [5] INFO: mmsbox_mm1.c:659 start_gprs [mmsbox-mm1] [n/a] waiting for connection: 0, pid=2427 cpid=2427, ifexited=1, exitstatus=0 2010-08-05 08:24:02 [2403] [5] WARNING: mmsbox_mm1.c:375 handle_mm1 [mmsbox-mm1]
Re: [Users] Mbuni try to send POST MMS before GPRS connection is established
With settings similar to yours I get the behaviour when mbuni sends everything that is queued and then disconnects. Maybe if you patch mmsbox_mm1.c to add a 2 second sleep at end of inner loop in handle_mm1 function that will solve your problem. On Thu, Aug 05, 2010 at 02:55:16PM +1100, Emmanuel CHANSON wrote: Yes, by default mmsbox.conf has the following config: group = mbuni storage-directory = /var/spool/mbuni max-send-threads = 5 maximum-send-attempts = 50 default-message-expiry = 36 queue-run-interval = 5 send-attempt-back-off = 300 sendmms-port = 10001 max-send-threads set to 5 but Mbuni connect and disconnect for each MMS If this is normal behavior of Mbuni, need to check for a patch or a script that handle pppd Emmanuel 2010/8/5 Piotr Isajew p...@ex.com.pl On Thu, Aug 05, 2010 at 04:59:59AM +0200, Emmanuel CHANSON wrote: I forgot to add /sbin before 'ip route' in ip-up script, now it is Ok Things is Mbuni connect to GPRS, send the MMS and disconnect just after although a second MMS has to be sent, reconnect, send it and disconnect? have you tried to set max-send-threads to something greater than 1? Also take a look at queue-run-interval and send-attempt-back-off settings. Is it a normal behavior ? or is it possible to keep the ppp0 open and send all MMS stored in spool before closing it ? You can always play with gprs-on and pid stuff; that would include setting idle timer in pppd and playing somehow with pids you pass to mbuni (you would need to create a kind of shielding script that manages pppd and ignores SIGTERM's from mbuni) Many thanks Piotr for your support, you helped me to solve this :) I plan to developp a web interface that can use mbuni to send MMS. BR, Emmanuel 2010/8/5 Piotr Isajew p...@ex.com.pl On Thu, Aug 05, 2010 at 01:29:24PM +1100, Emmanuel CHANSON wrote: Yeah, thanks Piotr, It seems better using 'nodetach', mbuni does not block anymore but retry to send MMS but I have an issue with routing to reach MMS-C, when pppd is established it should set the route in ip-up script: ip route to 192.168.39.201 dev ppp0 I guess? Can I use route add -host 192.168.39.201 gw ppp0IP@ 10.152.149.196 show below somewhere ? Sure. In basic configuration I used /sbin/route add -host $PROXY dev ppp0 in ip-up, but for me proxy was directly reachable from IP assigned by pppd. You may need to use 192.168.254.254 as gateway here. #!/bin/sh IFNAME=$1 LOCAL_IP=$4 REMOTE_IP=$5 IPPARAM=$6 *MMS_PROXY=192.168.39.201 ip route add to $MMS_PROXY dev $IFNAME* # routing has been set up, so: ln -sf /var/run/ppp0.pid /var/run/ppp0-mbuni.pid but I saw in the netstat -rn output (stay few second): coming from pppd process? *192.168.254.254 0.0.0.0 255.255.255.255 UH0 0 0 ppp0 # cat /etc/ppp/peers/options-mobile *ttyACM1 115200 lock crtscts modem passive novj nodefaultroute nodetach noipdefault usepeerdns noauth hide-password persist holdoff 10 maxfail 0 debug* * mmsbox.log: -- 2010-08-05 13:15:35 [3941] [3] DEBUG: HTTP: Creating HTTPClient for `127.0.0.1'. 2010-08-05 13:15:35 [3941] [3] DEBUG: HTTP: Created HTTPClient area 0xb5900d20. 2010-08-05 13:15:35 [3941] [14] DEBUG: WSP: Mapping `text/plain', WSP 1.2 to 0x0003. 2010-08-05 13:15:35 [3941] [14] INFO: mmsbox.c:1366 make_and_queue_msg [mmsbox] [n/a] MMSBox: Queued message from service [sendmms-user], [transid [Mbuni-msg.4535.x2.41.34]: 6-qf4535.2.x941.9 2010-08-05 13:15:35 [3941] [14] DEBUG: HTTP: Destroying HTTPClient area 0xb5900d20. 2010-08-05 13:15:35 [3941] [14] DEBUG: HTTP: Destroying HTTPClient for `127.0.0.1'. 2010-08-05 13:15:35 [3941] [14] INFO: mmsbox.c:1613 dispatch_sendmms_recv [mmsbox] [n/a] MMSBox.mmssend: u=tester, Queued [Accepted: Mbuni-msg.4535.x2.41.34] 2010-08-05 13:15:37 [3941] [7] DEBUG: Queued to thread 1 for /var/spool/mbuni/mmsbox_outgoing/6/qf4535.2.x941.9, sendt=1280974535, tnow=1280974537 arg 0: pppd arg 1: call arg 2: mobile-auth Script /usr/sbin/chat -v -t15 -f /etc/ppp/chatscripts/mobile-modem.chat finished (pid 4006), status = 0x5 Connect script failed cat: /var/run/ppp0-mbuni.pid: Aucun fichier ou dossier de ce type 2010-08-05 13:15:42 [3941] [5] INFO: mmsbox_mm1.c:659 start_gprs [mmsbox-mm1] [n/a] waiting for connection: 0, pid=4005 cpid=0, ifexited=1, exitstatus=5 cat: /var/run/ppp0-mbuni.pid: Aucun fichier ou dossier de ce type 2010-08-05 13:15:47 [3941] [5] INFO: mmsbox_mm1.c:659 start_gprs
Re: [Users] Mbuni try to send POST MMS before GPRS connection is established
You could also do this with proper if-up script. Mbuni tries to
connect to MMS proxy when it sees pppd pid file. On other hand pid
file is created _before_ interface IP and routing is set up. I solved
this by symlinking ppp pid to some path in if-up after everything is
set-up and making mbuni to look for a file on that path.
On Tue, Aug 03, 2010 at 03:13:09PM +1100, Emmanuel CHANSON wrote:
Hello mbuni users and developers,
Mbuni CVS 20100702
Modem: Sagem My300x
Purpose: Try to send MMS through MM1 GPRS modem but failed.
I did not succeed to send a MMS through MM1 GPRS modem connection.
When sending a MMS through mmsbox interface I do see the pppd process
starting to connect to GPRS but fail the first time then succeed, but Mbuni
says:
WARNING: mmsbox_mm1.c:375 handle_mm1 [mmsbox-mm1] [n/a] *failed to start
GPRS connection. waiting...
*
Mbuni did not make a retry after the GPRS connection was established.*
Find below:
*- mmsbox.log
- messages file (pppd message)
- mmmsbox.conf*
Questions:
**- Did you ever experiment this situation ?
- Do I have to use another process instead of pppd ?
- Why Mbuni does not retry to send the MMS stored in pool ?**
**- Problem of configuration ? of mbuni or routing issue to contact MMS-C**
*- I saw an another post where a someone implement a delay (from Ben
Hardill):*
--
**In order to get it all working I had to add a small delay after starting
PPP as Mbuni was trying to send the post before the routing was all up and
running properly, so I have added the following just after the call to start
ppp in mmsbox_mm1.c
if (mm1-gprs_on)
pid = start_gprs(mm1-gprs_on, mm1-gprs_pid);
gwthread_sleep(3); #--- short pause to allow ppp to finish
setting up the connection
if (pid 0) {
mms_warning(0, mmsbox-mm1, NULL,failed to start GPRS
connection. waiting...);*
*--
*
Starting log:
mmsbox.log:
---
[r...@navette mbuni]# mmsbox /etc/mbuni/mmsbox.conf
2010-08-03 14:31:44 [3327] [0] INFO: Debug_lvl = -1, log_file = none,
log_lvl = 0
2010-08-03 14:31:44 [3327] [0] INFO: Added logfile
`/var/log/mbuni/mmsbox.log' with level `0'.
2010-08-03 14:31:44 [3327] [0] INFO: Started access logfile
`/var/log/mbuni/mmsbox-access.log'.
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 1 (mmsbox_cdr.c:(void
*)cdr_logger_func)
2010-08-03 14:31:44 [3327] [0] INFO: HTTP: Opening server at port 10002.
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 2
(gwlib/fdset.c:poller)
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 3
(gwlib/http.c:server_thread)
2010-08-03 14:31:44 [3327] [1] DEBUG: Thread 1 (mmsbox_cdr.c:(void
*)cdr_logger_func) maps to pid 3327.
2010-08-03 14:31:44 [3327] [0] INFO: mmsbox_cfg.c:578 start_mmsc_from_conf
[mmsbox] [n/a] Loaded MMSC[modem], allow=[(null)], deny=[(null)]
group_id=[modem]
2010-08-03 14:31:44 [3327] [0] INFO: HTTP: Opening server at port 3130.
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 4
(mmsbox_mm1.c:(gwthread_func_t *)handle_notify)
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 5
(mmsbox_mm1.c:(gwthread_func_t *)handle_mm1)
2010-08-03 14:31:44 [3327] [0] INFO: mmsbox_cfg.c:529
mmsbox_start_mmsc_conn [mmsbox] [n/a] Startup for mmsc [modem] complete
2010-08-03 14:31:44 [3327] [2] DEBUG: Thread 2 (gwlib/fdset.c:poller) maps
to pid 3327.
2010-08-03 14:31:44 [3327] [0] WARNING: mmsbox_cfg.c:459
mms_load_mmsbox_settings [mmsbox] [n/a] Empty or no password supplied for
admin port. All requests will be allowed!
2010-08-03 14:31:44 [3327] [0] INFO: mmsbox.c:758 main [mmsbox] [n/a]
2010-08-03 14:31:44 [3327] [0] INFO: mmsbox.c:759 main [mmsbox] [n/a]
Mbuni MMSBox version cvs-20100702 starting
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 6
(mmsbox.c:(gwthread_func_t *)sendmms_func)
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 7
(mmsbox.c:(gwthread_func_t *)mmsbox_outgoing_queue_runner)
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 8
(mms_queue.c:(gwthread_func_t *)tdeliver)
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 9
(mms_queue.c:(gwthread_func_t *)tdeliver)
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 10
(mms_queue.c:(gwthread_func_t *)tdeliver)
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 11
(mms_queue.c:(gwthread_func_t *)tdeliver)
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 12
(mms_queue.c:(gwthread_func_t *)tdeliver)
2010-08-03 14:31:44 [3327] [5] DEBUG: Thread 5
(mmsbox_mm1.c:(gwthread_func_t *)handle_mm1) maps to pid 3327.
2010-08-03 14:31:44 [3327] [5] INFO: mmsbox_mm1.c:363 handle_mm1
[mmsbox-mm1] [n/a] handle_mm1 started
2010-08-03 14:31:44 [3327] [4] DEBUG: Thread 4
(mmsbox_mm1.c:(gwthread_func_t *)handle_notify) maps to pid 3327.
2010-08-03 14:31:44 [3327] [3] DEBUG: Thread 3 (gwlib/http.c:server_thread)
maps to pid
Re: [Users] Mbuni try to send POST MMS before GPRS connection is established
On Tue, Aug 03, 2010 at 05:44:30PM +1100, Emmanuel CHANSON wrote:
One question:
Does Mbuni will open and close GPRS connection each time it will have to
send a MMS ? or does it keep the connection always open ?
It opens connection once there is something in queue and keeps it open
until processing queue is empty. In reality to achieve this you should
have max-send-threads slightly higher than amount of modems
used. I.e. for one modem you shoud have 2 sending threads. With one
thread it will open and close the connection for each message.
Is it a good idea to keep the GPRS connection open in case a lot of MMS have
to be send through modem?
If you have lots to send you could write fake start-gprs script that
does nothing and start persistent pppd connection outside of
mbuni. That could evolve to inteligent start-gprs script that starts
gprs connection once something appears on queue and stays open for
some idle period while cheating mbuni for closing connection (mbuni
kills pid given in pid file when it does not need gprs connection any more)
I will check about if-up script.
Others ideas maybe ? Just to confirm that it is a normal behavior and I
should not use pppd call gprs that lead to this behavior ?
depends on your options. To be more specific using 'nodetach' option
of pppd works better for me.
BR,
Emmanuel
2010/8/3 Piotr Isajew p...@ex.com.pl
You could also do this with proper if-up script. Mbuni tries to
connect to MMS proxy when it sees pppd pid file. On other hand pid
file is created _before_ interface IP and routing is set up. I solved
this by symlinking ppp pid to some path in if-up after everything is
set-up and making mbuni to look for a file on that path.
On Tue, Aug 03, 2010 at 03:13:09PM +1100, Emmanuel CHANSON wrote:
Hello mbuni users and developers,
Mbuni CVS 20100702
Modem: Sagem My300x
Purpose: Try to send MMS through MM1 GPRS modem but failed.
I did not succeed to send a MMS through MM1 GPRS modem connection.
When sending a MMS through mmsbox interface I do see the pppd process
starting to connect to GPRS but fail the first time then succeed, but
Mbuni
says:
WARNING: mmsbox_mm1.c:375 handle_mm1 [mmsbox-mm1] [n/a] *failed to
start
GPRS connection. waiting...
*
Mbuni did not make a retry after the GPRS connection was established.*
Find below:
*- mmsbox.log
- messages file (pppd message)
- mmmsbox.conf*
Questions:
**- Did you ever experiment this situation ?
- Do I have to use another process instead of pppd ?
- Why Mbuni does not retry to send the MMS stored in pool ?**
**- Problem of configuration ? of mbuni or routing issue to contact
MMS-C**
*- I saw an another post where a someone implement a delay (from Ben
Hardill):*
--
**In order to get it all working I had to add a small delay after
starting
PPP as Mbuni was trying to send the post before the routing was all up
and
running properly, so I have added the following just after the call to
start
ppp in mmsbox_mm1.c
if (mm1-gprs_on)
pid = start_gprs(mm1-gprs_on, mm1-gprs_pid);
gwthread_sleep(3); #--- short pause to allow ppp to
finish
setting up the connection
if (pid 0) {
mms_warning(0, mmsbox-mm1, NULL,failed to start GPRS
connection. waiting...);*
*--
*
Starting log:
mmsbox.log:
---
[r...@navette mbuni]# mmsbox /etc/mbuni/mmsbox.conf
2010-08-03 14:31:44 [3327] [0] INFO: Debug_lvl = -1, log_file = none,
log_lvl = 0
2010-08-03 14:31:44 [3327] [0] INFO: Added logfile
`/var/log/mbuni/mmsbox.log' with level `0'.
2010-08-03 14:31:44 [3327] [0] INFO: Started access logfile
`/var/log/mbuni/mmsbox-access.log'.
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 1
(mmsbox_cdr.c:(void
*)cdr_logger_func)
2010-08-03 14:31:44 [3327] [0] INFO: HTTP: Opening server at port 10002.
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 2
(gwlib/fdset.c:poller)
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 3
(gwlib/http.c:server_thread)
2010-08-03 14:31:44 [3327] [1] DEBUG: Thread 1 (mmsbox_cdr.c:(void
*)cdr_logger_func) maps to pid 3327.
2010-08-03 14:31:44 [3327] [0] INFO: mmsbox_cfg.c:578
start_mmsc_from_conf
[mmsbox] [n/a] Loaded MMSC[modem], allow=[(null)], deny=[(null)]
group_id=[modem]
2010-08-03 14:31:44 [3327] [0] INFO: HTTP: Opening server at port 3130.
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 4
(mmsbox_mm1.c:(gwthread_func_t *)handle_notify)
2010-08-03 14:31:44 [3327] [0] DEBUG: Started thread 5
(mmsbox_mm1.c:(gwthread_func_t *)handle_mm1)
2010-08-03 14:31:44 [3327] [0] INFO: mmsbox_cfg.c:529
mmsbox_start_mmsc_conn [mmsbox] [n/a] Startup for mmsc [modem] complete
2010-08-03 14:31:44 [3327] [2] DEBUG: Thread 2
Re: [Users] Mbuni try to send POST MMS before GPRS connection is established
Mbuni uses curl to connect() to proxy. This is issued just after start-gprs pid is returned so on normal system it uses default route, which is not good because of firewalling and most ops using private addresses for mmsc's. From what I saw (maybe someone will correct me here) mmsbox-mm1 does not set any connection timeouts on CURL and default is to wait indefinitly (or at least very long). So handle_mm1 thread blocks here. On Wed, Aug 04, 2010 at 02:15:46PM +1100, Emmanuel CHANSON wrote: I also dont understand why mbuni does not retry to send the MMS stored in spool after the ppp0 connection is up ? mbuni stay blocked: 2010-08-04 13:52:37 [10240] [5] INFO: mmsbox_mm1.c:659 start_gprs [mmsbox-mm1] [n/a] waiting for connection: 0, pid=10263 cpid=10263, ifexited=1, exitstatus=0 2010-08-04 13:52:37 [10240] [5] WARNING: mmsbox_mm1.c:375 handle_mm1 [mmsbox-mm1] [n/a] failed to start GPRS connection. waiting... Emmanuel 2010-08-03 14:31:44 [3327] [14] DEBUG: Thread 14 (mms_queue.c:(gwthread_func_t *)tdeliver) maps to pid 3327. MMS send through MMS interface of mmsbox: # lynx -dump http://localhost:10002/?username=testerpassword=foobarmmsc=modemto=%2B87773502/TYPE=PLMNsubject=Testtext=MMS-1 Accepted: Mbuni-msg.7610.x1.24.85 mmsbox.log generated after the MMS: 2010-08-03 14:53:30 [2324] [3] DEBUG: HTTP: Creating HTTPClient for `127.0.0.1'. 2010-08-03 14:53:30 [2324] [3] DEBUG: HTTP: Created HTTPClient area 0xb5700ab0. 2010-08-03 14:53:30 [2324] [18] DEBUG: WSP: Mapping `text/plain', WSP 1.2 to 0x0003. 2010-08-03 14:53:30 [2324] [18] INFO: mmsbox.c:1366 make_and_queue_msg [mmsbox] [n/a] MMSBox: Queued message from service [sendmms-user], [transid [Mbuni-msg.7610.x1.24.85]: q-qf7610.1.x324.69 2010-08-03 14:53:30 [2324] [18] DEBUG: HTTP: Destroying HTTPClient area 0xb5700ab0. 2010-08-03 14:53:30 [2324] [18] DEBUG: HTTP: Destroying HTTPClient for `127.0.0.1'. 2010-08-03 14:53:30 [2324] [18] INFO: mmsbox.c:1613 dispatch_sendmms_recv [mmsbox] [n/a] MMSBox.mmssend: u=tester, Queued [Accepted: Mbuni-msg.7610.x1.24.85] 2010-08-03 14:53:35 [2324] [7] DEBUG: Queued to thread 0 for /var/spool/mbuni/mmsbox_outgoing/q/qf7610.1.x324.69, sendt=1280807610, tnow=1280807615 arg 0: pppd arg 1: call arg 2: mobile-auth cat: /var/run/ppp0.pid: Aucun fichier ou dossier de ce type 2010-08-03 14:53:40 [2324] [5] INFO: mmsbox_mm1.c:659 start_gprs [mmsbox-mm1] [n/a] waiting for connection: 0, pid=2457 cpid=2457, ifexited=1, exitstatus=0 2010-08-03 14:53:40 [2324] [5] WARNING: mmsbox_mm1.c:375 handle_mm1 [mmsbox-mm1] [n/a] *failed to start GPRS connection. waiting...* /var/log/messages: Aug 3 14:53:35 navette kernel: PPP generic driver version 2.4.2 Aug 3 14:53:35 navette pppd[2462]: pppd 2.4.5 started by admin, uid 0 Aug 3 14:53:36 navette chat[2463]: abort on (BUSY) Aug 3 14:53:36 navette chat[2463]: abort on (NO CARRIER) Aug 3 14:53:36 navette chat[2463]: abort on (VOICE) Aug 3 14:53:36 navette chat[2463]: abort on (NO DIALTONE) Aug 3 14:53:36 navette chat[2463]: abort on (NO DIAL TONE) Aug 3 14:53:36 navette chat[2463]: abort on (NO ANSWER) Aug 3 14:53:36 navette chat[2463]: abort on (DELAYED) Aug 3 14:53:36 navette chat[2463]: report (CONNECT) Aug 3 14:53:36 navette chat[2463]: timeout set to 6 seconds Aug 3 14:53:36 navette chat[2463]: send (ATQ0^M) Aug 3 14:53:36 navette chat[2463]: expect (OK) Aug 3 14:53:36 navette chat[2463]: ^M Aug 3 14:53:36 navette chat[2463]: OK Aug 3 14:53:36 navette chat[2463]: -- got it Aug 3 14:53:36 navette chat[2463]: send (ATZ^M) Aug 3 14:53:37 navette chat[2463]: timeout set to 3 seconds Aug 3 14:53:37 navette chat[2463]: expect (OK) Aug 3 14:53:37 navette chat[2463]: ^M Aug 3 14:53:37 navette chat[2463]: ^M Aug 3 14:53:37 navette chat[2463]: OK Aug 3 14:53:37 navette chat[2463]: -- got it Aug 3 14:53:37 navette chat[2463]: send (AT^M) Aug 3 14:53:37 navette chat[2463]: expect (OK) Aug 3 14:53:37 navette chat[2463]: ^M Aug 3 14:53:40 navette chat[2463]: alarm Aug 3 14:53:40 navette chat[2463]: send (AT^M) Aug 3 14:53:40 navette chat[2463]: expect (OK) Aug 3 14:53:40 navette chat[2463]: AT^M^M Aug 3 14:53:40 navette chat[2463]: OK Aug 3 14:53:40 navette chat[2463]: -- got it Aug 3 14:53:40 navette chat[2463]: send (ATI^M) Aug 3 14:53:40 navette chat[2463]: expect (OK) Aug 3 14:53:40 navette chat[2463]: ^M Aug 3 14:53:40 navette chat[2463]: ATI^M^M Aug 3 14:53:40 navette chat[2463]: my300X GPRS^M Aug 3 14:53:40 navette chat[2463]:
Re: [Users] Mbuni try to send POST MMS before GPRS connection is established
On Wed, Aug 04, 2010 at 07:14:52AM +0200, Emmanuel CHANSON wrote:
Thanks Piotr for this,
One more questions:
Where and when do I call ip-up.sh $1 $2 ... and then call pppd ? All
inside custom-settings gprs-on= option ?
it's enough if you symlink it to /etc/ppp/ip-up. From pppd manual:
/etc/ppp/ip-up
A program or script which is executed when the link is available
for sending and receiving IP packets (that is, IPCP has come
up). It is executed with the parameters
interface-name tty-device speed local-IP-address
remote-IP-address ipparam
I miss some experience on this
About:
*Mbuni uses curl to connect() to proxy. This is issued just after start-gprs
pid is returned so on normal system it uses default
route, which is not good because of firewalling and most ops using private
addresses for mmsc's. From what I saw (maybe someone will correct me here)
mmsbox-mm1 does not set any connection timeouts on CURL and default is to
wait indefinitly (or at least very long). So handle_mm1 thread blocks here.*
I understand that if ppp0 connection is not well established before Mbuni
try to send MMS, Mbuni blocks and becomes unsuable ?
That's mine experience with it.
So I really have to make ppp0 connection ready and ip routing to reach MMS-C
configured, before Mbuni it try to send any MMS right ? or patch
mmsbox_mm1/curl function to add a timeout ? or fasten my GPRS connection
process (because 1st try failed and second try successfully connect to GPRS
always)?
Is this issue due to my pppd config? the modem I use ? Is it a normal
behavior ?
That may be due to imperfect chat script. You should check your logs
to find a reason. On the other way it can always happen that you can
temporarily lost connection with MMSC even with perfect configuration
on your side. IMO modifying mmsbox_mm1 is the only way to get rid of
the problem in production environment. I've modified mmsbox_mm1.c to
fix problems with this. I'll send a patch to devel list later.
I plan to test using Huawei E220 modem maybe it will be better.
I try tu understand if all mbuni user had same problem when using MM1
interface through a modem
BR,
Emmanuel
custom-settings = gprs-on=pppd call mobile-auth;gprs-pid=cat
/var/run/ppp0.pid|head -1;port=3130;mmsc-url=
http://mms.x.xx/mmsc;proxy=192.168.39.201;msisdn=100;
mmsc-library = /usr/local/lib/libmmsbox_mm1.
2010/8/4 Piotr Isajew p...@ex.com.pl
On Wed, Aug 04, 2010 at 04:01:22AM +0200, Emmanuel CHANSON wrote:
Is it possible to get an example of the if-up/down script that deal with
ppp0.pid symlink so that Mbuni start to send MMS only after the ppp0
connection is established?
You may try something like:
ip-up.sh:
IFNAME=$1
LOCAL_IP=$4
REMOTE_IP=$5
IPPARAM=$6
MMS_PROXY=your mmsc proxy ip
ip route add to $MMS_PROXY dev $IFNAME
# routing has been set up, so:
ln -sf /var/run/ppp-${IPPARAM}.pid /var/run/ppp-for-mbuni.pid
then start pppd with:
nodetach
linkname mms
ipparam mms
and watch for it's pid in mbuni with something like:
gprs-pid=cat /var/run/ppp-for-mbuni.pid|head -1
I notice that routing is also missing after the GPRS connection is
established that is why maybe mbuni POST nothing.
I need to set a route add mmsproxyip@ gw ppp0 in order to reach
MMS-C
Yes
One question about the port parameter:
# Sample conf for MMSBox using a modem (MM1)
group = mmsc
id = modem
type = custom
custom-settings = gprs-on=pppd call mobile-auth;gprs-pid=cat
/var/run/ppp0.pid|head -1;port=3130;mmsc-url=
http://mms.x.xx/mmsc;proxy=192.168.39.201;msisdn=100;
mmsc-library = /usr/local/lib/libmmsbox_mm1.
Is it the same to use port=*3130* and mmsc-url=http://mmscurl
;pro...@ip:*
3130* ? in the mmsbox.conf?
In my case I use port=3130 and does not set a :port on the proxy
parameter
in mmsc-url
No. port in settings is for other applications (like kannel) to
communicate with mmsbox i.e. to trigger fetch actions. To specify your
operator's mmsc port use :port in mmsc url or proxy settings depending
on your MMSC settings.
Regards thanks for your help
Emmanuel
2010/8/3 Piotr Isajew p...@ex.com.pl
On Tue, Aug 03, 2010 at 05:44:30PM +1100, Emmanuel CHANSON wrote:
One question:
Does Mbuni will open and close GPRS connection each time it will have
to
send a MMS ? or does it keep the connection always open ?
It opens connection once there is something in queue and keeps it open
until processing queue is empty. In reality to achieve this you should
have max-send-threads slightly higher than amount of modems
used. I.e. for one modem you shoud have 2 sending threads. With one
thread it will open and close the connection for each message.
Is it a good idea to keep the GPRS connection open
[Users] MM1 - detecting message send failure
Hello. I'm using current mbuni from CVS to send MMS messages through GPRS modem. Messages are submitted with something like: curl -s --data username=xpassword=yto=some_msisdnfrom=my_msisdnsubject=Testdlr-url=my_urlrr-url=my_urlmmsc=play20 --data_url-encode s...@smilfile That works pretty well except when message to be sent exceeds size limit set by the carrier. When this occurs operator sets appropriate headers in reply (see log below). In such situation I would expect mbuni to report delivery as failure. However it appears that it reports such message as 'Forwarded' - both for dlr-url and CDR logs. As the result I cannot detect (from the level of dlr-url script) that mbuni failed to send the message and I have to assume that message was sent successfuly. Is there any way to recognize such situations correctly and detect failure from dlr-url script? Log output for example message: 2010-07-20 17:00:56 [20236] [5] INFO: mmsbox_mm1.c:659 start_gprs [mmsbox-mm1] [n/a] waiting for connection: 0, pid=25641 cpid=0, ifexited=0, exitstatus=0 2010-07-20 17:01:01 [20236] [5] INFO: mmsbox_mm1.c:379 handle_mm1 [mmsbox-mm1] [n/a] start_gprs returned PID: 25641 2010-07-20 17:01:31 [20236] [5] INFO: mmsbox_mm1.c:589 write_octstr_data [mmsbox-mm1] [n/a] write_data called with nmemn=7 5, size=1 2010-07-20 17:01:31 [20236] [5] DEBUG: Octet string at 0x1016ce68: 2010-07-20 17:01:31 [20236] [5] DEBUG: len: 0 2010-07-20 17:01:31 [20236] [5] DEBUG: size: 1024 2010-07-20 17:01:31 [20236] [5] DEBUG: immutable: 0 2010-07-20 17:01:31 [20236] [5] DEBUG: Octet string dump ends. 2010-07-20 17:01:31 [20236] [5] DEBUG: Dumping HTTP headers: 2010-07-20 17:01:31 [20236] [5] DEBUG: Octet string at 0x10175a30: 2010-07-20 17:01:31 [20236] [5] DEBUG:len: 31 2010-07-20 17:01:31 [20236] [5] DEBUG:size: 1024 2010-07-20 17:01:31 [20236] [5] DEBUG:immutable: 0 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 58 2d 4d 6d 73 2d 4d 65 73 73 61 67 65 2d 54 79 X-Mms-Message-Ty 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 70 65 3a 20 6d 2d 73 65 6e 64 2d 63 6f 6e 66 pe: m-send-conf 2010-07-20 17:01:31 [20236] [5] DEBUG: Octet string dump ends. 2010-07-20 17:01:31 [20236] [5] DEBUG: Octet string at 0x10185d70: 2010-07-20 17:01:31 [20236] [5] DEBUG:len: 27 2010-07-20 17:01:31 [20236] [5] DEBUG:size: 1024 2010-07-20 17:01:31 [20236] [5] DEBUG:immutable: 0 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 58 2d 4d 6d 73 2d 54 72 61 6e 73 61 63 74 69 6f X-Mms-Transactio 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 6e 2d 49 64 3a 20 30 30 30 30 31 n-Id: 1 2010-07-20 17:01:31 [20236] [5] DEBUG: Octet string dump ends. 2010-07-20 17:01:31 [20236] [5] DEBUG: Octet string at 0x10186920: 2010-07-20 17:01:31 [20236] [5] DEBUG:len: 22 2010-07-20 17:01:31 [20236] [5] DEBUG:size: 1024 2010-07-20 17:01:31 [20236] [5] DEBUG:immutable: 0 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 58 2d 4d 6d 73 2d 4d 4d 53 2d 56 65 72 73 69 6f X-Mms-MMS-Versio 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 6e 3a 20 31 2e 30 n: 1.0 2010-07-20 17:01:31 [20236] [5] DEBUG: Octet string dump ends. 2010-07-20 17:01:31 [20236] [5] DEBUG: Octet string at 0x10172020: 2010-07-20 17:01:31 [20236] [5] DEBUG:len: 43 2010-07-20 17:01:31 [20236] [5] DEBUG:size: 1024 2010-07-20 17:01:31 [20236] [5] DEBUG:immutable: 0 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 58 2d 4d 6d 73 2d 52 65 73 70 6f 6e 73 65 2d 53 X-Mms-Response-S 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 74 61 74 75 73 3a 20 45 72 72 6f 72 2d 73 65 72 tatus: Error-ser 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 76 69 63 65 2d 64 65 6e 69 65 64 vice-denied 2010-07-20 17:01:31 [20236] [5] DEBUG: Octet string dump ends. 2010-07-20 17:01:31 [20236] [5] DEBUG: Octet string at 0x10175a48: 2010-07-20 17:01:31 [20236] [5] DEBUG:len: 44 2010-07-20 17:01:31 [20236] [5] DEBUG:size: 1024 2010-07-20 17:01:31 [20236] [5] DEBUG:immutable: 0 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 58 2d 4d 6d 73 2d 52 65 73 70 6f 6e 73 65 2d 54 X-Mms-Response-T 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 65 78 74 3a 20 4d 65 73 73 61 67 65 20 6f 76 65 ext: Message ove 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 72 20 73 69 7a 65 20 6c 69 6d 69 74 r size limit 2010-07-20 17:01:31 [20236] [5] DEBUG: Octet string dump ends. 2010-07-20 17:01:31 [20236] [5] DEBUG: Octet string at 0x101733d8: 2010-07-20 17:01:31 [20236] [5] DEBUG:len: 47 2010-07-20 17:01:31 [20236] [5] DEBUG:size: 1024 2010-07-20 17:01:31 [20236] [5] DEBUG:immutable: 0 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 4d 65 73 73 61 67 65 2d 49 44 3a 20 67 62 75 76 Message-ID: gbuv 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 68 62 61 62 76 72 30 65 31 35 32 40 77 2e 6d 6d hbabvr0e...@w.mm 2010-07-20 17:01:31 [20236] [5] DEBUG:data: 73 2e 70 6c
