Mae castio'n torri mewn tri lle sy'n edrych yr un fath o'r soffa. Efallai na fydd y ffôn byth yn gweld y derbynnydd, gall y derbynnydd ymddangos ac yna gwrthod y sesiwn, neu gall y sesiwn ddechrau ac oedi funud yn ddiweddarach. Mae twnnel ar y ffôn yn newid pob un o'r llwybrau hynny'n wahanol, ac ar gyfer un ohonynt nid yw'n newid dim o gwbl. Enwch y cam sy'n methu yn gyntaf, yna penderfynwch a yw newid polisi hyd yn oed yn lifer gywir i'w thynnu.

Enwch y cam sy'n methu cyn newid polisi

Gwyliwch beth mae'r ffôn yn ei wneud yn syth ar ôl i chi dapio'r eicon castio. Mae rhestr wag yn ganlyniad darganfod, mae tap sy'n adrodd methiant yn ganlyniad rheoli, ac mae sesiwn sy'n dechrau cyn oedi yn ganlyniad chwarae. Mae gan y tri hyn berchnogion gwahanol, a dim ond y ddau gyntaf sydd fel arfer yn ymwneud â gosodiadau twnnel y ffôn.

StageWhat the phone showsEvidence that separates it
DiscoveryNo receiver in the listAnother device on the same segment sees the receiver
ControlReceiver listed, session refusedPort answer versus permission prompt
PlaybackSession starts, then stallsThe receiver's own link, not the phone's

Ysgrifennwch y cam i lawr cyn newid unrhyw beth. Mae atgyweiriad a gymhwysir i'r cam anghywir yn gwneud y prawf nesaf yn annarllenadwy, ac mae'r rhan fwyaf o lên gwerin castio yn dod o'r dryswch hwnnw'n union.

Mae darganfod yn draffig lleol, ac mae twnnel yn ei guddio

Mae derbynyddion yn hysbysebu eu hunain trwy gyhoeddiadau lleol ac mae'r ffôn yn dod o hyd iddynt â chwestiynau ar yr un cyswllt, felly mae unrhyw beth sy'n tynnu'r ffôn oddi ar y cyswllt hwnnw'n tynnu'r derbynnydd oddi ar y rhestr. Gall twnnel sy'n llwybro'r holl draffig oddi wrth y LAN guddio'r cyfnewidiadau hynny, a gall caniatâd rhwydwaith lleol ar lefel ap rwystro nhw hyd yn oed pan fo'r llwybr yn bodoli. Mae Wi-Fi gwestai ag ynysu cleientiaid yn cynhyrchu'r un rhestr wag heb unrhyw VPN o gwbl. Profwch fod y ddau ddyfais yn rhannu segment cyn beio'r twnnel.

avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTR

Mae'r gorchymyn cyntaf yn rhestru'r hyn sy'n hysbysebu ei hun yn segment y peiriant cynorthwyol, ac mae'r ail yn gofyn i'r grŵp DNS multicast yn uniongyrchol. Ni fydd derbynnydd sydd ar goll o'r ddau yn ymddangos mewn ap ffôn chwaith, beth bynnag yw cyflwr twnnel y ffôn. Os yw'r derbynnydd yn weladwy o ddyfais sydd â'i thwnnel i ffwrdd ac yn anweladwy o un sydd â'i thwnnel ymlaen, rydych wedi dod o hyd i'r cam a'r achos gyda'i gilydd.

Mae eithriad LAN yn cadw'r twnnel ymlaen

Mae llawer o gleientiaid yn cynnig eithriad rhwydwaith lleol sy'n gadael y twnnel yn weithredol tra'n caniatáu cyfeiriadau lleol. Defnyddiwch y gosodiad dogfennedig hwnnw yn hytrach na diffodd y kill switch neu'r wal dân gyfan, oherwydd mae'r rheini'n newid llawer mwy nag sydd ei angen ar gastio. Os yw'r rhwydwaith yn gwahanu dyfeisiau clyfar yn fwriadol, gofynnwch i'r perchennog am y draffig darganfod, rheoli a dychwelyd penodol yn hytrach na gofyn am fynediad gwastad.

nc -vz 192.168.1.50 8009

Mae prawf rheoli yn erbyn y derbynnydd yn gwahanu caniatâd oddi wrth gyrhaeddiad: mae porth sy'n ateb yn golygu bod y llwybr yn bodoli, tra bo gwrthodiad yn golygu bod y ffôn wedi cael caniatâd i ddarganfod y ddyfais ac yn dal i fethu siarad â hi. Porthladdoedd 8008 a 8009 yw'r porthladdoedd castio arferol, a gall ap ddefnyddio eraill, felly triniwch un porth a wrthodwyd fel awgrym yn hytrach na dedfryd. Mae'r eithriad a chaniatâd yr ap yn aros yn annibynnol, gan nad yw rhoi mynediad lleol yn creu llwybr ac nad yw ychwanegu llwybr yn rhoi caniatâd. Gall kill switch hefyd ollwng traffig lleol ar ôl ailgysylltu, a dyna pam mae'n rhaid ailbrofi darganfod unwaith y daw'r twnnel yn ôl.

Efallai na fydd chwarae yn defnyddio cysylltiad y ffôn

Mewn sesiwn a gyfarwyddir gan ap mae'r ffôn yn rhoi cyfeiriad cyfrwng i'r derbynnydd ac mae'r derbynnydd yn ei nôl dros ei gysylltiad ei hun, felly nid yw newid cyfeiriad cyhoeddus y ffôn yn gwneud dim i'r ffrwd. Gall teitl sydd wedi'i gyfyngu gan gyfrif fethu o hyd am ei resymau ei hun, ac mae gofynion castio Google yn ymdrin â chydnawsedd ap a dyfais yn hytrach na'r llwybr rhwydwaith. Mae llwybro'r teledu ei hun drwy dwnnel yn ffurfweddiad ar wahân â'i gwestiynau polisi ei hun.

Mae dau gliw yn gwahaniaethu'r moddau. Mae cast sy'n goroesi cloi sgrin y ffôn yn cael ei gyfarwyddo gan ap, oherwydd bod y derbynnydd yn nôl ar ei liwt ei hun; mae drych sy'n stopio pan fydd sgrin y sawlydd yn cloi yn ffrwd barhaus o'r ffôn. Pan fydd darganfod a rheoli'n llwyddo ond chwarae'n oedi, edrychwch ar gyswllt Wi-Fi y derbynnydd a'i lwybr rhyngrwyd yn lle hynny, gan fod prawf cyflymder ar y ffôn yn disgrifio'r ffôn ac nid y teledu.

Dadwnewch yr eithriad ac ailbrofi

Mae angen ffordd yn ôl ar bob newid dros dro, ac mae'r drefn yn bwysig. Tynnwch yr eithriad LAN, ailgysylltwch y twnnel fel bod y cleient yn ailgymhwyso ei bolisi, yna ailadroddwch y cam darganfod a nodwch a yw'r derbynnydd yn diflannu eto. Mae'r dilyniant hwnnw'n dweud wrthych a oedd yr eithriad yn gwneud y gwaith neu a newidiodd rhywbeth arall yn y cyfamser.

# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'

Gwiriwch y tri cham ar wahân wedyn, oherwydd nid yw llwyddiant ar un yn dweud dim am y lleill. Yna gwiriwch fod apiau ffôn heb gysylltiad yn dal i ddilyn y llwybr a fwriadwyd, gan fod eithriad lleol a ddaeth yn ddistaw yn osgoi llwyr yn ganlyniad gwaeth na chast sy'n gofyn am un tap ychwanegol.

Erthyglau cysylltiedig