MMS retrieval BAM! got it

Wed Jun 12 21:34:59 UTC 2019

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