Ano ba talaga ang hinihintay ng gateway-ping-timeout sa NetworkManager

Makikita mo ang connection.gateway-ping-timeout sa isang usapan tungkol sa laptop na nagbo-boot bago pa maging magamit ang network, itataas mo ito, at may nagbabago. Kung nakatulong ang pagbabago sa dahilang iniisip mo ay hiwalay na tanong. Nagsisimula ang sagot sa aktuwal na ginagawa ng activation habang tumatakbo ang timer na iyon, at sa katotohanang may dalawang posibleng pagtatapos ang paghihintay.

Sundan ang isang koneksyon mula sa command line at magiging konkretong ang semantika.

Pagsunod sa isang activation

Magsimula sa naka-save na koneksyon at hindi sa global na default, dahil property ito ng bawat koneksyon. Idagdag ang --show-secrets kung talagang kailangan mo ito; ang setting mismo ay hindi lihim.

nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-ping

Kapag zero ang property, na siyang dokumentadong default, nagpapatuloy ang activation sa sandaling matapos ang addressing. Magtakda ng positibong halaga at ang activation ng IP configuration ay maghihintay hanggang may tugon mula sa gateway o mag-expire ang timeout.

Pagkatapos, ibaba at itaas muli ang koneksyon habang pinapanood ang event stream. Ang order na nakikita mo ay ang setting na gumagawa ng trabaho nito: state ng device, addressing, ang paghihintay, at sa huli ang activated state kung saan karaniwang naka-order ang mga dependent service.

May dalawang pagtatapos ang paghihintay

Mahalaga ang dalawang pagtatapos, at karamihan ay isa lang ang natatandaan. Ang tugon mula sa gateway ay nagtatapos ng paghihintay nang mas maaga, at ang timeout ay nagtatapos din nito, may sumagot man o wala. Hindi hinihiling ng property na ito ang matagumpay na ping bago makumpleto ang activation.

Ang isang pangungusap na iyon ay naglilinaw ng maraming kalituhan tungkol sa mga laptop sa mga hotel at conference venue, kung saan madalas tinatanggihan ng captive portal ang ICMP hanggang mag-login ka. Nag-a-activate pa rin ang koneksyon pagkatapos mag-expire ang timeout; mas huli lang itong ginagawa kaysa sa kailangan, at bawat service na naka-order pagkatapos ng koneksyon ay naghihintay kasama nito.

Hindi rin ito liveness check. Wala sa paglalarawan ang nagsisimulang mag-ping sa gateway pagkatapos umangat ang koneksyon, at walang nagdi-disconnect sa aktibong profile dahil nabigo ang susunod na ping. Kung kailangan mo ng loss detection, pag-aari iyon ng protocol o ng may-ari ng tunnel, hindi ng property na tumakbo nang isang beses noong activation.

Dalawang object, isang setting

Ang wired base profile at ang VPN profile ay magkahiwalay na configuration object, at ang pagtatakda ng property sa isa ay hindi nakakaapekto sa isa. Ang VPN profile na nagpangalan ng base connection ay hindi nagmamana ng alinman sa mga activation setting nito, kaya ang halagang binago mo ay maaaring magmukhang walang epekto sa bagay na pinapanood mo.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-ping

Basahin ang UUID at hindi ang mga pangalan. Nadodoble ang mga pangalan pagkatapos ng reinstall o naibalik na profile, at dalawang koneksyon na may parehong nakikitang pangalan ang mag-uudyok sa iyong i-edit ang maling file habang ang tunay ay nananatiling hindi nagbabago.

Mahalaga rin ang naka-install na release ng NetworkManager. Nag-iiba ang pag-uugali ng plugin at kung paano minamapa ng uri ng koneksyon ang property na ito sa sarili nitong mga hakbang sa activation, kaya subukan sa bersyong dine-deploy mo sa halip na ipalagay na ang post na nakita mo ay applicable nang walang pagbabago.

Ano ang hindi maipapatunay ng paghihintay

Narito ang bahaging pinakamalaki ang gastos sa oras. Ang tugon mula sa lokal na router ay nagpapatunay na isang host ang sumagot sa isang ICMP echo noong activation. Hindi nito pinatutunayan na nagre-resolve ang isang VPN endpoint, na tinatanggap ang pagkakakilanlan ng client, na nailagay ang mga pribadong ruta, na sumasagot ang resolver ng opisina, o na gagana ang application na mahalaga sa iyo.

Magkahiwalay na dependency ang mga iyon na may magkahiwalay na ebidensya. Maaaring sumagot ang gateway habang nabibigo ang DNS, at maaaring tahimik na i-drop ng gateway ang ICMP ayon sa patakaran habang gumagana ang lahat ng path ng application. Kaya ang paglalagay ng kondisyon sa property na ito ay isang hula kung aling layer ang nahuhuli, hindi isang pagsukat nito.

Kung naghihintay ka sa isang dependent service, pangalanan kung ano ang kailangan nito. Ang itinalagang address ay sinasagot ng addressing. Ang tunnel ay sinasagot ng sariling state ng tunnel. Ang pribadong pangalan ay sinasagot ng isang query. Ang application ay sinasagot ng application, at wala sa mga sagot na iyon ang nagmumula sa timer na ipinangalan sa gateway.

Kung babaguhin mo ito, isulat kung bakit

Itala ang dating halaga at ang dahilan bago ang isang aprubadong pagbabago, pagkatapos ay itakda ito sa partikular na koneksyon at hindi sa lahat ng dako. Ang mas mahabang paghihintay ay nagbabago ng oras ng activation para sa lahat ng naka-order pagkatapos ng koneksyong iyon, na maaaring magpamukhang maayos ang mabagal na sistema at sira ang mabilis.

May isang makasaysayang patibong na dapat pangalanan: ang ganitong halaga ay kung minsan binabago para tanggapin ng mas lumang editor ang isang profile. Kung iyon ang tunay na kuwento, mayroon kang dalawang pangyayari, hindi isa. Nag-save ang editor, at nagbago ang live na patakaran ng network. Ayusin ang editor o ang plugin at ibalik ang timer.

Itinatakda ng source ng NetworkManager ang property bilang pagkaantala ng tagumpay ng IP addressing hanggang sa tugon ng gateway o sa timeout, na may default na zero, at ang depinisyon ng setting ng koneksyon ang sangguniang dapat basahin bago umasa sa pag-uugaling ikinuwento ng iba.