MMS misluk op Android met VPN aan: die netwerkverskaffer se pad eerste

Webblaaie laai, oproepe werk, en ’n prentboodskap bly op stuur hang sonder ’n fout waarop jy kan reageer. Daardie kombinasie is nie ’n internetonderbreking nie. MMS is ’n netwerkverskafferdiens met sy eie konfigurasie en sy eie afleweringspad, en op Android kan die platform ’n spesifieke netwerk daarvoor aanvra in plaas daarvan om dieselfde roete as jou blaaier te gebruik. Drie besluite volg: watter tipe boodskap werklik gefaal het, wie die vervoer besit, en of die VPN hoegenaamd betrokke is.

Watter tipe boodskap het werklik gefaal

SMS, netwerkverskaffer-MMS en RCS is drie verskillende dienste wat een gesprekvenster deel. Die borrel in die draad sê nie vir jou watter een gebruik is nie, en die herstel vir een raak nie die ander nie. ’n Mislukte prentboodskap wat eintlik ’n RCS-boodskap is, sal nie reggestel word deur APN-instellings te verander nie, en ’n MMS wat nooit die foon verlaat het nie, sal nie reggestel word deur RCS weer te registreer nie.

Stel die fout vas in die eenvoudigste terme wat beskikbaar is: kom ’n suiwer teks-SMS aan, misluk ’n klein prentjie by stuur, by ontvang of by albei, en dateer die fout voor die VPN. As die antwoord is dat net inkomende prente misluk, kyk jy na ’n aflaaipad, wat anders optree as ’n oplaaispad op ’n beperkte netwerk.

MMS vra vir ’n netwerk, nie net ’n roete nie

Android stel MMS-bewerkings beskikbaar deur SmsManager en die platform se MMS-diens, wat ’n sellulêre netwerk met die MMS-vermoë vir ’n spesifieke intekening kan aanvra. Dit is ’n nouer versoek as wanneer ’n toepassing ’n HTTPS-verbinding oor die verstekroete open. Dit is ook hoekom ’n VPN wat al die gewone verkeer dra, saam met ’n werkende MMS-pad kan bestaan, en hoekom die omgekeerde kombinasie as ’n fout opduik.

Die onderskeid maak saak, want dit wys na verskillende eienaars. As die platform se MMS-versoek nie bevredig kan word nie, is die probleem aan die intekening- of netwerkverskafferkant. As dit slaag maar die oordrag net terwyl die VPN aktief is vassteek, is die toepassing se netwerkintegrasie of die VPN-beleid die beter verdagte. Om tussen daardie twee te raai, mors die meeste tyd in hierdie soort verslag.

Los die netwerkverskaffer se konfigurasie alleen

Hou die netwerkverskaffer se bedoelde APN, MMS-bedieneradres en instellings vir die instaanbediener net so. ’n VPN wat jou blaaiery verander, is nie ’n rede om ’n onbekende APN of ’n openbare DNS-bediener in te plak nie; MMS gebruik nie die wysiger wat jou blaaier verkies nie, en ’n verkeerde APN breek die een pad wat gewerk het.

Kyk op ’n tweesimfoon na twee afsonderlike dinge: watter intekening tans mobiele data besit, en van watter intekening die boodskap gestuur is. Dit is algemeen om te toets op die SIM wat toevallig data het, terwyl die mislukkende draad aan die ander een gekoppel is. ’n Ouer derdeparty-boodskapp kan ook ’n pasgemaakte of verouderde netwerkpad gebruik wat anders optree as die stelselgeïntegreerde pad, so verkies die onderhoude toepassing se gedokumenteerde modus bo kieslysname wat jy uit ’n ou weergawe onthou.

Maak die vergelyking eng

Hou alles konstant behalwe die een veranderlike wat jy toets: dieselfde toepassing, dieselfde ontvanger, dieselfde intekening, een klein nie-sensitiewe toetsfoto. Teken op of stuur, ontvang of albei misluk, wat die presiese foutteks is, en of die uitkoms verander wanneer die VPN aktief is.

As beleid dit op ’n persoonlike toestel toelaat, is ’n kort vergelyking sonder die VPN ’n goeie manier om die afhanklikheid te isoleer. Dit is ’n diagnostiek, nie ’n aanbeveling om onbeskermd te werk nie, en op ’n bestuurde of vastgesluite toestel kom die ondersteunde werkvloei van die administrateur eerder as van ’n forumpos. Vermy om private media herhaaldelik te stuur net om ’n fout te reproduseer wat jy een keer kan reproduseer.

Wat om aan ondersteuning te gee, en wat nie om te aanvaar nie

As net die geval met die VPN aktief misluk, bevat die nuttige verslag die kliëntnaam en -weergawe, die boodskaptoepassing se weergawe, die netwerktipe, die intekening in gebruik en die presiese plaaslike tyd van die fout. Met daardie vyf feite kan iemand die fout teen netwerkverskaffer- en kliëntlogboeke oplyn in plaas daarvan om te raai.

Moenie aanvaar dat om die boodskaptoepassing uit te sluit ’n kuur is nie. Stelseltelefonie-komponente kan deel van die bewerking besit, en ’n beleid wat blokkeer sonder die VPN tree anders op as ’n eenvoudige uitsluiting, so die toepassing kan steeds misluk terwyl dit vrygestel lyk. Toets die uitsluiting as ’n hipotese, hou die resultaat, en draai dit terug as die bewyse dit nie ondersteun nie.