MMS retrieval BAM! got it

Wed Jun 12 21:23:55 UTC 2019

So it was a dns thing, like most problems of this type are.  I ignore 
the carriers 10.*.*.* dns entries and used googles because they're 
almost always faster.

But wouldn't you know it that if I use the carriers dns entries the url 
resolves to a 10.* address and a straight curl call works.

So yeah, if you need to retrieve MMS from t-mobile use their DNS to do 
it. If you go off the reservation with curl and wget and custom compile 
it, you can get a --dns-servers option if you want to avoid doing 
anything clever but default debian doesn't have that in there for either.

On 6/12/19 2:05 PM, Christopher McKenzie wrote:
> As usual the people on stackoverflow seem to not have any of the 
> troubles I do.
>
> I've tried binding it both to my ipv4 and ipv6 address. I tried 
> running the initial binary through the MMS decoder here 
> (https://raw.githubusercontent.com/heyman/mms-decoder/master/mmsdecoder.php) 
> which gave useful information such as the size etc but nothing that 
> looks like some kind of salt or auth token I might need to pass 
> (nobody is *suggesting* this, I'm just kinda out of ideas)
>
> It's important to note that there seems to be some other container 
> format (here's a dump of the mms I'm looking at now http://9ol.es/mms) 
> The decodable parts are 0x26-0xcf
>
> Also there is this other hint. There's these two strings:
>
> http://ttnmmsget.msg.eng.t-mobile.com/mms/wapenc?T=mavodi-1-13b-ad-4-9d-3fd9efc 
>
> mavodi-1-89-1b-5-9d-1-ad-4-9d-3fd9efc
>
> Upon closer inspection they aren't the same.
> mavodi-1-13b-ad-4-9d-3fd9efc
> mavodi-1-89-1b-5-9d-1-ad-4-9d-3fd9efc
>
> I'm thinking that the 3GPP TS 33.220 has an opinion on what that means 
> but I haven't gone through the trouble of looking at it.
>
> Lastly I tried very small files on the theory that all of this is 
> simply to stitch large files over some limited connection but alas, 
> that also led nowhere.
>
> On 6/12/19 1:09 PM, Dan Williams wrote:
>> On Wed, 2019-06-12 at 12:52 -0700, Christopher McKenzie wrote:
>>> Replies below.
>>>
>>> On 6/12/19 11:25 AM, Dan Williams wrote:
>>>> On Wed, 2019-06-12 at 10:34 -0700, Christopher McKenzie wrote:
>>>>> Hello,
>>>>>
>>>>> I've checked the mailing list and I can't find any history on
>>>>> this.
>>>>> I'm
>>>>> wondering if anyone has successfully received the content of MMS
>>>>> messages.
>>>>>
>>>>> On my T-Mobile SIM I get a message that translates to
>>>>> (binascii.unhexlify of the mmcli -m -s * content)
>>>>> "application/vnd.wap.mms-message" with a URL link at the end of
>>>>> the
>>>>> payload.  When I curl -I the url I get the following:
>>>>>
>>>>> 299 GBA "Generic Bootstrapping Architecture (3GPP TS 33.220)
>>>>> support
>>>>> is
>>>>> required to access the requested resource"
>>>>>
>>>>> After doing some research it looks like the server wants to have
>>>>> a
>>>>> sophisticated conversation with me (see the spec here, warning
>>>>> zipped
>>>>> msword:
>>>>> https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2280). 
>>>>>
>>>>>
>>>>> I've seen evidence that Maemo knows how to talk this language and
>>>>> after
>>>>> searching the source code I believe that gammu does not.
>>>>>
>>>>> I've found a few implementations that will decode the
>>>>> vnd.wap.mms-message payload, but no standalone that will then
>>>>> proceed
>>>>> to
>>>>> talk with the remote server and get the content.
>>>>>
>>>>> Has anyone found any open source tools that can ingest these
>>>>> application/vnd.wap.mms-message payloads and get the
>>>>> corresponding
>>>>> MMS
>>>>> content?
>>>> IIRC it's just HTTP to the MMSC over the MMS PDP/EPS context if
>>>> your
>>>> provider uses a non-default context for MMS. Otherwise it can just
>>>> go
>>>> to the MMSC over the default context.
>>> A standard curl request returns:
>>>
>>> HTTP/1.1 400 Bad Request
>>> Warning: 299 GBA "Generic Bootstrapping Architecture (3GPP TS
>>> 33.220)
>>> support  required to access the requested resource"
>>> Connection: Close
>>> Content-Length: 0
>>> Content-Type: text/html; charset=UTF-8
>> Are you sure the curl is going out via the modem network interface?
>> Like I said I don't know a ton about it, but this thread:
>>
>> https://stackoverflow.com/questions/53783799/receiving-a-binary-mms#
>>
>> seems to say the user got that GBA error until they bound curl/wget to
>> the IP of the modem:
>>
>> "When I do wget --bind-address=IP.OF.MO.DEM ttnmmsget.msg.eng.t-
>> mobile.com/mms/… it does download a fairly big file with no extension:
>> wapenc?T=mavodi-1-13b-db-1-9d-3fcf1b8 ..."
>>
>>> On my mobile phone it doesn't seem to use the URL at all. If I
>>> disable
>>> data and turn off my wifi I can still receive photographs. Even when
>> Often MMS will use a different PDP/EPS context that is not billed the
>> same (or is even free/unlimited) as the default data context. So
>> perhaps in this case disabling data just deactivates the default
>> context and MMS is still enabled. Just a guess.
>>
>> Dan
>>
>>> I
>>> have only the wifi on if I do tcpdump at the router there's no
>>> traffic
>>> that goes over the network to retrieve the image.
>>>
>>> So this means that there's ways of retrieving the media OTA without
>>> using the internet and that I'd at least have to modify my HTTP
>>> header
>>> to get the server to play nicely. Maybe it's effectively just and
>>> HTTP
>>> GET but I need to append something to the request to tell the server
>>> I'm
>>> special somehow
>>>
>>>> Which is why ModemManager doesn't do anything MMS-related because
>>>> MMS
>>>> is all at the IP level so once MM has set up connectivity then
>>>> anything
>>>> can do MMS.
>>>>
>>>> For example, fMMS:
>>>>
>>>> https://github.com/frals/fmms/blob/315e24068ef23e87f68838ff96e6ec91f7849959/wappushhandler.py#L225 
>>>>
>>> This appears to just do essentially an HTTP GET ... I tried it with
>>> the
>>> x-wap-profile header as the code does just for kicks but I continue
>>> to
>>> get the 400 Bad Request. There may be a proxy as the code suggests
>>> but I
>>> haven't found evidence of that.
>>>
>>>
>>>> But I don't actually know much more than that. But I think fMMS is
>>>> basically what you want, albeit in Python and coded to Maemo UI and
>>>> system services.
>>>>
>>>> MM might still be involved if it doesn't correctly
>>>> deliver/interpret
>>>> the SMS Push messages that say you have a new MMS to receive, but I
>>>> think it already does that. I haven't checked though.
>>> yes, you can do this through dbus.
>>>
>>>
>>>> Dan
>>>>
>>>>> Or, alternatively, is there another way to retrieve the (mostly)
>>>>> images
>>>>> from an MMS message that doesn't use this approach? Thanks.
>>>>>
>>>>> ~chris.
>>>>>
>>>>> _______________________________________________
>>>>> libqmi-devel mailing list
>>>>> libqmi-devel at lists.freedesktop.org
>>>>> https://lists.freedesktop.org/mailman/listinfo/libqmi-devel
>>> _______________________________________________
>>> libqmi-devel mailing list
>>> libqmi-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/libqmi-devel