MMS retrieval BAM! got it

Thu Jun 13 21:00:08 UTC 2019

Split DNS is a very common practice in the telco world sadly. DNS manipulation plays a big role in how networks, and VoLTE calls work.
It is unhealthy in my opinion. Fortunately in 5G this will be changed. Hopefully the new repository function will make the correct distinction between network level and service level :).

Cheers
Domi

2019. jún. 12. dátummal, 23:35 időpontban Dan Williams <dcbw at redhat.com> írta:

>> On Wed, 2019-06-12 at 14:23 -0700, Christopher McKenzie wrote:
>> 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.
> 
> Well that's cute. I'm not surprised they'd return something different
> on non-internal interfaces than they do for the internal interface
> (assuming whatever the TMO DNS returns is the internal interface).
> 
> Good to know.
> 
> Dan
> 
>> 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
>> _______________________________________________
>> 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