[FIX] fMMS - MMS on the N900, cannot receive - Page 7 - maemo.org

Active Topics

Maemo repository (8)
to Community by Maemish - 1 day, 1 hr ago
Porting apps to Leste (44)
to Maemo 7 / Leste by norayr - 1 day, 6 hrs ago
List of well performing apps on Leste (35)
to Maemo 7 / Leste by smatkovi - 4 days, 3 hrs ago
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (13)
to SailfishOS by edp17 - 5 days, 1 hr ago
Sailfish OS for the Samsung Galaxy Note 4 (SM-N910C) - (treltexx) (79)
to SailfishOS by edp17 - 5 days, 1 hr ago
U-Boot for Nokia RX-51 with BootMenu (updated version 2012.10-rc3-1) (843)
to Alternatives by Arno_11 - 5 days, 6 hrs ago
more...

Page 7 of 8

« First

< Prev

Next >

Thread Tools

Tsippaduida	2016-08-08 , 11:46
Posts: 123 \| Thanked: 268 times \| Joined on Dec 2009 @ Helsinki, Finland	#61

Not to worry too much. I will reset the settings and report back how it goes. One thing is apparent: There are two partially different MMS settings for Saunalahti customers depending on the SIM-card. Newer sim cards (I belong to this group), should use different proxy and MMSC.

So I try to sort out the settings, update wiki settings page accordingly if needed, and report back.

I think I can provide debug information as well if it comes to that.

Last edited by Tsippaduida; 2016-08-08 at 12:16.

Quote & Reply |

The Following User Says Thank You to Tsippaduida For This Useful Post:
peterleinchen

shubell	2016-11-18 , 08:01
Posts: 64 \| Thanked: 84 times \| Joined on Oct 2012	#62

Well i have a similar problem with fmms. Ever since our great glorious provider changed some settings i receive mms with no receiver. I am kinda trying to fix it by myself but have some issues.
Ok the log says that it cannot get the sender from the push data.

Code:

2016-11-18 07:48:34,742 fmms.__main__: Incoming SMS Push!
2016-11-18 07:48:34,769 fmms.__main__: SRC: MMS:9200
2016-11-18 07:48:34,771 fmms.__main__: DST: 2948
2016-11-18 07:48:34,775 fmms.__main__: decoding...
2016-11-18 07:48:34,789 fmms.controller: content-location: http://mms.telekom.si/MB//7D18F876
2016-11-18 07:48:34,792 fmms.controller: transid: 7D18F876
2016-11-18 07:48:34,796 fmms.controller: No sender value defined: <type 'exceptions.KeyError'> 'From'
Traceback (most recent call last):
  File "/opt/fmms/controller.py", line 160, in decode_mms_from_push
    sndr = wsplist["From"]
KeyError: 'From'
2016-11-18 07:48:34,822 fmms.controller: saved binary push: <open file '/home/user/.fmms/push/7D18F876', mode 'wb' at 0x569188>
2016-11-18 07:48:35,182 fmms.contacts: loaded contacthandler in 0.18 s
2016-11-18 07:48:35,632 fmms.__main__: saving...
2016-11-18 07:48:36,148 fmms.dbhandler: inserted row as: 624
2016-11-18 07:48:37,295 fmms.__main__: fetching mms...

ok i checked the saved binary push file and inside i can see the sender number

Code:

Œ‚˜7D18F876 ‘Š€Ž·ˆô€ƒhttp://mms.telekom.si/MB//7D18F876 ‰€+38641666666/TYPE=PLMN –êFwd: Fwd: Fwd:

i think that the problem is somewhere in the decideNessageHeaderToList fuction as it does not return the sender from the decoded binary data.

Code:

 def decodeMessageHeaderToList(self, data):
        """ Decodes the (full) MMS header data
        
        @note: This B{must} be called before C{_decodeBody()}, as it sets
        certain internal variables relating to data lengths, etc.
        """
        dataIter = PreviewIterator(data)
        
        # First 3  headers (in order
        ############################
        # - X-Mms-Message-Type
        # - X-Mms-Transaction-ID
        # - X-Mms-Version
        # TODO: reimplement strictness - currently we allow these 3 headers 
        #       to be mixed with any of the other headers (this allows the
        #       decoding of "broken" MMSs, but is technically incorrect
           
        # Misc headers
        ##############
        # The next few headers will not be in a specific order, except for
        # "Content-Type", which should be the last header
        # According to [4], MMS header field names will be short integers
        # If the message type is a M-Notification* or M-Acknowledge
        #type we don't expect any ContentType and should break on
        # StopIteration exception
        contentTypeFound = False
        contentLocationFound = False
        while (contentTypeFound == False):
            try:
            	header, value = self.decodeHeader(dataIter)
            except StopIteration, e:
            	print e, e.args
            	break
            if header == MMSEncodingAssignments.fieldNames[0x04][0]:
                contentTypeFound = True
            elif header == MMSEncodingAssignments.fieldNames[0x03][0]:
                contentLocationFound = True
                break
                #pass
            else:
            	try:
			self._mmsMessage.headers[header] = value
			#print '%s: %s' % (header, str(value))
		except StopIteration, e:
			print e, e.args
			break
        
        cType = value[0]
        #print '%s: %s' % (header, cType)
        params = value[1]
        #for parameter in params:
        #    print '    %s: %s' % (parameter, str(params[parameter]))

        self._mmsMessage.headers[header] = (value)
        return self._mmsMessage.headers

The only data that gets returned (i think, still debuging a bit) and is later inserted into the pust_headers table are the following rows adn there is no from row

Code:

3422	624	Message-Class	Personal
3423	624	Message-Size	1719
3424	624	MMS-Version	1.1
3425	624	Expiry	259200
3426	624	Content-Type	('application/vnd.wap.multipart.mixed', {'Start': '<smil>', 'Type': 'application/smil'})

ok here is also the last incoming push message

Code:

MMS
9200
2948
dbus.Array([dbus.Byte(97), dbus.Byte(112), dbus.Byte(112), dbus.Byte(108), dbus.Byte(105), dbus.Byte(99), dbus.Byte(97), dbus.Byte(116), dbus.Byte(105), dbus.Byte(111), dbus.Byte(110), dbus.Byte(47), dbus.Byte(118), dbus.Byte(110), dbus.Byte(100), dbus.Byte(46), dbus.Byte(119), dbus.Byte(97), dbus.Byte(112), dbus.Byte(46), dbus.Byte(109), dbus.Byte(109), dbus.Byte(115), dbus.Byte(45), dbus.Byte(109), dbus.Byte(101), dbus.Byte(115), dbus.Byte(115), dbus.Byte(97), dbus.Byte(103), dbus.Byte(101), dbus.Byte(0), dbus.Byte(175), dbus.Byte(132)], signature=dbus.Signature('y'))
dbus.Array([dbus.Byte(140), dbus.Byte(130), dbus.Byte(152), dbus.Byte(55), dbus.Byte(68), dbus.Byte(49), dbus.Byte(56), dbus.Byte(70), dbus.Byte(56), dbus.Byte(55), dbus.Byte(54), dbus.Byte(0), dbus.Byte(141), dbus.Byte(145), dbus.Byte(138), dbus.Byte(128), dbus.Byte(142), dbus.Byte(2), dbus.Byte(6), dbus.Byte(183), dbus.Byte(136), dbus.Byte(5), dbus.Byte(129), dbus.Byte(3), dbus.Byte(3), dbus.Byte(244), dbus.Byte(128), dbus.Byte(131), dbus.Byte(104), dbus.Byte(116), dbus.Byte(116), dbus.Byte(112), dbus.Byte(58), dbus.Byte(47), dbus.Byte(47), dbus.Byte(109), dbus.Byte(109), dbus.Byte(115), dbus.Byte(46), dbus.Byte(116), dbus.Byte(101), dbus.Byte(108), dbus.Byte(101), dbus.Byte(107), dbus.Byte(111), dbus.Byte(109), dbus.Byte(46), dbus.Byte(115), dbus.Byte(105), dbus.Byte(47), dbus.Byte(77), dbus.Byte(66), dbus.Byte(47), dbus.Byte(47), dbus.Byte(55), dbus.Byte(68), dbus.Byte(49), dbus.Byte(56), dbus.Byte(70), dbus.Byte(56), dbus.Byte(55), dbus.Byte(54), dbus.Byte(0), dbus.Byte(137), dbus.Byte(24), dbus.Byte(128), dbus.Byte(43), dbus.Byte(51), dbus.Byte(56), dbus.Byte(54), dbus.Byte(52), dbus.Byte(49), dbus.Byte(55), dbus.Byte(52), dbus.Byte(50), dbus.Byte(49), dbus.Byte(56), dbus.Byte(54), dbus.Byte(47), dbus.Byte(84), dbus.Byte(89), dbus.Byte(80), dbus.Byte(69), dbus.Byte(61), dbus.Byte(80), dbus.Byte(76), dbus.Byte(77), dbus.Byte(78), dbus.Byte(0), dbus.Byte(150), dbus.Byte(16), dbus.Byte(234), dbus.Byte(70), dbus.Byte(119), dbus.Byte(100), dbus.Byte(58), dbus.Byte(32), dbus.Byte(70), dbus.Byte(119), dbus.Byte(100), dbus.Byte(58), dbus.Byte(32), dbus.Byte(70), dbus.Byte(119), dbus.Byte(100), dbus.Byte(58), dbus.Byte(0)], signature=dbus.Signature('y'))

so if anyone has any idea...

i am kinda new to this python/mms thingy.
Maybe if i would be able to understand the decodeMessageHeaderToList function or how the push message gets decoded i could do a fix but... well am trying to figure out stuff

Last edited by shubell; 2016-11-18 at 09:48.

Quote & Reply |

The Following 3 Users Say Thank You to shubell For This Useful Post:
Ilew, nieldk, peterleinchen

Ilew	2016-11-18 , 08:34
Posts: 75 \| Thanked: 269 times \| Joined on Aug 2012	#63

You could try to uncomment the line 159 in mms/mms_pdu.py :
#print '%s: %s' % (header, str(value))

This won't fix anything but you should be able to see if it decodes the From field if you run it via the cmd line.

Quote & Reply |

The Following 2 Users Say Thank You to Ilew For This Useful Post:
peterleinchen, shubell

	peterleinchen	2016-11-18 , 09:03
	Posts: 4,118 \| Thanked: 8,901 times \| Joined on Aug 2010 @ Ruhrgebiet, Germany	#64

Yep, go for Ilew's advice, please.

Even I would guess the decoding stops before all header fields read (provider moved it to a later position, possibly inserted a not-known header field in front of the 'From'?) as 'From' is a mandatory field and as you saw it is inside the push.
Did you check the binary '.sav' file (if existing) or the header file in the message folder, too?

Oh and thanks for the full logs ! [but at least you should/may remove clear text phone numbers for privacy]

__________________
SIM-Switcher, automated SIM switching with a Double (Dual) SIM adapter
--
Thank you all for voting me into the Community Council 2014-2016!

Please consider your membership / supporting Maemo e.V. and help to spread this by following/copying this link to your TMO signature:
[MC eV] Maemo Community eV membership application, http://talk.maemo.org/showthread.php?t=94257

editsignature, http://talk.maemo.org/profile.php?do=editsignature

Quote & Reply |

The Following 2 Users Say Thank You to peterleinchen For This Useful Post:
Ilew, shubell

shubell	2016-11-18 , 09:38
Posts: 64 \| Thanked: 84 times \| Joined on Oct 2012	#65

well tnx for all the info. You were correct the decoding stops a little bit too early. Here is the log. If i understand it correctly something breaks while reading the content location?

Code:

MMS 9200 2948 dbus.Array([dbus.Byte(97), dbus.Byte(112), dbus.Byte(112), dbus.Byte(108), dbus.Byte(105), dbus.Byte(99), dbus.Byte(97), dbus.Byte(116), dbus.Byte(105), dbus.Byte(111), dbus.Byte(110), dbus.Byte(47), dbus.Byte(118), dbus.Byte(110), dbus.Byte(100), dbus.Byte(46), dbus.Byte(119), dbus.Byte(97), dbus.Byte(112), dbus.Byte(46), dbus.Byte(109), dbus.Byte(109), dbus.Byte(115), dbus.Byte(45), dbus.Byte(109), dbus.Byte(101), dbus.Byte(115), dbus.Byte(115), dbus.Byte(97), dbus.Byte(103), dbus.Byte(101), dbus.Byte(0), dbus.Byte(175), dbus.Byte(132)], signature=dbus.Signature('y')) dbus.Array([dbus.Byte(140), dbus.Byte(130), dbus.Byte(152), dbus.Byte(55), dbus.Byte(68), dbus.Byte(49), dbus.Byte(55), dbus.Byte(66), dbus.Byte(67), dbus.Byte(52), dbus.Byte(57), dbus.Byte(0), dbus.Byte(141), dbus.Byte(145), dbus.Byte(138), dbus.Byte(128), dbus.Byte(142), dbus.Byte(2), dbus.Byte(6), dbus.Byte(208), dbus.Byte(136), dbus.Byte(5), dbus.Byte(129), dbus.Byte(3), dbus.Byte(3), dbus.Byte(244), dbus.Byte(128), dbus.Byte(131), dbus.Byte(104), dbus.Byte(116), dbus.Byte(116), dbus.Byte(112), dbus.Byte(58), dbus.Byte(47), dbus.Byte(47), dbus.Byte(109), dbus.Byte(109), dbus.Byte(115), dbus.Byte(46), dbus.Byte(116), dbus.Byte(101), dbus.Byte(108), dbus.Byte(101), dbus.Byte(107), dbus.Byte(111), dbus.Byte(109), dbus.Byte(46), dbus.Byte(115), dbus.Byte(105), dbus.Byte(47), dbus.Byte(77), dbus.Byte(66), dbus.Byte(47), dbus.Byte(47), dbus.Byte(55), dbus.Byte(68), dbus.Byte(49), dbus.Byte(55), dbus.Byte(66), dbus.Byte(67), dbus.Byte(52), dbus.Byte(57), dbus.Byte(0), dbus.Byte(137), dbus.Byte(24), dbus.Byte(128), dbus.Byte(43), dbus.Byte(51), dbus.Byte(56), dbus.Byte(54), dbus.Byte(52), dbus.Byte(49), dbus.Byte(55), dbus.Byte(52), dbus.Byte(50), dbus.Byte(49), dbus.Byte(56), dbus.Byte(54), dbus.Byte(47), dbus.Byte(84), dbus.Byte(89), dbus.Byte(80), dbus.Byte(69), dbus.Byte(61), dbus.Byte(80), dbus.Byte(76), dbus.Byte(77), dbus.Byte(78), dbus.Byte(0), dbus.Byte(150), dbus.Byte(31), dbus.Byte(41), dbus.Byte(234), dbus.Byte(70), dbus.Byte(119), dbus.Byte(100), dbus.Byte(58), dbus.Byte(32), dbus.Byte(70), dbus.Byte(119), dbus.Byte(100), dbus.Byte(58), dbus.Byte(32), dbus.Byte(70), dbus.Byte(119), dbus.Byte(100), dbus.Byte(58), dbus.Byte(32), dbus.Byte(70), dbus.Byte(119), dbus.Byte(100), dbus.Byte(58), dbus.Byte(32), dbus.Byte(70), dbus.Byte(119), dbus.Byte(100), dbus.Byte(58), dbus.Byte(32), dbus.Byte(70), dbus.Byte(119), dbus.Byte(100), dbus.Byte(58), dbus.Byte(32), dbus.Byte(70), dbus.Byte(119), dbus.Byte(100), dbus.Byte(58), dbus.Byte(32), dbus.Byte(70), dbus.Byte(119), dbus.Byte(100), dbus.Byte(58), dbus.Byte(0)], signature=dbus.Signature('y')) 
Message-Type: m-notification-ind 
Transaction-Id: 7D17BC49 
MMS-Version: 1.1 
Message-Class: Personal 
Message-Size: 1744 
Expiry: 259200 
Content-Location: h 
Traceback (most recent call last): 
File "/usr/lib/python2.5/logging/handlers.py", line 73, in emit 
if self.shouldRollover(record): 
File "/usr/lib/python2.5/logging/handlers.py", line 146, in shouldRollover 
msg = "%s\n" % self.format(record) 
File "/usr/lib/python2.5/logging/__init__.py", line 630, in format 
return fmt.format(record) 
File "/usr/lib/python2.5/logging/__init__.py", line 418, in format 
record.message = record.getMessage() 
File "/usr/lib/python2.5/logging/__init__.py", line 288, in getMessage 
msg = msg % self.args 
TypeError: not all arguments converted during string formatting 
+ id -u 
+ [ 29999 != 0 ] 
+ exec sudo /opt/fmms/fmms_magic START gprs0 10.206.128.13 mms.telekom.si mms.telekom.si 213.229.249.161 213.229.249.40

about the binary .sav file. Where is it stored? I only saw the filles stored in the .fmms/push folder and the LAST_INCOMING file in .fmms/temp/

Quote & Reply |

The Following User Says Thank You to shubell For This Useful Post:
Ilew

Ilew	2016-11-18 , 10:28
Posts: 75 \| Thanked: 269 times \| Joined on Aug 2012	#66

It's breaking the while loop when it finds contentLocation.
In mms/mms_pdu.py comment out lines 152-154:

Code:

            elif header == MMSEncodingAssignments.fieldNames[0x03][0]:
                contentLocationFound = True
                break

This should allow the function to decode the header a bit further.

Quote & Reply |

The Following User Says Thank You to Ilew For This Useful Post:
shubell

shubell	2016-11-18 , 13:08
Posts: 64 \| Thanked: 84 times \| Joined on Oct 2012	#67

It works. I can get the full header now. Even tho there are still some errors. The question is if something is now broken because of those 3 lines.

Code:

MMS 9200 2948 dbus.Array([dbus.Byte(97), dbus.Byte(112), dbus.Byte(112), dbus.Byte(108), dbus.Byte(105), dbus.Byte(99), dbus.Byte(97), dbus.Byte(116), dbus.Byte(105), dbus.Byte(111), dbus.Byte(110), dbus.Byte(47), dbus.Byte(118), dbus.Byte(110), dbus.Byte(100), dbus.Byte(46), dbus.Byte(119), dbus.Byte(97), dbus.Byte(112), dbus.Byte(46), dbus.Byte(109), dbus.Byte(109), dbus.Byte(115), dbus.Byte(45), dbus.Byte(109), dbus.Byte(101), dbus.Byte(115), dbus.Byte(115), dbus.Byte(97), dbus.Byte(103), dbus.Byte(101), dbus.Byte(0), dbus.Byte(175), dbus.Byte(132)], signature=dbus.Signature('y')) dbus.Array([dbus.Byte(140), dbus.Byte(130), dbus.Byte(152), dbus.Byte(49), dbus.Byte(53), dbus.Byte(52), dbus.Byte(67), dbus.Byte(51), dbus.Byte(56), dbus.Byte(56), dbus.Byte(54), dbus.Byte(0), dbus.Byte(141), dbus.Byte(145), dbus.Byte(138), dbus.Byte(128), dbus.Byte(142), dbus.Byte(2), dbus.Byte(6), dbus.Byte(172), dbus.Byte(136), dbus.Byte(5), dbus.Byte(129), dbus.Byte(3), dbus.Byte(3), dbus.Byte(244), dbus.Byte(128), dbus.Byte(131), dbus.Byte(104), dbus.Byte(116), dbus.Byte(116), dbus.Byte(112), dbus.Byte(58), dbus.Byte(47), dbus.Byte(47), dbus.Byte(109), dbus.Byte(109), dbus.Byte(115), dbus.Byte(46), dbus.Byte(116), dbus.Byte(101), dbus.Byte(108), dbus.Byte(101), dbus.Byte(107), dbus.Byte(111), dbus.Byte(109), dbus.Byte(46), dbus.Byte(115), dbus.Byte(105), dbus.Byte(47), dbus.Byte(76), dbus.Byte(74), dbus.Byte(47), dbus.Byte(47), dbus.Byte(49), dbus.Byte(53), dbus.Byte(52), dbus.Byte(67), dbus.Byte(51), dbus.Byte(56), dbus.Byte(56), dbus.Byte(54), dbus.Byte(0), dbus.Byte(137), dbus.Byte(24), dbus.Byte(128), dbus.Byte(43), dbus.Byte(51), dbus.Byte(56), dbus.Byte(54), dbus.Byte(52), dbus.Byte(49), dbus.Byte(55), dbus.Byte(52), dbus.Byte(50), dbus.Byte(49), dbus.Byte(56), dbus.Byte(54), dbus.Byte(47), dbus.Byte(84), dbus.Byte(89), dbus.Byte(80), dbus.Byte(69), dbus.Byte(61), dbus.Byte(80), dbus.Byte(76), dbus.Byte(77), dbus.Byte(78), dbus.Byte(0), dbus.Byte(150), dbus.Byte(6), dbus.Byte(234), dbus.Byte(116), dbus.Byte(101), dbus.Byte(115), dbus.Byte(116), dbus.Byte(0)], signature=dbus.Signature('y')) 
Message-Type: m-notification-ind 
Transaction-Id: 154C3886 
MMS-Version: 1.1 
Message-Class: Personal 
Message-Size: 1708 
Expiry: 259200 
Content-Location: http://mms.telekom.si/LJ//154C3886 
From: +38641666999/TYPE=PLMN 
Subject: test 
() 
Subject: t 
Traceback (most recent call last): 
File "/usr/lib/python2.5/logging/handlers.py", line 73, in emit 
if self.shouldRollover(record): 
File "/usr/lib/python2.5/logging/handlers.py", line 146, in shouldRollover 
msg = "%s\n" % self.format(record) 
File "/usr/lib/python2.5/logging/__init__.py", line 630, in format 
return fmt.format(record) 
File "/usr/lib/python2.5/logging/__init__.py", line 418, in format 
record.message = record.getMessage() 
File "/usr/lib/python2.5/logging/__init__.py", line 288, in getMessage 
msg = msg % self.args 
TypeError: not all arguments converted during string formatting 
+ id -u 
+ [ 29999 != 0 ] 
+ exec sudo /opt/fmms/fmms_magic START gprs0 10.206.128.9 mms.telekom.si mms.telekom.si 213.229.249.161 213.229.249.40

btw is it normal that you receive the mms notification after the mms has been downloaded not after the push sms?

Code:

2016-11-18 14:00:35,702 fmms.__main__: Incoming SMS Push!
2016-11-18 14:00:35,748 fmms.__main__: SRC: MMS:9200
2016-11-18 14:00:35,750 fmms.__main__: DST: 2948
2016-11-18 14:00:35,754 fmms.__main__: decoding...
2016-11-18 14:00:35,814 fmms.controller: content-location: http://mms.telekom.si/LJ//154D3AF6
2016-11-18 14:00:35,826 fmms.controller: transid: 154D3AF6
2016-11-18 14:00:35,828 fmms.controller: Sender: +38641742186/TYPE=PLMN
2016-11-18 14:00:35,954 fmms.controller: saved binary push: <open file '/home/user/.fmms/push/154D3AF6', mode 'wb' at 0x41780140>
2016-11-18 14:00:36,201 fmms.contacts: loaded contacthandler in 0.15 s
2016-11-18 14:00:36,632 fmms.__main__: saving...
2016-11-18 14:00:36,661 fmms.dbhandler: inserted row as: 626
2016-11-18 14:00:37,274 fmms.__main__: fetching mms...
2016-11-18 14:00:37,367 fmms.connectors: i acquired lock (2653)
2016-11-18 14:00:37,377 fmms.connectors: RUNNING IN UGLYHACK MODE
2016-11-18 14:00:37,440 fmms.connectors: UglyHackHandler UP!
APN: Mms.mobitel.si user: mobitel pass: internet proxyip: 213.229.249.40 mmsc1: mms.telekom.si mmsc2: mms.telekom.si
2016-11-18 14:04:39,781 fmms.connectors: fmms_magic retcode: 0
2016-11-18 14:04:39,784 fmms.__main__: getting file: http://mms.telekom.si/LJ//154D3AF6
2016-11-18 14:04:39,920 fmms.__main__: sending notify...
2016-11-18 14:04:39,923 fmms.__main__: using custom mms
2016-11-18 14:04:39,949 fmms.__main__: connecting via proxy 213.229.249.40:8080
2016-11-18 14:04:39,952 fmms.__main__: mmschost: http://mms.telekom.si
2016-11-18 14:04:41,172 fmms.__main__: MMSC STATUS: 200 OK
2016-11-18 14:04:41,177 fmms.__main__: MMSC RESPONDED: {}
2016-11-18 14:04:41,180 fmms.__main__: m-notifyresp-ind: (200, 'OK', {}, True)
2016-11-18 14:04:41,183 fmms.__main__: notifyresp sent
2016-11-18 14:04:41,187 fmms.__main__: connecting with proxy 213.229.249.40:8080
2016-11-18 14:04:41,203 fmms.__main__: trying url: http://mms.telekom.si/LJ//154D3AF6
2016-11-18 14:04:45,972 fmms.__main__: mmsc info: content-length: 2020^M
content-type: application/vnd.wap.mms-message^M
date: Fri, 18 Nov 2016 14:04:45 +0100^M
Connection: close^M

2016-11-18 14:04:46,028 fmms.controller: saved binary mms <open file '/home/user/.fmms/mms/154D3AF6/message', mode 'wb' at 0x417fa920>
2016-11-18 14:04:46,031 fmms.__main__: fetched http://mms.telekom.si/LJ//154D3AF6 and wrote to file
2016-11-18 14:04:46,148 fmms.__main__: sending ack...
2016-11-18 14:04:46,152 fmms.__main__: using custom mms
2016-11-18 14:04:46,183 fmms.__main__: connecting via proxy 213.229.249.40:8080
2016-11-18 14:04:46,185 fmms.__main__: mmschost: http://mms.telekom.si
2016-11-18 14:04:47,010 fmms.__main__: MMSC STATUS: 200 OK
2016-11-18 14:04:47,014 fmms.__main__: MMSC RESPONDED: {}
2016-11-18 14:04:47,017 fmms.__main__: m-acknowledge-ind: (200, 'OK', {}, True)
2016-11-18 14:04:47,020 fmms.__main__: ack sent
2016-11-18 14:04:47,025 fmms.connectors: UglyHackHandler running disconnect
2016-11-18 14:04:47,305 fmms.connectors: disconnecting connection. rx: 3230 tx: 5013
2016-11-18 14:04:47,314 fmms.connectors: UglyHackHandler running disconnect
2016-11-18 14:04:47,539 fmms.connectors: disconnecting connection. rx: 3334 tx: 5065
2016-11-18 14:04:47,547 fmms.__main__: decoding mms... path: /home/user/.fmms/mms/154D3AF6
2016-11-18 14:04:47,549 fmms.controller: decode_binary_mms running: /home/user/.fmms/mms/154D3AF6
2016-11-18 14:04:47,887 fmms.controller: returning message!
2016-11-18 14:04:47,890 fmms.__main__: storing mms...
2016-11-18 14:04:47,938 fmms.dbhandler: inserted row as: 644
2016-11-18 14:04:48,355 fmms.dbhandler: inserting attachment: smil.smil
2016-11-18 14:04:48,403 fmms.dbhandler: inserting attachment: text_0.txt
2016-11-18 14:04:48,442 fmms.dbhandler: inserting attachment: unnamed.png
2016-11-18 14:04:48,482 fmms.dbhandler: inserting description: test2
2016-11-18 14:04:48,521 fmms.__main__: notifying mms...
2016-11-18 14:04:48,842 fmms.__main__: done, returning!

Quote & Reply |

The Following User Says Thank You to shubell For This Useful Post:
Ilew

	peterleinchen	2016-11-18 , 14:22
	Posts: 4,118 \| Thanked: 8,901 times \| Joined on Aug 2010 @ Ruhrgebiet, Germany	#68

Your content-location contains a double slash '//', possibly this causes this (not checked just guess)

the .sav. file is only saved as a binary copy of the downloaded MMS if decoding fails, seems decoding returned success even FROM was nog filled?

iirc notification should appear on push message

Quote & Reply |

The Following 3 Users Say Thank You to peterleinchen For This Useful Post:
Ilew, shubell, xes

Ilew	2016-11-18 , 20:01
Posts: 75 \| Thanked: 269 times \| Joined on Aug 2012	#69

Well it's only errors when the print isn't giving the correct amount of arguments. This is probably because when we find 'Content-Type' field we don't assign the value to the header. Turning off the print should fix that error, or even adding 'self._mmsMessage.headers[header] = value' would fix it. I suggest the former option.

With that said I don't think commenting out the 'Content-Location' check will cause any problems. Mostly because it doesn't look for it when calling 'decodeMessageHeader'.

The notification will happen on push sms only if we failed to fetch. Otherwise it does it after it's downloaded.

Quote & Reply |

The Following 3 Users Say Thank You to Ilew For This Useful Post:
peterleinchen, shubell, xes

xes	2016-11-18 , 21:38
Posts: 638 \| Thanked: 1,692 times \| Joined on Aug 2009	#70

@ilew go ahead and fix it in extras.

One request:
very often i see the error "impossible to download" when i receive messages with one image but without any text inside. (or corrupted text part? - no idea)
Then, looking in the fmms folder, i can find the new folder with the image correctly saved.

In case of an error during the download, would it be possible to manage the problem evaluating the presence of new files (not empty) asking confirmation before open them?
(Example: an error has occurred during the download but one part of the message has been saved. Do you want to open it?)