MMS mislykkes på Android med VPN påslått: operatørens vei først
Bildemeldinger bruker sin egen operatørvei og sin egen nettverkskapasitet, så nettlesing som fungerer beviser ingenting. Skille SMS, MMS og RCS før du berører VPN.
Nettsider lastes inn, samtaler fungerer, men en bildemelding blir hengende på sending uten noen feilmelding du kan handle ut fra. Kombinasjonen er ikke det samme som internettnedbrudd. MMS er en operatørtjeneste med eget oppsett og egen leveringsvei, og på Android kan plattformen be om et bestemt nett for den fremfor å gjenbruke ruten nettleseren din valgte. Det gir tre spørsmål: hvilken meldingstype som egentlig feilet, hvem som står bak transporten, og om VPN i det hele tatt spiller en rolle.
Hvilken meldingstype som egentlig feilet
SMS, operatørens MMS og RCS er tre ulike tjenester som deler samme samtalevindu. Boblen i tråden sier ingenting om hvilken som ble brukt, og en reparasjon for én påvirker ikke de andre. En bildemelding som feiler og egentlig er en RCS-melding, blir ikke løst ved å endre APN-innstillingene, og en MMS som aldri forlot telefonen, blir ikke løst ved å registrere RCS på nytt.
Beskriv feilen med de enkleste ordene du har: kommer en SMS med bare tekst frem, feiler et lite bilde ved sending, ved mottak eller begge, og oppsto feilen før VPN ble slått på. Svarer du at bare innkommende bilder feiler, står du overfor en nedlastingsvei, som oppfører seg annerledes enn en opplastingsvei på et begrenset nett.
MMS krever et nett, ikke bare en rute
Android gjør MMS-operasjoner tilgjengelige gjennom SmsManager og plattformens MMS-tjeneste, som kan be om et mobilnett med MMS-støtte for et gitt abonnement. Det er en trangere forespørsel enn når en app åpner en HTTPS-forbindelse over standardruten. Derfor kan en VPN som frakter all vanlig trafikk leve side om side med en fungerende MMS-vei, og derfor fremstår den motsatte kombinasjonen som en feil.
Forskjellen betyr noe fordi den peker mot ulike ansvarlige. Klarer ikke plattformen å oppfylle MMS-forespørselen, ligger problemet hos abonnementet eller operatøren. Virker den, men overføringen stopper bare mens VPN er på, er appens nettverksintegrasjon eller VPN-regelverket en bedre kandidat. Å gjette mellom disse to er det som sløser mest tid i en slik rapport.
| What you observe | Where to look first |
|---|---|
| No mobile data at all, SMS also fails | Subscription, carrier data service, SIM state |
| Browsing works, MMS fails only with the VPN on | The app's network integration or the VPN policy |
| MMS fine, RCS will not register | RCS registration, unrelated to the MMS transport |
| MMS fails on one SIM but not the other | Which subscription owns mobile data, and which sent the message |
Ikke rør operatørens oppsett
La den tiltenkte APN-en, MMS-serveradressen og proxy-innstillingene stå urørt. At en VPN endrer hvordan du surfer, er ingen grunn til å klistre inn en fremmed APN eller en offentlig DNS-server; MMS bruker ikke den resolveren nettleseren din foretrekker, og en feil APN ødelegger den eneste veien som fungerte.
På en telefon med to SIM-kort, undersøk to ting hver for seg: hvilket abonnement som har mobildata akkurat nå, og hvilket abonnement meldingen ble sendt fra. Det er vanlig å teste på SIM-kortet som tilfeldigvis har data, mens den feilende tråden hører til det andre. En eldre meldingsapp fra tredjepart kan også bruke en egen eller utdatert nettverksvei som oppfører seg annerledes enn veien som er integrert i systemet, så velg den vedlikeholdte appens dokumenterte modus fremfor menynavn du husker fra en gammel versjon.
Hold sammenligningen stram
Alt skal være uendret bortsett fra variabelen du tester: samme app, samme mottaker, samme abonnement, ett lite og ufølsomt testbilde. Skriv ned om sending, mottak eller begge feiler, hva den nøyaktige feilteksten er, og om resultatet endrer seg når VPN er på.
Hvis reglene tillater det på en privat enhet, vil en kort sammenligning uten VPN avdekke avhengigheten. Dette er en diagnose, ikke en anbefaling om å kjøre uten beskyttelse, og på en administrert eller låst enhet kommer den støttede fremgangsmåten fra administratoren og ikke fra et foruminnlegg. Unngå å sende privat innhold om og om igjen bare for å gjenskape en feil du kan gjenskape én gang.
Hva du bør gi supporten, og hva du ikke bør anta
Feiler bare tilfellet med VPN på, bør rapporten inneholde klientens navn og versjon, meldingsappens versjon, nettverkstype, abonnementet som brukes og det eksakte lokale klokkeslettet for feilen. Med disse fem opplysningene kan noen sammenholde feilen med operatørens og klientens logger i stedet for å gjette.
Ikke gå ut fra at det å utelate meldingsappen løser problemet. Systemets telefonikomponenter kan eie deler av operasjonen, og en blokkeringsregel uten VPN virker annerledes enn en enkel utelatelse, så appen kan fortsatt feile selv om den ser utelatt ut. Prøv utelatelsen som en hypotese, ta vare på resultatet, og reverser den hvis bevisene ikke støtter den.